Implementing Dual-Stack Telephony Architectures for Parallel Legacy and Cloud Operation
What This Guide Covers
This guide details the architectural implementation of a hybrid telephony environment where an on-premises Private Branch Exchange (PBX) operates simultaneously with Genesys Cloud CX. The end result is a unified dial plan that routes calls to either legacy hardware or cloud endpoints based on specific criteria, ensuring business continuity during migration and maintaining feature parity across both platforms. You will configure SIP trunking, define routing profiles for traffic distribution, and establish failover mechanisms that prevent service interruption when one platform becomes unavailable.
Prerequisites, Roles & Licensing
To successfully deploy this architecture, the following requirements must be met within your environment:
- Licensing Tier: Genesys Cloud CX Organization must possess a Premium or Enterprise license tier. The Cloud Connect add-on is required for direct integration with legacy SIP trunks if using the standard connector approach.
- Granular Permissions: The deploying engineer requires
Telephony > Trunk > Editpermissions andRouting > Flows > Editpermissions within the Admin console. - OAuth Scopes: API interactions require the
telephony:trunks:read,telephony:trunks:write, androuting:flows:writescopes. - External Dependencies: A Session Border Controller (SBC) is mandatory to mediate signaling between the legacy PBX and Genesys Cloud. Common implementations include Cisco CUBE, Avaya G450, or Genesys Edge. Carrier SIP Trunks must be provisioned on both the legacy side and the cloud side with overlapping DID ranges or split DID pools.
- Network: The SBC must have public IP addresses accessible by the carrier for SIP registration. Firewalls must allow TCP/UDP 5060 (SIP) and UDP 10000-20000 (RTP media).
The Implementation Deep-Dive
1. SIP Trunking Topology and Signaling Mediation
The foundation of a dual-stack architecture is the signaling path. You must establish two distinct SIP trunks: one terminating at the Genesys Cloud platform and one terminating at the legacy PBX. These trunks must share a common signaling interface via the SBC to allow for call transfer and failover logic.
Configuration Steps:
- Navigate to Admin > Telephony > Trunks in Genesys Cloud. Create a new SIP Trunk named
Legacy_PBX_Interconnect. Set theTrunk Typeto SIP. Configure theProxy Addressto point to the SBC public IP. - On the legacy PBX, configure a secondary SIP trunk pointing to the Genesys Cloud proxy address provided in your organization portal.
- Ensure both trunks utilize TLS 1.2 for signaling encryption and SRTP for media encryption to maintain PCI-DSS compliance during transit.
The Trap: A common misconfiguration involves enabling SIP ALG (Application Layer Gateway) on the network router or firewall between the SBC and Genesys Cloud. SIP ALG rewrites SIP headers in ways that break URI authentication and cause one-way audio. If you enable SIP ALG, you will experience call drops during media negotiation.
Architectural Reasoning: You use an SBC as a mediator rather than direct peering between the PBX and Genesys Cloud to normalize signaling differences. Legacy PBX systems often use proprietary SDP (Session Description Protocol) formats that differ from Genesys Cloud standards. The SBC normalizes these packets, ensuring that a call leg established on legacy hardware can be transferred seamlessly to the cloud without renegotiation failure. This decoupling prevents the legacy system from becoming a bottleneck for cloud features.
API Reference:
To verify trunk connectivity status programmatically before routing traffic:
GET /api/v2/telephony/trunks/{trunkId}
Authorization: Bearer {access_token}
Content-Type: application/json
{
"id": "12345678-1234-1234-1234-123456789012",
"name": "Legacy_PBX_Interconnect",
"type": "sip",
"status": {
"state": "CONNECTED"
},
"ipAddress": "203.0.113.50",
"port": 5061,
"protocol": "TLS"
}
2. Routing Profile Logic for Parallel Call Distribution
Once the transport layer is established, you must define how calls enter the system. A dual-stack architecture requires a routing decision point that evaluates whether to send traffic to the legacy PBX or Genesys Cloud. This is typically achieved through Routing Profiles and Flow Definitions in Architect.
Configuration Steps:
- Create a Routing Profile named
Dual_Stack_Entry. Assign this profile to your DID range within the carrier portal. - Inside Genesys Cloud Architect, create a new Flow that acts as the entry point for inbound calls.
- Add a Route Call node at the start of the flow. Configure the logic to check the
Incoming DigitsorCaller ID. If the call matches a specific internal range (e.g., extension extensions), route it to the legacy PBX via the SBC. If it matches external DID ranges, route it to Genesys Cloud queues. - Implement an Expression within the Route Call node to handle the logic dynamically.
The Trap: The most frequent error in this step is creating a routing loop. If the Architect Flow sends a call back to the SBC without checking the Call Direction, the call will bounce between the PBX and Cloud indefinitely until it times out. You must ensure that calls routed from Cloud to Legacy do not re-enter the Cloud flow upon return.
Architectural Reasoning: We use an expression-based routing model instead of hard-coded queue assignments because the business requirement for dual-stack operation is dynamic. For example, you may want to route all sales inquiries to Cloud queues while sending support escalations to legacy agents who are not yet licensed in the cloud. The logic must evaluate the Caller ID and Time of Day in real-time. Hard-coding these into the carrier routing tables would require manual updates for every business rule change, whereas Architect allows you to deploy changes instantly via API without carrier intervention.
API Reference:
Update the Routing Flow logic to include dual-stack decision nodes via API:
PATCH /api/v2/routing/flows/{flowId}
Authorization: Bearer {access_token}
Content-Type: application/json
{
"name": "Dual_Stack_Entry_Flow",
"language": "en-US",
"definition": {
"nodes": [
{
"id": "node_route_call",
"type": "RouteCall",
"config": {
"expression": "${callerId} matches '100.*' ? 'Legacy_PBX' : 'Cloud_Queue'",
"targetType": "QUEUE_OR_PHONE"
}
},
{
"id": "node_legacy_transfer",
"type": "Transfer",
"config": {
"destinationType": "SIP_TRUNK",
"sipAddress": "legacy-pbx.internal.domain.com"
}
}
]
}
}
3. Failover and Continuity Logic
The critical value proposition of a dual-stack architecture is resilience. If the Genesys Cloud platform experiences an outage, calls must automatically fail over to the legacy PBX without requiring customer intervention. Conversely, if the legacy PBX loses power or connectivity, traffic should shift to the cloud queues.
Configuration Steps:
- Configure SIP Trunk Failover settings in Genesys Cloud under Admin > Telephony > Trunks. Set the
Failover Strategyto Route to Fallback Trunk. Define your legacy SIP trunk as the fallback target. - On the SBC, configure Outbound Proxy Groups. Assign a higher priority to the Genesys Cloud proxy and a lower priority to the legacy PBX for outbound calls. If the primary link fails, the SBC automatically reroutes signaling through the secondary path.
- Implement Heartbeat Monitoring using an external script or network monitoring tool (e.g., Nagios, SolarWinds) to ping the Genesys Cloud SIP endpoints every 60 seconds. Configure alerts for latency spikes exceeding 150ms.
The Trap: Relying solely on carrier-level failover is insufficient because carriers often take minutes to detect a route failure. If you configure only the carrier to handle failover, you will experience dropped calls during the detection window. You must implement application-layer or network-layer failover at the SBC level for sub-second recovery times.
Architectural Reasoning: We prioritize SBC-level failover over carrier-level failover because the SBC controls the signaling path directly. Carrier routing tables are static and often cached by DNS providers, leading to stale routes. By configuring the SBC with dynamic priority groups, you ensure that the network layer redirects traffic immediately upon link failure. This approach minimizes call setup time during a disaster scenario, preserving customer experience metrics even during infrastructure degradation.
Validation, Edge Cases & Troubleshooting
Edge Case 1: One-Way Audio in Hybrid Transfers
The Failure Condition: A user initiates a call on the legacy PBX and transfers it to a Genesys Cloud agent via Architect. The transfer succeeds, but audio is one-way (Agent hears Caller, but Caller does not hear Agent).
The Root Cause: This occurs when the SBC fails to properly map the media IP addresses in the SDP body during the transfer. The legacy PBX sends an internal private IP address (e.g., 10.0.0.5) as the media destination, which is unreachable from the Genesys Cloud public infrastructure.
The Solution: Verify that your SBC is configured for Media Anchoring. In Cisco CUBE or Avaya G450 settings, ensure voice-card or media relay options are enabled to rewrite SDP headers with the public IP address of the SBC before forwarding the call leg to Genesys Cloud. Do not rely on NAT traversal; explicitly force media anchoring at the edge device.
Edge Case 2: STIR/SHAKEN Compliance During Migration
The Failure Condition: Calls originating from the legacy PBX are marked as “Spam Likely” or blocked by mobile carriers, while cloud-originated calls pass verification.
The Root Cause: Genesys Cloud automatically handles STIR/SHAKEN attestation for cloud calls. Legacy PBX systems often lack this capability or have incorrect SIP headers (e.g., missing P-Asserted-Identity). When a call originates from the legacy side and is routed through the SBC, the attestation token may not be generated correctly if the SBC does not forward the necessary credentials to the carrier.
The Solution: Ensure the carrier provisioning for the legacy SIP trunk includes the SHA-256 Hash required for STIR/SHAKEN verification. You must register the legacy DID range with the same attestation level as the cloud DIDs. If the legacy system cannot generate tokens, configure the SBC to append a P-Asserted-Identity header that matches the carrier’s registered identity for that DID range.
Edge Case 3: E911 Location Data Mismatch
The Failure Condition: An emergency call placed from a Genesys Cloud agent is routed to the legacy PBX due to failover logic, but the dispatch center receives the wrong location data.
The Root Cause: Genesys Cloud manages E911 locations dynamically per user or queue. Legacy PBX systems use static physical address configurations tied to trunks. When a call fails over from Cloud to Legacy, the E911 payload may revert to the default legacy trunk address rather than the agent’s specific location.
The Solution: You must configure Dynamic Location Reporting on the SBC or ensure that the fallback logic includes passing the original E911_Location_ID header through to the legacy system. If the legacy PBX does not support dynamic E911, you must map all cloud locations to a single generic emergency address on the legacy side for failover scenarios and document this limitation in your Disaster Recovery Plan.