Subject: [Sip] SIP session without SDP

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 6 Oct 2005 10:03:55 +0200

Hi,

Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an session description offer, the response  (reliable) MUST contain an session description answer.

First, it is not said that the session description must be a SDP body, so I assume something else could be used too?

Second, assume that I want to set up a session without SDP (or, another type of session description)? If I include an empty Accept header (or an Accept header where application/sdp is not listed) I don't think the UAS should be mandated to include an SDP offer in the response.

So, I think the rules in 13.2.1 shall be applicable IF I am using a session description, but I should NOT be mandated to use session description.

Regards,

Christer
Ericsson

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2005 09:29:50 -0400

> So, I think the rules in 13.2.1 shall be applicable IF I am using a session description, but I should NOT be mandated to use session description.

So you want to set up a session that has no description? Why would you 
want to do that?

That seems *so* wrong! The whole point of INVITE is to negotiate the 
details of the session.

Yes, you could use something else besides SDP - the obvious candidate is 
SDPng. But using none doesn't seem to fit the intent of INVITE.

You can get much the effect you seem to be seeking simply by using SDP 
that has no m= lines.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 06 Oct 2005 09:35:50 -0400

On Thu, 2005-10-06 at 10:03 +0200, Christer Holmberg (JO/LMF) wrote:
> Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an
> session description offer, the response  (reliable) MUST contain an
> session description answer.
> 
> First, it is not said that the session description must be a SDP body,
> so I assume something else could be used too?

Yes.  But I do not believe that any other form of session description
has been standardized.

> Second, assume that I want to set up a session without SDP (or,
> another type of session description)?

Why would you want to have a dialog with no session description?

Though with the advent of MESSAGE, it is possible that one could
establish a SIP dialog entirely to be able to pass MESSAGE requests, and
thus need no "media" at all.

> If I include an empty Accept header (or an Accept header where
> application/sdp is not listed) I don't think the UAS should be
> mandated to include an SDP offer in the response.

Section 20.1 makes it clear that an empty Accept header means that no
body formats are acceptable, whereas a missing Accept header is
equivalent to "application/sdp".

> So, I think the rules in 13.2.1 shall be applicable IF I am using a
> session description, but I should NOT be mandated to use session
> description.

The last paragraphs of section 13.2.1 make it clear that a session
description is mandatory only if there is an explicit or implicit
"Content-Disposition: session" header.  Checking section 20.11 and the
IANA registrations (http://www.iana.org/assignments/mail-cont-disp), it
does not appear that there is a Content-Disposition that means "no
content", but the values "alert", "icon", and "render" would seem safe
to use with an empty body.  Perhaps a new value "none" is needed?

Do you have an application where all this is a serious consideration?
If so, you might want to lobby for standardizing "Content-Disposition:
none".

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2005 13:23:29 -0400

> thus need no "media" at all.

This would be an abuse of INVITE. INVITE creates an *invite dialog 
usage* and as a side effect also may create a dialog. If all you want is 
a dialog within which to send MESSAGE, then you don't need the invite 
dialog usage.

There are currently two kinds of dialog usage: invite & subscribe. 
Neither of these is right if all you want is to send MESSAGEs. That is a 
hint that you are doing something wrong. If you wanted to do that, then 
the right thing to do would be to come up with a new 
message-dialog-usage and a way to establish it. But there would be 
resistance to that - there is resistance to the whole concept of using 
MESSAGEs within a dialog as a message session. It was considered and 
rejected in favor of MSRP.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 06 Oct 2005 14:55:17 -0400

> a dialog within which to send MESSAGE, then you don't need the invite 

What is an "invite dialog usage"?  I haven't seen that term.  Presumably
it means more than "a dialog started by an INVITE".

> But there would be 

Hmmm, but I see that MSRP is set up using SDP, so it doesn't give an
example of a different body-content for INVITE.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Oct 2005 14:58:57 -0400

inline.

> to use with an empty body.  Perhaps a new value "none" is needed?

I don't think so. The intent of the paragraphs at the end of 13.2.1 was 
to say that presence of a jpg in an INVITE does NOT mean that the jpg is 
the offer. This doesnt mean that its ok to do a SIP INVITE exchange 
without exchanging session descriptions. Indeed, I think the current 
text would forbid it (certainly, that was the intent). Note the following:

The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be
    supported by all user agents as a means to describe sessions, and its
    usage for constructing offers and answers MUST follow the procedures
    defined in [13].

This means that the Accept header field has to be either absent 
(implying support only for SDP), or present and include SDP. It cannot 
be present and list nothing. As a consqeuence, lack of an offer in the 
INVITE will trigger an offer in the first reliable response.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 06 Oct 2005 15:24:42 -0400

> INVITE will trigger an offer in the first reliable response.

I'm new here, and I can't say what the intent was, but if you read that
sentence closely, it does not say that setting up a session with SDP is
mandatory in all INVITEs.  All it says is that the UA must be able to do
so with SDP, and if it does use SDP, it must do so according to [13].

In regard to the Accept header, section 20.1 says (in part):

   20.1 Accept

   An empty Accept header field means that no formats are acceptable.

Perhaps an empty Accept header is forbidden elsewhere, but I haven't
seen such a statement.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2005 17:21:07 -0400

> it means more than "a dialog started by an INVITE".

I thought dialog usage was discussed in either 3261 or 3265, but I can't 
find it right now. In any case it is a not widely understood.

There are dialogs, and there are things that use dialogs: invites and 
subscriptions. The dialog itself has a certain amount of state 
associated with it. Then each usage has some added state. So, a dialog 
has: route set, target address, callid, local and remote CSeq, ...

A subscribe dialog usage has: a direction (is this a subscriber or 
notifier), event type, event id, expiration time, ...

An invite dialog usage has very little state of its own. I think you can 
probably consider offer/answer state to be part of this, maybe the most 
recent offered and answered sdp.

> example of a different body-content for INVITE.

Right, because that is just a bad idea. Doing MSRP as a real media 
stream within a session made it fit into the overall model better.

	Paul