Aller au contenu principal

15. Fin d'une session (Terminating a Session)

15 Fin d'une session (Terminating a Session)

Cette section décrit les procédures pour terminer une session établie par SIP. L'état de la session et l'état du dialogue sont très étroitement liés. Lorsqu'une session est initiée avec un INVITE, chaque réponse 1xx ou 2xx d'un UAS distinct crée un dialogue, et si cette réponse complète l'échange offre/réponse, elle crée également une session. Par conséquent, chaque session est « associée » à un seul dialogue - celui qui a abouti à sa création. Si un INVITE initial génère une réponse finale non 2xx, cela termine toutes les sessions (s'il y en a) et tous les dialogues (s'il y en a) qui ont été créés par les réponses à la requête. En achevant la transaction, une réponse finale non 2xx empêche également la création d'autres sessions résultant de l'INVITE. La requête BYE est utilisée pour terminer une session spécifique ou une session tentée. Dans ce cas, la session spécifique est celle avec le UA pair de l'autre côté du dialogue. Lorsqu'un BYE est reçu sur un dialogue, toute session associée à ce dialogue DEVRAIT (SHOULD) se terminer. Un UA NE DOIT PAS (MUST NOT) envoyer de BYE en dehors d'un dialogue. Le UA de l'appelant PEUT (MAY) envoyer un BYE pour des dialogues confirmés ou précoces, et le UA de l'appelé PEUT (MAY) envoyer un BYE sur des dialogues confirmés, mais NE DOIT PAS (MUST NOT) envoyer de BYE sur des dialogues précoces.

Cependant, le UA de l'appelé NE DOIT PAS (MUST NOT) envoyer de BYE sur un dialogue confirmé tant qu'il n'a pas reçu un ACK pour sa réponse 2xx ou tant que la transaction serveur n'a pas expiré. Si aucune extension SIP n'a défini d'autres états de couche applicative associés au dialogue, le BYE termine également le dialogue.

L'impact d'une réponse finale non 2xx à INVITE sur les dialogues et les sessions rend l'utilisation de CANCEL attrayante. Le CANCEL tente de forcer une réponse non 2xx à l'INVITE (en particulier, un 487). Par conséquent, si un UAC souhaite abandonner complètement sa tentative d'appel, il peut envoyer un CANCEL. Si l'INVITE aboutit à une ou des réponses finales 2xx à l'INVITE, cela signifie qu'un UAS a accepté l'invitation alors que le CANCEL était en cours. Le UAC PEUT (MAY) poursuivre avec les sessions établies par toute réponse 2xx, ou PEUT (MAY) les terminer avec un BYE.

  La notion de « raccrocher » (hanging up) n'est pas bien définie dans SIP. Elle est spécifique à une interface utilisateur particulière, bien que commune. Typiquement, lorsque l'utilisateur raccroche, cela indique le désir de terminer la tentative d'établissement d'une session, et de terminer toutes les sessions déjà créées. Pour le UA de l'appelant, cela impliquerait une requête CANCEL si l'INVITE initial n'a pas généré de réponse finale, et un BYE vers tous les dialogues confirmés après une réponse finale. Pour le UA de l'appelé, cela impliquerait typiquement un BYE ; vraisemblablement, lorsque l'utilisateur a décroché, un 2xx a été généré, et donc raccrocher entraînerait un BYE après la réception de l'ACK. Cela ne signifie pas qu'un utilisateur ne peut pas raccrocher avant la réception de l'ACK, cela signifie simplement que le logiciel de son téléphone doit maintenir un état pendant un court laps de temps afin de nettoyer correctement. Si l'interface utilisateur particulière permet à l'utilisateur de rejeter un appel avant d'y répondre, un 403 (Forbidden) est une bonne façon de l'exprimer. Selon les règles ci-dessus, un BYE ne peut pas être envoyé.

15.1 Fin d'une session avec une requête BYE (Terminating a Session with a BYE Request)

15.1.1 Comportement UAC (UAC Behavior)

Une requête BYE est construite comme toute autre requête dans un dialogue, comme décrit dans la section 12.

Une fois le BYE construit, le cœur UAC crée une nouvelle transaction client non INVITE et lui passe la requête BYE. Le UAC DOIT (MUST) considérer la session comme terminée (et donc arrêter d'envoyer ou d'écouter des médias) dès que la requête BYE est passée à la transaction client. Si la réponse pour le BYE est un 481 (Call/Transaction Does Not Exist) ou un 408 (Request Timeout) ou aucune réponse n'est reçue pour le BYE (c'est-à-dire qu'un dépassement de délai est renvoyé par la transaction client), le UAC DOIT (MUST) considérer la session et le dialogue comme terminés.

15.1.2 Comportement UAS (UAS Behavior)

Un UAS traite d'abord la requête BYE selon le traitement général UAS décrit dans la section 8.2. Un cœur UAS recevant une requête BYE vérifie si elle correspond à un dialogue existant. Si le BYE ne correspond pas à un dialogue existant, le cœur UAS DEVRAIT (SHOULD) générer une réponse 481 (Call/Transaction Does Not Exist) et la passer à la transaction serveur.

  Cette règle signifie qu'un BYE envoyé sans étiquettes par un UAC sera rejeté. C'est un changement par rapport à la RFC 2543, qui autorisait les BYE sans étiquettes.

Un cœur UAS recevant une requête BYE pour un dialogue existant DOIT (MUST) suivre les procédures de la section 12.2.2 pour traiter la requête. Une fois fait, le UAS DEVRAIT (SHOULD) terminer la session (et donc arrêter d'envoyer et d'écouter des médias). Le seul cas où il peut choisir de ne pas le faire concerne les sessions multicast, où la participation est possible même si l'autre participant au dialogue a terminé sa participation à la session. Qu'il termine ou non sa participation à la session, le cœur UAS DOIT (MUST) générer une réponse 2xx au BYE, et DOIT (MUST) la passer à la transaction serveur pour transmission.

Le UAS DOIT (MUST) toujours répondre à toute requête en attente reçue pour ce dialogue. Il est RECOMMANDÉ de générer une réponse 487 (Request Terminated) à ces requêtes en attente.