Subject: "c=IN URL" at media level

From: Rob Lanphier <[email-masked]>
Date: Wed, 10 Sep 1997 18:06:29 -0700

Let's back up and look at what it is that people are objecting to:

*  "c=IN URL" in the session level to signal aggregate streaming
*  "c=IN URL" in the media level to give the URL for a specific stream

The former is what I think there was the most objection to.  However, there
seems to also be an objection to the latter now, and I want to address this.

I would agree with Mark (the way I read his mail) that the former is an
overloading, and I regret suggesting it.  The latter is something that Mark
(with some hesitation) suggested to me at Munich and I latched on to.

The reason why is that the "c=" line *really* says "here's a rendezvous
point for getting this stream" (regardless of whether you call it a source
or a destination).  In the case of "c=IN IP4 <multicast address>/<params>",
this means that the rendezvous point is a multicast address that the sender
is streaming to.  This could potentially be rewritten (if you're a glutton
for punishment) as "c=IN URL multicast://224.2.0.1/ttl=127/addresses=3".

I don't want this to erupt into an argument over the virtues/errors in
having an multicast url syntax, but my point is that "c=" really does make
sense to put the URL in.  Furthermore, not using "c=" for URLs begs the
question: "if you don't put the URL in c=, what *do* you put there".

For folks who suggest that it is possible to have a useful situation where
a node can act as an RTSP client and pass through the SDP untouched to a
non-RTSP entity, please spell out that situation so that I can understand
it (preferably with examples), 'cause I'm just not getting it.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

---

From: Karl Auerbach <[email-masked]>
Date: Wed, 10 Sep 1997 21:05:40 -0700 (PDT)

I rather strongly object to overloading c=

The reason is simply that it is *not* (in my mind) a session level bit
of information at all.

Rather it is a per-media stream bit of information.

Its presence at session level is merely a convienience to provide a
default to each media stream.

Here's the language from the SDP draft about c= ...  Notice the words
"unless overridden".

	Internet Engineering Task Force					  MMUSIC WG
	INTERNET-DRAFT					  Mark Handley/Van Jacobson
	draft-ietf-mmusic-sdp-03.txt					   ISI/LBNL
								    26th March 1997
							    Expires: 26th Sept 1997

	The connection (`c=') and attribute (`a=') information in  the	session-
	level section applies to all the media of that session unless overridden
	by connection information or an	attribute of the same name in the  media
	description.

If one wants to specify some bit of information that applies to the
session as a whole, I would suggest using a purely session level
characteristic rather than trying to avoid reusing a letter.

		--karl--

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 11 Sep 1997 00:08:05 -0700

Karl,

I must not have been clear enough here.  I withdraw my suggestion to
overload "c=" at the session level for signalling RTSP stream aggregation
(1-1-n).  Let's drop this debate, because it is getting confused whether
"c=IN URL" should be used at the media level, which I'm in favor of (and
Mark seems to be as well, in lieu a good case against it).

Rob

---

---

From: Stephen Casner <[email-masked]>
Date: Thu, 11 Sep 1997 11:56:57 -0700 ()

Rob,

> Mark seems to be as well, in lieu a good case against it).

In addition to the reasons I've listed earlier for objecting to c=IN
URL, in thinking about how the various issues being discussed fit
together, I find the following reasoning:

  - Agreed that using c=IN URL at the session level is bad.

  - As in Anup's message (a reply to that shortly), we need to specify
    a presentation URL at the session level as well as stream URLs at
    the media level.

  - I would like the syntax for specifying the URLs at both level to
    be the same.

  => c=IN URL at the media level is bad.

> for punishment) as "c=IN URL multicast://224.2.0.1/ttl=127/addresses=3".

That's a nice round of semantic maneuvering, but I am unconvinced.  I
think the URL is a different kind of information than a transport
address.  That's why I mentioned the "a=source:" that Precept is
using.  I'm not suggesting that this should be adopted, but there is a
need for some SDP applications to specify what data is supposed to be
flowing over the session, e.g., to provide instruction to the server.
It's like "the other end of the connection", if you will, whether it
is a camera selection, or the file that is supposed to be streamed
out, or a file that the stream should be recorded into.  I see the
RTSP URL as being a similar requirement.

> sense to put the URL in.

