[asterisk-bugs] [Asterisk 0013136]: [patch] sip peer qualified failed, asterisk lock.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=13136 
====================================================================== 
Reported By:                pabelanger
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13136
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     confirmed
Target Version:             1.6.0.x Pending Blocker
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-07-23 02:32 CDT
Last Modified:              2009-09-02 15:19 CDT
====================================================================== 
Summary:                    [patch] sip peer qualified failed, asterisk lock.
Description: 
We just had asterisk lock on us tonight.  Best we can guess is because we
lost our SIP PEER (via qualify).

See output from 'show core locks'.
====================================================================== 

---------------------------------------------------------------------- 
 (0110073) whys (reporter) - 2009-09-02 15:19
 https://issues.asterisk.org/view.php?id=13136#c110073 
---------------------------------------------------------------------- 
Coolmig: 
1. ???
2. No. Qualify = no, only hides the (my) problem until a call is placed.
3. I tried notthematrix workarounds. They did nothing for me.

I am not sure if this is the same problem. For what it's worth, I make a
UDP sip channel to an IP that does not exist (doesn't answer)  The call
takes 33 seconds to timeout. If it's a TCP channel it takes 190 seconds to
timeout.  If it dial two extensions, where one answers and the other one
(as above) can not (tcp), the call never bridges.

This behavior is the same on branches 1.6.0, 1.6.1, 1.6.2 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-02 15:19 whys           Note Added: 0110073                          
======================================================================