Troubleshooting One-Way Audio in Genesys Cloud Voice with Complex NAT

How-To-Articles
1

Troubleshooting One-Way Audio in Genesys Cloud Voice with Complex NAT

What This Guide Covers

This guide details the architectural methodology for diagnosing and resolving one-way audio issues in Genesys Cloud Voice deployments where the on-premises SIP trunk or SBC operates behind complex Network Address Translation (NAT) or Carrier-Grade NAT (CGNAT). By the end of this document, you will have a validated SIP ALG configuration, a verified SDP media negotiation flow, and a definitive troubleshooting workflow for isolating whether the failure resides in the Genesys Cloud edge, the intermediate SBC, or the upstream carrier infrastructure.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud Voice license (any tier). No additional licensing is required for standard SIP trunking or SBC integration.
  • Permissions:
    • Telephony > Trunk > View
    • Telephony > Trunk > Edit
    • Telephony > Media > View
    • Telephony > Trunk > View Diagnostics
  • API/OAuth:
    • Scope: telephony:trunk:read, telephony:media:read
    • Endpoint: GET /api/v2/telephony/providers/edge/trunks/{id}
  • External Dependencies:
    • Access to the on-premises SBC (Cisco CUBE, Ribbon, AudioCodes, etc.) or SIP-enabled PBX.
    • Packet capture capability on the SBC ingress/egress interfaces (Wireshark/tcpdump).
    • Administrative access to the upstream carrier gateway (if direct SIP trunking without SBC).

The Implementation Deep-Dive

1. Understanding the SDP Media Negotiation Failure Mode

One-way audio in VoIP is almost exclusively a media path failure, not a signaling failure. The SIP INVITE and 200 OK messages establish the control plane, but the RTP/RTCP streams travel on the UDP ports defined in the Session Description Protocol (SDP) payload. In complex NAT environments, the IP address and port advertised in the SDP c= (connection) and m= (media) lines often do not match the actual routable IP address that the Genesys Cloud edge can send traffic to.

Genesys Cloud Voice acts as a SIP User Agent (UA). When it receives an INVITE from an on-premises SBC, it parses the SDP to determine where to send the RTP stream. If the SBC is behind NAT, it may advertise its private internal IP (e.g., 192.168.10.50) in the SDP. Genesys Cloud, residing in the public cloud, cannot route UDP traffic to a private RFC1918 address. The result is that Genesys Cloud sends RTP to a black hole, while the SBC receives the call setup but hears nothing. Conversely, if the SBC advertises the correct public IP but the NAT device drops the inbound UDP traffic because it was not initiated from inside the local network (stateful firewall behavior), the return audio fails.

The Trap: Configuring the SBC to use NAT keepalive packets alone. Many engineers enable SIP ALG or NAT keepalives on the SBC and assume this resolves the issue. However, if the SDP negotiation itself contains an incorrect IP address, keepalives will maintain the NAT mapping but the media will still route to the wrong destination. You must fix the SDP before relying on keepalives.

Architectural Reasoning: We prioritize SDP correctness over NAT keepalives because Genesys Cloud edges are stateless regarding media paths. They do not maintain a persistent NAT mapping on the carrier side. Every call requires a fresh SDP negotiation that explicitly defines the public routable IP and port.

2. Verifying the SIP Trunk Configuration in Genesys Cloud

Before inspecting the SBC, you must confirm how Genesys Cloud expects to handle the remote IP address. The trunk configuration dictates whether Genesys Cloud trusts the SDP c= line or overrides it with the source IP of the SIP signaling.

Navigate to Admin > Telephony > Voice Trunks. Select the relevant trunk. Inspect the Advanced tab.

  • SIP Trunk IP Address: This is the public IP address that Genesys Cloud advertises to the SBC in its SDP. Ensure this matches the IP address visible to the SBC. If the SBC is behind CGNAT, it may see a different IP than what is configured here.
  • Use Source IP for Media: If this option is enabled, Genesys Cloud will ignore the IP address in the incoming SDP and instead use the source IP address from which the SIP INVITE was received. This is the primary mitigation for simple NAT scenarios.

The Trap: Enabling “Use Source IP for Media” when the SBC performs SIP normalization. If the SBC rewrites the SIP headers to use a public IP but the underlying network path involves multiple NAT hops (e.g., SBC → Carrier Gateway → Genesys), the source IP seen by Genesys Cloud may be the Carrier Gateway’s IP, not the SBC’s public IP. This causes Genesys Cloud to send RTP to the Carrier Gateway, which may drop it or fail to route it back to the SBC.

Architectural Reasoning: In complex NAT environments, “Use Source IP for Media” is often insufficient because the source IP is not always the media termination point. The SDP c= line is the authoritative source for media routing. We must ensure the SBC injects its public IP into the SDP c= line explicitly.

3. Configuring the SBC for Correct SDP Injection

The on-premises SBC must rewrite the SDP payload to reflect its public IP address. This process is vendor-specific but follows a universal pattern.

Cisco CUBE Example:

voice class sip-profiles NAT_SDP
  absend "c=IN IP4 <PUBLIC_IP_ADDRESS>"
  absend "m=audio <PORT> RTP/AVP 8 0 101 13 9 114"

dial-peer voice 100 voip
  session protocol sipv2
  destination-pattern .
  session target ipv4:<GENESYS_EDGE_IP>
  incoming called-number .
  sip-profiles NAT_SDP
  codec g711ulaw
  no vad

Ribbon/Metaswitch Example:
In the SIP Application Designer, ensure the “SIP NAT” service is enabled and configured to rewrite the SDP c= line to the public IP address assigned to the SBC’s WAN interface.

