I disagree with the notion that you should include C-T:application/sdp
and C-L:0 to indicate no offer. In fact, I think it is probably invalid
to do so.
There are at least a couple of issues with that:
- If you specify a C-T, then the body needs to conform to the
specification for that type. In the case of SDP, a valid SDP body always
has a few lines. For instance it must have an o-line. So your zero
length body will be ill-formed, resulting in an error.
- If that were not the case, then the empty sdp body would be an offer.
In that regard, 3261 differs from 2543. In 2543 you could have an SDP
body, and if it didn't have any m-lines, then it was considered not to
be an offer. In 3261, the presence of an sdp body (with C-D session)
constitutes an offer (or answer) assuming it is in a place where an
offer or answer is valid. This is true even if it has no m-lines. If an
entirely empty sdp body were valid, then it too would be an offer if in
an initial INVITE.
If you want to omit the offer, then you need to omit the C-T:
application/sdp as well as the body itself.
Thanks,
Paul
Vikram Chhibber wrote:
> On Mon, Apr 20, 2009 at 3:29 PM, Kevin Spencer
> <spenk.l...@googlemail.com> wrote:
>> Dave,
>> Thanks, thats clear from the point of view of the arbitrary binary body.
>> Vikram,
>> But in the case where no offer is made in the initial INVITE surely there is
>> no need to indicate a content-type at that stage (it may not be known at
>> that point?), for example the "Session via Redirect and Proxy Servers with
>> SDP in ACK" scenario in 3665 shows the initial INVITE with a content-length
>> 0 but no content-type header.
> As such, there is no defined behavior in case Content-Length 0 is
> defined and Content-Type is missing.
> I have seen few UA which rejects initial INVITE without SDP if it has
> missing type. On the safe side, you might
> want to include the type even though length is 0.
>> In this context would it be correct to say that while the type isn't
>> necessary you should still be prepared to receive it while not necessarily
>> acting upon it?
> For the above context, yes, we should be lenient enough to recieve or
> not receive the type if length is 0.
> But we can not generalize as it very much depends on the type and context.
>> Or, in the case of an SDP body does 0 length have no
>> significance and the content-type shouldn't be used, and rejected if
>> received - I don't see that in 4566 or 3264 though.
> I do not think RFCs should be that harsh and define the behavior for
> unexpected scenarios where presence
> or absence of something does not violate anything.
>> Thanks for the responses,
>> /K
>>
>> On Mon, Apr 20, 2009 at 10:15 PM, Dale Worley <dwor...@nortel.com> wrote:
>>
>>> On Mon, 2009-04-20 at 16:21 +0100, Kevin Spencer wrote:
>>>> Does anyone have any suggestions as to under what circumstances you would
>>>> consider including a Content-Type: header when your Content-Length: is
>>> zero?
>>>> 3261 gives the following example in section 20.15:
>>> I don't know of any current application, but SIP is careful to allow the
>>> body to be an arbitrary (binary) object of any type. As such, we must
>>> provide for the possibility that for a particular media type, a content
>>> of zero bytes has a useful meaning.
>>>
>>> Dale
>>>
>> On Mon, Apr 20, 2009 at 6:4 PM, Vikram Chhibber <vikram.chhib...@gmail.com>
>> wrote:
>>
>>> You will carry Conent-Type with 0 Content-Length when you say "I am
>>> carrying 0 length XYZ Content-Type", which is different then saying "I
>>> am carrying no body with an type". Typical scenario would be INVITE
>>> without offer sdp. You still need to have Conent-Type as
>>> "application/sdp". If you remove Content-Type itself, you can receive
>>> 488 response.
>>> Example of 0 Content-Length and no type would be BYE message where you
>>> typically do not send any body.
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
