Amazon Connect, Twilio, NICE CXone und Avaya: vier Medienpfade, zwei Stellen, an denen man stehen kann

Jede Spezifikationsaussage unten ist aus der eigenen veröffentlichten Dokumentation des jeweiligen Herstellers zitiert und verlinkt; die Zitate geben wir im englischen Original wieder, weil es auf den exakten Wortlaut ankommt. Wo wir etwas nicht bestätigen konnten, ist es als unbestätigt markiert statt aufgefüllt, und gegen Ende gibt es eine konsolidierte Liste. Dieser Beitrag schärft außerdem etwas nach, das wir über Twilio zuvor zu stark formuliert haben; diese Korrektur hat einen eigenen Abschnitt. Sollte etwas davon falsch sein oder sich ändern, sagen Sie es uns, und wir korrigieren es mit Datum.

Der Begleitbeitrag liest Genesys Cloud AudioHook auf dieselbe Weise und findet ein Protokoll, das seine Abtastrate im Typsystem festnagelt, und einen Medienpfad ohne Einfügepunkt darin. Dieser hier behandelt die anderen vier Oberflächen, auf denen unsere Käufer tatsächlich laufen, und die Antwort ist weniger einheitlich, als wir erwartet hatten.

Eine Frage, jeder Plattform gestellt:

Kann ein Dritter das Anruf-Audio empfangen, es verarbeiten und das verarbeitete Audio zu dem machen, was der Bot, der Recognizer, die Aufzeichnung oder die Gegenseite der Plattform konsumiert?

Plattform	Oberfläche	Audio raus zu Ihnen	Verarbeitetes Audio zurück hinein	Dokumentierte Rate
Amazon Connect	Kinesis Video Streams	Ja	Nein	8 kHz
Twilio	<Connect><Stream>	Ja	Ja	8000 Hz µ-law
Twilio	<Connect><ConversationRelay>	Nein — nur JSON	Nein	nicht veröffentlicht
NICE CXone	Custom Agent Assist	Ja	Nein	8 kHz µ-law
NICE CXone	Custom Virtual Agent	Ja	Nur turn-basiertes Playback	G.711, Rate nicht genannt
Avaya Infinity	Real-time Contextual Media Streaming	Ja	Ja	8 kHz, oder 16 kHz auf G.722

Zwei davon sind echte Man-in-the-Middle-Positionen. Der Rest sind Abgriffe, Verzweigungen oder Bot-Turns im selben Vokabular.

Amazon Connect: eine Einweg-Verzweigung, und zwei Dinge, die alle falsch verstehen

Es wird nicht per API gestartet. StartContactStreaming ist der naheliegende Kandidat, und es ist der falsche — die eigene Referenz sagt, es "initiates real-time message streaming for a new chat contact", und sein einziges Konfigurationsobjekt ist eine Chat-Streaming-Config, die auf einen SNS-Endpoint zeigt. Es ist eine Chat-API.

Voice-Media-Streaming wird auf Instanzebene aktiviert und dann innerhalb eines Flows eingeschaltet:

"After you enable live media streaming, add Start media streaming and Stop media streaming blocks to your flow." — enable live media streams

Der Block bietet zwei Optionen — Stream vom Kunden oder zum Kunden — und gilt nur für Voice; jeder andere Kanal nimmt den Fehlerzweig. Soweit wir es finden können, gibt es keine öffentliche API, um Voice-Media-Streaming zu starten, nur den Flow-Block.

Das Format ist 8 kHz, und fast nichts sonst ist veröffentlicht. Das ist der Satz zum Zitieren:

"Media streaming uses Kinesis Video Streams multi-track support so that what the customer says is on a separate track from what the customer hears. Audio sent to Kinesis uses a sampling rate of 8 kHz." — plan live media streams

Die Tracks heißen AUDIO_FROM_CUSTOMER und AUDIO_TO_CUSTOMER, und der Consumer-Guide sagt, ein Reader "stores this data as a raw PCM file".

