19. Gemeinsame Nachrichtenbestandteile (Common Message Components)

Es gibt bestimmte Bestandteile von SIP-Nachrichten, die an verschiedenen Stellen in SIP-Nachrichten (und manchmal außerhalb davon) auftreten und einer separaten Erörterung wert sind.

19.1 SIP- und SIPS-URI (SIP and SIPS Uniform Resource Indicators)

Ein SIP- oder SIPS-URI identifiziert eine Kommunikationsressource. Wie alle URIs können SIP- und SIPS-URIs auf Webseiten, in E-Mail-Nachrichten oder auf gedruckten Dokumenten platziert werden. Sie enthalten ausreichende Informationen, um eine Kommunikationssitzung mit der Ressource zu initiieren und aufrechtzuerhalten.

Beispiele für Kommunikationsressourcen umfassen:

  o  einen Benutzer eines Onlinedienstes

  o  ein Erscheinungsbild an einem Mehrleitungstelefon

  o  ein Postfach auf einem Nachrichtensystem

  o  eine PSTN-Nummer auf einem Gateway-Dienst

  o  eine Gruppe (wie „sales" oder „helpdesk") in einer Organisation

Ein SIPS-URI gibt an, dass die Ressource sicher kontaktiert werden soll. Dies bedeutet insbesondere, dass zwischen dem UAC und der Domäne, die den URI besitzt, TLS verwendet werden muss. Von dort aus werden sichere Kommunikationen verwendet, um den Benutzer zu erreichen, wobei der spezifische Sicherheitsmechanismus von der Richtlinie der Domäne abhängt. Jede durch einen SIP-URI beschriebene Ressource kann zu einem SIPS-URI „hochgestuft" werden, indem einfach das Schema geändert wird, sofern man mit dieser Ressource sicher kommunizieren möchte.

19.1.1 Bestandteile des SIP- und SIPS-URI (SIP and SIPS URI Components)

Die Schemen „sip:" und „sips:" folgen den Richtlinien der RFC 2396 [5]. Sie verwenden eine ähnliche Form wie die mailto-URL und ermöglichen die Angabe von SIP-Anforderungs-Headerfeldern und des SIP-Nachrichtenrumpfs. Dies ermöglicht die Angabe von Betreff, Medientyp oder Dringlichkeit von Sitzungen, die unter Verwendung eines URIs auf einer Webseite oder in einer E-Mail-Nachricht gestartet werden. Die formale Syntax eines SIP- oder SIPS-URI ist in Abschnitt 25 dargestellt. Ihre allgemeine Form im Falle eines SIP-URI lautet:

  sip:user:password@host:port;uri-parameters?headers

