Resolving DTMF Interoperability Failures: RFC 2833 / RFC 4733

Problem

Inbound or outbound DTMF digits are ignored or duplicated by IVR systems and remote endpoints due to dynamic payload type mismatches, missing SDP telephone-event negotiation, or dual-transmission (RFC 2833 combined with in-band audio tones) across SIP trunks and Session Border Controllers (SBCs).

Symptoms

• IVRs fail to respond when callers press digits on their keypad.
• Double digit presses are registered (e.g., pressing '1' registers as '11').
• Wireshark captures show RTP Event packets with dynamic payload types not matching the SDP negotiation.
• Asterisk or FreeSWITCH CLI reports 'Unhandled RTP payload type' when DTMF buttons are pressed.

Root cause

RFC 2833/4733 relies on dynamically allocated RTP payload types (commonly 101, but legally any integer between 96 and 127). Interoperability breaks when the local system, SBC, and carrier negotiate different dynamic payload numbers without an active RTP payload remapping engine, when the SDP payload frequency (e.g., 8000 Hz vs 16000 Hz) does not match the active audio codec rate, or when the system fails to suppress in-band audio frequencies while generating out-of-band RTP events.

Resolution steps

1. step #1

   Capture and analyze the SIP SDP negotiation and RTP media packets using tshark to identify payload type mismatches or double-tone generation.

   tshark -i eth0 -n -f "udp port 5060 or udp portrange 10000-20000" -Y "sip.Method == INVITE || sip.Status-Code == 200 || rtp.p_type == 101" -T fields -e frame.time -e ip.src -e ip.dst -e sip.rtp.pt -e rtp.p_type

2. step #2

   Inspect SDP media attributes in the OFFER and ANSWER for correct telephone-event definition and clock rates (must match audio sample rate, e.g., 8000 for PCMU/G729, 16000 for G722).

   v=0
   o=FreeSWITCH 123456 123457 IN IP4 192.168.1.10
   s=FreeSWITCH
   c=IN IP4 192.168.1.10
   t=0 0
   m=audio 20002 RTP/AVP 0 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16

3. step #3

   Explicitly configure Asterisk PJSIP endpoint DTMF mode and specify the exact payload type if required by a legacy provider.

   ; /etc/asterisk/pjsip.conf
   [my-carrier-endpoint]
   type=endpoint
   context=from-external
   dtmf_mode=rfc4733
   rtp_ipv6=no
   
   ; Adjust global custom payload mapping if remote uses rigid non-standard PT
   [system]
   type=system
   ; rtp_codecs can be tailored if default dynamic mapping fails

4. step #4

   Configure FreeSWITCH SIP profile and channel parameters to enforce out-of-band RFC 2833 DTMF and remove duplicate in-band audio tones.

   <!-- In /etc/freeswitch/sip_profiles/external.xml -->
   <param name="dtmf-type" value="rfc2833"/>
   <param name="rfc2833-pt" value="101"/>
   <param name="pass-rfc2833" value="true"/>
   <!-- Suppress audio frequency tones when RFC 2833 is active -->
   <param name="rtp-digit-delay" value="20"/>

5. step #5

   If using Kamailio with RTPEngine, configure RTPEngine to actively rewrite dynamic payload types between inbound and outbound legs when bridging incompatible endpoints.

   # Inside kamailio.cfg route[NATMANAGE] or call setup handler
   rtpengine_manage("replace-origin replace-session-connection DTMF-rfc2833 codec-strip-G722 codec-offer-telephone-event/8000");

6. step #6

   Verify real-time DTMF processing in the CLI during an active call to ensure events are received without errors or fallbacks.

   # Asterisk CLI
   asterisk -rx "rtp set debug on"
   asterisk -rx "pjsip set logger on"
   
   # FreeSWITCH CLI
   freeswitch> fsctl debug_level 7
   freeswitch> switchname> uuid_debug_media <uuid> read write on

Verification evidence

Sipping trace shows SDP offer containing 'a=rtpmap:101 telephone-event/8000' and SDP answer using 'a=rtpmap:96 telephone-event/8000', but RTP media stream transmits DTMF events on PT 101 to a receiver expecting PT 96. Asterisk CLI outputs: '[Jan 15 10:12:01] NOTICE[1234]: res_rtp_asterisk.c:7890 ast_rtp_read: Unknown RTP codec 101 received from 192.168.1.50:10002'.