<div dir="ltr">Xavier,<div><br></div><div>DoNotDisturb generates a &quot;Busy&quot; indication. Insert that into my earlier response, and you have an explanation of why the call tries to go from RING to BUSY, and confirms my theory.</div>
<div><br></div><div>No you cannot replace the Zaptel card driver on its own (and the problem was bigger than that anyway), as Asterisk is compiled and linked to a specific Zaptel (Dahdi) version.<br></div><div><br></div><div>
<div>As mentioned, you need to call IPCortex.</div></div><div><br></div><div>Regards,</div><div>Steve</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 July 2013 16:23, Xavier Singer - EcuTek <span dir="ltr">&lt;<a href="mailto:xavier@ecutek.com" target="_blank">xavier@ecutek.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Update:<br>
I can reproduce the error by putting the reception phone (call queue 0) in Do Not Disturb mode, then call in from outside using a mobile, then pick up the call from the 2nd phone in the queue. It will cause the error only if I hang up _before_ the mobile hangs up. The error doesn&#39;t seem to happen if the external call hangs up, or if the call is answered by the reception phone (first call in the queue).<br>

<br>
Thanks again,<br>
Xavier<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
-----Original Message-----<br>
From: Xavier Singer - EcuTek<br>
Sent: 11 July 2013 12:02<br>
To: &#39;<a href="mailto:asterisk-users@lists.digium.com">asterisk-users@lists.digium.com</a>&#39;<br>
Subject: IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6<br>
<br>
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).<br>

<br>
Since implementing this feature we&#39;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:<br>

<br>
        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.<br>
        Jul 11 08:30:54 ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6! Corrected.<br>
        Jul 11 08:30:54 WARNING[7133] chan_zap.c: Call specified, but not found?<br>
        Jul 11 08:30:54 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127<br>
        Jul 11 08:30:54 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1<br>
        Jul 11 08:30:58 WARNING[7133] chan_zap.c: Call specified, but not found?<br>
        Jul 11 08:30:58 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127<br>
        Jul 11 08:30:58 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1<br>
        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,<br>
        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,<br>
        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,<br>
        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,<br>
<br>
The ERROR happens when the call is ended. I can&#39;t replicate the error either...<br>
<br>
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.<br>
<br>
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):<br>
ISDN State 6 = not initialised<br>
Cause 16 = normal call clearing<br>
Cause 17 = user busy<br>
TEI 127 = reserved as the broadcast TEI<br>
<br>
<br>
So my questions are:<br>
1. What could be causing the error and any suggestions on how to troubleshoot this issue?<br>
2. Can I upgrade the chan_zap driver for the ISDN card without breaking the IPcortex frontend (we have root access)?<br>
3. Should I supply any config files?<br>
<br>
<br>
Thanks!<br>
Xavier<br>
<br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
               <a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br></div>