Here we will try to quickly explain how to troubleshoot RTP DTMF problems in Asterisk.

In order to debug problems of incorrectly detected DTMF digits, one needs to figure out whether digits are detected at all and why they are ignored.

First one should detect via tcpdump that DTMF are indeed sent! And if that is the case, one goes further…

To do that certain logging options have to be set:

1. logger.conf has to be modified and full debugging with dtmf option has to be enabled

full => notice,warning,error,debug,verbose,dtmf,fax

2. core set debug 3 or core set debug 4 needs to be set in Asterisk CLI

3. rtp set debug on needs to be enabled in Asterisk CLI

4. logger reload to apply logger details

Since there will be lots of data, I recommend that you enable above quickly and then reset to default settings:

1. core set debug 1 in Asterisk CLI

2. rtp set debug off

3. Disable full in logger.conf and perform logger reload

Once above is enabled full file will be filled with data about RTP packets, try to grep by string DTMF. Once you identify the interesting line what you need to look for is something like this: [Mar 20 09:27:43] VERBOSE[21156] res_rtp_asterisk.c: Sent RTP DTMF packet to x.x.x.x:14584 (type 101, seq 052452, ts 411623440, len 000004)

The important piece is in above log message is number 21156 which is thread id to look for. Grep by that number and you will see all relevant messages for that particular thread-id.

RTP bridging modes

In case you see message Sent RTP packet that means that the core bridging is in use. In such case Asterisk will reconstruct each RTP frame differently and this may affect DTMF RTP packets as well.

Here is info on possible RTP bridges (from HERE )

• Native bridge: Media is sent directly between devices, never going through Asterisk at all. This requires the devices to be speaking the same codecs, no Asterisk features are enabled that process media (volume adjustment, recording, DTMF features, etc), and NAT has to not prevent media from going between the devices.
• Packet2Packet: Media is sent to Asterisk and then immediately sent out to the other party without going through any intermediate processing. This has the same requirements as "native" bridging except for the NAT one. Most typically, you'd see this when using SIP peers that had "canreinvite" (or "directmedia") set to no.
• "core": You'd never actually see it called this since this is the default behavior. This is where media comes into Asterisk, gets translated into an internal frame of some sort, and then goes out the other side, where it is translated back into whatever native method that the channel type requires.

One can try to enable Packet2Packet bridging, but this will only work if certain conditions are met:

1. Both sides have to be SIP

2. Both sides have to have same audio codecs and same payload size (for instance 20ms)

3. Both sides have to have video support disabled

4. Both sides must not have options for DTMF processing (such as tT, instant recording etc)

5. Dynamic features in Settings > Servers > Edit must be turned off

6. Direct media must be off

7. DTMF settings on both sides must be same (eg RFC2833)

8. Jitterbuffer must be off

9. SRTP encryption must be off

If above conditions are met (and possibly certain other options need to be fiddled with), when you do rtp set debug on you should see something like this: Sent RTP P2P packet to x.x.x.x:15632 (type 101, len 000004).