3-way Call DTMF 3rd Party Issue

FreePBX Applications / Modules
1

Hello,

I am at my wits end and need some help. I’ve diagnosed the issue and found where the issue is but I can’t find how to fix the issue.

PBX Version: 15.0.29
PBX Distro: 12.7.8-2203-2.sng7
Asterisk Version: 16.29.1

Issue:
Agent receives call >> places call on hold >> dials credit card process company >> enters account code >> conf in customer >> customer enters CC number.
DTMF works perfectly fine all the way until the customer enters their card number. DTMF is not sent at all. To get around it the agent is writing down the number and entering it for them since DTMF still works for them.

I setup a scenario for testing.
DID >> IVR option 1 >> to test phone.
Dialing from my cell phone in I press 1 and DTMF is working fine, my phone rings.
I answer >> place on hold >> dial my office phone (different server with IVR) >> conf in cell phone that’s on hold >> press 1 (or any digit) and nothing happens >> press 1 (or any digit) from desk phone and it works perfectly fine.

DTMF is working perfectly fine except for when the calls are in a simple-bridge. Then it doesn’t pass DTMF only for the external call.

I’ve turned on “dtmf_passthrough” in custom config. I’ve tried doing a straight conference instead of putting the call on hold. I’ve tried different trunks as well. It is only when in the bridge.

I’ve captured the log for the calls and I can’t find any difference between the log line where I call in and select 1 and where I am pressing it during the 3-way call.

Anyone have any ideas as to where the issue is and how to fix it?

Log: Inbound Call >> IVR >> 1 >> transfer to extension (Recognizes DTMF and transfers call to extension 700)

[2023-01-13 21:33:29] DTMF[11418][C-00000018]: channel.c:4013 __ast_read: DTMF begin ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:33:29] DTMF[11418][C-00000018]: channel.c:4017 __ast_read: DTMF begin ignored ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:33:29] DTMF[11418][C-00000018]: channel.c:3899 __ast_read: DTMF end ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a, duration 260 ms
[2023-01-13 21:33:29] DTMF[11418][C-00000018]: channel.c:3988 __ast_read: DTMF end passthrough ‘1’ on PJSIP/vitel-inbound-sbc-0000002a

Log: 3-way call connected and DTMF not sent
(Last DTMF line is pressing 1 from the desk phone x700)

[2023-01-13 21:33:57] DTMF[11418][C-00000018]: channel.c:4013 __ast_read: DTMF begin ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:33:57] DTMF[11418][C-00000018]: channel.c:4024 __ast_read: DTMF begin passthrough ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:33:57] DTMF[11418][C-00000018]: channel.c:3899 __ast_read: DTMF end ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a, duration 280 ms
[2023-01-13 21:33:57] DTMF[11418][C-00000018]: channel.c:3950 __ast_read: DTMF end accepted with begin ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:33:57] DTMF[11418][C-00000018]: channel.c:3988 __ast_read: DTMF end passthrough ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:01] DTMF[11418][C-00000018]: channel.c:4013 __ast_read: DTMF begin ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:01] DTMF[11418][C-00000018]: channel.c:4024 __ast_read: DTMF begin passthrough ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:01] DTMF[11418][C-00000018]: channel.c:3899 __ast_read: DTMF end ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a, duration 280 ms
[2023-01-13 21:34:01] DTMF[11418][C-00000018]: channel.c:3950 __ast_read: DTMF end accepted with begin ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:01] DTMF[11418][C-00000018]: channel.c:3988 __ast_read: DTMF end passthrough ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:03] DTMF[11418][C-00000018]: channel.c:4013 __ast_read: DTMF begin ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:03] DTMF[11418][C-00000018]: channel.c:4024 __ast_read: DTMF begin passthrough ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:03] DTMF[11418][C-00000018]: channel.c:3899 __ast_read: DTMF end ‘1’ received on PJSIP/vitel-inbound-sbc-0000002a, duration 270 ms
[2023-01-13 21:34:03] DTMF[11418][C-00000018]: channel.c:3950 __ast_read: DTMF end accepted with begin ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:03] DTMF[11418][C-00000018]: channel.c:3988 __ast_read: DTMF end passthrough ‘1’ on PJSIP/vitel-inbound-sbc-0000002a
[2023-01-13 21:34:06] DTMF[11446][C-00000019]: channel.c:4013 __ast_read: DTMF begin ‘1’ received on PJSIP/700-0000002c
[2023-01-13 21:34:06] DTMF[11446][C-00000019]: channel.c:4024 __ast_read: DTMF begin passthrough ‘1’ on PJSIP/700-0000002c
[2023-01-13 21:34:06] DTMF[11446][C-00000019]: channel.c:3899 __ast_read: DTMF end ‘1’ received on PJSIP/700-0000002c, duration 160 ms
[2023-01-13 21:34:06] DTMF[11446][C-00000019]: channel.c:3950 __ast_read: DTMF end accepted with begin ‘1’ on PJSIP/700-0000002c
[2023-01-13 21:34:06] DTMF[11446][C-00000019]: channel.c:3988 __ast_read: DTMF end passthrough ‘1’ on PJSIP/700-0000002c
– Channel PJSIP/700-0000002c left ‘simple_bridge’ basic-bridge <8538a8a7-efe7-4c4e-98e8-1bed7e8f72fd>

