Troubleshooting SIP Interoperability Failures between Genesys Cloud and Legacy Avaya CM

How-To-Articles
1

Troubleshooting SIP Interoperability Failures between Genesys Cloud and Legacy Avaya CM

What This Guide Covers

  • Diagnosing and resolving signaling and media failures when integrating Genesys Cloud BYOC with legacy Avaya Communication Manager (CM) environments via a Session Border Controller (SBC).
  • Establishing a stable SIP trunking relationship that handles session refreshes, codec negotiation, and transfer signaling (REFER) without call drops or one-way audio.
  • The end result is a high-availability voice path that supports full feature parity across the hybrid cloud boundary.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 1, 2, or 3 with BYOC (Premise or Cloud) enabled.
  • Permissions: Telephony > Trunk > View, Telephony > Trunk > Edit, and access to the local SBC (AudioCodes, Ribbon, or Avaya SBCE).
  • Network: SIP (5060/5061) and RTP (16384-32768) connectivity between the SBC and Genesys Cloud Edges/Media Tiers.
  • Hardware: Avaya CM v6.3+ with Processor Ethernet (PE) or CLAN/Medpro resources.

The Implementation Deep-Dive

1. Resolving oRTP Timestamp Drift and Clock Sync

Legacy Avaya Medpro cards (TN2302/TN2602) often exhibit timestamp drift when interfaced with modern cloud-native media servers. Genesys Cloud’s media tier is strict about oRTP (Open Real-time Transport Protocol) sequencing. If the Avaya system’s clock is not perfectly synchronized with an NTP source shared by the SBC, you will experience “robotic” audio or silent drops after 15-20 minutes.

The Trap:
Configuring the Avaya IP-Codec-Set to use G.729 without verifying that the SBC is performing transcoding. Genesys Cloud prefers Opus or G.711. If Avaya sends G.729 and the SBC transparently passes it, Genesys Cloud may reject the media stream or fail to allocate a transcoder, leading to immediate call termination upon answer.

Architectural Reasoning:
Always terminate the Avaya SIP trunk on a standards-based SBC (like an AudioCodes Mediant). Do not attempt a direct SIP tie-trunk from Avaya CM to Genesys Cloud. The SBC acts as a “normalization layer,” absorbing Avaya’s non-standard header behaviors (like the User-to-User header format) before they reach the cloud.

2. Handling SIP Session Timers and UPDATE vs. re-INVITE

Avaya CM typically relies on UPDATE packets for session refreshes. However, many older Avaya configurations fail to respond correctly to re-INVITE requests initiated by Genesys Cloud for session heartbeats. If the session timer expires without a successful refresh, the call will drop at exactly the 15-minute or 30-minute mark (depending on the Min-SE value).

The Trap:
Leaving “Session Refresh Method” as “Auto” on the SBC. On older Avaya CM versions, the SBC must be configured to Force re-INVITE for session refreshes toward the Avaya side, while allowing UPDATE or re-INVITE toward Genesys Cloud.

3. Transfer Signaling: REFER vs. Hairpinning

When an agent on Genesys Cloud transfers a call back to an extension on Avaya, the default behavior is to send a SIP REFER. Many legacy Avaya configurations do not support REFER on SIP tie-trunks without specific firmware and “SIP Trunk” signaling group adjustments.

The Trap:
Enabling REFER on the Genesys Cloud trunk without verifying the SBC’s ability to “Localize” the refer. If the SBC passes the REFER to Avaya and Avaya doesn’t understand it, the transfer fails, and the caller is disconnected.

Solution:
Configure the SBC to perform REFER-to-re-INVITE normalization. The SBC handles the REFER from Genesys Cloud and executes a new INVITE to Avaya, effectively “hairpinning” the media at the SBC. This is more stable for legacy environments.

Validation, Edge Cases & Troubleshooting

Edge Case 1: One-Way Audio on Inbound Calls

  • The Failure Condition: Caller can hear the agent, but the agent hears silence.
  • The Root Cause: Avaya CM sending its internal IP address in the SIP Contact header or SDP c= line instead of the SBC’s public/interface IP.
  • The Solution: Enable SIP NAT Traversal or Topology Hiding on the SBC. Ensure the SBC is rewriting the SDP c= line to its own IP address before the packet is sent to Genesys Cloud.

Edge Case 2: 488 Not Acceptable Here (Codec Mismatch)

  • The Failure Condition: Call fails immediately with a 488 error.
  • The Root Cause: Avaya is requesting G.711mu but Genesys Cloud is configured for a region that defaults to G.711alaw, or Avaya is sending “T.38” fax relay packets for a voice call.
  • The Solution: Explicitly lock the IP-Codec-Set in Avaya to match the Genesys Cloud Trunk configuration. On the SBC, implement a Media List that enforces a strict codec priority: Opus (first), G.711 (fallback).

Official References