dtmf issues with vms and ivrs

Discussion in 'General' started by jgibson, May 5, 2009.

  1. jgibson

    Joined:
    Dec 29, 2008
    Messages:
    78
    Likes Received:
    0
    When I am using my polycom phone over my sip trunks I am only able to either access my elastix voice mail or my cell voice mail, not both at the same time.

    If I use rfc2833, inband or auto I am able to dial my elastix voice mail from my polycom phone. The only way I am able to get my cell vm or another companies IVR to respond to the tones is if I have info set for my dtmfmode.

    My question is what do I have to do to be able to have everything respond to my dtmf?

    Thank you,

    Jason
     
  2. agibson79

    Joined:
    May 6, 2009
    Messages:
    3
    Likes Received:
    0
    Same issue here.

    Using elastix 1.3-2 on Asterisk 1.4.22?
    Did this problem just start happening out of the blue? (worked initially)

    I attempted to duplicate this problem on a cloned box (same elastix, asterisk, configs, extensions, phones etc) and everything works fine both internal and over the sip trunk using rfc2833!!

    Here's my situation: We installed a PBX appliance with the above configuration using sip trunk and rfc2833 set to the extensions, phonsets (Aastra 5755i) set to force DTMF out-of-band. Everything worked perfectly satisfying internal VM access as well as DTMF recognition over the SIP trunk. 2 weeks later we received reports that phones were locking up when pressing DTMF digits on outbound calls over the SIP trunk. This locking problem went away *on its own* but DTMF over the SIP trunk has not worked right since. Now that I have the same config and phones loaded onto another box without any DTMF issues, I am beginning to think that this may be a bug within asterisk that is prone to occur over time.

    Check out http://bugs.digium.com/view.php?id=13209 and see what you think. I have not applied this patch myself, as it supposedly addresses asterisk 1.4.21.2 but there are users reporting the same bug with 1.4.22 in the bug report. Of note is that the patch updates rtp.c to revision 162204. 1.4.22 uses 136062.

    Cheers,
    Andy
     
  3. jgibson

    Joined:
    Dec 29, 2008
    Messages:
    78
    Likes Received:
    0
    Yes I am running Elastix 1.3-2 on Asterisk 1.4.22-rc5, and its sip all the way to my provider.

    I believe that this problem has been happening the whole time. When I first installed the system, which was a couple months ago now, we just needed to be able to access other peoples IVRs. To do that we had to change the dtmfmode to be info. That is the only setting that allows us right now to have other systems recognize that we are sending digits to them. However if I go and Dial my vm from my phone with dtmfmode=info it does not work, but I'm just repeating myself.

    I'm not to sure about using that patch if it is for a different version. I am getting close to having the system where I want it and I don't want to risk breaking it, even though I have thought of tossing it out a window.:)

    Does anyone know how to get Elastix to accept info for the dtmfmode. Is that even what I should be looking to do or should I be taking another route. I've been searching a lot of forums about dtmf and there doesn't seem to be a lot to it yet it is giving me a huge headache.

    Thanks
    Jason
     
  4. jgibson

    Joined:
    Dec 29, 2008
    Messages:
    78
    Likes Received:
    0
    Also which take priority in this situation. There is the dtmfmode box for each extension. I've read that you can also have dtmfmode=info, or whatever, in the user and peer details. Which one take control?
     
  5. agibson79

    Joined:
    May 6, 2009
    Messages:
    3
    Likes Received:
    0
    Hi Jason,

    I just fixed this problem yesterday.

    In my scenario, dtmfmode is set to rfc2833 for extensions and trunk. I can only get internal DTMF recognition with this setting when I set the phoneset (Aastra 55i) to "force rfc2833 out-of-band", OR if I set the extension to inband and disable "force rfc2833 out-of-band", but this setting breaks dtmf over our sip trunk, which only supports G.711u. As I stated previously, rfc2833 for extension, trunk and "force out-of-band" on the phones worked initially for internal and trunk DTMF without issues... it simply broke over time.

    It turns out that the on-demand call recording that was enabled to use the trunk was the cause of the whole issue. In General Settings, we had "trW" configured for "Asterisk Outbound Dial command options:". This setting causes Asterisk to listen in on the call for DTMF tones, which asterisk will detect and rebuild the DTMF tones on that call. Once we removed the "W", DTMF worked perfectly as it should over the trunk. If you have "W" configured in your outbound dial command options, try disabling it.

    Otherwise, I would check with your SIP provider to determine which codecs are supported, as this will impact which DTMF method to use over your trunk. Also check for a force dtmf out-of-band setting on whichever phonesets you are using and test it on and off (if applicable) with the extension set to rfc2833.

    You can also test forcing Asterisk to use a particular dtmf mode for internal processes separate from your extension and trunk settings. For example, by adding "exten => *97,1,SIPDtmfMode(info)" to sip.conf, forces *97 (personal VM) to use that method when dialed (other options are inband, rfc2833, auto). You can try playing with those settings, although I didn't seem to make a difference in my particular case.

    To make SIP INFO work for DTMF, the setting must be supported by your SIP provider. You will also have to match the setting for your extensions and phonesets to use info for DTMF. I have not tested this as my provider only supports out-of-band dtmf.

    Hope this helps.
    Andy
     
  6. agibson79

    Joined:
    May 6, 2009
    Messages:
    3
    Likes Received:
    0
    Your peer settings applies whenever a call is made using that particular trunk, otherwise the extension setting applies. In testing I have noticed that the extension overrides the trunk by overlapping different DTMF methods, ie if the extension is set to inband and the trunk set to dtmfmode=rfc2833, rtp debugging revealed both in-band and out-of-band methods were trying to go over the trunk (and failed miserably). Preferably you should match the extension to the same as your trunk, but again this may only apply to my situation which requires rfc2833 by my sip provider. Also, I could not get rfc2833 for the extensions to work for internal processes without enabling the "force rfc2833 out-of-band" on each phoneset.

    Cheers,
    Andy
     
  7. jgibson

    Joined:
    Dec 29, 2008
    Messages:
    78
    Likes Received:
    0
    I was able to get this to work. My provider had over looked a setting that was not allow them to pass out of band dtmf. Now that I am able to pass out of band everything is working fine.

    Thanks for your help.
    Jason
     

Share This Page