Anyone have any ideas?
Thanks!!

2

Maybe try DTMF ‘inband’

3

I’ve tried every one of them. I’ve tried them on the extensions in combination as well. Some of them kill DTMF entirely of course and others had no success.

I just found “allow dtmf transfer features” in asterisk settings. It was turned off. I turned it on and am trying that now.

4

No dice.

I forgot to mention that last year their server crashed. I moved them from a hosted environment to a dedicated server with the latest FreePBX. I also configured everything for PjSIP instead of chan_sip. I believe that is when the issue started. It used to work fine.

I also tried a trunk configured for chan_sip instead of PjSIP but that didn’t work either.

Could it be something with PjSIP? I’ve tried different codecs, from g711 to g729 with no success.

5

Update:

I have several servers out there and I tried the same thing on 3 different ones and all of them had the exact same results. Conf in 3rd party and 3rd party DTMF is not passed through.

There is something I am missing. Are there settings for the simple-bridge that asterisk creates that would allow for DTMF passthrough? All other DTMF works for in/outbound, just not in a 3-way call.

6

If in a 3-way call initiated on the endpoint itself, then it is up to that endpoint to pass through any DTMF. Asterisk isn’t involved with the conference in that case, and options relating to passing through DTMF for conferences would not apply.

7

Okay, I was thinking asterisk was just bridging the two channels together. I did look in the settings for the phones and didn’t find anything labeled for pass-through, I will look again.

Do you know what it’s most commonly called or something I should look for? Been looking so long it’s all run together :confused:

8

Also, what’s weird about it is that it was working fine for a long time and didn’t break until around the time I switched servers. I was having an issue with the grandstream phones I was using at first, years ago, and switched them to Cisco 972 phones which worked right out the box.

9

I don’t know regarding endpoints. I can only speak of Asterisk.

10

No worries. I’m just glad to have some help with this. It’s driving me nuts because I know it’s something dumb that I just need to check a box or add/remove a character somewhere.

11

If I have Symmetric RTP turned on in Asterisk endpoints do I need to have it active on the endpoint as well if there is an option for it?

12

I set the inbound call to go to a conference bridge I setup for testing and DTMF works fine for entering the password but once in none of the options work. Pressing *# to leave the conf or any of the codes like vol work.

Is there a way to turn on DTMF for external calls for conferences?

13

The dtmf_passthrough option will pass through DTMF. I don’t know how that is explicitly done in FreePBX, or whether your past attempt was correct or not.

14

I found a similar thread on here that dicko commented on where he linked to the custum conf config file and so I set it up in there but I don’t think it’s working properly as the changes to it are not reflecting the function.

15

If both ends needs symmetric RTP, you will end in a stalemate, where neither is sending to the other, so the other can never learn the correct address. Typically setting it at both ends will be tolerated, if only one end actually needs it, as the end that doesn’t need it will initially send to the offered address from the end that does it, so that end has RTP traffic from which to learn the address of the first mentioned end.

16

Ok, that makes sense. I never set it on the endpoint before. Asking because DTMF transports over RTP or in the audio channel, depending on settings so I wasn’t sure if there was something there or not. I’ll leave it default.

thanks

17

Haha, I had it working 10 minutes after my last comment but I couldn’t send the message below because I reached the “New User” message limit. Had to wait 20 HOURS to say thank you. LMAO!!

Oh man, where oh where can I buy you two a beer?!

Problem solved by both @dicko and @jcolp

I changed the “send DTMF” method in the phone to “in-band” and that did the trick. I also had to change it to inband in FreePBX as well in extension >> advanced. I could hear my cell phone DTMF over the receiver and was able to dial the external number!! Applied it to the phones this morning and confirmed everything working great.

I was thinking in the way POTS lines and a key system work but now I understand that the phone is the one handling the DTMF processing.

Thanks again guys, I have been messing with this for 5 days now!!!

18

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