[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 08:40 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 08:40  
---------------------------------------------------------------------- 
It's a re-invite, proxy re-invites because there is a transfer between
proxy extensions.

I will attach a wireshark trace but with the patch applied.. I don't have
the original trace..

Info about the trace:

asterisk box: 192.168.20.205
asterisk extension: 192.168.20.28

proxy ip: 10.162.100.75
proxy extension A: 192.168.20.23
proxy extension B: 192.168.20.25

INVITE with no SDP is the trap number: 2940
Originally Asterisk will reply with a 488 to that INVITE. 

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