[Asterisk-Dev] Ring requested on channel already in use

[James Sizemore]

If I had to guess you also log cdr's to a database and your database 
server is slow for some reason, Asterisk will not hang up a call till 
the database query finished, the telco will only wait so long for an 
acknowledgment from a hang up and disconnects it's end and tried to use
the same channel for the next incoming call, hence your reported error.



Matt Fredrickson wrote:
> On Tue, Sep 06, 2005 at 03:56:11PM -0400, alan wrote:
> 
>>A problem was recently posted on the Asterisk-Users mailing list, and it
>>went unresolved. Now that it's plaguing our production system as well, I
>>need to look into it further.
>>
>>I am fairly sure this is a bug and not a misconfiguration issue. I will
>>be happy to provide much more additional information, after I'm sure
>>it's a bug and not a -users issue :)
>>
>>Summary:
>>
>>Occasionally, the same PRI channel receives two "Channel ... got hangup"
>>notifications in sequence, with no intervening activity on the channel.
>>A subsequent call coming in to the same span and channel receives the
>>"warning:"
>>Ring requested on channel 0/3 already in use on span 1. Hanging up owner.
>>
>>When this happens, Asterisk enters an inconsistent state, which I have
>>only been able to correct by restarting.
>>
>>Some symptoms I've seen when it's in this state are: previously active
>>"asterisk -r" sessions fail to exectue commands; most/all extensions
>>fail when dialed by local phones; and of course incoming calls on the
>>PRI fail (with the Ring Requested error).
>>
>>A few more details:
>>
>>I dug into chan_zap.c, and found 2 places which generate the exact same
>>"Channel 0/3, span 1 got hangup" message, both in the huge function
>>pri_dchannel. One was inside "case PRI_EVENT_HANGUP" and one was inside
>>"case PRI_EVENT_HANGUP_REQ".
>>
>>I recompiled with slightly different error messages, so I could see what
>>was happening in this case. In the one failure case I've had since that
>>change, the first "Channel got hangup" message was generated by the
>>PRI_EVENT_HANGUP_REQ case, and the second message was generated by
>>PRI_EVENT_HANGUP.
>>
>>"set debug 4" and "pri intense debug" logs are available if anyone knows
>>more about parsing the intense PRI debugging than I do.
>>
>>
>>** System specs:
>>Asterisk 1.0.8
>>libpri 1.0.8
>>zaptel 1.0.8
>>fedora core 3
>>1x Digium Wildcard TE110P, single T1/E1 card
>>  with a T1/PRI to the PSTN (US)
> 
> 
> Good report, lots of information.  See if you can reproduce it in CVS-HEAD
> (Asterisk, libpri, zaptel)
>