AudioCodes Example:
Navigate to SIP > Media > SDP. Ensure “SDP Modification” is set to “Replace” and specify the public IP address in the “IP Address” field.

The Trap: Using the SBC’s internal private IP in the SDP rewrite rule. If the SBC is configured to inject 192.168.10.50 into the SDP, Genesys Cloud will send RTP to that address. The packet will never leave the local network. You must inject the public IP that is routable from the internet.

Architectural Reasoning: The SBC acts as the media anchor. By explicitly rewriting the SDP, we decouple the media path from the signaling path’s source IP. This allows the signaling to traverse NAT devices that may change the source IP (CGNAT) while ensuring the media path points to the stable public IP of the SBC.

4. Validating UDP Port Range and Firewall Rules

Genesys Cloud Voice uses a dynamic range of UDP ports for RTP/RTCP. By default, Genesys Cloud edges send media to the port specified in the SDP. However, the SBC must also be configured to accept media on the port it advertised.

If the SBC advertises port 10000 in the SDP, the SBC’s firewall must allow inbound UDP traffic on port 10000 from any Genesys Cloud edge IP. Genesys Cloud edge IP ranges are documented in the Resource Center.

The Trap: Restricting inbound UDP to a single port. Many SBCs are configured to use a single port for all media (e.g., 10000). However, if the SBC is configured to allocate dynamic ports for each call (e.g., 10000-20000), the firewall must allow the entire range. If the SBC advertises port 10050 for a specific call but the firewall only allows 10000, the media will be dropped.

Architectural Reasoning: Dynamic port allocation improves security by making it harder for attackers to predict the media port. However, it requires broader firewall rules. We recommend using a fixed port range on the SBC and documenting that range in the firewall configuration.

5. Diagnosing SIP ALG Interference

SIP Application Layer Gateways (ALG) are commonly found on routers, firewalls, and carrier gateways. SIP ALG attempts to inspect SIP messages and rewrite SDP payloads to accommodate NAT. In complex NAT environments, SIP ALG often corrupts the SDP by rewriting the IP address incorrectly or stripping necessary SDP attributes.

The Trap: Leaving SIP ALG enabled on intermediate devices. If a router between the SBC and the internet has SIP ALG enabled, it may rewrite the SDP c= line to the router’s private IP, overriding the SBC’s correct public IP injection. This causes one-way audio.

Architectural Reasoning: SIP ALG is legacy technology that does not understand modern SIP extensions like SRTP or ICE. Genesys Cloud Voice does not require SIP ALG. We recommend disabling SIP ALG on all intermediate devices between the SBC and the internet.

Validation Step: Perform a packet capture on the SBC ingress interface. Look for the INVITE message sent to Genesys Cloud. Inspect the SDP payload. If the c=IN IP4 line contains a private IP address (e.g., 192.168.x.x, 10.x.x.x, 172.16.x.x), SIP ALG is likely interfering. Disable SIP ALG on the upstream device and retest.

Validation, Edge Cases & Troubleshooting

Edge Case 1: CGNAT with Asymmetric Routing

In some carrier environments, the SBC’s public IP address is behind Carrier-Grade NAT (CGNAT). The carrier assigns a public IP to the SBC, but that IP is shared among multiple customers. The carrier gateway may rewrite the SIP headers and SDP payloads independently.

Failure Condition: The call connects, but audio is one-way. Packet captures show that Genesys Cloud sends RTP to the SBC’s advertised public IP, but the SBC does not receive the RTP packets.

Root Cause: The carrier gateway is rewriting the SDP c= line to a different IP address or port than what the SBC advertised. The carrier’s SIP ALG is active and overriding the SBC’s configuration.

Solution:

  1. Contact the carrier to disable SIP ALG on their gateway.
  2. If the carrier cannot disable SIP ALG, configure the SBC to use a static media port and ensure the carrier’s ALG is aware of this port.
  3. Alternatively, use a SIP trunk provider that does not employ SIP ALG and provides a dedicated public IP.

Edge Case 2: SRTP Mismatch Due to NAT Hairpinning

If the SBC is configured to use Secure RTP (SRTP), the NAT device must support UDP hole punching for encrypted traffic. Some firewalls drop SRTP packets if they cannot inspect the payload.

Failure Condition: The call connects with G.711 audio, but fails when SRTP is enabled. Or, the call connects with SRTP, but audio is one-way.

Root Cause: The firewall drops the SRTP UDP packets because it cannot decrypt them to verify the payload. NAT hairpinning (where the SBC sends traffic to its own public IP) may also fail if the firewall does not support symmetric NAT.

Solution:

  1. Ensure the firewall is configured to allow UDP traffic on the SRTP port range without deep packet inspection.
  2. Verify that the SBC is configured to use symmetric NAT if required by the carrier.
  3. Test with G.711 RTP only to isolate the issue to SRTP. If G.711 works but SRTP does not, the issue is firewall-related.

Edge Case 3: DNS SRV Record Misconfiguration

If the SBC uses DNS SRV records to locate the Genesys Cloud edge, the SRV record may point to a private IP address if the DNS resolver is internal.

Failure Condition: The SBC resolves the Genesys Cloud edge to a private IP address. The SIP signaling fails or times out.

Root Cause: The SBC is using an internal DNS server that does not have the correct public DNS records for Genesys Cloud.

Solution:

  1. Configure the SBC to use a public DNS server (e.g., 8.8.8.8 or 1.1.1.1) for resolving Genesys Cloud endpoints.
  2. Verify that the DNS SRV record for _sip._tls.<domain> or _sip._udp.<domain> resolves to a public IP address.

Official References