Re: [reSIProcate-users] UPDATE with Content-Type: application/sdp but Content-Length: 0

[Ruadhri Howman <ruadhri@xxxxxxxxx>]

Thanks for that Scott; I appreciate the patch.

Regards,
Ruadhri

On Mon, Jul 5, 2010 at 4:32 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

Ok sounds like those updates are coming from the session timer logic.  The following code was added in revision 8400 (InviteSession.cxx - resip 1.5) that should remove the content type header:

here is the commit comment:

-fixed a bug where the Content-Type header could be set in a UPDATE Session Refresh 

 to application/sdp, but the content length would be 0 - the content-type header 

 should not be present

void

InviteSession::sessionRefresh()

{

   if (updateMethodSupported())

   {

      transition(SentUpdate);

      mDialog.makeRequest(*mLastLocalSessionModification, UPDATE);

      mLastLocalSessionModification->setContents(0);  // Don't send SDP

   }

Scott

On Mon, Jul 5, 2010 at 4:13 AM, Ruadhri Howman <ruadhri@xxxxxxxxx> wrote:

Hi Scott,


I'm looking into it at the moment, but I'm pretty sure reSIProcate 1.3 looks after sending the UPDATE and that we're not modifying it. We set a timer in the master profile, and that's it.

I've noticed that if the initial INVITE from reSIP 1.3 doesn't contain an SDP (so we're setting a control channel, or it's a late media session), the UPDATEs for that SIP dialog don't contain a Content-Type field. If the initial INVITE does contain an SDP, then the UPDATEs for that dialog contain the Content-Type field.

I'll let you know when I've figured out if our code is doing anything to the UPDATEs.

Regards,
Ruadhri.

On Sat, Jul 3, 2010 at 4:26 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

I think the bug is on the sending side.  I don't think its legal to send an UPDATE can can carry an SDP offer with a 0-length SDP body.  The Content-Type field should not be present if there is no intent to send a SDP body.

How are you sending the update?

Scott

On Thu, Jul 1, 2010 at 6:56 AM, Ruadhri Howman <ruadhri@xxxxxxxxx> wrote:

Hi,

I'm using two different versions of reSIProcate in two processes. (I plan on using the samw one in both, but I'm not there yet).

The client is using a heavily modified reSIP 1.3, and the server is using a vanilla reSIP 1.5.

The client sets up a SIP dialog with a timer:

// Start SIP
INVITE sip:sip-server@xxxxxxxxxxx:5070 SIP/2.0
Via: SIP/2.0/TCP 172.16.1.45:5080;branch=z9hG4bK-d8754z-d81c143c00af7807-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:sip-client@xxxxxxxxxxx:5080;transport=TCP>
To: <sip:sip-server@xxxxxxxxxxx:5070>
From: <sip:sip-client@xxxxxxxxxxx:5080>;tag=18da4b21
Call-ID: ZTEwNGRkZDk0YjdhZWMyZGQxNjZhZGQwMzNmNDE1NzE.
CSeq: 1 INVITE
Session-Expires: 180
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, INFO
Content-Type: application/sdp
Supported: timer
Content-Length: 201

[Valid SDP]
// End SIP

This is agreed and the dialog created.

Later, when the timer expires, the client sends an UPDATE:

// Start SIP
UPDATE sip:sip-server@xxxxxxxxxxx:5070 SIP/2.0
Via: SIP/2.0/TCP 172.16.1.45:5080;branch=z9hG4bK-d8754z-f55ba540c282647d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:sip-client@xxxxxxxxxxx:5080;transport=TCP>
To: <sip:sip-server@xxxxxxxxxxx:5070>;tag=5ea8af36
From: <sip:sip-client@xxxxxxxxxxx:5080>;tag=18da4b21
Call-ID: ZTEwNGRkZDk0YjdhZWMyZGQxNjZhZGQwMzNmNDE1NzE.
CSeq: 6 UPDATE
Session-Expires: 180;refresher=uac
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, INFO
Content-Type: application/sdp
Supported: timer
Content-Length: 0

// End SIP

As you can see, the UPDATE contains "Content-Type: application/sdp" but a Content-Length of zero.

From looking at the SIP spec, this seems valid (though I'm open to correction):
   The Content-Type header field indicates the media type of the
   message-body sent to the recipient.  The "media-type" element is
   defined in [H3.7].  The Content-Type header field MUST be present if
   the body is not empty.  If the body is empty, and a Content-Type
   header field is present, it indicates that the body of the specific
   type has zero length (for example, an empty audio file).

However, reSIProcate is treating the message as if it contained an offer: "OnUpdateOffer"; rather than as an update without an offer: "OnUpdate". The fact that the Content-Type header states that it's an "application/sdp" is seen as enough to think that it's got an SDP.

To get around this we check that the Content-Length: value is greater than zero in the method InviteSession::toEvent in resip/dum/InviteSession.cxx.

I took reSIP 1.6 down, and saw that the bug(?) still exists there, so the change is against that file.

File: resip/dum/InviteSession.cxx
2848c2848
<       if (sdp)
---
>       if (sdp && (msg.header(h_ContentLength).value() > 0))


Regards,
Ruadhri.

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/