[asterisk-bugs] [Asterisk 0011475]: Asterisk replies with a 488 to a Re-Invite with no SDP

[noreply at bugs.digium.com]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=11475 
====================================================================== 
Reported By:                andrebarbosa
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   11475
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:            1.2.24  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-05-2007 08:49 CST
Last Modified:              03-12-2008 14:12 CDT
====================================================================== 
Summary:                    Asterisk replies with a 488 to a Re-Invite with no
SDP
Description: 
I notice that Asterisk replies with a "488 not acceptable here" when
receives a re-invite with no SDP data.

In the 488_log file is possible to see a sip debug of this dialog.

RFC 3261 talks about UAS behaviour in these scenario in section 14,
quoting:

"
14.1 UAC Behavior

   The same offer-answer model that applies to session descriptions in
   INVITEs (Section 13.2.1) applies to re-INVITEs.  As a result, a UAC
   that wants to add a media stream, for example, will create a new
   offer that contains this media stream, and send that in an INVITE
   request to its peer.  It is important to note that the full
   description of the session, not just the change, is sent.  This
   supports stateless session processing in various elements, and
   supports failover and recovery capabilities.  Of course, a UAC MAY
   send a re-INVITE with no session description, in which case the first
   reliable non-failure response to the re-INVITE will contain the offer
   (in this specification, that is a 2xx response). "

I found a solution for this on find_sdp routine, but I need help to
understand if my patch will break other stuff.

I've attach my little hack, and the sip log of dialog with the hacked
chan_sip

Thanks!


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012110 CCM sends multiple INVITEs which causes...
====================================================================== 

---------------------------------------------------------------------- 
 svnbot - 03-12-08 14:12  
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 108086

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r108086 | kpfleming | 2008-03-12 14:12:09 -0500 (Wed, 12 Mar 2008) | 6
lines

if we receive an INVITE with a Content-Length that is not a valid number,
or is zero, then don't process the rest of the message body looking for an
SDP

closes issue http://bugs.digium.com/view.php?id=11475
Reported by: andrebarbosa


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

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

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-12-08 14:12  svnbot         Note Added: 0083842                          
03-12-08 14:12  svnbot         Status                   ready for testing =>
assigned
03-12-08 14:12  svnbot         Assigned To               => kpfleming       
======================================================================