DTMF Behavior In Asterisk 12 With PJSIP

Home » Asterisk Users » DTMF Behavior In Asterisk 12 With PJSIP
Asterisk Users 4 Comments

Hello all, We have recently upgraded some of our services to Asterisk 12 with PJSIP. We have 2 issues related to DTMF:
1. in the regular SIP channel we had DTMF auto mode, which adapted the DTMF
settings according to the incoming INVITE – RFC2833 or inband. The is no such settings in PJSIP. Do you know is there is a plan to develop it?
2. When we setup 2 peers, one RFC4733 and the other inband, the asterisk does not transcode the DTMF signals, therefore DTMF is not working. It used to work on release 11. This is really bad. Do you know of a solution to this issue? Maybe some settings?

Thanks, Yaron.

4 thoughts on - DTMF Behavior In Asterisk 12 With PJSIP

  • No one that I’m aware of is currently working on that.

    As Asterisk is an open source project, if having the ‘auto’ feature added to the PJSIP stack is something you’re interested in, you should consider writing a patch for the project [1].

    [1] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process

    That actually is a bug. You are most likely ending up in a native packet to packet bridge (or a native remote bridge), which does not decode the RTP
    stream. Hence, the inband DTMF or RFC 2833 DTMF is not being decoded and is being passed to the other side. Please do open an issue for that [2]. Make sure you provide a full DEBUG log, as that will illustrate what is actually occurring.

    Note that you can work around that issue by adding a feature flag to whatever application caused the bridging to occur.

    [2] https://issues.asterisk.org/jira

  • Hello Mathew, Thank you for the reply.

    I will open an issue and send debug information.

    Can you explain more about the workaround? A reference to the documentation would be fine.

    Thanks again, Yaron.

  • Sure – really, what you are running into is a difference in how Asterisk bridges channels:


    I suspect the reason DTMF is not decoded is because you are in a native bridge (local or remote). You can force a core two-party bridge by requiring that Asterisk decode the media and detect DTMF. Those requirements are done by setting the various ‘feature’ flags on whatever dialplan application is causing the channels to be bridged. For an example, see the ‘t’ or ‘T’ options in Dial:


  • Thank you Mathew, We tested the feature flag workaround and it worked.

    We opened a ticket – Asterisk-24459.

    If you need any information please get back to us and we will do our best.

    Thanks again, Yaron.