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