SIP-Trunking im Detail: Wie Signalisierung und Sitzungsaufbau technisch funktionieren

Die unsichtbare Architektur moderner Unternehmenskommunikation

SIP-Trunking hat im DACH-Raum den klassischen ISDN-Anlagenanschluss weitgehend als technische Grundlage moderner Geschäftstelefonie abgelöst. Statt mehrere physische Sprachkanäle separat bereitzustellen, verbindet ein SIP-Trunk die IP-PBX oder Cloud-PBX eines Unternehmens über eine Datenverbindung mit dem öffentlichen Telefonnetz. Mehrere Durchwahlen, parallele Gespräche, Standortkopplungen, CRM-Integrationen und flexible Rufverteilungen lassen sich dabei über eine gemeinsame IP-Infrastruktur abbilden. Für Unternehmen bedeutet das mehr Skalierbarkeit, allerdings auch eine stärkere Abhängigkeit von Routing, Firewall, DNS, Internetqualität und sauberer Konfiguration.

Das entscheidende architektonische Prinzip besteht in der Trennung zweier Ebenen. SIP übernimmt die Signalisierung, also den Aufbau, die Steuerung und die Beendigung einer Sitzung. Die eigentlichen Sprachdaten werden dagegen typischerweise über RTP übertragen. Dazwischen liegt SDP, das innerhalb von SIP-Nachrichten beschreibt, welche Medien verwendet werden und unter welcher IP-Adresse und welchem Port sie erreichbar sind. Wer diese Trennung versteht, kann Fehler wie One-Way-Audio, fehlgeschlagene Codec-Aushandlungen und unerwartete Gesprächsabbrüche deutlich systematischer analysieren. Ein guter Einstieg sind detaillierte Einblicke in moderne SIP-Trunking-Strukturen für Telefonie-Infrastrukturen.

Grundlagen der Signalisierung nach RFC 3261

Das Session Initiation Protocol, kurz SIP, ist ein textbasiertes Protokoll der Anwendungsschicht. Es dient dazu, Kommunikationssitzungen zwischen Teilnehmern aufzubauen, zu verändern und zu beenden. Der RFC 3261 beschreibt SIP als Protokoll für Sitzungen mit einem oder mehreren Teilnehmern, darunter Internettelefonie, Videokommunikation und Multimedia-Konferenzen. SIP transportiert dabei nicht die Sprache selbst. Es übermittelt Nachrichten, die Endpunkte, Proxies, Registrar-Server und Session Border Controller zur Steuerung einer Verbindung verwenden.

Ein SIP-Endpunkt wird als User Agent bezeichnet. Die Rolle User Agent Client, kurz UAC, sendet eine Anfrage, während der User Agent Server, kurz UAS, diese Anfrage entgegennimmt und beantwortet. In einem realen Gespräch können beide Seiten beide Rollen einnehmen. Ein IP-Telefon oder eine PBX registriert sich häufig beim Registrar des Providers. Dabei meldet das Gerät seine aktuelle Erreichbarkeit, meist mit einer Contact-Adresse. Bei eingehenden Gesprächen kann der Provider diese Information verwenden, um den Ruf an die aktuelle IP-PBX oder an einen SBC zuzustellen. Die Registrierung ist deshalb nicht mit dem Medienpfad gleichzusetzen. Sie schafft Erreichbarkeit auf der Signalisierungsebene, sagt aber noch nichts darüber aus, ob RTP in beide Richtungen fließen kann.

Für die Analyse eines SIP-Traces sind einige Header-Felder besonders wichtig. Sie bilden zusammen die Identität, Reihenfolge und Zustelllogik der Nachrichten:

• Via dokumentiert den Transportweg einer Anfrage und enthält unter anderem den Rücksendeort für Antworten sowie eine Branch-Kennung für die Transaktion.
• From beschreibt die logische Identität des Anrufers und enthält einen Tag zur Dialogidentifikation.
• To bezeichnet das Ziel und erhält bei etablierten Dialogen ebenfalls einen Tag.
• Call-ID identifiziert den Dialog über die beteiligten Nachrichten hinweg.
• CSeq ordnet Anfragen innerhalb eines Dialogs sequenziell und unterscheidet beispielsweise INVITE, ACK, BYE und re-INVITE.

