Sechs Header sind in jedem SIP-Request Pflicht: Via (erfasst den Pfad und trägt den Transaktions-branch), From und To (die logischen Parteien, mit Tags), Call-ID (eine eindeutige Anrufkennung), CSeq (eine Sequenznummer plus Methode) und Max-Forwards (ein Hop-Limit). Zusammen identifizieren Call-ID, From-Tag und To-Tag einen Dialog.
Die sechs Pflicht-Header
RFC 3261 verlangt sechs Header-Felder in jedem Request. Via verfolgt die Route, die der Request nahm, und teilt Responses mit, wie sie zurückfinden. From und To identifizieren den logischen Urheber und das Ziel des Requests. Call-ID ist ein global eindeutiges Token, das alle Nachrichten eines Anrufs teilen. CSeq ordnet Requests innerhalb eines Dialogs und benennt die Methode. Max-Forwards ist ein herabzählender Hop-Zähler, der Schleifen verhindert. Fehlt einer davon, ist die Nachricht ungültig.
| Header | Zweck |
|---|---|
| Via | Zeichnet jeden Hop auf; Antworten nehmen denselben Weg zurück. Enthält den Transaktions-Branch |
| From | Logischer Absender; trägt ein Tag |
| To | Logischer Empfänger; erhält ein Tag in der Antwort |
| Call-ID | Weltweit eindeutige Kennung für den gesamten Anruf |
| CSeq | Sequenznummer + Methode; ordnet Anfragen innerhalb des Dialogs |
| Max-Forwards | Hop-Limit (typischerweise 70); verhindert Routing-Schleifen |
Via und der branch-Parameter
Jeder Proxy, der einen Request weiterleitet, fügt oben seinen eigenen Via-Header ein und baut einen Stack auf, den Responses wieder hinablaufen — eine Response wird rein durch Folgen der Via-Liste geroutet und verfolgt so den Pfad des Requests zurück. Der Via-branch-Parameter identifiziert die Transaktion; seit RFC 3261 muss er mit dem festen Magic Cookie z9hG4bK beginnen, das den branch als global eindeutig und RFC-3261-konform kennzeichnet. Das Zuordnen von Responses und Neuübertragungen zur richtigen Transaktion hängt von diesem Wert ab.
Tags, Dialoge und Transaktionen
Die Dialog-Identität setzt sich aus drei Teilen zusammen: der Call-ID plus dem Tag in From und dem Tag in To. Der Anrufer setzt das From-Tag, wenn er das INVITE sendet; der Angerufene fügt das To-Tag in seiner Response hinzu, und ab diesem Punkt ist der Dialog für beide Seiten vollständig identifiziert. Jeder spätere In-Dialog-Request (re-INVITE, BYE) trägt alle drei, sodass er dem richtigen Anruf zugeordnet ist. Transaktionen hingegen werden über den Via-branch und die Methode zugeordnet — eine feinere Granularität als der Dialog.
| Geltungsbereich | Identifiziert durch |
|---|---|
| Dialog (der Anruf) | Call-ID + From-tag + To-tag |
| Transaktion (Anfragen + Antworten) | Via-Branch + Anfragemethode |
| Reihenfolge der Anfragen in einem Dialog | CSeq-Nummer (wird pro Anfrage erhöht) |
Contact, Routing und weitere gängige Header
Über die sechs Pflicht-Header hinaus prägen mehrere Header Routing und Fähigkeiten. Contact gibt eine direkte URI an, unter der der Sender für künftige Requests erreichbar ist — entscheidend in REGISTER und in dialogaufbauenden Nachrichten. Record-Route lässt einen Proxy für den gesamten Dialog im Signalisierungspfad bleiben, und Route lenkt nachfolgende Requests durch diese Proxies. Expires begrenzt eine Registrierung oder ein Abonnement. Allow, Supported und Require kündigen Fähigkeiten und Erweiterungen an und handeln sie aus. Content-Type und Content-Length beschreiben den Body (meist SDP).
Via: SIP/2.0/UDP pc.example.com;branch=z9hG4bK74bf9 ← transaction id
From: Alice <sip:alice@example.com>;tag=9fxced76sl ← caller + From-tag
To: Bob <sip:bob@biloxi.com> ← callee (To-tag added in reply)
Call-ID: 3848276298220188511@pc.example.com ← whole-call id
CSeq: 1 INVITE ← sequence + method
Contact: <sip:alice@pc.example.com> ← where to reach the caller
Max-Forwards: 70 ← hop limitHäufig gestellte Fragen
Was macht der Via-Header in SIP?
Via erfasst den Pfad, den ein Request nimmt: Jeder Proxy fügt oben seinen eigenen Via hinzu, und Responses folgen dem Via-Stack zurück zum Sender. Sein branch-Parameter identifiziert die Transaktion, sodass Responses und Neuübertragungen dem korrekten Request zugeordnet werden.
Was ist der branch-Parameter z9hG4bK?
z9hG4bK ist das obligatorische Magic Cookie, mit dem ein SIP-branch-Parameter unter RFC 3261 beginnen muss. Es signalisiert, dass der branch-Wert global eindeutig und RFC-3261-konform ist, und ist der Schlüssel, mit dem eine Response ihrer Transaktion zugeordnet wird.
Wie wird ein SIP-Dialog identifiziert?
Durch die Kombination aus Call-ID, dem From-Header-Tag und dem To-Header-Tag. Der Anrufer liefert die Call-ID und das From-Tag im INVITE; der Angerufene fügt das To-Tag in seiner Response hinzu. Alle In-Dialog-Requests tragen dieselben drei Werte.
Wofür ist der CSeq-Header da?
CSeq enthält eine Sequenznummer und die Request-Methode, ordnet Requests innerhalb eines Dialogs und lässt jede Seite Neuübertragungen und Nachrichten außer der Reihe erkennen. Die Nummer erhöht sich mit jedem neuen Request; die Methode muss zu dem Request passen, den sie kennzeichnet.
Was ist der Unterschied zwischen Contact und To?
To ist das logische Ziel des Requests und ändert sich in der Regel nicht. Contact ist eine konkrete URI, unter der der Sender für nachfolgende Requests tatsächlich erreichbar ist. Proxies routen auf To/Request-URI, doch spätere In-Dialog-Requests werden an den Contact gesendet.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)