Android Linphone and DTMF

Hi,

I am running Linphone on my Google Pixel 6.

I can dial-out successfully.

When I dial out I do not hear DTMF but I see the phone number displayed on the console of my Asterisk PBX.

When I try to access voicemail I do not hear DTMF, I do not see digits displayed on the console, and voicemail prompts me to enter the number until it times out.

If I call-in externally using an analog phone DTMF works–I don’t know if this is an applicable or valid test-case. I hear the DTMF, see the digits displayed on the console, and subsequent processes are executed as a result of received DTMF.

I asked on the Linphone mailing list and they told me my configuration on the Asterisk PBX was incorrect so I am asking, here.

And troubleshooting pointers would be sincerely appreciated!!!

You configure the DTMF mode in Asterisk for the endpoint and the phone to match, with rfc2833 (or rfc4733 which is backwards compatible) being the most common.

Asterisk has nothing to do with whether you hear the tones, as those are locally generated by the phone. Asterisk may affect whether the phone thinks there is any way of sending DTMF, which might also affect whether it enables the buttons locally.

You need matching configurations on both ends. The de facto standard configuration is RFC 4733, so you want your chan_pjsip settings to have this line enabled:

It is possible that this is referred to by the older RFC, RFC 2833, on the Linphone side.

If you are using chan_sip, please upgrade, or do your own research, for the equivalent setting.

Asterisk also supports INFO, and subject to the use of appropriate codecs, inband.

You can go into Debug settings and turn on DTMF debugging to see any digits being captured by Asterisk. Hopes this helps.

Hi and thank you for responding!

Based upon the above I’ve done some research and am posting below what I tried in hopes someone can point out where I’m going wrong.

I verified PJSIP has:

dtmf_mode=rfc4733
;dtmf_mode=rfc2833

Just to test, I tried each individually and then just 2833 without any DTMF detected.

Next I (hopefully correctly interpreted and) followed the above instructions:

*CLI> logger show channels
Logger queue limit: 1000

Channel                             Type     Formatter  Status    Configuration
-------                             ----     ---------  ------    -------------
/var/log/asterisk/messages          File     default    Enabled    - NOTICE WARNING ERROR 
                                    Console  default    Enabled    - NOTICE WARNING ERROR VERBOSE
# update logger.conf
console => notice,warning,error <--from
console => notice,warning,error,dtmf,debug <--to

*CLI> logger reload
*CLI> logger show channels
Logger queue limit: 1000

Channel                             Type     Formatter  Status    Configuration
-------                             ----     ---------  ------    -------------
/var/log/asterisk/messages          File     default    Enabled    - NOTICE WARNING ERROR 
                                    Console  default    Enabled    - DEBUG NOTICE WARNING ERROR VERBOSE DTMF

A test call displayed the following (which is what I am hoping shows I correctly set-up DTMF debugging):

[Aug 23 08:34:55] DTMF[234643][C-0000004c]: channel.c:3980 __ast_read: DTMF begin '5' received on PJSIP/flowroute
[Aug 23 08:34:55] DTMF[234643][C-0000004c]: channel.c:3984 __ast_read: DTMF begin ignored '5' on PJSIP/flowroute
[Aug 23 08:34:56] DTMF[234643][C-0000004c]: channel.c:3866 __ast_read: DTMF end '5' received on PJSIP/flowroute, duration 130 ms
[Aug 23 08:34:56] DTMF[234643][C-0000004c]: channel.c:3955 __ast_read: DTMF end passthrough '5' on PJSIP/flowroute

Linphone–no dtmf displayed
Here is the console out for the session:
Please note I changed numbers for this post (I don’t use ext 1000 or 7045551234).

    -- Executing [xxxx@my-phone:1] VoiceMailMain("PJSIP/1000-0000006e", "") in new stack
       > 0x7f4bb80529f0 -- Strict RTP learning after remote address set to: 192.168.1.x:xxxx
    -- <PJSIP/1000-0000006e> Playing 'vm-login.ulaw' (language 'en')
       > 0x7f4bb80529f0 -- Strict RTP switching to RTP target address 192.168.1.x:xxxx as source
       > 0x7f4bb80529f0 -- Strict RTP learning complete - Locking on source address 192.168.1.x:xxxx
    -- <PJSIP/1000-0000006e> Playing 'vm-password.ulaw' (language 'en')
    -- Incorrect password '' for user '7045551234' (context = default)
    -- <PJSIP/1000-0000006e> Playing 'vm-incorrect-mailbox.ulaw' (language 'en')
[Aug 23 08:40:55] WARNING[234656][C-0000004d]: app_voicemail.c:11235 vm_authenticate: Couldn't read username

I think the “Incorrect password for user 7045551234” also indicates no DTMF detected because I believe DTMF would cause the number to change from the default to any detected DTMF–but that’s just my guess.

I also did some client-research. Here’s what I found going through my Linphone settings:

Settings --> Audio
Software echo cancellation - on
Adaptive rate control - on
bitrate limit 36 kbits/s

and a list of codecs:
opus 48kHz - on
speex 16kHz - off
speex 8kHz - off
PCMU 8kHz - on
PCMA 8kHz - on
GSM 8kHz - on
G722 8kHz - on
iLBC 8kHz - off
G729 8kHz - on
iSAC 16kHz - off
speex 32kHz - off
L16 44.1kHz - off
L16 44.1kHz - off

Settings --> Call
encryption - all off, set to none
Send out-band DTMFs (SIP INFO)
Send in-band DTMFs (RFC 2833)

With regards to the above 2 settings I have tried:
Send out-band DTMFs (SIP INFO) - off
Send in-band DTMFs (RFC 2833) - off

Send out-band DTMFs (SIP INFO) - off
Send in-band DTMFs (RFC 2833) - on

Send out-band DTMFs (SIP INFO) - on
Send in-band DTMFs (RFC 2833) - off

Send out-band DTMFs (SIP INFO) - on
Send in-band DTMFs (RFC 2833) - on

No DTMF messages and the following line each attempt:
WARNING[234688][C-00000051]: app_voicemail.c:11235 vm_authenticate: Couldn't read username

Thank you very much for your help!

Linphone has two dialers.

The main dialer.

The app dialer.

I was switching back to the main dialer. After receiving assistance from the Linphone mailing list I looked at the UI to access the app dialer after connecting to voicemail. Using the app dialer (not the main dialer) allowed me to successfully access my voicemail box.

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