Subject: RE: [SIP] re-INVITE without SDP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2001 01:13:08 -0500

> -----Original Message-----
> From: Rick Workman [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 6:08 PM
> Cc: 'SIPbell-labs (E-mail)'
> Subject: Re: [SIP] re-INVITE without SDP
> 
> 
> 
> Indeed, which means you can't have a SIP session without SDP 
> described media,
> e.g., an instant messaging session where the endpoints just 
> exchange MESSAGE
> requests. Is this really the intent?
> 
> We've had this discussion at least twice over the last year, 
> and I'm still
> trying to figure out why it's desirable to reply with SDP to 
> an INVITE without
> SDP. Apologies if I've missed the response to my earlier 
> (Dec.) posting.

Since the rfc itself, there have been two ways defined to exchange SDP.
Either:

1. SDP in the invite, SDP in 200 ok, no SDP in ACK
2. no SDP in the invite, SDP in the 200 OK, SDP in the ACK

thats it. (2) was needed initially for h.323v1 interoperability, and is
widely used in that context. It has uses for third party call control, which
have been documented in the 3pcc draft.

Note also that with the results of the discussions at IETF on messaging,
messaging will be setup as a session with INVITE, and so session timer to
keep alive a messaging session will, in fact, need SDP, as for any other
media type (or sdpng, or whatever).

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Rick Workman" <[email-masked]>
Date: Thu, 29 Mar 2001 10:02:30 -0500

> 2. no SDP in the invite, SDP in the 200 OK, SDP in the ACK

I'm afraid I can't find the reference. The closest I get is:

B.4 Delayed Media Streams

   In some cases, a caller may not know the set of media formats which
   it can support at the time it would like to issue an invitation. This
   is the case when the caller is actually a gateway to another protocol
   which performs media format negotiation after call setup. When this
   occurs, a caller MAY issue an INVITE with a session description that
   contains no media lines. The callee SHOULD interpret this to mean
   that the caller wishes to participate in a multimedia session
   described by the session description, but that the media streams are
   not yet known. The callee SHOULD return a session description
   indicating the streams and media formats it is willing to support,
   however. The caller MAY update the session description either in the
   ACK request or in a re-INVITE at a later time, once the streams are
   known.

but I interpret no media lines as different from no SDP. This text is still
retained in bis-02. Is INVITE with no SDP implying a media session covered in
some other section?

> have been documented in the 3pcc draft.

From my posting last year:

There seem to be three proposals I've seen so far which attach some meaning to
no SDP content:

1. 3pcc - Controller uses an INVITE with no SDP to "entice" a UA to provide
sufficient media content information so that a call can be set up to another UA
independent of the controller. In fact, it appears that the UA has to offer a
media description of every kind it can support so the the controller can pick
one
it likes. IMO, it'd be a rare case where the controller didn't have some idea of

what kind of media session it wanted to establish. It does not have the other
media endpoint yet, so it can put the media on hold until it does receive it. (A

previous thread on the list seemed to establish that a UA responds to
media-on-hold with a valid media description of what it's prepared to receive.)
The controller also doesn't know what codecs the other UA can support; if this
is
important, it should use OPTIONS to find out (bis-4.2.3) . Once the INVITE
response has been received from the second UA has been received, the full media
path can be extablished. Whether this happens in the ACK or a subsequent INVITE
is
debatable; I'd prefer the re-INVITE to keep it clean, but it's a much lower
priority nit than attaching semantics to no SDP.

2. H.323 gateways - I'm not up on H.323 gateway thinking so not quite sure what
the issue is here. Does it reduce to the same issue as 3pcc? Or is it just an
ACK
vs. reINVITE discussion?

3. Implied off-hold - Unless I missed something, there seems to be consensus
that
this isn't a good idea given that there's already a recommended way to do this -
a
non 0.0.0.0 connection address.

Any others?

It's hard (and getting harder all the time) to imagine a use of SIP that doesn't

include SDP, but I believe the original intent was to separate media description

from control, so SIP could be used to control sessions of any kind. Defining
semantics for the absence of something (SDP bodies) makes this somewhat
difficult.

> media type (or sdpng, or whatever).

Not sure I understand this or, for that matter, why IM *always* must establish a
session, but that's another discussion. The real question is whether we can
continue to separate SIP as a session control protocol from the session content
which may or may not be described using SDP, or is this just hopelessly
idealistic?

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 29 Mar 2001 15:11:50 -0500

> I'm afraid I can't find the reference. 

<snip> 

> Is INVITE with no SDP implying a media session 
> covered in some other section? 

It has been in section "4.2.1 INVITE" of 
the bis since August 1999.

<snip>
   
> There seem to be three proposals I've seen so far 
> which attach some meaning to no SDP content: 
> 1. 3pcc 
> 2. H.323 gateways
> 3. Implied off-hold 

All three share the same meaning: 
I wish to communicate; I'll provide my 
body (SDP) in the ACK.
 
> semantics for the absence of something (SDP bodies) 
> makes this somewhat difficult. 
  
Nothing has changed; the body is not 
required to be SDP.  The call will be 
released if the content-type of the 
INVITE's 200 response was not 
supported.  However using SDP would be 
encouraged unless the INVITE contained 
an Accept header listing other session 
descriptors.

---

From: "Rick Workman" <[email-masked]>
Date: Fri, 30 Mar 2001 09:22:00 -0500

> the bis since August 1999.

You're right,although this text isn't in the RFC, so this appears to be another
source of upwards incompatibility.

> I wish to communicate; I'll provide my

Although I'd argue that, with the possible exception of the H.323 gateway,
there are better ways. And I'm still not sure why it's required for H.323,
other than a possible optimization. I guess the idea of wanting to establish a
session but providing absolutely no information on the purpose bothers me;
perhaps because I view a session as a very general purpose thing.

> an Accept header listing other session

I think this is too strong, but maybe I'm just being religious. SDP may be the
preferred way of establishing media sessions, but why can't a SIP session be
more general than that. Implied SDP and similar concepts should be part of a
profile of usage rather than mandated by the base protocol. However, I appear
to be in the minority on this, so lets move on.

Rick