[asterisk-users] e&m wink, TE110P, * answers too soon

[Sean Cook]

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