The IP addresses and ranges on all Adobe Connect clusters will be updated to accommodate future updates from IPV4 to IPV6 when required. This requires changing all IP addresses on all Adobe Connect Hosted servers. Any customer configuring IP bypass exceptions for Adobe Connect RTMP(S) streaming must update the IP list. Contact Adobe Connect Support for the specific list of IP addresses for the cluster on which your Hosted account resides.
Overview
The core of Adobe Connect 12 contains an upgrade of the underlying audio/video/screen-sharing technology from RTMP to WebRTC.
RTMP is still used in a limited capacity for Meeting management, but the primary heavy lifting in an Adobe Connect Enhanced Meeting is via 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 will manifest themselves after the meeting has been launched when a user tries to publish or view audio, video, or screen sharing.
This whitepaper will describe the minimum required network configuration and the recommended network configuration for optimal performance.
These WebRTC 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. For more information, learn about IP address changes affecting RTMP(s).
Minimum required network configuration for Enhanced Meetings based on WebRTC
The minimum configurations are divided into:
- 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 it isn't the same as HTTPS traffic on deep inspection. 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 North America and EMEA. This will allow customers to allow by IPs rather than by wildcard domain.
Customers hosted in North America can allow the IPs 35.92.28.0/23 and 35.92.29.0/23, and customers hosted in EMEA and APAC can allow the IPs 3.252.48.0/23 and 3.252.49.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 most significant advantages of WebRTC is that it prefers UDP traffic. UDP better handles poor network conditions (high latency, high packet loss)
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 and 35.92.29.0/23
- For customers in EMEA and APAC to 3.252.48.0/23 and 3.252.49.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.