Résumé

  • RFC 3261 identifie un dialogue par un Call-ID, un tag local et un tag distant. La perspective s'inverse chez le pair : le tag local de l'un est le tag distant de l'autre.
  • Un INVITE bifurqué peut créer plusieurs dialogues précoces ou confirmés. Tous conservent le Call-ID et le tag de l'appelant, tandis que chaque répondant fournit un To-tag distinct.
  • Le dialogue transporte ensuite l'ordre, la route et la cible des requêtes futures. Son identifiant corrèle un contexte ; il n'authentifie pas une personne et ne prouve pas le passage des médias.

L'adresse était unique, les réponses ne l'étaient pas

Le vocabulaire téléphonique incite à voir un appel comme un objet singulier. Une personne compose une adresse, un correspondant décroche, une conversation commence. Le routage SIP pouvait raconter une autre histoire. Un proxy envoyait le même INVITE vers un téléphone fixe, un logiciel et une passerelle. Plusieurs appareils sonnaient ; plusieurs agents pouvaient répondre.

L'identifiant de la transaction initiale ne suffisait pas pour la suite. Une transaction devait associer une requête, ses retransmissions et ses réponses pendant un échange déterminé. Après la réponse, ACK, reconfiguration ou BYE lançaient de nouvelles transactions. L'un ou l'autre pair pouvait devenir l'émetteur. Des proxies pouvaient devoir rester sur la route, tandis qu'un terminal changeait d'adresse de contact.

SIP avait donc besoin d'un nom pour la mémoire de la relation, et non seulement pour le travail d'une requête.

En mars 1999, RFC 2543 appelait cette relation persistante un call leg. Elle l'identifiait avec Call-ID, To et From. La norme avait déjà vu le piège de la bifurcation : lorsqu'une demande pouvait atteindre plusieurs serveurs utilisateurs, chaque réponse recevait un To-tag afin que l'initiateur distingue les répondants. Plusieurs réponses portant des tags différents représentaient plusieurs branches d'appel.

Le modèle restait pourtant lié à l'ensemble des champs d'adresse. Le From-tag demeurait facultatif et la construction de Route et Record-Route était incomplète. SIP 2.0 a conservé la réalité du fork, mais a donné une frontière plus nette à l'état qu'il produisait.

Chaque extrémité écrivait une moitié du nom

RFC 3261, publié en juin 2002, a remplacé le call leg par le dialogue. Un dialogue est une relation SIP pair à pair entre deux agents utilisateurs qui persiste pendant un certain temps. Il fournit le contexte d'interprétation des messages, l'ordre dans chaque sens et les données nécessaires au routage des requêtes ultérieures.

Chez chaque agent, le dialog ID réunit trois éléments : Call-ID, tag local et tag distant. « Local » et « distant » dépendent du regard. Le tag local d'Alice est le tag distant chez Bob ; celui de Bob devient le tag distant chez Alice. Les deux extrémités partagent les mêmes valeurs opaques, sans imposer une orientation universelle.

La requête initiale apporte un Call-ID et un From-tag, soit, selon l'explication de RFC 3261, une moitié de l'identifiant. Une réponse capable d'établir un dialogue ajoute le To-tag. Pour l'émetteur, son From-tag devient local et le To-tag reçu devient distant. Le répondant inverse ces rôles.

Cette répartition résout précisément la bifurcation. Toutes les branches héritent du Call-ID et du tag de l'initiateur ; chaque terminal joint son propre To-tag. Le demandeur peut regrouper les signaux apparentés sans confondre les états créés avec plusieurs pairs.

Le Call-ID ne devait donc pas suffire à lui seul. Les tags n'étaient pas davantage des noms d'utilisateur ou des justificatifs. RFC 3261 exigeait d'un tag généré qu'il soit globalement unique et cryptographiquement aléatoire, avec au moins 32 bits de hasard. Cette exigence visait l'unicité du contexte, pas l'authentification d'Alice, l'autorisation de Bob ou la véracité du nom affiché.

Un dialogue existait avant le décrochage

Pour INVITE, une réponse provisoire de 101 à 199 portant un To-tag crée un early dialog. L'initiateur peut déjà conserver l'état de ce répondant alors que l'issue reste inconnue. Une réponse finale 2xx confirme le dialogue correspondant. Un échec, ou l'absence d'une réussite sur cette branche, met fin au dialogue précoce selon les règles du cœur.

Le fork donne à cette distinction une portée concrète. Plusieurs dialogues précoces peuvent coexister : un poste sonne, un autre indique une progression, un troisième refuse. Ils partagent la contribution de l'initiateur, mais leurs tags distants les séparent. Plusieurs 2xx peuvent même arriver et produire plusieurs dialogues confirmés que l'application doit acquitter puis départager.

PRACK traite une question voisine, mais différente. Avec RSeq et RAck, il fiabilise et ordonne certaines réponses provisoires. Les tags indiquent à quel contexte de pair ces réponses appartiennent. La fiabilité fonctionne dans un early dialog déjà nommé ; elle ne crée pas ce nom.

