Aller au contenu principal

12. Dialogs

12 Dialogs

Un dialogue (dialog) est une relation SIP pair-à-pair entre deux agents utilisateurs qui persiste pendant un certain temps. Les dialogues sont utilisés comme moyen d'établir un appel (section 13), et de modifier et terminer des appels (sections 14 et 15). Les dialogues forment la base de fonctionnalités plus avancées (par exemple, PRESENCE et REFER [1] pour référencer les ressources multimédias d'un participant à l'autre) définies ultérieurement.

Un dialogue est identifié par le Call-ID et les balises locales et distantes (connues respectivement comme les balises To et From) (ceux-ci forment un identifiant de dialogue unique). La série de messages envoyés dans un dialogue comprend le maintien de l'état du dialogue, y compris la cible distante du dialogue (l'URI pour envoyer des messages dans le dialogue) et l'ensemble de routes (un ensemble de proxys) correspondant aux requêtes envoyées dans le dialogue. Le dialogue est créé par les comportements du UAS et du UAC établis, comme décrit tout au long de ce chapitre.

Cette section introduit le concept d'état de dialogue. Cet état est nécessaire pour router les requêtes envoyées dans chaque dialogue. Cet état est suivi du « côté » de chaque UA. C'est-à-dire que, dans un dialogue particulier, le UAC et le UAS maintiennent chacun un état différent. Un UA enregistre l'état à l'aide des concepts de côté « local » et « distant » du dialogue. L'URI locale, l'URI cible distante, le numéro de séquence distant et la balise distante du UAS correspondent à l'URI distante, l'URI cible locale, le numéro de séquence local et la balise locale du UAC. Chaque côté de l'état de dialogue se compose d'une paire d'identifiants de dialogue (Call-ID, balise locale et balise distante), d'un numéro de séquence local (UAC uniquement), d'un numéro de séquence distant, d'un URI distant (utilisé par le UAS pour déterminer où envoyer ou où envoyer les messages), d'un URI cible distante et d'un ensemble de routes.

  Les termes « distant » et « local » du chapitre 12 font référence à un état de dialogue particulier, et non au comportement général UAS et UAC du chapitre 8.

Les côtés maintiennent l'état du dialogue en créant le dialogue et via le traitement de la réponse INVITE initiale (réussie ou non) et des requêtes ultérieures envoyées dans le dialogue.

12.1 Création d'un dialogue

