Overview

For B2B telecom engineers deploying ONT VoIP services, selecting the correct DTMF transport method is critical for ensuring IVR navigation, voicemail access, and automated call handling function reliably. The three primary methods—In-band, RFC2833 (RTP Named Telephony Events), and SIP INFO—differ fundamentally in how they carry digit information across the network. This FAQ addresses the most common pre-sales compatibility questions and post-sales troubleshooting scenarios encountered when configuring DTMF on Optical Network Terminals (ONTs).

Frequently Asked Questions

Q1: What is the correct DTMF method for ONT VoIP setups?

The correct and most widely recommended DTMF method for ONT VoIP setups is RFC2833 (technically superseded by RFC 4733). RFC2833 transmits DTMF digits as separate RTP event packets outside the audio stream, ensuring reliable detection even when low-bitrate codecs like G.729 compress the voice channel. ONTs typically negotiate this method via SDP using the telephone-event payload type. If the far-end gateway or softswitch does not support RFC2833 negotiation, SIP INFO should be configured as the fallback out-of-band method. In-band DTMF should be avoided unless strictly required for legacy analog terminal adapters, as it is highly susceptible to distortion and clipping.

Q2: Why is in-band DTMF unreliable for ONT VoIP deployments?

In-band DTMF is unreliable because the DTMF tones are encoded using the same lossy voice codec as speech, which frequently distorts the dual-frequency signals beyond recognition. Low-bitrate codecs such as G.723 and G.729 are designed to compress human speech and often fail to reproduce the precise 697–1633 Hz frequency pairs required for accurate DTMF detection. Additionally, in-band tones are vulnerable to network impairments like jitter and packet loss, and echo cancellers may inadvertently suppress the tones. For B2B applications requiring guaranteed IVR interaction, out-of-band signaling (RFC2833 or SIP INFO) eliminates these codec-related risks entirely.

Q3: How does RFC2833 differ from SIP INFO for DTMF transport?

RFC2833 carries DTMF as RTP event packets within the media stream, while SIP INFO sends digits as out-of-band signaling messages along the SIP signaling path. RFC2833 packets share the same sequence number and timestamp space as the audio RTP, allowing precise timing alignment and built-in redundancy against packet loss. SIP INFO messages travel separately from the media path, meaning they depend on reliable SIP signaling delivery and may experience different latency characteristics. RFC2833 is generally processed by VoIP hardware DSPs with minimal CPU load, whereas SIP INFO relay requires CPU intervention on the gateway or ONT. Most B2B deployments prioritize RFC2833 for its tighter media synchronization and hardware efficiency.

Q4: How do I configure the DTMF method on an ONT via CLI?

The correct CLI configuration depends on the specific ONT vendor and firmware, but the general workflow involves enabling RFC2833 in the SIP profile and ensuring SDP negotiation is permitted. On Alcatel-Lucent compatible ONTs, for example, the parameter enable_rfc2833 must be set to yes within the VoIP ent-profile for the ONT to offer RFC2833 in SDP. You must also verify that the softswitch or SIP server is configured to accept the negotiated telephone-event payload type (commonly 96–127, with 101 being typical). If interoperability issues arise, temporarily forcing SIP INFO on both the ONT and the call agent can isolate whether the problem lies in the RFC2833 negotiation or the media path itself.

Q5: What causes DTMF failures after an ONT firmware upgrade?

DTMF failures after firmware upgrades are most commonly caused by SDP negotiation mismatches or default profile resets. A firmware update may alter the default enable_rfc2833 setting, change the advertised payload type, or modify codec preference order—any of which can break previously working digit transmission. Troubleshoot by capturing a SIP trace and verifying that the ONT still includes the telephone-event line in its SDP offer or answer. Check whether the firmware release notes mention changes to DTMF handling or VoIP profile defaults. If the softswitch rejects the new payload type, reconfiguring the ONT to use the original payload value or switching to SIP INFO will restore service while a vendor fix is pursued.

Q6: Can I use both RFC2833 and SIP INFO simultaneously (dual mode)?

Yes, dual-mode DTMF is supported on some ONT and session border controller platforms, but it should be used only as a transitional troubleshooting measure. In dual mode, the device sends both RFC2833 RTP events and SIP INFO messages for each digit, maximizing the chance that the far-end detects at least one form of signaling. However, this approach doubles signaling overhead and can cause duplicate digit detection if the receiving gateway is not configured to suppress redundant events. For production B2B deployments, select a single negotiated method—preferably RFC2833—and ensure both endpoints consistently honor the SDP agreement.

Q7: How do I troubleshoot one-way DTMF audio on an ONT SIP trunk?

One-way DTMF audio typically indicates an SDP direction attribute mismatch or asymmetric codec negotiation between the ONT and the softswitch. Verify that the ONT's SDP includes a=sendrecv for the telephone-event payload type and that the softswitch is not forcing a=sendonly or a=recvonly on its side. Capture RTP traces on both the ONT LAN-side and the softswitch media interface to confirm whether RFC2833 packets are present in both directions. If the ONT sends RFC2833 events but receives none, the return path is being blocked—check firewall rules, SBC media policies, or NAT traversal settings. As a temporary workaround, switching both sides to SIP INFO can bypass media-path issues while the RTP routing problem is resolved.