Aller au contenu principal

13. Initiating a Session

13 Démarrage d'une session (Initiating a Session)

13.1 Aperçu (Overview)

Lorsqu'un client d'agent utilisateur souhaite démarrer une session (voix, vidéo ou jeu, par exemple), il crée une requête INVITE. La requête INVITE demande l'établissement d'une session au serveur. Cette requête est transférée par des proxys et atteint finalement un ou plusieurs UAS susceptibles d'accepter l'invitation. Ces UAS doivent souvent consulter l'utilisateur pour savoir s'il accepte l'invitation.

Après un certain temps, ces UAS peuvent accepter l'invitation (ce qui signifie que la session est établie) en envoyant une réponse 2xx. Si l'invitation n'est pas acceptée, une réponse 3xx, 4xx, 5xx ou 6xx est envoyée selon la raison du refus. Avant d'envoyer la réponse finale, un UAS PEUT envoyer une réponse provisoire (1xx) pour informer le UAC de la progression vers l'utilisateur appelé.

Après avoir pu recevoir une ou plusieurs réponses provisoires, le UAC reçoit une ou plusieurs réponses finales 2xx, ou une seule réponse finale non 2xx. En raison du temps que la réception d'une réponse finale à un INVITE peut prendre, le mécanisme de fiabilité de la transaction INVITE diffère de celui des autres requêtes. Lorsqu'une réponse finale est reçue, le UAC DOIT envoyer un ACK pour chaque réponse finale reçue. Le traitement de l'ACK diffère selon le type de réponse.

Une réponse 2xx à un INVITE établit la session et crée un dialogue entre le UA qui a émis l'INVITE et le UA qui a généré la réponse 2xx. Ainsi, si plusieurs réponses 2xx sont reçues de différents UAS distants (car l'INVITE a été forké), chaque 2xx établit un dialogue distinct. Tous ces dialogues font partie du même appel.

Cette section décrit les détails de l'établissement d'une session à l'aide d'INVITE. Un UA prenant en charge INVITE DOIT aussi prendre en charge ACK, CANCEL et BYE.

13.2 Traitement du UAC (UAC Processing)

13.2.1 Création de l'INVITE initial (Creating the Initial INVITE)

Puisqu'un INVITE initial représente une requête hors dialogue, sa construction suit les procédures de la section 8.1.1. Des traitements supplémentaires sont nécessaires pour le cas particulier d'INVITE.

Un champ d'en-tête Allow DEVRAIT être présent dans l'INVITE. Il indique les méthodes qui peuvent être invoquées sur le UA émettant l'INVITE pendant la durée du dialogue.

Un champ d'en-tête Supported DEVRAIT être présent dans l'INVITE. Il énumère toutes les extensions comprises par le UAC.

Un champ d'en-tête Accept PEUT être présent dans l'INVITE. Il indique les Content-Type acceptables par le UA, tant dans les réponses reçues que dans les requêtes ultérieures envoyées dans le dialogue établi par l'INVITE.

Un UAC PEUT ajouter un champ Expires pour limiter la validité de l'invitation. Si le temps indiqué par le champ Expires est atteint sans réponse finale à l'INVITE, le UAC core DEVRAIT générer une requête CANCEL pour l'INVITE selon la section 9.

Un UAC PEUT inclure d'autres informations pertinentes, telles que les champs Subject, Organization et User-Agent.

Un UAC PEUT choisir d'ajouter un corps de message à l'INVITE. La section 8.1.1.10 traite de la construction des champs d'en-tête nécessaires pour décrire le corps du message.