Le dialogue est créé par les comportements du UAS et du UAC qui le créent. Le comportement du UAS est décrit à la section 12.1.1, et celui du UAC à la section 12.1.2. Le dialogue est créé par la réponse UAS à un nouveau INVITE, sous réserve que la réponse ait une balise dans le champ To et que la réponse soit un code de réponse 2xx ou 101-199. Les réponses de redirection 3xx ne créent pas de dialogue.

  Note : dans la RFC 2543, le dialogue était appelé un appel (call), mais il est maintenant appelé dialogue. Cela laisse le terme appel avec sa signification informelle (par exemple, configuration d'appel). Le dialogue est établi par l'échange INVITE initial pour établir une session. Cependant, le dialogue ne correspond pas nécessairement à une session de manière un-à-un. Plusieurs dialogues (et donc plusieurs appels) peuvent être associés à la même session. Lorsqu'un agent utilisateur envoie un re-INVITE pour la même session, comme décrit à la section 12.2, aucun nouveau dialogue n'est créé. Cependant, si un utilisateur envoie un nouveau INVITE menant à un autre dialogue et que cet INVITE pointe vers un autre utilisateur dans la même session, un autre dialogue (et donc un autre appel) est créé. Cela se produit, par exemple, lorsque l'utilisateur utilise le transfert d'appel en cours d'appel pour mettre fin au premier appel et en démarrer un nouveau.

12.1.1 Comportement du UAS

Un UAS générant une réponse créant un dialogue (c'est-à-dire une réponse 101-199 ou 2xx) DOIT (MUST) inclure une balise dans le champ d'en-tête To de la réponse (section 8.2.6.2). Cette balise, combinée avec la valeur Call-ID contenue dans la réponse et la valeur de balise From fournie par l'appelant, forme le côté UAS de l'identifiant de dialogue. Le côté UAC de l'identifiant de dialogue (l'inverse des balises To et From) est établi par la requête créant le dialogue. Par conséquent, si la requête ne crée pas de dialogue (par exemple, une requête non-INVITE), le UAC envoyant la requête n'a pas besoin (NEED NOT) d'enregistrer la valeur de balise To contenue dans la réponse. Le côté UAC de l'identifiant de dialogue est formé par la balise From dans la requête et la balise To dans la réponse (car il est le créateur de la requête, pas de la réponse). Une requête ultérieure comme une requête BYE établit le côté UAS de l'identifiant de dialogue en utilisant la balise From dans la requête (car il est le UAC de cette requête).

Un UAS établissant un appel PEUT (MAY) inclure des valeurs de champ d'en-tête Record-Route dans la réponse créant le dialogue. Celles-ci sont ajoutées à l'état de dialogue pour s'assurer que les requêtes ultérieures passent par eux.

Le numéro de séquence distant (du point de vue du UAS) du dialogue créé est défini sur la valeur du numéro de séquence dans le champ d'en-tête CSeq de la réponse. L'URI distante est définie sur l'URI dans le champ d'en-tête To de la réponse. L'URI cible distante est définie sur l'URI dans le champ d'en-tête Contact de la réponse.

12.1.2 Comportement du UAC

Un UAC recevant une réponse créant un dialogue (c'est-à-dire une réponse 2xx ou une réponse provisoire 101-199) DOIT (MUST) copier la partie balise distante de l'identifiant de dialogue à partir du champ To de la réponse. Si la réponse est 2xx, la balise distante DOIT (MUST) être copiée à partir de la réponse créant la requête, puisque certaines requêtes peuvent créer l'état de dialogue à partir de réponses 1xx ultérieures reçues (section 13). L'URI distante est définie sur l'URI dans le champ d'en-tête To de la réponse. L'URI cible distante est définie sur l'URI dans le champ d'en-tête Contact de la réponse.

  Si des valeurs de champ d'en-tête Record-Route sont présentes dans la réponse (fournies par le UAS), le UAC DOIT (MUST) les conserver comme valeur initiale de l'ensemble de routes, et DOIT (MUST) les inverser (car elles apparaissent dans la requête dans l'ordre inverse de celui où les champs Record-Route ont été ajoutés). Le UAC utilise l'ensemble de routes pour envoyer des requêtes dans le dialogue (section 12.2.1.1). Lorsqu'une requête ultérieure est envoyée dans le dialogue, le numéro de séquence local par UAC est défini sur le numéro de séquence dans le champ d'en-tête CSeq de la requête. Ce numéro de séquence DOIT (MUST) être incrémenté de un pour chaque requête envoyée dans le dialogue.

  Note : une réponse de redirection 3xx ne crée pas de dialogue. Une réponse de redirection 3xx est traitée par le UAC selon l'exigence par défaut.

12.2 Requêtes dans un dialogue

Cette section décrit comment les requêtes sont envoyées dans un dialogue. Cela inclut les requêtes envoyées dans un dialogue existant, comme un re-INVITE (un INVITE pour mettre à jour la cible distante du dialogue) ou un BYE. Ces requêtes sont construites en utilisant les procédures générales de construction de requête UAC définies à la section 8.1.1. Par conséquent, cette section décrit uniquement les différences spécifiques par rapport à ces procédures. L'envoi de ces requêtes n'utilise pas le numéro de séquence (CSeq) de requête dans le dialogue (avertissement : il y a quelques exceptions). Un proxy PEUT (MAY) utiliser les informations d'ensemble de routes, sous la forme du modèle d'entité, pour aider au routage des requêtes envoyées dans un dialogue.

Notation : cette section suppose que, comme le dialogue a déjà été configuré en tant que UAS ou UAC avant que le côté récepteur traite la requête, la requête INVITE initiale qui l'a créé n'est pas traitée comme une requête dans le dialogue, quel que soit l'état de l'INVITE initial.

12.2.1 Comportement du UAC

Une requête UAC envoyée dans un dialogue DOIT (MUST) être routée en utilisant l'état du dialogue.

12.2.1.1 Génération de la requête

Lors de la construction de la requête, les champs d'en-tête To, From et Call-ID DOIVENT (MUST) être définis sur l'URI distante, l'URI locale et le Call-ID de l'état du dialogue, et le champ d'en-tête CSeq DOIT (MUST) être défini sur une nouvelle valeur supérieure de un au dernier CSeq de requête envoyé dans le dialogue. Le Request-URI de la requête DOIT (MUST) être défini sur l'URI cible distante du dialogue. Si l'ensemble de routes n'est pas vide, les valeurs du champ d'en-tête Route de la requête DOIVENT (MUST) être les valeurs de l'ensemble de routes. Si l'ensemble de routes est vide, la valeur du champ d'en-tête Route DEVRAIT (SHOULD) être omise.

  Note : cela garantit que, si l'ensemble de routes n'est pas vide, la requête passe par un proxy (c'est l'objectif de fournir l'ensemble de routes). L'URI cible distante est utilisée pour contourner les proxys car elle fournit une route directe entre le UAC et le UAS.

Par exemple, si un UAC envoie un re-INVITE dans un dialogue créé via un seul Record-Route (proxy) :

  Re-INVITE sip:[email protected] SIP/2.0
  Via: SIP/2.0/UDP host.ua1.example.com;branch=z9hG4bKvscx
  Max-Forwards: 70
  To: Bob `<sip:[email protected]>;tag=a6c85cf`
  From: Alice `<sip:[email protected]>`;tag=1928301774
  Call-ID: [email protected]
  CSeq: 314160 INVITE
  Contact: `<sip:[email protected]>`
  Route: `<sip:proxy.example.com>`

Note : la seule valeur Via est l'URI de l'expéditeur. La valeur CSeq du re-INVITE DOIT (MUST) être supérieure à celle de l'INVITE original. Notez qu'une valeur de séquence CSeq ne DOIT PAS (MUST NOT) être réutilisée. La valeur du champ d'en-tête Route est obtenue à partir de l'ensemble de routes.

Les procédures suivantes s'appliquent à l'envoi d'une requête dans un dialogue. Si une requête de rafraîchissement de cible (définie à la section 12.2.2) est générée par le UAC dans le dialogue, la valeur du champ d'en-tête Contact de cette requête DOIT (MUST) mettre à jour l'URI cible distante du dialogue.

  En général, un re-INVITE est utilisé pour mettre à jour la cible distante du dialogue, mais une requête UPDATE ou d'autres requêtes de rafraîchissement de cible peuvent également être utilisées. Les procédures décrites dans cette section (y compris le routage) sont des règles générales permettant à une requête de rafraîchissement de cible de se mettre à jour à l'aide d'un booléen. Pour une requête INVITE, un re-INVITE DOIT (MUST) également être utilisé pour initialiser un changement de description de session (section 14).

12.2.1.2 Traitement de la réponse

Une réponse à une requête envoyée dans un dialogue est traitée en utilisant les procédures décrites à la section 8.1.3.

Lors de la réception d'une réponse 2xx à une requête de rafraîchissement de cible (définie à la section 12.2.2), le UAC DOIT (MUST) mettre à jour l'URI cible distante du dialogue en utilisant l'URI du champ d'en-tête Contact de la réponse.

12.2.2 Requêtes de rafraîchissement de cible

Une requête de rafraîchissement de cible est définie comme une requête envoyée dans un dialogue qui peut modifier la cible distante du dialogue. Les requêtes INVITE et UPDATE de cette spécification sont des requêtes de rafraîchissement de cible. D'autres requêtes envoyées dans un dialogue (par exemple BYE) ne DEVRAIENT PAS (SHOULD NOT) modifier l'URI cible distante.

12.3 Fin d'un dialogue

Un dialogue se termine par la réception d'un BYE réussi (avec réponse 2xx), ou par une réponse non-2xx (par exemple 408 ou 480 pour un INVITE refusé) (voir section 15). Dans les deux cas, le côté récepteur DOIT (MUST) effacer l'état du dialogue. L'expéditeur d'un BYE réussi ne DOIT (MUST) l'effacer qu'après avoir reçu le BYE (bien qu'un UAC avec un INVITE échoué puisse effacer l'état du dialogue immédiatement (MAY)).

  Note : un dialogue correspondant à un INVITE échoué se termine par la réception de la réponse finale (réussie ou échouée). Un dialogue correspondant à un INVITE réussi ne se termine que par une requête BYE ultérieure. Par conséquent, un re-INVITE ne termine pas le dialogue contenant la requête INVITE originale.

  Un INVITE échoué est traité comme une simple transaction. Un dialogue correspondant à un INVITE réussi se termine uniquement via la réception d'une requête BYE. Même après la fin via la réception d'un BYE, le UAC peut continuer à conserver l'ancien état de dialogue jusqu'à ce que toutes les transactions dans le dialogue soient terminées (MAY).