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