1. Introduction (Introduzione)
Internet è stato, fin dall'inizio della sua esistenza, considerato un possibile veicolo per la distribuzione di applicazioni interattive in tempo reale -- essendo le più facilmente immaginabili le conversazioni audio (alias "telefonia Internet") e le videoconferenze.
I primi tentativi di costruire tali applicazioni dipendevano da reti speciali, hardware speciale e software personalizzato, spesso a prezzi molto elevati o di bassa qualità, ponendo grandi richieste sull'infrastruttura.
Man mano che la larghezza di banda disponibile è aumentata e i processori e altro hardware sono diventati sempre più veloci, le barriere alla partecipazione sono diminuite ed è diventato possibile fornire un'esperienza soddisfacente su hardware di calcolo comunemente disponibile.
Tuttavia, esistono ancora numerose barriere alla capacità di comunicare universalmente -- una di queste è che, ad oggi, non esiste un singolo insieme di protocolli di comunicazione su cui tutti concordano dovrebbe essere reso disponibile per la comunicazione; un'altra è la pura mancanza di sistemi di identificazione universali (come quelli forniti dai numeri di telefono o dagli indirizzi e-mail in altri sistemi di comunicazione).
Lo sviluppo de "La Soluzione Universale" si è tuttavia dimostrato difficile.
Gli ultimi anni hanno anche visto l'ascesa di una nuova piattaforma per la distribuzione di servizi: l'applicazione incorporata nel browser (Browser-Embedded Application), o "applicazione web (Web Application)". Si scopre che, finché la piattaforma del browser ha le interfacce necessarie, è possibile fornire quasi qualsiasi tipo di servizio su di essa.
Tradizionalmente, queste interfacce sono state fornite da plugin, che dovevano essere scaricati e installati separatamente dal browser; nello sviluppo di HTML5 [HTML5], gli sviluppatori di applicazioni vedono grandi promesse nella possibilità di rendere disponibili queste interfacce in modo standardizzato all'interno del browser.
Questo memo descrive un insieme di blocchi di costruzione (Building Blocks) che (1) possono essere resi accessibili e controllabili tramite un'API JavaScript in un browser e (2) insieme formano un insieme sufficiente di funzioni per consentire l'uso di audio e video interattivi in applicazioni che comunicano direttamente tra browser attraverso Internet. La suite di protocolli risultante è destinata a abilitare tutte le applicazioni descritte come scenari richiesti nel documento "casi d'uso" WebRTC [RFC7478].
Altri sforzi -- ad esempio, i gruppi di lavoro W3C Web Real-Time Communications, Web Applications Security e Devices and Sensors -- si concentrano sulla messa a disposizione di API e interfacce standardizzate, all'interno o accanto allo sforzo HTML5, per queste funzioni. Questo memo si concentra sulla specificazione dei protocolli e sottoprotocolli necessari per specificare le interazioni sulla rete.
Gli operatori dovrebbero notare che la distribuzione di WebRTC comporterà un cambiamento nella natura della segnalazione per i media in tempo reale sulla rete e può comportare uno spostamento nei tipi di dispositivi utilizzati per creare e consumare tali media. Nel caso della segnalazione, la configurazione della sessione WebRTC avverrà tipicamente tramite tecnologie web protette da TLS utilizzando protocolli specifici dell'applicazione. Le tecniche operative che coinvolgono l'inserimento di elementi di rete per interpretare il Session Description Protocol (SDP) -- tramite (1) l'endpoint che chiede alla rete un server SIP [RFC3361] o (2) l'inserimento trasparente di Application Layer Gateways (ALGs) SIP -- non funzioneranno con tale segnalazione. Nel caso di reti che utilizzano endpoint cooperativi, gli approcci definiti in [RFC8155] possono servire come sostituto appropriato per [RFC3361]. L'aumento delle comunicazioni basate su browser può anche portare a uno spostamento dai dispositivi hardware di comunicazione in tempo reale dedicati, come i telefoni da scrivania SIP. Ciò diminuirà l'efficacia delle tecniche operative che collocano dispositivi in tempo reale dedicati sul proprio segmento di rete, intervallo di indirizzi o VLAN per scopi come l'applicazione del filtraggio del traffico e della QoS. L'applicazione delle marcature descritte in [RFC8837] può essere un sostituto appropriato per tali tecniche.
Sebbene questo documento si basi formalmente su [RFC8445], al momento della sua pubblicazione, la maggioranza delle implementazioni WebRTC supporta la versione di Interactive Connectivity Establishment (ICE) descritta in [RFC5245] e utilizza una versione pre-standard del meccanismo Trickle ICE descritto in [RFC8838]. L'attributo "ice2" definito in [RFC8445] può essere utilizzato per rilevare la versione in uso da un endpoint remoto e per fornire una transizione fluida dalla specifica più vecchia a quella più recente.
Questo memo utilizza il termine "WebRTC" (notare la maiuscola usata) per riferirsi allo sforzo complessivo consistente sia negli sforzi IETF che W3C.