IRStone - stock.adobe.com
SIP und RTP: Grundlagen für die VoIP-Fehlerbehebung
Vertiefen Sie Ihre Kenntnisse über SIP und RTP, um Fehler in der Signalisierung sowie im Medientransport zu beheben und eine hohe Sprachqualität in UC-Umgebungen sicherzustellen.
Mehr als zwei Jahrzehnte nach der Veröffentlichung des ersten Request for Comments (RFC) bilden das Session Initiation Protocol (SIP) und das Real-Time Transport Protocol (RTP) nach wie vor das technologische Fundament der IP-basierten Telekommunikation und der zugehörigen Unified-Communications-Dienste.
Ob in internen Unternehmensnetzen zur Anbindung von Hardware- und Softwaretelefonen an eine IP-PBX, bei der Kopplung mehrerer IP-PBX untereinander oder bei der Verbindung mit öffentlichen Telefonnetzen über SIP-Trunks – die Kombination dieser Protokolle ist allgegenwärtig. SIP-Trunks gelten dabei als aktueller technischer Standard für die Anbindung an das öffentliche Telefonnetz.
Allen Unkenrufen zum Trotz bildet die Telekommunikation noch immer einen wichtigen Teil der Unternehmenskommunikation. Das zeigt sich auch in Telefonieintegrationen wie in die Unified-Communications-Lösungen Microsoft Teams mit Direct Routing und Cisco Webex Calling mit Local Gateways. Gleichzeitig stellen sie spezifische Anforderungen an die Echtzeitfähigkeit der zugrunde liegenden Netzwerke, zudem gibt es eine hohe Verfügbarkeitserwartung der Nutzer.
Die Stärken von SIP und RTP in puncto Flexibilität, Skalierbarkeit und Echtzeitfähigkeit bringen jedoch auch eine erhebliche Komplexität mit sich. Die Aufteilung in mehrere bidirektional fließende Datenströme – SIP für die Signalisierung, RTP für die Medien und RTCP für die Kontrollinformationen – erhöht die Fehleranfälligkeit. Die dynamische Aushandlung von Codecs, Adressen und Zusatzinformationen über das Session Description Protocol (SDP) innerhalb des SIP-Dialogs für RTP kann in einigen Fällen zu Problemen bei der Interoperabilität führen. Bei mittlerweile über 100 RFCs, von denen viele mit „Sollte“- anstatt „Muss“-Empfehlungen agieren, kommt es unweigerlich zu Schwierigkeiten. In der Praxis führt diese Situation immer wieder zu Interoperabilitätsproblemen zwischen verschiedenen Implementierungen. Bisherige Ansätze zur Verbesserung der Interoperabilität wie SIPConnect 2.0 mit Empfehlungen für Provider-Anschaltungen waren nur bedingt erfolgreich.
Dieser erste Beitrag einer vierteiligen Artikelserie zum SIP- und RTP-Troubleshooting stellt zunächst die Grundlagen der Protokolle vor, bevor in den nächsten Teilen Werkzeuge und Praxisbeispiele an der Reihe sind.
Technische Architektur und Protokollinteraktion
SIP und RTP sind komplementäre Protokolle mit klar getrennten Aufgabenbereichen. Während SIP für die Signalisierung, also den Aufbau, die Modifikation und den Abbau von Kommunikationssitzungen verantwortlich ist, übernimmt RTP den Echtzeit-Transport von Medieninhalten wie Sprache oder Video. Beide Protokolle arbeiten mit unterschiedlichen Datenströmen, die jedoch eng miteinander verknüpft sind. So werden etwa die für RTP benötigten Informationen wie IP-Adressen, Ports und Codecs über SDP-Nachrichten innerhalb des SIP-Dialogs ausgetauscht.
Besonders interessant ist das sogenannte SIP-Trapezoid, das die Trennung von Signalisierung und Medienströmen veranschaulicht. Während SIP-Nachrichten den Weg über SIP-Proxys und -Server nehmen, folgen die RTP-Streams oft einem eigenen Pfad. Dies kann zu Problemen führen, wenn die Netzwerkpfade für Signalisierung und Medien nicht konsistent sind oder wenn Firewalls und NAT-Geräte die RTP-Streams blockieren.
Nachrichtenaufbau und Adressierung in SIP
Eine SIP-Nachricht besteht grundsätzlich aus drei Teilen: der Request- oder Statuszeile, dem Message-Header und dem Message Body, der optional das SDP enthält. Die Header enthalten beispielsweise Quell- und Zielinformationen in To- und From-Header. Sie können aber auch beispielsweise für den Austausch von unterstützen Funktionen, wie Session-Timer oder für die Authentifizierung zum Einsatz kommen.
Für die Adressierung von Teilnehmern kommt in SIP der Uniform Resource Identifier (URI) zum Einsatz. Dieser setzt sich aus einem User-Anteil (meist eine Rufnummer oder ein Benutzername) und einem Host-Anteil (eine IP-Adresse oder ein vollqualifizierter Domänenname) zusammen. Optional können Ports und Transportprotokolle, wie TCP oder UDP angegeben werden. Diese flexible Adressierung ermöglicht es, SIP in verschiedenen Netzwerkumgebungen einzusetzen, erfordert aber auch eine präzise Konfiguration und Abstimmung der beteiligten Kommunikationspartner, um Kompatibilitätsprobleme zu vermeiden.
SDP: Dynamische Medienbeschreibung und Codec-Aushandlung
Das Session Description Protocol (SDP) spielt eine zentrale Rolle bei der Aushandlung der Medienparameter zwischen den Kommunikationspartnern. Im Rahmen des SIP-Dialogs tauschen die Parteien SDP-Nachrichten aus, um die unterstützten Codecs, IP-Adressen, Ports und andere Parameter zu vereinbaren. Dieser Prozess folgt dem Offer/Answer-Modell: Eine Seite bietet ihre Fähigkeiten an (Offer), die andere prüft diese und antwortet mit den gemeinsam nutzbaren Parametern (Answer).
SDP definiert nicht nur, welche Medien (Audio, Video) übertragen werden sollen, sondern auch, ob die Kommunikation bidirektional oder unidirektional (beispielsweise im Haltezustand mit Wartemusik) erfolgt, welche Paketierungszeiten (zum Beispiel 20 oder 30 ms) verwendet werden und ob die Übertragung verschlüsselt stattfindet. Die Codec-Auswahl ist dabei besonders kritisch, da Inkompatibilitäten hier zu einseitiger oder keiner Sprachverbindung führen können. Die Zuordnung der Codecs zu sogenannten Payload Types ist von der IANA standardisiert. Dabei sind die Werte 0 bis 34 fest definiert, während die Werte von 96 bis 127 dynamisch vergeben werden können.
RTP: Echtzeit-Transport von Medieninhalten
Das Real-Time Transport Protocol (RTP) dient der Übertragung von Echtzeitmedien, beispielsweise Sprache und Video. Da jeder RTP-Stream unidirektional ist, werden für eine bidirektionale Kommunikation zwei Ströme benötigt. Da Echtzeitanwendungen keine Zeit für Paketwiederholungen oder Flusskontrolle haben, nutzt RTP das Transportprotokoll UDP. Verspätet eintreffende Pakete werden verworfen, da sie für die Echtzeitwiedergabe nicht mehr nutzbar sind.
Der RTP-Header enthält wichtige Informationen wie den Synchronization Source Identifier (SSRC) zur eindeutigen Identifizierung des Streams und die Sequence Number, eine fortlaufende Nummer, die es ermöglicht, Paketverluste zu erkennen. Diese Informationen sind für die Fehlerbehebung von entscheidender Bedeutung, da sie Aufschluss über die Qualität der Übertragung geben. So lassen sich aus der Analyse der Sequence Numbers nicht nur Paketverluste, sondern auch Latenz und Jitter ableiten, die die Sprachqualität maßgeblich beeinflussen.
Als Faustformel für eine gute Qualität der Sprachübertragung gelten
- maximal ein Prozent Paketverlust,
- maximal 20 Millisekunden Jitter,
- maximal 150 Millisekunden Verzögerung von Mund zu Ohr (unidirektional).
Jedoch kommt es beispielsweise auch auf die Häufung der Paketverluste, den sogenannten Burst Loss, sowie den ausgewählten Codec und den Umgang der Endgeräte mit schlechten Qualitätseigenschaften im Netzwerk an. Neuere KI-Codecs, wie beispielsweise in Teams und Webex, versuchen, schlechte Eigenschaften zu kaschieren.
SIP-Transaktionen, Dialoge und Anfragemethoden
SIP orientiert sich stark an HTTP und verwendet ein transaktionsbasiertes Modell. Eine Transaktion besteht aus einer Anfrage und der dazugehörigen finalen Antwort, während ein Dialog alle Signalisierungsnachrichten von der Initialisierung bis zum Abbau einer Sitzung umfasst. Zu den wichtigsten SIP-Anfragemethoden zählen:
- INVITE für den Aufbau eines Anrufs oder die Änderung einer Sitzung.
- BYE für den Abbruch eines Gesprächs.
- CANCEL für den Abbruch einer ausstehenden Anfrage.
Ein besonderer Fall ist das Re-INVITE, das nach dem initialen Anrufaufbau gesendet wird, um Parameter wie Codecs oder Haltezustände zu ändern. Diese Flexibilität ist zwar nützlich, kann aber auch zu Problemen führen, wenn die Kommunikationspartner die SIP-Spezifikationen unterschiedlich interpretieren.
SIP-Antwortcodes: Fehlererkennung und -behebung
SIP-Antwortcodes sind in sechs Klassen unterteilt, die von vorläufigen Informationen (1xx) bis zu globalen Fehlern (6xx) reichen. Für das Troubleshooting besonders relevant sind die Fehlercodes ab 4xx. Sie weisen auf clientseitige (4xx), serverseitige (5xx) oder globale (6xx) Probleme hin.
Häufige Fehlercodes im Praxisbetrieb sind etwa 401 Unauthorized und 407 Proxy Authentication Required, die eine Authentifizierung erfordern, sowie 404 Not Found, das auf eine nicht auffindbare Rufnummer hinweist. Die Codes 415 Unsupported Media und 488 Not Acceptable Here deuten auf Inkompatibilitäten bei der Codec-Aushandlung hin. Die Codes 500 Server Internal Error und 503 Service Unavailable lassen auf serverseitige Probleme schließen. Die korrekte Interpretation dieser Codes ist essenziell, um die Ursache von Verbindungsproblemen schnell zu identifizieren und zu beheben.
Ein typisches Beispiel ist die Antwort 401 Unauthorized beziehungsweise 407 Proxy Authentication Required, die nicht zwingend einen Fehler darstellt, sondern oft eine Aufforderung zur Authentifizierung ist. Enthält die Antwort einen WWW-Authenticate-Header, muss der Client die Anfrage mit den entsprechenden Authentifizierungsdaten wiederholen. Fehlt dieser Header, handelt es sich um eine endgültige Ablehnung, deren Ursache oft nur durch Rücksprache mit dem Betreiber der Gegenseite geklärt werden kann.
Fazit
Trotz der Komplexität und der zahlreichen potenziellen Fehlerquellen bleibt die Kombination aus SIP und RTP der dominierende Standard für IP-basierte Telekommunikation. Die Flexibilität und Skalierbarkeit dieser Protokolle ermöglichen innovative Dienste und Anwendungen, erfordern aber auch ein tiefes technisches Verständnis für den Betrieb und die Fehlerbehebung.
Die größten Herausforderungen liegen in der Interoperabilität zwischen verschiedenen Implementierungen, der dynamischen Aushandlung von Parametern und der Sicherstellung der Medienqualität in heterogenen Netzwerken. Moderne Analysewerkzeuge unterstützen zwar bei der Diagnose, doch das Verständnis der zugrunde liegenden Mechanismen bleibt unverzichtbar.
