Implementing Genesys Cloud Coexistence with Microsoft Teams Direct Routing for Voice

How-To-Articles
1

Implementing Genesys Cloud Coexistence with Microsoft Teams Direct Routing for Voice

What This Guide Covers

This guide details the architectural configuration required to establish bidirectional voice routing between Microsoft Teams Direct Routing and Genesys Cloud CX. You will configure a SIP Trunk in Genesys Cloud to accept signaling from an enterprise Session Border Controller (SBC) managed under Microsoft Teams Direct Routing policies. The end result is a unified telephony fabric where users interface via the Teams client but rely on Genesys Cloud for call control, routing logic, and contact center integration capabilities.

Prerequisites, Roles & Licensing

Before initiating configuration, verify the following constraints to prevent licensing conflicts or provisioning failures.

Licensing Requirements

  • Genesys Cloud: Active Cloud Phone System license assigned to all users who will receive calls via this trunk. The SIP Trunking add-on is required for external trunk connections.
  • Microsoft Teams: Enterprise Voice enabled tenant with a valid Direct Routing configuration. This includes a supported SBC (e.g., Ribbon, Audiocodes, Oracle) configured in the Microsoft Teams Admin Center.
  • Network: Open bidirectional connectivity on TCP/UDP port 5061 for TLS signaling and UDP ports 50000-60000 for media SRTP streams.

Permissions

  • Genesys Cloud Administrator: Must hold the Telephony > SIP Trunking > Edit permission to create and modify trunk configurations.
  • SBC Administrator: Access to the SBC configuration interface (e.g., Ribbon UCM, Audiocodes MP-SBC) to update dial plans and signaling parameters.

External Dependencies

  • Valid TLS 1.2 or 1.3 certificates issued by a trusted CA for the Genesys Cloud FQDN.
  • Publicly routable IP addresses for the SBC media relay endpoints.
  • DNS records configured to resolve the SBC fully qualified domain name (FQDN) to its public IP address.

The Implementation Deep-Dive

1. Microsoft Teams Direct Routing SBC Configuration

The first architectural step involves configuring the Session Border Controller to signal Genesys Cloud as a trusted partner. This establishes the trust boundary for SIP transactions.

Configuration Steps
In the Microsoft Teams Admin Center, navigate to Voice > Session border controllers. Create or modify the existing SBC entry with the following parameters:

  • Signaling Port: 5061 (TLS only). Do not use port 5060 as Genesys Cloud enforces encrypted signaling by default for trunk connections.
  • FQDN: Enter the FQDN of your Genesys Cloud SIP Trunk endpoint. This must match the domain provided in the Genesys Cloud portal during trunk creation.
  • Trusted IP Address: Enter the public static IP address assigned to your SBC by your network infrastructure team.

The Trap: TLS Certificate Mismatch
A common failure mode occurs when the SBC trusts a self-signed certificate or an expired certificate from Genesys Cloud. Microsoft Teams Direct Routing enforces strict TLS validation. If the SBC cannot validate the chain of trust for the Genesys Cloud FQDN, the TLS handshake fails immediately during the SIP OPTIONS probe.

To resolve this, ensure the SBC has the root CA and intermediate certificates installed in its trust store. The Genesys Cloud portal provides a downloadable certificate bundle for this purpose. Do not bypass certificate validation on the SBC to avoid security vulnerabilities. If using a managed SBC (e.g., Cisco or Ribbon), update the TLS profile to accept the specific certificate authority provided by Genesys Cloud.

Architectural Reasoning
We enforce TLS 1.2 minimum because older versions are susceptible to BEAST and POODLE attacks. The SBC must initiate a SIP OPTIONS request to verify reachability before routing live call traffic. If this probe fails, Microsoft Teams will mark the trunk as “Unhealthy” in the admin portal, preventing any calls from originating.

2. Genesys Cloud SIP Trunk Configuration

Once the SBC is configured to signal outward, you must configure the receiving endpoint within Genesys Cloud. This involves defining the signaling URI and media handling policies.

Configuration Steps
Navigate to Admin > Telephony > SIP Trunks. Click Add SIP Trunk.

  • Name: Teams-DirectRouting-Trunk-01 (Use a descriptive naming convention for auditability).
  • Type: External.
  • Protocol: SIP TLS.
  • Signaling URI: Enter the SBC FQDN provided by the Microsoft Teams Admin Center.
  • Allow SIP OPTIONS: Enable this setting to allow the SBC health check probes.
  • SRTP Policy: Select Mandatory. This ensures media encryption is enforced for all calls traversing this trunk.

The Trap: Header Manipulation and Caller ID Loss
When configuring the signaling URI, administrators often neglect the handling of the P-Asserted-Identity header. Microsoft Teams injects user identities into this header during the INVITE process. If Genesys Cloud strips this header during routing to internal queues or agents, the call appears as anonymous on the agent desktop.

To prevent this, configure the Call Routing settings within the SIP Trunk configuration. Ensure that the Allow P-Asserted-Identity option is enabled in the trunk settings. This preserves the calling number and user identity across the boundary between Teams and Genesys Cloud. If using a custom domain for your Genesys Cloud instance, ensure the FQDN matches the domain registered in the Microsoft tenant to avoid DNS resolution failures.

