DTMF not passing thru on transfer

Asterisk Asterisk Support
1

This is probably more educational than technical, but here goes:

I have an IVR running on Asterisk 15.2.2. Calls come in over a SIP trunk. dtmfmode is set to rfc2833 on the SIP trunk.

A few steps down the IVR path, the caller can select an option and be forwarded to an offsite 3rd party IVR to complete their call. It’s blind dial out, I don’t care what they do on the 3rd party IVR, and when they hang up the call on the 3rd party, all the better. I’m just qualifying the call before forwarding for executions, and I am not waiting on any feedback back.

Here is an abbreviated test from extensions.conf:

[dialout-test]
exten => s,1,Answer()
exten => s,n,Playback(IVR/fwd_third_party_ivr)
exten => s,n,Dial(SIP/twilio0/+17163280303,120,r)

Here’s the problem. We are successfully accepting DTMF up to this point, but as soon as we forward the call, no DTMF is “replayed” to the 3rd party IVR though it is heard on the line.

Every site I’ve googled states that DTMF should just work via passthrough; however, it is not in our application.

I am already logging dtmf:

[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF begin passthrough ‘5’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end ‘5’ received on SIP/twilio4-00000238, duration 160 ms
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end accepted with begin ‘5’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end passthrough ‘5’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF begin ‘6’ received on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF begin passthrough ‘6’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end ‘6’ received on SIP/twilio4-00000238, duration 160 ms
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end accepted with begin ‘6’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end passthrough ‘6’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF begin ‘#’ received on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF begin passthrough ‘#’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end ‘#’ received on SIP/twilio4-00000238, duration 160 ms
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end accepted with begin ‘#’ on SIP/twilio4-00000238
[Mar 22 15:49:12] DTMF[15423][C-00000223] channel.c: DTMF end passthrough ‘#’ on SIP/twilio4-00000238
[Mar 22 15:53:00] DTMF[16000][C-00000224] channel.c: DTMF begin ‘4’ received on SIP/twilio1-0000023a
[Mar 22 15:53:00] DTMF[16000][C-00000224] channel.c: DTMF begin ignored ‘4’ on SIP/twilio1-0000023a
[Mar 22 15:53:00] DTMF[16000][C-00000224] channel.c: DTMF end ‘4’ received on SIP/twilio1-0000023a, duration 260 ms
[Mar 22 15:53:00] DTMF[16000][C-00000224] channel.c: DTMF end passthrough ‘4’ on SIP/twilio1-0000023a
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF begin ‘5’ received on SIP/twilio1-0000023a
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF begin ignored ‘5’ on SIP/twilio1-0000023a
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF end ‘5’ received on SIP/twilio1-0000023a, duration 260 ms
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF end passthrough ‘5’ on SIP/twilio1-0000023a
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF begin ‘#’ received on SIP/twilio1-0000023a
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF begin ignored ‘#’ on SIP/twilio1-0000023a
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF end ‘#’ received on SIP/twilio1-0000023a, duration 260 ms
[Mar 22 15:53:01] DTMF[16000][C-00000224] channel.c: DTMF end passthrough ‘#’ on SIP/twilio1-0000023a
[Mar 22 15:53:10] DTMF[16000][C-00000224] channel.c: DTMF begin ‘1’ received on SIP/twilio1-0000023a
[Mar 22 15:53:10] DTMF[16000][C-00000224] channel.c: DTMF begin ignored ‘1’ on SIP/twilio1-0000023a
[Mar 22 15:53:11] DTMF[16000][C-00000224] channel.c: DTMF end ‘1’ received on SIP/twilio1-0000023a, duration 260 ms
[Mar 22 15:53:11] DTMF[16000][C-00000224] channel.c: DTMF end passthrough ‘1’ on SIP/twilio1-0000023a

Twilio (SIP provider) states they do not see DTMF on the second CallSID, back to them. They do see them from Twilio to Asterisk.

Can someone please educate me on what I am missing?

Thanks in advance.

Chris

2

You would need to provide the configuration as well as the output of “rtp set debug on”. That would show whether DTMF is going out via RFC2833.

3

Many thanks for the reply.

Trunk Config:

twilio-trunk
type=peer
context=from-twilio ;Which dialplan to use for incoming calls
;dtmfmode=rfc4733
dtmfmode=rfc2833
canreinvite=no
insecure=port,invite
transport=tls
qualify=yes
encryption=yes
media_encryption=sdes

Call starts at 17:26:15.
Forward happens at 17:26:19.
I start pressing digits at 17:26:27.

asterisk-20180326.txt (2.0 MB)

4

Based on the log it appears as though we are sending DTMF out to them, so from Asterisk it is behaving as it should.

5

Thank you for the review. We’ll check with Twilio but knowing them, they will be stubborn about rfc4733.

Cheers!

6

Said to hell with my stubborness, and swapped out chan_sip for chan_pjsip and DTMF is passing through a-ok.