Das Format eines SIPS-URI ist dasselbe, außer dass das Schema „sips" anstelle von sip ist. Diese Token und einige der Token in ihren Erweiterungen haben folgende Bedeutungen:

  user: Der Bezeichner einer bestimmten Ressource auf dem adressierten Host. Der Begriff „host" bezieht sich in diesem Kontext häufig auf eine Domäne. Der „userinfo" eines URI besteht aus diesem user-Feld, dem password-Feld und dem folgenden @-Zeichen. Der userinfo-Teil eines URI ist optional und KANN fehlen, wenn der Zielhost keinen Benutzerbegriff hat oder wenn der Host selbst die identifizierte Ressource ist. Wenn das @-Zeichen in einem SIP- oder SIPS-URI vorhanden ist, DARF das user-Feld NICHT leer sein.

      Wenn der adressierte Host Telefonnummern verarbeiten kann, beispielsweise ein Internet-Telefonie-Gateway, KANN ein in RFC 2806 [9] definiertes telephone-subscriber-Feld verwendet werden, um das user-Feld zu füllen. Es gibt besondere Escape-Regeln für die Kodierung von telephone-subscriber-Feldern in SIP- und SIPS-URIs, die in Abschnitt 19.1.2 beschrieben sind.

  password: Ein mit dem Benutzer verbundenes Passwort. Obwohl die Syntax des SIP- und SIPS-URI das Vorhandensein dieses Feldes zulässt, wird seine Verwendung NICHT EMPFOHLEN, da die Übergabe von Authentifizierungsinformationen im Klartext (wie URIs) sich in nahezu allen Fällen, in denen sie verwendet wurde, als Sicherheitsrisiko erwiesen hat. Beispielsweise führt das Transportieren einer PIN in diesem Feld zur Preisgabe der PIN.

      Beachten Sie, dass das password-Feld nur eine Erweiterung des user-Teils ist. Implementierungen, die dem password-Teil des Feldes keine besondere Bedeutung beimessen wollen, KÖNNEN „user:password" einfach als eine einzelne Zeichenfolge behandeln.

  host: Der Host, der die SIP-Ressource bereitstellt. Der host-Teil enthält entweder einen vollqualifizierten Domänennamen oder eine numerische IPv4- oder IPv6-Adresse. Die Verwendung der Form des vollqualifizierten Domänennamens wird nach Möglichkeit EMPFOHLEN.

  port: Die Portnummer, an die die Anforderung gesendet werden soll.

  URI-Parameter: Parameter, die eine aus dem URI konstruierte Anforderung beeinflussen.

     URI-Parameter werden nach der hostport-Komponente hinzugefügt und durch Semikolons getrennt.

     URI-Parameter haben die Form:

        parameter-name "=" parameter-value

     Obwohl eine beliebige Anzahl von URI-Parametern in einen URI aufgenommen werden kann, DARF ein bestimmter parameter-name NICHT mehr als einmal erscheinen.

     Dieser erweiterbare Mechanismus umfasst die Parameter transport, maddr, ttl, user, method und lr.

     Der transport-Parameter bestimmt den zu verwendenden Transportmechanismus für das Senden von SIP-Nachrichten, wie in [4] angegeben. SIP kann ein beliebiges Netzwerktransportprotokoll verwenden. Es sind Parameternamen für UDP (RFC 768 [14]), TCP (RFC 761 [15]) und SCTP (RFC 2960 [16]) definiert. Für einen SIPS-URI MUSS der transport-Parameter einen zuverlässigen Transport angeben.

     Der maddr-Parameter gibt die Adresse des Servers an, der für diesen Benutzer kontaktiert werden soll, und überschreibt jede aus dem host-Feld abgeleitete Adresse. Wenn ein maddr-Parameter vorhanden ist, gelten die port- und transport-Komponenten des URI für die im maddr-Parameterwert angegebene Adresse. [4] beschreibt die entsprechende Interpretation von transport, maddr und hostport, um die Zieladresse, den Port und den Transport für das Senden einer Anforderung zu erhalten.

     Das maddr-Feld wurde als einfache Form des Loose-Source-Routings verwendet. Es ermöglicht einem URI, einen Proxy anzugeben, der auf dem Weg zum Ziel durchquert werden muss. Die fortgesetzte Verwendung des maddr-Parameters auf diese Weise wird dringend missbilligt (die Mechanismen, die sie ermöglichen, sind veraltet). Implementierungen sollten stattdessen den in diesem Dokument beschriebenen Route-Mechanismus verwenden und bei Bedarf einen vorab vorhandenen Routensatz festlegen (siehe Abschnitt 8.1.1.1). Dies stellt einen vollständigen URI bereit, um den zu durchquerenden Knoten zu beschreiben.

     Der ttl-Parameter bestimmt den Time-to-Live-Wert (TTL) des UDP-Multicast-Pakets und DARF NUR verwendet werden, wenn maddr eine Multicast-Adresse ist und das Transportprotokoll UDP ist. Um beispielsweise einen Anruf an [email protected] unter Verwendung von Multicast an 239.255.255.1 mit einem ttl von 15 anzugeben, würde der folgende URI verwendet:

        sip:[email protected];maddr=239.255.255.1;ttl=15

     Die Menge der gültigen telephone-subscriber-Zeichenfolgen ist eine Teilmenge der gültigen user-Zeichenfolgen. Der URI-Parameter user existiert, um Telefonnummern von Benutzernamen zu unterscheiden, die zufällig wie Telefonnummern aussehen. Wenn die user-Zeichenfolge eine als telephone-subscriber formatierte Telefonnummer enthält, SOLLTE der user-Parameterwert „phone" vorhanden sein. Selbst ohne diesen Parameter DÜRFEN Empfänger von SIP- und SIPS-URIs den Teil vor dem @ als Telefonnummer interpretieren, sofern die lokalen Beschränkungen für den Namensraum des Benutzernamens dies zulassen.

     Die Methode der aus dem URI konstruierten SIP-Anforderung kann mit dem method-Parameter angegeben werden.

     Der lr-Parameter, sofern vorhanden, zeigt an, dass das für diese Ressource zuständige Element die in diesem Dokument spezifizierten Routing-Mechanismen implementiert. Dieser Parameter wird in den URIs verwendet, die Proxys in Record-Route-Headerfeldwerten ablegen, und kann in URIs eines vorab vorhandenen Routensatzes erscheinen.

     Dieser Parameter wird verwendet, um Abwärtskompatibilität mit Systemen zu erreichen, die die strikten Routing-Mechanismen der RFC 2543 und der rfc2543bis-Entwürfe bis bis-05 implementieren. Ein Element, das sich darauf vorbereitet, eine Anforderung basierend auf einem URI zu senden, der diesen Parameter nicht enthält, kann annehmen, dass das empfangende Element striktes Routing implementiert, und die Nachricht neu formatieren, um die Informationen im Request-URI zu erhalten.

     Da der uri-parameter-Mechanismus erweiterbar ist, MÜSSEN SIP-Elemente alle uri-Parameter, die sie nicht verstehen, stillschweigend ignorieren.

  Header: Headerfelder, die in eine aus dem URI konstruierte Anforderung aufgenommen werden sollen.

     SIP-Anforderungs-Headerfelder können mit dem „?"-Mechanismus in einem URI angegeben werden. Headernamen und -werte werden als durch kaufmännische Und-Zeichen getrennte hname = hvalue-Paare kodiert. Der besondere hname „body" zeigt an, dass der zugehörige hvalue der Nachrichtenrumpf der SIP-Anforderung ist.

