[asterisk-app-dev] absorbDTMF option only working on one channel

[Richard Frith-Macdonald]

> On 18 Dec 2019, at 12:59, Joshua C. Colp <jcolp at sangoma.com> wrote:
> 
> On Wed, Dec 18, 2019 at 8:56 AM Richard Frith-Macdonald <richard.frith-macdonald at engagehub.com> wrote:
> 
> 
> > On 18 Dec 2019, at 12:28, Joshua C. Colp <jcolp at sangoma.com> wrote:
> > 
> > 
> > For the non-mobile leg is it configured with dtmf_mode=rfc4733?
> 
> There's no specific dtmf_mode configured for it, which the documentation says means rfc4733 (the default).
> 
> > If so then it looks as though from the perspective of Asterisk it is not actually forwarding DTMF through, at least DTMF it has been told about. If the DTMF is also coming in over the audio stream itself, then that would be forwarded on as-is since it is the responsibility of the remote party to suppress that audio and not Asterisk.
> 
> Shouldn't I be seeing that in the log as RTP packets?  I don't see any audio packets interleaved with the DTMF ones.
> 
> It depends where exactly it's inserted into the audio stream. It's all just theories right now and suggestions on how to narrow things down.
> 
> 
> > A test would be sending the mobile leg to Record() and seeing if the DTMF is recorded. Record() doesn't record DTMF that Asterisk knows about, but merely records the audio stream as received. If it's played back and there is DTMF then it's not being suppressed as expected by the remote side.
> 
> I'll try that later.

I tried making a recording of the mobile leg (before bridging), and it seems the dtmf tones are present in the recording.

> If the remote side (mobile phone / network operator / SIP provider) is sending DTMF both in rfc4733 form and in the audio dat itself, is there anything asterisk can do to remedy that (eg apply a notch filter to the audio before passing it on over the brdge)?
> 
> Nothing springs to mind. We really depend on the remote endpoint to remove it.

:-(

Thanks for the help.  I guess I need to follow this up with our SIP supplier.
Any other ideas welcome of course.
-- 




Every customer is unique. Engage each one. 


www.engagehub.com 
<http://www.engagehub.com/> 

This communication is sent by Engage Hub and 
contains information which is confidential and privileged and is intended 
for the use of the addressee only. If you are not the intended recipient 
please destroy and contact the sender. Please note that any distribution, 
copying or use of this communication or the information in it is strictly 
prohibited. Any views expressed in this email are those of the individual 
sender and may not necessarily reflect the views of Engage Hub. Engage Hub 
makes no warranties that emails are virus free. This company is registered 
in England and Wales as Brainstorm Mobile Solutions Ltd and trading as 
Engage Hub (registered at Studio 311 Highgate Studios, 53-79 Highgate Road, 
London NW5 1TL. Company Number: 01661467; VAT Number: 214 9845 90) and 
Oxygen8 Communications Limited (registered in Ireland at 1st Floor, 21-22 
Grafton Street, Dublin 2, Ireland. Company No: 350312; VAT Number: 
6370312O).