19. Composants de message communs (Common Message Components)

Il existe certains composants des messages SIP qui apparaissent à divers endroits dans les messages SIP (et parfois à l'extérieur de ceux-ci) qui méritent une discussion séparée.

19.1 Indicateurs de ressources uniformes SIP et SIPS (SIP and SIPS Uniform Resource Indicators)

Un URI SIP ou SIPS identifie une ressource de communication. Comme tous les URI, les URI SIP et SIPS peuvent être placés dans des pages web, des messages électroniques ou des documents imprimés. Ils contiennent suffisamment d'informations pour initier et maintenir une session de communication avec la ressource.

Les exemples de ressources de communication incluent ce qui suit :

  o  un utilisateur d'un service en ligne

  o  une apparition sur un téléphone multiligne

  o  une boîte aux lettres sur un système de messagerie

  o  un numéro PSTN sur un service de passerelle

  o  un groupe (tel que « sales » ou « helpdesk ») dans une organisation

Un URI SIPS spécifie que la ressource doit être contactée de manière sécurisée. Cela signifie, en particulier, que TLS doit être utilisé entre le UAC et le domaine qui possède l'URI. À partir de là, des communications sécurisées sont utilisées pour atteindre l'utilisateur, le mécanisme de sécurité spécifique dépendant de la politique du domaine. Toute ressource décrite par un URI SIP peut être « mise à niveau » vers un URI SIPS en changeant simplement le schéma, si l'on souhaite communiquer avec cette ressource de manière sécurisée.

19.1.1 Composants des URI SIP et SIPS (SIP and SIPS URI Components)

Les schémas « sip: » et « sips: » suivent les directives de la RFC 2396 [5]. Ils utilisent une forme similaire à l'URL mailto, permettant la spécification de champs d'en-tête de requête SIP et du corps du message SIP. Cela permet de spécifier l'objet, le type de média ou l'urgence des sessions initiées en utilisant un URI sur une page web ou dans un message électronique. La syntaxe formelle d'un URI SIP ou SIPS est présentée à la section 25. Sa forme générale, dans le cas d'un URI SIP, est :

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

Le format d'un URI SIPS est le même, sauf que le schéma est « sips » au lieu de sip. Ces jetons, et certains des jetons dans leurs expansions, ont les significations suivantes :

  user : L'identifiant d'une ressource particulière sur l'hôte adressé. Le terme « host » dans ce contexte fait fréquemment référence à un domaine. Le « userinfo » d'un URI est composé de ce champ user, du champ password et du signe @ qui les suit. La partie userinfo d'un URI est optionnelle et PEUT être absente lorsque l'hôte de destination n'a pas de notion d'utilisateurs ou lorsque l'hôte lui-même est la ressource identifiée. Si le signe @ est présent dans un URI SIP ou SIPS, le champ user NE DOIT PAS être vide.

      Si l'hôte adressé peut traiter les numéros de téléphone, par exemple une passerelle de téléphonie Internet, un champ telephone-subscriber défini dans la RFC 2806 [9] PEUT être utilisé pour remplir le champ user. Il existe des règles d'échappement spéciales pour l'encodage des champs telephone-subscriber dans les URI SIP et SIPS décrites à la section 19.1.2.

  password : Un mot de passe associé à l'utilisateur. Bien que la syntaxe de l'URI SIP et SIPS permette la présence de ce champ, son utilisation N'EST PAS RECOMMANDÉE, car le passage d'informations d'authentification en texte clair (telles que des URI) s'est avéré être un risque de sécurité dans presque tous les cas où il a été utilisé. Par exemple, transporter un numéro PIN dans ce champ expose le PIN.

      Notez que le champ password n'est qu'une extension de la partie user. Les implémentations ne souhaitant pas donner de signification particulière à la partie password du champ PEUVENT simplement traiter « user:password » comme une chaîne unique.

  host : L'hôte fournissant la ressource SIP. La partie host contient soit un nom de domaine pleinement qualifié, soit une adresse IPv4 ou IPv6 numérique. L'utilisation de la forme de nom de domaine pleinement qualifié est RECOMMANDÉE dans la mesure du possible.

  port : Le numéro de port où la requête doit être envoyée.

  Paramètres URI : Paramètres affectant une requête construite à partir de l'URI.

     Les paramètres URI sont ajoutés après le composant hostport et sont séparés par des points-virgules.

     Les paramètres URI prennent la forme :

        parameter-name "=" parameter-value

     Même si un nombre arbitraire de paramètres URI peut être inclus dans un URI, un parameter-name donné NE DOIT PAS apparaître plus d'une fois.

     Ce mécanisme extensible inclut les paramètres transport, maddr, ttl, user, method et lr.

     Le paramètre transport détermine le mécanisme de transport à utiliser pour l'envoi des messages SIP, tel que spécifié dans [4]. SIP peut utiliser n'importe quel protocole de transport réseau. Des noms de paramètres sont définis pour UDP (RFC 768 [14]), TCP (RFC 761 [15]) et SCTP (RFC 2960 [16]). Pour un URI SIPS, le paramètre transport DOIT indiquer un transport fiable.

     Le paramètre maddr indique l'adresse du serveur à contacter pour cet utilisateur, remplaçant toute adresse dérivée du champ host. Lorsqu'un paramètre maddr est présent, les composants port et transport de l'URI s'appliquent à l'adresse indiquée dans la valeur du paramètre maddr. [4] décrit l'interprétation appropriée du transport, du maddr et du hostport afin d'obtenir l'adresse, le port et le transport de destination pour l'envoi d'une requête.

     Le champ maddr a été utilisé comme une forme simple de routage à source libre. Il permet à un URI de spécifier un proxy qui doit être traversé vers la destination. La poursuite de l'utilisation du paramètre maddr de cette manière est fortement découragée (les mécanismes qui l'activent sont obsolètes). Les implémentations devraient plutôt utiliser le mécanisme Route décrit dans ce document, en établissant un ensemble de routes préexistant si nécessaire (voir la section 8.1.1.1). Cela fournit un URI complet pour décrire le nœud à traverser.

     Le paramètre ttl détermine la valeur de durée de vie (time-to-live) du paquet UDP multicast et NE DOIT être utilisé que si maddr est une adresse multicast et que le protocole de transport est UDP. Par exemple, pour spécifier un appel à [email protected] utilisant le multicast vers 239.255.255.1 avec un ttl de 15, l'URI suivant serait utilisé :

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

     L'ensemble des chaînes telephone-subscriber valides est un sous-ensemble des chaînes user valides. Le paramètre URI user existe pour distinguer les numéros de téléphone des noms d'utilisateur qui ressemblent par hasard à des numéros de téléphone. Si la chaîne user contient un numéro de téléphone formaté comme un telephone-subscriber, la valeur de paramètre user « phone » DOIT être présente. Même sans ce paramètre, les destinataires d'URI SIP et SIPS PEUVENT interpréter la partie avant le @ comme un numéro de téléphone si les restrictions locales sur l'espace de noms du nom d'utilisateur le permettent.

     La méthode de la requête SIP construite à partir de l'URI peut être spécifiée avec le paramètre method.

     Le paramètre lr, lorsqu'il est présent, indique que l'élément responsable de cette ressource implémente les mécanismes de routage spécifiés dans ce document. Ce paramètre sera utilisé dans les URI que les proxys placent dans les valeurs de champ d'en-tête Record-Route, et peut apparaître dans les URI d'un ensemble de routes préexistant.

     Ce paramètre est utilisé pour obtenir la compatibilité ascendante avec les systèmes implémentant les mécanismes de routage strict de la RFC 2543 et les brouillons rfc2543bis jusqu'à bis-05. Un élément se préparant à envoyer une requête basée sur un URI ne contenant pas ce paramètre peut supposer que l'élément récepteur implémente le routage strict et reformater le message pour préserver les informations dans le Request-URI.

     Puisque le mécanisme uri-parameter est extensible, les éléments SIP DOIVENT ignorer silencieusement tout uri-paramètre qu'ils ne comprennent pas.

  En-têtes : Champs d'en-tête à inclure dans une requête construite à partir de l'URI.

     Les champs d'en-tête dans la requête SIP peuvent être spécifiés avec le mécanisme « ? » dans un URI. Les noms et valeurs d'en-tête sont codés en paires hname = hvalue séparées par des esperluettes. Le hname spécial « body » indique que la hvalue associée est le corps du message de la requête SIP.

