Zum Hauptinhalt springen

7. SIP Messages

7 SIP Messages

SIP ist ein textbasiertes Protokoll und verwendet den Zeichensatz UTF-8 (RFC 2279 [7]).

Eine SIP-Nachricht ist entweder eine Anfrage vom Client zum Server oder eine Antwort vom Server zum Client.

Obwohl Anforderungsnachrichten (Abschnitt 7.1) und Antwortnachrichten (Abschnitt 7.2) in den Details des Zeichensatzes und der Syntax abweichen, verwenden sie das Grundformat der RFC 2822 [3] (beispielsweise lässt SIP Header-Felder zu, die nach RFC 2822 keine gültigen Header-Felder sind). Beide Nachrichtentypen bestehen aus einer Startzeile, einem oder mehreren Header-Feldern, einer leeren Zeile, die das Ende der Header-Felder kennzeichnet, und einem optionalen Nachrichtenrumpf.

     generic-message  =  start-line
                         *message-header
                         CRLF
                         [ message-body ]
     start-line       =  Request-Line / Status-Line

Die Startzeile, jede Header-Feldzeile und die Leerzeile MÜSSEN (MUST) mit einer Wagenrücklauf-Zeilenvorschub-Sequenz (CRLF) enden. Beachten Sie, dass eine Leerzeile auch dann vorhanden sein muss, wenn kein Nachrichtenrumpf existiert.

Mit Ausnahme der obigen Zeichensatzunterschiede ist ein Großteil der Syntax der SIP-Nachrichten und Header-Felder mit der von HTTP/1.1 identisch. Anstatt die Syntax und Semantik hier zu wiederholen, verwenden wir [HX.Y], um auf den Abschnitt X.Y der aktuellen HTTP/1.1-Spezifikation (RFC 2616 [8]) zu verweisen.

SIP ist jedoch keine Erweiterung von HTTP.

7.1 Anfragen

Eine SIP-Anfrage unterscheidet sich durch eine Startzeile vom Typ Request-Line. Die Request-Line enthält einen Methodennamen, einen Request-URI und die Protokollversion, getrennt durch jeweils ein einzelnes Leerzeichen (SP).

Die Request-Line endet mit CRLF. Außer der CRLF-Sequenz am Zeilenende sind keine CR oder LF zulässig. In keinem Element ist linearer Leerraum (LWS) zulässig.

     Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

  Method: Diese Spezifikation definiert sechs Methoden. REGISTER zum Registrieren von Kontaktinformationen, INVITE, ACK und CANCEL zum Einrichten einer Sitzung, BYE zum Beenden einer Sitzung und OPTIONS zum Abfragen der Fähigkeiten eines Servers. SIP-Erweiterungen, die in Standards-Track-RFCs beschrieben sind, können zusätzliche Methoden definieren.

  Request-URI: Der Request-URI ist ein SIP- oder SIPS-URI wie in Abschnitt 19.1 beschrieben oder ein generischer URI (RFC 2396 [5]). Er gibt den Benutzer oder Dienst an, an den diese Anfrage gerichtet ist. Der Request-URI DARF NICHT (MUST NOT) nicht maskierte Leerzeichen oder Steuerzeichen enthalten und DARF NICHT (MUST NOT) in « < > » eingeschlossen sein.

       SIP-Elemente DÜRFEN (MAY) Request-URIs mit einem Schema anderen als „sip“ oder „sips“ unterstützen (z. B. das „tel“-URI-Schema der RFC 2806 [9]). SIP-Elemente DÜRFEN (MAY) eigene Mittel verwenden, um einen Nicht-SIP-URI umzuwandeln und daraus einen SIP-URI, SIPS-URI oder ein anderes Schema zu erzeugen.

  SIP-Version: Sowohl Anfrage- als auch Antwortnachrichten enthalten die verwendete SIP-Version und folgen [H3.1] (mit SIP anstelle von HTTP und SIP/2.0 anstelle von HTTP/1.1) bezüglich Versionsreihenfolge, Konformitätsanforderungen und Versionsnummern-Upgrade. Zur Konformität MUSS (MUST) eine Anwendung, die eine SIP-Nachricht sendet, eine SIP-Version von „SIP/2.0“ enthalten. Die SIP-Versionszeichenkette ist nicht fallunterschempfindlich, aber Implementierungen MÜSSEN (MUST) sie in Großbuchstaben senden.

       Im Gegensatz zu HTTP/1.1 behandelt SIP die Versionsnummer als literale Zeichenkette. In der Praxis sollte dies keinen Unterschied machen.

7.2 Antworten