Architectural Reasoning
Enabling SRTP Mandatory protects voice media from interception during transit over public networks. However, this requires strict negotiation between the SBC and Genesys Cloud. If the SBC negotiates a codec that Genesys Cloud does not support (e.g., G.729 without proper licensing), the call will drop at the SDP exchange stage. Ensure both endpoints share a common set of codecs: PCMU/PCMA (G.711) and OPUS are recommended for optimal quality and compatibility.

3. Architect Expressions for Inbound Routing

Routing logic must be defined within Genesys Cloud to handle calls arriving from the Teams SBC. This ensures that inbound traffic is directed to the correct queues or agents based on the source or dialed number.

Configuration Steps
Navigate to Architect > Flows. Create a new flow or modify an existing one to handle this specific trunk.

  • Trigger: Select Inbound Call.
  • Condition: Add a condition checking the call.to.number or trunk.name.
  • Expression: Use the following JSON logic within the Flow Designer to identify calls from the Teams SBC:
{
  "type": "Call",
  "flowId": "FLOW_ID_FROM_GENESYS_PORTAL",
  "triggerType": "INBOUND",
  "routingRule": {
    "condition": "${trunk.name} == 'Teams-DirectRouting-Trunk-01'",
    "action": "RouteToQueue"
  }
}

The Trap: Infinite Routing Loops
A frequent architectural error is creating a routing path that sends a call back to the same trunk without modification. If an inbound call from Teams arrives, and the Architect Flow routes it to a queue that has no agents, and the failover logic directs it back to the SBC, you create a signaling loop. This results in rapid SIP re-INVITEs that eventually trigger a timeout or rate limit on the Microsoft side.

To prevent this, always implement a Maximum Call Duration check or a Loop Detection variable within the flow. Set a flag (e.g., call.fromTeamsSBC) at the start of the flow. If the call returns to the trunk logic with this flag set, force the call to a default fallback queue rather than re-sending it to the SBC.

Architectural Reasoning
Using Architect Expressions allows for dynamic decision-making based on caller input or time of day. This is superior to static routing tables because it enables you to route calls from Teams users differently than calls from external PSTN providers if both are connected to the same Genesys Cloud environment. For example, you might prioritize Teams internal calls over external PSTN calls during peak hours.

4. Emergency Calling (E911) Configuration

Emergency calling requirements differ significantly between Teams Direct Routing and standard SIP Trunking. Compliance with local regulations is mandatory for all voice connections.

Configuration Steps
Navigate to Admin > Telephony > E911. Configure the emergency service location for the SBC IP range.

  • Service Location: Create a new location entry linked to the SBC public IP.
  • Address Details: Enter the physical address associated with the SBC device.
  • Routing Rule: Associate this location with the Teams-DirectRouting-Trunk-01.

The Trap: Dynamic Address Resolution
Microsoft Teams Direct Routing often relies on the SBC to provide the caller’s location. If the SBC does not pass the correct P-Asserted-Identity or location header, Genesys Cloud cannot route the emergency call to the appropriate Public Safety Answering Point (PSAP).

Ensure that the SBC is configured to send the Location URI in the SIP INVITE header for all calls originating from users assigned to a specific E911 service location. In Genesys Cloud, verify that the Emergency Call Routing policy is set to use the provided location data rather than a static default address. Failure to map the SBC IP to a valid physical address results in emergency services dispatching to the wrong location, creating significant liability exposure.

Architectural Reasoning
Hybrid coexistence models often obscure the user’s physical location because the call originates from a client device but is routed through an SBC located elsewhere. The architecture must ensure that the E911 data flows end-to-end without translation errors. Use the Genesys Cloud Location API to update service locations dynamically if users roam, ensuring compliance with FCC or local telecommunications regulations.

Validation, Edge Cases & Troubleshooting

Edge Case 1: One-Way Audio via NAT

The Failure Condition: Calls connect successfully, but only one party hears audio (usually the Genesys Cloud side).
The Root Cause: The SBC and Genesys Cloud have mismatched understanding of the IP address for media. The SBC may be placing its private internal IP in the SDP body, which is unreachable from Genesys Cloud.
The Solution: Configure the SBC to use NAT Traversal settings explicitly. Enable Force Public IP in the SBC media routing configuration. In Genesys Cloud, ensure the SIP Trunk is configured with the correct public IP of the SBC as the signaling source. Check the SDP payload in call logs using the Call Trace tool to verify the c= (connection) line contains a routable public IP.

Edge Case 2: Codec Mismatch and Quality Degradation

The Failure Condition: Calls connect, but audio sounds robotic or fails after a few seconds.
The Root Cause: The SBC negotiates a codec like G.729 that Genesys Cloud does not have licensed for the specific user role, or vice versa.
The Solution: Inspect the SDP Offer/Answer in the SIP logs. Force both endpoints to prefer PCMU (G.711u) as the primary codec. In the Genesys Cloud Trunk settings, set the Preferred Codec to PCMU. On the Microsoft SBC, adjust the media profile to prioritize PCMU over G.729 for this specific trunk connection.

Edge Case 3: Call Drop on Transfer

The Failure Condition: A call is transferred from a Teams user to a Genesys Cloud agent, but the transfer fails or drops the caller.
The Root Cause: Microsoft Teams uses REFER methods for transfers which may not be fully supported in all SIP Trunk configurations without specific header passing.
The Solution: Enable Refer Support in the Genesys Cloud SIP Trunk configuration. Ensure that the Refer-Sub header is passed through the SBC. If using a third-party SBC, verify that the firmware supports standard RFC 3515 REFER handling and does not strip the Replaces header required for blind transfers across heterogeneous systems.

Official References