Internal phone DTMF not recognised

FreePBX Endpoints
1

Hi,

I have installed Freepbx 16 with Asterisk 18 on a Raspberry Pi running Bullseye. I also have another test desktop PC machine running the same versions.

For some strange reason DTMF is being recognised without any problems on the desktop PC but just not recognised at all on the Raspberry PI. I know therefore it is not the phone. The DTMF setting on the extension in Freepbx is set to RFC4733.

I’ve tried debugging for DTMF in the logs but nothing appears after turning on DTMF logging and then setting the debug level to 3 in the Asterisk CLI.

I’ve compared settings between the two systems but just can’t nail down what the issue might be.

Any ideas?

Thanks.

2

First, please confirm:

The DTMF logging you did does show button presses on the desktop system, using the same device.

On outgoing external calls on the Pi from the same device, DTMF works properly.

On *43 (echo test), you can hear your echo, but pressing # during the introduction does not interrupt it.

Phone make/model? Have you tried with another type of phone/softphone/mobile SIP app?

3

Thanks very much for the reply.

I’ll do those tests and post the logs.

Thanks again…

4

So I ran the test on both the desktop PC and the Raspberry Pi.

The VoIP phone used for the test is a Snom 760. Have also tried with a Gigaset DECT phone and that does not work on Raspberry Pi either.

In asterisk CLI -

core set debug 3
rtp set debug ip 192.168.4.24

Made a call to voicemail and operated some digits through the menus.

The desktop log has this in it:

[2023-08-28 20:50:55] VERBOSE[26267][C-00000025] res_rtp_asterisk.c: Sent RTP packet to 192.168.4.24:58792 (type 00, seq 006072, ts 308334, len 000160)
[2023-08-28 20:50:55] VERBOSE[26267][C-00000025] res_rtp_asterisk.c: Got RTP packet from 192.168.4.24:58792 (type 101, seq 001927, ts 306640, len 000004)
[2023-08-28 20:50:55] VERBOSE[26267][C-00000025] res_rtp_asterisk.c: Got RTP RFC2833 from 192.168.4.24:58792 (type 101, seq 001927, ts 306640, len 000004, mark 0, event 00000000, end 1, duration 01760)
[2023-08-28 20:50:55] DEBUG[26267][C-00000025] res_rtp_asterisk.c: - RTP 2833 Event: 00000000 (len = 4)
[2023-08-28 20:50:55] DEBUG[26267][C-00000025] res_rtp_asterisk.c: (0x7f6ea00227e0) RTP creating END DTMF Frame: 48 (0), at 192.168.4.24:58792
[2023-08-28 20:50:55] DTMF[26267][C-00000025] channel.c: DTMF end ‘0’ received on PJSIP/404-0000003d, duration 220 ms
[2023-08-28 20:50:55] DTMF[26267][C-00000025] channel.c: DTMF end passthrough ‘0’ on PJSIP/404-0000003d

So the DTMF was recognised with no problem.

Ran the same test on the Raspberry Pi but no DTMF entries at all in the logs

The echo test on the desktop recognised the # key but the Raspberry Pi did not although the echo itself did work, just didn’t recognise the #.

Does give any clues as to what is going on?

Thanks.

5

Using in-band DTMF might work around the problem. If your internet connection is stable with essentially no packet loss and minimal jitter, this is probably acceptable.

Otherwise, find out whether RFC4733 packets are being sent (the SDP in the 200 OK sent by Asterisk may not include it). If they are, then it appears that Asterisk is not recognizing them. I know nothing about that logic, but with luck a higher verbosity will show something useful.

On the Pi, does DTMF work on external outgoing calls? On external incoming calls, e.g. when trying to remotely listen to voicemail?

6

Thank you the suggestions.

I set the extension to in-band and this did indeed get around the problem. Strange that the same phone works fine with RFC4733 packets on the desktop but not on the Pi which would lead me to think that either something on the Pi is blocking those packets for whatever reason?

Next step is to try DTMF on inbound/outbound calls and I’ll report back…

Thanks.

7

:man_facepalming: Duh! Just discovered the problem and it all became very obvious after running a tcpdump.

The Raspberry Pi was plugged into one of the router ports and not the network switch and the router had SIP ALG turned on.

Now all resolved but thank you for your valued input in tracking down the issue.