Das ist das gesamte dokumentierte Format. Wir haben die vier Live-Media-Streaming-Seiten nach L16, endian, bit und codec gegrept und nichts bekommen. Das häufig weitergereichte „audio/L16, 16-bit, little-endian, mono" steht nicht in der Amazon-Connect-Dokumentation. Das einzige Bit-Tiefen-Signal irgendwo in AWS' eigenem Material ist eine Audacity-Importanweisung in einem Demo-Repository — set encoding to signed 16-bit PCM and sample rate to 8000 Hz —, die Ihnen sagt, was die Bytes am Ende waren, nicht, was der Vertrag ist. Sechzehn Bit mono ist stark impliziert. Es ist nicht dokumentiert, und wir werden es nicht aufschreiben, als wäre es das.

Beachten Sie auch, dass Connect bei der Encodierung aus der Reihe fällt. Twilio und NICE reichen Ihnen beide kompandiertes G.711 µ-law; Connect reicht Ihnen lineares PCM bei denselben 8 kHz. Gleiche Bandbegrenzung, anderes Quantisierungsrauschen — und wer ein Modell gegen das eine benchmarkt, benchmarkt es nicht gegen das andere.

Es ist einbahnig, und AWS sagt das indirekt, aber unmissverständlich. Jedes dokumentierte Verb ist Erfassen oder Konsumieren, es gibt keinen Schreibpfad, und auf der Planungsseite steht dies:

"We recommend that you refrain from modifying the streams. Doing so can cause unexpected behavior."

Es ist ein Live-Stream, aus dem Sie Fragmente lesen, mit kurzer Default-Aufbewahrung. "If you select No data retention, data is not retained and is available to be consumed for only 5 minutes." Connect übergibt Ihrem Konsumenten einen Fragment-Cursor über Kontaktattribute — StartFragmentNumber, StreamARN, StartTimestamp, StopTimestamp —, Ihr Reader springt also in den Stream, statt einen Socket zu abonnieren. Das ist ein architektonischer Unterschied, den man einplanen sollte: Es ist ein Pull, kein Push, und Ihr Latenzbudget schließt ein, was die Polling-Schleife Ihres Konsumenten kostet.

Was ist mit den anderen Connect-Oberflächen? Wir haben sie geprüft, weil die Benennung zur Verwechslung einlädt:

• Contact Lens Real-time ist Transkripte, nicht Audio. Es liefert Utterance-Segmente über Kinesis Data Streams — "partial transcripts... to meet ultra-low latency requirements to assist agents on live calls". Text, stromabwärts eines Recognizers, den Sie nicht kontrollieren.
• External Voice Systems nimmt über SIPREC in Contact Lens auf — die Konfigurationsseite benennt den Host, der "will receive the SIPREC audio". Das ist Audio, das von einer Drittanbieter-Telefonieplattform in Connect hineinfließt, nicht zur Verarbeitung heraus. Die Codec-Spezifikation ist an Amazon-Chime-SDK-Guides delegiert, die wir nicht gelesen haben; das Format dort ist also unbestätigt.
• StartWebRTCContact gibt Chime-SDK-Meeting- und Teilnehmer-Credentials zurück — AudioHostUrl, SignalingUrl, JoinToken. So tritt ein Client-SDK dem Anruf als Teilnehmer bei. Es ist keine serverseitige Roh-Audio-Leitung.
• Third-party Speech Providers ist die eine Stelle, an der Connect das Modell eines anderen im Pfad dokumentiert: "Connect routes audio to the chosen third-party speech-to-text provider", konfiguriert pro Bot-Locale mit dem API-Key des Anbieters im Secrets Manager. Begleitseiten existieren für Drittanbieter-TTS. Das ist Anbieterauswahl aus einer unterstützten Liste, kein Einfügepunkt für Ihre eigene Verarbeitung.

Ein Hinweis für alle, die gerade über Connect schreiben: Das Inhaltsverzeichnis der Dokumentation trägt inzwischen eine End-of-Support-Seite für Amazon Connect Voice ID. Prüfen Sie den Status, bevor Sie darauf bauen.

Urteil: Nein. Kinesis Video Streams ist eine Verzweigung zur Seite. Sie können alles hören und nichts ändern.

