Subject: RE: [Sip] SIP session without SDP

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 7 Oct 2005 09:16:51 +0200

Hi,

The issus is not whether the UA entity supports SDP or not, but more if it's mandatory to use for all sessions.

Eventhough it's called session description, SIP usess SDP mainly for MEDIA description (SIP headers and parameters are used to identity the SIP session). So, the questions is whether an INVITE initiated dialog MUST contain media.

Yes, it is possible to send an SDP without m= lines, so if SDP really is mandated I guess one would have to use that. I just think it would be a little unecessary to include such SDP if the UA knows that there will be no media during the dialog.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: 6. lokakuuta 2005 21:59
> To: Dale R. Worley
> Cc: Sip
> Subject: Re: [Sip] SIP session without SDP
> 
> 
> inline.
> 
> Dale R. Worley wrote:
> 
> > 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?
> 
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Fri, 07 Oct 2005 09:21:58 -0400

Christer Holmberg (JO/LMF) wrote:
> Eventhough it's called session description, SIP usess SDP mainly for MEDIA description (SIP headers and parameters are used to identity the SIP session).

This is not remarkable. Look back at the history of MMUSIC. SDP predates 
SIP. SDP stands for Session Description Protocol, while SIP stands for 
Session Initiation Protocol. I don't think it is a coincidence that they 
both use *session* in their name, and for the most part we should assume 
that they intend to mean the same thing by it.

So SIP initiates sessions by exchanging their descriptions.

> So, the questions is whether an INVITE initiated dialog MUST contain media.
> 

Yes, I think that is the way it is.

If you look back at 2543, it said that you distinguished whether a 
request contained an offer or not by whether the body contained an m= 
line. That got pretty ugly, and certainly wasn't easily extensible to 
other forms of session description. So it was changed to be based on a 
the presence of a body part with Content-Disposition of session.

That change admitted the possibility of establishing a session with no 
media - via a session description that specifies no media. This is a 
degenerate case, but a potentially useful one - primarily as an 
intermediate state when it is known that communication is desired but 
the media to be used has not been decided.

	Paul