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

[Bart Fisher]

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