20. Headerfelder (Header Fields)
20 Headerfelder
Die allgemeine Syntax der Headerfelder wird in Abschnitt 7.3 behandelt. Dieser Abschnitt listet den vollständigen Satz von Headerfeldern mit Anmerkungen zu Syntax, Semantik und Verwendung auf. In diesem Abschnitt wird [HX.Y] verwendet, um auf den Abschnitt X.Y der aktuellen HTTP/1.1-Spezifikation RFC 2616 [8] zu verweisen. Beispiele für jedes Headerfeld werden gezeigt.
Informationen zu Headerfeldern im Zusammenhang mit Methoden und Proxy-Verarbeitung sind in den Tabellen 2 und 3 zusammengefasst.
Die Spalte „where" beschreibt die Arten von Anforderungen und Antworten, in denen das Headerfeld erscheinen kann. Die Werte dieser Spalte lauten wie folgt:
R: Das Headerfeld kann nur in Anforderungen erscheinen.
r: Das Headerfeld kann nur in Antworten erscheinen.
2xx, 4xx usw.: Eine Zahl oder ein Bereich gibt den Antwortcode an, in dem das Headerfeld verwendet werden kann.
c: Das Headerfeld wird von der Anforderung in die Antwort kopiert.
Wenn die Spalte „where" leer ist, zeigt dies an, dass das Headerfeld in allen Anforderungen und Antworten vorhanden sein kann.
Die Spalte „proxy" beschreibt die Vorgänge, die ein Proxy für das Headerfeld ausführen kann.
a: Ein Proxy kann das Headerfeld hinzufügen oder anfügen, wenn es fehlt.
m: Ein Proxy kann einen vorhandenen Headerfeldwert ändern.
d: Ein Proxy kann den Headerfeldwert entfernen.
r: Ein Proxy muss in der Lage sein, das Headerfeld zu lesen, daher darf dieses Headerfeld nicht verschlüsselt werden.
Die folgenden sechs Spalten beziehen sich auf das Vorhandensein des Headerfeldes in den Methoden.
c: Bedingt. Die Anforderung an das Headerfeld hängt vom Kontext der Nachricht ab.
m: Das Headerfeld ist obligatorisch.
m*: Das Headerfeld SOLLTE gesendet werden, aber Client/Server müssen bereit sein, eine Nachricht ohne dieses Headerfeld zu empfangen.
o: Das Headerfeld ist optional.
t: Das Headerfeld SOLLTE gesendet werden, aber Client/Server müssen bereit sein, eine Nachricht ohne dieses Headerfeld zu empfangen.
Wenn ein strombasierter Transport (wie TCP) verwendet wird, MUSS das Headerfeld gesendet werden.
*: Das Headerfeld ist obligatorisch, wenn der Nachrichtenrumpf nicht leer ist. Details siehe Abschnitte 20.14, 20.15 und 7.4.
-: Das Headerfeld ist nicht anwendbar.
„Optional" bedeutet, dass ein Element das Headerfeld in einer Anforderung oder Antwort enthalten MAY, und dass ein UA das Headerfeld ignorieren MAY, wenn es in einer Anforderung oder Antwort vorhanden ist (mit der Ausnahme des Require-Headerfelds, das in Abschnitt 20.32 erörtert wird). Ein „obligatorisches" Headerfeld muss in einer Anforderung vorhanden sein und vom empfangenden UAS verstanden werden. Ein „obligatorisches" Antworthheaderfeld muss in der Antwort vorhanden sein, und das Headerfeld muss vom die Antwort verarbeitenden UAC verstanden werden. „Nicht anwendbar" bedeutet, dass das Headerfeld in einer Anforderung NICHT vorhanden sein darf. Wenn es versehentlich in eine Anforderung gesetzt wird, muss es vom empfangenden UAS ignoriert werden. Ebenso bedeutet ein als „nicht anwendbar" für eine Antwort gekennzeichnetes Headerfeld, dass der UAS das Headerfeld nicht in die Antwort setzen darf und der UAC das Headerfeld in der Antwort ignorieren muss.
Ein UA SOLLTE Erweiterungs-Headerfeldparameter, die er nicht versteht, ignorieren.
Für den Fall, dass die Gesamtgröße der Nachricht problematisch ist, sind einige Abkürzungen für gängige Headerfeldnamen definiert.
Die Headerfelder Contact, From und To enthalten URIs. Wenn ein URI ein Komma, ein Fragezeichen oder ein Semikolon enthält, muss der URI von Winkelklammern („<" und „>") umschlossen sein. URI-Parameter sind innerhalb dieser Klammern enthalten. Wenn der URI nicht von Winkelklammern umschlossen ist, sind die durch Semikolons getrennten Parameter Header-Parameter und keine URI-Parameter.
20.1 Accept
Das Accept-Headerfeld folgt der in [H14.1] definierten Syntax. Die Semantik ist ebenfalls identisch, mit der Ausnahme, dass, wenn das Accept-Headerfeld fehlt, der Server den Standardwert application/sdp annehmen SOLLTE.
Ein leeres Accept-Headerfeld bedeutet, dass kein Format akzeptiert wird.
Beispiel:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
Authentication-Info 2xx - o - o o o
Authorization R o o o o o o
Call-ID c r m m m m m m
Call-Info ar - - - o o o
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
Content-Disposition o o - o o o
Content-Encoding o o - o o o
Content-Language o o - o o o
Content-Length ar t t t t t t
Content-Type * * - * * *
CSeq c r m m m m m m
Date a o o o o o o
Error-Info 300-699 a - o o o o o
Expires - - - o - o
From c r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R amr m m m m m m
Min-Expires 423 - - - - - m
MIME-Version o o - o o o
Organization ar - - - o o o
Tabelle 2: Zusammenfassung der Headerfelder, A–O
Header field where proxy ACK BYE CAN INV OPT REG
Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o
Tabelle 3: Zusammenfassung der Headerfelder, P–Z; (1): mit möglichem Tag-Zusatz kopiert
Accept: application/sdp;level=1, application/x-private, text/html
20.2 Accept-Encoding
Das Accept-Encoding-Headerfeld ähnelt Accept, schränkt aber auf die in der Antwort akzeptierten content-codings [H3.5] ein. Siehe [H14.3]. Die Semantik in SIP ist identisch mit der in [H14.3] definierten.
Ein leeres Accept-Encoding-Headerfeld ist zulässig. Es ist äquivalent zu Accept-Encoding: identity, das heißt, nur das identity-Coding, das keine Codierung bedeutet, ist zulässig.
Wenn das Accept-Encoding-Headerfeld fehlt, SOLLTE der Server den Standardwert identity annehmen.
Dies unterscheidet sich etwas von der HTTP-Definition. Die HTTP-Definition besagt, dass, wenn es fehlt, ein beliebiges Coding verwendet werden kann, aber das identity-Coding bevorzugt wird.
Beispiel:
Accept-Encoding: gzip
20.3 Accept-Language
Das Accept-Language-Headerfeld wird in einer Anforderung verwendet, um die bevorzugte Sprache für den Grund Satz, die Sitzungsbeschreibung oder die Statusantwort anzugeben, die im Nachrichtenrumpf der Antwort transportiert werden. Wenn das Accept-Language-Headerfeld fehlt, SOLLTE der Server annehmen, dass alle Sprachen vom Client akzeptiert werden.
Das Accept-Language-Headerfeld folgt der in [H14.4] definierten Syntax. Die Sortierregeln für Sprachen basierend auf dem Parameter „q" gelten auch für SIP.
Beispiel:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
20.4 Alert-Info
Wenn es in einer INVITE-Anforderung vorhanden ist, gibt das Alert-Info-Headerfeld einen alternativen Klingelton für den UAS an. Wenn es in einer 180 (Ringing)-Antwort vorhanden ist, gibt das Alert-Info-Headerfeld einen alternativen Klingelton für den UAC an. Die typische Verwendung besteht darin, dass ein Proxy dieses Headerfeld einfügt, um eine eigene Klingeltonfunktion bereitzustellen.
Das Alert-Info-Headerfeld kann ein Sicherheitsrisiko darstellen. Diese Risiken und deren Umgang werden in Abschnitt 20.9 erörtert, der das Call-Info-Headerfeld behandelt, da die Risiken identisch sind.
Darüber hinaus SOLLTE der Benutzer in der Lage sein, diese Funktion selektiv zu deaktivieren.
Dies hilft, Verwirrung zu vermeiden, die durch die Verwendung dieses Headerfelds durch ein nicht vertrauenswürdiges Element entstehen kann.
Beispiel:
Alert-Info: <http://www.example.com/sounds/moo.wav>
20.5 Allow
Das Allow-Headerfeld zählt die Menge der vom die Nachricht generierenden UA unterstützten Methoden auf.
Alle vom UA verstandenen Methoden (einschließlich ACK und CANCEL) MÜSSEN, falls vorhanden, in der Methodenliste des Allow-Headerfelds enthalten sein. Das Fehlen des Allow-Headerfelds darf NICHT so interpretiert werden, dass der die Nachricht sendende UA keine Methode unterstützt. Vielmehr bedeutet es, dass es keine Informationen über die vom UA unterstützten Methoden bereitstellt.
Das Einschließen des Allow-Headerfelds in eine Antwort auf eine andere als die OPTIONS-Methode reduziert die Anzahl der benötigten Nachrichten.
Beispiel:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
20.6 Authentication-Info
Das Authentication-Info-Headerfeld bietet gegenseitige Authentifizierung über HTTP Digest. Ein UAS KANN dieses Headerfeld in eine 2xx-Antwort auf eine Anforderung aufnehmen, die basierend auf dem Authorization-Headerfeld durch Digest erfolgreich authentifiziert wurde.
Die Syntax und Semantik folgen den in RFC 2617 [17] angegebenen.
Beispiel:
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
20.7 Authorization
Das Authorization-Headerfeld enthält die Authentifizierungsanmeldedaten des UA. Eine Zusammenfassung der Verwendung des Authorization-Headerfelds findet sich in Abschnitt 22.2, und die Syntax und Semantik bei Verwendung für die HTTP-Authentifizierung werden in Abschnitt 22.4 beschrieben.
Dieses Headerfeld bricht zusammen mit Proxy-Authorization die allgemeinen Regeln für mehrere Headerfelder. Es ist keine durch Kommas getrennte Liste, aber dieser Headerfeldname kann mehrmals erscheinen und darf NICHT unter Verwendung der in Abschnitt 7.3 beschriebenen üblichen Regeln zu einer einzelnen Headerzeile zusammengeführt werden.
Im folgenden Beispiel befinden sich keine Anführungszeichen um die Digest-Parameter.
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
20.8 Call-ID
Das Call-ID-Headerfeld identifiziert eine bestimmte Einladung oder alle Registrierungen eines bestimmten Clients eindeutig. Eine einzelne Multimedia-Konferenz kann beispielsweise, wenn ein Benutzer eine einzelne Person mehrmals zur selben (langlebigen) Konferenz einlädt, mehrere Anrufe mit unterschiedlichen Call-ID erzeugen. Die Call-ID unterscheidet zwischen Groß- und Kleinschreibung und wird einfach byteweise verglichen.
Die Abkürzung des Call-ID-Headerfelds ist i.
Beispiel:
Call-ID: [email protected]
i:[email protected]
20.9 Call-Info
Das Call-Info-Headerfeld liefert zusätzliche Informationen über den Anrufer oder den Gerufenen, je nachdem, ob es sich um eine Anforderung oder eine Antwort handelt. Der Zweck des URI wird durch den Parameter „purpose" beschrieben. Der Parameter „icon" gibt ein Bild an, das als ikonische Darstellung des Anrufers oder Gerufenen geeignet ist. Der Parameter „info" beschreibt den Anrufer oder Gerufenen allgemein, beispielsweise über eine Webseite. Der Parameter „card" stellt eine Visitenkarte bereit, beispielsweise im vCard [36]- oder LDIF [37]-Format. Zusätzliche Token können unter Verwendung von IANA und den Verfahren des Abschnitts 27 registriert werden.
Die Verwendung des Call-Info-Headerfelds kann ein Sicherheitsrisiko darstellen. Wenn der Benutzer einen vom bösartigen Anrufer bereitgestellten URI abruft, kann er Risiken wie unangemessene oder beleidigende Inhalte, gefährliche oder illegale Inhalte ausgesetzt sein. Daher SOLLTE ein UA die Informationen des Call-Info-Headerfelds nur anzeigen, wenn er die Echtheit des Elements, das das Headerfeld ausgegeben hat, verifizieren kann und ihm vertraut. Dies muss nicht der Peer-UA sein. Ein Proxy kann dieses Headerfeld in eine Anforderung einfügen.
Beispiel:
Call-Info: http://wwww.example.com/alice/photo.jpg ;purpose=icon, http://www.example.com/alice/ ;purpose=info
20.10 Contact
Der Wert des Contact-Headerfelds liefert einen URI, dessen Bedeutung von der Art der Anforderung oder Antwort abhängt, in der er enthalten ist.
Ein Contact-Headerfeldwert kann einen Anzeigenamen, einen URI mit URI-Parametern und Header-Parametern enthalten.
Dieses Dokument definiert die Contact-Parameter „q" und „expires". Diese Parameter werden nur verwendet, wenn Contact in einer REGISTER-Anforderung oder -antwort oder in einer 3xx-Antwort vorhanden ist. Zusätzliche Parameter können in anderen Spezifikationen definiert werden.
Wenn der Headerfeldwert einen Anzeigenamen enthält, ist der URI einschließlich aller URI-Parameter von „<" und „>" umschlossen. In Abwesenheit von „<" und „>" sind alle Parameter nach dem URI Header-Parameter und keine URI-Parameter. Der Anzeigename kann ein Token sein oder, falls ein größeres Zeichenset gewünscht wird, eine Zeichenfolge in Anführungszeichen.
Wenn der „display-name" leer ist, MUSS die Form „name-addr" verwendet werden, wenn die „addr-spec" ein Komma, ein Semikolon oder ein Fragezeichen enthält. Es darf, muss aber nicht, ein LWS zwischen dem Anzeigenamen und „<" vorhanden sein.
Diese Regeln zum Parsen des Anzeigenamens, des URI, der URI-Parameter und der Header-Parameter gelten auch für die Headerfelder To und From.
Das Contact-Headerfeld hat eine ähnliche Rolle wie das Location-Headerfeld von HTTP. Das HTTP-Headerfeld erlaubt jedoch nur eine einzelne Adresse ohne Anführungszeichen. URIs können Kommas und Semikolons als reservierte Zeichen enthalten, und sie könnten jeweils mit dem Header- oder Parameter-Trennzeichen verwechselt werden.
Die Abkürzung des Contact-Headerfelds ist m (für „moved").
Beispiel:
Contact: "Mr. Watson" <sip:[email protected]>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:[email protected]> ;q=0.1
m: <sips:[email protected]>;expires=60
20.11 Content-Disposition
Das Content-Disposition-Headerfeld beschreibt, wie der Nachrichtenrumpf oder im Falle einer Mehrteil-Nachricht der Nachrichtenrumpfteil vom UAC oder UAS interpretiert wird. Dieser SIP-Header erweitert den MIME Content-Type (RFC 2183 [18]).
Mehrere neue „disposition-type" des Content-Disposition-Headers werden durch SIP definiert. Der Wert „session" gibt an, dass der Rumpfteil eine Sitzung beschreibt, entweder für den Anruf oder für die anfänglichen (vor dem Anruf) Medien. Der Wert „render" gibt an, dass der Rumpfteil dem Benutzer angezeigt oder anderweitig gerendert werden soll. Der Wert „render" wird anstelle von „inline" verwendet, um die Implikation zu vermeiden, dass der MIME-Rumpf im Rahmen des Renderings der gesamten Nachricht angezeigt wird (da der MIME-Rumpf einer SIP-Nachricht oft nicht dem Benutzer angezeigt wird). Für Abwärtskompatibilität SOLLTE ein Server, wenn das Content-Disposition-Headerfeld fehlt, annehmen, dass ein Rumpf des Inhaltstyps application/sdp die Disposition „session" hat und andere Inhaltstypen die Disposition „render" haben.
Der Dispositionstyp „icon" gibt an, dass der Rumpfteil ein Bild enthält, das als ikonische Darstellung des Anrufers oder Gerufenen geeignet ist und vom Benutzeragenten bei Nachrichtenempfang als Information gerendert werden kann oder während eines Dialogs fortlaufend gerendert werden kann. Der Wert „alert" gibt an, dass der Rumpfteil Informationen (wie einen Audioclip) enthält, die vom Benutzeragenten gerendert werden sollen, um den Benutzer auf den Empfang einer Anforderung (allgemein eine einen Dialog initiierende Anforderung) aufmerksam zu machen. Dieser Warnrumpf kann beispielsweise nach dem Senden einer vorläufigen 180 Ringing-Antwort als Klingelton eines Telefonanrufs gerendert werden.
Jeder MIME-Rumpf mit einem „disposition-type", der Inhalte für den Benutzer rendert, SOLLTE nur verarbeitet werden, wenn die Nachricht ordnungsgemäß authentifiziert ist.
Der handling-Parameter (handling-param) beschreibt die Reaktion des UAS, wenn es einen Nachrichtenrumpf empfängt, dessen Inhaltstyp oder Dispositionstyp es nicht versteht. Der Parameter hat die vordefinierten Werte „optional" und „required". Wenn der handling-Parameter fehlt, SOLLTE der Wert „required" angenommen werden. Der handling-Parameter ist in RFC 3204 [19] beschrieben.
Wenn dieses Headerfeld fehlt, bestimmt der MIME-Typ die standardmäßige Inhaltsdisposition. In dessen Abwesenheit wird „render" angenommen.
Beispiel:
Content-Disposition: session
20.12 Content-Encoding
Das Content-Encoding-Headerfeld wird als Modifikator für den „media-type" verwendet. Wenn vorhanden, zeigt sein Wert an, welches zusätzliche content-coding auf den Entity-Rumpf angewendet wurde, und somit welcher Decodierungsmechanismus angewendet werden muss, um den vom Content-Type-Headerfeld referenzierten media-type zu erhalten. Content-Encoding wird hauptsächlich verwendet, um den Rumpf ohne Verlust der Identität des zugrunde liegenden media-type zu komprimieren.
Wenn mehrere Codings auf den Entity-Rumpf angewendet wurden, MÜSSEN die content-codings in der Reihenfolge aufgezählt werden, in der sie angewendet wurden.
Alle content-coding-Werte unterscheiden nicht zwischen Groß- und Kleinschreibung. IANA dient als Register für content-coding-Wert-Token. Siehe [H3.5] für die Definition der Syntax von content-coding.
Ein Client MAY ein content-coding auf den Rumpf in einer Anforderung anwenden. Ein Server MAY ein content-coding auf den Rumpf in einer Antwort anwenden. Ein Server MUSS nur die in dem Accept-Encoding-Headerfeld der Anforderung aufgezählten Codings verwenden.
Die Abkürzung des Content-Encoding-Headerfelds ist e.
Beispiel:
Content-Encoding: gzip
e: tar
20.13 Content-Language
Siehe [H14.12]. Beispiel:
Content-Language: fr
20.14 Content-Length
Das Content-Length-Headerfeld gibt die Größe des an den Empfänger gesendeten Nachrichtenrumpfs als Dezimalzahl von Oktetten an. Anwendungen SOLLTEN dieses Feld verwenden, um die Größe des übertragenen Nachrichtenrumpfs unabhängig vom media-type der Entität anzugeben. Wenn ein strombasierter Transport (wie TCP) verwendet wird, MUSS das Headerfeld verwendet werden.
Die Größe des Nachrichtenrumpfs umfasst nicht das CRLF, das Headerfelder und Rumpf trennt. Jeder Content-Length-Wert größer oder gleich 0 ist ein gültiger Wert. Wenn die Nachricht keinen Rumpf hat, MUSS der Wert des Content-Length-Headerfelds auf 0 gesetzt werden.
Dass Content-Length weggelassen werden kann, vereinfacht die Erstellung von cgi-artigen Skripten, die dynamisch Antworten generieren.
Die Abkürzung des Headerfelds ist l.
Beispiel:
Content-Length: 349
l: 173
20.15 Content-Type
Das Content-Type-Headerfeld gibt den media-type des an den Empfänger gesendeten Nachrichtenrumpfs an. Das Element „media-type" ist in [H3.7] definiert. Wenn der Rumpf nicht leer ist, MUSS das Content-Type-Headerfeld vorhanden sein. Wenn der Rumpf leer ist und das Content-Type-Headerfeld vorhanden ist, zeigt es an, dass ein Rumpf eines bestimmten Typs eine Länge von null hat (beispielsweise eine leere Audiodatei).
Die Abkürzung des Headerfelds ist c.
Beispiel:
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
20.16 CSeq
Das CSeq-Headerfeld enthält eine einzelne Dezimalsequenznummer und die Anforderungsmethode in einer Anforderung. Die Sequenznummer MUSS als vorzeichenlose 32-Bit-Ganzzahl darstellbar sein. Der Methodenteil von CSeq unterscheidet zwischen Groß- und Kleinschreibung. Das CSeq-Headerfeld bietet ein Mittel, Transaktionen in einem Dialog zu ordnen, eine Transaktion eindeutig zu identifizieren und eine neue Anforderung von einer Retransmission einer Anforderung zu unterscheiden. Zwei CSeq-Headerfelder gelten als gleich, wenn die Sequenznummer und die Anforderungsmethode identisch sind. Beispiel:
CSeq: 4711 INVITE
20.17 Date
Das Date-Headerfeld enthält Datum und Uhrzeit. Im Gegensatz zu HTTP/1.1 unterstützt SIP nur Datum im neuesten RFC 1123 [20]-Format. Wie [H3.3] beschränkt SIP die Zeitzone von SIP-date auf „GMT", während RFC 1123 eine beliebige Zeitzone zulässt. RFC 1123-Daten unterscheiden zwischen Groß- und Kleinschreibung.
Das Date-Headerfeld spiegelt die Zeit wider, zu der die Anforderung oder Antwort ursprünglich gesendet wurde.
Das Date-Headerfeld kann von einem einfachen Endsystem ohne gepufferte Uhr verwendet werden, um ein Konzept der aktuellen Zeit zu erhalten. Mit dem GMT-Format muss der Client jedoch seinen Versatz gegenüber GMT kennen.
Beispiel:
Date: Sat, 13 Nov 2010 23:29:00 GMT
20.18 Error-Info
Das Error-Info-Headerfeld bietet einen Zeiger auf Zusatzinformationen zu einer Fehlerstatusantwort.
Die Benutzeroberflächenfunktionen von SIP-UACs reichen von Popup-Fenstern und Ton auf einem PC-Softwareclient bis hin zu nur Ton auf einem „schwarzen" Telefon oder Endpunkt, der über ein Gateway verbunden ist. Anstatt den fehler erzeugenden Server zu zwingen, einen Fehlerstatuscode mit einem detaillierten Grundtext zu senden und eine Tonaufnahme abzuspielen, ermöglicht das Error-Info-Headerfeld, beides zu senden. Der UAC kann dann den anzuzeigenden Fehlerindikator auswählen.
Ein UAC KANN einen SIP- oder SIPS-URI im Error-Info-Headerfeld wie einen Contact in einer Umleitung behandeln und eine neue INVITE generieren, was zur Einrichtung einer aufgezeichneten Ansagesitzung führt. Ein Nicht-SIP-URI KANN dem Benutzer angezeigt werden.
Beispiel:
SIP/2.0 404 The number you have dialed is not in service
Error-Info: <sip:[email protected]>
20.19 Expires
Das Expires-Headerfeld gibt die relative Zeit an, nach der die Nachricht (oder der Inhalt) abläuft.
Die genaue Bedeutung hängt von der Methode ab.
Der Ablauf in einer INVITE hat keine Auswirkung auf die Dauer der tatsächlichen Sitzung, die sich aus der Einladung ergeben könnte. Das Sitzungsbeschreibungsprotokoll kann jedoch die Möglichkeit bieten, eine Zeitbegrenzung für die Sitzungsdauer auszudrücken.
Der Wert dieses Feldes ist eine ganze Dezimalzahl von Sekunden im Bereich 0 bis (2**32)-1, gemessen ab dem Empfang der Anforderung.
Beispiel:
Expires: 5
20.20 From
Das From-Headerfeld gibt den Initiator der Anforderung an. Dies kann sich vom Initiator des Dialogs unterscheiden. Eine vom Gerufenen an den Anrufer gesendete Anforderung verwendet die Adresse des Gerufenen im From-Headerfeld.
Der optionale „display-name" ist für die Anzeige durch die menschliche Benutzeroberfläche vorgesehen. Wenn die Kennungen des Clients verborgen werden, SOLLTE das System den Anzeigenamen „Anonymous" verwenden. Wenn der „display-name" leer ist, MUSS die Form „name-addr" verwendet werden, wenn die „addr-spec" ein Komma, ein Fragezeichen oder ein Semikolon enthält. Syntaktische Probleme werden in Abschnitt 7.3.1 erörtert.
Zwei From-Headerfelder sind gleichwertig, wenn ihre URIs übereinstimmen und ihre Parameter übereinstimmen. Ein in einem der Headerfelder vorhandener, im anderen fehlender Erweiterungsparameter wird zu Vergleichszwecken ignoriert. Dies bedeutet, dass das Vorhandensein oder Fehlen des Anzeigenamens und der Winkelklammern die Übereinstimmung nicht beeinflusst.
Siehe Abschnitt 20.10 für die Regeln zum Parsen des Anzeigenamens, des URI, der URI-Parameter und der Headerfeldparameter.
Die Abkürzung des From-Headerfelds ist f.
Beispiel:
From: "A. G. Bell" <sip:[email protected]> ;tag=a48s
From: sip:[email protected];tag=887s
f: Anonymous <sip:[email protected]>;tag=hyh8
20.21 In-Reply-To
Das In-Reply-To-Headerfeld zählt die Call-IDs auf, auf die sich dieser Anruf bezieht oder die er beantwortet. Diese Call-IDs können vom Client zwischengespeichert worden sein und in das Headerfeld dieses Rückrufs aufgenommen worden sein.
Dies ermöglicht einem automatisierten Anrufverteilungssystem, einen Rückruf an den Anrufer des ursprünglichen Anrufs zu leiten. Es ermöglicht dem Gerufenen auch, Anrufe zu filtern, indem nur Antworten auf eigene Anrufe akzeptiert werden. Dieses Feld ist kein Ersatz für die Anforderungsauthentifizierung.
Beispiel:
In-Reply-To: [email protected], [email protected]
20.22 Max-Forwards
Das Max-Forwards-Headerfeld wird mit einer beliebigen SIP-Methode verwendet und MUSS die Anzahl der Proxys oder Gateways einschränken, über die die Anforderung an den nächsten Downstream-Server weitergeleitet werden kann. Dies ist auch nützlich, wenn ein Client eine Anforderungskette zu verfolgen versucht, die unterwegs fehlgeschlagen oder sich in einer Schleife zu befinden scheint.
Der Max-Forwards-Wert ist eine ganze Zahl im Bereich 0–255, die angibt, wie oft diese Anforderungsnachricht noch weitergeleitet werden kann. Dieser Zähler wird von jedem Server, der die Anforderung weiterleitet, dekrementiert. Der empfohlene Anfangswert ist 70.
Dieses Headerfeld SOLLTE von einem Element eingefügt werden, das andernfalls keine Schleifenerkennung garantieren kann. Beispielsweise SOLLTE ein B2BUA das Max-Forwards-Headerfeld einfügen.
Beispiel:
Max-Forwards: 6
20.23 Min-Expires
Das Min-Expires-Headerfeld übermittelt das minimale unterstützte Aktualisierungsintervall für die vom Server verwalteten Soft-State-Elemente. Dies schließt die in einem Registrar gespeicherten Contact-Headerfelder ein. Das Headerfeld enthält eine ganze Dezimalzahl von Sekunden im Bereich 0 bis (2**32)-1. Die Verwendung des Headerfelds in einer 423 (Interval Too Brief)-Antwort wird in den Abschnitten 10.2.8, 10.3 und 21.4.17 beschrieben.
Beispiel:
Min-Expires: 60
20.24 MIME-Version
Siehe [H19.4.1].
Beispiel:
MIME-Version: 1.0
20.25 Organization
Das Organization-Headerfeld übermittelt den Namen der Organisation, zu der das die Anforderung oder Antwort ausgebende SIP-Element gehört.
Dieses Feld KANN von der Client-Software zum Filtern von Anrufen verwendet werden.
Beispiel:
Organization: Boxes by Bob
20.26 Priority
Das Priority-Headerfeld gibt die Dringlichkeit der Anforderung an, wie sie vom Client erkannt wird. Das Priority-Headerfeld beschreibt die Priorität, die die SIP-Anforderung für die empfangende Person oder deren Agenten haben sollte. Beispielsweise kann es in Routing- und Annahmeentscheidungen von Anrufen einbezogen werden. In diesen Entscheidungen SOLLTE eine Nachricht ohne Priority-Headerfeld so behandelt werden, als würde sie die Priorität „normal" angeben. Das Priority-Headerfeld hat keine Auswirkung auf die Nutzung von Kommunikationsressourcen wie die Weiterleitungspriorität von Paketen in einem Router oder den Zugriff auf den Schaltkreis in einem PSTN-Gateway. Das Headerfeld kann die Werte „non-urgent", „normal", „urgent" und „emergency" annehmen, obwohl zusätzliche Werte andernorts definiert werden können. Der Wert „emergency" wird nur empfohlen, wenn Leben, körperliche Unversehrtheit oder Eigentum in unmittelbarer Gefahr sind. Andernfalls ist keine Semantik für dieses Headerfeld definiert.
Dies sind die Werte der RFC 2076 [38] mit Hinzufügung von „emergency".
Beispiel:
Subject: A tornado is heading our way!
Priority: emergency
Oder
Subject: Weekend plans
Priority: non-urgent
20.27 Proxy-Authenticate
Der Wert des Proxy-Authenticate-Headerfelds enthält eine Authentifizierungsherausforderung.
Die Verwendung dieses Headerfelds ist in [H14.33] definiert. Details zur Verwendung finden sich in Abschnitt 22.3.
Beispiel:
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
20.28 Proxy-Authorization
Das Proxy-Authorization-Headerfeld ermöglicht es einem Client, sich bei einem Proxy zu identifizieren, der die Authentifizierung des Clients anfordert. Der Proxy-Authorization-Feldwert besteht aus Anmeldedaten, die die Authentifizierungsinformationen des Benutzeragenten für den Proxy und/oder den realm der angeforderten Ressource enthalten.
Siehe Abschnitt 22.3 für die Definition der Verwendung dieses Headerfelds.
Dieses Headerfeld bricht zusammen mit Authorization die allgemeinen Regeln für mehrere Headerfeldnamen. Es ist keine durch Kommas getrennte Liste, aber dieser Headerfeldname kann mehrmals erscheinen und darf NICHT unter Verwendung der in Abschnitt 7.3.1 beschriebenen üblichen Regeln zu einer einzelnen Headerzeile zusammengeführt werden.
Beispiel:
Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022"
20.29 Proxy-Require
Das Proxy-Require-Headerfeld wird von einem UAC verwendet, um Funktionen anzugeben, die ein Proxy unterstützen MUSS, um diese Anforderung zu verarbeiten. Das Require-Headerfeld (Abschnitt 20.32) wird verwendet, um Funktionen anzugeben, die sowohl vom UAC als auch vom UAS unterstützt werden.
Wie das Require-Headerfeld MUSS ein Proxy, wenn das Proxy-Require-Headerfeld eine nicht unterstützte Funktion enthält, eine 420 (Bad Extension)-Antwort zurückgeben und die nicht unterstützten Funktionen im Unsupported-Headerfeld auflisten. Dieses Headerfeld SOLLTE nicht in einer Anforderung verwendet werden, die möglicherweise außerhalb einer Kette vertrauenswürdiger Proxys gesendet wird. Dieses Headerfeld existiert speziell, um einen Proxy über die Funktion zu informieren, die er zur Verarbeitung der Anforderung benötigt, damit die Funktion korrekt funktioniert, wenn der Proxy sie unterstützt, anstatt den Proxy zu zwingen, die Funktion zu implementieren.
Beispiel:
Proxy-Require: foo
20.30 Record-Route
Das Record-Route-Headerfeld wird von einem Proxy verwendet, um ihn in eine Anforderung einzusetzen und das Durchlaufen nachfolgender Anforderungen im Dialog über diesen Proxy zu erzwingen.
Das Record-Route-Headerfeld trägt nicht zur Dialog-ID bei (Abschnitt 12). Die im Record-Route-Headerfeld enthaltenen URIs werden jedoch verwendet, um den Routensatz festzulegen, über den nachfolgende Anforderungen im Dialog gesendet werden.
Ein UA darf keine Elemente aus einem der URIs des Record-Route-Headerfelds oder aus URIs, die im Route-Headerfeld erscheinen, entfernen. Das Record-Route-Headerfeld KANN von einem Proxy hinzugefügt werden, der die Anforderung verarbeitet, und kann basierend auf den in Element 5 des Abschnitts 16.6 erörterten Routing-Entscheidungen auf andere Proxys verweisen. URIs, die den Parameter pp (Abschnitt 19.1.1) nicht enthalten, SOLLTEN den lr-Parameter für die Routing-Kompatibilität mit RFC 2543-Elementen enthalten.
Siehe Abschnitt 12 für weitere Details, wie das Record-Route-Headerfeld zum Routen von Anforderungen in einem Dialog verwendet wird.
Beispiel:
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
20.31 Reply-To
Das Reply-To-Headerfeld enthält, wenn es in einer Anforderungsnachricht enthalten ist, einen SIP- oder SIPS-URI, an den eine Antwort auf die angeforderte Methode (beispielsweise INVITE) gesendet wird. Wenn dieser URI fehlt, wird die Antwort an die im From- oder Contact-Headerfeldwert angegebene Adresse gesendet. In einigen Fällen wird der Anruf von einer anderen Adresse als der Antwortadresse initiiert. Dieses Headerfeld ermöglicht es, die Antwortadresse unabhängig von der Zieladresse anzugeben.
Dieses Feld KANN verwendet werden, um eine Antwort zwischen mehreren Adressen des Empfängers zu leiten. Beispielsweise könnte der Empfänger wünschen, dass der Anruf am geschäftlichen SIP-Telefon eingeht, die Antwort jedoch an ein Mobiltelefon gesendet wird.
Beispiel:
Reply-To: <sip:[email protected]>
20.32 Require
Das Require-Headerfeld wird von einem UAC verwendet, um die Funktionen anzugeben, die der UAS (und die Proxys) unterstützen muss, um die Anforderung zu verarbeiten. Wenn ein Proxy oder UAS eine im Require-Headerfeld einer empfangenen Anforderung aufgeführte Funktion nicht versteht, MUSS dieses Element eine 420 (Bad Extension)-Antwort (Abschnitt 20.40) zurückgeben, die die nicht unterstützten Funktionen im Unsupported-Headerfeld enthält.
Im Gegensatz dazu hätten Funktionen, die nicht im Require-Headerfeld aufgeführt sind, vom UAS möglicherweise angemessen verarbeitet werden können, wenn die Funktion nicht wesentlich für die Semantik der Anforderung war.
Eine Funktion kann als Format der SIP-Nachricht, oder als media-type in der Sitzungsbeschreibung, oder als Parameter, oder als andere Funktion erscheinen. Die Option-Tags des Require-Headerfelds beziehen sich auf mehrere markierte Funktionen, wie in Abschnitt 19.2 beschrieben. Einige Funktionen sind auf Proxys beschränkt (beispielsweise „re-route"). Diese werden mit dem Proxy-Require-Headerfeld (Abschnitt 20.29) angegeben.
Wenn das Require-Headerfeld in einer Anforderungsnachricht enthalten ist, MUSS es in die Antwortnachricht kopiert werden.
Die Implementierungen dieser Spezifikation MÜSSEN äußerst sorgfältig sein, das Require-Headerfeld korrekt zu generieren.
Das Require-Headerfeld führt zu vielen Situationen, in denen Implementierungen miteinander kommunizieren möchten, aber widersprüchliche Erweiterungen unterstützen. Richtig implementierte Erweiterungsaushandlung ist schwierig. Wenn eine im UA unterstützte Funktion in das Require-Headerfeld gesetzt wird, lehnt der Peer, der sie nicht unterstützt, die Anforderung ab. Daher SOLLTE das Require-Headerfeld nur für Funktionen verwendet werden, von denen der UA vernünftigerweise glaubt, dass sie unterstützt werden. Alle anderen Funktionen SOLLTEN im Supported-Headerfeld (Abschnitt 20.37) angegeben werden. Verfügbare Option-Tags für das Require-Headerfeld werden nur in Standards-Track-RFCs definiert. Dies stellt sicher, dass nur wenige standardisierte Funktionen (und insbesondere solche, die sowohl UAS als auch UAC betreffen) ein Option-Tag erhalten. Der strenge Prüfungsprozess für Option-Tags verhindert, dass das Require-Headerfeld einfach zu verwenden und verbreitet ist.
Beispiel:
Require: 100rel
20.33 Retry-After
Das Retry-After-Headerfeld ermöglicht es einem Server anzugeben, wie lange ein Client warten muss, bis er seine Anforderung erneut versuchen kann. Es kann eine relative Anzahl von Sekunden ab der aktuellen Zeit oder optional einen SIP-Datumswert enthalten. Wenn es in einer eine Anforderung ablehnenden Antwort (beispielsweise 500, 503 oder 600) vorhanden ist, zeigt der Wert die Zeitspanne an, nach der der Server die Anforderung akzeptieren oder den Anruf versuchen kann. Wenn es in einer 503 (Service Unavailable)-Antwort vorhanden ist, zeigt dieses Headerfeld die Zeit an, zu der die aufgetretene Überlastung voraussichtlich endet.
Wenn der retry-after-Wert größer als 0 ist, MUSS der Client vor dem erneuten Versuch der Anforderung diese Zeitspanne warten. Wenn dieser Wert 0 ist, KANN der Client die Anforderung sofort erneut versuchen.
Der optionale Parameter „comment" enthält für Menschen lesbaren Text. Der optionale Parameter „duration" stellt die Zeitspanne (in Sekunden) dar, in der ein Anruf nicht versucht werden sollte, auch nachdem der Server entschieden hat, dass er den Anruf versuchen kann.
Beispiel:
Retry-After: 18000;duration=3600
Retry-After: 120;duration=3600
20.34 Route
Das Route-Headerfeld existiert, um einen bevorzugten Fluss zu erzwingen, den der UAC zum Routen der Sitzung verwendet. Ein Proxy ist auch dafür verantwortlich, den in einer empfangenen Anforderung enthaltenen Routensatz zu erfüllen. Siehe Abschnitt 8.1.1.1.
Beispiel:
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
20.35 Server
Das Server-Headerfeld enthält Informationen über den die Antwort verarbeitenden Server und KANN Informationen über die Benutzeragenten-Server-Software enthalten. Wie das ähnliche HTTP-Headerfeld kann dieses Headerfeld aus Sicherheitsgründen weggelassen werden.
Die Verwendung des Server-Headerfelds folgt den gleichen Regeln wie die in [H14.38] für HTTP/1.1 definierten.
Beispiel:
Server: HomeServer v2
20.36 Subject
Das Subject-Headerfeld liefert eine kurze Beschreibung der Art oder des Themas des Anrufs.
Die Verwendung der „Subject"-Zeile durch den Benutzeragenten hat dieselbe Semantik wie in RFC 822 [39] definiert.
Beispiel:
Subject: Need more boxes
20.37 Supported
Das Supported-Headerfeld listet die Menge der vom UAC oder UAS unterstützten Funktionen auf. In vielen Fällen werden Funktionen als Option-Tags (Abschnitt 19.2) aufgeführt.
Wenn das Supported-Headerfeld von einem UAC gesendet wird, KANN der UAS mit den unterstützten Funktionen im Supported-Headerfeld auf den UAC antworten.
Wenn das Supported-Headerfeld von einem UAS gesendet wird, KANN der UAC es ignorieren.
Require und Supported dürfen beide in einer 2xx-Antwort enthalten sein.
Wenn das Supported-Headerfeld in einer Anforderungsnachricht enthalten ist, MUSS es in die Antwortnachricht kopiert werden.
Die Implementierungen dieser Spezifikation MÜSSEN äußerst sorgfältig sein, das Supported-Headerfeld korrekt zu generieren.
Wie in der Erörterung des Require-Headerfelds erklärt, SOLLTE ein UA auf das Require-Headerfeld nur Funktionen setzen, die durch standardisierte Option-Tags identifiziert werden. Der Versuch, das Require-Headerfeld zu verwenden, um nicht standardisierte oder unternehmensspezifische Erweiterungen zu erzwingen, kann die Interoperabilität verringern. Daher SOLLTEN alle unterstützten Optionen im Supported-Headerfeld aufgeführt werden. Verfügbare Option-Tags für das Require-Headerfeld werden nur in Standards-Track-RFCs definiert. Dies stellt sicher, dass nur wenige standardisierte Funktionen (und insbesondere solche, die sowohl UAS als auch UAC betreffen) ein Option-Tag erhalten. Der strenge Prüfungsprozess für Option-Tags verhindert, dass das Require-Headerfeld einfach zu verwenden und verbreitet ist.
Beispiel:
Supported: 100rel
20.38 Timestamp
Das Timestamp-Headerfeld spiegelt die Zeit wider, zu der die Anforderung des UAC generiert wurde. Der Client kann die an den Server zurückgegebene Zeit verwenden, um die Wartezeit auf eine Antwort zu berechnen.
Beispiel:
Timestamp: 54
20.39 To
Das To-Headerfeld gibt die zweite Partei (oder die logisch adressierte Ressource) an, an die die Anforderung ursprünglich gerichtet war. Dieses Headerfeld gibt allgemein den eingeladenen Benutzer oder die Ressource an, nachdem der UAS die Anforderung akzeptiert hat.
Das To-Headerfeld MUSS in allen SIP-Nachrichten in Anforderungen und Antworten enthalten sein.
Wenn das To-Headerfeld von einem UAS generiert wird, MUSS der UAS einen „tag"-Parameter zum To-Headerfeld hinzufügen, um als Teil der Dialog-ID zu fungieren.
Ein UAS KANN dem To-Headerfeld auch dann einen Tag hinzufügen, wenn er die Anforderung aus irgendeinem Grund ablehnt.
Siehe Abschnitt 19.3 für weitere Details zur Tag-Generierung.
Zwei To-Headerfelder sind gleichwertig, wenn ihre URIs übereinstimmen und ihre Parameter übereinstimmen. Ein in einem der Headerfelder vorhandener, im anderen fehlender Erweiterungsparameter wird zu Vergleichszwecken ignoriert. Dies bedeutet, dass das Vorhandensein oder Fehlen des Anzeigenamens und der Winkelklammern die Übereinstimmung nicht beeinflusst.
Siehe Abschnitt 20.10 für die Regeln zum Parsen des Anzeigenamens, des URI, der URI-Parameter und der Headerfeldparameter.
Die Abkürzung des To-Headerfelds ist t.
Beispiel:
To: "A. G. Bell" <sip:[email protected]>;tag=a6c85cf
20.40 Unsupported
Das Unsupported-Headerfeld listet die vom Server nicht unterstützten Funktionen auf. Dieses Headerfeld wird generiert, wenn ein Server eine Anforderung ablehnt, die das Require-Headerfeld (Abschnitt 20.32) enthält.
Beispiel:
Unsupported: foo
20.41 User-Agent
Das User-Agent-Headerfeld enthält Informationen über den die Anforderung initiierenden Benutzeragenten. Wie das ähnliche HTTP-Headerfeld kann dieses Headerfeld aus Sicherheitsgründen weggelassen werden.
Beispiel:
User-Agent: Softphone Release 1.0
20.42 Via
Das Via-Headerfeld gibt das Transportprotokoll an, das zum Senden der Anforderung verwendet wurde, und die Adressen der Agenten (Proxys, Redirectoren und Benutzeragenten), die sie in der Reihenfolge transportiert haben, in der die Anforderung das Netzwerk erreicht hat. Die Via-Headerfelder in Anforderungen und Antworten verfolgen die Route, die die Anforderung genommen hat, und verhindern Schleifen beim Senden von Antworten.
Das Via-Headerfeld listet das Protokoll auf, das die Anwendung zum Senden der Anforderung verwendet hat, und darf nicht mit dem Transportprotokoll verwechselt werden, das zum Übertragen von Nachrichten zwischen Anwendungen verwendet wird. Beispielsweise kann eine SIP-Nachricht zwischen Anwendungen über UDP übertragen werden, aber die SIP-Anwendung verwendet SIP/2.0/TCP, um das Protokoll anzugeben, das zum Senden der Nachricht über TCP verwendet wird.
Die im Rahmen des Via-Headerfelds aufgeführte Adresse ist die Adresse, an die die Antwort gesendet wird. Die verantwortliche Stelle (normalerweise das nächstgelegene Upstream-Element) KANN einen „received"-Parameter zum empfangenen Via-Headerfeld hinzufügen, um dem Proxy zu helfen zu bestimmen, woher er die Antwort empfangen soll.
Siehe Abschnitte 18.2.1 und 18.2.2 für weitere Details zu den Parametern „received" und „rport" des Via-Headerfelds.
Ein UA oder Proxy, der eine Antwort generiert, enthält einen Via-Headerfeldwert, der das Protokoll auflistet, das zum Generieren der Nachricht verwendet wurde. Dieser Wert darf nicht mit dem Protokoll verwechselt werden, das zum Senden der Antwort verwendet wird. Wie bei der Anforderung KANN der Via-Headerfeldwert mehrere Elemente durchlaufen (beispielsweise wenn die Antwort über eine Proxykette zurückgesendet wird).
Ein Via-Headerfeldwert enthält das Protokoll, das zum Senden der Anforderung verwendet wurde, einen Branch-Bezeichner und die Adresse der sendenden Anwendung. Der Branch-Parameter wird verwendet, um die Transaktion zu identifizieren. Das nächstgelegene Upstream-Element (und möglicherweise der Proxy) KANN einen „received"-Parameter einfügen, den es zum Routen der Antwort hinzufügt. Der Wert des Branch-Parameters wird vom Element gewählt, muss aber die folgenden Anforderungen erfüllen. Dies ermöglicht der Anwendung, die Anforderung, den Transport, der zum Senden der Anforderung verwendet wurde, und die Adresse (teilweise groß-/kleinschreibungsunabhängig) der Transportinstanz, die zum Senden der Anforderung verwendet wurde, zu unterscheiden.
o Der Branch-Parameterwert MUSS den Hostnamen oder die Identifikationsinformationen des Elements enthalten.
o Der Branch-Parameterwert KANN geändert werden, um die Erstellung oder Änderung von Teilen der Anforderung einer Nachricht widerzuspiegeln, die geändert werden, ohne die Adresse, den Port und das Transportprotokoll des Elements zu ändern.
Siehe Abschnitt 17 für weitere Details zum „branch"-Parameter.
Die Abkürzung dieses Headerfelds ist V.
Beispiel:
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776sgdkse
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK77ef4z