Sprachtechnologie1. Okt 2026 · 5 Min. Lesezeit

AvaritCall · Redaktion

SIP, SDP und RTP: Von der Codec-Aushandlung zum hörbaren Gespräch

Ein verbundener Anruf kann trotzdem stumm bleiben. Prüfen Sie SIP, SDP und RTP getrennt: akzeptierte Formate, Payload-Zuordnungen und den Medienpfad in beiden Gesprächsrichtungen.

SIP, SDP und RTP: Von der Codec-Aushandlung zum hörbaren Gespräch

Ein angenommener Telefonanruf beweist noch nicht, dass Audio in beiden Richtungen funktioniert. Prüfen Sie Gesprächsaufbau, vereinbarte Medienbeschreibung und tatsächlich übertragene Sprachpakete getrennt. SIP, SDP und RTP beantworten unterschiedliche Fragen. Bei einer Sprach-KI-Integration kann eine bloße Änderung des Codec-Namens den Fehlerort unklar lassen. Der folgende Ablauf verbindet beobachtbare Belege mit gezielten Änderungen bei einem verbundenen, aber stummen Anruf.

1. Für drei Ebenen getrennte Belege sammeln

SIP signalisiert Aufbau, Änderung und Beendigung einer Sitzung. [1] SDP beschreibt Medien; RTP transportiert Audiodaten. [3][5] Trennen Sie diese Aufgaben bei der Untersuchung. Setzen Sie den Status „angenommen“ im Gesprächsprotokoll nicht mit hörbarer Empfängerausgabe gleich. Fordern Sie für jede Stufe beobachtbare Belege an. Ein erfolgreicher Steuerungsaustausch ist nur ein Teil der Untersuchung.

Die Ebenen bei der Gesprächsuntersuchung trennen
EbeneZentrale FrageZu prüfende Belege
SIPWelche Stufe hat der Anruf erreicht?Zeitlicher Verlauf von Anfragen und Antworten
SDPWelche Medienbedingungen wurden beschrieben?Vergleich von Angebot, Antwort und späteren Aktualisierungen
RTPErreichen Audiodaten den vorgesehenen Empfänger?Paketbeobachtungen und dekodiertes Audio in beiden Richtungen

Diese Unterscheidung erleichtert auch die Zusammenarbeit zwischen Teams. Ersetzen Sie „Der Codec funktioniert nicht“ durch eine Beobachtung wie „RTP ist auf dem externen Gesprächsabschnitt sichtbar, auf dem internen jedoch nicht“. Nennen Sie den Aufzeichnungspunkt, der den Befund belegt. Eine anderswo erstellte Aufzeichnung kann dieselbe Frage anders beantworten. Beschreiben Sie den Befund, bevor Sie eine Konfigurationsänderung vorschlagen.

2. SDP-Angebot und Antwort gemeinsam lesen

SDP-Offer/Answer legt nutzbare Formate fest; ohne gemeinsames Format wird der Medienstrom mit Port null abgelehnt. [2] Kopieren Sie nicht lediglich die Codec-Liste des ersten Angebots. Berücksichtigen Sie Antwort, Richtung und spätere Änderungen. Der erste Name einer Liste beweist nicht, dass ausschließlich dieses Format gerade verwendet wird. Dokumentieren Sie deshalb auch den Zeitpunkt der Beobachtung.

Eine Antwort kann mehrere akzeptierte Formate enthalten; prüfen Sie die tatsächliche Übertragung anhand von RTP. [2] Teilt eine Telefonanlage oder ein Grenzcontroller das Gespräch in zwei Abschnitte, dokumentieren Sie beide getrennt. Behandeln Sie die Liste der Anruferseite und die Liste der KI-Seite nicht wie eine einzige Aushandlung. Beschreiben Sie im Fehlerbericht Konfiguration, beobachtete Vereinbarung und gewünschtes Verhalten in getrennten Aussagen.

3. Eine Payload-Nummer ist kein Codec-Name

a=rtpmap ordnet einer Payload-Nummer Kodierungsname, Taktrate und Kanäle zu; a=fmtp enthält formatspezifische Parameter. [3] Wählen Sie den Decoder nicht allein anhand einer Zahl. Behält ein Werkzeug die Zuordnung eines älteren Anrufs, kann es Pakete der neuen Sitzung falsch interpretieren. Verknüpfen Sie jede Paketaufzeichnung mit der aktuellen SDP-Beschreibung dieses Anrufs, insbesondere beim Vergleich wiederholter Tests.

In der RTP/AVP-Standardzuordnung steht 0 für PCMU und 8 für PCMA; dynamische Zuordnungen gelten pro Sitzung. [4] In einer hypothetischen Zeile a=rtpmap:111 opus/48000/2 ist 111 keine universelle Opus-Kennung für alle Anrufe. Bewerten Sie fmtp anhand der jeweiligen Codec-Definition, statt lediglich zwei Textfolgen zu vergleichen. So unterscheiden Sie Gesprächsabschnitte mit unterschiedlichen Bedingungen unter einem scheinbar identischen Codec-Namen.

