[Home]

Summary:ASTERISK-03683: chan_zap does not wait for wink on E&M Wink lines
Reporter:km (km)Labels:
Date Opened:2005-03-15 10:03:59.000-0600Date Closed:2011-06-07 14:05:28
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:E&M Wink support is incomplete in chan_zap.

When making a telephone call out on a T1 configured as E&M wink, Asterisk will not wait for a wink.  The call always stays in the "Ringing" state and never goes "Up."  Because of this, SIP users cannot use the system because their calls never get out of "Session Progress" mode.

****** ADDITIONAL INFORMATION ******

The setup:    Asterisk is an intermediate leg between the telephone company (XO) and our existing NEC Electra Elite 48 system.

The problem is that when Asterisk originates a call on either the CO side or the NEC side, it will not wink or wait for wink.  The CO and NEC system both wink the Asterisk system properly, however.  The only effect of this is that the asterisk system always thinks that the line is Ringing, it never gets to the "Up" stage, when it originates the call.  The incoming calls from the CO and the NEC system are answered and go to "Up" immediately, never staying in the Ringing stage for longer than it took the call to actually ring through.

As you can see in zapata.conf, I was attempting to fiddle with prewink/preflash/wink/flash times, but I don't really know how I should set those variables so they're commented out at the moment.   The reason why I have zapata.conf going to 12-24  and 36-48 is because we have an integrated access t1, so the first few lines are data lines that are transferred off to the cisco router before it hits the pbx.  Those channels are just dead air, as far as I know.

Listed below are logs I took with some added printk's in zaptel.c relating to how the call progress goes from the CO to asterisk, versus asterisk to the CO.


---------------------------------------------
zaptel.conf:
loadzone=us
defaultzone=us
span=1,1,0,esf,b8zs
e&m=1-24
span=2,0,0,esf,b8zs
e&m=25-48
---------------------------------------------
zapata.conf
usecallerid=yes
echocancel=yes
immediate=no
context=default
switchtype=national
signalling=em_w
;prewink=270
;preflash=270
;wink=270
;flash=270
group=1
rxgain=2
context=incomingt1
channel=>12-24

group=2
usecallerid=yes
callerid=RTTX <484-875-9460>
immediate=no
;signalling=featdmf
echocancel=no
signalling=em_w
rxgain=2
emdigitwait=2500
context=incomingpbx
channel=>36-48
=====================================
ast-to-co:
ZT_HOOK:ZT_START
Mar 13 23:31:11 pbx01 kernel: chan_ioctl: calling sethook with chan, zt_txsig_start,zt_txstate_start,chan->starttime
Mar 13 23:31:11 pbx01 kernel: Setting bits to 15 for channel TE4/0/1/12 state 2 in 64 signalling

ZT_TXSTATE_START (ready to debounce):
Mar 13 23:31:11 pbx01 kernel: chan_ioctl: calling sethook with chan, zt_txsig_offhook,zt_txstate_afterstart,zt_afterstart_time
Mar 13 23:31:11 pbx01 kernel: Setting bits to 15 for channel TE4/0/1/12 state 1 in 64 signalling

ZT_TXSTATE_AFTERSTART
Mar 13 23:31:12 pbx01 kernel: chan_ioctl: calling sethook in txstate_afterstart -- offhook,offhook,NULL
Mar 13 23:31:12 pbx01 kernel: Setting bits to 15 for channel TE4/0/1/12 state 1 in 64 signalling

Mar 13 23:31:27 pbx01 kernel: zt_hangup: calling sethook with chan, zt_txsig_onhook,zt_txstate_onhook,NULL
Mar 13 23:31:27 pbx01 kernel: Setting bits to 0 for channel TE4/0/1/12 state 0 in 64 signalling
--------------------------------------------------------
co-to-ast:
ZT_HOOK:ZT_WINK
Mar 13 23:41:34 pbx01 kernel: chan_ioctl: calling sethook with chan, zt_txsig_onhook,zt_txstate_prewink,chan->prewinktime
Mar 13 23:41:34 pbx01 kernel: Setting bits to 0 for channel TE4/0/1/12 state 0 in 64 signalling

ZT_TXSTATE_PREWINK:
Mar 13 23:41:34 pbx01 kernel: chan_ioctl: calling sethook in actually wink -- offhook,wink,winktime
Mar 13 23:41:34 pbx01 kernel: Setting bits to 15 for channel TE4/0/1/12 state 1 in 64 signalling

ZT_TXSTATE_WINK:
Mar 13 23:41:34 pbx01 kernel: chan_ioctl: calling sethook in winkcomplete -- onhook,onhook,NULL
Mar 13 23:41:34 pbx01 kernel: Setting bits to 0 for channel TE4/0/1/12 state 0 in 64 signalling

ZT_HOOK:ZT_OFFHOOK:
Mar 13 23:41:35 pbx01 kernel: chan_ioctl: calling sethook with chan, zt_txsig_onhook,zt_txstate_debounce,chan->debouncetime
Mar 13 23:41:35 pbx01 kernel: Setting bits to 15 for channel TE4/0/1/12 state 1 in 64 signalling

ZT_TXSTATE_DEBOUNCE:
Mar 13 23:41:35 pbx01 kernel: chan_ioctl: calling sethook in txstate_debounce -- offhook,offhook,NULL
Mar 13 23:41:35 pbx01 kernel: Setting bits to 15 for channel TE4/0/1/12 state 1 in 64 signalling

in zt_hangup()
Mar 13 23:41:43 pbx01 kernel: zt_hangup: calling sethook with chan, zt_txsig_onhook,zt_txstate_onhook,NULL
Mar 13 23:41:43 pbx01 kernel: Setting bits to 0 for channel TE4/0/1/12 state 0 in 64 signalling
==================================



Comments:By: Andrew Kohlsmith (akohlsmith) 2005-03-15 10:14:51.000-0600

I've been working with km on this on and off over the past few weeks.  Asterisk will correctly wink when terminating a call, but unless we're missing something obvious, it does not wait for a wink when originating a call.

Since all E&M functions appear to be done in chan_zap I looked there and it seems obvious that nothing is done for E&M wink on Dial().  Around line 1747 in chan_zap.c you see where it starts modifying the dial string that is sent to the zaptel driver based on the signaling.  Nothing is done with SIG_EMWINK.

around line 1735 you see it call ZT_HOOK, then at 1780 ZT_DIAL.  Zaptel.c looks like it can send a wink (~line 4158) but it doesn't seem to ever LOOK for one.
By: Mark Spencer (markster) 2005-03-15 10:16:32.000-0600

This is a technical support issue, please pursue through support@digium.com
By: km (km) 2005-03-15 10:20:45.000-0600

This has been in digium's tech support system (support@digium.com) for a day and a half now -- It is assumed that since the digium people have not gotten back to me within one business day with at least a message stating that they're working towards a solution, that perhaps this was a code bug and not a card-related technical support issue.

EDIT:  Ticket number ASTERISK-15886

edited on: 03-15-05 10:21
By: Russell Bryant (russell) 2005-03-15 10:33:45.000-0600

They are likely just swamped at the moment.  Give them a little bit more time.  If they determine that it is a code issue, it will be handled internally at Digium, and not through the Asterisk bug tracker.
By: Mark Spencer (markster) 2005-03-16 18:10:37.000-0600

Reminder sent to km

Bill Hall, our director of services, assures me he has been attempting to contact you to follow up on your need for technical support regarding this E&M.  If for any reason you do not receive the assistance you need from technical support, please feel free to contact him or myself directly.  His direct number is +1-256-428-6266 and my direct number is +1-256-428-6275.  Thanks!