Les corps de message contenant une description de session ont des règles spéciales. Leur Content-Disposition est « session ». SIP utilise un modèle offre/réponse. Un UA envoie une description de session (appelée offre), et un autre UA répond avec une autre description de session (appelée réponse) indiquant les moyens de communication acceptés et l'adresse de réception des médias. L'échange offre/réponse étant dans le contexte d'un dialogue, si un INVITE SIP donne lieu à plusieurs dialogues, chacun est un échange offre/réponse distinct. Le modèle offre/réponse définit des restrictions sur le moment où les offres et réponses peuvent être créées. Cela impose des restrictions sur l'endroit où offres et réponses apparaissent dans les messages SIP. Dans cette spécification, les offres et réponses PEUVENT uniquement apparaître dans les requêtes et réponses INVITE, et dans ACK. Les règles pour la transaction INVITE initiale sont les suivantes.

  o L'offre initiale DOIT être dans l'INVITE, ou à défaut dans le premier message fiable et non en échec du UAS vers le UAC (dans cette spécification, c'est la réponse finale 2xx).

  o Si l'offre initiale est dans l'INVITE, la réponse DOIT être dans un message fiable et non en échec du UAS vers le UAC associé à cet INVITE. Dans cette spécification, c'est uniquement la réponse finale 2xx. La même réponse PEUT être placée dans toute réponse provisoire envoyée avant la réponse. Le UAC DOIT traiter la première description de session reçue comme la réponse et ignorer toute description dans les réponses ultérieures.

  o Si l'offre initiale est dans le premier message fiable et non en échec du UAS vers le UAC, la réponse DOIT être dans l'accusé de réception de ce message (dans cette spécification, l'ACK de la réponse 2xx).

  o Après avoir envoyé ou reçu la réponse à l'offre initiale, le UAC PEUT générer une offre ultérieure dans une requête ultérieure, selon les règles spécifiées pour cette méthode, mais seulement s'il a reçu une réponse à l'offre précédente et n'a pas envoyé d'offre sans réponse.

  o Après qu'un UAS a envoyé ou reçu la réponse à l'offre initiale, il NE DOIT PAS générer d'offre ultérieure dans une réponse à la transaction initiale.

Concrètement, les deux échanges ci-dessus sont pris en charge par tout UA conforme : offre dans INVITE et réponse dans 2xx (et éventuellement 1xx de même valeur), ou offre dans 2xx et réponse dans ACK. Tout agent prenant en charge INVITE DOIT prendre en charge ces deux échanges.

Le Session Description Protocol (SDP, RFC 2327) DOIT être pris en charge par tous les agents utilisateurs comme moyen de décrire la session, et son utilisation pour construire offres et réponses DOIT suivre les procédures définies dans la RFC 2138.

Les restrictions du modèle offre/réponse ci-dessus s'appliquent uniquement aux corps dont le Content-Disposition est « session ». Ainsi, un INVITE et un ACK peuvent tous deux contenir des corps de message (par exemple, un INVITE transportant une photo, et un ACK transportant une description de session).

Si le champ Content-Disposition est absent, un corps de type application/sdp a une disposition « session », et les autres types de contenu ont une disposition « render ».

Une fois l'INVITE créé, le UAC suit les procédures d'envoi d'une requête hors dialogue. Cela construit une transaction client qui finit par envoyer la requête et livrer les réponses au UAC.

13.2.2 Traitement des réponses INVITE (Processing INVITE Responses)

Une fois l'INVITE passé à la transaction client INVITE, le UAC attend les réponses. Si la transaction client INVITE renvoie un timeout au lieu d'une réponse, le TU agit comme s'il avait reçu une réponse 408 selon la section 8.1.3.

13.2.2.1 Réponses 1xx (1xx Responses)

Zéro, une ou plusieurs réponses provisoires peuvent arriver avant qu'une ou plusieurs réponses finales ne soient reçues. Une réponse provisoire à une requête INVITE PEUT créer un « dialogue précoce ». Si le champ To de la réponse provisoire a une balise et que l'ID de dialogue de la réponse ne correspond à aucun dialogue existant, il est construit selon la section 12.1.2.

Un dialogue précoce n'est nécessaire que si le UAC doit envoyer une requête dans le dialogue à son pair avant la fin de la transaction INVITE initiale. Les champs d'en-tête présents dans la réponse provisoire s'appliquent tant que le dialogue est à l'état précoce.

13.2.2.2 Réponses 3xx (3xx Responses)

Une réponse 3xx peut contenir une ou plusieurs valeurs de champ Contact fournissant de nouvelles adresses où le destinataire est joignable. Selon le code de statut de la réponse 3xx, le UAC PEUT choisir d'essayer ces nouvelles adresses.

13.2.2.3 Réponses 4xx, 5xx et 6xx (4xx, 5xx and 6xx Responses)

Une seule réponse finale non 2xx peut être reçue pour un INVITE. Les réponses 4xx, 5xx et 6xx peuvent contenir une valeur de champ Contact indiquant où trouver des informations supplémentaires sur l'erreur. Les réponses finales ultérieures (qui ne peuvent arriver qu'en cas d'erreur) DOIVENT être ignorées.

Tous les dialogues précoces sont considérés comme terminés à la réception d'une réponse finale non 2xx.

Après réception d'une réponse finale non 2xx, le UAC core considère la transaction INVITE comme terminée. La transaction client INVITE gère la génération de l'ACK pour la réponse.

13.2.2.4 Réponses 2xx (2xx Responses)

En raison des proxys de forkage, plusieurs réponses 2xx d'un seul INVITE peuvent arriver au UAC. Chaque réponse est distinguée par un paramètre de balise dans le champ To, chacune représentant un dialogue distinct.

Si l'ID de dialogue dans la réponse 2xx correspond à l'ID de dialogue d'un dialogue existant, le dialogue DOIT passer à l'état « confirmé », et l'ensemble de routes du dialogue DOIT être recalculé à partir de la réponse 2xx selon la section 12.2.1.2. Sinon, un nouveau dialogue à l'état « confirmé » DOIT être construit selon la section 12.1.2.

Le UAC core DOIT générer une requête ACK pour chaque 2xx reçu de la couche transaction. Les champs de l'ACK sont construits comme pour toute requête envoyée dans un dialogue, à l'exception des champs liés à CSeq et à l'authentification. Le numéro de séquence du champ CSeq DOIT être le même que l'INVITE confirmé, mais la méthode CSeq DOIT être ACK. L'ACK DOIT contenir les mêmes informations d'identification que l'INVITE. Si le 2xx contient une offre, l'ACK DOIT transporter la réponse dans son corps. Si l'offre dans la réponse 2xx n'est pas acceptable, le UAC core DOIT générer une réponse valide dans l'ACK et envoyer un BYE immédiatement après.

Une fois l'ACK construit, la destination est déterminée selon les procédures de la RFC 3263. L'ACK n'est pas passé à une transaction client mais directement à la couche transport et envoyé. L'ACK DOIT être passé à la couche transport client à chaque réception d'une retransmission de la réponse finale 2xx qui a déclenché l'ACK.

Le UAC core considère la transaction INVITE comme terminée 64*T1 secondes après la réception de la première réponse 2xx. À ce moment, tous les dialogues précoces non passés à un dialogue établi se terminent. Aucune nouvelle réponse 2xx n'est attendue après.

Après avoir confirmé une réponse 2xx à un INVITE, si le UAC ne souhaite pas poursuivre le dialogue, il DOIT envoyer une requête BYE pour terminer le dialogue selon la section 15.

13.3 Traitement du UAS (UAS Processing)

13.3.1 Traitement de l'INVITE (Processing of the INVITE)

Le UAS core reçoit la requête INVITE de la couche transaction. Il exécute d'abord les procédures de traitement des requêtes de la section 8.2 applicables aux requêtes dans et hors dialogue.

En supposant que ces états de traitement se terminent sans générer de réponse, le UAS core effectue des procédures supplémentaires.

  1. Si la requête est un INVITE contenant un champ Expires, le UAS core définit une minuterie du nombre de secondes indiqué. Si la minuterie expire avant qu'une réponse finale ne soit générée, il DEVRAIT générer une réponse 487.

  2. Si la requête est une requête dans un dialogue, le traitement indépendant de la méthode décrit à la section 12.2.2 s'applique d'abord.

  3. Si le champ To de la requête a une balise mais que l'ID de dialogue ne correspond à aucun dialogue existant, le UAS a peut-être planté et redémarré, ou reçu une requête destinée à un UAS différent.

Le traitement ci-après suppose que l'INVITE est hors dialogue et établit donc une nouvelle session.

Un INVITE peut contenir une description de session, auquel cas une offre de session est présentée au UAS. L'utilisateur peut déjà être participant à cette session, même si l'INVITE est hors dialogue. Le UAS PEUT utiliser les identifiants dans la description de session pour détecter ce doublon. Si l'utilisateur est déjà membre de la session et que les paramètres de session n'ont pas changé, le UAS PEUT accepter silencieusement l'INVITE.

Si l'INVITE ne contient pas de description de session, le UAS est invité à rejoindre la session et le UAC attend que le UAS fournisse l'offre. Le UAS DOIT fournir l'offre dans le premier message fiable non en échec vers le UAC. Dans cette spécification, c'est la réponse 2xx à l'INVITE.

Le UAS peut indiquer la progression, accepter, rediriger ou rejeter l'invitation. Dans tous les cas, la réponse est créée en utilisant les procédures de la section 8.2.6.

13.3.1.1 Progression (Progress)

Si le UAS ne peut pas répondre immédiatement à l'invitation, il peut choisir d'indiquer une certaine progression au UAC (par exemple que le téléphone sonne). Cela se fait avec des réponses provisoires de 101 à 199. Ces réponses provisoires établissent un dialogue précoce, donc elles suivent la section 12.1.1 en plus de 8.2.6. Un UAS PEUT envoyer autant de réponses provisoires qu'il le souhaite. Chacune DOIT indiquer le même ID de dialogue. Elles ne sont pas livrées de manière fiable.

Si un UAS a besoin de beaucoup de temps pour répondre à un INVITE, il DOIT envoyer des réponses provisoires non 100 chaque minute pour contrer la possibilité de réponses provisoires perdues.

13.3.1.2 L'INVITE est redirigé (The INVITE is Redirected)

Si le UAS décide de rediriger l'appel, une réponse 3xx est envoyée. Les réponses 300, 301 ou 302 DEVRAIENT contenir un champ Contact avec une ou plusieurs URI à essayer. La réponse est passée à la transaction serveur INVITE qui gère ses retransmissions.

13.3.1.3 L'INVITE est rejeté (The INVITE is Rejected)

Dans le scénario général où le destinataire ne peut ou ne veut pas émettre ou recevoir d'autres appels sur ce terminal, il DEVRAIT retourner 486. Si le UAS sait que d'autres terminaux ne peuvent pas accepter cet appel, il DEVRAIT plutôt envoyer une réponse 600. Un UAS qui rejette une offre contenue dans un INVITE DEVRAIT retourner une réponse 488, avec un champ Warning expliquant la raison.

13.3.1.4 L'INVITE est accepté (The INVITE is Accepted)

Le UAS core génère une réponse 2xx. Cette réponse établit un dialogue, elle suit donc la section 12.1.1 en plus de 8.2.6.

Une réponse 2xx à un INVITE DEVRAIT contenir les champs Allow et Supported, et PEUT contenir un champ Accept.

Si la requête INVITE contenait une offre et que le UAS n'a pas encore envoyé de réponse, le 2xx DOIT contenir une réponse. Si l'INVITE ne contenait pas d'offre et que le UAS n'en a pas encore envoyé, le 2xx DOIT contenir une offre.

Une fois la réponse construite, elle est passée à la transaction serveur INVITE. Celle-ci est détruite dès qu'elle reçoit la réponse finale et la passe au transport. Par conséquent, la réponse DOIT être périodiquement repassée directement au transport tant qu'aucun ACK n'est reçu. Les réponses 2xx sont passées au transport à des intervalles commençant à T1 et doublant jusqu'à T2. La retransmission s'arrête à la réception de la requête ACK pour cette réponse.

Si le serveur retransmet la réponse 2xx pendant 64*T1 secondes sans recevoir d'ACK, le dialogue est confirmé mais la session devrait être terminée par un BYE.