Zusätzlich sind Request-URI, Contact, Route, Record-Route, Max-Forwards und die Allow- beziehungsweise Supported-Header für die Fehlersuche relevant. Ein SIP-Response-Code liefert eine erste Einordnung: 1xx steht für vorläufige Antworten, 2xx für erfolgreiche Verarbeitung, 3xx für Umleitungen und 4xx bis 6xx für Fehler unterschiedlicher Ursache. Die SIP-Parameter-Registrierung der IANA dokumentiert standardisierte Methoden, Header, Statuscodes und Erweiterungen.

Der vollständige SIP-Call-Flow im schrittweisen Ablauf

Ein typischer ausgehender Anruf beginnt mit einem INVITE. Diese Anfrage enthält die Zieladresse, die Identität des Anrufers und häufig bereits ein SDP-Angebot. Darin teilt der anrufende Endpunkt mit, welche Codecs, Medienports und Transportparameter er unterstützt. Der Request wird je nach Architektur zunächst von der lokalen PBX an einen SBC oder direkt an den Provider gesendet. Authentifizierung kann durch eine 401- oder 407-Antwort ausgelöst werden, worauf die PBX das INVITE mit passenden Zugangsdaten erneut übermittelt.

1. INVITE startet den Sitzungsaufbau und kann das SDP-Angebot enthalten.
2. 100 Trying bestätigt, dass die Anfrage verarbeitet wird, ohne bereits ein Klingeln zu signalisieren.
3. 180 Ringing zeigt an, dass das Zielgerät klingelt oder der Zielanschluss den Ruf bearbeitet.
4. 183 Session Progress kann zusätzliche Sitzungsinformationen und Early Media bereitstellen.
5. 200 OK bestätigt die Annahme des Gesprächs und enthält üblicherweise das SDP-Antwortangebot.
6. ACK bestätigt den erfolgreichen Abschluss des INVITE-Dialogs.

Erst nach dem erfolgreichen Abschluss des Dialogs wird die Sprachübertragung nicht durch SIP, sondern durch RTP gestartet. SIP bleibt während des Gesprächs häufig nahezu stumm, kann aber für Halten, Codec-Wechsel, Medienänderungen oder Session-Timer erneut verwendet werden. Der Ablauf lässt sich in einer vereinfachten Übersicht darstellen:

Das Gespräch endet normalerweise mit einem BYE, auf das der andere Teilnehmer mit 200 OK antwortet. Ein CANCEL wird dagegen verwendet, um einen noch nicht abgeschlossenen INVITE-Vorgang abzubrechen, etwa wenn der Anrufer während des Klingelns auflegt. Kommt ein BYE unmittelbar nach dem Verbindungsaufbau, sollte der Trace auf Timer, Authentifizierungsfehler, Codec-Probleme, NAT-Mappings und Session-Timer geprüft werden. Ein Call-Drop ist daher nicht automatisch ein Medienproblem, sondern kann auf jeder Signalisierungsstufe entstehen.

Medien­aushandlung und Nutzdatenübertragung mittels SDP und RTP

SDP, das Session Description Protocol, beschreibt die Medienparameter einer SIP-Sitzung. Es steht nicht neben SIP als eigener Transportkanal, sondern wird häufig als Body in INVITE-, 200-OK- oder re-INVITE-Nachrichten übertragen. Besonders wichtig sind die Sitzungs- und Medienzeilen. Die m=-Zeile nennt Medientyp, Port, Transportprofil und Payload-Typen. Die c=-Zeile enthält die IP-Adresse, während Attribute wie a=rtpmap und a=fmtp Codecdetails und Parameter festlegen.

Die Aushandlung folgt dem Offer-Answer-Modell. Ein Endpunkt sendet ein Angebot, der andere antwortet mit einer kompatiblen Auswahl. Häufig angebotene Sprachcodecs sind G.711, G.722 und Opus. G.711 ist im Festnetz- und Unternehmensumfeld weit verbreitet, benötigt aber mehr Bandbreite als stark komprimierende Verfahren. G.722 ermöglicht HD-Voice, sofern beide Seiten und die Netzqualität dies unterstützen. Opus ist flexibel und für unterschiedliche Bandbreiten geeignet, wird im klassischen Provider-Trunk aber nicht überall angeboten. Gibt es keinen gemeinsamen Codec, kann die Gegenstelle mit 488 Not Acceptable Here antworten.