Tabelle 1 fasst die Verwendung der SIP- und SIPS-URI-Bestandteile basierend auf dem Kontext zusammen, in dem der URI erscheint. Die Spalte „external" beschreibt URIs, die irgendwo außerhalb einer SIP-Nachricht erscheinen, beispielsweise auf einer Webseite oder einer Visitenkarte. Einträge mit „m" sind erforderlich, solche mit „o" sind optional und solche mit „-" sind nicht zulässig. Elemente, die URIs verarbeiten, SOLLTEN alle nicht zulässigen Bestandteile ignorieren, falls sie vorhanden sind. Die zweite Spalte gibt den Standardwert eines optionalen Elements an, falls es fehlt. „--" zeigt an, dass das Element entweder nicht optional ist oder keinen Standardwert hat.

URIs in Contact-Headerfeldern haben unterschiedliche Einschränkungen, je nachdem, in welchem Kontext das Headerfeld erscheint. Ein Satz gilt für Nachrichten, die Dialoge herstellen und aufrechterhalten (INVITE und seine 200 (OK)-Antwort). Der andere gilt für Registrierungs- und Umleitungsnachrichten (REGISTER, seine 200 (OK)-Antwort und 3xx-Klasse-Antworten auf eine beliebige Methode).

19.1.2 Zeichen-Escape-Anforderungen (Character Escaping Requirements)

                                                   dialog
                                      reg./redir. Contact/
          default  Req.-URI  To  From  Contact   R-R/Route  external

