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, >