12. Usage with SIP (Utilizzo con SIP)
12.1. Latency Guidelines (Linee guida sulla latenza)
ICE richiede che abbia luogo una serie di controlli di connettività basati su STUN tra gli endpoint. Questi controlli iniziano dal risponditore alla generazione della sua risposta e iniziano dall'offerente quando riceve la risposta. Questi controlli possono richiedere tempo per essere completati e, come tale, la selezione dei messaggi da utilizzare con offerte e risposte può influenzare la latenza percepita dall'utente. Due cifre di latenza sono di particolare interesse. Questi sono il ritardo post-risposta (post-pickup delay) e il ritardo post-composizione (post-dial delay). Il ritardo post-risposta si riferisce al tempo che intercorre tra quando un utente "risponde al telefono" e quando qualsiasi discorso che pronuncia può essere consegnato al chiamante. Il ritardo post-composizione si riferisce al tempo che intercorre tra quando un utente inserisce l'indirizzo di destinazione per l'utente e l'inizio del segnale di libero come conseguenza dell'aver avviato con successo lo squillo del telefono della parte chiamata.
Si possono considerare due casi: uno in cui l'offerta è presente nell'INVITE iniziale e uno in cui è in una risposta.
12.1.1. Offer in INVITE (Offerta in INVITE)
Per ridurre i ritardi post-composizione, è RECOMMENDED che il chiamante inizi a raccogliere candidati prima di inviare effettivamente il suo INVITE iniziale. Questo può essere avviato su segnali dell'interfaccia utente che una chiamata è in sospeso, come l'attività su una tastiera o il telefono che viene sganciato.
Se un'offerta viene ricevuta in una richiesta INVITE, il risponditore SHOULD iniziare a raccogliere i suoi candidati alla ricezione dell'offerta e quindi generare una risposta in una risposta provvisoria una volta completato quel processo. ICE richiede che una risposta provvisoria con un SDP sia trasmessa in modo affidabile. Questo può essere fatto attraverso il meccanismo esistente di riconoscimento della risposta provvisoria (PRACK) [RFC3262] o attraverso un'ottimizzazione specifica per ICE. Con questa ottimizzazione, le risposte provvisorie contenenti una risposta SDP che avvia l'elaborazione ICE per uno o più flussi multimediali possono essere inviate in modo affidabile senza RFC 3262. Per fare ciò, l'agente ritrasmette la risposta provvisoria con i timer di backoff esponenziale descritti in RFC 3262. Le ritrasmissioni MUST cessare alla ricezione di una richiesta STUN Binding per uno dei flussi multimediali segnalati in quell'SDP (perché la ricezione di una richiesta Binding indica che l'offerente ha ricevuto la risposta) o alla trasmissione della risposta in una risposta 2xx. Se l'agente peer è lite, non ci sarà mai una richiesta STUN Binding. In tal caso, l'agente MUST cessare di ritrasmettere il 18x dopo averlo inviato quattro volte (ICE funzionerà effettivamente anche se il peer non riceve mai il 18x; tuttavia, l'esperienza ha dimostrato che inviarlo è importante per i middlebox e l'attraversamento del firewall). Se non viene ricevuta alcuna richiesta Binding prima dell'ultima ritrasmissione, l'agente non considera terminata la sessione. Nonostante il fatto che la risposta provvisoria sarà consegnata in modo affidabile, le regole per quando un agente può inviare un'offerta o una risposta aggiornata non cambiano da quelle specificate in RFC 3262. In particolare, se l'INVITE conteneva un'offerta, la stessa risposta appare in tutti gli 1xx e nella risposta 2xx all'INVITE. Solo dopo che quel 2xx è stato inviato può avvenire uno scambio offerta/risposta aggiornato. Questa ottimizzazione SHOULD NOT essere utilizzata se entrambi gli agenti supportano PRACK. Si noti che l'ottimizzazione è molto specifica per la risposta provvisoria che trasporta risposte che avviano l'elaborazione ICE; non è una tecnica generale per l'affidabilità 1xx.
In alternativa, un agente MAY ritardare l'invio di una risposta fino al 200 OK; tuttavia, ciò si traduce in una scarsa esperienza utente ed è NOT RECOMMENDED.
Una volta inviata la risposta, l'agente SHOULD iniziare i suoi controlli di connettività. Una volta che le coppie di candidati per ciascun componente di un flusso multimediale entrano nell'elenco valido, il risponditore può iniziare a inviare media su quel flusso multimediale.
Tuttavia, prima di questo punto, qualsiasi supporto che deve essere inviato verso il chiamante (come SIP early media [RFC3960]) MUST NOT essere trasmesso. Per questo motivo, le implementazioni SHOULD ritardare l'avviso della parte chiamata fino a quando i candidati per ciascun componente di ciascun flusso multimediale non sono entrati nell'elenco valido. Nel caso di un gateway PSTN, ciò significherebbe che il messaggio di configurazione nella PSTN viene ritardato fino a questo punto. Fare ciò aumenta il ritardo post-composizione, ma ha l'effetto di eliminare gli "squilli fantasma". Gli squilli fantasma sono casi in cui la parte chiamata sente squillare il telefono, risponde, ma non sente nulla e non può essere sentita. Questa tecnica funziona senza richiedere supporto o utilizzo di precondizioni [RFC3312], poiché è una decisione localizzata. Ha anche il vantaggio di garantire che non un singolo pacchetto di media verrà tagliato, in modo che il ritardo post-risposta sia zero. Se un agente sceglie di ritardare l'avviso locale in questo modo, SHOULD generare una risposta 180 una volta iniziato l'avviso.
12.1.2. Offer in Response (Offerta in risposta)
Oltre agli usi in cui l'offerta è in un INVITE e la risposta è nella risposta provvisoria e/o 200 OK, ICE funziona con i casi in cui l'offerta appare nella risposta. In tali casi, che sono comuni nel controllo delle chiamate di terze parti [RFC3725], gli agenti ICE SHOULD generare le loro offerte in una risposta provvisoria affidabile (che MUST utilizzare RFC 3262) e non avvisare l'utente alla ricezione dell'INVITE. La risposta arriverà in un PRACK. Ciò consente all'elaborazione ICE di aver luogo prima dell'avviso, in modo che non vi sia alcun ritardo post-risposta, a scapito di un aumento dei ritardi di configurazione della chiamata. Una volta completato ICE, il chiamato può avvisare l'utente e quindi generare un 200 OK quando risponde. Il 200 OK non conterrebbe alcun SDP, poiché lo scambio offerta/risposta è completato.
In alternativa, gli agenti MAY inserire invece l'offerta in un 2xx (nel qual caso la risposta arriva nell'ACK). Quando ciò accade, il chiamato avviserà l'utente alla ricezione dell'INVITE e gli scambi ICE avranno luogo solo dopo che l'utente avrà risposto. Ciò ha l'effetto di ridurre il ritardo di configurazione della chiamata, ma può causare notevoli ritardi post-risposta e taglio dei media.
12.2. SIP Option Tags and Media Feature Tags (Tag di opzione SIP e tag di funzionalità multimediali)
[RFC5768] specifica un tag di opzione SIP e un tag di funzionalità multimediale per l'utilizzo con ICE. Le implementazioni ICE che utilizzano SIP SHOULD supportare questa specifica, che utilizza un tag di funzionalità nelle registrazioni per facilitare l'interoperabilità attraverso intermediari di segnalazione.
12.3. Interactions with Forking (Interazioni con il forking)
ICE interagisce molto bene con il forking. In effetti, ICE risolve alcuni dei problemi associati al forking. Senza ICE, quando una chiamata si biforca e il chiamante riceve più flussi multimediali in entrata, non può determinare quale flusso multimediale corrisponde a quale chiamato.
Con ICE, questo problema è risolto. I controlli di connettività che si verificano prima della trasmissione dei media trasportano frammenti di nome utente, che a loro volta sono correlati a un chiamato specifico. I successivi pacchetti multimediali che arrivano sulla stessa coppia di candidati del controllo di connettività saranno associati a quello stesso chiamato. Pertanto, il chiamante può eseguire questa correlazione purché abbia ricevuto una risposta.
12.4. Interactions with Preconditions (Interazioni con le precondizioni)
Le precondizioni di Quality of Service (QoS), definite in RFC 3312 [RFC3312] e RFC 4032 [RFC4032], si applicano solo agli indirizzi di trasporto elencati come obiettivi predefiniti per i media in un'offerta/risposta.
Se ICE modifica l'indirizzo di trasporto in cui vengono ricevuti i media, questa modifica si riflette in un'offerta aggiornata che modifica la destinazione predefinita per i media in modo che corrisponda alla selezione di ICE. Come tale, appare come qualsiasi altro re-INVITE ed è completamente trattato nelle RFC 3312 e 4032, che si applicano indipendentemente dal fatto che la destinazione per i media stia cambiando a causa delle negoziazioni ICE che si verificano "in background".
In effetti, un agente SHOULD NOT indicare che le precondizioni QoS sono state soddisfatte fino a quando i controlli non sono stati completati e non sono state selezionate le coppie di candidati da utilizzare per i media.
ICE ha anche interazioni (intenzionali) con le precondizioni di connettività [SDP-PRECON]. Tali interazioni sono descritte lì. Si noti che le procedure descritte nella Sezione 12.1 descrivono il proprio tipo di "precondizioni", sebbene con meno funzionalità di quelle fornite dalle precondizioni esplicite in [SDP-PRECON].
12.5. Interactions with Third Party Call Control (Interazioni con il controllo delle chiamate di terze parti)
ICE funziona con i flussi I, III e IV come descritto in [RFC3725]. Il flusso I funziona senza che il controller supporti o sia a conoscenza di ICE. Il flusso IV funzionerà finché il controller trasmette gli attributi ICE senza alterazioni. Il flusso II è fondamentalmente incompatibile con ICE; ogni agente crederà di essere il risponditore e quindi non genererà mai un re-INVITE.
I flussi per il funzionamento continuato, come descritto nella Sezione 7 della RFC 3725, richiedono un comportamento aggiuntivo delle implementazioni ICE per il supporto. In particolare, se un agente riceve un re-INVITE a metà dialogo che non contiene alcuna offerta, MUST riavviare ICE per ogni flusso multimediale e passare attraverso il processo di raccolta di nuovi candidati. Inoltre, quell'elenco di candidati SHOULD includere quelli attualmente utilizzati per i media.