14. Modifica di una sessione esistente (Modifying an Existing Session)
14 Modifica di una sessione esistente (Modifying an Existing Session)
Una richiesta INVITE riuscita (vedere sezione 13) stabilisce sia un dialogo tra due user agent sia una sessione che usa il modello offerta/risposta. La sezione 12 spiega come modificare un dialogo esistente usando una richiesta di aggiornamento della destinazione (per esempio, cambiando l'URI di destinazione remota del dialogo). Questa sezione descrive come modificare la sessione reale. Tale modifica può comportare la modifica di indirizzi o porte, l'aggiunta di un flusso multimediale, la rimozione di un flusso multimediale, ecc. Ciò è realizzato inviando una nuova richiesta INVITE nello stesso dialogo che ha stabilito la sessione. Una richiesta INVITE inviata all'interno di un dialogo esistente è conosciuta come re-INVITE.
Si noti che un singolo re-INVITE può modificare il dialogo e i parametri di sessione contemporaneamente.
Sia il chiamante sia il chiamato possono modificare una sessione esistente.
Il comportamento di un UA al rilevamento di un guasto multimediale è una questione di politica locale. Tuttavia, la generazione automatica di re-INVITE o di BYE NON È RACCOMANDATA per evitare di inondare la rete di traffico in caso di congestione. In ogni caso, se questi messaggi sono inviati automaticamente, DOVREBBERO (SHOULD) essere inviati dopo un certo intervallo casuale.
Si noti che il paragrafo sopra riguarda i BYE e i re-INVITE generati automaticamente. Se l'utente riaggancia in caso di guasto multimediale, il UA invierebbe una richiesta BYE come al solito.
14.1 Comportamento UAC (UAC Behavior)
Lo stesso modello offerta/risposta che si applica alle descrizioni di sessione negli INVITE (sezione 13.2.1) si applica ai re-INVITE. Di conseguenza, un UAC che vuole aggiungere un flusso multimediale, per esempio, creerà una nuova offerta contenente tale flusso multimediale e la invierà in una richiesta INVITE al suo peer. È importante notare che è la descrizione completa della sessione, e non solo la modifica, che viene inviata. Ciò supporta l'elaborazione della sessione senza stato in vari elementi e supporta le capacità di failover e recupero. Certamente, un UAC PUÒ (MAY) inviare un re-INVITE senza descrizione di sessione, nel qual caso la prima risposta affidabile non fallita al re-INVITE conterrà l'offerta (in questa specifica, è una risposta 2xx).
Se il formato di descrizione di sessione ha la capacità di numeri di versione, l'offerente DOVREBBE (SHOULD) indicare che la versione della descrizione di sessione è cambiata.
Il To, il From, il Call-ID, il CSeq e il Request-URI di un re-INVITE sono impostati seguendo le stesse regole delle richieste regolari in un dialogo esistente, descritte nella sezione 12.
Un UAC PUÒ (MAY) scegliere di non aggiungere un campo di intestazione Alert-Info o un corpo con Content-Disposition "alert" ai re-INVITE, poiché i UAS generalmente non avvisano l'utente al ricevimento di un re-INVITE.
A differenza di un INVITE, che può effettuare il forking, un re-INVITE non effettuerà mai il forking e di conseguenza genererà sempre una sola risposta finale. Il motivo per cui un re-INVITE non effettua mai il forking è che la Request-URI identifica la destinazione come l'istanza UA con la quale ha stabilito il dialogo, piuttosto che identificare un address-of-record per l'utente.
Si noti che un UAC NON DEVE (MUST NOT) iniziare una nuova transazione INVITE all'interno di un dialogo mentre un'altra transazione INVITE è in corso in una qualsiasi delle due direzioni.
1. Se c'è una transazione client INVITE in corso, la TU DEVE (MUST) attendere che la transazione raggiunga lo stato terminato o completato prima di iniziare il nuovo INVITE.
2. Se c'è una transazione server INVITE in corso, la TU DEVE (MUST) attendere che la transazione raggiunga lo stato confermato o terminato prima di iniziare il nuovo INVITE.
Tuttavia, un UA PUÒ (MAY) iniziare una transazione regolare mentre una transazione INVITE è in corso, e PUÒ (MAY) iniziare una transazione INVITE mentre una transazione regolare è in corso.
Se un UA riceve una risposta finale non 2xx a un re-INVITE, i parametri di sessione DEVONO (MUST) rimanere invariati, come se non fosse stato emesso alcun re-INVITE. Si noti che, come indicato nella sezione 12.2.1.2, se la risposta finale non 2xx è un 481 (Call/Transaction Does Not Exist), o un 408 (Request Timeout), o se non viene ricevuta alcuna risposta per il re-INVITE (cioè un timeout è restituito dalla transazione client INVITE), il UAC terminerà il dialogo.
Se un UAC riceve una risposta 491 a un re-INVITE, DOVREBBE (SHOULD) avviare un timer con un valore T scelto come segue:
1. Se il UAC è il proprietario del Call-ID dell'ID del dialogo (il che significa che ha generato il valore), T ha un valore scelto casualmente tra 2,1 e 4 secondi in unità di 10 ms.
2. Se il UAC non è il proprietario del Call-ID dell'ID del dialogo, T ha un valore scelto casualmente tra 0 e 2 secondi in unità di 10 ms.
Quando il timer scatta, il UAC DOVREBBE (SHOULD) riprovare il re-INVITE di nuovo, se desidera ancora che questa modifica di sessione abbia luogo. Per esempio, se la chiamata è già stata chiusa con un BYE, il re-INVITE non avrebbe luogo.
Le regole per inviare un re-INVITE e per generare un ACK per una risposta 2xx a un re-INVITE sono le stesse dell'INVITE iniziale (sezione 13.2.1).
14.2 Comportamento UAS (UAS Behavior)
La sezione 13.3.1 descrive la procedura per distinguere i re-INVITE in ingresso dagli INVITE iniziali in ingresso e gestire un re-INVITE per un dialogo esistente.
Un UAS che riceve un secondo INVITE prima di aver inviato la risposta finale a un primo INVITE con numero di sequenza CSeq più basso sullo stesso dialogo DEVE (MUST) restituire una risposta 500 (Server Internal Error) al secondo INVITE e DEVE (MUST) includere un campo di intestazione Retry-After con un valore scelto casualmente tra 0 e 10 secondi.
Un UAS che riceve un INVITE su un dialogo mentre un INVITE che ha inviato su quel dialogo è in corso DEVE (MUST) restituire una risposta 491 (Request Pending) all'INVITE ricevuto.
Se un UA riceve un re-INVITE per un dialogo esistente, DEVE (MUST) verificare eventuali identificatori di versione nella descrizione di sessione o, se non c'è identificatore di versione, il contenuto della descrizione di sessione per vedere se è cambiato. Se la descrizione di sessione è cambiata, il UAS DEVE (MUST) adattare i parametri di sessione di conseguenza, eventualmente dopo aver chiesto conferma all'utente.
Il versioning della descrizione di sessione può essere usato per accogliere le capacità dei nuovi arrivati a una conferenza, aggiungere o rimuovere media, o passare da una conferenza unicast a una conferenza multicast.
Se la nuova descrizione di sessione non è accettabile, il UAS può rifiutarla restituendo una risposta 488 (Not Acceptable Here) per il re-INVITE. Tale risposta DOVREBBE (SHOULD) includere un campo di intestazione Warning.
Se un UAS genera una risposta 2xx e non riceve mai un ACK, DOVREBBE (SHOULD) generare un BYE per terminare il dialogo.
Un UAS PUÒ (MAY) scegliere di non generare risposte 180 (Ringing) per un re-INVITE poiché i UAC generalmente non mostrano questa informazione all'utente. Per la stessa ragione, i UAS POSSONO (MAY) scegliere di non usare un campo di intestazione Alert-Info o un corpo con Content-Disposition "alert" nelle risposte a un re-INVITE.
Un UAS che fornisce un'offerta in un 2xx (perché l'INVITE non conteneva un'offerta) DOVREBBE (SHOULD) costruire l'offerta come se il UAS stesse facendo una chiamata del tutto nuova, soggetto ai vincoli di invio di un'offerta che aggiorna una sessione esistente, come descritto in [13] nel caso di SDP. Più precisamente, ciò significa che DOVREBBE (SHOULD) includere tutti i formati e tipi di media che il UA è disposto a supportare. Il UAS DEVE (MUST) assicurarsi che la descrizione di sessione si sovrapponga alla sua descrizione di sessione precedente nei formati media, trasporti o altri parametri che richiedono il supporto del peer. Ciò serve a evitare che il peer debba rifiutare la descrizione di sessione. Se, tuttavia, essa è inaccettabile per il UAC, il UAC DOVREBBE (SHOULD) generare una risposta con una descrizione di sessione valida, poi inviare un BYE per terminare la sessione.