Implementing SIP Profile Configuration for Codec Negotiation and DTMF Relay Standardization

How-To-Articles
1

Implementing SIP Profile Configuration for Codec Negotiation and DTMF Relay Standardization

What This Guide Covers

This guide details the precise configuration of SIP Profiles in Genesys Cloud CX to enforce strict codec negotiation policies and standardize Dual-Tone Multi-Frequency (DTMF) relay methods across your telephony infrastructure. You will learn how to align your Genesys SIP Profile settings with your Session Border Controller (SBC) or carrier requirements to prevent codec mismatch failures, eliminate audio artifacts, and ensure reliable DTMF transmission for IVR interactions.

Prerequisites, Roles & Licensing

  • Licensing: Standard CX licensing. SIP Profile configuration is available on all tiers.
  • Permissions:
    • Telephony > SIP Profile > Edit
    • Telephony > Trunk > Edit (to associate the profile)
  • External Dependencies:
    • Access to your SBC or Carrier documentation to verify supported codecs and DTMF relay preferences.
    • Network connectivity between Genesys Cloud and the SBC on ports 5060/5061 (SIP) and the media port range (typically 10000-20000 UDP).

The Implementation Deep-Dive

1. Codec Negotiation Strategy and Priority Ordering

Codec negotiation is not merely a preference list; it is a handshake protocol that determines media quality, bandwidth consumption, and interoperability. Genesys Cloud uses the SIP Supported and Require headers alongside the SDP (Session Description Protocol) payload to negotiate codecs. The most critical architectural decision here is determining whether your environment is Codec-Agnostic (letting the carrier decide) or Codec-Strict (forcing Genesys to offer only specific codecs).

For enterprise deployments, we almost always enforce Codec-Strict negotiation. This prevents scenarios where a carrier defaults to a low-quality codec like G.729 when G.711 (PCMU/PCMA) is available, or conversely, forces high-bandwidth codecs on constrained links.

Configuring the Codec List

Navigate to Admin > Telephony > SIP Profiles. Select your active SIP Profile. Locate the Codec Settings section.

  1. Clear Default List: Genesys often pre-populates a broad list of codecs. Remove all codecs except those explicitly supported and preferred by your SBC/Carrier.
  2. Order Matters: The order in which you list codecs is the Offer Order. Genesys Cloud will offer these codecs in the exact sequence they appear in the list. The SBC/Carrier will select the first codec in that list that it also supports.
    • Recommendation: Place G.711u (PCMU) and G.711a (PCMA) at the top for voice clarity. Place G.729 below them if bandwidth conservation is required for specific long-haul routes. Place Opus or AMR-WB only if your entire path (including the carrier) supports wideband audio.

The Trap: The “Empty Intersection” Failure
A common misconfiguration occurs when the Genesys SIP Profile offers G.711u and G.729, but the SBC is configured to only accept G.711a and G.722. Since there is no common codec in the intersection of the Offer and the Answer, the SIP INVITE fails with a 488 Not Acceptable Here response.

Architectural Reasoning:
We do not rely on “Negotiation” to fix bad configuration. We rely on Pre-alignment. Before saving the SIP Profile, you must verify the SBC’s codec priority list. If the SBC prefers G.711a, your Genesys Profile must include G.711a. If you omit it, calls will fail. Always configure the Genesys Profile to mirror the SBC’s supported subset, ordered by your quality preference.

Payload Type Mapping

While Genesys handles most payload type mapping automatically, you must be aware of the standard RTP payload types:

  • G.711u: Payload Type 0
  • G.711a: Payload Type 8
  • G.729: Payload Type 18
  • G.722: Payload Type 9

If your SBC uses non-standard payload types (rare, but possible in legacy integrations), you must manually map these in the SIP Profile if Genesys does not auto-detect them. However, in 99% of cases, sticking to ITU-T standard payload types prevents SDP parsing errors.

2. DTMF Relay Standardization and Interoperability

DTMF relay is the most fragile aspect of SIP telephony. Unlike voice, DTMF tones are signaling events. If the relay method does not match between Genesys Cloud and the SBC, you will experience one of three failures:

  1. Silent DTMF: The user presses keys, but the IVR does not react.
  2. Audio Artifacts: The DTMF tone is heard as a robotic screech in the audio stream.
  3. Call Drop: The SBC rejects the INVITE due to unsupported SDP attributes for DTMF.

Genesys Cloud supports three primary DTMF relay methods: RFC 2833, In-Band Audio, and SIP INFO.

Selecting the Primary Method: RFC 2833

RFC 2833 (RTP Payload Type DTMF) is the industry standard for modern VoIP. It sends DTMF events as separate RTP packets with a specific payload type (usually 101). This method is efficient, low-latency, and does not interfere with voice quality.

Configuration Steps:

  1. In the SIP Profile, locate DTMF Settings.
  2. Set DTMF Method to RFC 2833.
  3. Ensure RFC 2833 Payload Type is set to 101 (the standard). If your carrier uses a non-standard payload type (e.g., 127), update this field accordingly.

The Trap: The “Double DTMF” Echo
A frequent issue arises when both Genesys and the SBC are configured to send DTMF via RFC 2833, but the SBC also converts RFC 2833 to In-Band Audio for downstream PSTN connectivity. If the Genesys IVR is listening for RFC 2833 and the SBC is sending both RFC 2833 (to Genesys) and In-Band (to PSTN), you may encounter timing issues.

Architectural Reasoning:
Always configure the Genesys SIP Profile to expect only the method the SBC sends to Genesys. Do not configure Genesys to handle In-Band if the SBC is sending RFC 2833. If you enable “Allow In-Band” in Genesys when the SBC is sending RFC 2833, Genesys may ignore the RFC 2833 packets because it is prioritizing audio analysis for DTMF tones, leading to missed inputs.

