# PJSIP inband DTMF detection **URL:** \ **Category:** Asterisk SIP\ **Created:** [April 1, 2022, 9:08am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161 "2022-04-01T09:08:58Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![raphaelo](https://avatars.discourse-cdn.com/v4/letter/r/f19dbf/32.png) [@raphaelo](https://community.asterisk.org/u/raphaelo)\ **Post date:** [April 1, 2022, 9:08am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/1 "2022-04-01T09:08:59Z")
Dear All, Normally we’re receiving incoming DTMF tones from our Trunk with rfc4733. In some cases (depending on the calling phone it seems) we receive the DTMF inband in the audio signal. At the moment Asterisk doesn’t detect these tones. Is there any tutorial on how to detect these inband DTMF when using PJSIP? I read about a solution using SpanDSP here: [PJSIP How to detect inband DTMF (no rfc2833） — PJ SIP](https://www.spinics.net/lists/pjsip/msg18866.html) It seems to follow the guideline here(?): [FAQ – pjsip Open source SIP, media, and NAT traversal stacks/libraries for smartphones](https://trac.pjsip.org/repos/wiki/FAQ#dtmf) Would writing the C library mean I would need to recompile Asterisk to get it to work? This is much more “low level” work than I have used so far when dealing with asterisk. If there is a step by step guide it would be no problem to follow it, though. I’m using 16.16.1 (via FreePBX 16.0.19) on Debian Thanks and best regards Raphael ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [April 1, 2022, 9:36am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/2 "2022-04-01T09:36:26Z")
The available DTMF modes are documented on the wiki[1]. This includes some auto functionality, as well as inband. It does not support having multiple enabled at once however. [1] [Asterisk 19 Configuration\_res\_pjsip - Asterisk Project - Asterisk Project Wiki](https://wiki.asterisk.org/wiki/display/AST/Asterisk+19+Configuration_res_pjsip#Asterisk19Configuration_res_pjsip-endpoint_dtmf_mode) ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [April 1, 2022, 9:46am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/3 "2022-04-01T09:46:51Z")
It also wasn’t clear to me whether the same endpoint had variable behaviour. In that case, I’d suggest that the DTMF quality was too poor to reliably decode, and that is why it wasn’t being sent using RFC 4733 frames. Also, the ability to handle inband DTMF depends on codecs. You need an audio codec, not a voice codec, e.g. A-law, µ-law or G.722, for reliable DTMF transmission. It is possible that your problem is with an upstream source sending inband DTMF over a voice codec. ---
**Author:** ![raphaelo](https://avatars.discourse-cdn.com/v4/letter/r/f19dbf/32.png) [@raphaelo](https://community.asterisk.org/u/raphaelo)\ **Post date:** [April 1, 2022, 10:02am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/4 "2022-04-01T10:02:18Z")
Thanks for your replies! > The available DTMF modes are documented on the wiki As I understood it this is used for outgoing DTMF. Does it also decide on whether inband DTMF will be parsed by Asterisk? So far I used fixed rfc4733 setting. Will try using AUTO now. > It also wasn’t clear to me whether the same endpoint had variable behaviour These are all outgoing calls using the same Trunk. In 9 out of 10 cases the DTMF comes in via rfc4733, but in 1 out of 10 apparently as inband only recognizable in the audio recording. > I’d suggest that the DTMF quality was too poor to reliably decode, and that is why it wasn’t being sent using RFC 4733 frames. That is possible. Does it mean that probably “normally” an upstream source is already handling any AUDIO DTMF-\>RFC 4733 DTMF conversion, which could fail in some cases? > Also, the ability to handle inband DTMF depends on codecs From Asterisk to the Trunk we’re exclusively using alaw and ulaw. But I don’t know if other codecs are being used on “the other side” (from trunk to phone devices). > It is possible that your problem is with an upstream source sending inband DTMF over a voice codec. That is possible. So far they tell us that “in the past a MSC used to handle it, but that’s not the case anymore for some time now”. I don’t really understand how it works. If the phone decides on which DTMF method to use or the telephony provider etc. ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [April 1, 2022, 10:08am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/5 "2022-04-01T10:08:53Z")
The option controls both directions. ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [April 1, 2022, 10:40am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/6 "2022-04-01T10:40:33Z")
> [@raphaelo](#): > > So far they tell us that “in the past a MSC used to handle it, but that’s not the case anymore for some time now”. I don’t really understand how it works. If the phone decides on which DTMF method to use or the telephony provider etc. Mobile networks always send DTMF out of band, as they use codecs that won’t support DTMF (an acoustically coupled DTMF sender is unlikely to work over a mobile phone). This isn’t done over RTP. RFC 4733 is only used over networks that use RTP. ---
**Author:** ![raphaelo](https://avatars.discourse-cdn.com/v4/letter/r/f19dbf/32.png) [@raphaelo](https://community.asterisk.org/u/raphaelo)\ **Post date:** [April 1, 2022, 2:30pm UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/7 "2022-04-01T14:30:03Z")
Thanks for your explanations! As these are mobile phones and the DTMF originates from them out of band: Do I understand it correctly that some component on the way to the trunk - in some cases - translates the out of band DTMF to an AUDIO signal (inband)? ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [April 1, 2022, 2:48pm UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/8 "2022-04-01T14:48:52Z")
At least before the PSTN started going VoIP, it would have probably been the base station that put the tones inband. However, I don’t have deep enough knowledge of the mobile network architectures to be 100% sure, only that they would have been put inband before the the main PSTN was reached. [http://www.eventiotic.com/eventiotic/files/Papers/URL/a0f286ed-6b5d-471a-8f8d-d38bf2728af7.pdf](http://www.eventiotic.com/eventiotic/files/Papers/URL/a0f286ed-6b5d-471a-8f8d-d38bf2728af7.pdf) provides some information on the architecture, but it looks like the transcoding has happened before it reaches the mobile switching centre, although the exact location depends on the generation. ---
**Author:** ![raphaelo](https://avatars.discourse-cdn.com/v4/letter/r/f19dbf/32.png) [@raphaelo](https://community.asterisk.org/u/raphaelo)\ **Post date:** [April 5, 2022, 9:12am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/9 "2022-04-05T09:12:15Z")
Is there any way to further debug this? I have set the dtmf\_mode to auto and incoming (inband) DTMF is still not recognized. ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [April 5, 2022, 9:26am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/10 "2022-04-05T09:26:42Z")
A SIP trace (pjsip set logger on) would show whether they are negotiating out-of-band DTMF. If they are, then inband is disabled. ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [April 5, 2022, 9:43am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/11 "2022-04-05T09:43:51Z")
I think you are wrongly assuming that auto makes decisions based on the actual media, whereas it give flexibility to go with what is offered in the SDP. Also, as I said previously, the reason that the upstream system isn’t sending out of band DTMF, may be that the incoming DTMF has been degraded to the point where it unrecognizable. ---
**Author:** ![raphaelo](https://avatars.discourse-cdn.com/v4/letter/r/f19dbf/32.png) [@raphaelo](https://community.asterisk.org/u/raphaelo)\ **Post date:** [April 6, 2022, 7:16am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/12 "2022-04-06T07:16:48Z")
INVITE PCAP ```auto INVITE sip:+4 *********8@****.pstn.de1.twilio.com:5060 SIP/2.0 Via: SIP/2.0/UDP 51. ***.***.***:5060;rport;branch=z9hG4bKPj565956c3-3873-46b8-845b-44a4fa5c1943 From: "+4 *********7" ;tag=5b002912-cf98-4e98-86cb-8e722678a61c To: Contact: Call-ID: da01c307-d7db-4304-b12b-d74a59f2226a CSeq: 20625 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Diversion: ;reason=unconditional Max-Forwards: 70 User-Agent: Asterisk PBX 16.2.1~dfsg-1+deb10u2 Content-Type: application/sdp Content-Length: 265 v=0 o=- 1085468592 1085468592 IN IP4 51. ***.***.*** s=Asterisk c=IN IP4 51. ***.***.*** t=0 0 m=audio 15916 RTP/AVP 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv ``` OK PCAP ```auto SIP/2.0 200 OK CSeq: 20625 INVITE Call-ID: da01c307-d7db-4304-b12b-d74a59f2226a From: "+4 *********7" ;tag=5b002912-cf98-4e98-86cb-8e722678a61c To: ;tag=52623029_c3356d0b_8ecc031f-277f-48c9-a430-797932b6345a Via: SIP/2.0/UDP 51. ***.***. ***:5060;received=51.***. ***.*** ;rport=5060;branch=z9hG4bKPj565956c3-3873-46b8-845b-44a4fa5c1943 Record-Route: Server: Twilio Contact: Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY Content-Type: application/sdp X-Twilio-CallSid: CAdbd53cc59ed84bba9b4ab4e8479fe856 X-Twilio-TlsPolicy: TLSv1.2+ Content-Length: 275 v=0 o=root 568824211 568824211 IN IP4 172. **.**.** s=Twilio Media Gateway c=IN IP4 3. ***.***.*** t=0 0 m=audio 14344 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 a=ptime:20 a=maxptime:150 a=sendrecv ``` As I understand it, with **a=rtpmap:101 telephone-event/8000** **a=fmtp:101 0-16** in this call, RFC DTMF is correctly negotiated and no AUDIO DTMF is expected by asterisk so it is ignored - if existing? ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [April 6, 2022, 9:06am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/13 "2022-04-06T09:06:02Z")
Yes, that is correct and how it works. The “auto” functionality is strictly based on whether telephone-event is negotiated or not. ---
**Author:** ![system](https://global.discourse-cdn.com/asterisk/original/2X/4/475d0c889911cfb84ac4881ad6df8b523e3f9105.png) [@system](https://community.asterisk.org/u/system)\ **Post date:** [May 6, 2022, 9:06am UTC](https://community.asterisk.org/t/pjsip-inband-dtmf-detection/92161/14 "2022-05-06T09:06:24Z")
Closed on May 6, 2022, 9:06am UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.