Media streams flow 1) from Presenters to ON24 and 2) from ON24 to Audience. Sources for both can be separately whitelisted to ensure a high quality experience.
Content from ON24 to the audience is described below under Audience Use Cases. Audience stream delivery is scaled using CDNs. URLs for the sources are provided. Many clients can now accept Fully Qualified Domain Names (FQDN) for the purpose of indicating traffic to allow and split tunneling traffic for VPN users. We cannot provide the IP addresses for CDN partners.
If your company cannot whitelist streams based on FQDN, please contact technical support well in advance of your webinar to determine if another option can be provided. We can provide some address information and may be able to configure the sources used so that address information to drive split tunneling is available.
Content to ON24 from Presenters is addressed under Presenter Use Cases. This material addresses the use of the Video Presenter Bridge (VPB).
Note: This information is updated as sources in use and CDNs change. This document should be referenced from this page each time the information is needed.
Audience Use Cases
If you whitelist using domain names, below is a list of source domains:
Audience Use Case
Static Content - Static Content is console static elements, mainly graphics
MPEG-DASH - streams for delivery to desktop browsers
HLS - streams for delivery to iOS and Android (mobile) devices
ON24 App Servers
If you require IP addresses, split tunneling configuration, and load-related assistance:
ON24 IP address range is 22.214.171.124/22, which is 126.96.36.199-188.8.131.52
CDNs do not generally provide IP addresses, as noted above.
If you require IP addresses to white-list traffic for a Town Hall session (large internal meeting), please submit a case to ON24 at firstname.lastname@example.org. We may have CDN facilities with known IP addresses for this use case - the CDNs used for an event are configured in an ON24 database; this database can be adjusted to control which sources are used.
Presenter Use Cases
The Presenter UI does not generally require whitelisting except for those using the Video Presenter Bridge (i.e., webcam or screen sharing). The list of addresses used by PMXD and Elite Studio are below.
Webcam and Screen Share Related Connection Issues (VPB Connections)
The ON24 component webcam/screen share presenters use is a cloud audio/video bridge (usually referred to as “VPB” for Video Presenter Bridge). The VPB accepts audio connections and video connections then composites them into an image that is encoded for the webcast. Protocols supported include: Phone Audio uses SIP, VCU uses H.323 or SIP, Skype/Teams are supported, but the network components required to support those products are normally addressed as part of the Teams rollout; Webcam and Screenshare use WebRTC. The problematic component is WebRTC.
WebRTC requires a control connection (HTTPS over 443) and separate audio and video stream channels in both directions; 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 searches for usable 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, even 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 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 while relaying traffic to/from the enterprise network using TLS over TCP.
We use secure TURN (TURNS) which generally works without intervention. There are several issues that can break the configuration:
- Since the TURNS traffic (TCP over TLS) is encrypted, it will go over the proxy path without incident, given that the PAC file recognizes the need to send to the proxy path. If it does not recognize the TURNS protocol, then the PAC file must select the addresses and route them to the proxy. Addresses are 184.108.40.206 and 220.127.116.11; 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 part of the STUN RFC (5766), so PAN recognizes the STUN application spec.
Google provides a test tool that will allow enterprise network users to determine whether the required network paths are open, see URL immediately below.
in the STUN or TURN URI: turns:turn.fav.on24.com:443?transport=tcp
In TURN username: 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.
Elite Studio fails to display Polls, Slides, etc.
Elite Studio uses WebSockets (wss://) to set up the browser to operate the necessary APIs and micro services. If WebSockets are not supported (routed through a proxy as HTTPS traffic would be) Elite studio will not function at all. Instructions to identify and fix are below:
For network requirements using ON24 Breakouts, please follow the requirements specified in the article below.
Broadcast Video Users (Encoding on Site)
For those using the ON24 Broadcast Video, your encoder will transmit from the venue to ON24's Ingress servers. These destination addresses are:
- fmseosa.on24.com - 18.104.22.168, 22.214.171.124
- fmseosb.on24.com - 126.96.36.199, 188.8.131.52
The encoder devices require outbound access from your network to the IP addresses above on TCP Port 1935; encoders are not generally proxy aware. RTMP and RTMPS are both supported at the Ingress servers.
ON24 Email Servers (across all products)
- 184.108.40.206 = r-smtp-wc.on24.com
- 220.127.116.11 = r-smtp-wc.on24.com
- 18.104.22.168 = r-smtp-wc.on24.com
- 22.214.171.124 = p-smtp-wc.on24.com
- 126.96.36.199 = p-smtp-wc.on24.com
- 188.8.131.52 = p-smtp-wc.on24.com
- 184.108.40.206 = r-smtp-ve.on24.com
- 220.127.116.11 = r-smtp-ve.on24.com
- 18.104.22.168 = r-smtp-ve.on24.com
- 22.214.171.124 = p-smtp-ve.on24.com
- 126.96.36.199 = p-smtp-ve.on24.com
- 188.8.131.52 = p-smtp-ve.on24.com
ON24 IP Range
184.108.40.206/22, which is 220.127.116.11-18.104.22.168
Proxy Server Settings
SSL Decryption should be suppressed - Many proxies, especially the Cloud proxies such as provided by Zscaler, routinely recommend decoding SSL traffic. This is a moderately bad call in the webcasting use case for several reasons (see below). The ON24 stream sources should be whitelisted, and SSL decryption disabled.
- Video chunks, assuming the bit rates used in ON24 streams, will generally be about 250 Kbps per chunk, with a chunk coming every 2 seconds. This volume and frequency are greater than that assumed in configuring proxies, generally, and will cause queue times on the SSL decode to be more highly variable than expected. Variable queue delay gives 1) buffering, and 2) exposure to lip-sync issues, as audio and video chunks are separate data streams.
- In a "Town Hall" scenario, there might be hundreds or thousands of streams being simultaneously pulled through the proxy; if decoding is specified, delivery timing anomalies are likely to be very common.
- There is no benefit to decoding the streams; they are innocuous on their own, and the sources which deliver them are specific to ON24, so not subject to delivering other types of (potentially dangerous) traffic.
VE Use Cases
ON24 Virtual Environments provide content from the sources listed below:
Virtual Environments may optionally include ON24 webcast content, in which case the settings toward the top of this page also need to be included.