Le tableau 1 résume l'utilisation des composants d'URI SIP et SIPS en fonction du contexte dans lequel l'URI apparaît. La colonne externe décrit les URI apparaissant n'importe où à l'extérieur d'un message SIP, par exemple sur une page web ou une carte de visite. Les entrées marquées « m » sont obligatoires, celles marquées « o » sont optionnelles et celles marquées « - » ne sont pas autorisées. Les éléments traitant les URI DEVRAIENT ignorer tout composant non autorisé s'ils sont présents. La deuxième colonne indique la valeur par défaut d'un élément optionnel s'il est absent. « -- » indique que l'élément n'est soit pas optionnel, soit n'a pas de valeur par défaut.

Les URI dans les champs d'en-tête Contact ont des restrictions différentes selon le contexte dans lequel le champ d'en-tête apparaît. Un ensemble s'applique aux messages qui établissent et maintiennent des dialogues (INVITE et sa réponse 200 (OK)). L'autre s'applique aux messages d'enregistrement et de redirection (REGISTER, sa réponse 200 (OK), et réponses de classe 3xx à toute méthode).

19.1.2 Exigences d'échappement de caractères (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) : La valeur de port par défaut dépend du transport et du schéma. La valeur par défaut est 5060 pour sip: utilisant UDP, TCP ou SCTP. La valeur par défaut est 5061 pour sip: utilisant TLS sur TCP et sips: sur TCP.