La branche Via se situe également ailleurs. Elle corrèle le travail d'une transaction et ses retransmissions. Le triplet du dialogue demeure après la fin de cette transaction et traverse les suivantes. Les confondre ferait soit disparaître trop tôt la relation, soit fusionner des requêtes distinctes dans une même transaction.

Le triplet protégeait une mémoire plus riche

Le dialogue ne stockait pas seulement trois champs. RFC 3261 y plaçait aussi les numéros de séquence locaux et distants, les URI des deux côtés, une cible distante, un indicateur de sécurité et un route set ordonné.

Chaque direction possède sa propre progression CSeq. Un agent augmente sa séquence locale lorsqu'il émet une nouvelle requête dans le dialogue ; le pair conserve la valeur distante et peut rejeter une valeur inférieure, donc hors ordre. Un trou n'est pas nécessairement une faute : une tentative précédente peut avoir été arrêtée par un défi d'authentification chez un intermédiaire. La séquence prouve un ordre relatif, pas l'arrivée de chaque entier.

Le route set indique quels proxies ont demandé à rester dans le chemin. Le serveur utilisateur l'apprend des Record-Route de la requête ; le client le construit dans l'ordre inverse à partir de la réponse. Les scénarios complets de RFC 3665 montrent le même Call-ID et les deux tags dans ACK, BYE et leurs réponses, tandis que les champs Route maintiennent les proxies choisis.

La cible distante répond à une autre question : à quelle adresse Contact joindre aujourd'hui le pair. Elle est initialisée lors de la création et peut être remplacée par une requête réussie de rafraîchissement de cible. Dans un dialogue créé par INVITE, le mécanisme central de RFC 3261 est re-INVITE.

Un terminal peut donc déplacer son Contact sans changer de dialogue. Le Call-ID et les tags restent ; le route set ne se réécrit pas non plus. Le triplet répond à « quel contexte ? », le route set à « par quels intermédiaires ? », la cible à « vers quelle adresse actuelle ? ». Une seule chaîne n'aurait pas pu porter ces trois pouvoirs sans ambiguïté.

Le contexte de signalisation n'était pas le son

Une fois le dialogue établi, chaque pair peut ouvrir une nouvelle transaction. L'émetteur devient UAC pour celle-ci, le destinataire UAS, même si leurs rôles étaient inverses lors de l'INVITE initial. La relation persistante dépasse ainsi l'asymétrie d'un échange client-serveur.

RFC 3264 place la négociation des médias dans SDP offer/answer. Les offres et réponses décrivent les flux, codecs, adresses et ports ; un contexte supérieur tel que SIP associe les échanges successifs. Une offre ultérieure peut ajouter, supprimer ou modifier un flux dans un dialogue qui continue.

Un dialogue confirmé ne prouve donc ni la réception du son ni l'existence d'une source RTP donnée. Il ne certifie pas le codec final ou la qualité. Il ordonne la signalisation ; le plan média doit fournir ses propres preuves.

RFC 4028 a ensuite défini des session timers négociés, rafraîchis par re-INVITE ou UPDATE. Des dialogues issus d'un même INVITE peuvent avoir des intervalles différents, ou aucun timer. Chaque rafraîchissement est une nouvelle transaction dans le contexte. Sa réussite prolonge la session ; son absence peut conduire à BYE. Le triplet ne constitue pas un bail perpétuel.

Un dialogue pouvait héberger plusieurs usages

Les extensions ont enfin montré qu'un dialogue ne correspondait pas toujours à une relation applicative unique. INVITE crée un invite usage, mais SUBSCRIBE ou REFER dans ce dialogue peut ajouter des usages. RFC 5057 explique qu'ils partagent Call-ID, tags, CSeq, route set, contacts, cible distante et indicateur de sécurité, tout en gardant un état propre, comme la durée d'un abonnement.

La fin normale d'un usage n'efface donc pas nécessairement les autres. BYE peut terminer l'invite usage alors qu'un abonnement événementiel reste actif. La fin de l'abonnement ne détruit pas forcément l'invitation. Le dialogue est un conteneur commun de signalisation, pas une promesse de destin unique.

RFC 6665 rend la limite visible. SUBSCRIBE et NOTIFY utilisent l'état du dialogue, mais le champ Event intervient pour reconnaître l'abonnement précis. Un SUBSCRIBE bifurqué peut créer des dialogues indépendants, rafraîchis séparément. Le triplet trouve le contexte partagé ; il n'est pas la clé complète de chaque usage.

La force de cet identifiant tient ainsi à sa retenue. Il continue de nommer la relation de pair pendant que les transactions finissent, que le Contact bouge, que la route reste, que les médias changent et que des usages s'ajoutent. Il ne prétend pas identifier tous ces phénomènes à leur place.