user -- o o o o o o password -- o o o o o o host -- m m m m m m port (1) o - - o o o user-param ip o o o o o o method INVITE - - - - - o maddr-param -- o - - o o o ttl-param 1 o - - o - o transp.-param (2) o - - o o o lr-param -- o - - - o o other-param -- o o o o o o headers -- - - - o - o

(1): Der Standard-Portwert hängt vom Transport und Schema ab. Der Standard ist 5060 für sip: mit UDP, TCP oder SCTP. Der Standard ist 5061 für sip: mit TLS über TCP und sips: über TCP.

(2): Der Standardtransport hängt vom Schema ab. Für sip: ist es UDP. Für sips: ist es TCP.

Tabelle 1: Verwendung und Standardwerte von URI-Bestandteilen für SIP-Headerfeldwerte, Request-URI und Referenzen

SIP folgt den Anforderungen und Richtlinien der RFC 2396 [5] bei der Definition des Zeichensatzes, der in einem SIP-URI escaped werden muss, und verwendet dessen „%" HEX HEX-Mechanismus zum Escapen. Auszug aus RFC 2396 [5]:

  Die Menge der innerhalb einer bestimmten URI-Komponente tatsächlich reservierten Zeichen wird von dieser Komponente definiert. Im Allgemeinen ist ein Zeichen reserviert, wenn sich die Semantik des URI ändert, wenn das Zeichen durch seine escapete US-ASCII-Kodierung ersetzt wird [5]. Die ausgeschlossenen US-ASCII-Zeichen (RFC 2396 [5]), wie Leerzeichen und Steuerzeichen sowie Zeichen, die als URI-Trennzeichen verwendet werden, MÜSSEN ebenfalls escaped werden. URIs DÜRFEN keine unescapeten Leerzeichen und Steuerzeichen enthalten.

Für jede Komponente definiert die Menge der gültigen BNF-Erweiterungen genau, welche Zeichen unescapet erscheinen dürfen. Alle anderen Zeichen MÜSSEN escaped werden.

Beispielsweise ist „@" nicht in der Zeichenmenge der user-Komponente enthalten, daher muss der Benutzer „j@s0n" mindestens das @-Zeichen kodieren, wie in „j%40s0n".

Die Erweiterung der hname- und hvalue-Token des Abschnitts 25 zeigt, dass alle URI-reservierten Zeichen in Headernamen und -werten escaped werden müssen.

Der telephone-subscriber-Teilsatz der user-Komponente hat besondere Escape-Erwägungen. Die Menge der nicht reservierten Zeichen in der telephone-subscriber-Beschreibung der RFC 2806 [9] enthält eine Reihe von Zeichen in verschiedenen Syntaxelementen, die beim Verwenden in SIP-URIs escaped werden müssen. Jedes Zeichen, das in einem telephone-subscriber erscheint und nicht in einer Erweiterung der BNF für die user-Regel erscheint, MUSS escaped werden.

Beachten Sie, dass Zeichen-Escaping in der host-Komponente eines SIP- oder SIPS-URI nicht zulässig ist (das %-Zeichen ist in seiner Erweiterung nicht gültig). Dies wird sich wahrscheinlich in Zukunft ändern, sobald die Anforderungen für internationalisierte Domänennamen festgelegt sind. Aktuelle Implementierungen DÜRFEN NICHT versuchen, die Robustheit zu verbessern, indem sie empfangene escapte Zeichen in der host-Komponente wörtlich als äquivalent zu ihren nicht escapten Gegenstücken behandeln. Das zur Erfüllung der IDN-Anforderungen erforderliche Verhalten kann erheblich anders sein.

19.1.3 Beispiele für SIP- und SIPS-URI (Example SIP and SIPS URIs)