Eine SIP-Antwort unterscheidet sich von einer Anfrage durch eine Startzeile vom Typ Status-Line. Die Status-Line besteht aus der Protokollversion, gefolgt vom numerischen Status-Code und dem zugehörigen Grundausdruck, wobei jedes Element durch ein einzelnes SP getrennt ist.

Außer der abschließenden CRLF-Sequenz sind keine CR oder LF zulässig.

  Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

Der Status-Code ist ein dreistelliges Ganzzahl-Ergebniscode, der das Ergebnis des Verstehens und des Versuchs der Befriedigung der Anfrage angibt. Die Reason-Phrase soll eine kurze textliche Beschreibung des Status-Codes geben. Der Status-Code ist für automatische Maschinen gedacht, die Reason-Phrase für menschliche Benutzer. Ein Client muss die Reason-Phrase nicht untersuchen oder anzeigen.

Diese Spezifikation schlägt bestimmte Ausdrücke für die Grundphrasen vor, aber Implementierungen DÜRFEN (MAY) einen anderen Text wählen, wie etwa die in dem Accept-Language-Header-Feld der Anfrage angegebene Sprache.

Die erste Ziffer des Status-Codes definiert die Klasse der Antwort. Die beiden letzten Ziffern haben keine Klassifizierungsrolle. Daher werden Antworten mit Status-Code zwischen 100 und 199 als „1xx-Antworten“, solche zwischen 200 und 299 als „2xx-Antworten“ bezeichnet, und so weiter. In SIP/2.0 sind sechs Werte für die erste Ziffer zulässig.

  1xx: Provisional (vorläufig) — Anfrage empfangen und Verarbeitung wird fortgesetzt.

  2xx: Success (Erfolg) — Aktion wurde empfangen, verstanden und akzeptiert.

  3xx: Redirection (Umleitung) — für die Befriedigung der Anfrage sind weitere Bearbeitungen erforderlich.

  4xx: Client Error (Client-Fehler) — Anfrage hat fehlerhafte Syntax oder kann von diesem Server nicht ausgeführt werden.

  5xx: Server Error (Server-Fehler) — der Server konnte eine scheinbar gültige Anfrage nicht ausführen.

  6xx: Global Failure (globaler Fehler) — die Anfrage kann von keinem Server ausgeführt werden.

Abschnitt 21 definiert diese Klassen und beschreibt die einzelnen Codes.

7.3 Header-Felder

SIP-Header-Felder sind den HTTP-Header-Feldern sowohl in der Syntax als auch in der Semantik ähnlich. Insbesondere folgen SIP-Header-Felder den Definitionen von [H4.2] bezüglich der message-header-Syntax und der Regeln für die Fortsetzung von Header-Feldern über mehrere Zeilen. Diese werden in HTTP jedoch durch impliziten Leerraum und Zeilenumbruch spezifiziert. Diese Spezifikation hält sich an RFC 2234 [10] und verwendet nur expliziten Leerraum und Zeilenumbruch als wesentlichen Teil der Grammatik.

[H4.2] besagt auch, dass mehrere Header-Felder mit demselben Feldnamen, deren Werte durch Kommas getrennte Listen sind, zu einem einzelnen Header-Feld kombiniert werden können. Dies gilt auch für SIP, aber mit spezifischen, unterschiedlichen Regeln aufgrund der anderen Grammatik. Genauer gesagt: Jeder SIP-Header, dessen Grammatik die Form

  header  =  "header-name" HCOLON header-value *(COMMA header-value)

hat, erlaubt das Kombinieren von Header-Feldern desselben Namens zu einer durch Kommas getrennten Liste. Das Contact-Header-Feld erlaubt eine durch Kommas getrennte Liste, sofern der Header-Feldwert nicht „*“ ist.

7.3.1 Header-Feld-Format

Header-Felder folgen dem allgemeinen Header-Format, das in RFC 2822 [3], Abschnitt 2.2, angegeben ist. Jedes Header-Feld besteht aus einem Feldnamen, gefolgt von einem Doppelpunkt („:“) und einem Feldwert.

  field-name: field-value

Die formale message-header-Grammatik in Abschnitt 25 erlaubt beliebigen Leerraum auf beiden Seiten des Doppelpunkts. Implementierungen SOLLTEN (SHOULD) jedoch Leerraum zwischen Feldname und Doppelpunkt vermeiden und ein einzelnes Leerzeichen (SP) zwischen Doppelpunkt und Feldwert verwenden.

  Subject:            lunch
  Subject      :      lunch
  Subject            :lunch
  Subject: lunch

