Zusammenfassung

  • RFC 5577 ersetzte die frühere RTP-Payload-Spezifikation, um 14-kHz-Audio nach Annex C von G.722.1, einen 32-kHz-Abtasttakt und 48 kbit/s zu unterstützen.
  • Einen harten Schnitt schrieb die Nachfolgespezifikation nicht vor: Für die Interoperabilität empfahl sie weiterhin die 16-kHz-Konfiguration und verlangte, jede vorgesehene Kombination aus Takt und Bitrate in SDP anzugeben.

Die Nachfolgespezifikation beseitigte nicht die Endgeräte der Vorgängerversion

Als RFC 5577 im Juli 2009 erschien, trug es den Vermerk „Obsoletes: 3047“. Das klingt nach einem Schalter: Eine Spezifikation geht, die nächste gilt. Doch der Abschnitt zur Interoperabilität beschreibt einen vorsichtigeren Übergang. RFC 3047 hatte G.722.1 mit einem Abtasttakt von 16 kHz beschrieben. Die Revision nahm das Super-Wideband-Audio aus Annex C der überarbeiteten ITU-T-Empfehlung auf: Die Audiobandbreite reichte nun bis 14 kHz, eine 32-kHz-Taktkonfiguration kam hinzu, ebenso eine Rate von 48 kbit/s.

Diese Zahlen bezeichnen unterschiedliche Größen. 14 kHz steht für die Bandbreite des codierten Audios; 16 oder 32 kHz bezeichnet den Abtasttakt der RTP-Zeitstempel; 24, 32 oder 48 kbit/s ist die Codec-Bitrate. RFC 5577 machte daraus keinen einzigen „Qualitätsregler“. Erst die Sitzungssignalisierung beschreibt eine nutzbare Kombination.

Im Codec-Bitstrom gab es keine In-Band-Meldung für einen Bitratenwechsel. Deshalb verlangte RFC 5577 eine separate Signalisierung und eine konstante Bitrate je RTP-Payload-Typ. Eine Anwendung durfte zwischen Paketen umschalten, musste dafür aber unterschiedliche Payload-Typen verwenden. In SDP nennt a=rtpmap das Encoding und den Takt; a=fmtp enthält die Bitrate. Zusammen legen sie fest, welche Konfiguration dem Empfänger angeboten wird.

Im Offer/Answer-Modell ist diese Deklaration maßgeblich. RFC 5577 verlangt, dass ein Angebot jede Konfiguration aufführt, die der Sender verwenden will. Zugleich benennt es die Kompatibilitätslücke: RFC 3047 unterstützte nur 16 kHz. Wer mit älteren Endgeräten interoperieren wollte, sollte daher auch einen Payload-Typ mit 16-kHz-Takt anbieten. Das Beispiel stellt die Variante 16 kHz/24 kbit/s und die Variante 32 kHz/48 kbit/s unter getrennten Payload-Typen dar.

Das belegt weder, dass jedes ältere Endgerät erfolgreich aushandeln konnte, noch dass die neue Variante automatisch zurückfiel. Ein Angebot listet unterstützte Wahlmöglichkeiten; es beweist nicht die Antwort des Gegenübers oder dass Audio die Hörenden erreichte. Das empfangende Gerät muss eine unterstützte Konfiguration auswählen, anschließend muss die Sitzung das vereinbarte Profil verwenden. RFC 5577 bewahrte einen Weg, bestätigte aber nicht, wer ihn tatsächlich nutzte.

Eine weitere Grenze blieb im Paketformat bestehen. Die Frames dauerten weiterhin 20 Millisekunden. Bei den standardisierten Bitraten belegte jeder Frame 60, 80 oder 120 Oktette. Ein Paket durfte aufeinanderfolgende Frames bündeln, sofern Bitrate und Takt übereinstimmten; ein Frame durfte nicht auf mehrere Pakete verteilt werden. Eine zusätzliche Payload-Angabe zur Frame-Zahl gab es nicht: Der Empfänger leitete sie aus der Oktettzahl und der erwarteten Größe je Frame ab. Für Telefonie mit strengen Verzögerungsanforderungen empfahl die RFC weniger Frames pro Paket; Streaming und Messaging konnten mehr bündeln.

Eine universelle Latenzzahl legte sie nicht fest.

Als Migrationsdokument erzählt RFC 5577 also nicht, wie „ein neuer Codec den alten verdrängte“, sondern wie die Auswahl sichtbar blieb. Die Zeile „Obsoletes“ ersetzte den Normtext. Das 16-kHz-Angebot hielt die frühere Kompatibilitätsgrenze offen. Keine der beiden Aussagen verrät, wie viele Endgeräte die jeweilige Konfiguration implementierten.

Quellen