What is a Proxy?
A proxy is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource (source Wikipedia)
Its role is to secure private networks, by acting as an “intermediary” between the Agents softphone and the Amazon Connect cloud; data is inspected by the Proxy and can be either passed or blocked.
The type of Agent data that passes through the Proxy is typically determined by a desk-top configuration called a Proxy Auto-Configuration (PAC) file.
Why is this important?
As data between the Agents softphone (CCP) and Amazon Connect is often passed through the Proxy, if the Proxy is under load, has issues or is misconfigured, then data can be delayed, causing both call and softphone feature issues.
What are typical symptoms and errors caused by Proxy delays?
Typical symptoms are dropped calls, softphone errors and unresponsive softphone features, for example agents being unable to answer calls and then moving to a "Missed Call Agent" state.
From an Operata perspective (as well as Agent Issue reports) you will see (Playbook 5) large numbers of errors (signalling_handshake_failure errors are common) across impacted agents.
How do I prove and resolve the issue?
To prove the Proxy as the cause, either:
Proxy bypass rules put into place for CCP Media, Signalling and API traffic for a sample of impacted agents.
Move a sample of agents to a different network that does not have the same Proxy rules applied.
If the issue is resolved then either the bypass rule needs to be extended to all agents permanently or the performance of the Proxy addressed.
What Proxy bypass rules are needed?
Amazon Connect to the Agent softphone (CCP) has four endpoints:
Telemetry - as this is not a real-time service, it can pass through the Proxy.
Softphone Media (UDP) - as this is real-time media (UCP) it must always bypass the Proxy.
Signalling (TCP WebSocket) - this should preferably bypass the Proxy.
API (HTML TCP) - this should preferably bypass the Proxy.
The diagram below provides additional detail, more can be found here.
The URL's circled in red are sensitive to Proxy delays as described above (for CCP-v2)
Are there any other Port and protocol considerations?
Important notes from the Amazon Connect networking guide
You need to allow traffic for all addresses and ranges for the Region in which you created your Amazon Connect instance.
If you are using a proxy or firewall between the CCP and Amazon Connect, increase the SSL certificate cache timeout to cover the duration of an entire shift for your agents, Do this to avoid connectivity issues with certificate renewals during their scheduled working time. For example, if your agents are scheduled to work 8 hour shifts that include breaks, increase the interval to 8 hours plus time for breaks and lunch.
When opening ports, Amazon EC2 and Amazon Connect require only the ports for endpoints in the same Region as your instance. CloudFront, however, serves static content from an edge location that has the lowest latency in relation to where your agents are located. IP range allow lists for CloudFront are global and require all IP ranges associated with "service": "CLOUDFRONT" in ip-ranges.json.
Once ip-ranges.json is updated, the associated AWS service will begin using the updated IP ranges after 30 days. To avoid intermittent connectivity issues when the service begins routing traffic to the new IP ranges, be sure to add the new IP ranges to your allow list, within 30 days from the time they were added to ip-ranges.json.
If you are using a custom CCP with the Amazon Connect Streams API, you can create a media-less CCP that does not require opening ports for communication with Amazon Connect, but still requires ports opened for communication with Amazon EC2 and CloudFront.