WebRTC requires a control connection (HTTPS over 443) and separate audio and video stream channels in both directions, with audio and video connections over high UDP ports. High Ports are sometimes blocked on large enterprise networks. The attendee's browser sets up a bridge session using HTTPS. The bridge and browser then looks for the paths into and out of the webinar.net network.

To establish the channels through which audio and video are sent, webRTC uses a process called "discovering ICE candidates". This identifies the conference nodes in the bridge system and the available ports addresses/protocols to reach the nodes. The negotiation process first attempts the native protocols which use UDP High ports 40000-49999 for audio and video transit and do not support NAT. These are normally blocked inside corporate networks, but each session attempts to use them. If not successful, the system then attempts to use a relay (TURN) server, which uses TLS over TCP to move the audio and video traffic from the attendee browser inside the enterprise network filters to the TURN server. The TURN server then handles the relay of the audio and video via the UDP ports and protocols the VPB conference nodes expect inside the webinar.net infrastructure.

With the TURN server, the browser makes an unencrypted authentication attempt over TCP 443, using the response to determine NAT info. Then connects to transmit audio and video using TLS to TURN server on 443. The TURN server deals with UDP High ports requirement of VPB.

Note. Proxy/Firewall must support/allow initial unencrypted traffic over 443 to TURN.

TCP Tunneling can be utilized by a single presenter, allowing the other presenters to use higher UDP ports providing low overhead and higher speeds. If a presenter is having audio and/or video difficulties, they can select the Enable TCP Tunneling checkbox to switch to a TCP connection.

For further assistance, contact us through chat or send us an email at support@webinar.net.