DMTF Mode

Home » Asterisk Users » DMTF Mode
Asterisk Users 41 Comments

Hi,

Which DTMF mode do people mostly use?

I’ve tried SIP INFO and RFC2833 but although Asterisk recognises the tones (for feature usage), the tones arent repeated to the end user.
So if I call a company that has a menu system, I can’t use the menu.

Thanks
Dan

41 thoughts on - DMTF Mode

  • It depends upon whether you are receiving DTMF or sending, and whether you
    are using a VoIP protocol or using DAHDI/Zaptel.

    Could you explain a bit what type of setup you have?

    Zeeshan A Zakaria

  • Sorry about the lack of info.

    It’s a simple SIP only setup. A handful of sip phones, an asterisk server, and a sip provider.

    The DTMF signals from the sip phones are received by Asterisk because they can access features like *1.

    The DTMF signal from the called party are received by Asterisk because they can also access features like *1.

    But, the DTMF tones are not passed through from the Sip Phone to the Called Party.

    The same happens regardless of whether its an incoming or outgoing call.

    That means, if any of my users try to call a company with a menu system, they can’t select any options.

    How can I tell if Asterisk is sending the tones through to the provider? I need to find out whether its something I’m doing, or something the provider is doing.

    Any ideas?

    Thanks

    Dan

  • I just tried this:-

    [test_calls]
    exten => 555,1,Answer()
    exten => 555,n,SendDTMF(12345)
    exten => 555,n,Playback(beep)

    I dialed 555 on the sip phone, nothing was heard, and then a beep…

    It seems that Asterisk isn’t sending DTMF. Its only able to receive.

    Thanks
    Dan

  • Then that likely means your phone have the correct dtmfmode, but the link
    between you and the provider doesn’t.

    Make sure both you and the provider are using the same dtmfmode. My
    experience shows that sometimes it’s also between your provider and THEIR
    provider, and sometimes reporting the issue to them helps.

    But of course, verify on your side first.

    Mike

    href=”mailto:asterisk-users-bounces@lists.digium.com”>asterisk-users-bounces@lists.digium.com
    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Dan Journo
    Sent: Wednesday, October 13, 2010 10:12 AM

    are using a VoIP protocol or using DAHDI/Zaptel.

    Sorry about the lack of info.

    It’s a simple SIP only setup. A handful of sip phones, an asterisk server,
    and a sip provider.

    The DTMF signals from the sip phones are received by Asterisk because they
    can access features like *1.

    The DTMF signal from the called party are received by Asterisk because they
    can also access features like *1.

    But, the DTMF tones are not passed through from the Sip Phone to the Called
    Party.

    The same happens regardless of whether its an incoming or outgoing call.

    That means, if any of my users try to call a company with a menu system,
    they can’t select any options.

    How can I tell if Asterisk is sending the tones through to the provider? I
    need to find out whether its something I’m doing, or something the provider
    is doing.

    Any ideas?

    Thanks

    Dan

  • Can you send us the SIP config of the sip provider (in sip.conf), removing
    appropriate passwords and static IPs of course.

    Mike

    href=”mailto:asterisk-users-bounces@lists.digium.com”>asterisk-users-bounces@lists.digium.com
    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Dan Journo
    Sent: Wednesday, October 13, 2010 10:22 AM

    I just tried this:-

    [test_calls]

    exten => 555,1,Answer()

    exten => 555,n,SendDTMF(12345)

    exten => 555,n,Playback(beep)

    I dialed 555 on the sip phone, nothing was heard, and then a beep…

    It seems that Asterisk isn’t sending DTMF. Its only able to receive.

    Thanks

    Dan

  • Just carried out another test to see if my provider was working properly:-

    exten => INCOMINGDDI,1,Wait(1)
    exten => INCOMINGDDI,n,Answer()
    exten => INCOMINGDDI,n,SendDTMF(12345)

    If I dial the incoming number from a normal phone. The DDI comes from my provider.
    When the calls is answered by asterisk, the tones are played and I can hear them.
    So it doesnt seem to be a problem with the connection to my provider.

  • [provider]
    type=friend
    host=removed
    username=removed
    fromuser=removed
    secret=password
    context=incoming_calls
    dtmfmode=rfc2833 < also tried "auto".
    disallow=all
    allow=gsm
    allow=ulaw
    insecure=invite
    canreinvite=no

    The provider has confirmed that they support rfc2833 or inband with the right codecs.

  • * The provider has confirmed that they support rfc2833 or inband with
    the right codecs.

    Are you using the .gsm codec or some other flavor (ulaw, alaw, G729?)

  • This is from the sip.conf for the provider:
    allow=gsm
    allow=ulaw

    This is from the sip extension:-
    alaw,ulaw,gsm

  • I would suggest first to make sure that asterisk is receiving DTMF fine from
    your IP devices/phones. Do you have a test IVR where you can dial and press
    digits and verify that asterisk is responding?

    Once you are sure that asterisk is receiving DTMF fine, then you should ask
    your provider what DTMF setting you should have on your system. Usually all
    of them support RFC2833, so if in your sip.conf where you have defined the
    trunk, dtmfmode is set to rfc2833, your provider should receive it and pass
    on to the next carrier or trunk.

    Zeeshan A Zakaria

  • _____

    href=”mailto:asterisk-users-bounces@lists.digium.com”>asterisk-users-bounces@lists.digium.com
    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Dan Journo
    Sent: Wednesday, October 13, 2010 9:38 AM

    This is from the sip.conf for the provider:

    allow=gsm

    allow=ulaw

    This is from the sip extension:-

    alaw,ulaw,gsm

    Based on this, your call is probably getting to the provider as ulaw (the
    alaw is thrown out since it isn’t in both selections; if you are in U.S. you
    don’t need the alaw). Try the call with higher debug (at least 5) and
    verify which one is being selected.

  • Made a quick IVR, and its working for both sides of the asterisk (between the provider and asterisk, and between the sip phones and asterisk).

    I think its an issue with DTMF Pass-through. Is there a way to disable DMTF passthrough? Maybe asterisk is blocking the signals from being repeated to the other party?

  • debug 5 doesnt give me any info regarding the codec.

    By the way, i’m using asterisk 1.4.36 if that makes any difference.

    Thanks
    Dan

  • On Wed, Oct 13, 2010 at 10:12 AM, Dan Journo
    wrote:
    You need to enable DTMF logging (logger.conf) and debug an incoming /
    outgoing call. However, if your DTMF works locally, with asterisk and
    SIP phones, but does not with your provider. Then I would suspect the
    issue is with your ITSP, make sure your provider is not converting
    out-of-band tones to inband, or something like that.

  • outgoing call.

    Can you understand this? I can see the DTMF signals coming in. I pressed 5 on the normal phone line, and then I pressed 8 on the sip phone.
    The call is outgoing from the sip phone (through the provider) to a normal land line phone.

    http://pastebin.com/UNs177LW

  • Not used. So default 1000ms.

    I just added alaw to the provider’s list, so now it reads (gsm, ulaw, alaw) and its started working in a fashion.

    The DTMF tones keep “getting stuck”. I press a number on the sip phone, and the other party hears a tone. But every few tones, it gets stuck and they hear a long tone of about 3 seconds and then it goes off.

    Any idea whats happening there?

    Thanks
    Dan

  • Here’s the debug log for two DTMF tones. The first was fine. The second got stuck.

    [2010-10-13 16:25:16] DEBUG[3287]: rtp.c:738 process_rfc2833: – RTP 2833 Event: 00000005 (len = 4)
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2129 ast_rtp_change_source: Changing ssrc from 775511001 to 1841818300 due to a source change
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2129 ast_rtp_change_source: Changing ssrc from 381691761 to 1746631866 due to a source change
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:940 ast_rtcp_read: Got RTCP report of 72 bytes
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:738 process_rfc2833: – RTP 2833 Event: 00000005 (len = 4)
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:635 create_dtmf_frame: Sending dtmf: 53 (5), at 91.110.53.170
    [2010-10-13 16:25:16] DEBUG[18139]: channel.c:4565 ast_generic_bridge: Got DTMF begin on channel (SIP/kesher_201-00000381)
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2117 ast_rtp_new_source: Setting the marker bit due to a source update
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2117 ast_rtp_new_source: Setting the marker bit due to a source update

    [2010-10-13 16:25:16] DEBUG[18139]: channel.c:4882 ast_channel_bridge: Bridge stops bridging channels SIP/kesher_201-00000381 and SIP/magrathea-00000382
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2129 ast_rtp_change_source: Changing ssrc from 1841818300 to 455288846 due to a source change
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2129 ast_rtp_change_source: Changing ssrc from 1746631866 to 340402601 due to a source change
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:738 process_rfc2833: – RTP 2833 Event: 00000005 (len = 4)
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:738 process_rfc2833: – RTP 2833 Event: 00000005 (len = 4)
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:738 process_rfc2833: – RTP 2833 Event: 00000005 (len = 4)
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:635 create_dtmf_frame: Sending dtmf: 53 (5), at 91.110.53.170
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:738 process_rfc2833: – RTP 2833 Event: 00000005 (len = 4)
    [2010-10-13 16:25:16] DEBUG[18139]: channel.c:4565 ast_generic_bridge: Got DTMF end on channel (SIP/kesher_201-00000381)
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2117 ast_rtp_new_source: Setting the marker bit due to a source update
    [2010-10-13 16:25:16] DEBUG[18139]: rtp.c:2117 ast_rtp_new_source: Setting the marker bit due to a source update

  • Dan Journo wrote:

    I would suggest log dtmf in your logger.conf and put rtp debug on and
    see if its sending dtmf. Also call the provider and see if they hear
    the tones.

  • other party is not in U.S.

    I dont understand why the codec should make a difference if im using rfc2833.

    Could you clear that up for me?

  • other party is not in U.S.

    Its stopped working again. This is really unusual. I didnt change anything.
    I decided to do a tcpdump, and I can clearly see the rfc2833 packets being exchanged correctly.

    Why should both parties not be able to hear the tones?

  • Hi All,

    Regarding the DTMF issue I reported where the tones werent being sent through the provider to the pstn phones,
    I ended up being told to switch to “inband”.

    However, now, asterisk is not recognising my features (*1, etc).

    Any ideas?

    I’ve checked using tcpdump, and asterisk is still part of the media path.

    Thanks
    Dan

  • I’m really struggling with this DTMF issue.

    In order to test it, I’ve tried a few different providers and DTMF RFC2833 does work with any of them, even though a few of them insist that it is.

    Is this a bug with 1.4.36?
    Has anyone else experienced this problem?

    The Asterisk CLI is showing the DTMF signals properly, the tones just don’t get repeated to the opposite end of the call properly.

    Any help would be greatly appreciated!
    Thanks
    Dan

  • Well, I connected my sip phone directly to the provider and totally skipped the asterisk server.
    DTMF rfc2833 worked fine!

    Looks like Asterisk is doing something that’s preventing it from working.
    However, looking at the tcpdump from asterisk, it all looks fine.

    Any ideas?
    Thanks
    Dan

  • Dan,

    I have to say, with 1.6.2.13 I am having the same or similar problems.
    I switched the affected customers to inband, haven’t had time
    to delve too deep into the problem.

    what I did see though, is that rfc2833 are indeed being sent, but
    not recognized by two of the sip providers we use.

    Ron

    Op 17-10-10 17:20, Dan Journo schreef:
    href=”mailto:asterisk-users-bounces@lists.digium.com”>asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Dan Journo

  • have been some update to RFC2833 over the last few months.

    In 1.4.36, its a regression issue. I switched to 1.4.35 and no problems since.
    Can anyone else confirm this for me?

    Problems are either no dtmf tones being processed by the provider. Or dtmf tones getting “stuck” and playing for 3 to 5 seconds before timing out.

    I’ve looked at the tcpdump logs for both, and don’t know enough to see where the problem could be.

    Thanks
    Dan