sip:[email protected] sip:alice:[email protected];transport=tcp sips:[email protected]?subject=project%20x&priority=urgent sip:+1-212-555-1212:[email protected];user=phone sips:[email protected] sip:[email protected] sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=[email protected]

Der Wert des user-Feldes des letzten URI-Beispiels oben ist „alice;day=tuesday". Die oben definierten Escape-Regeln ermöglichen es dem Semikolon, in diesem Feld unescapet zu erscheinen. Für die Zwecke dieses Protokolls ist dieses Feld opaque. Die Struktur seines Wertes ist nur für das für diese Ressource zuständige SIP-Element nützlich.

19.1.4 URI-Vergleich (URI Comparison)

Einige Operationen dieser Spezifikation müssen bestimmen, ob zwei SIP- oder SIPS-URI äquivalent sind. Diese Spezifikation verlangt, dass Registrare die Bindings des Contact-URI in einer REGISTER-Anforderung vergleichen (siehe Abschnitt 10.3). SIP- und SIPS-URI werden gemäß folgenden Regeln auf Gleichheit verglichen:

  o  Ein SIP-URI und ein SIPS-URI sind niemals äquivalent.

  o  Der Vergleich des userinfo von SIP- und SIPS-URI ist groß-/kleinschreibungssensitiv. Dies schließt userinfo ein, das ein Passwort enthält oder als telephone-subscriber formatiert ist. Der Vergleich aller anderen URI-Bestandteile ist nicht groß-/kleinschreibungssensitiv, sofern nicht ausdrücklich anders definiert.

  o  Die Reihenfolge von Parametern und Headerfeldern ist beim Vergleich von SIP- und SIPS-URI nicht signifikant.

  o  Zeichen, die nicht in der „reservierten" Menge sind (siehe RFC 2396 [5]), sind äquivalent zu ihrer „%" HEX HEX-Kodierung.

  o  Eine aus einer DNS-Suche des Hostnamens resultierende IP-Adresse ist nicht gleich diesem Hostnamen.

  o  Damit zwei URI gleich sind, müssen die Bestandteile user, password, host und port übereinstimmen.

     Ein URI, dem der user-Bestandteil fehlt, stimmt nicht mit einem URI überein, der ihn enthält. Ein URI, dem der password-Bestandteil fehlt, stimmt nicht mit einem URI überein, der ihn enthält.

     Ein URI, der einen Bestandteil mit Standardwert weglässt, stimmt nicht mit einem URI überein, der diesen Bestandteil explizit mit seinem Standardwert enthält. Beispielsweise stimmt ein URI, der den optionalen port-Bestandteil weglässt, nicht mit einem URI überein, der explizit Port 5060 deklariert. Dies gilt ebenso für die Bestandteile transport-parameter, ttl-parameter, user-parameter und method.

        Die Definition von sip:user@host als nicht äquivalent zu sip:user@host:5060 ist eine Änderung gegenüber RFC 2543. Bei der Ableitung einer Adresse aus einem URI wird erwartet, dass äquivalente URIs äquivalente Adressen ergeben. Der URI sip:user@host:5060 wird immer zu Port 5060 aufgelöst. Der URI sip:user@host kann über den in [4] detailliert beschriebenen DNS-SRV-Mechanismus zu anderen Ports aufgelöst werden.

  o  Die uri-parameter-Bestandteile des URI werden wie folgt verglichen.

     -  Jeder uri-parameter, der in beiden URI erscheint, muss übereinstimmen.

     -  Ein uri-parameter user, ttl oder method, der nur in einem der URI erscheint, stimmt niemals überein, selbst wenn er einen Standardwert enthält.

     -  Ein URI, der den maddr-Parameter enthält, stimmt nicht mit einem URI überein, der den maddr-Parameter nicht enthält.

     -  Alle anderen uri-parameter, die nur in einem der URI erscheinen, werden beim Vergleich der URI ignoriert.

  o  Die header-Bestandteile eines URI werden niemals ignoriert. Vorhandene header-Bestandteile müssen in beiden URI erscheinen und übereinstimmen, damit die URI übereinstimmen. Die Abgleichsregeln sind für jedes Headerfeld in Abschnitt 20 definiert.