Alle obigen sind daher gültig und äquivalent, aber die letzte ist das empfohlene Format.

Header-Felder können über mehrere Zeilen erweitert werden, indem jede zusätzliche Zeile mit mindestens einem SP oder Horizontal-Tabulator (HT) beginnt. Der Zeilenumbruch und der führende Leerraum der nächsten Zeile werden als ein einzelnes SP-Zeichen behandelt. Daher sind folgende äquivalent.

  Subject: I know you're there, pick up the phone and talk to me!
  Subject: I know you're there,
           pick up the phone
           and talk to me!

Die relative Reihenfolge von Header-Feldern mit unterschiedlichem Feldnamen ist nicht signifikant. Header-Felder, die für die Proxy-Verarbeitung benötigt werden (Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization usw.), werden jedoch empfohlen (RECOMMENDED) am Anfang der Nachricht, um eine schnelle Analyse zu erleichtern. Die relative Reihenfolge von Header-Feldzeilen mit demselben Feldnamen ist signifikant. Mehrere Header-Feldzeilen mit demselben Feldnamen DÜRFEN (MAY) in einer Nachricht nur dann existieren, wenn der vollständige Feldwert dieses Header-Felds als durch Kommas getrennte Liste definiert ist (d. h. gemäß der Grammatik in Abschnitt 7.3). Sie MÜSSEN (MUST) ohne Änderung der Semantik der Nachricht zu einem einzelnen „field-name: field-value“-Paar kombinierbar sein, indem jeder nachfolgende Feldwert an den ersten durch Kommas getrennt angehängt wird. Die Ausnahme von dieser Regel betrifft die Header-Felder WWW-Authenticate, Authorization, Proxy-Authenticate und Proxy-Authorization. Mehrere Header-Feldzeilen mit diesen Namen DÜRFEN (MAY) in einer Nachricht existieren, aber ihre Grammatik folgt nicht dem allgemeinen Format aus Abschnitt 7.3, sie DÜRFEN (MUST NOT) nicht zu einer einzelnen Header-Feldzeile kombiniert werden.

Implementierungen MÜSSEN (MUST) in der Lage sein, mehrere Header-Feldzeilen mit demselben Namen in beliebiger Kombination aus Einzelwert-pro-Zeile- und kommagetrennten Wertformaten zu verarbeiten.

Die folgenden Gruppen von Header-Feldzeilen sind alle gültig und äquivalent.

  Route: `&lt;sip:[email protected]>`
  Subject: Lunch
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Subject: Lunch

  Subject: Lunch
  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

Jeder der folgenden Blöcke ist gültig, aber sie sind nicht untereinander äquivalent.

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`,`&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

Das Format des Header-Feldwerts ist pro Header-Feldname definiert. Es ist immer entweder eine opake Sequenz von TEXT-UTF8-Oktetts oder eine Kombination aus Leerraum, Token, Trennzeichen und Zeichenketten in Anführungszeichen. Viele bestehende Header-Felder folgen dem allgemeinen Format, bei dem der Feldwert von einer Folge von durch Semikolons getrennten Parametername-Parameterwert-Paaren gefolgt wird.

     field-name: field-value *(;parameter-name=parameter-value)

Beachten Sie, dass, sofern eine beliebige Anzahl von Parameterpaaren an den Header-Feldwert angehängt werden kann, ein bestimmter Parametername nicht mehrmals erscheinen DARF (MUST NOT).

Beim Vergleich von Header-Feldern ist der Feldname nie fallunterschempfindlich. Sofern in der Definition eines bestimmten Header-Felds nicht anders angegeben, sind Feldwerte, Parameternamen und Parameterwerte nicht fallunterschempfindlich. Token sind nie fallunterschempfindlich. Sofern nicht anders angegeben, sind Werte, die als Zeichenketten in Anführungszeichen dargestellt werden, fallunterschempfindlich. Zum Beispiel ist

  Contact: `&lt;sip:[email protected]>`;expires=3600

äquivalent zu

  CONTACT: `&lt;sip:[email protected]>`;ExPiReS=3600

und

  Content-Disposition: session;handling=optional

äquivalent zu

  content-disposition: Session;HANDLING=OPTIONAL

Die folgenden beiden Header-Felder sind nicht äquivalent.

  Warning: 370 devnull "Choose a bigger pipe"
  Warning: 370 devnull "CHOOSE A BIGGER PIPE"

7.3.2 Klassifizierung von Header-Feldern