(2) : Le transport par défaut dépend du schéma. Pour sip:, c'est UDP. Pour sips:, c'est TCP.

Tableau 1 : Utilisation et valeurs par défaut des composants d'URI pour les valeurs de champ d'en-tête SIP, Request-URI et références

SIP suit les exigences et directives de la RFC 2396 [5] lors de la définition de l'ensemble des caractères qui doivent être échappés dans un URI SIP, et utilise son mécanisme « % » HEX HEX pour l'échappement. Extrait de la RFC 2396 [5] :

  L'ensemble des caractères réellement réservés au sein de tout composant d'URI donné est défini par ce composant. En général, un caractère est réservé si la sémantique de l'URI change si le caractère est remplacé par son encodage US-ASCII échappé [5]. Les caractères US-ASCII exclus (RFC 2396 [5]), tels que les espaces et caractères de contrôle et les caractères utilisés comme délimiteurs d'URI, DOIVENT également être échappés. Les URI NE DOIVENT PAS contenir d'espaces et de caractères de contrôle non échappés.

Pour chaque composant, l'ensemble des expansions BNF valides définit exactement quels caractères peuvent apparaître non échappés. Tous les autres caractères DOIVENT être échappés.

Par exemple, « @ » n'est pas dans l'ensemble des caractères du composant user, donc l'utilisateur « j@s0n » doit avoir au moins le signe @ encodé, comme dans « j%40s0n ».

L'expansion des jetons hname et hvalue de la section 25 montre que tous les caractères réservés d'URI dans les noms et valeurs de champ d'en-tête DOIVENT être échappés.

Le sous-ensemble telephone-subscriber du composant user a des considérations d'échappement spéciales. L'ensemble des caractères non réservés dans la description telephone-subscriber de la RFC 2806 [9] contient un certain nombre de caractères dans divers éléments de syntaxe qui doivent être échappés lorsqu'ils sont utilisés dans des URI SIP. Tout caractère apparaissant dans un telephone-subscriber qui n'apparaît pas dans une expansion de la BNF pour la règle user DOIT être échappé.