Die URI in jedem der folgenden Sätze sind äquivalent.

sip:%[email protected];transport=TCP sip:[email protected];Transport=tcp

sip:[email protected] sip:[email protected];newparam=5 sip:[email protected];security=on

sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com

sip:[email protected]?subject=project%20x&priority=urgent sip:[email protected]?priority=urgent&subject=project%20x

Die URI in jedem der folgenden Sätze sind nicht äquivalent.

SIP:[email protected];Transport=udp (unterschiedlicher Benutzername) sip:[email protected];Transport=UDP

sip:[email protected] (könnte zu einem anderen Port aufgelöst werden) sip:[email protected]:5060

sip:[email protected] (könnte zu einem anderen Transport aufgelöst werden) sip:[email protected];transport=udp

sip:[email protected] (könnte zu einem anderen Port und Transport aufgelöst werden) sip:[email protected]:6000;transport=tcp

sip:[email protected] (unterschiedliche header-Bestandteile) sip:[email protected]?Subject=next%20meeting

sip:[email protected] (selbst wenn dies die Auflösung von sip:[email protected] phone21.boxesbybob.com ist)

Beachten Sie, dass Gleichheit nicht transitiv ist.

  o  sip:[email protected] und sip:[email protected];security=on sind äquivalent

  o  sip:[email protected] und sip:[email protected];security=off sind äquivalent

  o  sip:[email protected];security=on und
     sip:[email protected];security=off sind nicht äquivalent

19.1.5 Bilden von Anforderungen aus einem URI (Forming Requests from a URI)

Implementierungen müssen vorsichtig sein, wenn sie Anforderungen direkt aus URIs konstruieren. URIs aus Visitenkarten, Webseiten oder sogar internen Protokollquellen (wie registrierte Kontakte) können unangemessene Headerfelder oder Rumpfteile enthalten.

Implementierungen MÜSSEN die bereitgestellten transport-, maddr-, ttl- oder user-Parameter in den Request-URI der konstruierten Anforderung aufnehmen. Wenn der URI einen method-Parameter enthält, MUSS dessen Wert als Methode der Anforderung verwendet werden. Der method-Parameter DARF NICHT im Request-URI platziert werden. Unbekannte URI-Parameter MÜSSEN im Request-URI der Nachricht platziert werden.

Implementierungen SOLLTEN das Vorhandensein von header- oder body-Bestandteilen im URI als Hinweis behandeln, dass sie in die Nachricht aufgenommen werden sollen, und komponentenweise wählen, ob sie dieser Anforderung nachkommen.

Implementierungen SOLLTEN NICHT auf diese offensichtlich gefährlichen Headerfelder reagieren: From, Call-ID, CSeq, Via und Record-Route.

Implementierungen SOLLTEN NICHT auf angeforderte Route-Headerfeldwerte reagieren, um nicht als unbewusste Agenten in einem bösartigen Angriff zu dienen.

Implementierungen SOLLTEN NICHT auf Anforderungen von Headerfeldern reagieren, die ihre eigene Position oder Fähigkeiten falsch bewerben könnten. Dies umfasst Accept, Accept-Encoding, Accept-Language, Allow, Contact (bei Verwendung in einem Dialog), Organization, Supported und User-Agent.

Implementierungen SOLLTEN die Genauigkeit der angeforderten deskriptiven Headerfelder einschließlich Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date und Timestamp validieren.

