PJSIP inband DTMF detection

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
It seems to follow the guideline here(?): FAQ – pjsip Open source SIP, media, and NAT traversal stacks/libraries for smartphones 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

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

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.

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.

The option controls both directions.

1 Like

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.

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)?

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 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.

Is there any way to further debug this?
I have set the dtmf_mode to auto and incoming (inband) DTMF is still not recognized.

A SIP trace (pjsip set logger on) would show whether they are negotiating out-of-band DTMF. If they are, then inband is disabled.

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.

INVITE PCAP

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" <sip:+4*********7@10.*.*.*>;tag=5b002912-cf98-4e98-86cb-8e722678a61c
To: <sip:+4*********8@****.pstn.de1.twilio.com>
Contact: <sip:asterisk@51.***.***.***:5060>
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: <sip:+4*********7@10.*.*.*>;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

SIP/2.0 200 OK
CSeq: 20625 INVITE
Call-ID: da01c307-d7db-4304-b12b-d74a59f2226a
From: "+4*********7" <sip:+4*********7@10.*.*.*>;tag=5b002912-cf98-4e98-86cb-8e722678a61c
To: <sip:+4*********8@****.pstn.de1.twilio.com>;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: <sip:35.***.***.***;lr>
Server: Twilio
Contact: <sip:172.**.*.***:5060>
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?

Yes, that is correct and how it works. The “auto” functionality is strictly based on whether telephone-event is negotiated or not.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.