· Networking  · 3 min read

Navigating Networking Challenges with Amazon Connect and Zscaler

Discover how to overcome networking issues when using Amazon Connect with Zscaler, ensuring smooth and uninterrupted customer support experiences.

Discover how to overcome networking issues when using Amazon Connect with Zscaler, ensuring smooth and uninterrupted customer support experiences.

When working with Amazon Connect, a contact center as a service in the AWS ecosystem, networking nuances can arise, particularly when dealing with client networks and security solutions like Zscaler. In this article, we’ll explore a case study involving an auto manufacturing client with 500+ agents and the challenges faced while ensuring call quality and durability.

Note: This article primarily discusses Zscalar 1.0 and while these concepts likely apply to Zscalar 2.0, the client has not yet updated to 2.0. If this happens and new information comes about, an update article will be added.

One recurring source of issues encountered involved Zscaler, a security solution that can impact network traffic, even if it claims it will not.

Issues

Amazon Connect’s

Salesforce Service Cloud Voice and the Omni-Channel Heartbeat

Another aspect to consider is the integration with Salesforce Omni Channel. In our case, the heartbeat mechanism of Omni Channel caused intermittent drops in Service Cloud Voice, which is a wrapper over Amazon Connect. Identifying the root cause took weeks of investigation.

The problematic URL was sending TCP traffic, and Zscaler’s packet inspection was altering the packets enough to cause occasional request failures. To resolve this, we had to analyze HAR logs from multiple agents’ computers until we finally caught the specific issue.

The culprit was a URL handling a heartbeat: *.salesforceliveagent.com. By simply permitting this URL through Zscaler without inspection, we resolved the intermittent drops.

To further improve overall performance, we permitted as many Amazon Connect domain/endpoints as possible through Zscaler without inspection. The application is quite chatty, making non-inspection essentially required. AWS provides a comprehensive networking page with the necessary URLs, which you can find at: https://docs.aws.amazon.com/connect/latest/adminguide/ccp-networking.html

Here are the primary URLs that you should populate for each environment:

  • *.telemetry.connect.{region}.amazonaws.com
  • participant.connect.{region}.amazonaws.com
  • .transport.connect.{region}.amazonaws.com
  • {prod_bucket_name}.s3.us-east-1.amazonaws.com
  • {instance_name}.my.connect.aws/ccp-v2
  • {instance_name}.my.connect.aws/api
  • {instance_name}.my.connect.aws/auth/authorize
  • {instance_name}.awsapps.com/connect/ccp-v2
  • {instance_name}.awsapps.com/connect/api
  • {instance_name}.awsapps.com/connect/auth/authorize
  • *.connect-telecom.{region}.amazonaws.com
  • *.static.connect.aws

These URLs should be trusted as they explicitly route traffic to controlled AWS services.

Although Zscaler 1.0 doesn’t touch UDP, it’s crucial to allow UDP endpoints for WebRTC media traffic through firewalls. With Zscaler 2.0, ensure that these endpoints remain untouched.

The UDP endpoints follow the pattern: TurnNlb-*.elb.{region}.amazonaws.com. If needed, you can obtain the specific turnlb(s) from the networking page: https://docs.aws.amazon.com/connect/latest/adminguide/ccp-networking.html#nlb-endpoints

Throughout our journey with the auto manufacturing client, we encountered several bumps in achieving the desired call quality and durability. Nearly every issue traced back to networking, either on-site or at third-party companies’ networks. It’s essential to remember that softphones and WebRTC are chatty and sensitive, requiring fast and untouched network conditions.

While this is relatively straightforward for on-prem and non-VDI users, it becomes more complex with VDIs. A future article may delve into the challenges of VDIs, split media, and the unsolvable call drop issues experienced on VDIs, AppStream, and WorkSpaces until switching to split media.

Resolving these networking challenges required significant collaboration between internal development, networking, AWS networking, Salesforce, and Microsoft support teams. By sharing this information, we hope to assist others who may encounter similar issues, saving them valuable time and effort in ensuring seamless customer support experiences with Amazon Connect.

Back to Blog

Related Posts

View All Posts »