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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11475 
====================================================================== 
Reported By:                andrebarbosa
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11475
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
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:              12-06-2007 04:08 CST
====================================================================== 
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!


====================================================================== 

---------------------------------------------------------------------- 
 andrebarbosa - 12-06-07 04:08  
---------------------------------------------------------------------- 
The scenario is this: I have an asterisk box registered on a SIP proxy.
Have a SIP client (A) registered in asterisk.

Have two(B and C) other extensions registered on the SIP proxy.

Extension A calls B. B transfer the call to C. SIP proxy send a new invite
with no SDP.

I don't know why, but reading the RFC I saw it is possible. :\ 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-06-07 04:08  andrebarbosa   Note Added: 0074883                          
======================================================================