[Home]

Summary:ASTERISK-08662: zap channel hangup is not detected if it occurs before the line is answered
Reporter:Antonio Gallo (agx)Labels:
Date Opened:2007-01-25 10:01:49.000-0600Date Closed:2007-02-07 14:39:07.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:if incoming caller hungup before asterisk with TDM400P answer the channell then the hangup is never detected

instead if line is answered in some way it works ok with the given timeout

you can see below: zaptel.conf zapata.conf and debugging of the incoming call

I was able to reprocude this problem on all of my installations with that analog card.


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

/etc/zaptel.conf
loadzone=it
defaultzone=it
fxsks=4

dmesg:
Module 0: Not installed
Module 1: Not installed
Module 2: Not installed
Module 3: Installed -- AUTO FXO (ITALY mode)

/etc/asterisk/zapata.conf:
[channels]
adsi=no
callerid=asreceived
callprogress=no
callreturn=no
callwaitingcallerid=yes
callwaiting=yes
cancallforward=no
canpark=yes
context=vuoto
echocancelwhenbridged=no
echocancel=0
echotraining=no
faxdetect=incoming
hidecallerid=no
immediate=no
internationalprefix=00
nationalprefix=0
overlapdial=yes
pridialplan=local
priindication = outofband
prilocaldialplan=local
rxgain=0.0
signalling=pri_cpe
switchtype=euroisdn
threewaycalling=no
transfer=yes
txgain=0.0
usecallerid=yes
usecallingpres=yes
callgroup=1
pickupgroup=1
; end template
; TDM400p settings that override default template
callprogress=no
usecallerid=yes
callerid=asreceived
busydetect=yes
busycount=5
busypattern=500,500
signalling=fxs_ks
language=it
context=from-trunk-zap-1
group=1
echotraining=100
echocancel=32
rxgain=0.0
txgain=0.0
usecallerid=yes
channel=>4

here is the logs:
Jan 25 16:57:59 VERBOSE[12217] logger.c: Asterisk Event Logger restarted
Jan 25 16:57:59 VERBOSE[12217] logger.c: Asterisk Queue Logger restarted
Jan 25 16:58:05 DEBUG[12208] dsp.c: dsp busy pattern set to 500,500
Jan 25 16:58:05 VERBOSE[12218] logger.c:     -- Starting simple switch on 'Zap/4-1'

(i hang up at this point)

Jan 25 16:58:13 WARNING[12218] chan_zap.c: CallerID returned with error on channel 'Zap/4-1'
Jan 25 16:58:13 VERBOSE[12218] logger.c:     -- Executing Set("Zap/4-1", "__FROMTRUNK=1") in new stack
Jan 25 16:58:13 VERBOSE[12218] logger.c:     -- Executing NoOp("Zap/4-1", "DNID=") in new stack
Jan 25 16:58:13 VERBOSE[12218] logger.c:     -- Executing NoOp("Zap/4-1", "FROMDNID=") in new stack
Jan 25 16:58:13 VERBOSE[12218] logger.c:     -- Executing Macro("Zap/4-1", "ringing|0") in new stack
Jan 25 16:58:13 VERBOSE[12218] logger.c:     -- Executing NoOp("Zap/4-1", "") in new stack

(i've hanged up but call keeps flowing keeping the line busy until my dial group expire and goes to voicemail... so Playback answer the channel and busydetect succefully detect the real busy 30 second later i hanged up: ofc it detect busy tone 3 seconds after the channel is answer)

Jan 25 17:00:54 VERBOSE[12245] logger.c:     -- Playing 'vm-isunavail' (language 'it')
Jan 25 17:00:55 DEBUG[12245] dsp.c: Requesting Hangup because the busy tone was detected on channel Zap/4-1
Jan 25 17:00:55 VERBOSE[12245] logger.c:     -- Hungup 'Zap/4-1'

Comments:By: Joshua C. Colp (jcolp) 2007-01-25 17:04:06.000-0600

Please contact Digium technical support at support@digium.com - if it is a core zaptel issue it will be forwarded onwards, Thanks!
By: Antonio Gallo (agx) 2007-01-26 05:16:48.000-0600

I checked today with a Sangoma A200 with 4FXO and onboard echo canceller and the problem is exactly the same, so i think its Zaptel problem.
By: Antonio Gallo (agx) 2007-01-29 04:58:55.000-0600

Can you move this to channel driver? I found the problem in depth.

When "usercallerid=yes" and the CID signalling is bell (i.e. callerID is sent onto the 2nd ring) then if the callers hang up before the lines is answered and/or the callerID is detected then chan_zap return the error at line 6147 of chan_zap.c revision 48371.

Then it continue execution without knowing that remote caller has hanged up keeping the line active (and ofc it keeps the remote caller paying...)

I temporary fixed this using this:

if (res < 0) {
   ast_log(LOG_WARNING, "CallerID returned with error on channel '%s'\n", chan->name);
   ast_log(LOG_WARNING, "AGX: Hanging up channel '%s'\n", chan->name);
   ast_log(LOG_WARNING, "AGX: State............: '%i'\n", chan->_state);
   ast_hangup(chan);
   return NULL;
}

This ofc doesn't fix the problem but provide a temporary solution until someone that developed the calledID stuff in chan_zap.c will modify it to monitor if line is hanged up during the callerID detection phase.

I have to check if this give problem when anonymous people call us.

Will let you know.
By: Tzafrir Cohen (tzafrir) 2007-02-01 01:15:29.000-0600

This belongs in "channel drivers".

The channel is configured to disconnect on busy tone (busydetect=yes).
When you listen on the channel with ztmonitor (or record using it to a file), do you hear a busy tone on the line?
By: Serge Vecher (serge-v) 2007-02-05 12:56:07.000-0600

agx: did you contact support as file requested?
By: Antonio Gallo (agx) 2007-02-07 03:45:50.000-0600

serge-v - manager: Yes

this is their answer:
--- begin ---
Hello,
Please try the latest svn branch of zaptel 1.4.  It is backwards compatible with Asterisk 1.2.  Also run fxotune from zaptel 1.4 source code.  This will help tune your fxo module.   Last in your /etc/asterisk/zapata.conf try the following options I provided below. If you need help compiling zaptel or any other configuration. Please either call or reply back to this email with ssh/telnet access.   When calling in reference case number 6052.
edit "/etc/asterisk/zapata.conf"
busydetect=yes
busycount=4
--- end ---
By: Serge Vecher (serge-v) 2007-02-07 14:39:06.000-0600

ok, as is clear from file's instructions ("if it is a core zaptel issue it will be forwarded onwards ...,") and support's response, the proper thing to do is   follow-through on suggestions made by tech.support and communicate with them directly should the issue persist. Please do that. Thank you.