Edge Group Configuration for Active-Active Media Tier Failover

How-To-Articles
1

Edge Group Configuration for Active-Active Media Tier Failover

Executive Summary & Architectural Context

In a BYOC Premise deployment (where physical or virtual Genesys Edges live in your corporate data center), the media tier is entirely your responsibility. If a physical Edge server suffers a kernel panic or a localized network switch failure, any active phone calls traversing that Edge will drop. More dangerously, if inbound routing isn’t instantly updated, new calls will attempt to hit the dead Edge and fail.

To achieve enterprise-grade high availability, you must architect an Active-Active Edge Group. This topology clusters multiple physical Edge servers into a single logical routing entity. The group continuously monitors the health of its members and automatically load-balances inbound SIP traffic and internal media processing (like call recording and IVR prompt playback) across healthy nodes.

This masterclass details how to construct an Edge Group, configure SIP tie-lines for intra-group routing, and engineer carrier-side failover logic to ensure absolute redundancy.

Prerequisites, Roles & Licensing

  • Licensing: Any Genesys Cloud CX tier with BYOC Premise.
  • Roles & Permissions: Telephony > Edge Group > Edit, Telephony > Edge > Edit.
  • Platform Dependencies:
    • At least two physical or virtual Genesys Cloud Edge appliances deployed in the same physical data center (or spanning ultra-low latency links).

The Implementation Deep-Dive

1. The Architectural Rule of Three

While you can build an Edge Group with two Edges, the engineering best practice is N+1, typically resulting in three Edges.

  • Why? If you have two Edges running at 60% CPU capacity, and Edge A dies, Edge B must suddenly absorb 120% CPU capacity, causing a cascading failure that crashes Edge B.
  • You must always provision your Edge Group so that the remaining nodes can comfortably handle 100% of the peak traffic load if the primary node goes offline.

2. Creating the Edge Group

  1. Navigate to Admin > Telephony > Edge Groups.
  2. Click Create New. Name it Datacenter_Alpha_Cluster.
  3. Phone Trunk Base Settings: Define the internal SIP parameters (UDP/TCP/TLS) used by physical hardware phones (like Polycom or AudioCodes) to register to this specific group.
  4. Assign the Edges:
    • Navigate to Admin > Telephony > Edges.
    • Edit Edge_01. In the configuration, assign it to Datacenter_Alpha_Cluster.
    • Edit Edge_02. Assign it to the same group.

3. SIP Tie-Lines and Intra-Group Communication

Edges within the same group must talk to each other constantly to sync state and pass media.

  1. The Tie-Line Requirement: When you assign multiple Edges to a group, Genesys Cloud automatically provisions a logical “Tie-Line” between them.
  2. Network Whitelisting: You must ensure that your internal data center firewalls allow absolute, unrestricted UDP and TCP traffic across all ephemeral ports between the physical IP addresses of Edge_01 and Edge_02. If intra-group routing is blocked by a firewall, the clustering will fail, and cross-node transfers (e.g., an agent registered to Edge A transferring to an IVR prompt living on Edge B) will result in dead air.

4. Carrier Load Balancing (The Inbound Handoff)

Genesys Cloud manages the internal clustering, but your SIP carrier controls the inbound flow of traffic.

  1. Provide your SIP carrier with the IP addresses of both Edge_01 and Edge_02.
  2. Instruct the carrier to configure their Session Border Controller (SBC) using an Active-Active Round Robin strategy.
    • Call 1 → INVITE Edge_01
    • Call 2 → INVITE Edge_02
    • Call 3 → INVITE Edge_01
  3. The Failover Trigger: The carrier SBC must be configured with a strict SIP OPTIONS ping or a fast-timeout rule (e.g., if no 100 Trying received within 500ms, immediately re-route the INVITE to the surviving Edge).

Validation, Edge Cases & Troubleshooting

Edge Case 1: Split-Brain Scenarios (Geographic Spanning)

Architects often try to put Edge_01 in New York and Edge_02 in London into the same Edge Group to achieve “Global Redundancy.”

  • The Trap: This is a catastrophic architectural failure. Edges in the same group constantly share state memory and media. If you span an Edge Group across an ocean, the 80ms+ latency will cause the Tie-Lines to choke. The Edges will lose synchronization, enter a “Split-Brain” state, and stop processing calls entirely.
  • Solution: Edge Groups must only contain Edges in the same physical data center (or Metro-Area Network with <5ms latency). To achieve geographic redundancy (NY to London), you must build two separate Edge Groups and use Site-based Outbound Routes to handle the failover logically, rather than clustering them at the hardware level.

Edge Case 2: Outbound Trunk Pinning

If an agent makes an outbound call, which Edge places the call to the carrier?

  • Logic: Genesys Cloud will dynamically pick the Edge with the lowest current CPU load within the assigned Edge Group.
  • Troubleshooting: If your carrier strictly authenticates outbound SIP calls based on the Source IP address, you must ensure your carrier has whitelisted the IPs of all Edges in the group. If they only whitelisted Edge_01, then roughly 50% of your outbound calls (the ones load-balanced to Edge_02) will fail with a 403 Forbidden from the carrier.

Official References