1. Introduction (Introduzione)

Questo documento descrive come l'interfaccia W3C Web Real-Time Communication (WebRTC) RTCPeerConnection [W3C.webrtc] viene utilizzata per controllare la configurazione, la gestione e la chiusura di una sessione multimediale.

1.1 General Design of JSEP (Progettazione generale di JSEP)

La configurazione delle chiamate WebRTC è stata progettata per concentrarsi sul controllo del piano media, lasciando il comportamento del piano di segnalazione all'applicazione il più possibile. La motivazione è che diverse applicazioni potrebbero preferire utilizzare protocolli diversi, come il protocollo di segnalazione di chiamata SIP esistente, o qualcosa di personalizzato per l'applicazione particolare, forse per un caso d'uso innovativo. In questo approccio, le informazioni chiave che devono essere scambiate sono la descrizione della sessione multimediale, che specifica le informazioni di configurazione del trasporto e dei media necessarie per stabilire il piano media.

Tenendo conto di queste considerazioni, questo documento descrive il JavaScript Session Establishment Protocol (JSEP), che consente il controllo completo della macchina a stati di segnalazione da JavaScript. Come descritto sopra, JSEP assume un modello in cui un'applicazione JavaScript viene eseguita all'interno di un runtime contenente API WebRTC (l'"implementazione JSEP"). L'implementazione JSEP è quasi completamente separata dal flusso di segnalazione principale, che è invece gestito dal JavaScript utilizzando due interfacce: (1) passaggio di descrizioni di sessione locali e remote e (2) interazione con la macchina a stati Interactive Connectivity Establishment (ICE) [RFC8445]. La combinazione dell'implementazione JSEP e dell'applicazione JavaScript è denominata "endpoint JSEP" in tutto questo documento.

In questo documento, l'uso di JSEP è descritto come se avvenisse sempre tra due endpoint JSEP. Si noti, tuttavia, che in molti casi avverrà effettivamente tra un endpoint JSEP e un qualche tipo di server, come un gateway o una Multipoint Control Unit (MCU). Questa distinzione è invisibile per l'endpoint JSEP; esso segue semplicemente le istruzioni che gli vengono date tramite l'API.

La gestione delle descrizioni di sessione da parte di JSEP è semplice e diretta. Ogni volta che è necessario uno scambio offerta/risposta, il lato iniziatore crea un'offerta chiamando un'API createOffer. L'applicazione utilizza quindi quell'offerta per configurare la sua configurazione locale tramite l'API setLocalDescription. L'offerta viene infine inviata al lato remoto tramite il suo meccanismo di segnalazione preferito (ad es., WebSockets); al ricevimento di quell'offerta, la parte remota la installa utilizzando l'API setRemoteDescription.

Per completare lo scambio offerta/risposta, la parte remota utilizza l'API createAnswer per generare una risposta appropriata, la applica utilizzando l'API setLocalDescription e invia la risposta all'iniziatore tramite il canale di segnalazione. Quando l'iniziatore riceve quella risposta, la installa utilizzando l'API setRemoteDescription e la configurazione iniziale è completa. Questo processo può essere ripetuto per ulteriori scambi offerta/risposta.

Per quanto riguarda ICE [RFC8445], JSEP disaccoppia la macchina a stati ICE dalla macchina a stati di segnalazione complessiva. La macchina a stati ICE deve rimanere nell'implementazione JSEP perché solo l'implementazione ha la conoscenza necessaria dei candidati e di altre informazioni di trasporto. L'esecuzione di questa separazione fornisce ulteriore flessibilità nei protocolli che disaccoppiano le descrizioni di sessione dal trasporto. Ad esempio, nel SIP tradizionale, ogni offerta o risposta è autonoma, includendo sia le descrizioni di sessione che le informazioni di trasporto. Tuttavia, [RFC8840] consente l'utilizzo di SIP con Trickle ICE [RFC8838], in cui la descrizione della sessione può essere inviata immediatamente e le informazioni di trasporto possono essere inviate quando disponibili. L'invio separato delle informazioni di trasporto può consentire un avvio ICE e DTLS più rapido, poiché i controlli ICE possono iniziare non appena sono disponibili informazioni di trasporto anziché attendere tutte. Il disaccoppiamento di JSEP tra le macchine a stati ICE e di segnalazione gli consente di adattarsi a entrambi i modelli.

Sebbene astraga la segnalazione, l'approccio JSEP richiede che l'applicazione sia consapevole del processo di segnalazione. Mentre l'applicazione non deve comprendere il contenuto delle descrizioni di sessione per configurare una chiamata, l'applicazione deve chiamare le API giuste al momento giusto, convertire le descrizioni di sessione e le informazioni ICE nei messaggi definiti del suo protocollo di segnalazione scelto e eseguire la conversione inversa sui messaggi che riceve dall'altro lato.

Un modo per rendere la vita più facile all'applicazione è fornire una libreria JavaScript che nasconda questa complessità allo sviluppatore; tale libreria implementerebbe un determinato protocollo di segnalazione insieme alla sua macchina a stati e al codice di serializzazione, presentando un'interfaccia orientata alle chiamate di livello superiore allo sviluppatore dell'applicazione. Ad esempio, esistono librerie per fornire implementazioni dei protocolli di segnalazione SIP [RFC3261] ed Extensible Messaging and Presence Protocol (XMPP) [RFC6120] sopra l'API JSEP. Pertanto, JSEP fornisce un maggiore controllo per lo sviluppatore esperto senza forzare alcuna complessità aggiuntiva sullo sviluppatore principiante.

1.2 Other Approaches Considered (Altri approcci considerati)

Un approccio considerato al posto di JSEP era includere un protocollo di segnalazione leggero. Invece di fornire descrizioni di sessione all'API, l'API produrrebbe e consumerebbe messaggi da questo protocollo. Pur fornendo un'API di livello più alto, questo metteva più controllo della segnalazione all'interno dell'implementazione JSEP, costringendola a dover comprendere e gestire concetti come il conflitto di segnalazione (vedere [RFC3264], Sezione 4).

Un secondo approccio considerato ma non scelto era disaccoppiare la gestione degli oggetti di controllo media dalle descrizioni di sessione, offrendo invece API che controllerebbero direttamente ogni componente. Questo è stato respinto sulla base dell'argomento che richiedere l'esposizione di questo livello di complessità al programmatore dell'applicazione non sarebbe benefico; ciò (1) risulterebbe in un'API dove anche un semplice esempio richiederebbe una quantità significativa di codice per orchestrare tutte le interazioni necessarie e (2) creerebbe una grande superficie API che dovrebbe essere concordata e documentata. Inoltre, questi punti API potrebbero essere chiamati in qualsiasi ordine, risultando in un insieme più complesso di interazioni con il sottosistema media rispetto all'approccio JSEP, che specifica come le descrizioni di sessione devono essere valutate e applicate.

Una variazione di JSEP considerata era mantenere l'API di base orientata alla descrizione della sessione ma spostare il meccanismo per generare offerte e risposte fuori dall'implementazione JSEP. Invece di fornire metodi createOffer/createAnswer all'interno dell'implementazione, questo approccio esporrebbe invece un'API getCapabilities, che fornirebbe all'applicazione le informazioni necessarie per generare le proprie descrizioni di sessione. Questo aumenta la quantità di lavoro che l'applicazione deve fare; deve sapere come generare descrizioni di sessione dalle capacità, e soprattutto come generare la risposta corretta da un'offerta arbitraria e dalle capacità supportate. Mentre questo potrebbe certamente essere affrontato utilizzando una libreria come quella menzionata sopra, fondamentalmente forza l'uso di tale libreria anche per un semplice esempio. Fornire createOffer/createAnswer evita questo problema.

1.3 Contradiction regarding bundle-only "m=" sections (Contraddizione riguardante le sezioni "m=" bundle-only)

Dall'approvazione dei documenti di specifica WebRTC, l'IETF è diventato consapevole di un'incoerenza tra il documento che specifica JSEP e il documento che specifica BUNDLE (questa RFC e [RFC8843], rispettivamente). Piuttosto che ritardare ulteriormente la pubblicazione per giungere a una risoluzione, i documenti vengono pubblicati come originariamente approvati. L'IETF intende riprendere il lavoro su queste tecnologie e versioni riviste di questi documenti saranno pubblicate non appena sarà disponibile una risoluzione.

Il problema specifico riguarda la gestione delle sezioni "m=" designate come bundle-only, come discusso nella Sezione 4.1.1 di questa RFC. Attualmente, c'è divergenza tra JSEP e BUNDLE, così come tra queste specifiche e le implementazioni dei browser esistenti:

JSEP prescrive che tali sezioni "m=" dovrebbero utilizzare la porta zero e aggiungere un attributo "a=bundle-only" nelle offerte iniziali, ma non nelle risposte o nelle offerte successive.
BUNDLE prescrive che queste sezioni "m=" dovrebbero essere contrassegnate come descritto nel punto precedente, ma in tutte le offerte e risposte.
La maggior parte dei browser attuali non contrassegna alcuna sezione "m=" con porta zero e utilizza invece la stessa porta per tutte le sezioni "m=" raggruppate; alcuni altri seguono il comportamento JSEP.