13. Initiating a Session
13 Avvio di una sessione (Initiating a Session)
13.1 Panoramica (Overview)
Quando un client agent utente desidera avviare una sessione (voce, video o gioco), crea una richiesta INVITE. La richiesta INVITE richiede l'istituzione di una sessione al server. La richiesta è inoltrata dai proxy e raggiunge infine uno o più UAS che potrebbero accettare l'invito. Questi UAS devono spesso consultare l'utente per sapere se accetta.
Dopo un certo tempo, gli UAS possono accettare l'invito inviando una risposta 2xx (la sessione è istituita). Se l'invito non è accettato, si invia 3xx, 4xx, 5xx o 6xx. Prima della risposta finale, un UAS PUÒ inviare una risposta provvisoria (1xx) per informare il UAC del progresso.
Dopo una o più risposte provvisorie, il UAC riceve una o più risposte finali 2xx, o una singola risposta finale non 2xx. Poiché la risposta finale a un INVITE può richiedere tempo, il meccanismo di affidabilità della transazione INVITE differisce da quello di altre richieste. Alla ricezione di una risposta finale, il UAC DEVE inviare un ACK per ciascuna risposta finale ricevuta.
Una risposta 2xx a un INVITE istituisce la sessione e crea un dialogo tra il UA che ha emesso l'INVITE e il UA che ha generato la 2xx. Se più 2xx provengono da diversi UAS remoti (l'INVITE è stato forkato), ciascuna 2xx istituisce un dialogo distinto; tutti appartengono alla stessa chiamata.
Questa sezione descrive i dettagli dell'istituzione di sessione con INVITE. Un UA che supporta INVITE DEVE supportare anche ACK, CANCEL e BYE.
13.2 Elaborazione UAC (UAC Processing)
13.2.1 Creazione dell'INVITE iniziale (Creating the Initial INVITE)
Poiché un INVITE iniziale rappresenta una richiesta fuori dialogo, la sua costruzione segue la sezione 8.1.1. Un campo Allow DOVREBBE essere presente, così come Supported. Un campo Accept PUÒ essere presente. Un UAC PUÒ aggiungere Expires per limitare la validità. Un UAC PUÒ aggiungere un corpo del messaggio; i corpi con descrizione di sessione hanno Content-Disposition «session» e seguono il modello offerta/risposta. Le regole per la transazione INVITE iniziale: l'offerta iniziale DEVE essere nell'INVITE o, in sua assenza, nella prima risposta affidabile e non fallita (2xx); la risposta DEVE essere nella 2xx; se l'offerta è nella 2xx, la risposta DEVE essere nell'ACK; dopo scambio iniziale, il UAC PUÒ generare offerte successive; il UAS non DEVE generare offerte successive nella transazione iniziale. Tutti i UA conformi DEVONO supportare entrambi gli scambi (offerta in INVITE e risposta in 2xx, oppure offerta in 2xx e risposta in ACK). SDP DEVE essere supportato da tutti. Se Content-Disposition manca, application/sdp è «session», altri tipi «render».
Una volta creato l'INVITE, il UAC segue le procedure di invio di una richiesta fuori dialogo.
13.2.2 Elaborazione delle risposte INVITE (Processing INVITE Responses)
Se la transazione client restituisce timeout invece di una risposta, il TU agisce come se avesse ricevuto 408.
13.2.2.1 Risposte 1xx (1xx Responses)
Zero, una o più risposte provvisorie possono arrivare prima delle finali. Una risposta provvisoria PUÒ creare un «dialogo precoce». Un dialogo precoce è necessario solo se il UAC deve inviare una richiesta nel dialogo prima del completamento della transazione INVITE iniziale.
13.2.2.2 Risposte 3xx (3xx Responses)
Una 3xx PUÒ contenere nuovi indirizzi di contatto; il UAC PUÒ provarli.
13.2.2.3 Risposte 4xx, 5xx e 6xx (4xx, 5xx and 6xx Responses)
Può essere ricevuta una sola risposta finale non 2xx. Tutti i dialoghi precoci terminano. Il UAC core considera la transazione terminata; la transazione client genera l'ACK.
13.2.2.4 Risposte 2xx (2xx Responses)
A causa dei proxy di fork, più 2xx possono arrivare. Se l'ID dialogo corrisponde a uno esistente, passa a «confermato» e ricalcola il route set; altrimenti crea un nuovo dialogo confermato. Il UAC core DEVE generare un ACK per ogni 2xx. Se la 2xx contiene un'offerta, l'ACK DEVE trasportare la risposta; se non accettabile, il UAC DEVE generare una risposta valida e inviare un BYE. Il UAC core considera la transazione terminata 64*T1 secondi dopo la prima 2xx. Se non vuole proseguire, DEVE inviare BYE.
13.3 Elaborazione UAS (UAS Processing)
13.3.1 Elaborazione dell'INVITE (Processing of the INVITE)
Il UAS core riceve l'INVITE e applica la sezione 8.2. Poi: se Expires presente, imposta timer (487 se scade); se mid-dialog, applica 12.2.2; se To ha tag ma nessun dialogo corrisponde, gestisce crash/restart. Se l'INVITE contiene descrizione di sessione, è presentata un'offerta; se l'utente è già membro, PUÒ accettare silenziosamente. Se non contiene offerta, il UAS DEVE fornirla nella 2xx.
Il UAS PUÒ mostrare progresso (101-199), accettare (2xx), reindirizzare (3xx) o rifiutare (4xx/6xx).
13.3.1.1 Progresso (Progress)
Se non può rispondere subito, invia risposte provvisorie; DEVE inviare risposte non 100 ogni minuto per evitare cancellazione da proxy.
13.3.1.2 L'INVITE è reindirizzato (The INVITE is Redirected)
Se decide di reindirizzare, invia 3xx con Contact di nuovi indirizzi.
13.3.1.3 L'INVITE è rifiutato (The INVITE is Rejected)
Se non disponibile, DEVEREBBE restituire 486; se sa che altri terminali non possono accettare, 600; se rifiuta offerta, 488 con Warning.
13.3.1.4 L'INVITE è accettato (The INVITE is Accepted)
Il UAS core genera 2xx, che istituisce dialogo. DEVREBBE contenere Allow e Supported. Se l'INVITE aveva offerta e nessuna risposta inviata, il 2xx DEVE contenere risposta; se non aveva offerta, DEVE contenere offerta. La 2xx è ritrasmessa periodicamente finché non arriva ACK; se per 64*T1 secondi non arriva ACK, la sessione DOVREBBE essere terminata con BYE.