We are setting up a remote site in Asia and need to understand the Edge Group media tier selection logic.
As an AppFoundry partner that provides SIP-based compliance recording software, we require the media to stay local to the Edge appliance. If the remote site’s Edge fails, what is the exact fallback order? Does it fail over to the primary site’s Edges, or does it immediately fail over to the AWS Cloud media tier?
To clarify the media tier selection logic, we must reference the official Resource Center article on ‘Edge Group Architecture’.
The fallback sequence is strictly enforced as follows:
If your compliance recording requires local RTP anchoring, you must disable the AWS Media Tier fallback in your trunk settings to prevent the media from traversing the internet.
Does this Edge failover logic affect the WebRTC media path for the Salesforce CTI widget?
If the local Edge goes down, does the SFDC widget automatically renegotiate the ICE candidates to connect to the secondary Edge, or does the agent have to refresh the Salesforce tab to re-establish the WebRTC connection?
From a regulatory perspective, if that media fails over to the AWS Cloud tier located in a different country, you are in violation of data sovereignty laws.
Under MiFID II, certain financial interactions cannot leave the jurisdiction. If your primary Edge fails and the fallback pushes the SIP RTP stream to the US-East AWS region, your recordings are technically crossing borders. You must disable the cloud fallback.
We actually pounded our Edge group with JMeter to find the exact failover threshold.
We simulated 5,000 concurrent SIP calls to force DSP exhaustion on the local Edge. The system seamlessly shifted the 5,001st call to the secondary Edge group. However, we noticed a slight delay in the API throughput for call control events during the transition. Make sure your JMeter configs account for the SIP 302 Redirects.
When an Edge fails and this fallback happens, my performance dashboard is completely useless for 5 minutes.
The dashboard just shows a massive spike in ‘System Errors’ and dropped calls. Can someone explain to the business in plain English why a ‘seamless failover’ results in 50 angry customers hanging up?
FWIW, the failover isn’t instantaneous for active calls.
YMMV depending on your carrier’s ability to quickly re-route the SIP INVITE, but active calls anchored to a dead Edge cannot magically migrate their media stream mid-sentence.
If you look at the Analytics API during the failover, you can see the exact moment the tier shifts.
The conversations/details/query payload will show the mediaType flag change. I run an executive dashboard that specifically filters for these flags to prove to the board when we are utilizing our local hardware versus the cloud fallback.
This complexity is a distinct differentiator when evaluating vendors.
In NICE CXone, you do not manage local Edge hardware at all; it is a pure cloud play. Genesys Cloud’s hybrid BYOC Premises model gives you total control over the media tier, but as we are seeing in this thread, it requires a deep understanding of network architecture to prevent dropped calls during hardware failures.
When you configure this remote site, ensure your Edges can still reach your IdP (Okta/Azure) during a WAN outage.
I spent two days debugging an SSO issue where agents couldn’t log into the local Edge because the firewall blocked the Edge from validating the SAML assertions with the cloud IdP during a failover event.
We monitor our Edge health systematically using the Java SDK and a Kafka event stream.
// Listen for Edge status changes
apiInstance.getTelephonyProvidersEdgesEdges(pageNumber, pageSize, name, siteId, ...);
// Push status to Kafka topic for alerting
kafkaTemplate.send("edge-health", edgeStatusJson);
This allows us to trigger the failover manually via automation if we detect high CPU utilization before the calls actually start dropping.