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)
_______________________________________________
Asterisk-Dev mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
