10. Registrations
10 Registrierungen (Registrations)
10.1 Überblick (Overview)
SIP bietet eine Ermittlungsfunktion (Discovery). Wenn ein Benutzer eine Sitzung mit einem anderen Benutzer beginnen möchte, muss SIP den aktuell erreichbaren Host für den Zielbenutzer ermitteln. Dieser Ermittlungsprozess wird häufig von SIP-Netzelementen wie Proxy- oder Redirect-Servern erreicht, die die Anfrage empfangen, anhand ihrer Kenntnis des Benutzerstandorts entscheiden, wohin sie gesendet wird, und sie dorthin senden. Zu diesem Zweck beziehen sich diese SIP-Netzelemente auf einen abstrakten Dienst namens Location Service, der Adressbindungen für eine bestimmte Domain bereitstellt. Diese Adressbindungen ordnen einen eingehenden SIP- oder SIPS-URI (z. B. sip:[email protected]) einem oder mehreren URIs zu, die dem gewünschten Benutzer „näher“ sind (z. B. sip:[email protected]). Letztlich besteht das Proxy-Verhalten darin, einen Location Service für den in der Request-URI übergebenen URI zu referenzieren, der dem Zielbenutzer entspricht.
Die Registrierung erstellt eine Bindung im Location Service einer bestimmten Domain, die einen Address-of-Record-URI mit einer oder mehreren Kontaktadressen verknüpft. Wenn also ein Proxy dieser Domain eine Anfrage empfängt, deren Request-URI mit dem Address-of-Record übereinstimmt, leitet der Proxy die Anfrage an die für diesen Address-of-Record registrierte Kontaktadresse weiter. Im Allgemeinen ist es nur sinnvoll, einen Address-of-Record im Location Service einer Domain zu registrieren, wenn Anfragen an diesen Address-of-Record an diese Domain geroutet werden. In den meisten Fällen bedeutet dies, dass die Domain der Registrierung mit der Domain im Address-of-Record-URI übereinstimmen muss.
Es gibt viele Möglichkeiten, den Inhalt des Location Service zu erstellen. Eine davon ist administrativ. In obigem Beispiel ist bekannt, dass Bob über den Zugriff auf eine Unternehmensdatenbank Mitglied der Abteilung Engineering ist. SIP bietet jedoch einen Mechanismus, mit dem UAs Bindungen explizit erstellen können. Dieser Mechanismus ist als Registrierung bekannt.
Die Registrierung umfasst das Senden einer REGISTER-Anfrage an eine spezielle Art von UAS, die als Registrar bezeichnet wird. Der Registrar fungiert als Front-End zum Location Service der Domain und liest und schreibt Zuordnungen basierend auf dem Inhalt der REGISTER-Anfragen. Dieser Location Service wird dann von den Proxy-Servern referenziert, die für das Routing von Anfragen an diese Domain zuständig sind.
Die Abbildung 2 zeigt ein Schema des gesamten Registrierungsprozesses. Beachten Sie, dass Registrar und Proxy-Server logische Rollen sind, die von einem einzigen Netzwerkgerät gespielt werden können. Zur Klarheit sind sie in der Abbildung getrennt. Zudem können UAs eine Anfrage über einen Proxy-Server senden, um den Registrar zu erreichen, wenn sie zwei verschiedene Elemente sind.
SIP schreibt keinen speziellen Mechanismus zur Implementierung des Location Service vor. Die einzige Anforderung ist, dass der Registrar einer Domain in der Lage SEIN MUSS, Daten in den Location Service zu lesen und zu schreiben, und dass der Proxy oder Redirect-Server dieser Domain in der Lage SEIN MUSS, dieselben Daten zu lesen.
10.2 Aufbau der REGISTER-Anfrage (Constructing the REGISTER Request)
Eine REGISTER-Anfrage fügt hinzu, entfernt und fragt Bindungen ab. Sie kann eine neue Bindung zwischen einem Address-of-Record und einer oder mehreren Kontaktadressen hinzufügen. Die Kontaktadressen können im Auftrag eines ordnungsgemäß autorisierten Drittanbieters registriert werden. Ein Client kann auch zuvor vorhandene Bindungen entfernen oder abfragen, welche Bindungen derzeit für den Address-of-Record platziert sind.
Sofern nicht anders angegeben, ist der Aufbau der REGISTER-Anfrage und das Verhalten des Clients, der sie sendet, identisch mit dem allgemeinen UAC-Verhalten aus den Abschnitten 8.1 und 17.1.
Eine REGISTER-Anfrage etabliert keinen Dialog. Ein UAC DARF ein Route-Header-Feld in einer REGISTER-Anfrage basierend auf einem vorab existierenden Routensatz einfügen. Das Record-Route-Header-Feld hat in einer REGISTER-Anfrage oder -antwort keine Bedeutung und MUSS ignoriert werden, falls vorhanden.
Die folgenden Header-Felder MÜSSEN in einer REGISTER-Anfrage enthalten sein (außer Contact). Das Contact-Header-Feld DARF enthalten sein.
Request-URI: Gibt die Domain des Location Service an, auf die sich die Registrierung bezieht. Die Komponenten „userinfo“ und „@“ des SIP-URI DÜRFEN NICHT vorhanden sein.
To: Enthält den Address-of-Record, für den die Registrierung erstellt, abgefragt oder geändert wird. To und Request-URI unterscheiden sich im Allgemeinen, da der erstere einen Benutzernamen enthält. Dieser Address-of-Record MUSS ein SIP- oder SIPS-URI sein.
From: Enthält den Address-of-Record der Person, die für die Registrierung verantwortlich ist. Sein Wert ist derselbe wie das To-Feld, sofern es sich nicht um eine Drittanbieterregistrierung handelt.
Call-ID: Für alle Registrierungen, die an einen bestimmten Registrar gesendet werden, SOLLTEN alle Registrierungen desselben UAC denselben Call-ID-Wert verwenden.
CSeq: Gewährleistet die richtige Reihenfolge der REGISTER-Anfragen. Ein UA MUSS den CSeq-Wert für jede REGISTER-Anfrage mit derselben Call-ID um 1 erhöhen.
Contact: Eine REGISTER-Anfrage DARF ein Contact-Header-Feld mit null oder mehr Werten enthalten, die Adressbindungen umfassen.
UAs DÜRFEN KEINE neue Registrierung senden (d. h. mit einem neuen Contact-Wert, nicht eine Retransmission), bevor die endgültige Antwort des Registrars auf die vorherige eingegangen ist oder die vorherige abgelaufen ist.
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| [email protected]
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+ [email protected]
carol
Figure 2: REGISTER example
Die folgenden Contact-Header-Parameter haben eine besondere Bedeutung in einer REGISTER-Anfrage.
action: Der „action“-Parameter aus RFC 2543 ist veraltet. Ein UAC SOLLTE den „action“-Parameter nicht verwenden.
expires: Gibt die Dauer an, für die der UA die Bindung gültig halten möchte. Ist kein „expires“-Parameter vorhanden, wird der Wert des Expires-Header-Felds verwendet. Werte über 2**32-1 werden als 2**32-1 behandelt. Ein ungültig formatierter Wert SOLLTE wie 3600 behandelt werden.
10.2.1 Hinzufügen von Bindungen (Adding Bindings)
Eine an einen Registrar gesendete REGISTER-Anfrage enthält eine Kontaktadresse, an die SIP-Anfragen für den Address-of-Record weitergeleitet werden. Der Address-of-Record befindet sich im To-Feld der Anfrage.
Der Contact-Wert ist im Allgemeinen ein SIP- oder SIPS-URI, der einen bestimmten SIP-Endpunkt identifiziert, DARF aber ein beliebiges URI-Schema verwenden.
Wenn der Address-of-Record im To-Feld ein SIPS-URI ist, SOLLTE auch der Contact-Wert ein SIPS-URI sein. Ein Client SOLLTE einen Nicht-SIPS-URI nur dann unter einem SIPS-Address-of-Record registrieren, wenn die Sicherheit der Ressource anderweitig garantiert ist.
Die Registrierung aktualisiert nicht alle Bindungen. Typischerweise aktualisiert ein UA nur seine eigene Kontaktadresse.
10.2.1.1 Festlegen des Ablaufintervalls von Kontaktadressen (Setting the Expiration Interval of Contact Addresses)
Ein Client kann bei einer REGISTER-Anfrage ein vorgeschlagenes Ablaufintervall angeben. Dazu dienen das Expires-Header-Feld oder der „expires“-Contact-Parameter. Letzterer erlaubt pro Bindung ein Intervall, wenn mehrere Bindungen in einer Anfrage angegeben sind.
10.2.1.2 Präferenzen zwischen Kontaktadressen (Preferences among Contact Addresses)
Werden in einer REGISTER-Anfrage mehrere Kontakte gesendet, so beabsichtigt der registrierende UA, alle Contact-Werte der Liste dem Address-of-Record zuzuordnen. Die Liste kann mit dem „q“-Parameter des Contact-Felds priorisiert werden.
10.2.2 Entfernen von Bindungen (Removing Bindings)
Obwohl die Registrierung ein Soft State ist und ohne Aktualisierung abläuft, kann sie explizit entfernt werden. Ein Client kann das Ablaufintervall „0“ für eine Kontaktadresse angeben, um eine sofortige Löschung zu veranlassen. Der spezielle Contact-Wert „*“ gilt für alle Registrierungen, DARF aber nur mit einem Expires-Feld mit Wert „0“ verwendet werden.
10.2.3 Abrufen von Bindungen (Fetching Bindings)
Jede erfolgreiche Antwort auf eine REGISTER-Anfrage enthält die vollständige Liste der vorhandenen Bindungen, unabhängig davon, ob die REGISTER-Anfrage ein Contact-Feld enthielt. Eine REGISTER-Anfrage ohne Contact-Feld ändert die Liste der Bindungen nicht.
10.2.4 Aktualisieren von Bindungen (Refreshing Bindings)
Jeder UA ist verantwortlich für die Aktualisierung der Bindungen, die er zuvor etabliert hat. Ein UA SOLLTE keine Bindung aktualisieren, die von einem anderen UA konfiguriert wurde. Die 200 (OK)-Antwort des Registrars enthält eine Liste aller aktuellen Bindungen. Der UA prüft anhand der Vergleichsregeln aus Abschnitt 19.1.4 jede Kontaktadresse und aktualisiert deren Ablaufzeit. Danach gibt der UA für jede Bindung vor deren Ablauf eine REGISTER-Anfrage aus.
10.2.5 Einstellen der internen Uhr (Setting the Internal Clock)
Wenn die Antwort auf eine REGISTER-Anfrage ein Date-Header-Feld enthält, DARF der Client dieses Feld nutzen, um die aktuelle Zeit zu erfahren und eine interne Uhr einzustellen.
10.2.6 Ermitteln eines Registrars (Discovering a Registrar)
UAs können drei Methoden verwenden, um die Adresse für das Senden von Registrierungen zu bestimmen: Konfiguration, Verwendung des Address-of-Record und Multicast. Ist keine Adresse konfiguriert, SOLLTE der UA die Host-Komponente des Address-of-Record als Request-URI verwenden und dorthin mit dem normalen SIP-Server-Lokalisierungsmechanismus adressieren.
10.2.7 Übertragen einer Anfrage (Transmitting a Request)
Nach dem Aufbau der REGISTER-Methode und der Identifizierung des Nachrichtenziels befolgt der UAC die Verfahren aus Abschnitt 8.1.2, um die Anfrage an die Transaktionsebene zu übergeben. Wenn die Transaktionsebene wegen Fehlens einer Antwort einen Timeout zurückgibt, SOLLTE der UAC die Registrierung beim selben Registrar nicht sofort wiederholen.
10.2.8 Fehlerantworten (Error Responses)
Erhält ein UA eine 423 (Interval Too Brief)-Antwort, DARF er die Registrierung wiederholen, nachdem er das Ablaufintervall aller Kontaktadressen auf den Wert im Min-Expires-Header-Feld der 423-Antwort gesetzt hat.
10.3 Verarbeitung von REGISTER-Anfragen (Processing REGISTER Requests)
Ein Registrar ist ein spezieller UAS, der auf REGISTER-Anfragen antwortet und eine Liste von Bindungen für Proxys und Redirect-Server seiner Domain vorhält. Er befolgt die Abschnitte 8.2 und 17.2, akzeptiert aber nur REGISTER-Anfragen. Ein Registrar DARF KEINE 6xx-Antwort generieren.
Ein Registrar MUSS REGISTER-Anfragen in Empfangsreihenfolge und atomar verarbeiten. Bei Erhalt einer REGISTER-Anfrage führt der Registrar die folgenden Schritte durch:
1. Prüfung des Request-URI auf Zuständigkeit; bei Nichtzuständigkeit ggf. Weiterleitung als Proxy.
2. Verarbeitung des Require-Header-Felds (Abschnitt 8.2.2).
3. Authentifizierung des UAC (Abschnitt 22).
4. Prüfung der Autorisierung; bei fehlender Berechtigung 403 (Forbidden).
5. Extraktion des Address-of-Record aus To; bei ungültig 404 (Not Found); anschließend Kanonisierung.
6. Prüfung auf Contact-Feld; Sonderfall „*“ mit Expires 0.
7. Verarbeitung jedes Kontakts: Bestimmung des Ablaufintervalls, optional Kürzung, ggf. 423 (Interval Too Brief) mit Min-Expires. Vergleich und Aktualisierung vorhandener Bindungen anhand Call-ID und CSeq.
8. Rückgabe einer 200 (OK)-Antwort mit allen aktuellen Bindungen und „expires“-Parameter, ggf. Date-Feld.