Subject: RE: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invi te response]

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Dec 2000 13:11:54 -0500

Hmm.

The problem is that we allow INVITE with no SDP, and it appears this is used
quite a bit (note the massive flames to my suggestion to remove it). Since
we allow it in an initial INVITE, we need to allow it in a re-INVITE. So,
the question becomes, what is its meaning? 

I think the initial thinking was that re-INVITE with no SDP means "no
change" in SDP. However, this breaks the idempotency of SIP, and is probably
a bad thing. The other alternative is that no SDP means no media. This is
consistent with its usage in initial INVITE today with H.323v1 gateways, an
makes it idemopotent for re-INVITEs. We can signal a "no-change" in SDP by
including the SDP we included in the previous message, with the same version
ID and all. If the last message had no SDP, meaning no media, then you would
still continue to signal no-change, and thus no media, with no SDP.

No m lines is something that has caused a lot of confusion. In the beginning
of section 6, the m line is not listed as optional (no star). The text
slightly above says there can be zero or more media descriptions. I believe
what this means is that if a media description is present, there must be an
m line, but media descriptions need not be present. However, I think many
folks assume there will be an m line. Thus, the INVITE with media-on-hold
made sure there was an m line, but had the same effect as if there was none.

-Jonathan R.

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, December 03, 2000 10:20 AM
> To: Brett Tate
> Cc: Sip Mail List
> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the
> re-invite response]
> 
> 
> I believe that the simple set of rules should be
> 
> - always send SDP in INVITE and 200
> 
> - if you don't know the media yet, don't include m lines. That is
> perfectly legal according to RFC 2327:
> 
>   "Zero or more media descriptions (see below)"
> 
> - Use the normal "0.0.0.0 means hold" (I had mis-spoken about ports)
> 
> - if you want to find out what the other side can do, but without
> changing things, use OPTIONS (this is needed anyway, since you need to
> find the whole set; no-SDP doesn't cover this)
> 
> This is much closer to the spirit of soft-state and
> always-send-full-state that underlies other Internet 
> protocols. Clearly,
> the spec needs to spell this out more explicitly. This is also much
> simpler since it integrates hold and normal media 
> changes/additions into
> one mechanism, rather than two.
> 
> Whether we need to address what end system should do if senders don't
> conform is a separate issue.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

---
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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 05 Dec 2000 13:25:22 -0500

> quite a bit (note the massive flames to my suggestion to remove it). Since

I thought the flames were about disallowing SDP in ACKs, not about "no
SDP". Obviously, ACK doesn't have SDP most of the time. 

> still continue to signal no-change, and thus no media, with no SDP.

The problem is that while this definition is consistent with the initial
INVITE (and subsequent ones), it doesn't quite work for ACK. At the very
least, I would like to strongly discourage 'no SDP' in INVITE and 200,
as it avoids these issues.

> made sure there was an m line, but had the same effect as if there was none.

The text below seems pretty clear:

   An announcement consists of a session-level section followed by zero
   or more media-level sections.  The session-level part starts with a
   `v=' line and continues to the first media-level section.  The media
   description starts with an `m=' line and continues to the next media
   description or end of the whole session description.  In general,
   session-level values are the default for all media unless overridden
   by an equivalent media-level value.

Later on pg. 7 (below a=*)
   Zero or more media descriptions (see below)

   Media description
   m= ...

Thus, the whole thing (m and following) lines is optional. Within a
media section, obviously m= cannot optional (there wouldn't be one
then).

Thus, I don't see the problem. Not allowing zero of an enumeration is
generally a very bad idea.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Vladislav Zubarev <[email-masked]>
Date: Tue, 05 Dec 2000 12:50:02 -0800

What difference does it make whether we send an INVITE with no SDP at all or
an SDP with no lines ?
I guess the purpose of SDP for the most part is to advertise the codecs party
supports and RTP ports (and of course connection address as well).
So if we do not send SDP in INVITE or send SDP with no media lines, then in both
cases we should advertise our codecs and RTP ports later - either in ACK or in
re-INVITE.

What's the point then to send SDP with no m lines ?
And I guess the understanding of section 6 by most people was exactly as
no SDP in INVITE (not as SDP without m lines).

I completely agree with Jonathan in the meaning of re-INVITE with no SDP
as no media and indication of "no change " by including the same SDP as last
one we sent.

Thanks.

--
Vladislav Zubarev        mailto:[email-masked]
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org

---

From: Sean Olson <[email-masked]>
Date: Tue, 05 Dec 2000 15:45:44 +0100

Then why make the differentiation between the procedure for a re-INVITE
and the initial INVITE. If we accept that a re-INVITE with no SDP means
no media, then an initial INVITE with no SDP should take on the same
meaning. IMO, this is easier to implement because of the consistency.

/sean
--
Sean Olson <[email-masked]>

Vladislav Zubarev wrote:

> cases we should advertise our codecs and RTP ports later - either in
> ACK or in re-INVITE.
>

---

From: "Rick Workman" <[email-masked]>
Date: Tue, 05 Dec 2000 17:34:36 -0500

As per a previous discussion on this list, I favour the sematics that says no SDP
means "no change". I may be misunderstanding something, but it's hard to imagine a
more idempotent operation than one which does nothing. 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.
(However, this is not an excuse for not specifying the UA SDP processing
algorithm, as suggested in an earlier posting to this thread - this is a very good
idea.)

Rick Workman
Nortel Networks

---

From: Sean Olson <[email-masked]>
Date: Tue, 05 Dec 2000 16:39:28 +0100

How can a request which differs in something as vital as the session
description (SDP)
be considered idempotent? If you don't want to indicate a change, then
don't change
the request. Whatever semantics you associate with no SDP should be
consistently
applied across INVITEs and re-INVITEs. Or perhaps I don't understand
your
comments(?)

/sean

Rick Workman wrote:

> As per a previous discussion on this list, I favour the sematics that
> says no SDP means "no change". I may be misunderstanding something,
> but it's hard to imagine a more idempotent operation than one which
> does nothing. There seem to be three proposals I've seen so far which
> attach some meaning to no SDP content:

---

From: Vladislav Zubarev <[email-masked]>
Date: Tue, 05 Dec 2000 15:20:50 -0800

Completely agree - in my opinion both INVITE and re-INVITE should have the

same meaning in relation to SDP: no SDP - no media at all, no change in
SDP compared to the
previous one - no change in media. Looks simple and consistent.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 05 Dec 2000 21:37:50 -0500

> cases we should advertise our codecs and RTP ports later - either in

Indeed. If we can agree on "no SDP - no media" (sounds like a good
placard to wave...), we would not need SDP without m lines, although
systems should be able to handle this as being equivalent. I would
prefer a single way of saying "no media", but it's probably too late for
that.

> as no media and indication of "no change " by including the same SDP

Also, this is trivial to detect at the receiver, without doing a
byte-by-byte comparison, as the version number in the o= line will be
the same.

---

From: Vladislav Zubarev <[email-masked]>
Date: Tue, 05 Dec 2000 18:10:36 -0800

Sorry, with this approach - we have to differentiate between initial
INVITE and re-INVITE:
no SDP in initial INVITE - we'll send SDP in ACK
no SDP in re-INVITE - no media.

Vladislav Zubarev wrote:

> same meaning in relation to SDP: no SDP - no media at all, no change
> in SDP compared to the
>> > What difference does it make whether we send an INVITE with no SDP
>> at
>> > all or
>> > an SDP with no lines ?
>> > So if we do not send SDP in INVITE or send SDP with no media
>> lines,
>> > then in both
>> > And I guess the understanding of section 6 by most people was
>> exactly
>> > as
>> > I completely agree with Jonathan in the meaning of re-INVITE with
>> no
>> > SDP
>> > as no media and indication of "no change " by including the same
>> SDP
>> > as last
>> > one we sent.
>> >
>> > Thanks.
>> >
>> >> > The problem is that we allow INVITE with no SDP, and it appears
>>
>> >> this is used
>> >> > quite a bit (note the massive flames to my suggestion to remove
>>
>> >> it). Since
>> >>
>> >> I thought the flames were about disallowing SDP in ACKs, not
>> about
>> >> "no
>> >> > I think the initial thinking was that re-INVITE with no SDP
>> means
>> >> "no
>> >> > change" in SDP. However, this breaks the idempotency of SIP,
>> and
>> >> is probably
>> >> > a bad thing. The other alternative is that no SDP means no
>> media.
>> >> This is
>> >> > makes it idemopotent for re-INVITEs. We can signal a
>> "no-change"
>> >> in SDP by
>> >> > including the SDP we included in the previous message, with the
>>
>> >> same version
>> >> > ID and all. If the last message had no SDP, meaning no media,
>> then
>> >> you would
>> >> INVITE (and subsequent ones), it doesn't quite work for ACK. At
>> the
>> >> very
>> >> least, I would like to strongly discourage 'no SDP' in INVITE and
>>
>> >> 200,
>> >> > No m lines is something that has caused a lot of confusion. In
>> the
>> >> beginning
>> >> > of section 6, the m line is not listed as optional (no star).
>> The
>> >> text
>> >> > slightly above says there can be zero or more media
>> descriptions.
>> >> I believe
>> >> > what this means is that if a media description is present,
>> there
>> >> must be an
>> >> > made sure there was an m line, but had the same effect as if
>> there
>> >> was none.
>> >> >
>> >>
>> >>    An announcement consists of a session-level section followed
>> by
>> >> zero
>> >>    or more media-level sections.  The session-level part starts
>> with
>> >> a
>> >>    `v=' line and continues to the first media-level section.  The
>>
>> >> media
>> >>    description starts with an `m=' line and continues to the next
>>
>> >> media
>> >> Thus, I don't see the problem. Not allowing zero of an
>> enumeration
>> >> is

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 06 Dec 2000 15:12:38 +0100

> What difference does it make whether we send an INVITE with no SDP at

In initial INVITE:

No SDP
    the other guy should propose a set of media streams
SDP but no m= lines
    a session is being set up in which there is initially no media
streams. This can be changed with re-INVITEs, but the callee CANNOT add
m= lines to the response.

In re-INVITE: 

No SDP
    well, that's what the argument is about
SDP but no m= lines
    ordinary re-INVITE (legal only when no streams have been set up)

I can see how no SDP in initial INVITE can be said to mean "no change",
it's more of a stretch to say it means "put on hold" (or "take off hold"
as ironically it was at the beginning of this thread).

