Overview
The core of Adobe Connect 12 contains an upgrade of the underlying audio/video/screen-sharing technology from RTMP to WebRTC.
WebRTC was designed from the outset to work across a wide range of networks, so for most customers, it will "just work." However, some customers with restrictive firewalls or web proxies may need to update their network configurations.
Any issues are likely to manifest themselves after the meeting has been launched when a user tries to publish or view audio, video, or screen sharing.
In this whitepaper, we will describe the minimum required network configuration and the recommended network configuration for optimal performance.
Note: These configurations are in addition to any existing network configuration customers may have implemented for Adobe Connect – the current configurations should be retained, as Connect 12 still uses RTMP for signaling.
Minimum required network configuration
The minimum configurations are divided as:
- Configuration for web traffic
- Configuration for WebRTC traffic
Minimum configuration for web traffic
Users must allow standard https:// and wss:// web traffic to *.adobeconnect.com.
Very few customers will need to change anything to meet this requirement, as this is standard HTTPS traffic.
In addition, users must allow certificate validation for (also something very few customers will need to do explicitly) the following:
Minimum configuration for WebRTC traffic
When all other communication methods are blocked, WebRTC falls back to tunneling over TLS (TURN-S). This is similar to how RTMP falls back to tunneling over HTTPS.
TURN-S performs very well. Approximately twenty percent of our production WebRTC traffic occurs over TURN-S, and those users have a great experience.
However, some proxies and firewalls block TURN-S traffic, because on deep inspection it isn't the same as HTTPS traffic. This is especially true for customers with firewall or proxy devices that perform man-in-the-middle inspections.
The minimum requirement is:
- Allow TURN-S traffic (or simply all encrypted traffic) over port 443 to *.webrtc.adobeconnect.com
On August 23, 2022, we will have transitioned to static IP blocks in both North America and EMEA. This will allow customers to allow by IPs rather than by wildcard domain.
Customers hosted in North America can allow IPs, 35.92.28.0/23 in North America, and customers hosted in EMEA and APAC can allow the IP, 3.252.48.0/23.
Additional static IP blocks will be added in the future, so customers who choose to allow static IPs will need to update their allowed IP blocks at that time. For this reason, we recommend that customers allow the IPs by domain name if possible.
Recommended network configuration
One of the biggest advantages of WebRTC is that it prefers UDP traffic. UDP handles poor network conditions (high latency, high packet loss) better than TCP.
Accordingly, we recommend that customers allow the following UDP and TCP ports:
Port |
Protocol |
Use |
3478 |
UDP |
STUN/TURN |
30000 - 65535 |
UDP |
SRTP (Secure RTP) |
3478 |
TCP |
TURN |
These ports should be allowed for the following destinations:
- For customers hosted in NA to 35.92.28.0/23
- For customers in EMEA and APAC to 3.252.48.0/23
Testing the network configuration
For testing the network configuration post changes requested above please do the following
- Enable 'Enhanced Audio/Video Experience' for one of the existing rooms or a new room
- Join the room as a host and start sharing your camera in the room
- Join the same room again (either from the same device or from a different device)
- If the shared camera is visible in the room from the second device then the changed network configuration is working as expected
Sign in to your account