Wenn eine durch Konstruieren einer Nachricht aus einem bestimmten URI gebildete Anforderung keine gültige SIP-Anforderung ist, ist der URI ungültig. Implementierungen DÜRFEN NICHT mit dem Senden der Anforderung fortfahren. Stattdessen SOLLTEN sie die angemessenen Maßnahmen für einen ungültigen URI im Kontext ergreifen, in dem er aufgetreten ist.

  Eine konstruierte Anforderung kann auf viele Arten ungültig sein. Dies umfasst, ohne darauf beschränkt zu sein, Headerfeld-Syntaxfehler, ungültige Kombinationen von URI-Parametern oder falsche Beschreibungen des Nachrichtenrumpfs.

Das Senden einer aus einem bestimmten URI gebildeten Anforderung kann Fähigkeiten erfordern, die der Implementierung nicht zur Verfügung stehen. Beispielsweise kann der URI die Verwendung eines nicht implementierten Transports oder einer Erweiterung angeben. Implementierungen SOLLTEN den Versand dieser Anforderungen verweigern, anstatt sie an ihre Fähigkeiten anzupassen. Implementierungen DÜRFEN KEINE Anforderungen senden, die Erweiterungen erfordern, die sie nicht unterstützen.

  Beispielsweise können solche Anforderungen durch das Vorhandensein eines Require-Headerparameters oder eines method-URI-Parameters mit einem unbekannten oder explizit nicht unterstützten Wert gebildet werden.

19.1.6 In Beziehung setzen von SIP-URI und tel-URL (Relating SIP URIs and tel URLs)

Wenn eine tel-URL (RFC 2806 [9]) in einen SIP- oder SIPS-URI konvertiert wird, wird der gesamte telephone-subscriber-Teil der tel-URL (einschließlich Parameter) in den userinfo-Teil des SIP- oder SIPS-URI platziert.

Somit wird tel:+358-555-1234567;postd=pp22 zu

  sip:+358-555-1234567;[email protected];user=phone

oder sips:+358-555-1234567;postd=[email protected];user=phone

aber NICHT

  sip:[email protected];postd=pp22;user=phone

oder

  sips:[email protected];postd=pp22;user=phone

Im Allgemeinen ergeben äquivalente „tel"-URLs, die auf diese Weise in SIP- oder SIPS-URI konvertiert werden, nicht notwendigerweise äquivalente SIP- oder SIPS-URI. Der userinfo von SIP- und SIPS-URI wird als groß-/kleinschreibungssensitive Zeichenfolge verglichen. Unterschiede in den nicht groß-/kleinschreibungssensitiven Teilen einer tel-URL oder die Neuanordnung von tel-URL-Parametern beeinflussen die Äquivalenz der tel-URL nicht, beeinflussen aber die Äquivalenz der daraus gebildeten SIP-URI.

Zum Beispiel sind

  tel:+358-555-1234567;postd=pp22
  tel:+358-555-1234567;POSTD=PP22

äquivalent, aber

  sip:+358-555-1234567;[email protected];user=phone
  sip:+358-555-1234567;[email protected];user=phone

sind es nicht.

Ebenso sind

  tel:+358-555-1234567;postd=pp22;isub=1411
  tel:+358-555-1234567;isub=1411;postd=pp22

äquivalent, aber

  sip:+358-555-1234567;postd=pp22;[email protected];user=phone
  sip:+358-555-1234567;isub=1411;[email protected];user=phone

sind es nicht.

Um dieses Problem zu mildern, SOLLTEN Elemente, die das telephone-subscriber-Feld bilden, das im userinfo-Teil eines SIP- oder SIPS-URI platziert wird, alle nicht groß-/kleinschreibungssensitiven Teile des telephone-subscriber in Kleinbuchstaben falten und die telephone-subscriber-Parameter in lexikografischer Reihenfolge der Parameternamen anordnen, mit Ausnahme von isdn-subaddress und post-dial, die zuerst und in dieser Reihenfolge erscheinen. (Alle Bestandteile außer zukünftigen tel-URL-Erweiterungen sind so definiert, dass sie ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden.)

