Steve Linabery
2006-Aug-09 09:49 UTC
[asterisk-users] e&m wink, TE110P, * answers too soon
Hi, I've been googling all over the place and have read the relevant articles in the Digium knowledge base. I have tried all the suggestions I found in the K.B. Spent some time on the asterisk irc, tweaking some parameters as people thereon thought would be helpful, but to no avail. I am trying to set up * on an e&m wink trunk currently attached to an Avaya Merlin Magix system. The provider of the T1 is McLeodUSA; our location is St Paul MN USA. I am in the process of getting more specific timing information from their tech support, but it takes days. I can call into the * PBX from my cell phone just fine. I can call between the two grandstream phones I bought for testing just fine. Here's the problem. When a call comes into *, * attempts to route it to an extension prematurely. For example, if the DTMF digits coming from upstream are '538', * tries to send the call to extn '53'. I still receive the '8', but too late. Here's a snip from /var/log/asterisk/messages where the incoming DID digits are '535': Aug 7 22:30:00 DEBUG[31492] chan_zap.c: Monitor doohicky got event Ring/Answered on channel 1 Aug 7 22:30:00 DEBUG[31478] devicestate.c: Changing state for Zap/1 - state 2 (In use) Aug 7 22:30:00 VERBOSE[31493] logger.c: Asterisk Ready. -- Starting simple switch on 'Zap/1-1' Aug 7 22:30:00 DEBUG[31494] app_queue.c: Device 'Zap/1' changed to state '2' (In use) but we don't care because they're not a member of any queue. Aug 7 22:30:01 DEBUG[31493] chan_zap.c: DTMF digit: 5 on Zap/1-1 Aug 7 22:30:01 DEBUG[31493] chan_zap.c: DTMF digit: 3 on Zap/1-1 Aug 7 22:30:01 DEBUG[31493] chan_zap.c: Enabled echo cancellation on channel 1 Aug 7 22:30:01 VERBOSE[31493] logger.c: == Unknown extension '53' in context 'demo' requested Aug 7 22:30:04 DEBUG[31493] channel.c: Set channel Zap/1-1 to write format gsm Aug 7 22:30:04 DEBUG[31493] channel.c: Scheduling timer at 160 sample intervals Aug 7 22:30:04 VERBOSE[31493] logger.c: -- Playing 'ss-noservice' (language 'en') Aug 7 22:30:04 DEBUG[31493] chan_zap.c: DTMF digit: 5 on Zap/1-1 Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Exception on 20, channel 1 Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Got event On hook(1) on channel 1 (index 0) Aug 7 22:30:07 DEBUG[31493] chan_zap.c: disabled echo cancellation on channel 1 Aug 7 22:30:07 DEBUG[31493] channel.c: Scheduling timer at 0 sample intervals Aug 7 22:30:07 DEBUG[31493] channel.c: Hanging up channel 'Zap/1-1' Aug 7 22:30:07 DEBUG[31493] chan_zap.c: zt_hangup(Zap/1-1) Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Hangup: channel: 1 index = 0, normal = 20, callwait = -1, thirdcall = -1 Aug 7 22:30:07 DEBUG[31493] chan_zap.c: disabled echo cancellation on channel 1 Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/1-1 Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Updated conferencing on 1, with 0 conference users Aug 7 22:30:07 VERBOSE[31493] logger.c: -- Hungup 'Zap/1-1' Aug 7 22:30:07 DEBUG[31478] devicestate.c: Changing state for Zap/1 - state 0 (Unknown) Aug 7 22:30:07 DEBUG[31495] app_queue.c: Device 'Zap/1' changed to state '0' (Unknown) but we don't care because they're not a member of any queue. Here are some settings from /etc/asterisk/zapata.conf: [trunkgroups] [channels] wink=300 rxwink=300 start=3000 context=default switchtype=national toneduration=100 usecallerid=no cidsignalling=dtmf hidecallerid=no callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=yes relaxdtmf=no rxgain=0.0 txgain=0.0 group=1 callgroup=1 pickupgroup=1 immediate=no callprogress=no switchtype = national context = demo signalling = em_w group = 1 channel => 1-20 It has occurred to me that I could just set immediate=yes, read the incoming DTMF digits into a variable, and route to the appropriate extension. That seems more fragile to me since we could someday (when I'm not here) start getting more than 3 digits (caller id, for example). Plus I'd like to make it work the way it's *supposed* to. Any help/suggestions are appreciated! Cheers, -- Steve Linabery B94B C3C7 8A27 FF09 3C9D E992 5A20 2492 D5F5 EE51 This electronic message transmission contains information from the sender's organization that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:"
Steve, I have the exact same problem with a sangoma a104d so I don't think it is related to the card. I am trying to figure that one out as well, fortunately I only have one DID on that trunk so I used _.* to route everything... Sorry this doesn't help other than to let you know that it probably isn't the card... Sean On 09-Aug-2006, Steve Linabery wrote:> Hi, > > I've been googling all over the place and have read the relevant articles in the Digium knowledge base. I have tried all the suggestions I found in the K.B. Spent some time on the asterisk irc, tweaking some parameters as people thereon thought would be helpful, but to no avail. > > I am trying to set up * on an e&m wink trunk currently attached to an Avaya Merlin Magix system. The provider of the T1 is McLeodUSA; our location is St Paul MN USA. I am in the process of getting more specific timing information from their tech support, but it takes days. > > I can call into the * PBX from my cell phone just fine. I can call between the two grandstream phones I bought for testing just fine. > > Here's the problem. When a call comes into *, * attempts to route it to an extension prematurely. For example, if the DTMF digits coming from upstream are '538', * tries to send the call to extn '53'. I still receive the '8', but too late. > > Here's a snip from /var/log/asterisk/messages where the incoming DID digits are '535': > Aug 7 22:30:00 DEBUG[31492] chan_zap.c: Monitor doohicky got event Ring/Answered on channel 1 > Aug 7 22:30:00 DEBUG[31478] devicestate.c: Changing state for Zap/1 - state 2 (In use) > Aug 7 22:30:00 VERBOSE[31493] logger.c: Asterisk Ready. > -- Starting simple switch on 'Zap/1-1' > Aug 7 22:30:00 DEBUG[31494] app_queue.c: Device 'Zap/1' changed to state '2' (In use) but we don't care because they're not a member of any queue. > Aug 7 22:30:01 DEBUG[31493] chan_zap.c: DTMF digit: 5 on Zap/1-1 > Aug 7 22:30:01 DEBUG[31493] chan_zap.c: DTMF digit: 3 on Zap/1-1 > Aug 7 22:30:01 DEBUG[31493] chan_zap.c: Enabled echo cancellation on channel 1 > Aug 7 22:30:01 VERBOSE[31493] logger.c: == Unknown extension '53' in context 'demo' requested > Aug 7 22:30:04 DEBUG[31493] channel.c: Set channel Zap/1-1 to write format gsm > Aug 7 22:30:04 DEBUG[31493] channel.c: Scheduling timer at 160 sample intervals > Aug 7 22:30:04 VERBOSE[31493] logger.c: -- Playing 'ss-noservice' (language 'en') > Aug 7 22:30:04 DEBUG[31493] chan_zap.c: DTMF digit: 5 on Zap/1-1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Exception on 20, channel 1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Got event On hook(1) on channel 1 (index 0) > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: disabled echo cancellation on channel 1 > Aug 7 22:30:07 DEBUG[31493] channel.c: Scheduling timer at 0 sample intervals > Aug 7 22:30:07 DEBUG[31493] channel.c: Hanging up channel 'Zap/1-1' > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: zt_hangup(Zap/1-1) > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Hangup: channel: 1 index = 0, normal = 20, callwait = -1, thirdcall = -1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: disabled echo cancellation on channel 1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/1-1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Updated conferencing on 1, with 0 conference users > Aug 7 22:30:07 VERBOSE[31493] logger.c: -- Hungup 'Zap/1-1' > Aug 7 22:30:07 DEBUG[31478] devicestate.c: Changing state for Zap/1 - state 0 (Unknown) > Aug 7 22:30:07 DEBUG[31495] app_queue.c: Device 'Zap/1' changed to state '0' (Unknown) but we don't care because they're not a member of any queue. > > > Here are some settings from /etc/asterisk/zapata.conf: > [trunkgroups] > [channels] > wink=300 > rxwink=300 > start=3000 > context=default > switchtype=national > toneduration=100 > usecallerid=no > cidsignalling=dtmf > hidecallerid=no > callwaiting=yes > usecallingpres=yes > callwaitingcallerid=yes > threewaycalling=yes > transfer=yes > canpark=yes > cancallforward=yes > callreturn=yes > echocancel=yes > echocancelwhenbridged=yes > relaxdtmf=no > rxgain=0.0 > txgain=0.0 > group=1 > callgroup=1 > pickupgroup=1 > immediate=no > callprogress=no > switchtype = national > context = demo > signalling = em_w > group = 1 > channel => 1-20 > > > It has occurred to me that I could just set immediate=yes, read the incoming DTMF digits into a variable, and route to the appropriate extension. That seems more fragile to me since we could someday (when I'm not here) start getting more than 3 digits (caller id, for example). Plus I'd like to make it work the way it's *supposed* to. > > Any help/suggestions are appreciated! > > Cheers, > -- > Steve Linabery > B94B C3C7 8A27 FF09 3C9D E992 5A20 2492 D5F5 EE51 > > > This electronic message transmission contains information from the sender's organization that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
Well you say too much and not enough about the problem or configuration So, I assume the DID's are on Ports 1 - 24 T1?. If asterisk is missing the first digit, then I'll bet the DID T1 from Telco is set to immediate on their side, not wink - Because dialing should NOT start until after the wink from asterisk - Try changing Telco T1 to immediate start and test. Bart Steve Linabery wrote:> Hi, > > I've been googling all over the place and have read the relevant articles in the Digium knowledge base. I have tried all the suggestions I found in the K.B. Spent some time on the asterisk irc, tweaking some parameters as people thereon thought would be helpful, but to no avail. > > I am trying to set up * on an e&m wink trunk currently attached to an Avaya Merlin Magix system. The provider of the T1 is McLeodUSA; our location is St Paul MN USA. I am in the process of getting more specific timing information from their tech support, but it takes days. > > I can call into the * PBX from my cell phone just fine. I can call between the two grandstream phones I bought for testing just fine. > > Here's the problem. When a call comes into *, * attempts to route it to an extension prematurely. For example, if the DTMF digits coming from upstream are '538', * tries to send the call to extn '53'. I still receive the '8', but too late. > > Here's a snip from /var/log/asterisk/messages where the incoming DID digits are '535': > Aug 7 22:30:00 DEBUG[31492] chan_zap.c: Monitor doohicky got event Ring/Answered on channel 1 > Aug 7 22:30:00 DEBUG[31478] devicestate.c: Changing state for Zap/1 - state 2 (In use) > Aug 7 22:30:00 VERBOSE[31493] logger.c: Asterisk Ready. > -- Starting simple switch on 'Zap/1-1' > Aug 7 22:30:00 DEBUG[31494] app_queue.c: Device 'Zap/1' changed to state '2' (In use) but we don't care because they're not a member of any queue. > Aug 7 22:30:01 DEBUG[31493] chan_zap.c: DTMF digit: 5 on Zap/1-1 > Aug 7 22:30:01 DEBUG[31493] chan_zap.c: DTMF digit: 3 on Zap/1-1 > Aug 7 22:30:01 DEBUG[31493] chan_zap.c: Enabled echo cancellation on channel 1 > Aug 7 22:30:01 VERBOSE[31493] logger.c: == Unknown extension '53' in context 'demo' requested > Aug 7 22:30:04 DEBUG[31493] channel.c: Set channel Zap/1-1 to write format gsm > Aug 7 22:30:04 DEBUG[31493] channel.c: Scheduling timer at 160 sample intervals > Aug 7 22:30:04 VERBOSE[31493] logger.c: -- Playing 'ss-noservice' (language 'en') > Aug 7 22:30:04 DEBUG[31493] chan_zap.c: DTMF digit: 5 on Zap/1-1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Exception on 20, channel 1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Got event On hook(1) on channel 1 (index 0) > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: disabled echo cancellation on channel 1 > Aug 7 22:30:07 DEBUG[31493] channel.c: Scheduling timer at 0 sample intervals > Aug 7 22:30:07 DEBUG[31493] channel.c: Hanging up channel 'Zap/1-1' > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: zt_hangup(Zap/1-1) > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Hangup: channel: 1 index = 0, normal = 20, callwait = -1, thirdcall = -1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: disabled echo cancellation on channel 1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/1-1 > Aug 7 22:30:07 DEBUG[31493] chan_zap.c: Updated conferencing on 1, with 0 conference users > Aug 7 22:30:07 VERBOSE[31493] logger.c: -- Hungup 'Zap/1-1' > Aug 7 22:30:07 DEBUG[31478] devicestate.c: Changing state for Zap/1 - state 0 (Unknown) > Aug 7 22:30:07 DEBUG[31495] app_queue.c: Device 'Zap/1' changed to state '0' (Unknown) but we don't care because they're not a member of any queue. > > > Here are some settings from /etc/asterisk/zapata.conf: > [trunkgroups] > [channels] > wink=300 > rxwink=300 > start=3000 > context=default > switchtype=national > toneduration=100 > usecallerid=no > cidsignalling=dtmf > hidecallerid=no > callwaiting=yes > usecallingpres=yes > callwaitingcallerid=yes > threewaycalling=yes > transfer=yes > canpark=yes > cancallforward=yes > callreturn=yes > echocancel=yes > echocancelwhenbridged=yes > relaxdtmf=no > rxgain=0.0 > txgain=0.0 > group=1 > callgroup=1 > pickupgroup=1 > immediate=no > callprogress=no > switchtype = national > context = demo > signalling = em_w > group = 1 > channel => 1-20 > > > It has occurred to me that I could just set immediate=yes, read the incoming DTMF digits into a variable, and route to the appropriate extension. That seems more fragile to me since we could someday (when I'm not here) start getting more than 3 digits (caller id, for example). Plus I'd like to make it work the way it's *supposed* to. > > Any help/suggestions are appreciated! > > Cheers, >