Network Latency and Adobe Connect Meetings Running WebRTC Enhanced Audio/Video

Note: This article contains images. You may need to refresh the WordPress URL in your browser to view them.

The network distance between Adobe Connect clients and Adobe Connect servers hosting a Meeting is often the primary variable driving the amount of latency experienced by end users. A second common variable is network infrastructure and the client use of virtual private network (VPN) connections.

Round-trip-time (RTT) and network distance between Adobe Connect servers and the majority of the clients attending Meetings or Seminars should be among the primary considerations in planning where to deploy an Adobe Connect cluster or clusters.

• Adobe Connect multi-tenancy hosted services offers clusters based in the US, Europe and Asia.
• Adobe Connect Managed Services (ACMS) offers hosting options in most all of the AWS global cloud regions although some restrictions may currently apply.
• Adobe Connect Managed ISPs can offer customized hosting options.
• Adobe Connect on-premise servers can go wherever you install them whether within a network infrastructure or in the cloud.

A simple tracert is helpful in determining the network distance and routing to any Adobe Connect servers from any client as is the hosted Connection test.

Here is an example of a tracert from my client in rural Georgia to an Adobe Connect Cluster in Australia. It took 8 hops and note the last three hops are the longest in msec. The tool counts to 30 by default and you can ignore the superfluous hops after the target domain:

• To test connections to a US-West-based hosted multi-tenancy Adobe Connect cluster:
  • https://arcps.adobeconnect.com/common/help/en/support/meeting_test.htm
  • From a command prompt run: tracert arcps.adobeconnect.com
• To test connections to a US-East-based hosted multi-tenancy Adobe Connect cluster:
  • https://na3cps.adobeconnect.com/common/help/en/support/meeting_test.htm
  • From a command prompt run: tracert na3cps.adobeconnect.com
• To test connection to an Australia-AP-Southeast based hosted multi-tenancy Adobe Connect cluster:
  • https://apac1cps.adobeconnect.com/common/help/en/support/meeting_test.htm
  • From a command prompt run: tracert apac1cps.adobeconnect.com
• To test connections to a UK EU-West based hosted multi-tenancy Adobe Connect cluster:
  • https://emea1cps.adobeconnect.com/common/help/en/support/meeting_test.htm
  • From a command prompt run: tracert emea1cps.adobeconnect.com

Sometimes you may be able to identify a particularly long hop in tracert output and work with network providers to solve issues adding undue latency to a network route. In other cases the network distance may simply be able to be shortened by rerouting after contacting the carriers. Issues with labyrinthine network routing may be more common in the APAC region than either EMEA or the US.

Here are an examples of client connections from Noida, India to US West and to APAC. See the 100 msec delta with the longer RTT:

APAC to US West:

APAC to APAC:

Another tool that is also helpful in determining the amount of network distance driven latency is used by the ACMS team to assist with properly locating an Adobe Connect cluster for support of a regional audience:

https://www.cloudping.info/

The output from Cloudping from each regional office in any enterprise can provide valuable information to help determine the optimal location for an Adobe Connect cluster deployment. Cloudping will sometimes reveal some surprises. We have seen instances where an APAC customer is better served by US-West than by Ap-Southeast for example.

While network distance is a major variable affecting latency, network architecture may play a significant role. For the best experience with WebRTC in Adobe Connect Hosted Meetings, you should allow UDP and TCP traffic as follows:

Port Number	Protocol	Use	Domain
443	TCP	STURN/TLS	*.webrtc.adobeconnect.com
3478	UDP	STUN/TURN	*.webrtc.adobeconnect.com
30000 – 65535	UDP	SRTP	*.webrtc.adobeconnect.com
443	TCP	TURNS	*.webrtc.adobeconnect.com
443	TCP	HTTPS	*.adobeconnect.com

Note: For customers who cannot allow UDP, or port 3478 over TCP, you can have a very good experience over TURN-S, by allowing only 443 as follows:

443	TCP	TURN-S	*.webrtc.adobeconnect.com
443	TCP	HTTPS	*.adobeconnect.com

Note: if using a proxy, you may need to turn off SSL inspection of TLS/TURNS traffic on 443.

To test your WebRTC connection you may use this: https://webcasts.com/webrtc/

While Adobe Connect does not require UDP and will work very well as described above using only TCP over port 443. It is nevertheless important to note that while the TURN-S protocol is similar to https, it is not exactly the same. Some proxy servers may require an exception to allow the TURN-S traffic through. It is often necessary to add an explicit rule to allow all encrypted traffic to *.adobeconnect.com:443.

Boarder latency levels:

Here are the acceptable latency thresholds for Meeting use-cases:

1. VoIP:
   • Acceptable: 150–250 ms
   • Over 250 ms: Users will notice delays.
   • Ideal: Less than 150 ms
2. Camera:
   • Acceptable: 200–400 ms
   • Over 400 ms: Performance may degrade noticeably.
   • Ideal: Less than 200 ms
3. Screen Share:
   • Acceptable: 150–300 ms
   • Over 300 ms: Latency becomes disruptive.
   • Ideal: Less than 150 ms
4. Chat:
   • Since chat sent by any user becomes visible in their chat pod only after the full round trip, high latency may be disruptive (a user may press enter to send a chat but it will take some time to show up in the chat area)
   • Over 300 ms can cause delays