We use an IPcortex PABX running Asterisk 1.2.39-BRIstuffed-0.3.0-PRE-1y-y. We
have recently implemented Call Queuing for our main incoming line with hold
music. The call queue type is: Ring all - One call at a time (no position
announcement).
Since implementing this feature we've been receiving the below error daily in
the mornings and lunchtime when the queue will jump to the next available
phone, as the main reception phone is in Do Not Disturb mode:
Jul 11 08:30:54 WARNING[23444] chan_zap.c: 1 Cause code 17 not allowed
when disconnecting an active call. Changing to cause 16.
Jul 11 08:30:54 ERROR[23444] chan_zap.c: You cannot use cause 17 number
when in state 6! Corrected.
Jul 11 08:30:54 WARNING[7133] chan_zap.c: Call specified, but not found?
Jul 11 08:30:54 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1,
tei 127
Jul 11 08:30:54 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on
span 1
Jul 11 08:30:58 WARNING[7133] chan_zap.c: Call specified, but not found?
Jul 11 08:30:58 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1,
tei 127
Jul 11 08:30:58 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on
span 1
Jul 11 08:47:04 WARNING[7133] chan_zap.c: 1 received SETUP message for
call that is not a new call (retransmission), peercallstate 19 ourcallstate 0
cr 1,
Jul 11 08:47:08 WARNING[7133] chan_zap.c: 1 received SETUP message for
call that is not a new call (retransmission), peercallstate 19 ourcallstate 0
cr 1,
Jul 11 08:47:19 WARNING[7133] chan_zap.c: 1 received SETUP message for
call that is not a new call (retransmission), peercallstate 19 ourcallstate 0
cr 1,
Jul 11 08:47:23 WARNING[7133] chan_zap.c: 1 received SETUP message for
call that is not a new call (retransmission), peercallstate 19 ourcallstate 0
cr 1,
The ERROR happens when the call is ended. I can't replicate the error either...
I suspect that the chan_zap driver has a bug and is possibly trying to hang up
the call on the first phone in the queue, rather than the phone that answered
the call.
I have investigated the different state and causes listed in the above log
file, and this is what I think they mean (please correct me if I got it wrong):
ISDN State 6 = not initialised
Cause 16 = normal call clearing
Cause 17 = user busy
TEI 127 = reserved as the broadcast TEI
So my questions are:
1. What could be causing the error and any suggestions on how to troubleshoot
this issue?
2. Can I upgrade the chan_zap driver for the ISDN card without breaking the
IPcortex frontend (we have root access)?
3. Should I supply any config files?
Thanks!
Xavier
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users