2015-08-30 10 views
5

Possiedo un MCU WebRTC (kurento) in esecuzione su un indirizzo IP pubblico che serve alcuni client che inviano o ricevono solo audio Quindi ogni client è direttamente connesso con MCU (non tra loro) che ha un indirizzo IP pubblico.È necessario ICE per le applicazioni WebRTC client-server?

Q1: È ancora necessario utilizzare STUN e TURN per NAT traversale ?? se è così, perché ??
Q2: C'è qualche trucco in WebRTC nel browser che rimuoverebbe la necessità di STUN e TURN?

A mio parere: la maggior parte delle architetture client-server non ha alcuna difficoltà con i client dietro NAT. Qual è la differenza qui con webrtc?

risposta

4

Sì ICE è assolutamente necessario per WebRTC.

Q1: C'è ancora una necessità di utilizzare STUN e girare per NAT traversal ?? se è così, perché ??

per lo scenario si non è necessario utilizzare STUN o girare. Lasciami spiegare perché.

Ogni client che si trova nella rete privata si trova in un tipo di NAT che ha un indirizzo IP pubblico. Il mondo esterno non conosce l'indirizzo IP privato di questo client e anche se sapesse che non possono connettersi con il client senza conoscere l'indirizzo IP pubblico. Il server STUN viene utilizzato per raccogliere questo indirizzo IP pubblico.

Quindi se il tuo server desidera avviare la connessione, allora ha bisogno del client per inviare l'IP pubblico del suo NAT. Il client utilizzerà il server STUN per conoscerne l'IP pubblico e inviarlo al server. Ma se il client avvia la connessione, non è necessario conoscere l'IP pubblico del NAT. Il client può inviare pacchetti al server pubblico per avviare la connessione. Il server può conoscere l'IP pubblico cilents dal pacchetto client e quindi possono connettersi. Quindi non c'è bisogno di STUN.

Il server sta svolgendo il ruolo di TURN in questo scenario. Quindi non hai bisogno del server TURN.

Q2: C'è qualche trucco in WebRTC nel browser che rimuoverebbe la necessità di STUN e TURN?

Non c'è nessun trucco. A seconda degli scenari viene utilizzato TURN/STUN. Per il tuo scenario non ti serve. Se si desidera creare una connessione client-client, sarebbe necessario disporre del server STUN.

+0

Come devo implementare il client in modo che avvii la connessione webrtc? Sembra che non abbiamo alcun controllo su chi inizia in webrtc! –

+0

Scrivi l'app, decidi chi invia l'offerta. –

+0

ICE funziona con l'offerta, modello di risposta. L'offerta di fine invio è colui che avvia la connessione. Un'offerta di invio di fine significa inviare la descrizione della sessione, che in realtà è informazione ip, all'altra estremità. Quando l'altra estremità riceve, genera la sua descrizione della sessione che è chiamata risposta e la invia all'altra estremità. Dopo che inizia il controllo del ghiaccio. Quindi è necessario avere accesso al codice finale sia client che server. Dal codice finale del cliente è necessario inviare l'offerta al server e dal codice finale del server ricevere questa offerta e generare e inviare la risposta al cliente. – Tahlil

1
  • ICE è obbligatoria
  • ma utilizzando qualsiasi stordimento e girare server non è.
  • poiché ci si connette a un server su una porta pubblica, non è necessario utilizzare un server TURN, ma a seconda del tipo di NAT/Firewall i vostri clienti sono alle spalle, potrebbe essere necessario un server STUN
  • non è necessario per modificare i browser. L'applicazione decide se utilizzare o meno un server di stordimento. se si passa un parametro vuoto "icserver" all'oggetto peerconnection al momento della creazione, l'ICE UA nel browser genera solo candidati (locali) host.
+0

Come devo configurare la RTCPearConnetion su client e server in modo che il mio MCU agisca come TURN? –

+0

Non è necessario che l'MCU agisca come turno. Non c'è bisogno di tutto quel macchinario in più. Il tuo MCU è seduto su un indirizzo pubblico, quindi ICE (o ICE-Lite) è sufficiente. Il tuo server di segnalazione può dire a ogni client che si connette ad esso per avviare un handshake (cioè inviare un'offerta) al tuo MCU. –

Problemi correlati