3.2 Session Descriptions and State Machine (Descrizioni di sessione e macchina a stati)

Per stabilire il piano media, l'implementazione JSEP necessita di parametri specifici per indicare cosa trasmettere al lato remoto, nonché come gestire il media ricevuto. Questi parametri sono determinati dallo scambio di descrizioni di sessione nelle offerte e risposte, e ci sono certi dettagli di questo processo che devono essere gestiti nelle API JSEP.

Il fatto che una descrizione di sessione si applichi al lato locale o al lato remoto influenza il significato di quella descrizione. Ad esempio, l'elenco dei codec inviati a una parte remota indica ciò che il lato locale è disposto a ricevere, che, quando intersecato con l'insieme di codec supportati dal lato remoto, specifica ciò che il lato remoto dovrebbe inviare. Tuttavia, non tutti i parametri seguono questa regola; alcuni parametri sono dichiarativi e il lato remoto deve accettarli o rifiutarli completamente. Un esempio di tale parametro sono le impronte digitali TLS [RFC8122] come utilizzate nel contesto di DTLS [RFC6347]; queste impronte digitali sono calcolate in base ai certificati locali offerti e non sono soggette a negoziazione.

Inoltre, vari RFC pongono condizioni diverse sul formato delle offerte rispetto alle risposte. Ad esempio, un'offerta può proporre un numero arbitrario di sezioni "m=" (cioè descrizioni media come descritto in [RFC4566], Sezione 5.14), ma una risposta deve contenere esattamente lo stesso numero dell'offerta.

Infine, sebbene i parametri media esatti siano noti solo dopo che un'offerta e una risposta sono state scambiate, l'offerente può ricevere controlli ICE e possibilmente media (ad es., nel caso di una ri-offerta dopo che una connessione è stata stabilita) prima di ricevere una risposta. Per elaborare correttamente il media in arrivo in questo caso, il gestore media dell'offerente deve essere a conoscenza dei dettagli dell'offerta prima dell'arrivo della risposta.

Pertanto, per gestire correttamente le descrizioni di sessione, l'implementazione JSEP necessita di:

Sapere se una descrizione di sessione riguarda il lato locale o remoto.
Sapere se una descrizione di sessione è un'offerta o una risposta.
Consentire che l'offerta sia specificata indipendentemente dalla risposta.

JSEP affronta questo aggiungendo sia i metodi setLocalDescription che setRemoteDescription e facendo in modo che gli oggetti di descrizione della sessione contengano un campo tipo che indica il tipo di descrizione della sessione fornita. Questo soddisfa i requisiti elencati sopra sia per l'offerente, che prima chiama setLocalDescription(sdp [offer]) e poi successivamente setRemoteDescription(sdp [answer]), sia per il rispondente, che prima chiama setRemoteDescription(sdp [offer]) e poi successivamente setLocalDescription(sdp [answer]).

Durante lo scambio offerta/risposta, l'offerta in sospeso è considerata "in sospeso" presso l'offerente e il rispondente, in quanto può essere accettata o rifiutata. Se questa è una ri-offerta, ogni lato avrà anche descrizioni locali e remote "correnti", che riflettono il risultato dell'ultimo scambio offerta/risposta. Le sezioni 4.1.14, 4.1.16, 4.1.13 e 4.1.15 forniscono maggiori dettagli sulle descrizioni in sospeso e correnti.

JSEP consente anche che una risposta sia trattata come provvisoria dall'applicazione. Le risposte provvisorie forniscono un modo per un rispondente di comunicare parametri di sessione iniziali all'offerente, al fine di consentire l'inizio della sessione, consentendo al contempo di specificare una risposta finale successivamente. Questo concetto di risposta finale è importante per il modello offerta/risposta; quando viene ricevuta tale risposta, tutte le risorse aggiuntive allocate dal chiamante possono essere rilasciate, ora che la configurazione della sessione esatta è nota. Queste "risorse" possono includere cose come componenti ICE aggiuntivi, candidati Traversal Using Relays around NAT (TURN) o decodificatori video. Le risposte provvisorie, d'altra parte, non effettuano tale deallocazione; di conseguenza, più risposte provvisorie dissimili, con le proprie scelte di codec, parametri di trasporto, ecc., possono essere ricevute e applicate durante la configurazione della chiamata. Si noti che la risposta finale stessa può essere diversa da qualsiasi risposta provvisoria ricevuta.

In [RFC3264], il vincolo a livello di segnalazione è che solo un'offerta può essere in sospeso per una determinata sessione, ma a livello JSEP, una nuova offerta può essere generata in qualsiasi momento. Ad esempio, quando si utilizza SIP per la segnalazione, se un'offerta viene inviata e poi annullata utilizzando un CANCEL SIP, un'altra offerta può essere generata anche se non è stata ricevuta alcuna risposta per la prima offerta. Per supportare questo, il livello media JSEP può fornire un'offerta tramite il metodo createOffer ogni volta che l'applicazione JavaScript ne ha bisogno per la segnalazione. Il rispondente può inviare zero o più risposte provvisorie e quindi terminare finalmente lo scambio offerta/risposta inviando una risposta finale. La macchina a stati per questo è la seguente:

                    setRemote(OFFER)               setLocal(PRANSWER)
                        /-----\                               /-----\
                        |     |                               |     |
                        v     |                               v     |
         +---------------+    |                +---------------+    |
         |               |----/                |               |----/
         |  have-        | setLocal(PRANSWER)  | have-         |
         |  remote-offer |------------------- >| local-pranswer|
         |               |                     |               |
         |               |                     |               |
         +---------------+                     +---------------+
              ^   |                                   |
              |   | setLocal(ANSWER)                  |
setRemote(OFFER)  |                                   |
              |   V                  setLocal(ANSWER) |
         +---------------+                            |
         |               |                            |
         |               |<---------------------------+
         |    stable     |
         |               |<---------------------------+
         |               |                            |
         +---------------+          setRemote(ANSWER) |
              ^   |                                   |
              |   | setLocal(OFFER)                   |
setRemote(ANSWER) |                                   |
              |   V                                   |
         +---------------+                     +---------------+
         |               |                     |               |
         |  have-        | setRemote(PRANSWER) |have-          |
         |  local-offer  |------------------- >|remote-pranswer|
         |               |                     |               |
         |               |----\                |               |----\
         +---------------+    |                +---------------+    |
                        ^     |                               ^     |
                        |     |                               |     |
                        \-----/                               \-----/
                    setLocal(OFFER)               setRemote(PRANSWER)

                     Figure 2: JSEP State Machine

A parte queste transizioni di stato, non c'è altra differenza tra la gestione delle risposte provvisorie ("pranswer") e finali ("answer").

3.2 Session Descriptions and State Machine (Descrizioni di sessione e macchina a stati)​

3.2 Session Descriptions and State Machine (Descrizioni di sessione e macchina a stati)