Notez que l'échappement de caractères n'est pas autorisé dans le composant host d'un URI SIP ou SIPS (le caractère % n'est pas valide dans son expansion). Cela devrait probablement changer à l'avenir à mesure que les exigences pour les noms de domaine internationalisés seront finalisées. Les implémentations actuelles NE DOIVENT PAS tenter d'améliorer la robustesse en traitant les caractères échappés reçus dans le composant host comme équivalents littéralement à leur contrepartie non échappée. Le comportement requis pour répondre aux exigences IDN peut être significativement différent.

19.1.3 Exemples d'URI SIP et SIPS (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]

La valeur du champ user de l'exemple d'URI le plus récent ci-dessus est « alice;day=tuesday ». Les règles d'échappement définies ci-dessus permettent au point-virgule d'apparaître non échappé dans ce champ. Pour les besoins de ce protocole, ce champ est opaque. La structure de sa valeur n'est utile que pour l'élément SIP responsable de cette ressource.

19.1.4 Comparaison d'URI (URI Comparison)

Certaines opérations de cette spécification nécessitent de déterminer si deux URI SIP ou SIPS sont équivalents. Cette spécification exige que les registraires comparent les liaisons de l'URI Contact dans une requête REGISTER (voir la section 10.3). Les URI SIP et SIPS sont comparés pour l'égalité selon les règles suivantes :

  o  Un URI SIP et un URI SIPS ne sont jamais équivalents.

  o  La comparaison de l'userinfo des URI SIP et SIPS est sensible à la casse. Cela inclut l'userinfo contenant un mot de passe ou formaté comme un telephone-subscriber. La comparaison de tous les autres composants de l'URI n'est pas sensible à la casse, sauf si elle est définie explicitement autrement.

  o  L'ordre des paramètres et des champs d'en-tête n'est pas significatif dans la comparaison des URI SIP et SIPS.

  o  Les caractères non dans l'ensemble « réservé » (voir la RFC 2396 [5]) sont équivalents à leur encodage « % » HEX HEX.

  o  Une adresse IP résultant d'une recherche DNS du nom d'hôte n'est pas égale à ce nom d'hôte.

  o  Pour que deux URI soient égaux, les composants user, password, host et port doivent correspondre.

     Un URI omettant le composant user ne correspond pas à un URI qui l'inclut. Un URI omettant le composant password ne correspond pas à un URI qui l'inclut.

     Un URI omettant un composant ayant une valeur par défaut ne correspond pas à un URI incluant explicitement ce composant avec sa valeur par défaut. Par exemple, un URI omettant le composant port facultatif ne correspond pas à un URI déclarant explicitement le port 5060. Il en va de même pour les composants transport-parameter, ttl-parameter, user-parameter et method.

        Le fait de définir sip:user@host comme non équivalent à sip:user@host:5060 est un changement par rapport à la RFC 2543. Lors de la dérivation d'une adresse à partir d'un URI, des URI équivalents sont censés donner des adresses équivalentes. L'URI sip:user@host:5060 est toujours résolu vers le port 5060. L'URI sip:user@host peut être résolu vers d'autres ports via le mécanisme DNS SRV détaillé dans [4].

  o  Les composants uri-parameter de l'URI sont comparés comme suit.

     -  Tout uri-parameter apparaissant dans les deux URI doit correspondre.

     -  Un uri-parameter user, ttl ou method apparaissant uniquement dans l'un des URI ne correspond jamais, même s'il inclut une valeur par défaut.

     -  Un URI incluant le paramètre maddr ne correspond pas à un URI n'incluant pas le paramètre maddr.

     -  Tous les autres uri-parameter apparaissant uniquement dans l'un des URI sont ignorés lors de la comparaison des URI.

  o  Les composants header d'un URI ne sont jamais ignorés. Les composants header présents doivent apparaître dans les deux URI et correspondre pour que les URI correspondent. Les règles de correspondance sont définies pour chaque champ d'en-tête à la section 20.

Les URI de chacun des ensembles suivants sont équivalents.

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

Les URI de chacun des ensembles suivants ne sont pas équivalents.