Wenn dieser Empfehlung gefolgt wird, werden sowohl

  tel:+358-555-1234567;postd=pp22
  tel:+358-555-1234567;POSTD=PP22

  zu

    sip:+358-555-1234567;[email protected];user=phone

und sowohl

    tel:+358-555-1234567;tsp=a.b;phone-context=5
    tel:+358-555-1234567;phone-context=5;tsp=a.b

  zu

    sip:+358-555-1234567;phone-context=5;[email protected];user=phone

19.2 Option-Tags (Option Tags)

Ein Option-Tag ist ein eindeutiger Bezeichner, der verwendet wird, um eine neue Option (Erweiterung) in SIP anzugeben. Diese Tags werden in den Headerfeldern Require (Abschnitt 20.32), Proxy-Require (Abschnitt 20.29), Supported (Abschnitt 20.37) und Unsupported (Abschnitt 20.40) verwendet. Beachten Sie, dass diese Optionen als Parameter in diesen Headerfeldern in der Form option-tag = token erscheinen (siehe Abschnitt 25 für die Definition von token).

Option-Tags werden in Standards-Track-RFCs definiert. Dies ist eine Änderung gegenüber früheren Praktiken, die eingeführt wurde, um die kontinuierliche Interoperabilität zwischen Anbietern sicherzustellen (siehe die Erörterungen in den Abschnitten 20.32 und 20.37). Ein IANA-Register für Option-Tags wird zur leichten Referenzierung verwendet.

19.3 Tags (Tags)

Der Parameter „tag" wird in den Headerfeldern To und From von SIP-Nachrichten verwendet. Er dient als allgemeiner Mechanismus zur Identifizierung von Dialogen, die die Kombination aus Call-ID und zwei Tags (je eine) jedes Dialogteilnehmers sind. Wenn ein UA eine Anforderung außerhalb eines Dialogs sendet, enthält sie nur ein From-Tag und stellt die „Hälfte" der Dialog-ID bereit. Der Dialog wird durch eine Antwort vervollständigt, die jeweils die zweite Hälfte im To-Headerfeld liefert. SIP-Anforderungen können verzweigt werden, was die Herstellung mehrerer Dialoge aus einer einzigen Anforderung ermöglicht. Dies erklärt auch die Notwendigkeit einer Dialog-ID von beiden Seiten. Ohne den Beitrag des Empfängers kann der Anrufer die mehreren aus einer einzigen Anforderung hergestellten Dialoge nicht eindeutig unterscheiden.

Wenn ein Tag von einem UA zur Einfügung in eine Anforderung oder Antwort generiert wird, MUSS es global eindeutig und kryptografisch zufällig mit mindestens 32 Bit Entropie sein. Als Konsequenz dieser Auswahlanforderung platziert ein UA ein Tag im From-Header eines INVITE, das sich von dem Tag unterscheidet, das es im To-Header einer Antwort auf genau diesen INVITE platziert. Dies ist notwendig, damit ein UA sich selbst zu einer Sitzung einladen kann (ein häufiger Fall von „Hairpinning" in einem PSTN-Gateway). Ebenso haben zwei INVITE für unterschiedliche Anrufe unterschiedliche From-Tags, und zwei Antworten für unterschiedliche Anrufe haben unterschiedliche To-Tags.

Zusätzlich zur Anforderung der globalen Eindeutigkeit ist der Tag-Generierungsalgorithmus implementierungsspezifisch. Tags sind in fehlertoleranten Systemen nützlich, in denen die Dialogwiederherstellung auf einem Ersatzserver nach einem Ausfall erforderlich ist. Ein UAS kann ein Tag so wählen, dass der Sicherungsserver die Anforderung als Teil eines Dialogs auf dem ausgefallenen Server erkennen kann und daher entscheiden kann, zu versuchen, diesen Dialog und den damit verbundenen anderen Zustand wiederherzustellen.