[Home]

Summary:ASTERISK-14306: Asterisk can not get channel lock when receiving BYE message which results in 503 error message
Reporter:Florian Floimair (ffloimair)Labels:
Date Opened:2009-06-12 06:47:41Date Closed:2011-06-07 14:00:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) SIP_trace.pcap
( 1) verbose_log_sip_debug.txt
Description:We have a SIP trunk to an Alcatel PBX running. Sometimes when the Alcatel side sends us a BYE message, the Asterisk would respond with a 503 error message. The logs in that case say that Asterisk could not get a channel lock.

Asterisk version is 1.4.21.1, but the same can be observed with versions up to 1.4.23.1
I was not yet able to test higher versions because the site is in France and one of our technicians will fly there on monday. I will update this post in case 1.4.25.1 does not show this error.

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

The error seems to be identical to this issue: https://issues.asterisk.org/view.php?id=11727

I will attach some log and capture files that were sent to me by the local technicians.
Comments:By: Mark Michelson (mmichelson) 2009-06-12 08:55:57

I don't mean to sound accusatory here, but are you certain that you saw the same behavior with 1.4.23.1? There was additional logic added between the 1.4.22 and 1.4.23 releases of Asterisk so that if we could not get the channel lock when trying to process an incoming SIP request, we would queue the request to be handled a short time later. We don't have the same "giving up" behavior in the code now. In fact, the "we could NOT get the channel lock" message does not exist in 1.4.23+.

I'm thinking then that if you are seeing 503s in response to BYEs in 1.4.23.1, then the cause is something different and it would be helpful to examine the logs from when this occurs in that version. If you can post such information, that would be helpful. Thanks!
By: Florian Floimair (ffloimair) 2009-06-19 01:49:09

Problem was indeed fixed with higher version. Sorry for the false alarm.
Please close this issue.