This article provides steps for resolving TURN server issues when connecting to the ON24 platform.

WebRTC Protocols - Presenter Webcam and Screenshare Access

The ON24 component your users are making use of is a cloud audio/video bridge (usually referred to as “VPB” for Video Presenter Bridge).  It accepts audio connections and video connections in a variety of flavors.  Audio uses SIP dial, VCU uses H.323 or SIP, Webcam and Screenshare use WebRTC.  The problematic component is the webRTC piece, so let me focus on that.

WebRTC requires a control connection (HTTPS over 443) and separate audio and video stream channels in both directions, with audio and video connections over UDP high ports.  That doesn't work in most enterprise networks because High Ports are blocked. The user (browser on your internal network) sets up a bridge session (using HTTPS, which works); the bridge and browser then looks for the paths into and out of the 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 means available (ports addresses, protocols) to reach the nodes.  This negotiation process is logged to the console section of the browser dev tools, so it can be easily visualized.  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 normally are blocked inside corporate networks, but they are always tried at each session initiation, event after it’s clear that they don’t work.  The system then attempts to use a relay (TURN) server, which uses TLS over TCP to move the A/V traffic from the user 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 ON24 network.

TURN Server Activation

TURN server activation (RFC 5766) used to do an unencrypted preamble that would frequently block successful setup of TURN relay.  Now, we’ve converted to secure TURN (TURNS), which avoids the unencrypted preamble and almost always works without intervention.  NOTE:  this is not HTTPS traffic; it will not be recognized as such by the pac file process.  If your proxy is handling via a CONNECT using HTTP1.1, it will not work.

The Proxy/firewall config required to support this depends on the network configuration on the client side.
 

• Since the TURNS traffic (TCP over TLS) is encrypted, it will go over the proxy path without incident, given that the pac file will recognize the need to pick it up and send to proxy path.  If it does not recognize the TURNS protocol, then the pac file must select by addresses and route them to the proxy.  Addresses are 199.83.47.94 and 199.83.46.94, and that traffic will likely be flowing to the firewall where it’ll be blocked.  We just need a rule in the pac file that’ll pick up the TURNS traffic or the addresses.  The FQDN which is the destination giving the two addresses indicated is TURN.FAV.ON24.COM.  With the protocol reference, the URI is turns:turn.fav.on24.com
• Quite frequently, a Palo Alto Networks firewall will require that you allow the STUN protocol.  TURNS is a parts of the STUN RFC (5766), so PAN recognizes the STUN application spec.

Verifying Success

Google (authors of webRTC) provides a test link to see if the TURN server discovery process is working:

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

in the STUN or TURN URI:  turns:turn.fav.on24.com:443?transport=tcp

In TURN User:   on24user

In TURN password: nev2Eni@

Click add server and remove any other servers that may be there, then hit “gather candidates”.  You have to get a “relay” response to confirm TURNS is working.

Diagram of Webcam and Screen Share Transport