15. Terminazione di una sessione (Terminating a Session)
15 Terminazione di una sessione (Terminating a Session)
Questa sezione descrive le procedure per terminare una sessione stabilita da SIP. Lo stato della sessione e lo stato del dialogo sono molto strettamente correlati. Quando una sessione è avviata con un INVITE, ogni risposta 1xx o 2xx da un UAS distinto crea un dialogo, e se quella risposta completa lo scambio offerta/risposta, crea anche una sessione. Di conseguenza, ogni sessione è "associata" a un singolo dialogo - quello che ha portato alla sua creazione. Se un INVITE iniziale genera una risposta finale non 2xx, ciò termina tutte le sessioni (se presenti) e tutti i dialoghi (se presenti) che sono stati creati tramite le risposte alla richiesta. Completando la transazione, una risposta finale non 2xx impedisce anche la creazione di ulteriori sessioni come risultato dell'INVITE. La richiesta BYE è usata per terminare una sessione specifica o una sessione tentata. In questo caso, la sessione specifica è quella con il UA peer dall'altra parte del dialogo. Quando un BYE è ricevuto su un dialogo, qualsiasi sessione associata a quel dialogo DOVREBBE (SHOULD) terminare. Un UA NON DEVE (MUST NOT) inviare un BYE al di fuori di un dialogo. Il UA del chiamante PUÒ (MAY) inviare un BYE per dialoghi confermati o preliminari, e il UA del chiamato PUÒ (MAY) inviare un BYE su dialoghi confermati, ma NON DEVE (MUST NOT) inviare un BYE su dialoghi preliminari.
Tuttavia, il UA del chiamato NON DEVE (MUST NOT) inviare un BYE su un dialogo confermato finché non ha ricevuto un ACK per la sua risposta 2xx o finché la transazione server non va in timeout. Se nessuna estensione SIP ha definito altri stati di livello applicativo associati al dialogo, il BYE termina anche il dialogo.
L'impatto di una risposta finale non 2xx a INVITE su dialoghi e sessioni rende attraente l'uso di CANCEL. Il CANCEL tenta di forzare una risposta non 2xx all'INVITE (in particolare, un 487). Pertanto, se un UAC desidera abbandonare completamente il suo tentativo di chiamata, può inviare un CANCEL. Se l'INVITE porta a una o più risposte finali 2xx all'INVITE, ciò significa che un UAS ha accettato l'invito mentre il CANCEL era in corso. Il UAC PUÒ (MAY) proseguire con le sessioni stabilite da qualsiasi risposta 2xx, o PUÒ (MAY) terminarle con un BYE.
La nozione di "riagganciare" (hanging up) non è ben definita all'interno di SIP. È specifica di una particolare, sebbene comune, interfaccia utente. Tipicamente, quando l'utente riaggancia, indica il desiderio di terminare il tentativo di stabilire una sessione e di terminare qualsiasi sessione già creata. Per il UA del chiamante, ciò implicherebbe una richiesta CANCEL se l'INVITE iniziale non ha generato una risposta finale, e un BYE a tutti i dialoghi confermati dopo una risposta finale. Per il UA del chiamato, implicherebbe tipicamente un BYE; presumibilmente, quando l'utente ha sollevato la cornetta, è stato generato un 2xx, e quindi riagganciare comporterebbe un BYE dopo la ricezione dell'ACK. Ciò non significa che un utente non possa riagganciare prima di ricevere l'ACK, significa solo che il software nel suo telefono deve mantenere lo stato per un breve periodo per pulire correttamente. Se la particolare UI consente all'utente di rifiutare una chiamata prima di rispondere, un 403 (Forbidden) è un buon modo per esprimerlo. Secondo le regole sopra, non può essere inviato un BYE.
15.1 Terminazione di una sessione con una richiesta BYE (Terminating a Session with a BYE Request)
15.1.1 Comportamento UAC (UAC Behavior)
Una richiesta BYE è costruita come qualsiasi altra richiesta all'interno di un dialogo, come descritto nella sezione 12.
Una volta costruito il BYE, il core UAC crea una nuova transazione client non INVITE e le passa la richiesta BYE. Il UAC DEVE (MUST) considerare la sessione terminata (e quindi smettere di inviare o ascoltare media) non appena la richiesta BYE è passata alla transazione client. Se la risposta per il BYE è un 481 (Call/Transaction Does Not Exist) o un 408 (Request Timeout) o non viene ricevuta alcuna risposta per il BYE (cioè, un timeout è restituito dalla transazione client), il UAC DEVE (MUST) considerare la sessione e il dialogo terminati.
15.1.2 Comportamento UAS (UAS Behavior)
Un UAS elabora prima la richiesta BYE secondo l'elaborazione generale UAS descritta nella sezione 8.2. Un core UAS che riceve una richiesta BYE verifica se corrisponde a un dialogo esistente. Se il BYE non corrisponde a un dialogo esistente, il core UAS DOVREBBE (SHOULD) generare una risposta 481 (Call/Transaction Does Not Exist) e passarla alla transazione server.
Questa regola significa che un BYE inviato senza tag da un UAC sarà rifiutato. Questo è un cambiamento rispetto alla RFC 2543, che consentiva BYE senza tag.
Un core UAS che riceve una richiesta BYE per un dialogo esistente DEVE (MUST) seguire le procedure della sezione 12.2.2 per elaborare la richiesta. Una volta fatto, il UAS DOVREBBE (SHOULD) terminare la sessione (e quindi smettere di inviare e ascoltare media). L'unico caso in cui può scegliere di non farlo riguarda le sessioni multicast, dove la partecipazione è possibile anche se l'altro partecipante nel dialogo ha terminato la sua partecipazione alla sessione. Che esso termini o meno la sua partecipazione alla sessione, il core UAS DEVE (MUST) generare una risposta 2xx al BYE, e DEVE (MUST) passarla alla transazione server per la trasmissione.
Il UAS DEVE (MUST) ancora rispondere a qualsiasi richiesta in sospeso ricevuta per quel dialogo. È RACCOMANDATO che sia generata una risposta 487 (Request Terminated) a quelle richieste in sospeso.