• Prüfe im SDP, ob die IP-Adresse öffentlich erreichbar oder eine private RFC-1918-Adresse ist.
• Vergleiche den ausgehandelten Codec mit der tatsächlich gesendeten RTP-Payload.
• Kontrolliere, ob die angekündigten UDP-Ports in der Firewall geöffnet und korrekt weitergeleitet werden.
• Berücksichtige DTMF-Parameter wie telephone-event, da Sprachcodec und Tonwahlübertragung getrennt behandelt werden können.
• Analysiere bei Faxproblemen zusätzlich T.38-Angebote und die Umschaltung per re-INVITE.

RTP überträgt die Sprachpakete mit Sequenznummern und Zeitstempeln. Dadurch kann der Empfänger Jitter ausgleichen und fehlende oder verspätete Pakete erkennen. RTCP begleitet RTP mit Kontroll- und Qualitätsinformationen, etwa zu Paketverlust, Jitter und Round-Trip-Zeit. Für die Qualitätssicherung reicht es deshalb nicht, nur den SIP-Statuscode zu betrachten. Ein Gespräch kann mit 200 OK erfolgreich aufgebaut sein und trotzdem wegen Paketverlust, falscher RTP-Adresse oder asymmetrischer Firewall-Regeln unbrauchbar bleiben. Erweiterte SDP-Verfahren, darunter die in RFC 6871 beschriebenen Fähigkeiten zur Medienaushandlung, sind vor allem in komplexen Endpunkt- und Konferenzszenarien relevant.

Typische Fehlerquellen bei NAT und Firewall-Transversal

One-Way-Audio ist eines der bekanntesten SIP-Trunk-Probleme. Ursache ist häufig, dass ein Endpunkt im SDP eine private Adresse wie 192.168.x.x oder 10.x.x.x ankündigt. Der entfernte Provider kann diese Adresse aus dem Internet nicht erreichen. Die SIP-Signalisierung funktioniert dann scheinbar, weil sie über ein korrektes NAT-Mapping läuft, während die RTP-Pakete am falschen Ziel landen. Umgekehrt kann auch nur eine Richtung blockiert sein, wenn die Firewall eingehende RTP-Pakete verwirft oder der Provider einen anderen Quellport verwendet als erwartet.

Symmetric NAT verschärft die Situation. Dabei hängt ein Mapping nicht nur vom internen Quellport, sondern auch vom Ziel ab. Ein Endpunkt kann daher nicht zuverlässig davon ausgehen, dass eine von ihm gelernte öffentliche Adresse für jede Gegenstelle gültig bleibt. SIP ALG soll solche Probleme auf Routern automatisch lösen, verändert aber in der Praxis nicht immer konsistent Header, SDP, Ports und Dialogzustände. Bei mehreren NAT-Schichten, etwa Router vor Firewall vor SBC, kann ein ALG sogar zusätzliche Fehler verursachen.

• Setze für öffentliche SIP-Trunks möglichst einen dedizierten SBC in einer kontrollierten DMZ ein.
• Definiere Signalisierungs- und RTP-Regeln getrennt, statt pauschal große Portbereiche freizugeben.
• Verwende statisches NAT und dokumentiere die öffentlichen Adressen sowie die zulässigen Providernetze.
• Deaktiviere ein fehlerhaft arbeitendes SIP ALG, wenn der SBC oder die PBX NAT bereits korrekt beherrscht.
• Nutze STUN für die Ermittlung öffentlicher Adressen, TURN als Relay bei restriktiven NAT-Situationen und Media-Proxy-Funktionen eines SBC für kontrollierte RTP-Pfade.

In professionellen Umgebungen sollte der SBC nicht nur Signalisierung, sondern auch Medien kontrollieren können. Er kann private Adressen aus SDP ersetzen, RTP terminieren, Sicherheitsrichtlinien anwenden und Provideranforderungen normalisieren. Eine Cisco-Konfigurationsanleitung für CUBE-Deployments verdeutlicht, wie wichtig DMZ-Platzierung, statisches NAT, definierte Signalisierungsports und passende Medienfreigaben sind. Für Unternehmen in Deutschland kommen zusätzlich Notruffähigkeit, Rufnummernstandort, Datenschutz und dokumentierte Ausweichrouten hinzu. Eine funktionierende NAT-Regel allein garantiert daher noch keine betriebssichere Telefonie.

