[asterisk-bugs] [Asterisk 0019182]: [patch] [regression] Asterisk drops sip messages and/or response codes if SIP/TLS is used

Asterisk Bug Tracker noreply at bugs.digium.com
Mon May 23 09:28:10 CDT 2011


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19182 
====================================================================== 
Reported By:                st
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   19182
Category:                   Channels/chan_sip/TCP-TLS
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     closed
Target Version:             1.8.5
Asterisk Version:           1.8.3.3 
JIRA:                       SWP-3404 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           1.8.5
====================================================================== 
Date Submitted:             2011-04-26 10:11 CDT
Last Modified:              2011-05-23 09:28 CDT
====================================================================== 
Summary:                    [patch] [regression] Asterisk drops sip messages
and/or response codes if SIP/TLS is used
Description: 
When a Snom 360 (Firmware 7.3.7) tries to register, there is a new tcp
connection. Sometimes Asterisk CLI shows Register and 401 Response, but the
phone does not get a response. Sometimes CLI shows nothing, but the phone
logs many attempts to register. Its strange and not easy to reproduce, but
here sipp is the solution.


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
parent of           0019192 [patch] [regression] segfault in _sip_t...
====================================================================== 

---------------------------------------------------------------------- 
 (0135253) svnbot (reporter) - 2011-05-23 09:28
 https://issues.asterisk.org/view.php?id=19182#c135253 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 320181

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r320181 | mnicholson | 2011-05-23 09:28:06 -0500 (Mon, 23 May 2011) | 23
lines

Merged revisions 320180 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r320180 | mnicholson | 2011-05-20 13:48:46 -0500 (Fri, 20 May 2011) | 16
lines
  
  This commit modifies the way polling is done on TLS sockets.
  
  Because of the buffering the TLS layer does, polling is unreliable. If
poll is
  called while there is data waiting to be read in the TLS layer but not
at the
  network layer, the messaging processing engine will not proceed until
something
  else writes data to the socket, which may not occur. This change
modifies the
  logic around TLS sockets to only poll after a failed read on a
non-blocking
  socket. This way we know that there is no data waiting to be read from
the
  buffering layer.
  
  (closes issue https://issues.asterisk.org/view.php?id=19182)
  Reported by: st
  Patches:
        ssl-poll-fix3.diff uploaded by mnicholson (license 96)
  Tested by: mnicholson
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=320181 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-23 09:28 svnbot         Checkin                                      
2011-05-23 09:28 svnbot         Note Added: 0135253                          
======================================================================




More information about the asterisk-bugs mailing list