[Home]

Summary:ASTERISK-10980: Asterisk replies with a 488 to a Re-Invite with no SDP
Reporter:andrebarbosa (andrebarbosa)Labels:
Date Opened:2007-12-05 08:49:12.000-0600Date Closed:2008-03-12 15:25:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 12[p1]-sip-reply-to-no-sdp-invites.diff
( 1) 488_log
( 2) after_patch_log
( 3) reinvite_with_sdp_without_patch
( 4) sip_log_with_patch_only_sip.pcap
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!

Comments:By: Olle Johansson (oej) 2007-12-05 11:15:25.000-0600

Why is a device sending a re-invite without an SDP?
By: andrebarbosa (andrebarbosa) 2007-12-06 04:08:10.000-0600

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. :\
By: Olle Johansson (oej) 2007-12-06 04:21:25.000-0600

Anything is possible, but if you don't know what you want to accomplish with this INVITE, I see no reason to patch Asterisk to support it. It seems like a no-op to me until you can explain... :-)
By: andrebarbosa (andrebarbosa) 2007-12-06 07:23:48.000-0600

If the RFC says he can do that, and if we can honor RFC with no effort, I think we should. Don't we?
By: Olle Johansson (oej) 2007-12-06 07:58:14.000-0600

Just because you can I don't like doing it without knowing why you're re-inviting. There has to be a reason to re-invite, something that the UA issuing the re-invite wants to change.
By: Steve Langstaff (srl100) 2007-12-06 08:20:05.000-0600

I am a bit unclear on the scenario.
Is it a re-invite or a new invite?
Is it the proxy sending the (re)invite?
Can you attach a wireshark trace?
By: andrebarbosa (andrebarbosa) 2007-12-06 08:40:36.000-0600

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: 51
Originally Asterisk will reply with a 488 to that INVITE.


By: Steve Langstaff (srl100) 2007-12-06 09:00:43.000-0600

I think that your patch *has* broken some other stuff - look at the trace... there appears to be a storm of 200 OK / ACK messages going to and fro until the call is hung up (frames 68..82).

Also, I think that the proxy behaviour is somewhat suspect - shouldn't the INVITE in frame 51 have a "Replaces" header (as well as the discussed SDP payload) if it is part of the call transfer?


By: Olle Johansson (oej) 2007-12-06 11:26:54.000-0600

You need to upload your patch as a file.

I needed to delete your uploaded patch since we need to make sure you have accepted our license.

Sorry for that, please try again.
By: andrebarbosa (andrebarbosa) 2007-12-06 11:32:33.000-0600

Done oej!

Regarding slr100 note, I have uploaded another trace from a Re-Invite with SDP, and Asterisk (1.2.17 with no patches) replies with a 200OK and there are a lots os 200OK and ACKs.

Is this normal? I can't explain why this happen, I'm trying to understand if I broke something.
By: Terry Wilson (twilson) 2007-12-12 14:36:59.000-0600

Seeing a string of 200 OK ACKs repeated generally means that whatever was sending the 200 OK didn't receive or didn't like the ACK that was sent.  I haven't gone through the captures yet, but that has been my general experience with asterisk and openser.  Will go ahead and take a quick look.
By: Raj Jain (rjain) 2007-12-26 09:47:25.000-0600

RE-INVITEs w/o SDP are generally a bad idea but they are frequently used in SIP trunk interfaces provided by many commercial PBXs. They are typically used in call hold/resume scenarios.
By: Olle Johansson (oej) 2007-12-28 07:52:45.000-0600

I think trunk behaves differently. Rjain reminded me that I fixed something like this for trunk for Cisco Call Manager Express. Please test. We might have to backport that.
By: Digium Subversion (svnbot) 2008-03-12 14:12:16

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 ASTERISK-10980
Reported by: andrebarbosa


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

http://svn.digium.com/view/asterisk?view=rev&revision=108086
By: Digium Subversion (svnbot) 2008-03-12 15:23:04

Repository: asterisk
Revision: 108191

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r108191 | kpfleming | 2008-03-12 15:23:03 -0500 (Wed, 12 Mar 2008) | 14 lines

Merged revisions 108086 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108086 | kpfleming | 2008-03-12 14:16:07 -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 ASTERISK-10980
Reported by: andrebarbosa


........

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

http://svn.digium.com/view/asterisk?view=rev&revision=108191
By: Digium Subversion (svnbot) 2008-03-12 15:25:53

Repository: asterisk
Revision: 108205

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r108205 | kpfleming | 2008-03-12 15:25:52 -0500 (Wed, 12 Mar 2008) | 22 lines

Merged revisions 108191 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r108191 | kpfleming | 2008-03-12 15:27:01 -0500 (Wed, 12 Mar 2008) | 14 lines

Merged revisions 108086 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108086 | kpfleming | 2008-03-12 14:16:07 -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 ASTERISK-10980
Reported by: andrebarbosa


........

................

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

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