Erweiterte Szenarien von Rufweiterleitung bis Early Media

Eine etablierte SIP-Sitzung bleibt nicht zwingend unverändert. Ein re-INVITE kann die Medienparameter während eines Gesprächs ändern, beispielsweise beim Halten, beim Wechsel des Codecs, bei der Aktivierung von Video oder beim Übergang zu T.38. UPDATE nach RFC 3311 ermöglicht ebenfalls eine Änderung der Sitzungsparameter. Der wesentliche Unterschied besteht darin, dass UPDATE auch in einem frühen Dialog vor dem endgültigen 200 OK eingesetzt werden kann. Das ist für Early-Media-Szenarien relevant, erfordert aber eine saubere Offer-Answer-Reihenfolge.

• re-INVITE wird häufig in bestätigten Dialogen zur Medienänderung verwendet.
• UPDATE kann Sitzungsparameter bereits während des frühen Dialogs aktualisieren.
• REFER fordert den Empfänger auf, eine im Refer-To-Header angegebene Ressource zu kontaktieren.
• 183 Session Progress kann vor der endgültigen Annahme Audio wie Netzansagen, Wartemusik oder Freizeichen liefern.

Bei einer Vermittlung wird REFER nach RFC 3515 eingesetzt. Der Refer-To-Header beschreibt das Ziel der weiteren Kontaktaufnahme, während Benachrichtigungen über das Refer-Event-Paket den Verlauf des Transfer-Vorgangs melden. Early Media ist besonders bei Provideransagen, Warteschlangen und internationalen Rufzielen wichtig. Ein 183 Session Progress bedeutet nicht automatisch, dass der Teilnehmer den Ruf angenommen hat. Deshalb muss bei der Auswertung unterschieden werden, ob RTP nur vor dem Verbindungsaufbau läuft oder bereits ein bestätigter Dialog besteht.

Souveräne Netzwerkdiagnose für störungsfreie VoIP-Infrastrukturen

Ein strukturiertes Verständnis von SIP, SDP und RTP verwandelt die Fehlersuche von einer Suche nach Einzelursachen in einen nachvollziehbaren Ablauf. Zuerst wird geprüft, ob die Signalisierung vollständig ist: Erreicht das INVITE den Provider, kommen Antworten zurück, wird der Dialog mit ACK bestätigt und beendet eine Seite die Sitzung eventuell durch BYE? Anschließend folgt die Medienanalyse: Welche Adresse steht im SDP, welcher Codec wurde ausgewählt, welche UDP-Ports werden tatsächlich verwendet und sind RTP-Pakete in beiden Richtungen sichtbar?

Für den operativen Betrieb empfiehlt sich ein standardisiertes Vorgehen:

• Wireshark-Traces an definierten Punkten aufnehmen, idealerweise an PBX, Firewall und SBC.
• SIP-Ladder-Diagramme erstellen, damit Transaktionen, Dialoge und Antwortzeiten sichtbar werden.
• SBC- und Firewall-Logs mit den Zeitstempeln des SIP-Traces korrelieren.
• RTP-Statistiken zu Paketverlust, Jitter und Laufzeit getrennt von SIP-Statuscodes bewerten.
• Testfälle für eingehende und ausgehende Gespräche, Halten, Transfer, DTMF, Fax, Notruf und Standortausfall dokumentieren.

Nachhaltige Stabilität entsteht durch klare Verantwortungsgrenzen. Die PBX sollte ihre SIP- und SDP-Parameter kontrolliert erzeugen, der SBC den Übergang zwischen internen und externen Netzen absichern und die Firewall nur notwendige Verkehrsbeziehungen erlauben. Ergänzend sind SIP-TLS für die Signalisierung und SRTP für die Medienübertragung sinnvoll, sofern Provider, Endgeräte und Infrastruktur dies durchgängig unterstützen. Wer zusätzlich Redundanz für Internetzugang, SBC, DNS und Stromversorgung plant, reduziert die Abhängigkeit von einzelnen Komponenten und schafft eine belastbare Grundlage für die Migration von ISDN zu einer modernen, integrierten Unternehmenskommunikation.