> What's the point then to send SDP with no m lines ?

Maybe there's an intent to set up media streams later. Maybe two
endpoints just want to establish a signaling relationship early so that
they know they're there. Maybe to test signaling without worrying about
media. Doesn't really matter - it's a simple generalization of how SIP
uses SDP and should be allowed.

--
Anders Kristensen

---

From: "Rick Workman" <[email-masked]>
Date: Wed, 06 Dec 2000 09:34:02 -0500

Not sure I understand your point. An idempotent operation can be applied
more than once with no subsequent effect after the first application.. The
semantics I'm supporting is no SDP means no change to the media state.

For the first INVITE, there's no media prior to the transaction, so there's
no change. A re-INVITE with no SDP and prior media results in no change -
prior media doesn't go away. Feels consistent to me.

Rick

---

From: Sean Olson <[email-masked]>
Date: Wed, 06 Dec 2000 09:08:04 +0100

An idempotent operation is one in which *identical* requests
can be applied successively with no subsequent effects.

If you send an initial INVITE with SDP, then a re-INVITE with
no SDP, these are not idempotent.  This was my point.

Of course, sending an INVITE with no SDP, followed by
another INVITE with no SDP is consistent.

/sean

---

From: "Rick Workman" <[email-masked]>
Date: Wed, 06 Dec 2000 10:38:43 -0500

> no SDP, these are not idempotent.  This was my point.

But I don't consider these identical requests - one has SDP and the other
doesn't.