Twilio: der stärkste Allzweck-Einfügepunkt der fünf

Twilio veröffentlicht den strengsten Formatvertrag von allen hier, und wir haben diese Angaben verifiziert, indem wir die Strings gelesen haben, statt einer Zusammenfassung zu trauen. Aus der Referenz der WebSocket-Nachrichten:

"start.mediaFormat.encoding — The encoding of the data in the upcoming payload. Value is always audio/x-mulaw. start.mediaFormat.sampleRate — Value is always 8000. start.mediaFormat.channels — Value is always 1."

Dreimal „always". Das Audio kommt als base64 in JSON an, mit einem chunk-Zähler ab 1 und einem timestamp in Millisekunden ab Stream-Start. Der Mechanismus ist eine Verzweigung: "Twilio forks the raw audio stream of the Call and streams it to your WebSocket server in near real-time", ausschließlich über wss.

Die Track-Auswahl — inbound_track, outbound_track, both_tracks, Default inbound_track — gehört zur unidirektionalen Form. Inbound ist, was Twilio von der Gegenseite empfängt; Outbound ist, was Twilio in Richtung des Anrufs erzeugt.

Die zwei Formen sind verschiedene Produkte mit einem Substantiv. Das ist die Unterscheidung, die Ihre Architektur entscheidet:

	<Start><Stream>	<Connect><Stream>
Richtung	Nur Fork nach außen	Bidirektional
TwiML-Flow	"immediately continues with the next TwiML instruction"	Blockiert: nachfolgendes TwiML läuft erst "after your server closes the WebSocket connection"
Per REST erstellbar	Ja	Nein
Track-Auswahl	Ja	In der Noun-Referenz auf die unidirektionale Form begrenzt

Bei der bidirektionalen Form wird das zurückgesendete Audio im Anruf abgespielt:

"Bidirectional Media Streams are those in which your WebSocket application both receives audio from Twilio and can send audio to Twilio, which is then played on the Call." — Media Streams

Mit einer strikten Payload-Regel und einer Falle darin: "The payload must be encoded audio/x-mulaw with a sample rate of 8000 and must be base64 encoded", und "the media.payload should not contain audio file type header bytes. Providing header bytes causes the media to be streamed incorrectly." Wer µ-law mit einer Bibliothek erzeugt, die einen WAV-Header schreibt, wird es hören.

Sie bekommen außerdem mark für das Nachverfolgen abgeschlossenen Playbacks und clear zum Flushen gepufferten Audios — das ist das Barge-in-Primitiv und der Grund, warum diese Oberfläche ein echtes Unterbrechungsmodell tragen kann, statt den Anrufer nur zu übertönen.

Urteil: Ja. <Connect><Stream> ist ein echter Man-in-the-Middle: Anrufer-Audio rein, Ihr Audio raus, abgespielt in den Anruf, mit Playback- und Unterbrechungskontrolle. Der Preis ist, dass <Connect> terminal ist — es besitzt den Anruf für die Dauer —, Sie dekorieren also keinen Flow, Sie werden er.

Eines veröffentlicht Twilio nicht: die Frame-Größe. Wir haben gezielt gesucht, weil alle 160 Bytes und 20 ms zitieren. Twilio dokumentiert den chunk-Zähler und den timestamp und nennt auf keiner der beiden Media-Streams-Seiten eine Zahl für Bytes pro Nachricht oder Millisekunden pro Frame. Wenn Sie diese Zahl brauchen, messen Sie sie auf Ihrem eigenen Traffic und kennzeichnen Sie sie als beobachtet.

Ebenso wenig veröffentlicht Twilio eine Abtastrate für Echtzeit-Transkription. Das <Transcription>-Noun dokumentiert Track-Auswahl und Labels und nennt Google oder Deepgram als Engines; eine Rate fanden wir weder in der Noun-Referenz noch in der REST-Ressource.

Die Twilio-Behauptung, die wir aufgestellt haben, korrekt formuliert

