10. Registrations
10 Enregistrements (Registrations)
10.1 Aperçu (Overview)
SIP fournit une fonctionnalité de découverte. Lorsqu'un utilisateur souhaite démarrer une session avec un autre utilisateur, SIP doit découvrir l'hôte actuellement joignable à l'utilisateur destinataire. Ce processus de découverte est souvent accompli par des éléments de réseau SIP tels que les serveurs proxy ou de redirection, qui reçoivent la requête et décident à qui l'envoyer en se basant sur leur connaissance de l'emplacement de l'utilisateur, et l'y envoient. À cette fin, ces éléments de réseau SIP font référence à un service abstrait appelé service de localisation, qui fournit des liaisons d'adresses pour un domaine particulier. Ces liaisons d'adresses mappent un URI SIP ou SIPS entrant (par exemple sip:[email protected]) vers un ou plusieurs URI « plus proches » de l'utilisateur souhaité (par exemple sip:[email protected]). En fin de compte, le proxy consiste à référencer un service de localisation pour l'URI passé dans la Request-URI, qui correspond à l'utilisateur destinataire.
L'enregistrement crée une liaison dans le service de localisation d'un domaine particulier, associant un URI d'adresse de référence (address-of-record) à une ou plusieurs adresses de contact. Ainsi, lorsqu'un proxy de ce domaine reçoit une requête dont la Request-URI correspond à l'adresse de référence, le proxy transfère la requête vers l'adresse de contact enregistrée pour cette adresse de référence. En général, il n'est utile d'enregistrer une adresse de référence dans le service de localisation d'un domaine que si les requêtes vers cette adresse de référence sont routées vers ce domaine. Dans la plupart des cas, cela signifie que le domaine de l'enregistrement doit correspondre au domaine dans l'URI d'adresse de référence.
Il existe de nombreuses façons d'établir le contenu du service de localisation. L'une d'elles est administrative. Dans l'exemple ci-dessus, Bob est connu pour être membre du département ingénierie via un accès à une base de données d'entreprise. Cependant, SIP fournit un mécanisme permettant aux UA de créer explicitement des liaisons. Ce mécanisme est connu sous le nom d'enregistrement.
L'enregistrement implique l'envoi d'une requête REGISTER à un type particulier d'UAS appelé registrar. Le registrar agit comme une interface frontale vers le service de localisation du domaine, lisant et écrivant des correspondances basées sur le contenu des requêtes REGISTER. Ce service de localisation est ensuite référencé par les serveurs proxy responsables du routage des requêtes vers ce domaine.
La figure 2 montre un schéma du processus d'enregistrement dans son ensemble. Notez que le registrar et le serveur proxy sont des rôles logiques qui peuvent être joués par un seul périphérique du réseau. Pour plus de clarté, la figure les sépare. De plus, les UA peuvent envoyer des requêtes via un serveur proxy pour atteindre le registrar s'ils sont deux éléments distincts.
SIP n'impose pas de mécanisme spécifique pour implémenter le service de localisation. La seule exigence est que le registrar d'un domaine DOIT pouvoir lire et écrire des données dans le service de localisation, et que le proxy ou le serveur de redirection de ce domaine DOIT pouvoir lire ces mêmes données. Le registrar PEUT être colocalisé avec un serveur proxy SIP particulier de ce domaine.
10.2 Construction de la requête REGISTER (Constructing the REGISTER Request)
Une requête REGISTER ajoute, supprime et interroge des liaisons. Une requête REGISTER peut ajouter une nouvelle liaison entre une adresse de référence et une ou plusieurs adresses de contact. La ou les adresses de contact peuvent être enregistrées pour le compte d'un tiers dûment autorisé. Un client peut également supprimer des liaisons précédentes ou interroger quelles liaisons sont actuellement placées pour l'adresse de référence.
Sauf indication contraire, la construction de la requête REGISTER et le comportement du client qui l'envoie sont identiques au comportement général de l'UAC décrit dans les sections 8.1 et 17.1.
Une requête REGISTER n'établit pas de dialogue. Un UAC PEUT inclure un champ d'en-tête Route dans une requête REGISTER basée sur un ensemble de routes préexistant décrit dans la section 8.1. Le champ d'en-tête Record-Route n'a pas de signification dans une requête ou une réponse REGISTER et DOIT être ignoré s'il est présent. En particulier, un UAC NE DOIT PAS créer un nouvel ensemble de routes en se basant sur la présence ou l'absence d'un champ d'en-tête Record-Route dans la réponse à une requête REGISTER.
Les champs d'en-tête suivants, à l'exception de Contact, DOIVENT être inclus dans une requête REGISTER. Le champ d'en-tête Contact PEUT être inclus.
Request-URI : Le Request-URI spécifie le domaine du service de localisation objet de l'enregistrement (par exemple « sip:chicago.com »). Les composants « userinfo » et « @ » de l'URI SIP NE DOIVENT PAS être présents.
To : Le champ To contient l'adresse de référence pour laquelle l'enregistrement est créé, interrogé ou modifié. Les champs To et Request-URI diffèrent généralement car le premier contient un nom d'utilisateur. Cette adresse de référence DOIT être un URI SIP ou SIPS.
From : Le champ From contient l'adresse de référence de la personne responsable de l'enregistrement. Sa valeur est la même que le champ To, sauf si la requête est un enregistrement tiers.
Call-ID : Pour tous les enregistrements envoyés à un registrar particulier, tous les enregistrements du UAC DEVRAIENT utiliser la même valeur de champ Call-ID.
CSeq : La valeur CSeq garantit un ordonnancement approprié des requêtes REGISTER. Un UA DOIT incrémenter la valeur CSeq de 1 pour chaque requête REGISTER ayant le même Call-ID.
Contact : Une requête REGISTER PEUT contenir un champ d'en-tête Contact avec zéro ou plusieurs valeurs incluant des liaisons d'adresses.
Les UA NE DOIVENT PAS envoyer un nouvel enregistrement (c'est-à-dire contenant une nouvelle valeur de champ Contact, et non une retransmission) avant de recevoir la réponse finale du registrar pour le précédent, ou avant l'expiration de la requête REGISTER précédente.
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 : Exemple REGISTER
Les paramètres de champ Contact suivants ont une signification spéciale dans une requête REGISTER.
action : Le paramètre « action » de la RFC 2543 est obsolète. Un UAC NE DEVRAIT PAS utiliser le paramètre « action ».
expires : Le paramètre « expires » indique la durée pendant laquelle le UA souhaite que la liaison reste valide. Sa valeur est un nombre indiquant un nombre de secondes. Si ce paramètre n'est pas fourni, la valeur du champ d'en-tête Expires est utilisée à la place. Les implémentations PEUVENT traiter toute valeur supérieure à 2**32-1 (4294967295 secondes, ou 136 ans) comme égale à 2**32-1. Une valeur mal formée DEVRAIT être traitée comme équivalente à 3600.
10.2.1 Ajout de liaisons (Adding Bindings)
Une requête REGISTER envoyée à un registrar contient une adresse de contact vers laquelle les requêtes SIP pour l'adresse de référence seront transférées. L'adresse de référence est contenue dans le champ To de la requête REGISTER.
La valeur du champ Contact de la requête est généralement composée d'un URI SIP ou SIPS identifiant un endpoint SIP particulier (par exemple « sip:[email protected] »), mais PEUT utiliser n'importe quel schéma d'URI. Par exemple, un UA SIP PEUT choisir d'enregistrer un numéro de téléphone (URL tel, RFC 2806) ou une adresse e-mail (URL mailto, RFC 2368) comme Contact de l'adresse de référence.
Par exemple, Carol, dont l'adresse de référence est « sip:[email protected] », enregistre auprès du registrar SIP du domaine chicago.com. Son enregistrement est ensuite utilisé par le serveur proxy du domaine chicago.com pour router les requêtes vers son adresse de référence vers son endpoint SIP.
Lorsqu'un client établit une liaison auprès d'un registrar, il PEUT envoyer des enregistrements ultérieurs incluant de nouvelles liaisons ou des modifications des liaisons existantes, selon les besoins. La réponse 2xx à la requête REGISTER contient la liste complète des liaisons enregistrées pour cette adresse de référence sur ce registrar, dans le champ d'en-tête Contact.
Si l'adresse de référence dans le champ To de la requête REGISTER est un URI SIPS, la valeur du champ Contact dans la requête DEVRAIT aussi être un URI SIPS. Un client NE DEVRAIT enregistrer un URI non-SIPS sous une adresse de référence SIPS que si la sécurité de la ressource représentée par l'adresse de contact est garantie par d'autres moyens.
L'enregistrement ne met pas à jour toutes les liaisons. Typiquement, un UA met à jour uniquement sa propre adresse de contact.
10.2.1.1 Définition de l'intervalle d'expiration des adresses de contact (Setting the Expiration Interval of Contact Addresses)
Lorsqu'un client envoie une requête REGISTER, il PEUT proposer un intervalle d'expiration indiquant la durée pendant laquelle il souhaite que l'enregistrement reste valide. (Comme décrit à la section 10.3, le registrar choisit l'intervalle réel en fonction de sa politique locale.)
Il existe deux façons pour un client d'exprimer l'intervalle d'expiration proposé : via le champ d'en-tête Expires ou le paramètre de contact « expires ». Ce dernier permet de proposer un intervalle d'expiration par liaison lorsque plusieurs liaisons sont données dans une seule requête REGISTER. Le premier propose un intervalle pour toutes les valeurs de champ Contact ne contenant pas de paramètre « expires ».
Si aucun des deux mécanismes d'expression de l'expiration proposée n'est présent dans l'enregistrement, le client indique qu'il laisse le choix au serveur.
10.2.1.2 Préférences entre adresses de contact (Preferences among Contact Addresses)
Lorsque plusieurs contacts sont envoyés dans une requête REGISTER, le UA qui enregistre a l'intention d'associer toutes les valeurs d'en-tête Contact de cette liste à l'adresse de référence dans le champ To. Cette liste PEUT être priorisée à l'aide du paramètre « q » du champ Contact. Le paramètre « q » indique la priorité relative d'une valeur d'en-tête Contact particulière par rapport aux autres liaisons de cette adresse de référence. La section 16.6 décrit comment un serveur proxy utilise cette indication de priorité.
10.2.2 Suppression de liaisons (Removing Bindings)
Bien que l'enregistrement soit un état logiciel (soft state) et expire s'il n'est pas actualisé, il PEUT être supprimé explicitement. Un client PEUT tenter d'influencer l'intervalle d'expiration choisi par le registrar comme décrit à la section 10.2.1. Les UA DEVRAIENT prendre en charge le mécanisme permettant à une liaison d'être supprimée immédiatement en spécifiant un intervalle d'expiration de « 0 » pour cette adresse de contact dans la requête REGISTER.
La valeur de champ Contact « * » propre à REGISTER s'applique à tous les enregistrements, mais NE DOIT PAS être utilisée sans un champ Expires présent avec la valeur « 0 ».
L'utilisation de la valeur de champ Contact « * » permet au UA enregistrant de supprimer toutes les liaisons associées à une adresse de référence sans connaître leur valeur exacte.
10.2.3 Obtention de liaisons (Fetching Bindings)
Toute réponse réussie à une requête REGISTER contient la liste complète des liaisons existantes, que la requête REGISTER ait inclus ou non un champ d'en-tête Contact. Une requête REGISTER sans champ d'en-tête Contact ne modifie pas la liste des liaisons.
10.2.4 Actualisation des liaisons (Refreshing Bindings)
Chaque UA est responsable de l'actualisation des liaisons qu'il a précédemment établies. Les UA NE DEVRAIENT PAS actualiser une liaison configurée par un autre UA.
La réponse 200 (OK) du registrar contient une liste de champs Contact énumérant toutes les liaisons actuelles. Le UA examine chaque adresse de contact en utilisant les règles de comparaison de la section 19.1.4 pour déterminer s'il en est le créateur. Le cas échéant, il met à jour son intervalle d'expiration en fonction du paramètre expires, ou à défaut de la valeur du champ Expires. Le UA émet ensuite une requête REGISTER pour chaque liaison avant l'expiration de l'intervalle. Plusieurs actualisations PEUVENT être combinées en une seule requête REGISTER.
Un UA DEVRAIT utiliser le même Call-ID pour tous les enregistrements au cours d'un seul cycle de démarrage. Les actualisations d'enregistrement DEVRAIENT être envoyées à la même adresse réseau que l'enregistrement d'origine, à moins qu'elles ne soient redirigées.
10.2.5 Réglage de l'horloge interne (Setting the Internal Clock)
Si la réponse à une requête REGISTER contient un champ d'en-tête Date, le client PEUT utiliser ce champ pour apprendre l'heure courante afin de régler toute horloge interne.
10.2.6 Découverte d'un registrar (Discovering a Registrar)
Les UA peuvent utiliser trois méthodes pour déterminer l'adresse d'envoi des enregistrements : la configuration, l'utilisation de l'adresse de référence, et le multicast. Un UA PEUT être configuré avec une adresse de registrar par des moyens hors de portée de cette spécification. S'il n'y a pas d'adresse configurée, le UA DEVRAIT utiliser la partie hôte de l'adresse de référence comme Request-URI et s'y adresser en utilisant le mécanisme de localisation de serveur SIP normal. Par exemple, le UA de l'utilisateur « sip:[email protected] » adresse une requête REGISTER à « sip:chicago.com ».
Enfin, un UA PEUT être configuré pour utiliser le multicast. Les enregistrements multicast sont adressés à l'adresse multicast bien connue « tous les serveurs SIP » « sip.mcast.net » (224.0.1.75 en IPv4). Aucune adresse multicast IPv6 bien connue n'est assignée ; une telle assignation sera documentée séparément si nécessaire. Les UA SIP PEUVENT écouter sur cette adresse et l'utiliser pour apprendre les emplacements d'autres utilisateurs locaux. Ils ne répondent pas à la requête.
Les enregistrements multicast peuvent être inappropriés dans certains environnements, par exemple lorsque plusieurs entreprises partagent le même réseau local.
10.2.7 Transmission d'une requête (Transmitting a Request)
Une fois la méthode REGISTER construite et la destination du message identifiée, le UAC suit les procédures de la section 8.1.2 pour transmettre la requête à la couche transaction.
Si la couche transaction renvoie une erreur de timeout parce que la requête REGISTER n'a pas produit de réponse, le UAC NE DEVRAIT PAS réessayer immédiatement l'enregistrement auprès du même registrar.
10.2.8 Réponses d'erreur (Error Responses)
Si un UA reçoit une réponse 423 (Interval Too Brief), il PEUT réessayer l'enregistrement après avoir rendu égal l'intervalle d'expiration de toutes les adresses de contact dans la requête REGISTER à la valeur de l'intervalle dans le champ d'en-tête Min-Expires de la réponse 423.
10.3 Traitement des requêtes REGISTER (Processing REGISTER Requests)
Un registrar est un UAS particulier qui répond aux requêtes REGISTER et maintient une liste de liaisons accessible aux serveurs proxy et de redirection de son domaine. Un registrar suit les sections 8.2 et 17.2 pour traiter les requêtes, mais n'accepte que les requêtes REGISTER. Un registrar NE DOIT PAS générer de réponse 6xx.
Un registrar PEUT rediriger une requête REGISTER si nécessaire. Un usage courant consiste pour un registrar écoutant sur une interface multicast à rediriger la requête REGISTER multicast vers sa propre interface unicast avec une réponse 302.
Un registrar DOIT traiter les requêtes REGISTER dans l'ordre de réception, et DOIT les traiter de manière atomique. Chaque message REGISTER DOIT être traité indépendamment de tout autre enregistrement ou changement de liaison.
Lorsqu'il reçoit une requête REGISTER, le registrar suit les étapes suivantes.
1. Le registrar examine le Request-URI et détermine s'il a accès aux liaisons du domaine indiqué. Sinon, et s'il fonctionne aussi comme proxy, il DEVRAIT transférer la requête au domaine de destination selon la section 16.
2. Le registrar DOIT traiter les valeurs du champ Require selon la section 8.2.2 pour s'assurer qu'il prend en charge les extensions requises.
3. Le registrar DEVRAIT authentifier le UAC. Si le mécanisme d'authentification n'est pas disponible, le registrar PEUT obtenir l'adresse From comme identité revendiquée par l'expéditeur.
4. Le registrar DEVRAIT déterminer si l'utilisateur authentifié est autorisé à modifier l'enregistrement de cette adresse de référence. S'il ne l'est pas, le registrar DOIT retourner 403 (Forbidden) et sauter les étapes restantes.
5. Le registrar extrait l'adresse de référence du champ To. Si elle n'est pas valide pour le domaine du Request-URI, le registrar DOIT envoyer une réponse 404 (Not Found) et sauter les étapes restantes. L'URI est ensuite converti sous forme canonique.
6. Le registrar vérifie si la requête contient un champ d'en-tête Contact. Sinon, il saute à la dernière étape. S'il y a un Contact avec la valeur spéciale « * » et un champ Expires, le registrar vérifie qu'il n'y a pas d'autre Contact ou d'expiration non nulle ; sinon la requête est invalide et le serveur DOIT retourner 400 (Invalid Request).
7. Le registrar traite chaque adresse de contact dans le champ Contact. Pour chacune, il détermine l'intervalle d'expiration demandé. Le registrar PEUT choisir un intervalle plus court que celui demandé. Il PEUT rejeter l'enregistrement avec une réponse 423 (Interval Too Brief) si l'intervalle demandé est supérieur à zéro, inférieur à une heure, et inférieur au minimum configuré. Cette réponse DOIT contenir un champ Min-Expires.
Pour chaque adresse, le registrar recherche dans la liste courante des liaisons en utilisant les règles de comparaison d'URI. S'il n'y a pas de liaison, elle est ajoutée. S'il y en a une, le registrar compare le Call-ID et le CSeq. Si le CSeq est supérieur à celui stocké, la liaison est mise à jour ou supprimée selon le cas ; sinon la mise à jour est abandonnée et la requête échoue.
Si toutes les mises à jour et ajouts réussissent, la liaison est validée (commit). Sinon, la requête échoue avec 500 et toutes les liaisons temporaires sont supprimées.
8. Le registrar renvoie une réponse 200 (OK). La réponse DOIT contenir un champ Contact énumérant toutes les liaisons actuelles, chacun avec un paramètre « expires » indiquant l'intervalle choisi. La réponse DEVRAIT contenir un champ Date.