Elastix with BT Featureline Commands

Discussion in 'General' started by stirlingit, Nov 24, 2010.

  1. stirlingit

    Joined:
    Nov 24, 2010
    Messages:
    2
    Likes Received:
    0
    Hello,

    I am moving our phone system to Elastix and have got pretty much everything hammered down apart from the ability for Elastix to send BT featureline codes. e.g. #21# to cancel call divert, etc.

    Every time I use the # key it just drops to call ended.

    I am using a Wildcard TDM400P with 2 FXO and 2 FXS modules and have two BT featurelines plugged into the FXOs.

    Outgoing and incoming calls are all fine, just immediate call end when using the # key.

    Thanks in advance.

    Stu
     
  2. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    In "General Settings" -> "dialing options" you will note that t and T intercept the line when a # is detected, the call is not terminated but dial-tone is returned so you can transfer the call, eliminAte any t's in the dialing command as appropriate.
     
  3. stirlingit

    Joined:
    Nov 24, 2010
    Messages:
    2
    Likes Received:
    0
    Hello,

    The dialing options did have "tr" in the general settings.

    Have removed the "t" then the "r" still get "call ended" once I press the hash key.

    Anywhere else I have to look for "t"s?
     
  4. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    you might want to try disabling

    ## In-Call Asterisk Blind Transfer

    on the feature codes page, but that would generally indicate the old double dtmf bug, make sure you are using the right dtmfmode , G711 (dahdi trunks) can only use inband

    add dtmf notices to the admin account in manager.conf:-

    read = dtmf,system,call,log,verbose,command,agent,user

    and tail -f /var/log/asterisk/full as you dial the code.

    always restart asterisk and dahdi when doing this sort of stuff, "just in case"
     
  5. franklin

    Joined:
    Oct 22, 2010
    Messages:
    254
    Likes Received:
    0
    Hi dicko. Having an issue with DTMF. Here is my scenario. I have three boxes. Two behind a firewall with the standard port forwards and sip_nat.conf set properly. One is in the DMZ for testing purposes only. The DMZ box will pass DTMF to a specific 877#'s IVR. The two boxes behind their individual firewalls will not. All boxes running 1.6. All with latest yum updates. All are virtually identical loads. All talk on the same SIP trunk. All use rfc2833 and from-internal in the ext. I've run tail -f /var/log/asterisk/full and when I press the digits when the call is connected there is no output on the tail, on the "good" call or the "bad."

    I've tried putting rfc2388=compensate in sip_general_custom, as suggested by someone else here. I even tried it in sip_nat.conf. No luck. Any ideas?

    My provider says that on the good call they are seeing an immediate connection. on the bad call there is some kind of ringback. We even tried spoofing and using the outbound CID of the good pbx on the outbound CID of the bad, and the bad was still bad, with the ringback.

    Thanks very much.
     
  6. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    If you added the DTMF to the logger conf file (and restarted it)

    then


    tail -f /var/log/asterisk/full|grep DTMF

    "should" give you something like the following:-



    [2010-12-22 16:09:08] DTMF[14224] channel.c: DTMF end passthrough '7' on SIP/3457-00007a8e
    [2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF begin '8' received on SIP/3457-00007a8e
    [2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF begin passthrough '8' on SIP/3457-00007a8e
    [2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF end '8' received on SIP/3457-00007a8e, duration 150 ms
    [2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF end accepted with begin '8' on SIP/3457-00007a8e
    [2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF end passthrough '8' on SIP/3457-00007a8e
    [2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF begin '9' received on SIP/3457-00007a8e
    [2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF begin passthrough '9' on SIP/3457-00007a8e
    [2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF end '9' received on SIP/3457-00007a8e, duration 140 ms
    [2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF end accepted with begin '9' on SIP/3457-00007a8e
    [2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF end passthrough '9' on SIP/3457-00007a8e
    [2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF begin '*' received on SIP/3457-00007a8e
    [2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF begin passthrough '*' on SIP/3457-00007a8e
    [2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF end '*' received on SIP/3457-00007a8e, duration 150 ms
    [2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF end accepted with begin '*' on SIP/3457-00007a8e
    [2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF end passthrough '*' on SIP/3457-00007a8e
    [2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF begin '0' received on SIP/3457-00007a8e
    [2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF begin passthrough '0' on SIP/3457-00007a8e
    [2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF end '0' received on SIP/3457-00007a8e, duration 180 ms
    [2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF end accepted with begin '0' on SIP/3457-00007a8e
    [2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF end passthrough '0' on SIP/3457-00007a8e
    [2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF begin '#' received on SIP/3457-00007a8e
    [2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF begin passthrough '#' on SIP/3457-00007a8e
    [2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF end '#' received on SIP/3457-00007a8e, duration 160 ms
    [2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF end accepted with begin '#' on SIP/3457-00007a8e
    [2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF end passthrough '#' on SIP/3457-00007a8e


    as you press each button (you will hear the dtmf on the far end (with usually a delay for * and # as incall signaling is processed and thus delayed.

    the nature of the logged output will vary as you change between the various dtmfmode's , but there should always be a trace

    diagnostically, inbound calls to your system (IVR navigation voicemail etc.) should also show the dtmf events.

    Once you get the logger to behave, perhaps it will become apparent either, it's just not there, or it's being misinterpreted. The LandBased Telco's VERY rarely need any modificatioon of how DTMF works, sometimes the VSP's just need a good kick in the arse.
     
  7. franklin

    Joined:
    Oct 22, 2010
    Messages:
    254
    Likes Received:
    0
  8. franklin

    Joined:
    Oct 22, 2010
    Messages:
    254
    Likes Received:
    0
    dicko, please take a look at the output of my tail. You'll notice about 13 lines down I get a pesky "begin ignored" return, and then "emulation." Is this my box telling me it got no acknowledgment from the other side? Why does it do this? My other identical 1.6 box does not get this, as evidenced by the same output labeled "begin good call." I expect to hear back from my VSP, who has a ticket open with the carrier, tomorrow. But if you could throw any of your thoughts out I would be grateful. Thanks.


    Begin bad call
    Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin '6' received on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin passthrough '6' on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end '6' received on SIP/2001-00000292, duration 250 ms
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end accepted with begin '6' on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end passthrough '6' on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin '0' received on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin passthrough '0' on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end '0' received on SIP/2001-00000292, duration 260 ms
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end accepted with begin '0' on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end passthrough '0' on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[4315] channel.c: DTMF begin '0' received on SIP/2001-00000292
    [Dec 22 22:16:09] DTMF[4315] channel.c: DTMF begin ignored '0' on SIP/2001-00000292
    [Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end '0' received on SIP/2001-00000292, duration 260 ms
    [Dec 22 22:16:10] DTMF[31906] channel.c: DTMF begin emulation of '0' with duration 260 queued on SIP/2001-00000292
    [Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end emulation of '0' queued on SIP/2001-00000292
    [Dec 22 22:16:10] DTMF[4315] channel.c: DTMF begin '5' received on SIP/2001-00000292
    [Dec 22 22:16:10] DTMF[4315] channel.c: DTMF begin ignored '5' on SIP/2001-00000292
    [Dec 22 22:16:10] DTMF[4315] channel.c: DTMF end '5' received on SIP/2001-00000292, duration 260 ms
    [Dec 22 22:16:10] DTMF[4315] channel.c: DTMF end passthrough '5' on SIP/2001-00000292
    [Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end '5' received on SIP/2001-00000292, duration 260 ms
    [Dec 22 22:16:10] DTMF[31906] channel.c: DTMF begin emulation of '5' with duration 260 queued on SIP/2001-00000292
    [Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end emulation of '5' queued on SIP/2001-00000292
    [Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin '4' received on SIP/2001-00000292
    [Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin ignored '4' on SIP/2001-00000292
    [Dec 22 22:16:11] DTMF[31906] channel.c: DTMF end '4' received on SIP/2001-00000292, duration 300 ms
    [Dec 22 22:16:11] DTMF[31906] channel.c: DTMF begin emulation of '4' with duration 300 queued on SIP/2001-00000292
    [Dec 22 22:16:11] DTMF[31906] channel.c: DTMF end emulation of '4' queued on SIP/2001-00000292
    [Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin '5' received on SIP/2001-00000292
    [Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin ignored '5' on SIP/2001-00000292
    [Dec 22 22:16:11] DTMF[31906] channel.c: DTMF end '5' received on SIP/2001-00000292, duration 310 ms
    [Dec 22 22:16:11] DTMF[31906] channel.c: DTMF begin emulation of '5' with duration 310 queued on SIP/2001-00000292
    [Dec 22 22:16:12] DTMF[31906] channel.c: DTMF end emulation of '5' queued on SIP/2001-00000292
    [Dec 22 22:16:12] DTMF[4315] channel.c: DTMF begin '#' received on SIP/2001-00000292
    [Dec 22 22:16:12] DTMF[4315] channel.c: DTMF begin ignored '#' on SIP/2001-00000292
    [Dec 22 22:16:12] DTMF[31906] channel.c: DTMF end '#' received on SIP/2001-00000292, duration 330 ms
    [Dec 22 22:16:12] DTMF[31906] channel.c: DTMF begin emulation of '#' with duration 330 queued on SIP/2001-00000292
    [Dec 22 22:16:13] DTMF[31906] channel.c: DTMF end emulation of '#' queued on SIP/2001-00000292

    Begin good call

    tail -f /var/log/asterisk/full|grep DTMF
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin '6' received on SIP/2003-00000063
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin passthrough '6' on SIP/2003-00000063
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end '6' received on SIP/2003-00000063, duration 240 ms
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end accepted with begin '6' on SIP/2003-00000063
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end passthrough '6' on SIP/2003-00000063
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin '0' received on SIP/2003-00000063
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin passthrough '0' on SIP/2003-00000063
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end '0' received on SIP/2003-00000063, duration 290 ms
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end accepted with begin '0' on SIP/2003-00000063
    [Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end passthrough '0' on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin '0' received on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin passthrough '0' on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end '0' received on SIP/2003-00000063, duration 270 ms
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end accepted with begin '0' on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end passthrough '0' on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin '0' received on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin passthrough '0' on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end '0' received on SIP/2003-00000063, duration 280 ms
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end accepted with begin '0' on SIP/2003-00000063
    [Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end passthrough '0' on SIP/2003-00000063
    [Dec 22 22:14:06] DTMF[19631] channel.c: DTMF begin '5' received on SIP/2003-00000063
    [Dec 22 22:14:06] DTMF[19631] channel.c: DTMF begin passthrough '5' on SIP/2003-00000063
    [Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end '5' received on SIP/2003-00000063, duration 260 ms
    [Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end accepted with begin '5' on SIP/2003-00000063
    [Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end passthrough '5' on SIP/2003-00000063
    [Dec 22 22:14:06] DTMF[6869] channel.c: DTMF begin '4' received on SIP/2003-00000063
    [Dec 22 22:14:06] DTMF[6869] channel.c: DTMF begin ignored '4' on SIP/2003-00000063
    [Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end '4' received on SIP/2003-00000063, duration 250 ms
    [Dec 22 22:14:06] DTMF[19631] channel.c: DTMF begin emulation of '4' with duration 250 queued on SIP/2003-00000063
    [Dec 22 22:14:07] DTMF[19631] channel.c: DTMF begin '5' received on SIP/2003-00000063
    [Dec 22 22:14:07] DTMF[19631] channel.c: DTMF begin ignored '5' on SIP/2003-00000063
    [Dec 22 22:14:07] DTMF[19631] channel.c: DTMF end emulation of '4' queued on SIP/2003-00000063
    [Dec 22 22:14:07] DTMF[19631] channel.c: DTMF end '5' received on SIP/2003-00000063, duration 320 ms
    [Dec 22 22:14:07] DTMF[19631] channel.c: DTMF begin emulation of '5' with duration 320 queued on SIP/2003-00000063
    [Dec 22 22:14:07] DTMF[19631] channel.c: DTMF end emulation of '5' queued on SIP/2003-00000063
    [Dec 22 22:14:08] DTMF[19631] channel.c: DTMF begin '#' received on SIP/2003-00000063
    [Dec 22 22:14:08] DTMF[19631] channel.c: DTMF begin passthrough '#' on SIP/2003-00000063
    [Dec 22 22:14:08] DTMF[19631] channel.c: DTMF end '#' received on SIP/2003-00000063, duration 300 ms
    [Dec 22 22:14:08] DTMF[19631] channel.c: DTMF end accepted with begin '#' on SIP/2003-00000063
    [Dec 22 22:14:08] DTMF[19631] channel.c: DTMF end passthrough '#' on SIP/2003-00000063
     
  9. franklin

    Joined:
    Oct 22, 2010
    Messages:
    254
    Likes Received:
    0
    found it in etc/asterisk. Please disregard. But it you have any ideas on why the ignore...?
     
  10. franklin

    Joined:
    Oct 22, 2010
    Messages:
    254
    Likes Received:
    0
    This is solved. I started by telling my XLite to send only in-band. It worked. Then I figured that I could do the same with my Polycom phones. in the admin guide 322 you find some parameters for dtmf. One of them:
    tone.dtmf.rfc2833Control 0 or 1 1 If set to 1, the phone will indicate a
    preference for encoding DTMF through
    RFC 2833 format in its Session
    Description Protocol (SDP) offers by
    showing support for the phone-event
    payload type; this does not affect SDP
    answers, these will always honor the
    DTMF format present in the offer since
    the phone has native support for RFC
    2833.

    I set it to 0. Long conversation with my carrier. They all have settings for DTMF. Long story short, this is the only thing that worked in my scenario with my Polycom phones.

    Thanks for any help given. Merry Christmas, dicko!
     
  11. franklin

    Joined:
    Oct 22, 2010
    Messages:
    254
    Likes Received:
    0
    dicko, I'm at a wall. When I set tone.dtmf.rfc2833Control to 0 in my Polycom sip.cfg, access to the IVR works. I have tone.dtmf.viaRtp set to 1, so I am sending the dtmf in the rtp stream.

    But this disables the *1 call record toggle. It simply won't work any longer. I've tried all the dtmfmodes in my ext. Set it to auto, info, and rfc2833. Here is a log, if is comes out formatted properly:

    sip.cfg= mask 0, viartp 1, rfc2833ctrl 0
    866# *1 call toggle
    info y n
    auto n y but *1 starts a new recording every time/cannot start/stop
    rfc2833 y n

    sip.cfg= mask 0, viartp 0, rfc2833crtl 0
    info n n
    auto n n
    rfc2833 n n

    0 1 1
    info y n
    auto n y but *1 starts a new recording every time
    rfc2833 n y but *1 starts a new recording every time

    1 0 1
    info n n
    auto n n
    rfc2833 n n
     
  12. franklin

    Joined:
    Oct 22, 2010
    Messages:
    254
    Likes Received:
    0
    Dear users, If you are having trouble with dtmf issues, I believe I have earned a graduate degree in the study. Perhaps not a master's or phd, but if you read my posts you will find my trials and tribulations. In the end, it was EWT that saved me, thank you to you know who for the default direction -- RTFM. The answer came from B.1.4 GoTalk. I just kept trying shit till it worked. Still strange one 1.6 box works without this in the Trunk and the other requires it...


    Setting tone.dtmf.rfc2833Control="0" certainly made the remote IVR respond. But it made my IVR on my Elastix box stop responding. I could no longer dial directly into 5000 for my conference bridge. So what I did is set my extensions to rfc2833, and included dtmfmode=inband in my SIP trunk. All works, and I am going to sleep.
     

Share This Page