Wir haben auf dieser Website geschrieben, dass Twilios <ConversationRelay> strukturell keinen <Stream>-Medien-Fork neben sich laufen lassen kann. Wir haben den Satz gesucht, der das sagt, und es gibt ihn nicht. Die Korrektur ist uns wichtiger als die Schlussfolgerung, also steht hier exakt, was die Dokumentation enthält und was nicht.

Was ConversationRelay ist, bestätigt. Es "routes a call to the Conversation Relay service, providing advanced AI-powered voice interactions". Twilio führt Speech-to-Text und Text-to-Speech selbst aus, und Ihr WebSocket tauscht ausschließlich JSON: eingehend setup, prompt (mit voicePrompt, bereits transkribiertem Text), dtmf, interrupt, error; ausgehend Text-Tokens, Play-Media per URL, Send-Digits, Switch-Language, End-Session. Kein rohes Audio überquert diesen Socket in irgendeiner Richtung, und nirgendwo, wo wir suchen konnten, ist ein Codec oder eine Abtastrate dafür veröffentlicht.

Was die Dokumentation nicht sagt, und wir haben sorgfältig geprüft:

• Es gibt keine Kardinalitätsregel für <Connect>. Die Noun-Referenz dokumentiert vier Nouns und zwei Attribute und sagt nirgends, dass <Connect> genau eines enthalten darf.
• Es gibt keine Aussage, dass <Stream> mit <ConversationRelay> inkompatibel ist. Wir haben die ConversationRelay-Übersicht, die Noun-Referenz, die Onboarding-Seite und die <Connect>-Referenz nach "cannot", "not supported", "limitation", "incompatible", "only one", "simultaneously" und "alongside" gegrept. Jeder Treffer war Navigations-Chrome. Kein Fließtext. Auf keiner ConversationRelay-Seite gibt es einen Limitations-Abschnitt.
• Ob ein vor einem <Connect><ConversationRelay> gestarteter <Start><Stream>-Fork überlebt, ist weder als funktionierend noch als scheiternd dokumentiert. Twilio adressiert die Kombination schlicht nie.

Die zutreffende Aussage ist also eine Schlussfolgerung, und wir hätten sie als solche kennzeichnen müssen. ConversationRelays Protokoll transportiert kein Audio, und <Connect> ist als terminal dokumentiert, was zusammen bedeutet, dass Twilio die Medien selbst terminieren und neu aufsetzen muss — womit keine dokumentierte Stelle für einen Drittverarbeiter zwischen dem Anrufer und dem Recognizer bleibt. Diese Argumentation ist stichhaltig, und sie ist kein Zitat. Den empirischen Test eines vorangestellten <Start><Stream> haben wir nicht durchgeführt, und bis wir das tun, lautet die ehrliche Form der Behauptung: Twilio dokumentiert die Kombination nicht; die Architektur impliziert, dass es keine Stelle gibt, an der sich ein Prozessor einfügen lässt; verifiziert haben wir es nicht.

Wenn Sie dieses Experiment in irgendeiner Richtung durchgeführt haben, hätten wir das Ergebnis aufrichtig gern, und wir veröffentlichen es mit Namensnennung.

NICE CXone: Die Dokumentation ist nicht dort, wo man suchen würde

Das öffentliche Entwicklerportal listet achtzehn API-Familien, und keine davon ist Live-Audio. „Real-Time Data" sind Metriken. „Media Playback" sind Aufzeichnungen. Wer dort sucht, folgert, dass CXone keine Echtzeit-Audio-Oberfläche hat, und diese Folgerung ist falsch — die Spezifikation lebt im Administrator-Help-Centre, unter Agent-Assist-Integrationen.

Vor den Details ein negativer Befund, den man haben sollte: Wir fanden kein Produkt namens CXone Real-Time Audio, RTMS, CXone Voice Streaming API oder CXone Open Agent Assist. Diese Namen tauchen in Texten Dritter auf. In einem Durchlauf über sechstausend URLs von NICEs eigener Dokumentation tauchten sie nicht auf. Bauen Sie keine Suche darauf.

Custom Agent Assist Integrations ist die Echtzeit-Audio-Oberfläche, und ihr Formatsatz ist unmissverständlich:

