Passa al contenuto principale

3. Transport and Middlebox Specification (Specifica del trasporto e delle middlebox)

Questa sezione definisce i protocolli di trasporto e le funzioni di gestione delle middlebox che gli endpoint WebRTC devono supportare.

3.1. System-Provided Interfaces (Interfacce fornite dal sistema)​

Le specifiche di protocollo utilizzate qui presuppongono che i seguenti protocolli siano disponibili per le implementazioni dei protocolli WebRTC:

UDP [RFC0768]: Questo è il protocollo presunto dalla maggior parte degli elementi di protocollo descritti.

TCP [RFC0793]: Viene utilizzato per HTTP/WebSockets, nonché per TURN/TLS e ICE-TCP.

Per entrambi i protocolli, si presume il supporto IPv4 e IPv6.

Per UDP, questa specifica presume la capacità di impostare il Differentiated Services Code Point (DSCP) dei socket aperti su base per pacchetto, al fine di ottenere le priorità descritte in [RFC8837] (vedere la sezione 4.2 di questo documento) quando più tipi di media sono multiplexati. Non presume che i DSCP saranno rispettati e presume che possano essere azzerati o modificati, poiché si tratta di un problema di configurazione locale.

Le piattaforme che non forniscono accesso a queste interfacce non saranno in grado di supportare un endpoint WebRTC conforme.

Questa specifica non presume che l'implementazione avrà accesso a ICMP o IP grezzo.

I seguenti protocolli possono essere utilizzati, ma possono essere implementati da un endpoint WebRTC e pertanto non sono definiti come "interfacce fornite dal sistema":

  • TURN: Traversal Using Relays Around NAT [RFC8656]
  • STUN: Session Traversal Utilities for NAT [RFC5389]
  • ICE: Interactive Connectivity Establishment [RFC8445]
  • TLS: Transport Layer Security [RFC8446]
  • DTLS: Datagram Transport Layer Security [RFC6347]

3.2. Ability to Use IPv4 and IPv6 (Capacità di utilizzare IPv4 e IPv6)​

Le applicazioni Web in esecuzione in un browser WebRTC devono (MUST) essere in grado di utilizzare sia IPv4 che IPv6 dove disponibili -- ovvero, quando due peer hanno solo connettività IPv4 l'uno con l'altro, o hanno solo connettività IPv6 l'uno con l'altro, le applicazioni in esecuzione nel browser WebRTC devono (MUST) essere in grado di comunicare.

Quando viene utilizzato TURN e il server TURN ha connettività IPv4 o IPv6 al peer o al server TURN del peer, i candidati dei tipi appropriati devono (MUST) essere supportati. La specifica "Happy Eyeballs" per ICE [RFC8421] dovrebbe (SHOULD) essere supportata.

3.3. Usage of Temporary IPv6 Addresses (Utilizzo di indirizzi IPv6 temporanei)​

La specifica di selezione degli indirizzi predefiniti IPv6 [RFC6724] specifica che gli indirizzi temporanei [RFC4941] devono essere preferiti agli indirizzi permanenti. Questo è un cambiamento rispetto alle regole specificate da [RFC3484]. Per le applicazioni che selezionano un singolo indirizzo, questo viene solitamente fatto dal flag di preferenza IPV6_PREFER_SRC_TMP specificato in [RFC5014]. Tuttavia, questa regola, che ha lo scopo di garantire che gli indirizzi con privacy migliorata vengano utilizzati in preferenza agli indirizzi statici, non ha l'effetto giusto in ICE, dove tutti gli indirizzi vengono raccolti e quindi rivelati all'applicazione. Pertanto, viene applicata invece la seguente regola:

Quando un endpoint WebRTC raccoglie tutti gli indirizzi IPv6 sul suo host e sono presenti sia indirizzi temporanei non deprecati che indirizzi permanenti dello stesso ambito, l'endpoint WebRTC dovrebbe (SHOULD) scartare gli indirizzi permanenti prima di esporre gli indirizzi all'applicazione o utilizzarli in ICE. Ciò è coerente con la politica predefinita descritta in [RFC6724].

Se alcuni, ma non tutti, degli indirizzi IPv6 temporanei sono contrassegnati come deprecati, l'endpoint WebRTC dovrebbe (SHOULD) scartare gli indirizzi deprecati, a meno che non siano utilizzati da una connessione in corso. In un riavvio ICE, gli indirizzi deprecati attualmente in uso possono (MAY) essere mantenuti.

Il meccanismo principale per gestire le middlebox è ICE, che è un modo appropriato per gestire le box NAT e i firewall che accettano traffico dall'interno, ma solo dall'esterno se è in risposta al traffico interno (firewall stateful semplici).

ICE [RFC8445] deve (MUST) essere supportato. L'implementazione deve (MUST) essere un'implementazione ICE completa, non ICE-Lite. Un'implementazione ICE completa consente l'interoperabilità con implementazioni sia ICE che ICE-Lite quando sono distribuite in modo appropriato.

