4.1.10.1. Use of Provisional Answers (Uso delle risposte provvisorie)
4.1.10.1. Use of Provisional Answers (Uso delle risposte provvisorie)
La maggior parte delle applicazioni non avrà bisogno di creare risposte utilizzando il tipo "pranswer". Sebbene sia buona pratica inviare una risposta immediata a un'offerta, al fine di preriscaldare il trasporto della sessione e prevenire il taglio dei media, la gestione preferita per un'applicazione JSEP è creare e inviare una risposta finale "sendonly" con un MediaStreamTrack nullo immediatamente dopo aver ricevuto l'offerta, che impedirà ai media di essere inviati dal chiamante e consentirà ai media di essere inviati immediatamente alla risposta da parte del chiamato. Successivamente, quando il chiamato accetta effettivamente la chiamata, l'applicazione può collegare il vero MediaStreamTrack e creare una nuova offerta "sendrecv" per aggiornare la coppia offerta/risposta precedente e avviare il flusso multimediale bidirezionale. Sebbene questo possa essere fatto anche con una pranswer "sendonly" seguita da una risposta "sendrecv", la pranswer iniziale lascia aperto lo scambio offerta/risposta, il che significa che il chiamante non può inviare un'offerta aggiornata durante questo periodo.
Come esempio, consideriamo un'applicazione JSEP tipica che desidera configurare audio e video il più rapidamente possibile. Quando il chiamato riceve un'offerta con MediaStreamTrack audio e video, invierà una risposta immediata accettando queste tracce come sendonly (il che significa che il chiamante non invierà ancora alcun media al chiamato, e poiché il chiamato non ha ancora aggiunto i propri MediaStreamTrack, anche il chiamato non invierà alcun media). Chiederà quindi all'utente di accettare la chiamata e acquisire le tracce locali necessarie. All'accettazione da parte dell'utente, l'applicazione collegherà le tracce che ha acquisito, che, poiché l'handshaking ICE e l'handshaking DTLS probabilmente sono stati completati a questo punto, possono iniziare a trasmettere immediatamente. L'applicazione invierà anche una nuova offerta al lato remoto indicando l'accettazione della chiamata e spostando audio e video per essere media bidirezionali. Un flusso di esempio dettagliato lungo queste linee è mostrato nella Sezione 7.3.
Naturalmente, alcune applicazioni potrebbero non essere in grado di eseguire questo doppio scambio offerta/risposta, in particolare quelle che stanno tentando di fare da gateway a protocolli di segnalazione legacy. In questi casi, pranswer può comunque fornire all'applicazione un meccanismo per preriscaldare il trasporto.