"Audio packets are encoded as G711 μlaw 8-bit 8000 kHz raw audio. This is the same format as all NiCE CXone telephony audio." — agent assist resources

Die Einheit ist NICEs eigener Tippfehler; gemeint sind offenkundig 8000 Hz. Die zweite Hälfte des Satzes ist die nützlichere: Das ist dasselbe Format wie alles CXone-Telefonie-Audio. Die Plattform sagt Ihnen, dass ihre interne Medienrepräsentation schmalbandiges G.711 ist, überall.

Das Kanalmodell ist pro Verbindung statt pro Track, was ungewöhnlich ist und leicht falsch gemacht wird:

"streamPerspective: RX — The audio being transmitted by the agent's phone: the agent talking. TX — The audio that the agent hears: the contact talking... MIX — Contains both agent and contact audio streams. An individual websocket connection only contains audio from one perspective."

Eine Stereo-Sicht auf einen Anruf sind also zwei Sockets, von Ihnen korreliert, ohne gemeinsame Uhr im Payload — denn im Payload ist nichts außer Audio:

"Only binary data flows through the webhook. For voice interactions, the only data sent from the call are audio bytes. No call control or other metadata is included."

Operativ: mindestens 2,000 gleichzeitige Requests unterstützt, kein Verbindungsablauf und keine Maximaldauer, und ein Hold schließt den Socket, während ein Resume einen frischen mit identischem Handshake öffnet. Beachten Sie auch, dass NICE einen ungesicherten Endpoint zulässt — "The audio relay endpoint must be a websocket. It can be secured (WSS) or unsecured (WS)" —, eine Wahl, die Sie bewusst treffen sollten statt durch Kopieren eines Beispiels.

Richtung: nur raus. Was Sie zurückgeben, sind Text und Ressourcen, die auf dem Bildschirm des Agenten gerendert werden. Audio betritt den Anruf nie wieder. Der Agent Assist Hub, der diese Integrationen vermittelt, streamt dem Dritten folglich rohes G.711-µ-law-Audio und erwartet, dass der Dritte sein eigenes Speech-to-Text betreibt.

Custom Virtual Agent ist das Nächste, was CXone an Audio-Rückgabe bietet, und es ist turn-basiert statt streamend. Äußerungen kommen an "either as audio in the format of the G-711 codec or as transcribed text", und das Antwortschema trägt ein Feld namens — mit NICEs eigenem Schreibfehler intakt — base64EndcodedG711ulawWithWavHeader, beschrieben als die encodierte WAV, "to be played at the next turn". Transport ist REST über HTTPS. Das ist eine Bot-Antwort, kein Inline-Filter.

Urteil: Nein für Agent Assist, und nur turn-basiertes Playback für Virtual Agent. Sie können alles hören, mit 8 kHz µ-law, auf getrennten Sockets pro Perspektive, und Sie können nicht ändern, was irgendjemand sonst hört.

Avaya: die Überraschung, und der einzige Breitband-Codec im Feld

Wir hatten erwartet zu schreiben, dass Avayas Echtzeit-Audio-Oberfläche nicht öffentlich dokumentiert ist. Sie ist es — im Detail, ohne Login, und sie ist das am ausdrücklichsten bidirektionale Design der fünf.

Avaya Infinity veröffentlicht Real-time Contextual Media Streaming, zuletzt aktualisiert am 23. Juli 2026:

"Real-time Contextual Media Streaming is an open WebSocket-based protocol that lets you connect your own AI services directly to Avaya Infinity... No proprietary SDKs. No middleware. Just a WebSocket connection carrying bidirectional audio and structured JSON messages."

Der Medienvertrag, wörtlich:

"Codecs: PCMU (8 kHz), PCMA (8 kHz), G.722 (16 kHz) / Frame size: 20ms default, configurable per session / Channels: Customer audio, agent audio, or both — negotiated at session setup"