I disagree because, again, I see these as two kinds of information.
Do you accept that in some instances we will want to have SDP files
that specify both addressing and file information?  Jeff Smith's
example was SIP, but another example is an SDP to tell a multicast
server what to play and where to stream it.  Now consider a generic
SDP parsing object which sees a list of c=IN IP4 lines to specify the
multicast addresses for a layered encoding, and then a c=IN URL line.
I think you'd want to have different methods for getting these two
kinds of information.  Yes, the parser can split the information apart
based on IP4 vs URL, but I think that is a level down from the point
where the split should happen.  When you're running both IP4 and IP6,
my guess is you'd want both of those to be returned by the address()
method, carrying the appropriate typing with them, but you'd want the
URL return by the source() method (there's probably a better name).

> Furthermore, not using "c=" for URLs begs the

I think that is the main reason why c=IN URL came to be.  My answer
is that there may not be anything we need to put there.  I suggest
that we have some null form of the c= line which says "you need to get
the addressing elsewhere".  Perhaps, in fact, a session-level null c=
should be the explicit indicator of an "RTSP-SDP" file that Anup's
message proposes.

> it (preferably with examples), 'cause I'm just not getting it.

That isn't necessarily the scenario I had in mind, but may be what
Jeff Smith was talking about.
							-- Steve

---

From: Rob Lanphier <[email-masked]>
Date: Fri, 12 Sep 1997 11:44:45 -0700

Steve,

I guess I'm ok with your reasoning, but I'd like Mark's input.  My
hesitations is that I'm wondering if there are there precedence problems
with having both an RTSP URL, and a direct connection multicast address.

Rob

---

---

From: Mark Handley <[email-masked]>
Date: Fri, 12 Sep 1997 15:05:21 -0400

>with having both an RTSP URL, and a direct connection multicast address.

I haven't been able to devote as much time to following this issue as
I'd like, but it seems like this is the first strong case in a couple
of years for adding a new SDP *field* defined to mean a per-media
control channel.  Probably we could change the SDP spec to allow
either a control channel, a data channel or both to be allowed, so
that RTSP doesn't need to include a null "c=" field when the control
channel is used to give the data channel parameters.

There may be some issues here with the standards track process, but I
don't think this should be a big deal so long as the RTSP spec
indicates which version of SDP is assumed.

I haven't though through this properly, so don't know what the syntax
should be though.  Suggestions?

Mark

---

From: Stephen Casner <[email-masked]>
Date: Fri, 12 Sep 1997 15:28:27 -0700 ()

Rob,

> My hesitations is that I'm wondering if there are there precedence problems

I don't think there is a problem with precedence in the SDP file
itself, because they are two different kinds of information.  There is
a question of precedence between the c= address and the SETUP
transport address.  However, the same question of precedence exists
between the m= port number and the SETUP port number, so it's not a
new problem.  The SDP spec needs to say.
							-- Steve

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 14 Sep 1997 21:09:52 -0400

Rob Lanphier wrote:

> it (preferably with examples), 'cause I'm just not getting it.

Virtual couch: Most everybody listens to a standard SDP-based
"conference" announcing the Friday night movie. The description also
contains a control (RTSP) line. Clients that understand this line can
use it to "remote-control" the movie, appropriate permission and "floor
control" assumed.

Virtual classroom based on video library: Same, except VCR control is
held by instructor (with RTSP authentication). Students just ignore the
RTSP part.

Henning

---

From: Jeff Smith <[email-masked]>
Date: Mon, 15 Sep 1997 09:08:37 -0700

|Rob Lanphier wrote:
|> 
|
|> For folks who suggest that it is possible to have a useful situation where
|> a node can act as an RTSP client and pass through the SDP untouched to a
|> non-RTSP entity, please spell out that situation so that I can understand
|> it (preferably with examples), 'cause I'm just not getting it.
|

[ Henning's two examples plus our system: ]

Playback into collaborative session.  One person is the chair, but the
chair can pass - all participants are given the info to join the
(playback) session plus the necessary control (RTSP).  Basically
Henning's "virtual couch."  Of course you could pass around the RTSP
info as part of the floor control protocol if there is one (in our
case it is just informal spoken floor control for now).

js

---

From: Jeff Smith <[email-masked]>
Date: Wed, 17 Sep 1997 09:20:42 -0700

What is the concensus on using m=control ... to convey the RTSP
information?

The spec says "conference control channel", but...

js

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 17 Sep 1997 10:00:40 -0700

>The spec says "conference control channel", but...

In the brand new spec (sent to Cynthia about 5 minutes ago), we have it as
a=control.  I hope that was what everyone wanted :)

Rob

---

---

From: Stephen Casner <[email-masked]>
Date: Wed, 17 Sep 1997 11:39:55 -0700 ()

> a=control.  I hope that was what everyone wanted :)

Yes, m=control would not work because we need a URL for each m=audio,
video, etc. line.
							-- Steve