Fallback Strategy: SIP INFO

Some legacy carriers or specific SBC configurations (e.g., older Cisco CUBE deployments) prefer SIP INFO for DTMF. SIP INFO sends DTMF digits as out-of-band SIP messages.

Configuration Steps:

  1. Set DTMF Method to SIP INFO.
  2. This method is less efficient because it adds latency (SIP signaling overhead) and can cause jitter if the SIP signaling path is congested.

The Trap: SIP INFO Blocking
Many firewalls and SBCs are configured to block SIP INFO messages for security reasons (to prevent SIP flooding attacks). If you configure Genesys to use SIP INFO, but your firewall drops INFO messages, DTMF will fail silently.

Architectural Reasoning:
Use SIP INFO only if RFC 2833 is explicitly unsupported by the carrier. Test RFC 2833 first. If you must use SIP INFO, ensure your network security team has explicitly allowed SIP INFO methods in the firewall rules between the Genesys IP ranges and your SBC.

In-Band Audio: The Last Resort

In-Band means DTMF tones are generated as actual audio frequencies (350-1470 Hz) within the voice stream.

Configuration Steps:

  1. Set DTMF Method to In-Band.
  2. Enable DTMF Gain Adjustment if necessary (default is usually sufficient).

The Trap: Codec Interference
In-Band DTMF fails completely with G.729 or G.723 codecs because these codecs are designed to suppress non-voice sounds (like DTMF tones) to save bandwidth. If you use In-Band DTMF with G.729, the tones will be stripped out.

Architectural Reasoning:
Never use In-Band DTMF with compressed codecs. If your environment forces G.729, you must use RFC 2833 or SIP INFO. If your carrier forces In-Band, you must force G.711 on that trunk. This is a hard constraint.

3. SIP Header Manipulation and Identity Preservation

While not strictly codec or DTMF related, SIP Profile configuration includes header handling which impacts how DTMF and Codec negotiations are perceived by the SBC.

Preserving User Identity

Ensure Preserve User Identity is enabled if your SBC relies on the From or P-Asserted-Identity headers for routing decisions. If these headers are stripped or modified incorrectly, the SBC may route the call to a default queue, bypassing your IVR logic entirely.

Custom Headers for DTMF

Some SBCs require specific headers to enable DTMF relay. For example, Avaya SBCs may require a Service-URN header.

Configuration Steps:

  1. In the SIP Profile, navigate to SIP Headers.
  2. Add custom headers if required by your SBC documentation.
  3. Example: Key: Service-URN, Value: urn:sbc:dtmf:rfc2833.

The Trap: Header Size Limits
Adding too many custom headers can exceed the SIP message size limit (typically 1024 or 1460 bytes). If the INVITE packet is too large, it will be fragmented or dropped.

Architectural Reasoning:
Only add headers that are strictly required. Test with a minimal set. Use Wireshark or your SBC’s debug logs to verify that the INVITE packet size remains within the MTU (Maximum Transmission Unit) of your network path.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “One-Way Audio” Codec Mismatch

The Failure Condition:
Calls connect, but audio is only audible in one direction, or the call drops immediately after ringing.

The Root Cause:
The Genesys SIP Profile offers G.711u, but the SBC answers with G.711a. Genesys Cloud is configured to use G.711u for media, but the SBC is sending G.711a RTP packets. Genesys discards these packets because they do not match the negotiated codec.

The Solution:

  1. Check the Genesys Call Detail Record (CDR) or Interaction Log for the codec used.
  2. Check the SBC logs for the SDP Answer payload.
  3. Align the codec lists. If the SBC answers with G.711a, ensure G.711a is in the Genesys Offer list.
  4. If the SBC is forcing a codec not in the Genesys list, add it to the Genesys SIP Profile.

Edge Case 2: DTMF “Ghost” Inputs in IVR

The Failure Condition:
The IVR plays a menu, but before the user presses any keys, the IVR skips to a default option or plays an error message.

The Root Cause:
The SBC is sending DTMF events via RFC 2833, but Genesys is configured to detect In-Band. The noise floor in the audio stream is being misinterpreted as DTMF tones by the In-Band detector. Alternatively, the SBC is sending “pre-emptive” DTMF events (e.g., from a previous call leg) that Genesys is processing.

The Solution:

  1. Verify the DTMF Method in Genesys matches the SBC’s transmission method.
  2. If using RFC 2833, ensure In-Band is disabled in Genesys.
  3. In Genesys Architect, add a Wait for Input block with a Timeout of 1-2 seconds to allow any stray DTMF events to clear before starting the IVR logic.
  4. Enable DTMF Filtering in the IVR block to ignore DTMF events received before the prompt starts playing.

Edge Case 3: SIP 488 Errors on High-Load Trunks

The Failure Condition:
During peak hours, a significant percentage of calls fail with 488 Not Acceptable Here.

The Root Cause:
The SBC is overwhelmed and fails to process the full SDP payload. It may be dropping the codec negotiation or DTMF attributes. This is often exacerbated by large SIP messages (due to custom headers or long URI strings).

The Solution:

  1. Minimize the SIP Profile’s custom headers.
  2. Reduce the number of codecs in the Offer list to only the top 2-3 preferred codecs. This reduces SDP size.
  3. Check SBC logs for memory or CPU spikes during peak times.
  4. Consider implementing SIP Keep-Alives in the Genesys SIP Profile to maintain state and reduce the overhead of re-negotiating sessions.

Official References