Das ist der einzige Breitband-Codec in dieser gesamten Erhebung. Jede andere Plattform hier, und Genesys, dokumentiert Schmalband und nur Schmalband. Dass Avaya G.722 mit 16 kHz dokumentiert, heißt nicht, dass Ihre Anrufe breitbandig sein werden — die Carrier-Strecke entscheidet weiterhin —, aber es heißt, dass die Plattform nicht das ist, was die Bandbegrenzung erzwingt, und das ist eine andere Lage als bei den anderen vier.

Das Richtungsmodell ist explizit und pro Service:

"Egress (out) (Avaya Infinity → Your Server) — live audio from the endpoint, streamed to your server for processing... Ingress (in) (Your Server → Avaya Infinity) — audio generated by your server, played back to the endpoint." / "A Virtual Agent bot typically uses both flows... A recording service uses egress only. A TTS service uses ingress only. Your server controls which flows are active per endpoint."

Zwei Transportmodi sind dokumentiert — avaya-wss, Binärframes über einen TLS-WebSocket, und avaya-wss-rtp, SRTP über UDP "for ultra-low latency environments" —, beide mit JSON für die Steuerung und beide mit dynamischer Codec-Verhandlung. Avaya ist der WebSocket-Client und Sie der Server, also "no inbound firewall rules required on your side"; die Authentifizierung ist ein signiertes JWT, das Ihr Server validiert; TLS 1.2 oder besser mit Zertifikaten öffentlicher CAs. Ein Socket multiplext mehrere Endpoints, die Frames sind mit Endpoint-ID getaggt.

Der Vorbehalt, der das ehrlich hält: Nur Virtual Agent ist live. Dieselbe Seite trägt eine „Coming Soon"-Tabelle, die Agent Assist, Recording, Text-to-Speech, Speech Recognition, Transcription und Translation als künftige Services auf demselben Protokoll listet. Heute existiert der bidirektionale Pfad also, und der Weg, ihn zu nutzen, ist, der Virtual Agent zu sein. Lesen Sie diesen Abschnitt nicht als „Avaya lässt Sie heute Drittanbieter-ASR oder -Recording einfügen", denn das sagt der Hersteller nicht.

Zwei weitere Abgrenzungen. Avaya Experience Platform hat kein Äquivalent — ihre Medienbehandlung ist signierter Upload und Download von Dateien, kein Live-Audio; Echtzeit-Streaming liegt auf Avaya Infinity, der neueren Plattform. Und Avaya Aura, AES oder Aura Media Server haben wir gar nicht untersucht. Das ist eine offene Frage in diesem Beitrag, kein negativer Befund, und wir sagen das lieber, als Schweigen wie Abwesenheit klingen zu lassen.

Was das in Summe ergibt

Zwei unabhängige Schlussfolgerungen, und sie zeigen in verschiedene Richtungen.

Bei der Abtastrate hält der Keil, und er ist etwas schmaler, als wir behauptet haben. Vier der fünf Oberflächen dokumentieren 8 kHz und nichts sonst, und NICE sagt rundheraus, schmalbandiges G.711 sei "the same format as all NiCE CXone telephony audio". Das ist der Kanal, auf dem das Geld ankommt, und im Wesentlichen jedes Modell zur Sprachverbesserung (speech enhancement) am Markt ist breitbandig trainiert — die DNS Challenge, die Benchmark-Reihe, gegen die die meisten veröffentlichten Denoiser getunt sind, hatte nie einen Schmalband-Track. Aber wir sollten aufhören zu schreiben „es ist überall 8 kHz µ-law": Amazon Connect ist lineares PCM, nicht kompandiert, und Avaya dokumentiert G.722 mit 16 kHz. Zwei Ausnahmen von sechs Oberflächen sind kein Rundungsfehler.

Bei der Integrationsoberfläche teilt sich das Feld sauber, und es ist nicht die Teilung, die das Marketing nahelegt. Jede dieser Plattformen lässt Sie zuhören. Zwei davon — Twilios <Connect><Stream> und Avaya Infinitys RCMS — dokumentieren einen Weg, Audio zurück in den Live-Medienpfad zu legen. Genesys, Amazon Connect und NICE CXone tun das nicht, und auf den Oberflächen, die Audio zurücknehmen, bittet man Sie, der Bot zu sein, nicht das Filter: Das Audio, das Sie senden, geht an den Menschen, nicht an den Recognizer eines anderen.