Einige Header-Felder sind nur in einer Anfrage oder nur in einer Antwort sinnvoll. Diese werden jeweils Anfrage-Header-Felder und Antwort-Header-Felder genannt. Wenn ein Header-Feld in einer Nachricht erscheint, die nicht zu seiner Kategorie passt (z. B. ein Anfrage-Header-Feld in einer Antwort), MUSS (MUST) es ignoriert werden. Abschnitt 20 definiert die Klassifizierung jedes Header-Felds.

7.3.3 Kompakte Form

SIP bietet einen Mechanismus, um gebräuchliche Header-Feldnamen in Kurzform darzustellen. Dies kann nützlich sein, wenn die Nachricht zu groß ist, um über das verfügbare Transportmedium transportiert zu werden (z. B. bei Verwendung von UDP, wenn die maximale Übertragungseinheit (MTU) überschritten wird). Diese Abkürzungen sind in Abschnitt 20 definiert. Die Kurzform DARF (MAY) jederzeit durch den langen Header-Feldnamen ersetzt werden, ohne die Semantik der Nachricht zu ändern. Der Header-Feldname DARF (MAY) in derselben Nachricht sowohl in langer als auch in kurzer Form erscheinen. Implementierungen MÜSSEN (MUST) sowohl die lange als auch die kurze Form jedes Header-Namens akzeptieren.

7.4 Rümpfe

Sofern nicht anders vermerkt, DÜRFEN (MAY) Anfragen einen Nachrichtenrumpf enthalten, einschließlich neuer Anfragen, die durch Erweiterungen dieser Spezifikation definiert werden. Die Interpretation des Rumpfs hängt von der Anfragemethode ab.

Bei Antwortnachrichten bestimmen die Anfragemethode und der Antwortstatuscode die Art und Interpretation des Nachrichtenrumpfs. Alle Antworten DÜRFEN (MAY) einen Rumpf enthalten.

7.4.1 Nachrichtenrumpf-Typ

Der Internet-Medientyp des Nachrichtenrumpfs MUSS (MUST) durch das Content-Type-Header-Feld angegeben werden. Hat der Rumpf eine Kodierung wie Komprimierung erfahren, MUSS (MUST) dies durch das Content-Encoding-Header-Feld angezeigt werden. Andernfalls MUSS (MUST) Content-Encoding weggelassen werden. Der Zeichensatz des Nachrichtenrumpfs, sofern zutreffend, wird als Teil des Content-Type-Header-Feldwerts angegeben.

Die in RFC 2046 [11] definierten „multipart“-MIME-Typen DÜRFEN (MAY) im Nachrichtenrumpf verwendet werden. Eine Implementierung, die eine Anfrage mit einem multipart-Nachrichtenrumpf sendet, MUSS (MUST), falls die entfernte Implementierung dies über ein Accept-Header-Feld ohne multipart angefordert hat, die Sitzungsbeschreibung als nicht-multipart-Nachrichtenrumpf senden.

SIP-Nachrichten DÜRFEN (MAY) einen binären Rumpf oder eine Binär-Rumpfteil enthalten. Wenn der Sender keinen expliziten charset-Parameter angibt, haben Medienuntertypen des Typs „text“ standardmäßig den Wert „UTF-8“ als charset.

7.4.2 Nachrichtenrumpf-Länge

Die Länge (in Bytes) des Rumpfs wird durch das Content-Length-Header-Feld bereitgestellt. Abschnitt 20.14 beschreibt den erforderlichen Inhalt dieses Header-Felds im Detail.

Beachten Sie, dass die „chunked“-Übertragungskodierung von HTTP/1.1 NICHT (MUST NOT) mit SIP verwendet werden darf. (Hinweis: Die Chunked-Kodierung verändert den Nachrichtenrumpf, um ihn als Reihe von Blöcken zu übertragen, von denen jeder einen eigenen Größenindikator hat.)

7.5 Rahmen von SIP-Nachrichten

Im Gegensatz zu HTTP können SIP-Implementierungen UDP oder ein anderes unzuverlässiges Datagrammprotokoll verwenden. Jedes solche Datagramm trägt eine einzelne Anfrage oder Antwort. Siehe Abschnitt 18 für Einschränkungen bei der Verwendung eines unzuverlässigen Transports.

Implementierungen, die SIP-Nachrichten über ein streamorientiertes Transportmedium verarbeiten, MÜSSEN (MUST) CRLF ignorieren, die vor der Startzeile erscheinen [H4.1].

  Um das Ende jeder SIP-Nachricht im Stream zu finden, wird der Wert des Content-Length-Header-Felds verwendet. Er ist immer vorhanden, wenn eine SIP-Nachricht über ein streamorientiertes Transportmedium gesendet wird.