SIP:[email protected];Transport=udp (nom d'utilisateur différent) sip:[email protected];Transport=UDP

sip:[email protected] (peut être résolu vers un port différent) sip:[email protected]:5060

sip:[email protected] (peut être résolu vers un transport différent) sip:[email protected];transport=udp

sip:[email protected] (peut être résolu vers un port et transport différents) sip:[email protected]:6000;transport=tcp

sip:[email protected] (composants header différents) sip:[email protected]?Subject=next%20meeting

sip:[email protected] (même si c'est la résolution de sip:[email protected] phone21.boxesbybob.com)

Notez que l'égalité n'est pas transitive.

  o  sip:[email protected] et sip:[email protected];security=on sont équivalents

  o  sip:[email protected] et sip:[email protected];security=off sont équivalents

  o  sip:[email protected];security=on et
     sip:[email protected];security=off ne sont pas équivalents

19.1.5 Formation de requêtes à partir d'un URI (Forming Requests from a URI)

Les implémentations doivent être prudentes lors de la construction directe de requêtes à partir d'URI. Les URI provenant de cartes de visite, de pages web, voire de sources internes au protocole (comme des contacts enregistrés) peuvent contenir des champs d'en-tête ou des parties de corps inappropriés.

Les implémentations DOIVENT inclure les paramètres transport, maddr, ttl ou user fournis dans le Request-URI de la requête construite. Si l'URI contient un paramètre method, sa valeur DOIT être utilisée comme méthode de la requête. Le paramètre method NE DOIT PAS être placé dans le Request-URI. Les paramètres URI inconnus DOIVENT être placés dans le Request-URI du message.

Les implémentations DEVRAIENT traiter la présence de composants header ou body dans l'URI comme une indication qu'ils doivent être inclus dans le message, et choisir de répondre à cette exigence composant par composant.

Les implémentations NE DEVRAIENT PAS répondre à ces champs d'en-tête manifestement dangereux : From, Call-ID, CSeq, Via et Record-Route.

Les implémentations NE DEVRAIENT PAS répondre aux valeurs de champ d'en-tête Route demandées, afin de ne pas servir d'agents inconscients dans une attaque malveillante.

Les implémentations NE DEVRAIENT PAS répondre aux exigences de champs d'en-tête susceptibles de causer la publicité fausse de leur propre emplacement ou de leurs capacités. Cela inclut Accept, Accept-Encoding, Accept-Language, Allow, Contact (utilisé dans un dialogue), Organization, Supported et User-Agent.

Les implémentations DEVRAIENT valider l'exactitude des champs d'en-tête descriptifs demandés incluant Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date et Timestamp.

Si une requête formée en construisant un message à partir d'un URI particulier n'est pas une requête SIP valide, l'URI est invalide. Les implémentations NE DOIVENT PAS procéder à l'envoi de la requête. Elles doivent plutôt prendre les mesures appropriées pour un URI invalide dans le contexte où il s'est produit.

  Une requête construite peut être invalide de nombreuses manières. Cela inclut, sans s'y limiter, les erreurs de syntaxe de champ d'en-tête, les combinaisons non valides de paramètres URI ou les descriptions incorrectes du corps du message.

L'envoi d'une requête formée à partir d'un URI particulier peut requérir des capacités non disponibles pour l'implémentation. Par exemple, l'URI peut indiquer l'utilisation d'un transport ou d'une extension non implémentés. Les implémentations DEVRAIENT refuser d'envoyer ces requêtes plutôt que de les modifier pour correspondre à leurs capacités. Les implémentations NE DOIVENT PAS envoyer de requêtes nécessitant des extensions qu'elles ne prennent pas en charge.

  Par exemple, de telles requêtes peuvent être formées via la présence d'un paramètre Require d'en-tête ou d'un paramètre method URI avec une valeur inconnue ou explicitement non prise en charge.

19.1.6 Mise en relation des URI SIP et des URL tel (Relating SIP URIs and tel URLs)

Lorsqu'une URL tel (RFC 2806 [9]) est convertie en un URI SIP ou SIPS, la totalité de la partie telephone-subscriber de l'URL tel (paramètres inclus) est placée dans la partie userinfo du URI SIP ou SIPS.

Ainsi, tel:+358-555-1234567;postd=pp22 devient

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

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

mais PAS

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

ou

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

En général, des « tel » URL équivalentes converties en URI SIP ou SIPS de cette manière ne produisent pas nécessairement des URI SIP ou SIPS équivalents. L'userinfo des URI SIP et SIPS est comparé comme une chaîne sensible à la casse. Les différences dans les parties non sensibles à la casse d'une URL tel, ou la réorganisation des paramètres d'une URL tel, n'affectent pas l'équivalence des URL tel, mais affectent l'équivalence des URI SIP formés à partir de celles-ci.

Par exemple,

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

sont équivalents, mais

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

ne le sont pas.

De même,

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

sont équivalents, mais

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

ne le sont pas.

Pour atténuer ce problème, les éléments composant le champ telephone-subscriber placé dans la partie userinfo d'un URI SIP ou SIPS DEVRAIENT replier en minuscules toutes les parties non sensibles à la casse du telephone-subscriber et réorganiser les paramètres telephone-subscriber par ordre lexicographique des noms de paramètres, à l'exception de isdn-subaddress et post-dial qui apparaissent en premier et dans cet ordre. (Tous les composants autres que les extensions futures des URL tel sont définis pour être comparés sans tenir compte de la casse.)

En suivant cette proposition, les deux

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

  deviennent

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

et les deux

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

  deviennent

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

19.2 Balises d'option (Option Tags)

Une balise d'option est un identifiant unique utilisé pour spécifier une nouvelle option (extension) dans SIP. Ces balises sont utilisées dans les champs d'en-tête Require (section 20.32), Proxy-Require (section 20.29), Supported (section 20.37) et Unsupported (section 20.40). Notez que ces options apparaissent en tant que paramètres dans ces champs d'en-tête, sous la forme option-tag = token (voir la section 25 pour la définition de token).

Les balises d'option sont définies dans des RFC de suivi standard. C'est un changement par rapport aux pratiques passées, introduit pour garantir l'interopérabilité continue multi-vendeurs (voir les discussions des sections 20.32 et 20.37). Un registre IANA des balises d'option est utilisé afin de faciliter la référence.

19.3 Balises (Tags)

Le paramètre « tag » est utilisé dans les champs d'en-tête To et From des messages SIP. Il sert de mécanisme général pour identifier les dialogues, qui sont la combinaison de la Call-ID et de deux balises (une de chaque) de chaque participant au dialogue. Lorsqu'un UA envoie une requête hors dialogue, elle inclut uniquement une balise From, fournissant la « moitié » de l'identifiant de dialogue. Le dialogue est complété par une réponse, chacune fournissant la seconde moitié dans le champ d'en-tête To. Les requêtes SIP peuvent être divisées en branches, permettant d'établir plusieurs dialogues à partir d'une seule requête. Cela explique également la nécessité d'un identifiant de dialogue des deux côtés. Sans la contribution du destinataire, l'appelant ne peut pas distinguer clairement les multiples dialogues établis à partir d'une seule requête.

Lorsqu'une balise est générée par un UA pour insertion dans une requête ou une réponse, elle DOIT être globalement unique et cryptographiquement aléatoire avec au moins 32 bits d'entropie. En tant que conséquence de cette exigence de choix, un UA place une balise dans l'en-tête From d'un INVITE différente de la balise qu'il place dans l'en-tête To d'une réponse à ce même INVITE. Cela est nécessaire pour qu'un UA puisse s'inviter lui-même à une session (un cas courant de « hairpin » dans une passerelle PSTN). De même, deux INVITE pour des appels différents ont des balises From différentes, et deux réponses pour des appels différents ont des balises To différentes.

Outre l'exigence d'unicité globale, l'algorithme de génération de balise est spécifique à l'implémentation. Les balises sont utiles dans les systèmes tolérants aux pannes où la récupération du dialogue sur un serveur de remplacement est nécessaire après une défaillance. Un UAS peut choisir une balise telle que le serveur de sauvegarde puisse reconnaître la requête comme faisant partie d'un dialogue sur le serveur défaillant, et ainsi décider d'essayer de récupérer ce dialogue et l'autre état qui y est associé.