Diese Unterscheidung ist die, die man in eine Build-Entscheidung mitnehmen sollte. „Kann ich das Audio des Anrufers verarbeiten, bevor der Speech Recognizer der Plattform es hört?" ist eine andere Frage als „Kann ich Audio in diesen Anruf senden?", und nur eine von beiden hat irgendwo in dieser Erhebung ein Ja — auf den Plattformen, auf denen Ihnen auch der Recognizer gehört.

Womit die Messungen zur Beschränkung werden statt der Plattform. Auf unseren sieben Telefonie-Bedingungen produzierte kein getesteter Enhancer eine nennenswerte Verbesserung gegenüber dem unverarbeiteten Audio, und mehrere verschlechterten es um fünf bis zehn Punkte Wortfehlerrate (WER). Die Einfügepunkte sind der einfache Teil. Etwas zu haben, das sich einzufügen lohnt, ist der Teil, den niemand gelöst hat, dessen Zahlen wir prüfen können — und genau in diese Lücke hinein bauen wir.

Was wir nicht bestätigen konnten

• Amazon Connect: Bit-Tiefe, Endianness und Kanalzahl. 8 kHz und „raw PCM" ist das gesamte veröffentlichte Format. Sechzehn Bit mono ist durch AWS' eigenes Demo-Material impliziert und ist nicht dokumentiert.
• Amazon Connect: irgendeine Latenzangabe. Auf keiner gelesenen Seite veröffentlicht.
• Amazon Connect: das SIPREC-Ingest-Codec-Profil. Von AWS an Amazon-Chime-SDK-Konfigurationsguides delegiert, die wir nicht gelesen haben.
• Twilio: Bytes oder Millisekunden pro Media-Nachricht. Nicht veröffentlicht. Die weithin zitierten 160 Bytes / 20 ms stehen nicht in Twilios Dokumentation.
• Twilio: Audioformat und Abtastrate von ConversationRelay. Nirgends veröffentlicht, wo wir suchen konnten, einschließlich der Voice-Konfigurationsseite, die TTS-Anbieter und Prosodie-Einstellungen behandelt und keine Codecs.
• Twilio: ob ein <Start><Stream>-Fork ein nachfolgendes <Connect><ConversationRelay> überlebt. In beide Richtungen undokumentiert, und von uns ungetestet.
• Twilio: Abtastrate der Echtzeit-Transkription. Nicht veröffentlicht.
• NICE CXone: die Audio-Abtastrate des Custom Virtual Agent. Der Codec ist als G.711 µ-law genannt; die Rate steht nicht auf der Schema-Seite.
• NICE CXone: Formate pro Anbieter hinter dem Agent Assist Hub. Die Integrationsseite wiederholt sie nicht; die einzige Formatspezifikation steht auf den Custom-Integration-Seiten.
• Avaya: die Protokollspezifikation auf Wire-Ebene. Avaya veröffentlicht eine Protokollspezifikation als PDF, Version 1.1, die wir nicht abgerufen haben — Session-Lebenszyklus und Nachrichtendefinitionen sind hier also unverifiziert.
• Avaya Aura, AES und Avaya Aura Media Server. Nicht untersucht. Offene Frage, kein negativer Befund.

Eine Anmerkung zur Methode, weil sie verändert, wie viel Gewicht diese Befunde tragen: Diese Erhebung entstand durch das Ablaufen herstellereigener Dokumentationsindizes und direktes Lesen der Seiten, nicht durch Suchen. Das ist verlässlicher, um zu bestätigen, was ein Dokument sagt, und weniger verlässlich, um zu beweisen, dass ein Dokument nicht existiert. Jedes „nicht dokumentiert" oben bedeutet „wir haben es beim Crawlen des herstellereigenen Index nicht gefunden" — eine schwächere Aussage als „der Hersteller dokumentiert es nicht", und noch einmal schwächer als die bestätigten Zitate, die wörtlich sind.