Percorsi multimediali per Video Call

Percorso di rete	STUN/Porta del server di inoltro
1: UDP peer-to-peer diretto, con attraversamento NAT assistito da server STUN Ciascun endpoint rileverà il proprio indirizzo Internet esterno utilizzando il server STUN fornito. Questo indirizzo viene fornito all'altro endpoint e utilizzato per configurare la connessione tramite Network Address Translation. I flussi multimediali su porte selezionate casualmente su un'ampia gamma di porte UDP 49152 - 65535.	3478 (UDP)
2: tramite server di inoltro chiamata video, utilizzando l'uscita con instradamento UDP Se non è possibile stabilire una connessione utilizzando il peer-to-peer diretto sopra, verrà tentata la porta UDP 3478 del server TURN configurata per stabilire un inoltro all'endpoint remoto. Questo indirizzo di inoltro viene fornito all'altro endpoint e utilizzato per configurare la connessione tramite l'inoltro, di nuovo tramite la connessione dell'endpoint locale al server TURN. I flussi multimediali alla porta UDP 3478 sul server TURN.	3478 (UDP)
3: tramite server di inoltro chiamata video, utilizzando l'uscita instradata TCP Se non è possibile stabilire una connessione tramite UDP al TURN Server, la connessione al TURN Server viene stabilita tramite TCP 443 e non UDP 3478. Il supporto scorre verso la porta TCP 443 sul TURN Server.	3478 (TCP)
4: tramite server di inoltro chiamata video, utilizzando il tunneling TCP tramite un server proxy Web locale Se non è possibile stabilire una connessione instradata tramite NAT al server TURN, verrà tentata una connessione in modalità tunnel alla porta TCP 443 tramite il server proxy Web configurato nel browser. I media fluiscono verso l'esterno attraverso il proxy web, alla porta TCP 443 sul TURN Server.	443 (TCP)
5a, 5b: tramite server di inoltro videochiamata, utilizzando Secure TCP Come per 3 o 4 sopra, ma utilizzando una connessione TLS TCP al TURN Server.	443 (TCP/TLS)

Percorso di rete

STUN/Porta del server di inoltro

1: UDP peer-to-peer diretto, con attraversamento NAT assistito da server STUN

Ciascun endpoint rileverà il proprio indirizzo Internet esterno utilizzando il server STUN fornito. Questo indirizzo viene fornito all'altro endpoint e utilizzato per configurare la connessione tramite Network Address Translation.

I flussi multimediali su porte selezionate casualmente su un'ampia gamma di porte UDP 49152 - 65535.

3478 (UDP)

2: tramite server di inoltro chiamata video, utilizzando l'uscita con instradamento UDP

Se non è possibile stabilire una connessione utilizzando il peer-to-peer diretto sopra, verrà tentata la porta UDP 3478 del server TURN configurata per stabilire un inoltro all'endpoint remoto. Questo indirizzo di inoltro viene fornito all'altro endpoint e utilizzato per configurare la connessione tramite l'inoltro, di nuovo tramite la connessione dell'endpoint locale al server TURN.

I flussi multimediali alla porta UDP 3478 sul server TURN.

3478 (UDP)

3: tramite server di inoltro chiamata video, utilizzando l'uscita instradata TCP

Se non è possibile stabilire una connessione tramite UDP al TURN Server, la connessione al TURN Server viene stabilita tramite TCP 443 e non UDP 3478.

Il supporto scorre verso la porta TCP 443 sul TURN Server.

3478 (TCP)

4: tramite server di inoltro chiamata video, utilizzando il tunneling TCP tramite un server proxy Web locale

Se non è possibile stabilire una connessione instradata tramite NAT al server TURN, verrà tentata una connessione in modalità tunnel alla porta TCP 443 tramite il server proxy Web configurato nel browser.

I media fluiscono verso l'esterno attraverso il proxy web, alla porta TCP 443 sul TURN Server.

443 (TCP)

5a, 5b: tramite server di inoltro videochiamata, utilizzando Secure TCP

Come per 3 o 4 sopra, ma utilizzando una connessione TLS TCP al TURN Server.

443 (TCP/TLS)

Raggiungere la migliore qualità di connessione

1. Per la maggior parte dei percorsi di rete, la negoziazione risulterà probabilmente in una connessione multimediale valida.

Il peer-to-peer diretto tramite UDP fornisce la migliore connessione , ma spesso non sarà disponibile nelle reti istituzionali, a causa dei vincoli di sicurezza delle loro politiche di rete.

Una connessione TCP protetta tramite tunnel è l'opzione meno desiderabile per il trasferimento dei media, ma molto probabilmente sarà supportata senza modifiche alla sicurezza della rete.

Opzione consigliata: per molte reti, consentendo l'uscita NAT alla porta UDP 3478 sul server di inoltro (percorso di rete 2, sopra) fornirà una bassa latenza con un sovraccarico ridotto. Ciò dovrebbe richiedere solo una piccola modifica a basso rischio alla configurazione di rete.

2. Per assicurarti che il traffico delle videochiamate abbia la priorità come comunicazione in tempo reale, guarda le opzioni seguenti:

Se il tuo router è in grado di assegnare la priorità al traffico con il valore del campo DSCP di 34 (noto anche come inoltro assicurato 41 o AF41), puoi configurarlo. Tutto il traffico WebRTC in tempo reale viene contrassegnato in questo modo e ciò migliorerà la qualità delle videochiamate e di altre soluzioni di videoconferenza.

Se il tuo router non è in grado di eseguire la funzionalità di cui sopra, puoi impostare QoS per dare la priorità ai pacchetti UDP nell'intervallo di porte 5000-40000 e questo aiuterà a dare la priorità ai pacchetti video e ridurre qualsiasi ritardo. WebRTC utilizza il protocollo RTP per fornire flussi multimediali e RTP generalmente utilizza UDP 5000-40000. Ciò potrebbe dare la priorità ad alcuni pacchetti che non ne hanno bisogno, ma la maggior parte saranno pacchetti RTP. L'impostazione della QoS in questo modo assicurerà che i flussi video abbiano il minor numero di interruzioni e jitter.