Re: [reSIProcate-users] UPDATE with Content-Type: application/sdp but Content-Length: 0
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/