8. Allgemeines Verhalten des User Agent (General User Agent Behavior)
8 Allgemeines Verhalten des User Agent (General User Agent Behavior)
Ein user agent (User Agent) repräsentiert ein Endsystem. Er umfasst einen user agent client (UAC), der Anfragen erzeugt, und einen user agent server (UAS), der darauf antwortet. Ein UAC kann eine Anfrage basierend auf einer externen Stimulation (der Benutzer klickt auf eine Schaltfläche oder ein Signal auf einer PSTN-Leitung) erzeugen und eine Antwort verarbeiten. Ein UAS kann eine Anfrage empfangen und eine Antwort basierend auf einer Benutzereingabe, einer externen Stimulation, dem Ergebnis der Ausführung eines Programms oder einem anderen Mechanismus erzeugen.
Wenn ein UAC eine Anfrage sendet, geht diese durch eine Reihe von Proxy-Servern, die sie an den UAS weiterleiten. Wenn der UAS eine Antwort erzeugt, wird diese an den UAC weitergeleitet.
Die UAC- und UAS-Verfahren hängen stark von zwei Faktoren ab. Erstens, ob die Anfrage oder Antwort innerhalb oder außerhalb eines dialog ist, und zweitens von der Methode der Anfrage. Dialogs werden in Abschnitt 12 ausführlich erörtert; sie stellen eine Peer-to-Peer-Beziehung zwischen User Agents dar und werden durch bestimmte SIP-Methoden wie INVITE etabliert.
In diesem Abschnitt erörtern wir die methodenunabhängigen Regeln für das UAC- und UAS-Verhalten bei der Verarbeitung von Anfragen, die außerhalb eines dialog sind. Dies umfasst natürlich Anfragen, die selbst einen dialog etablieren.
Die Sicherheitsverfahren für Anfragen und Antworten außerhalb eines dialog sind in Abschnitt 26 beschrieben. Insbesondere existieren Mechanismen, damit sich UAS und UAC gegenseitig authentifizieren. Ein begrenztes Set von Datenschutzfunktionen wird ebenfalls durch Verschlüsselung der Bodies mittels S/MIME unterstützt.
8.1 UAC-Verhalten (UAC Behavior)
Dieser Abschnitt behandelt das UAC-Verhalten außerhalb eines dialog.
8.1.1 Erzeugung der Anfrage (Generating the Request)
Eine gültige SIP-Anfrage, die von einem UAC erstellt wird, MUSS mindestens die folgenden header fields enthalten: To, From, CSeq, Call-ID, Max-Forwards und Via; alle diese header fields sind in allen SIP-Anfragen obligatorisch. Diese sechs header fields sind die grundlegenden Bausteine einer SIP-Nachricht, da sie gemeinsam die meisten kritischen Nachrichtenrouting-Dienste bereitstellen, einschließlich Adressierung der Nachrichten, Routing der Antworten, Begrenzung der Nachrichtenausbreitung, Ordnung der Nachrichten und eindeutige Identifizierung von Transaktionen. Diese header fields ergänzen die obligatorische request line, die die Methode, den Request-URI und die SIP-Version enthält.
Beispiele für außerhalb eines dialog gesendete Anfragen umfassen ein INVITE zum Aufbau einer Session (Abschnitt 13) und ein OPTIONS zum Abfragen von Fähigkeiten (Abschnitt 11).
8.1.1.1 Request-URI
Der anfängliche Request-URI der Nachricht SOLLTE (SHOULD) auf den Wert des URI im To-Feld gesetzt werden. Eine bemerkenswerte Ausnahme ist die REGISTER-Methode; das Verhalten zum Setzen des Request-URI von REGISTER ist in Abschnitt 10 angegeben. Aus Datenschutz- oder Bequemlichkeitsgründen kann es auch unerwünscht sein, diese Felder auf denselben Wert zu setzen (insbesondere wenn der originate UA erwartet, dass der Request-URI während der Übertragung geändert wird).
In bestimmten Sondersituationen kann die Anwesenheit eines vorab vorhandenen Route-Sets (pre-existing route set) den Request-URI der Nachricht beeinflussen. Ein vorab vorhandenes Route-Set ist eine geordnete Menge von URIs, die eine Kette von Servern identifizieren, an die ein UAC ausgehende Anfragen außerhalb eines dialog senden wird. Üblicherweise werden sie manuell durch den Benutzer oder Dienstanbieter auf dem UA konfiguriert oder über einen anderen Nicht-SIP-Mechanismus. Wenn ein Anbieter einen UA mit einem outbound proxy konfigurieren möchte, wird EMPFOHLEN (RECOMMENDED), dies durch Bereitstellung eines vorab vorhandenen Route-Sets mit einem einzigen URI, nämlich dem des outbound proxy, zu tun.
Wenn ein vorab vorhandenes Route-Set vorhanden ist, MÜSSEN (MUST) die in Abschnitt 12.2.1.1 detaillierten Verfahren zum Befüllen des Request-URI und des Route header field befolgt werden (auch wenn kein dialog existiert), wobei der gewünschte Request-URI als remote target URI verwendet wird.
8.1.1.2 To
Das To header field gibt zunächst den gewünschten "logischen" Empfänger der Anfrage an, oder die address-of-record des Benutzers oder der Ressource, die das Ziel dieser Anfrage ist. Dies kann, muss aber nicht, der endgültige Empfänger der Anfrage sein. Das To header field DARF (MAY) einen SIP- oder SIPS-URI enthalten, kann aber bei Bedarf auch andere URI-Schemes nutzen (z. B. tel-URL (RFC 2806 [9])). Alle SIP-Implementierungen MÜSSEN (MUST) das SIP-URI-Scheme unterstützen. Jede Implementierung, die TLS unterstützt, MUSS (MUST) das SIPS-URI-Scheme unterstützen. Das To header field erlaubt einen display name.
Ein UAC kann auf verschiedene Weisen lernen, wie das To header field für eine bestimmte Anfrage befüllt wird. Üblicherweise schlägt der Benutzer das To header field über eine menschliche Schnittstelle vor, indem er möglicherweise den URI manuell eingibt oder aus einem Adressbuch auswählt. Häufig gibt der Benutzer keinen vollständigen URI ein, sondern eine Zeichenkette aus Ziffern oder Buchstaben (z. B. "bob"). Es liegt im Ermessen des UA, zu interpretieren, wie diese Eingabe zu verstehen ist. Die Zeichenkette zur Bildung des user part eines SIP-URI zu verwenden, bedeutet, dass der UA den Namen in der Domain rechts vom At-Zeichen (@) im SIP-URI auflösen möchte (z. B. sip:[email protected]). Die Zeichenkette zur Bildung des user part eines SIPS-URI zu verwenden, bedeutet, dass der UA sicher kommunizieren möchte und der Name in der Domain rechts vom At-Zeichen aufgelöst werden muss. Die rechte Seite (RHS) ist häufig die home domain des Anfragenden, was es der home domain ermöglicht, die ausgehende Anfrage zu verarbeiten. Dies ist nützlich für Funktionen wie "Kurzwahl" (speed dial), die die Interpretation des user part in der home domain erfordern. Die tel-URL kann verwendet werden, wenn der UA die Domain, die eine vom Benutzer eingegebene Telefonnummer interpretieren soll, nicht vorgeben möchte. Vielmehr erhält jede Domain, durch die die Anfrage geht, diese Gelegenheit. Beispielsweise könnte sich ein Benutzer an einem Flughafen anmelden und Anfragen über einen outbound proxy am Flughafen senden. Wenn sie "411" eingeben (dies ist die Telefonnummer für lokale Auskunft in den USA), muss dies vom outbound proxy des Flughafens interpretiert und verarbeitet werden, nicht von der home domain des Benutzers. In diesem Fall ist tel:411 die richtige Wahl.
Eine Anfrage außerhalb eines dialog DARF KEINEN (MUST NOT) To tag enthalten; der tag im To-Feld einer Anfrage identifiziert den Peer des dialog. Da kein dialog etabliert ist, ist kein tag vorhanden.
Weitere Informationen zum To header field finden Sie in Abschnitt 20.39. Hier ist ein Beispiel für ein gültiges To header field:
To: Carol `<sip:[email protected]>`
8.1.1.3 From
Das From header field zeigt die logische Identität des Initiators der Anfrage an, möglicherweise die address-of-record des Benutzers. Wie das To header field enthält es einen URI und optional einen display name. Es wird von SIP-Elementen verwendet, um zu bestimmen, welche Verarbeitungsregeln auf eine Anfrage anzuwenden sind (z. B. automatische Anrufablehnung). Daher ist es sehr wichtig, dass der From-URI keine IP-Adressen oder den FQDN des Hosts enthält, auf dem der UA ausgeführt wird, da dies keine logischen Namen sind.
Das From header field erlaubt einen display name. Ein UAC SOLLTE (SHOULD) den display name "Anonymous" mit einem ansonsten sinnlosen, aber syntaktisch korrekten URI (z. B. sip:[email protected]) verwenden, wenn die Identität des Clients verborgen bleiben soll.
Üblicherweise wird der Wert, der das From header field in Anfragen eines bestimmten UA füllt, vom Benutzer oder den Administratoren der lokalen Domain des Benutzers vorab bereitgestellt. Wenn ein bestimmter UA von mehreren Benutzern verwendet wird, kann er umschaltbare Profile haben, die einen URI entsprechend der Identität des profilierten Benutzers enthalten. Empfänger von Anfragen können den Initiator einer Anfrage authentifizieren, um zu überprüfen, ob sie tatsächlich diejenigen sind, die ihr From header field behauptet (siehe Abschnitt 22 für Details zur Authentifizierung).
Das From-Feld MUSS (MUST) einen neuen "tag"-Parameter enthalten, der vom UAC gewählt wurde. Einzelheiten zur Wahl eines tag finden Sie in Abschnitt 19.3.
Weitere Informationen zum From header field finden Sie in Abschnitt 20.20. Beispiele:
From: "Bob" `<sips:[email protected]>` ;tag=a48s
From: sip:[email protected];tag=887s
From: Anonymous `<sip:[email protected]>`;tag=hyh8
8.1.1.4 Call-ID
Das Call-ID header field fungiert als eindeutiger Bezeichner, um eine Reihe von Nachrichten zusammenzufassen. Es MUSS (MUST) für alle Anfragen und Antworten, die von einem der beiden UA in einem dialog gesendet werden, gleich sein. Es SOLLTE (SHOULD) für jede Registrierung eines UA gleich sein.
In einer neuen, außerhalb eines dialog erstellten Anfrage MUSS (MUST) das Call-ID header field vom UAC als global eindeutiger Bezeichner in Raum und Zeit gewählt werden, sofern nicht durch methodenspezifisches Verhalten außer Kraft gesetzt. Alle SIP-UA müssen Mittel haben, um sicherzustellen, dass die Call-ID header fields, die sie erzeugen, nicht versehentlich von einem anderen UA erzeugt werden. Beachten Sie, dass, wenn Anfragen nach bestimmten Fehlerantworten, die eine Änderung der Anfrage verlangen (z. B. eine Authentifizierungsaufforderung), erneut versucht werden, diese erneuten Versuche nicht als neue Anfragen gelten und daher keine neuen Call-ID header fields benötigen; siehe Abschnitt 8.1.3.5.
Die Verwendung kryptografisch zufälliger Bezeichner (RFC 1750 [12]) bei der Erzeugung von Call-IDs wird EMPFOHLEN (RECOMMENDED). Implementierungen DÜRFEN (MAY) das Format "localid@host" verwenden. Call-IDs unterscheiden zwischen Groß- und Kleinschreibung und werden einfach byteweise verglichen.
Die Verwendung kryptografisch zufälliger Bezeichner bietet einen gewissen Schutz gegen Session-Hijacking und verringert die Wahrscheinlichkeit unbeabsichtigter Call-ID-Kollisionen.
Für die Auswahl des Call-ID header field-Wertes für eine Anfrage ist keine Bereitstellung oder menschliche Schnittstelle erforderlich.
Weitere Informationen zum Call-ID header field finden Sie in Abschnitt 20.8.
Beispiel:
Call-ID: [email protected]
8.1.1.5 CSeq
Das CSeq header field dient der Identifizierung und Ordnung von Transaktionen. Es besteht aus einer Sequenznummer und einer Methode. Die Methode MUSS (MUST) mit der der Anfrage übereinstimmen. Für nicht-REGISTER-Anfragen außerhalb eines dialog ist der Wert der Sequenznummer beliebig. Der Wert der Sequenznummer MUSS (MUST) als vorzeichenlose 32-Bit-Ganzzahl darstellbar sein und MUSS kleiner als 2**31 sein. Sofern er den obigen Richtlinien folgt, darf ein Client einen beliebigen Mechanismus zur Auswahl der CSeq header field-Werte verwenden.
Abschnitt 12.2.1.1 erörtert den Aufbau des CSeq für Anfragen innerhalb eines dialog.
Beispiel:
CSeq: 4711 INVITE
8.1.1.6 Max-Forwards
Das Max-Forwards header field dient dazu, die Anzahl der Hops zu begrenzen, die eine Anfrage auf dem Weg zu ihrem Ziel durchlaufen kann. Es besteht aus einer ganzen Zahl, die bei jedem Hop um eins dekrementiert wird. Wenn der Max-Forwards-Wert 0 erreicht, bevor die Anfrage ihr Ziel erreicht, wird sie mit einer Fehlerantwort 483 (Too Many Hops) abgelehnt.
Ein UAC MUSS (MUST) ein Max-Forwards header field in jede Anfrage einfügen, die er aussendet, mit einem Wert, der 70 sein SOLLTE (SHOULD). Diese Zahl wurde groß genug gewählt, um sicherzustellen, dass eine Anfrage in einem beliebigen SIP-Netz ohne Schleifen nicht verworfen wird, aber klein genug, um bei Auftreten einer Schleife keine zu großen Proxy-Ressourcen zu verbrauchen. Niedrigere Werte sollten mit Vorsicht und nur in Netzen verwendet werden, deren Topologie dem UA bekannt ist.
8.1.1.7 Via
Das Via header field gibt den Transport an, der für die Transaktion verwendet wird, und identifiziert die Stelle, an die die Antwort gesendet werden soll. Ein Via header field-Wert wird erst hinzugefügt, nachdem der Transport, der zur Erreichung des nächsten Hops verwendet wird, ausgewählt wurde (was die Verwendung der Verfahren aus [4] einschließen kann).
Wenn der UAC eine Anfrage erstellt, MUSS (MUST) er ein Via in diese Anfrage einfügen. Der Protokollname und die Protokollversion im header field MÜSSEN (MUST) jeweils SIP und 2.0 sein. Der Via header field-Wert MUSS (MUST) einen branch-Parameter enthalten. Dieser Parameter wird verwendet, um die durch diese Anfrage erzeugte Transaktion zu identifizieren. Dieser Parameter wird sowohl vom Client als auch vom Server verwendet.
Der branch-Parameterwert MUSS (MUST) für alle vom UA gesendeten Anfragen im Raum und in der Zeit eindeutig sein. Ausnahmen von dieser Regel sind CANCEL und ACK für nicht-2xx-Antworten. Wie unten beschrieben hat eine CANCEL-Anfrage denselben branch-Parameterwert wie die Anfrage, die sie abbricht. Wie in Abschnitt 17.1.1.3 beschrieben hat ein ACK für eine nicht-2xx-Antwort ebenfalls dieselbe branch-ID wie das INVITE, dessen Antwort er bestätigt.
Die Eindeutigkeit des branch-ID-Parameters zur Erleichterung seiner Nutzung als Transaktions-ID war kein Teil von RFC 2543.
Die von einem Element, das konform zu dieser Spezifikation ist, eingefügte branch-ID MUSS (MUST) immer mit den Zeichen "z9hG4bK" beginnen. Diese 7 Zeichen werden als magic cookie verwendet (7 wird als ausreichend erachtet, um sicherzustellen, dass eine ältere RFC-2543-Implementierung keinen solchen Wert wählen würde), damit Server, die die Anfrage empfangen, bestimmen können, dass die branch-ID auf die in dieser Spezifikation beschriebene Weise (d. h. global eindeutig) konstruiert wurde. Über diese Anforderung hinaus ist das genaue Format des branch-Tokens implementierungsdefiniert.
Die Komponenten maddr, ttl und sent-by des Via-Headers werden gesetzt, wenn die Anfrage von der Transportschicht verarbeitet wird (Abschnitt 18).
Die Via-Verarbeitung für Proxys ist in Abschnitt 16.6 Punkt 8 und Abschnitt 16.7 Punkt 3 beschrieben.
8.1.1.8 Contact
Das Contact header field stellt einen SIP- oder SIPS-URI bereit, der verwendet werden kann, um diese spezifische UA-Instanz für nachfolgende Anfragen zu kontaktieren. Das Contact header field MUSS (MUST) in jeder Anfrage vorhanden sein und genau einen SIP- oder SIPS-URI enthalten, die zu einem dialog führen kann. Für die in dieser Spezifikation definierten Methoden umfasst dies nur die INVITE-Anfrage. Für diese Anfragen ist der Geltungsbereich des Contact global. Das heißt, der Contact header field-Wert enthält den URI, unter dem der UA Anfragen empfangen möchte, und dieser URI MUSS (MUST) auch dann gültig sein, wenn er in nachfolgenden Anfragen außerhalb eines dialog verwendet wird.
Wenn der Request-URI oder der oberste Route header field-Wert einen SIPS-URI enthält, MUSS (MUST) auch das Contact header field einen SIPS-URI enthalten.
Weitere Informationen zum Contact header field finden Sie in Abschnitt 20.10.
8.1.1.9 Supported und Require
Wenn ein UAC Erweiterungen an SIP unterstützt, die vom Server auf die Antwort angewendet werden können, SOLLTE (SHOULD) er ein Supported header field in der Anfrage einfügen, das die Option-Tags (Abschnitt 19.2) für diese Erweiterungen auflistet.
Die aufgelisteten Option-Tags DÜRFEN NUR (MUST NOT) Erweiterungen referenzieren, die in standards-track-RFCs definiert sind. Dies verhindert, dass Server von Clients verlangen, herstellerdefinierte Nicht-Standard-Funktionen zu implementieren, um den Dienst zu erhalten. Von experimentellen und informativen RFCs definierte Erweiterungen sind von der Verwendung im Supported header field einer Anfrage ausdrücklich ausgeschlossen, da sie ebenfalls häufig zur Dokumentation herstellerdefinierter Erweiterungen verwendet werden.
Wenn ein UAC darauf besteht, dass ein UAS eine Erweiterung versteht, die der UAC auf die Anfrage anwendet, um sie zu verarbeiten, MUSS (MUST) er ein Require header field in die Anfrage einfügen, das den Option-Tag für diese Erweiterung auflistet. Wenn ein UAC eine Erweiterung auf die Anfrage anwendet und darauf besteht, dass alle durchlaufenen Proxys diese Erweiterung verstehen, MUSS (MUST) er ein Proxy-Require header field einfügen, das den Option-Tag auflistet.
Wie beim Supported header field DÜRFEN (MUST NOT) die Option-Tags in Require- und Proxy-Require-header fields nur Erweiterungen referenzieren, die in standards-track-RFCs definiert sind.
8.1.1.10 Zusätzliche Nachrichtenkomponenten (Additional Message Components)
Nachdem eine neue Anfrage erstellt und die oben beschriebenen header fields ordnungsgemäß konstruiert wurden, werden zusätzliche optionale header fields sowie methodenspezifische header fields hinzugefügt.
SIP-Anfragen DÜRFEN (MAY) einen MIME-kodierten message-body enthalten. Unabhängig von der Art des in einer Anfrage enthaltenen Body müssen bestimmte header fields erstellt werden, um den Inhalt des Body zu kennzeichnen. Einzelheiten zu diesen header fields finden Sie in den Abschnitten 20.11 bis 20.15.
8.1.2 Senden der Anfrage (Sending the Request)
Das Ziel der Anfrage wird dann berechnet. Sofern nicht durch eine lokale Richtlinie anders angegeben, MUSS (MUST) das Ziel durch Anwendung der in [4] beschriebenen DNS-Verfahren wie folgt bestimmt werden. Wenn das erste Element im Route-Set einen strict router anzeigte (was zur Bildung der Anfrage wie in Abschnitt 12.2.1.1 beschrieben führt), MÜSSEN (MUST) die Verfahren auf den Request-URI der Anfrage angewendet werden. Andernfalls werden die Verfahren auf den ersten Route header field-Wert in der Anfrage (falls vorhanden) oder, falls kein Route header field vorhanden ist, auf den Request-URI der Anfrage angewendet. Diese Verfahren ergeben eine geordnete Menge von Adresse, Port und Transport, die versucht werden sollen. Unabhängig davon, welcher URI als Eingabe für die Verfahren in [4] verwendet wird, MUSS (MUST) ein UAC, falls der Request-URI eine SIPS-Ressource angibt, die Verfahren in [4] so befolgen, als ob der Eingabe-URI ein SIPS-URI wäre.
Die lokale Richtlinie DARF (MAY) eine alternative Menge von zu versuchenden Zielen angeben. Wenn der Request-URI einen SIPS-URI enthält, MUSS (MUST) jedes alternative Ziel mit TLS kontaktiert werden. Darüber hinaus gibt es keine Einschränkungen für alternative Ziele, wenn die Anfrage kein Route header field enthält. Dies bietet eine einfache Alternative zu einem vorab vorhandenen Route-Set als Mittel, einen outbound proxy anzugeben. Dieser Ansatz zur Konfiguration eines outbound proxy wird jedoch NICHT EMPFOHLEN (NOT RECOMMENDED); stattdessen SOLLTE (SHOULD) ein vorab vorhandenes Route-Set mit einem einzigen URI verwendet werden. Wenn die Anfrage ein Route header field enthält, SOLLTE (SHOULD) die Anfrage an die aus ihrem obersten Wert abgeleiteten Stellen gesendet werden, darf aber an jeden Server gesendet werden, von dem der UA sicher ist, dass er die in diesem Dokument (nicht die von RFC 2543) angegebenen Route- und Request-URI-Richtlinien einhält. Insbesondere SOLLTE (SHOULD) ein mit einem outbound proxy konfigurierter UAC versuchen, die Anfrage an die im ersten Route header field-Wert angegebene Stelle zu senden, anstatt die Richtlinie zu übernehmen, alle Nachrichten an den outbound proxy zu senden.
Dies stellt sicher, dass outbound proxys, die keine Record-Route-header field-Werte hinzufügen, aus dem Pfad nachfolgender Anfragen ausscheiden. Es ermöglicht Endpunkten, die den ersten Route-URI nicht auflösen können, diese Aufgabe an einen outbound proxy zu delegieren.
Der UAC SOLLTE (SHOULD) den in [4] für zustandsbehaftete Elemente definierten Verfahren folgen und jede Adresse versuchen, bis ein Server kontaktiert wird. Jeder Versuch stellt eine neue Transaktion dar und trägt daher einen unterschiedlichen obersten Via header field-Wert mit einem neuen branch-Parameter. Darüber hinaus wird der Transportwert im Via header field auf den für den Zielserver ermittelten Transport gesetzt.
8.1.3 Verarbeitung von Antworten (Processing Responses)
Antworten werden zunächst von der Transportschicht verarbeitet und dann an die Transaktionsschicht übergeben. Die Transaktionsschicht führt ihre Verarbeitung aus und übergibt dann die Antwort an das TU. Der Großteil der Antwortverarbeitung im TU ist methodenspezifisch. Es gibt jedoch einige allgemeine, methodenunabhängige Verhaltensweisen.
8.1.3.1 Transaktionsschicht-Fehler (Transaction Layer Errors)
In einigen Fällen ist die von der Transaktionsschicht zurückgegebene Antwort keine SIP-Nachricht, sondern ein Transaktionsschicht-Fehler. Wenn ein timeout error von der Transaktionsschicht empfangen wird, MUSS (MUST) er wie der Empfang eines Statuscodes 408 (Request Timeout) behandelt werden. Wenn von der Transportschicht ein fataler Transportfehler gemeldet wird (im Allgemeinen aufgrund fatale ICMP-Fehler bei UDP oder Verbindungsfehler bei TCP), MUSS (MUST) die Bedingung als Statuscode 503 (Service Unavailable) behandelt werden.
8.1.3.2 Nicht erkannte Antworten (Unrecognized Responses)
Ein UAC MUSS (MUST) jede nicht erkannte finale Antwort als gleichwertig mit dem x00-Antwortcode dieser Klasse behandeln und MUSS (MUST) den x00-Antwortcode für alle Klassen verarbeiten können. Wenn beispielsweise ein UAC einen nicht erkannten Antwortcode 431 empfängt, kann er sicher annehmen, dass ein Problem mit seiner Anfrage vorlag, und die Antwort so behandeln, als hätte er einen Antwortcode 400 (Bad Request) erhalten. Ein UAC MUSS (MUST) jede nicht erkannte vorläufige Antwort ungleich 100 als 183 (Session Progress) behandeln. Ein UAC MUSS (MUST) die Antworten 100 und 183 verarbeiten können.
8.1.3.3 Vias
Wenn in einer Antwort mehr als ein Via header field-Wert vorhanden ist, SOLLTE (SHOULD) der UAC die Nachricht verwerfen.
Das Vorhandensein zusätzlicher Via header field-Werte vor dem Initiator der Anfrage deutet darauf hin, dass die Nachricht falsch geroutet oder möglicherweise beschädigt wurde.
8.1.3.4 Verarbeitung von 3xx-Antworten (Processing 3xx Responses)
Beim Empfang einer Redirection-Antwort (z. B. Statuscode 301) SOLLTEN (SHOULD) Clients die URIs im Contact header field verwenden, um eine oder mehrere neue Anfragen basierend auf der umgeleiteten Anfrage zu erstellen. Dieser Prozess ähnelt dem eines Proxy, der wie in Abschnitt 16.5 und 16.6 detailliert eine Rekursion auf eine 3xx-Klasse-Antwort ausführt. Ein Client beginnt mit einem initialen target set, das genau einen URI enthält, den Request-URI der ursprünglichen Anfrage. Wenn ein Client basierend auf einer 3xx-Klasse-Antwort auf diese Anfrage neue Anfragen erstellen möchte, platziert er die zu versuchenden URIs in das target set. Unter Berücksichtigung der Einschränkungen dieser Spezifikation kann ein Client auswählen, welche Contact-URIs er in das target set aufnimmt. Wie bei der Proxy-Rekursion DARF (MUST NOT) ein Client, der 3xx-Klasse-Antworten verarbeitet, einen gegebenen URI mehr als einmal in das target set aufnehmen. Wenn die ursprüngliche Anfrage einen SIPS-URI im Request-URI hatte, DARF (MAY) der Client eine Rekursion zu einem nicht-SIPS-URI wählen, SOLLTE (SHOULD) jedoch den Benutzer über die Umleitung zu einem unsicheren URI informieren.
Eine neue Anfrage kann selbst eine 3xx-Antwort empfangen, die den ursprünglichen URI als contact enthält. Zwei Stellen können so konfiguriert sein, dass sie sich gegenseitig umleiten. Das Platzieren eines beliebigen gegebenen URI nur einmal in das target set verhindert unendliche Redirection-Schleifen.
Wenn das target set wächst, DARF (MAY) der Client neue Anfragen an die URIs in beliebiger Reihenfolge erzeugen. Ein üblicher Mechanismus ist die Ordnung des Sets nach dem "q"-Parameterwert des Contact header field-Werts. Anfragen an die URIs DÜRFEN (MAY) seriell oder parallel erzeugt werden. Ein Ansatz ist die serielle Verarbeitung von Gruppen fallender q-Werte und parallele Verarbeitung der URIs in jeder q-Wert-Gruppe. Ein anderer Ansatz ist nur serielle Verarbeitung in fallender q-Wert-Reihenfolge, wobei willkürlich zwischen Contacts mit gleichem q-Wert gewählt wird.
Wenn der Kontakt mit einer Adresse in der Liste fehlschlägt (wie im folgenden Absatz definiert), geht das Element zur nächsten Adresse in der Liste über, bis die Liste erschöpft ist. Wenn die Liste erschöpft ist, ist die Anfrage fehlgeschlagen.
Fehler SOLLTEN (SHOULD) durch Fehlerantwortcodes (Codes größer als 399) erkannt werden; bei Netzwerkfehlern meldet die client transaction jeden Transportfehler an den transaction user. Beachten Sie, dass einige Antwortcodes (in 8.1.3.5 detailliert) anzeigen, dass die Anfrage erneut versucht werden kann; erneut versuchte Anfragen gelten nicht als Fehler.
Beim Empfang eines Fehlers für eine bestimmte contact address SOLLTE (SHOULD) der Client die nächste contact address versuchen. Dies umfasst die Erstellung einer neuen client transaction, um eine neue Anfrage zuzustellen.
Um eine Anfrage basierend auf einer contact address in einer 3xx-Antwort zu erstellen, MUSS (MUST) ein UAC den gesamten URI aus dem target set in den Request-URI kopieren, mit Ausnahme der URI-Parameter "method-param" und "header" (siehe Abschnitt 19.1.1 für eine Definition dieser Parameter). Er verwendet die "header"-Parameter, um header field-Werte für die neue Anfrage zu erstellen, und überschreibt die mit der umgeleiteten Anfrage verbundenen header field-Werte gemäß den Richtlinien in Abschnitt 19.1.5.
Beachten Sie, dass in einigen Fällen die im contact header field kommunizierten header fields stattdessen zu den vorhandenen request header fields in der ursprünglich umgeleiteten Anfrage hinzugefügt werden. Als allgemeine Regel gilt: Wenn das header field eine durch Kommas getrennte Werteliste akzeptiert, DARF (MAY) der neue header field-Wert zu allen vorhandenen Werten in der ursprünglich umgeleiteten Anfrage hinzugefügt werden. Wenn das header field keine mehreren Werte akzeptiert, DARF (MAY) der Wert in der ursprünglich umgeleiteten Anfrage durch den im contact header field kommunizierten header field-Wert überschrieben werden. Wenn beispielsweise eine contact address mit folgendem Wert zurückgegeben wurde:
sip:user@host?Subject=foo&Call-Info=`\`http://www.foo.com\``
Dann wird jedes Subject header field in der ursprünglich umgeleiteten Anfrage überschrieben, die HTTP-URL wird jedoch einfach zu allen vorhandenen Call-Info header field-Werten hinzugefügt.
Es wird EMPFOHLEN (RECOMMENDED), dass der UAC denselben To, From und Call-ID verwendet, die in der ursprünglich umgeleiteten Anfrage verwendet wurden, aber der UAC DARF (MAY) auch wählen, den Call-ID header field-Wert für neue Anfragen zu aktualisieren, beispielsweise.
Schließlich, sobald die neue Anfrage konstruiert ist, wird sie mit einer neuen client transaction gesendet und MUSS (MUST) daher wie in Abschnitt 8.1.1.7 beschrieben eine neue branch-ID im obersten Via-Feld haben.
In allen anderen Punkten SOLLTEN (SHOULD) die bei Empfang einer Redirection-Antwort gesendeten Anfragen die header fields und Bodies der ursprünglichen Anfrage wiederverwenden.
In einigen Fällen können Contact header field-Werte beim UAC temporär oder dauerhaft zwischengespeichert werden, abhängig vom empfangenen Statuscode und dem Vorhandensein eines Ablaufintervalls; siehe Abschnitte 21.3.2 und 21.3.3.
8.1.3.5 Verarbeitung von 4xx-Antworten (Processing 4xx Responses)
Bestimmte 4xx-Antwortcodes erfordern eine bestimmte, methodenunabhängige UA-Verarbeitung.
Wenn eine Antwort 401 (Unauthorized) oder 407 (Proxy Authentication Required) empfangen wird, SOLLTE (SHOULD) der UAC den Authentifizierungsverfahren in Abschnitt 22.2 und 22.3 folgen, um die Anfrage mit Anmeldeinformationen erneut zu versuchen.
Wenn eine Antwort 413 (Request Entity Too Large) empfangen wird (Abschnitt 21.4.11), enthielt die Anfrage einen Body, der länger war als der, den der UAS akzeptieren wollte. Falls möglich, SOLLTE (SHOULD) der UAC die Anfrage erneut versuchen, indem er den Body weglässt oder einen Body mit geringerer Länge verwendet.
Wenn eine Antwort 415 (Unsupported Media Type) empfangen wird (Abschnitt 21.4.13), enthielt die Anfrage Medientypen, die vom UAS nicht unterstützt werden. Der UAC SOLLTE (SHOULD) den Versand der Anfrage erneut versuchen, diesmal nur unter Verwendung von Inhalten mit den im Accept header field der Antwort aufgelisteten Typen, den im Accept-Encoding header field der Antwort aufgelisteten Kodierungen und den im Accept-Language der Antwort aufgelisteten Sprachen.
Wenn eine Antwort 416 (Unsupported URI Scheme) empfangen wird (Abschnitt 21.4.14), verwendete der Request-URI ein Scheme, das vom Server nicht unterstützt wird. Der Client SOLLTE (SHOULD) die Anfrage erneut versuchen, diesmal unter Verwendung eines SIP-URI.
Wenn eine Antwort 420 (Bad Extension) empfangen wird (Abschnitt 21.4.15), enthielt die Anfrage ein Require- oder Proxy-Require-header field, das einen Option-Tag für eine Funktion auflistete, die von einem Proxy oder UAS nicht unterstützt wird. Der UAC SOLLTE (SHOULD) die Anfrage erneut versuchen, diesmal unter Weglassung aller im Unsupported header field der Antwort aufgelisteten Erweiterungen.
In allen obigen Fällen wird die Anfrage durch Erstellen einer neuen Anfrage mit den entsprechenden Änderungen erneut versucht. Diese neue Anfrage stellt eine neue Transaktion dar und SOLLTE (SHOULD) denselben Call-ID-, To- und From-Wert wie die vorherige Anfrage haben, aber der CSeq muss eine neue Sequenznummer enthalten, die um eins höher ist als der vorherige Wert.
Bei anderen 4xx-Antworten, einschließlich derer, die noch definiert werden müssen, kann ein erneuter Versuch je nach Methode und Anwendungsfall möglich oder nicht möglich sein.
8.2 UAS-Verhalten (UAS Behavior)
Wenn ein UAS eine Anfrage außerhalb eines dialog verarbeitet, folgt er einem Satz methodenunabhängiger Verarbeitungsregeln. Abschnitt 12 gibt Anleitungen, wie ein UAS feststellen kann, ob eine Anfrage innerhalb oder außerhalb eines dialog ist.
Beachten Sie, dass die Anfrageverarbeitung atomar ist. Wenn eine Anfrage akzeptiert wird, MÜSSEN (MUST) alle damit verbundenen Zustandsänderungen ausgeführt werden. Wenn sie abgelehnt wird, DÜRFEN (MUST NOT) keine Zustandsänderungen ausgeführt werden.
UAS SOLLTEN (SHOULD) Anfragen in der Reihenfolge der Schritte in diesem Abschnitt verarbeiten (d. h. beginnend mit der Authentifizierung, dann Prüfung der Methode, der header fields usw. durch den Rest dieses Abschnitts).
8.2.1 Methodenprüfung (Method Inspection)
Sobald eine Anfrage authentifiziert ist (oder die Authentifizierung übersprungen wird), MUSS (MUST) der UAS die Methode der Anfrage prüfen. Wenn der UAS die Methode einer Anfrage erkennt, sie aber nicht unterstützt, MUSS (MUST) er eine 405 (Method Not Allowed)-Antwort erzeugen. Die Verfahren zur Erzeugung von Antworten sind in Abschnitt 8.2.6 beschrieben. Der UAS MUSS (MUST) auch ein Allow header field zur 405 (Method Not Allowed)-Antwort hinzufügen. Das Allow header field MUSS (MUST) die Menge der vom UAS unterstützten Methoden auflisten. Das Allow header field ist in Abschnitt 20.5 dargestellt.
Wenn die Methode eine vom Server unterstützte ist, wird die Verarbeitung fortgesetzt.
8.2.2 Header-Prüfung (Header Inspection)
Wenn ein UAS ein header field in einer Anfrage nicht versteht (d. h., das header field ist weder in dieser Spezifikation noch in einer unterstützten Erweiterung definiert), MUSS (MUST) der Server dieses header field ignorieren und die Verarbeitung der Nachricht fortsetzen. Ein UAS SOLLTE (SHOULD) jedes falsch formatierte header field ignorieren, das nicht für die Verarbeitung der Anfrage benötigt wird.
8.2.2.1 To und Request-URI
Das To header field identifiziert den ursprünglichen Empfänger der Anfrage, der durch den im From-Feld identifizierten Benutzer bestimmt wird. Der ursprüngliche Empfänger kann, muss aber nicht, der UAS sein, der die Anfrage verarbeitet, aufgrund von Anrufweiterschaltung oder anderen Proxy-Operationen. Ein UAS DARF (MAY) eine beliebige Richtlinie anwenden, um zu entscheiden, ob er Anfragen annimmt, wenn das To header field nicht die Identität des UAS ist. Es wird jedoch EMPFOHLEN (RECOMMENDED), dass ein UAS Anfragen auch dann annimmt, wenn er das URI-Scheme (z. B. tel:-URI) im To header field nicht erkennt, oder wenn das To header field nicht an einen bekannten oder aktuellen Benutzer dieses UAS adressiert ist. Wenn der UAS andererseits beschließt, die Anfrage abzulehnen, SOLLTE (SHOULD) er eine Antwort mit Statuscode 403 (Forbidden) erzeugen und zur Übertragung an die server transaction übergeben.
Der Request-URI identifiziert jedoch den UAS, der die Anfrage verarbeiten soll. Wenn der Request-URI ein Scheme verwendet, das vom UAS nicht unterstützt wird, SOLLTE (SHOULD) er die Anfrage mit einer 416 (Unsupported URI Scheme)-Antwort ablehnen. Wenn der Request-URI keine Adresse identifiziert, für die der UAS bereit ist, Anfragen anzunehmen, SOLLTE (SHOULD) er die Anfrage mit einer 404 (Not Found)-Antwort ablehnen. Typischerweise sieht ein UA, der die REGISTER-Methode verwendet, um seine address-of-record an eine bestimmte contact address zu binden, Anfragen, deren Request-URI gleich dieser contact address ist. Andere potenzielle Quellen empfangener Request-URIs umfassen die Contact header fields von Anfragen und Antworten, die vom UA gesendet wurden und dialogs etablieren oder auffrischen.
8.2.2.2 Zusammengeführte Anfragen (Merged Requests)
Wenn die Anfrage keinen tag im To header field hat, MUSS (MUST) der UAS core die Anfrage gegen laufende Transaktionen prüfen. Wenn From tag, Call-ID und CSeq genau mit denen übereinstimmen, die einer laufenden Transaktion zugeordnet sind, die Anfrage aber nicht mit dieser Transaktion übereinstimmt (basierend auf den Abgleichsregeln in Abschnitt 17.2.3), SOLLTE (SHOULD) der UAS core eine 482 (Loop Detected)-Antwort erzeugen und an die server transaction übergeben.
Dieselbe Anfrage ist mehr als einmal beim UAS angekommen, über wahrscheinlich unterschiedliche Pfade, vermutlich aufgrund von forking. Der UAS verarbeitet die zuerst empfangene dieser Anfragen und antwortet mit 482 (Loop Detected) auf den Rest.
8.2.2.3 Require
Unter der Annahme, dass der UAS entscheidet, dass er das geeignete Element zur Verarbeitung der Anfrage ist, prüft er das Require header field, falls vorhanden.
Das Require header field wird von einem UAC verwendet, um einem UAS die SIP-Erweiterungen mitzuteilen, die der UAC erwartet, dass der UAS unterstützt, um die Anfrage ordnungsgemäß zu verarbeiten. Sein Format ist in Abschnitt 20.32 beschrieben. Wenn ein UAS einen im Require header field aufgelisteten Option-Tag nicht versteht, MUSS (MUST) er mit einem Statuscode 420 (Bad Extension) antworten. Der UAS MUSS (MUST) ein Unsupported header field hinzufügen und darin die Optionen auflisten, die er aus dem Require header field der Anfrage nicht versteht.
Beachten Sie, dass Require und Proxy-Require NICHT (MUST NOT) in einer SIP-CANCEL-Anfrage oder in einer ACK-Anfrage verwendet werden dürfen, die für eine nicht-2xx-Antwort gesendet wird. Diese header fields MÜSSEN (MUST) ignoriert werden, wenn sie in diesen Anfragen vorhanden sind.
Eine ACK-Anfrage für eine 2xx-Antwort DARF NUR (MUST) die Require- und Proxy-Require-Werte enthalten, die in der ursprünglichen Anfrage vorhanden waren.
Beispiel:
UAC->UAS: INVITE sip:[email protected] SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
Dieses Verhalten stellt sicher, dass die Client-Server-Interaktion ohne Verzögerung abläuft, wenn alle Optionen von beiden Seiten verstanden werden, und nur dann verlangsamt wird, wenn Optionen (wie im obigen Beispiel) nicht verstanden werden. Für ein gut zusammenpassendes Client-Server-Paar läuft die Interaktion schnell ab und spart den Hin-und-her, der oft von Verhandlungsmechanismen benötigt wird. Darüber hinaus beseitigt es die Mehrdeutigkeit, wenn der Client Funktionen verlangt, die der Server nicht versteht. Einige Funktionen (wie Call-Handling-Felder) interessieren nur Endsysteme.
8.2.3 Inhaltsverarbeitung (Content Processing)
Unter der Annahme, dass der UAS alle vom Client benötigten Erweiterungen versteht, prüft der UAS den Body der Nachricht und die header fields, die ihn beschreiben. Wenn es Bodies gibt, deren Typ (durch Content-Type angezeigt), Sprache (durch Content-Language angezeigt) oder Kodierung (durch Content-Encoding angezeigt) nicht verstanden wird und dieser Body-Teil nicht optional ist (wie durch das Content-Disposition header field angezeigt), MUSS (MUST) der UAS die Anfrage mit einer 415 (Unsupported Media Type)-Antwort ablehnen. Die Antwort MUSS (MUST) ein Accept header field enthalten, das alle von ihm verstandenen Body-Typen auflistet, falls die Anfrage Bodies von vom UAS nicht unterstützten Typen enthielt. Wenn die Anfrage von ihm nicht verstandene Content-Kodierungen enthielt, MUSS (MUST) die Antwort ein Accept-Encoding header field enthalten, das die vom UAS verstandenen Kodierungen auflistet. Wenn die Anfrage Inhalte in vom UAS nicht verstandenen Sprachen enthielt, MUSS (MUST) die Antwort ein Accept-Language header field enthalten, das die vom UAS verstandenen Sprachen angibt. Über diese Prüfungen hinaus hängt die Verarbeitung des Body von der Methode und dem Typ ab. Einzelheiten zur Verarbeitung inhaltsbezogener header fields finden Sie in Abschnitt 7.4 sowie Abschnitten 20.11 bis 20.15.
8.2.4 Anwendung von Erweiterungen (Applying Extensions)
Ein UAS, der eine Erweiterung bei der Erzeugung der Antwort anwenden möchte, DARF ES NICHT (MUST NOT), sofern die Unterstützung dieser Erweiterung nicht im Supported header field der Anfrage angezeigt ist. Wenn die gewünschte Erweiterung nicht unterstützt wird, SOLLTE (SHOULD) der Server nur auf Basis-SIP und andere vom Client unterstützte Erweiterungen vertrauen. In seltenen Fällen, in denen der Server die Anfrage ohne die Erweiterung nicht verarbeiten kann, DARF (MAY) der Server eine 421 (Extension Required)-Antwort senden. Diese Antwort zeigt an, dass die angemessene Antwort ohne Unterstützung einer bestimmten Erweiterung nicht erzeugt werden kann. Die benötigten Erweiterungen MÜSSEN (MUST) in einem Require header field in der Antwort enthalten sein. Dieses Verhalten wird NICHT EMPFOHLEN (NOT RECOMMENDED), da es im Allgemeinen die Interoperabilität beeinträchtigt.
Alle auf eine nicht-421-Antwort angewendeten Erweiterungen MÜSSEN (MUST) in einem Require header field aufgeführt sein, das in der Antwort enthalten ist. Selbstverständlich DARF (MUST NOT) der Server Erweiterungen anwenden, die nicht im Supported header field der Anfrage aufgeführt sind. Folglich enthält das Require header field in einer Antwort nur Option-Tags, die in standards-track-RFCs definiert sind.
8.2.5 Verarbeitung der Anfrage (Processing the Request)
Unter der Annahme, dass alle Prüfungen der vorherigen Unterabschnitte bestanden wurden, wird die UAS-Verarbeitung methodenspezifisch. Abschnitt 10 behandelt die REGISTER-Anfrage, Abschnitt 11 die OPTIONS-Anfrage, Abschnitt 13 die INVITE-Anfrage und Abschnitt 15 die BYE-Anfrage.
8.2.6 Erzeugung der Antwort (Generating the Response)
Wenn ein UAS eine Antwort auf eine Anfrage erstellen möchte, folgt er den in den folgenden Unterabschnitten detaillierten allgemeinen Verfahren. Zusätzliches, für den betreffenden Antwortcode spezifisches Verhalten, das in diesem Abschnitt nicht detailliert ist, kann ebenfalls erforderlich sein.
Sobald alle mit der Erstellung einer Antwort verbundenen Verfahren abgeschlossen sind, gibt der UAS die Antwort an die server transaction zurück, von der er die Anfrage empfangen hat.
8.2.6.1 Senden einer vorläufigen Antwort (Sending a Provisional Response)
Eine weitgehend methodenunabhängige Richtlinie für die Antwortgenerierung ist, dass UAS KEINE (SHOULD NOT) vorläufige Antwort für eine nicht-INVITE-Anfrage ausgeben sollten. Vielmehr SOLLTEN (SHOULD) UAS eine finale Antwort auf eine nicht-INVITE-Anfrage so schnell wie möglich erzeugen.
Wenn eine 100 (Trying)-Antwort erzeugt wird, MUSS (MUST) jedes in der Anfrage vorhandene Timestamp header field in diese 100 (Trying)-Antwort kopiert werden. Wenn bei der Erzeugung der Antwort eine Verzögerung auftritt, SOLLTE (SHOULD) der UAS einen Verzögerungswert im Timestamp-Wert der Antwort hinzufügen. Dieser Wert MUSS (MUST) die Differenz zwischen der Sendezeit der Antwort und dem Empfang der Anfrage in Sekunden enthalten.
8.2.6.2 Header und Tags (Headers and Tags)
Das From-Feld der Antwort MUSS (MUST) gleich dem From header field der Anfrage sein. Das Call-ID header field der Antwort MUSS (MUST) gleich dem Call-ID header field der Anfrage sein. Das CSeq header field der Antwort MUSS (MUST) gleich dem CSeq-Feld der Anfrage sein. Die Via header field-Werte in der Antwort MÜSSEN (MUST) gleich den Via header field-Werten in der Anfrage sein und dieselbe Reihenfolge beibehalten.
Wenn eine Anfrage einen To tag in der Anfrage enthielt, MUSS (MUST) das To header field in der Antwort gleich dem der Anfrage sein. Wenn das To header field in der Anfrage jedoch keinen tag enthielt, MUSS (MUST) der URI im To header field in der Antwort gleich dem URI im To header field sein; darüber hinaus MUSS (MUST) der UAS dem To header field in der Antwort einen tag hinzufügen (mit Ausnahme der 100 (Trying)-Antwort, in der ein tag vorhanden sein darf (MAY)). Dies dient dazu, den antwortenden UAS zu identifizieren und kann möglicherweise ein Bestandteil einer dialog-ID werden. Derselbe tag MUSS (MUST) für alle Antworten auf diese Anfrage verwendet werden (sowohl finale als auch vorläufige, wiederum mit Ausnahme von 100 (Trying)). Die Verfahren zur Erzeugung von tags sind in Abschnitt 19.3 definiert.
8.2.7 Statusloses UAS-Verhalten (Stateless UAS Behavior)
Ein stateless UAS ist ein UAS, der keinen Transaktionszustand aufrechterhält. Er antwortet normal auf Anfragen, verwirft aber jeden Zustand, der normalerweise von einem UAS nach dem Senden einer Antwort beibehalten würde. Wenn ein stateless UAS eine Retransmission einer Anfrage empfängt, regeneriert er die Antwort und sendet sie erneut, als ob er auf die erste Instanz der Anfrage antworten würde. Ein UAS kann nur dann statuslos sein, wenn die Verarbeitung der Anfrage für diese Methode bei identischen Anfragen immer dieselbe Antwort ergibt. Dies schließt beispielsweise statuslose Registrare aus. Statuslose UAS verwenden keine Transaktionsschicht; sie empfangen Anfragen direkt von der Transportschicht und senden Antworten direkt an die Transportschicht.
Die Rolle des statuslosen UAS ist hauptsächlich notwendig, um nicht authentifizierte Anfragen zu verarbeiten, für die eine Challenge-Antwort ausgegeben wird. Wenn nicht authentifizierte Anfragen zustandsbehaftet verarbeitet würden, könnten bösartige Fluten nicht authentifizierter Anfragen große Mengen an Transaktionszustand erzeugen, die die Call-Verarbeitung in einem UAS verlangsamen oder vollständig stoppen könnten, was effektiv einen Denial-of-Service-Zustand erzeugt; siehe Abschnitt 26.1.5 für Details.
Die wichtigsten Verhaltensweisen eines statuslosen UAS sind:
o Ein stateless UAS DARF KEINE (MUST NOT) vorläufigen (1xx) Antworten senden.
o Ein stateless UAS DARF KEINE (MUST NOT) Antworten retransmitieren.
o Ein stateless UAS MUSS (MUST) ACK-Anfragen ignorieren.
o Ein stateless UAS MUSS (MUST) CANCEL-Anfragen ignorieren.
o To header tags MÜSSEN (MUST) auf statuslose Weise erzeugt werden - auf eine Weise, die für dieselbe Anfrage konsistent denselben tag erzeugt. Siehe Abschnitt 19.3 für den Aufbau von tags.
In allen anderen Punkten verhält sich ein stateless UAS genau wie ein stateful UAS. Ein UAS kann für jede neue Anfrage im zustandsbehafteten oder statuslosen Modus arbeiten.
8.3 Redirect-Server (Redirect Server)
In einigen Architekturen kann es wünschenswert sein, sich auf Redirection zu verlassen, um die Verarbeitungslast auf Proxy-Servern, die für das Routing von Anfragen zuständig sind, zu verringern und die Robustheit des Signaling-Pfads zu verbessern.
Redirection ermöglicht es Servern, die Routing-Informationen für eine Anfrage in einer Antwort an den Client zurückzuschieben, wodurch sie sich selbst aus der Schleife zusätzlicher Messaging für diese Transaktion ausschließen, während sie weiterhin helfen, das Ziel der Anfrage zu finden. Wenn der Initiator der Anfrage die Redirection empfängt, sendet er eine neue Anfrage basierend auf dem (den) empfangenen URI(s). Durch die Verbreitung von URIs vom Kern des Netzes zu seinen Rändern ermöglicht Redirection eine beträchtliche Netzwerkskalierbarkeit.
Ein redirect server ist logisch aus einer server transaction layer und einem transaction user zusammengesetzt, der Zugriff auf einen Location-Service irgendeiner Art hat (siehe Abschnitt 10 für mehr über Registrare und Location-Services). Dieser Location-Service ist effektiv eine Datenbank, die Zuordnungen zwischen einem einzelnen URI und einer Menge von einem oder mehreren alternativen Orten enthält, an denen das Ziel dieses URI gefunden werden kann.
Ein redirect server gibt keine eigenen SIP-Anfragen aus. Nach dem Empfang einer Anfrage außer CANCEL lehnt der Server die Anfrage ab oder sammelt die Liste alternativer Orte aus dem Location-Service und gibt eine finale Antwort der Klasse 3xx zurück. Für wohlgeformte CANCEL-Anfragen SOLLTE (SHOULD) er eine 2xx-Antwort zurückgeben. Diese Antwort beendet die SIP-Transaktion. Der redirect server hält den Transaktionszustand für eine gesamte SIP-Transaktion aufrecht. Es ist die Verantwortung der Clients, Weiterleitungsschleifen zwischen redirect servern zu erkennen.
Wenn ein redirect server eine 3xx-Antwort auf eine Anfrage zurückgibt, füllt er die Liste der alternativen Orte (einen oder mehrere) in das Contact header field ein. Ein "expires"-Parameter für die Contact header field-Werte DARF (MAY) ebenfalls angegeben werden, um die Lebensdauer der Contact-Daten anzuzeigen.
Das Contact header field enthält URIs, die die neuen Orte oder Benutzernamen angibt; oder es kann einfach zusätzliche Transportparameter angeben. Eine 301 (Moved Permanently)- oder 302 (Moved Temporarily)-Antwort kann auch denselben Ort und Benutzernamen wie das ursprüngliche Ziel der Anfrage angeben, aber zusätzliche Transportparameter wie einen anderen zu versuchenden Server oder eine Multicast-Adresse oder eine Änderung des SIP-Transports von UDP zu TCP (oder umgekehrt) angeben.
Redirect server DÜRFEN (MUST NOT) jedoch eine Anfrage zu einem URI umleiten, der gleich dem im Request-URI ist; stattdessen DARF (MAY) der Server, sofern der URI nicht auf sich selbst verweist, die Anfrage an den Ziel-URI proxien oder DARF (MAY) sie mit 404 ablehnen.
Wenn ein Client einen outbound proxy verwendet und dieser Proxy tatsächlich Anfragen umleitet, kann ein unendliches Redirection-Schleifenpotenzial entstehen.
Beachten Sie, dass ein Contact header field-Wert auch auf eine andere Ressource als die ursprünglich aufgerufene verweisen kann. Beispielsweise kann ein mit einem PSTN-Gateway verbundener SIP-Anruf eine spezielle Informationsansage wie "The number you have dialed has been changed" zustellen müssen.
Ein Contact-Antwort-header field kann einen beliebigen geeigneten URI enthalten, der angibt, wo die angerufene Partei erreichbar ist, nicht beschränkt auf SIP-URIs. Zum Beispiel kann es URIs für Telefon, Fax oder irc (falls definiert) oder eine mailto:-URL (RFC 2368 [32]) enthalten. Abschnitt 26.4.4 erörtert Auswirkungen und Einschränkungen der Umleitung eines SIPS-URI zu einem nicht-SIPS-URI.
Der "expires"-Parameter eines Contact header field-Werts gibt an, wie lange der URI gültig ist. Der Wert des Parameters ist eine Zahl, die Sekunden angibt. Wenn dieser Parameter nicht angegeben wird, bestimmt der Wert des Expires header field, wie lange der URI gültig ist. Fehlerhaft formatierte Werte SOLLTEN (SHOULD) als gleich 3600 behandelt werden.
Dies bietet ein maßvolles Maß an Abwärtskompatibilität mit RFC 2543, die absolute Zeiten in diesem header field erlaubte. Wenn eine absolute Zeit empfangen wird, wird sie als fehlerhaft behandelt und standardmäßig auf 3600 gesetzt.
Redirect server MÜSSEN (MUST) nicht verstandene Funktionen (einschließlich nicht erkannter header fields, unbekannter Option-Tags in Require oder sogar Methodennamen) ignorieren und mit der Redirection der betreffenden Anfrage fortfahren.