4. Ein gemeinsamer Codec garantiert keinen Medienpfad

NAT oder eine falsche eingebettete Medienadresse kann Audio trotz erfolgreicher Signalisierung blockieren. [5] c= beschreibt die Verbindungsadresse, m=audio Port und Formatliste. [3] Bestimmen Sie die betroffene Richtung, den letzten Punkt mit sichtbaren Paketen und den ersten ohne. Der Abschnitt zwischen diesen Beobachtungen setzt der nächsten Untersuchung eine konkrete Grenze. Notieren Sie, ob die Stille seit Beginn oder erst nach einer Gesprächsänderung auftritt.

G722 verwendet einen RTP-Takt von 8 kHz bei 16 kHz Abtastrate. [4] Opus verwendet in allen Modi einen RTP-Takt von 48 kHz. [6] Verwechseln Sie den SDP-Takt nicht mit der Abtastrate des Anwendungseingangs. Hier geht es um korrekte Zeit- und Formatinterpretation in der Dekodierungskette, nicht um einen Vergleich der Klangqualität.

5. Ein hypothetischer angenommener, aber stummer Anruf

In einem Kundendiensttest wird der Anruf angenommen und beide Gesprächsabschnitte zeigen kompatible Formate; der Anrufer hört dennoch nichts. Das Team sammelt Angebot und Antwort anhand der Gesprächskennung. Anschließend untersucht es denselben Zeitraum an externer Schnittstelle, Medienvermittler und Anwendungseingang. Pakete an der externen Schnittstelle ersetzen keinen Beleg für Pakete am Anwendungseingang. Der Vergleich muss dieselbe Richtung betreffen.

Erreichen die Pakete die Anwendung nicht, werden Route und Medienziel vor den Decoder-Einstellungen untersucht. Treffen Pakete ein, ohne dekodiertes Audio zu ergeben, prüft das Team Zuordnung und Formatinterpretation. Existiert dekodiertes Audio, untersucht es Eingangsauswahl und Wiedergabe in der Anwendung. Jeder Befund bestimmt die nächste Frage. Das Team verknüpft jeden Befund mit demselben Anruf und vermischt keine Aufzeichnungen unterschiedlicher Versuche.

6. Eine Checkliste für den nächsten Versuch verwenden

  • Gesprächskennung, betroffene Richtung und Beginn der Stille dokumentieren.
  • Aktuelles Angebot und Antwort einschließlich möglicher SDP-Aktualisierungen im Gespräch sichern.
  • Medienziel und Payload-Zuordnung jedes Gesprächsabschnitts im eigenen Zusammenhang prüfen.
  • Paketempfang und hörbare Ausgabe als getrennte Schritte verifizieren.
  • Eine Änderung vornehmen; erwartetes Ergebnis und Rücksetzschritt vorher festhalten.
  • Verbindungsaufbau, Rückkehr aus der Warteschleife und Verhalten nach Weiterleitung getrennt testen.

Häufig gestellte Fragen

Ist die Verbindung vollständig geprüft, wenn beide Endpunkte denselben Codec-Namen anzeigen? Nein. Prüfen Sie aktuelle Formatbedingungen, übertragene Payload und Medienpfad in beiden Richtungen. Übereinstimmende Namen ersetzen diese Kontrollen nicht.

Sollte bei Stille zuerst die Codec-Reihenfolge geändert werden? Meist ist Beweissammlung zuerst hilfreicher. Wenn feststeht, wo Pakete verschwinden oder Audio nicht dekodiert wird, lässt sich eine kleinere Änderung vornehmen und deren Ergebnis leichter beurteilen.

Quellen
  1. [1]RFC 3261: SIP: Session Initiation Protocol — RFC Editor / IETF, 2002-06 (abgerufen: 2026-10-01)
  2. [2]RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP) — RFC Editor / IETF, 2002-06 (abgerufen: 2026-10-01)
  3. [3]RFC 8866: SDP: Session Description Protocol — IETF, 2021-01 (abgerufen: 2026-10-01)
  4. [4]RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control — RFC Editor / IETF, 2003-07 (abgerufen: 2026-10-01)
  5. [5]NAT in VoIP — Cisco, 2021-07-16 (abgerufen: 2026-10-01)
  6. [6]RFC 7587: RTP Payload Format for the Opus Speech and Audio Codec — RFC Editor / IETF, 2015-06 (abgerufen: 2026-10-01)
Passende Lösungen

Erleben Sie es bei Ihren eigenen Anrufen.

In 5 Minuten eingerichtet. 5 $ Startguthaben bei der Registrierung, nutzungsbasierte Abrechnung — ohne Vertragsbindung.

Weiterlesen