Per gestire situazioni in cui entrambe le parti sono dietro NAT del tipo che eseguono mapping dipendente dall'endpoint (come definito in [RFC5128], sezione 2.4), TURN [RFC8656] deve (MUST) essere supportato.

I browser WebRTC devono (MUST) supportare la configurazione di server STUN e TURN, sia dalla configurazione del browser che da un'applicazione.

Si noti che esistono altri lavori sulla scoperta e gestione dei server STUN e TURN, incluso [RFC8155] per la scoperta dei server, nonché [RETURN].

Per gestire i firewall che bloccano tutto il traffico UDP, la modalità TURN che utilizza TCP tra l'endpoint WebRTC e il server TURN deve (MUST) essere supportata, e la modalità TURN che utilizza TLS su TCP tra l'endpoint WebRTC e il server TURN deve (MUST) essere supportata. Vedere la sezione 3.1 di [RFC8656] per i dettagli.

Per gestire situazioni in cui una parte è su una rete IPv4 e l'altra parte è su una rete IPv6, le estensioni TURN per IPv6 devono (MUST) essere supportate.

I candidati TURN TCP, dove la connessione dal server TURN dell'endpoint WebRTC al peer è una connessione TCP, [RFC6062] possono (MAY) essere supportati.

Tuttavia, tali candidati non sono considerati come fornitori di alcun beneficio significativo, per i seguenti motivi.

In primo luogo, l'uso di candidati TURN TCP sarebbe rilevante solo nei casi in cui entrambi i peer sono tenuti a utilizzare TCP per stabilire una connessione.

In secondo luogo, quel caso d'uso è supportato in modo diverso da entrambe le parti che stabiliscono candidati relay UDP utilizzando TURN su TCP per connettersi ai rispettivi server relay.

In terzo luogo, l'utilizzo di TCP tra il server TURN dell'endpoint WebRTC e il peer può causare più problemi di prestazioni rispetto all'utilizzo di UDP, ad esempio a causa del blocco head-of-line.

I candidati ICE-TCP [RFC6544] devono (MUST) essere supportati; ciò può consentire alle applicazioni di comunicare con peer con indirizzi IP pubblici attraverso firewall che bloccano UDP senza utilizzare un server TURN.

Se vengono utilizzate connessioni TCP, il framing RTP secondo [RFC4571] deve (MUST) essere utilizzato per tutti i pacchetti. Ciò include i pacchetti RTP, i pacchetti DTLS utilizzati per trasportare i canali dati e i pacchetti di controllo della connettività STUN.

Il meccanismo ALTERNATE-SERVER specificato nella sezione 11 di [RFC5389] (300 Try Alternate) deve (MUST) essere supportato.

L'endpoint WebRTC può (MAY) supportare l'accesso a Internet tramite un proxy HTTP. Se lo fa, deve (MUST) includere l'intestazione "ALPN" come specificato in [RFC7639], e l'autenticazione proxy come descritto nella sezione 4.3.6 di [RFC7231] e [RFC7235] deve (MUST) essere anch'essa supportata.

3.5. Transport Protocols Implemented (Protocolli di trasporto implementati)​

Per il trasporto dei media, viene utilizzato RTP sicuro. I dettagli del profilo RTP utilizzato sono descritti in "Media Transport and Use of RTP in WebRTC" [RFC8834], che impone l'uso di un circuit breaker [RFC8083] e del controllo della congestione (vedere [RFC8836] per ulteriori indicazioni).

Lo scambio di chiavi deve (MUST) essere effettuato utilizzando DTLS-SRTP, come descritto in [RFC8827].

Per il trasporto dati sul canale dati WebRTC [RFC8831], gli endpoint WebRTC devono (MUST) supportare SCTP su DTLS su ICE. Questo incapsulamento è specificato in [RFC8261]. La negoziazione di questo trasporto nel Session Description Protocol (SDP) è definita in [RFC8841]. L'estensione SCTP per I-DATA [RFC8260] deve (MUST) essere supportata.

Il protocollo di configurazione per i canali dati WebRTC descritto in [RFC8832] deve (MUST) essere supportato.

Nota: L'interazione tra DTLS-SRTP come definito in [RFC5764] e ICE come definito in [RFC8445] è descritta nella sezione 6 di [RFC8842]. L'effetto di questa specifica è che tutte le coppie di candidati ICE associate a un singolo componente fanno parte della stessa associazione DTLS. Pertanto, ci sarà solo un handshake DTLS, anche se ci sono più coppie di candidati valide.

Gli endpoint WebRTC devono (MUST) supportare il multiplexing di DTLS e RTP sulla stessa coppia di porte, come descritto nella specifica DTLS-SRTP [RFC5764], sezione 5.1.2, con chiarimenti in [RFC7983]. Tutti i payload del protocollo a livello di applicazione su questa connessione DTLS sono pacchetti SCTP.

L'identificazione del protocollo deve (MUST) essere fornita come parte dell'handshake DTLS, come specificato in [RFC8833].

Ultimo aggiornamento il