3. Architecture and Functionality Groups (Architettura e gruppi funzionali)
Il modello di supporto in tempo reale per le applicazioni basate su browser non presume che il browser conterrà tutte le funzioni richieste da applicazioni come telefonia o videoconferenza. La visione è che il browser avrà le funzioni necessarie per l'applicazione web, lavorando in cooperazione con i suoi server backend per implementare queste funzioni.
Ciò significa che è necessario specificare due interfacce importanti: i protocolli che il browser utilizza per comunicare tra loro senza alcun server intermedio e l'API fornita alle applicazioni JavaScript per sfruttare le capacità del browser.
+------------------------+ On-the-wire
| | Protocols
| Servers |--------->
| |
| |
+------------------------+
^
|
|
| HTTPS/
| WebSockets
|
|
+----------------------------+
| JavaScript/HTML/CSS |
+----------------------------+
Other ^ ^ RTC
APIs | | APIs
+---|-----------------|------+
| | | |
| +---------+|
| | Browser || On-the-wire
| Browser | RTC || Protocols
| | Function|----------->
| | ||
| | ||
| +---------+|
+---------------------|------+
|
V
Native OS Services
Figura 1: Modello di browser
Si noti che HTTPS e WebSockets sono anche resi disponibili alle applicazioni JavaScript tramite API del browser.
Come con tutte le specifiche di protocollo e API, i protocolli non sono limitati all'uso solo per comunicare con un altro browser; essendo completamente specificati, qualsiasi endpoint che implementi fedelmente i protocolli dovrebbe essere in grado di interoperare con applicazioni in esecuzione nel browser.
La Figura 2 descrive un modello di distribuzione comune. ("JS" sta per JavaScript.)
+-----------+ +-----------+
| Web | | Web |
| | | |
| |------------------| |
| Server | Signaling Path | Server |
| | | |
+-----------+ +-----------+
/ \
/ \ Application-defined
/ \ over
/ \ HTTPS/WebSockets
/ Application-defined over \
/ HTTPS/WebSockets \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ +-----------+
| | | |
| | | |
| Browser |--------------------------------| Browser |
| | Media Path | |
| | | |
+-----------+ +-----------+
Figura 2: Trapezoide RTC del browser
In questo diagramma, le parti essenziali da notare sono che il percorso media (il "percorso inferiore") va direttamente tra i browser, quindi deve essere conforme alle specifiche della suite di protocolli WebRTC; il percorso di segnalazione (il "percorso superiore") passa attraverso i server, che possono modificare, tradurre o manipolare i segnali secondo necessità.
Se i due server web sono gestiti da entità diverse, è necessario un accordo sul meccanismo di segnalazione inter-server tramite standardizzazione o altri mezzi di protocollo. I protocolli esistenti (ad esempio, SIP [RFC3261] o Extensible Messaging and Presence Protocol (XMPP) [RFC6120]) possono essere utilizzati tra i server, e protocolli basati su standard o proprietari possono essere utilizzati tra il browser e il server web.
Ad esempio, se i server di entrambi gli operatori implementano SIP, allora SIP può essere utilizzato per la comunicazione tra i server, mentre un meccanismo di segnalazione standardizzato (ad esempio, SIP over WebSockets) o proprietario viene utilizzato tra l'applicazione in esecuzione nel browser e il server web. Allo stesso modo, se i server di entrambi gli operatori implementano XMPP, allora XMPP può essere utilizzato tra i server XMPP, mentre un meccanismo di segnalazione standardizzato (ad esempio, XMPP over WebSockets o Bidirectional-streams Over Synchronous HTTP (BOSH) [XEP-0124]) o proprietario viene utilizzato tra l'applicazione in esecuzione nel browser e il server web.
La scelta dei protocolli per la segnalazione client-server e inter-server, e la definizione delle traduzioni tra di essi, sono al di fuori dell'ambito della suite di protocolli WebRTC descritta in questo documento.
I gruppi funzionali necessari nel browser possono essere, più o meno, specificati dal basso verso l'alto come segue:
Data transport (Trasporto dati): Ad esempio, TCP e UDP, nonché i mezzi per stabilire connessioni in modo sicuro tra entità, e funzionalità per decidere quando inviare dati: gestione della congestione (Congestion Management), stima della larghezza di banda (Bandwidth Estimation), ecc.
Data framing (Inquadramento dati): RTP, Stream Control Transmission Protocol (SCTP), DTLS e altri formati di dati utilizzati come contenitori, e le loro funzionalità per la riservatezza e l'integrità dei dati.
Data formats (Formati dati): Specifiche codec (Codec Specifications), specifiche di formato (Format Specifications) e specifiche di funzionalità per i dati passati tra i sistemi. I codec audio e video, nonché i formati per la condivisione di dati e documenti, rientrano tutti in questa categoria. Per utilizzare un formato di dati, è necessario un modo per descriverli (ad esempio, descrizione di sessione (Session Description)).
Connection management (Gestione connessione): Ad esempio, stabilire connessioni, accordarsi sui formati di dati, modificare i formati di dati durante una chiamata. SDP, SIP e Jingle/XMPP rientrano in questa categoria.
Presentation and control (Presentazione e controllo): Ciò che deve accadere per garantire che le interazioni avvengano in modo non sorprendente. Questo può includere il controllo della parola (Floor Control), il layout dello schermo (Screen Layout), la commutazione di immagini attivata dalla voce (Voice-Activated Image Switching) e altre funzionalità di questo tipo, dove una parte del sistema deve cooperare tra le parti. Centralized Conferencing (XCON) [RFC6501] e il Telepresence Interoperability Protocol (TIP) di Cisco/Tandberg sono alcuni tentativi di specificare tali funzionalità; molte applicazioni sono costruite senza interfacce standardizzate per queste funzioni.
Local system support functions (Funzioni di supporto del sistema locale): Funzioni che non devono essere specificate in modo uniforme perché ogni partecipante può implementarle secondo la propria scelta senza influenzare i bit sul filo in un modo di cui gli altri devono preoccuparsi. Gli esempi in questa categoria includono la cancellazione dell'eco (Echo Cancellation) (alcune forme di essa), i meccanismi di autenticazione e autorizzazione locale (Local Authentication and Authorization Mechanisms), il controllo degli accessi al sistema operativo (OS Access Control) e la capacità di registrazione locale di una conversazione.
In ciascun gruppo funzionale, è importante preservare sia la libertà di innovazione che la capacità di comunicazione globale. La libertà di innovazione è aiutata specificando in termini di interfacce piuttosto che in termini di implementazioni; qualsiasi implementazione in grado di comunicare secondo le interfacce è un'implementazione valida. La capacità di comunicazione globale è aiutata avendo: (1) le specifiche di base non ostacolate da problemi di proprietà intellettuale (IPR), e (2) le specifiche di formati e protocolli sufficientemente complete da consentire implementazioni indipendenti.
Si può considerare i primi tre gruppi come formanti "l'infrastruttura di trasporto media (Media Transport Infrastructure)" e gli ultimi tre gruppi come formanti il "servizio media (Media Service)". In molti casi, ha senso utilizzare specifiche comuni per l'infrastruttura di trasporto media che possono essere incorporate nel browser e accessibili utilizzando interfacce standard, e "lasciare che mille fiori sboccino" nello strato "servizio media"; tuttavia, per realizzare un servizio interoperabile, è necessario specificare almeno i primi cinque dei sei gruppi.