Subject: SDP syntax with RTSP

From: Rob Lanphier <[email-masked]>
Date: Sun, 07 Sep 1997 14:54:16 -0700

One way to distinguish between client redirection and multi-server proxying
is to use the global "c=" when the server is volunteering to proxy requests
and to provide a cohesive session, and to use *only* media-level "c=" lines
when the client is to be redirected to destinations unknown.

For example, this is the syntax when all requests are being coordinated
through a proxy:

C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1

S->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      c=IN URL rtsp://proxy.com/twister   # aggregate URL 
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://audio.server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://video.server.com/twister/video

...whereas this is what the interaction looks like with the client is
expected to go elsewhere to do SETUP/PLAY:

C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1

S->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://audio.server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://video.server.com/twister/video

This is very similar to what Anup first proposed in draft03, but seems to
have slipped through the cracks.  I think part of the problem with this
syntax is that it does go against the current notion that the media-level
connection fields are supposed to entirely override the session-level
connection field, if I'm reading SDP correctly.

Thoughts?
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: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Sep 1997 22:55:53 -0400

What's wrong with having an explicit field for a proxy? Why are we
constraining ourselves to overloading and implicit semantics, given that
backwards compatibility is not an issue? I'm uncomfortable with
violating the 'override' rule just for RTSP URLs, since this override
may also be desirable in some circumstances. Purely from a manual
authoring perspective,

a=proxy:rtsp://proxy.com/twister

and then normal c= for the individual streams seems far more obvious to
the reader (and writer).

Regarding DESCRIBE and recursion thereof:

A suggested set of rules to limit recursion:

1) If an SDP description retrieved (typically by non-RTSP means)
contains just a global c= RTSP URL, issue a DESCRIBE request on that URL
to get more details.

2) If an SDP description retrieved via RTSP contains per-media stream
RTSP URLs, no DESCRIBE is necessary unless indicated by a parameter,
e.g., a:rtsp=DESCRIBE . If the c= RTSP URL is the same as that used to
get the description, the client should stop as well (to avoid
inadvertent looping when the description has an extraneous
a:rtsp=DESCRIBE).

3) One can debate whether certain media formats imply the need for a
DESCRIBE. If the client knows that encoding FOO needs parameters, it
might do a DESCRIBE for a stream without being told explicitly. This
doesn't seem necessary, as I would assume that in almost all cases,
these encodings have a default set of parameters, so that this may just
add additional work without increasing functionality.

Henning

---

From: Rob Lanphier <[email-masked]>
Date: Sun, 07 Sep 1997 20:52:23 -0700

Henning's proposal sounds very reasonable to me.  

To give examples of what he just said (correct me if I'm wrong), the
following is an example where a coordinating proxy will be used:

S->C: RTSP/1.0 200 1 OK

      v=0

S->C: RTSP/1.0 200 1 OK

      v=0

In both cases above, the media initialization phase is complete (no more
DESCRIBEs necessary, though there are no rules against this).  A
description that would force another DESCRIBE to happen would be:

S->C: RTSP/1.0 200 1 OK

      v=0
      a=rtsp:DESCRIBE
      a=rtsp:DESCRIBE

This last example seems a bit awkward, but I think that's just syntax and
not conceptual.   Having a parameter named "rtsp" bugs me a bit, but I
don't have a better name just yet.

I think that that name is the least of our worries.  Are the first two
examples things that folks can live with?  If so, I'd like to ship out a
version of the draft this week with this solution in it.  If you object,
please do so before Wednesday.

One final note, which is preferrable?

a=aggregate:rtsp://proxy.com/twister   
..or..
a=proxy:rtsp://proxy.com/twister   

The former makes more sense when the URLs actually point to different
machines.  The latter makes more sense in the following example:

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      a=aggregate:rtsp://server.com/twister   
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://server.com/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://server.com/twister/video

This gives us an unambiguous way of specifying the desire to do aggregate
control.

Rob

---

---

From: Stephen Casner <[email-masked]>
Date: Sun, 7 Sep 1997 23:30:34 -0700 (PDT)

> Henning's proposal sounds very reasonable to me.  

Whoa, I don't think any of this extra mechanism is needed.  After all,
we're talking about an atypical situation.

If redirection is not allowed in the DESCRIBE, then you don't need the
proxy attribute because it is implicit that the opaque URLs get sent
to the same place whence the DESCRIBE came.  If redirection is allowed
and the host that sent the DESCRIBE is the one that is going to
provide control, then the URLs should start with its hostname.  The
remainder of the URL tells where the data comes from, in any format
that is legal and meaningful to the proxy.  The client doesn't need to
know that proxying is going on, and should not be required to take any
other special action.  (I think I've been making this argument
before in a slightly differnt context.)

I don't see that the a=rtsp:DESCRIBE is needed, either.  When you
start an interaction with an RTSP server, you do a DESCRIBE.  If that
session description redirects you to another RTSP server (assuming
we've made that choice), then you do another DESCRIBE on that new RTSP
session.  If it doesn't, you don't.

To guard against looping, you'd either need to look for passing
through the same node twice, or establish a maximum count, just as in
other indirection schemes.
							-- Steve

---

From: Mark Handley <[email-masked]>
Date: Mon, 08 Sep 1997 10:15:00 -0400

>when the client is to be redirected to destinations unknown.

I really don't like this idea - I don't think this is in the spirit of
the SDP semantics or the letter of them.

Mark

---

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

My biggest problem with this (as I said in Munich) is the concern for
how you use the resulting SDP for an invitation (SIP).

Something has to keep the mapping of c=URL_stuff and
c=ip_address_stuff so that you can invite other entities.

This would of course be easier if SDP seperated media from transport,
but that's a done deal for now... we work with what we have.

|One way to distinguish between client redirection and multi-server proxying
|is to use the global "c=" when the server is volunteering to proxy requests
|and to provide a cohesive session, and to use *only* media-level "c=" lines
|when the client is to be redirected to destinations unknown.
|
|For example, this is the syntax when all requests are being coordinated
|through a proxy:
|
|C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1
|
|S->C: RTSP/1.0 200 1 OK
|      Content-Type: application/sdp
|      Content-Length: 164
|
|      v=0
|      o=- 2890844256 2890842807 IN IP4 172.16.2.93
|      s=RTSP Session
|      i=An Example of RTSP Session Usage
|      c=IN URL rtsp://proxy.com/twister   # aggregate URL 
|      t=0 0
|      m=audio 0 RTP/AVP 0	
|      c=IN URL rtsp://audio.server.com/twister/audio
|      m=video 0 RTP/AVP 26
|      c=IN URL rtsp://video.server.com/twister/video
|
|...whereas this is what the interaction looks like with the client is
|expected to go elsewhere to do SETUP/PLAY:
|
|C->S: DESCRIBE rtsp://proxy.com/twister  RTSP/1.0 1
|
|S->C: RTSP/1.0 200 1 OK
|      Content-Type: application/sdp
|      Content-Length: 164
|
|      v=0
|      o=- 2890844256 2890842807 IN IP4 172.16.2.93
|      s=RTSP Session
|      i=An Example of RTSP Session Usage
|      t=0 0
|      m=audio 0 RTP/AVP 0	
|      c=IN URL rtsp://audio.server.com/twister/audio
|      m=video 0 RTP/AVP 26
|      c=IN URL rtsp://video.server.com/twister/video
|
|This is very similar to what Anup first proposed in draft03, but seems to
|have slipped through the cracks.  I think part of the problem with this
|syntax is that it does go against the current notion that the media-level
|connection fields are supposed to entirely override the session-level
|connection field, if I'm reading SDP correctly.
|
|Thoughts?
|Rob
|

---

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

js

---

From: Jeff Smith <[email-masked]>
Date: Mon, 08 Sep 1997 08:13:29 -0700

Yes.

|> Henning's proposal sounds very reasonable to me.  
|
|Whoa, I don't think any of this extra mechanism is needed.  After all,
|we're talking about an atypical situation.
|
|If redirection is not allowed in the DESCRIBE, then you don't need the
|proxy attribute because it is implicit that the opaque URLs get sent
|to the same place whence the DESCRIBE came.  If redirection is allowed
|and the host that sent the DESCRIBE is the one that is going to
|provide control, then the URLs should start with its hostname.  The
|remainder of the URL tells where the data comes from, in any format
|that is legal and meaningful to the proxy.  The client doesn't need to
|know that proxying is going on, and should not be required to take any
|other special action.  (I think I've been making this argument
|before in a slightly differnt context.)
|
|I don't see that the a=rtsp:DESCRIBE is needed, either.  When you
|start an interaction with an RTSP server, you do a DESCRIBE.  If that
|session description redirects you to another RTSP server (assuming
|we've made that choice), then you do another DESCRIBE on that new RTSP
|session.  If it doesn't, you don't.
|
|To guard against looping, you'd either need to look for passing
|through the same node twice, or establish a maximum count, just as in
|other indirection schemes.
|							-- Steve
|
|

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 08 Sep 1997 11:19:24 -0400

> session.  If it doesn't, you don't.

The base assumption always was that DESCRIBE is optional and that the
default mode is that you don't need it. In many cases, it is completely
superfluous (e.g., you get an SDP description of a session completely
described in SDP via HTTP). In many cases, the description returned by
HTTP and DESCRIBE will be exactly the same file in any event, residing
on the same shared file system. Requiring a DESCRIBE just adds latency,
server and client processing to the process.

> other indirection schemes.

I spec'ed the first option; the second is probably a good back-up for
loops of length > 1.

-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 08 Sep 1997 08:48:24 -0700

>c=ip_address_stuff so that you can invite other entities.

Ultimately, it will be up to the client that wants to use the SDP in SIP to
do the necessary translation.  I don't see how it is possible to avoid this
situation, especially given that we are under the constraint of the client
potentially picking the multicast address.  Any suggestions? :)

>but that's a done deal for now... we work with what we have.

Yes.  I think the ultimate answer is going to be to define a new media
description language, but we realized we needed to retrofit SDP into RTSP
first and get some experience with it before we rush off and create a new
thing (should we need to).  

Rob

---

---

From: Karl Auerbach <[email-masked]>
Date: Mon, 8 Sep 1997 12:13:09 -0700 (PDT)

> when the client is to be redirected to destinations unknown.

This method really bothers me.  The c= is one of those things that, if it
appears at session level, is effectively a default for the various media.

Your proposal gives it a different meaning and, perhaps more importantly, 
scoping.

I'd suggest not overloading c=

		--karl--

---

From: Rob Lanphier <[email-masked]>
Date: Tue, 09 Sep 1997 02:28:35 -0700

At 11:30 PM 9/7/97 -0700, Stephen Casner wrote:
>to the same place whence the DESCRIBE came.

...which actually, from PN's perspective would be great, actually.  If we
could count on a server to aggregrate all URLs which it spits out in a
DESCRIBE response, we would be happy campers.

I'm a bit worried, though, about having context-sensitive SDP, where the
exact same SDP coming from two different sources (one from an HTTP server
and one from an RTSP server) actually mean two different things.  If we
plan to allow SDP as a metafile (which several folks have expressed
interest in doing), I'd prefer to have a way of distinguishing the
indirection that necessarily goes on there from the same-server
initialization that goes on in SDP.

I also think that we do need some way of specifying aggregate control
(1-1-n), vs. a 1-n-n scenario.  Thus, Henning's suggestion (or a varient
thereof) seemed pretty reasonable:

      v=0

I feel sort of silly arguing this side of the case, though, because doing
1-n-n is something PN has no desire to do, and so in trying to make that
possible, I'm not making life any easier on our engineers.  Because of
this, I'm very inclined to agree with you, Steve, because what you tend to
point out here is how to do the 99% case (server doesn't DESCRIBE something
it isn't ready to serve).

So, the questions we need to ask ourselves:

*  Is SDP suited to metafile/indirection use as well as media initialization?
*  Do we wish to be able to specify both 1-1-n and 1-n-n in the RTSP/SDP
DESCRIBE response?

If both of these answers are "yes", then it's pretty clear we need at least
one, if not two mechanisms.  If we are willing to let these go, we can
avoid introducing extra SDP mechanisms.

Rob

---

---

From: Dave Singer <[email-masked]>
Date: Tue, 9 Sep 1997 08:42:36 -0700

I'm not happy that we fully understand all the issues around having
sessions which are served through different RTSP servers (sync. is one that
bugs me, for example). I'd be most happy with a spec which has enough room
to allow this to happen in future, while not requiring it now. To that end,
how about saying that in this version of the spec, it is an error for the
media URLs to address a host other than the originating RTSP host.

Note that this does NOT stop the RTSP hist from being a co-ordinator for
multiple stream servers (Though we need to be careful what IP address the
RTCP goes to for each stream).

David Singer
Apple Computer/IMG 408-974-3162

---

From: Stephen Casner <[email-masked]>
Date: Tue, 9 Sep 1997 23:51:39 -0700 (PDT)

On Mon, 8 Sep 1997, Henning Schulzrinne wrote:
> default mode is that you don't need it.

OK, so before you proposed a=rtsp:DESCRIBE, how was it that you would
decide when to do a DESCRIBE?

On Tue, 9 Sep 1997, Rob Lanphier wrote:
> and one from an RTSP server) actually mean two different things.

OK, fine, I share that worry.  So, that means SETUPs get sent where
the host portions of the RTSP URLs in the DESCRIBE say.  And, as I
said in the summary message I sent on Saturday, this means the
aggregate URL is not really a promise of aggregate control unless the
URLs do point to the same host.

> If we

I'm not sure I understand you here.  You can tell whether indirection
is occurring by the host portion of the URL being different.  But I do
see that when SDP is used as a metafile (e.g., fetched via HTTP), then
there is no aggregate RTSP URL, whereas in the RTSP case that
aggregate URL is what gets the operation started.  So, I guess that's
what you were getting to next:

...
>       c=IN URL rtsp://server.com/twister/video

We can add an aggregate URL in the session global information like
this, but I think the format should be consistent for the aggregate
and media URLs.  There have been strong objections, which I agree
with, to using the session global c= for this purpose.  In fact, as I
stated in an earlier message, I don't think we should put the URL on
the c= line for the per-media URLs either.  Nobody has commented on
that part of my message, but I confirmed in private email with Jeff
Smith today that this is the point of his message yesterday to
confctrl, too.  He says:

    Exactly.  The 'c' field is supposed to be for IP addresses and
    putting URLs is overloading it and creates potential problems in
    other cases (SIP as an example).

    My model is to use an 'a' field if necessary for RTSP URLs, etc.

This is in fact a better argument than the ones I mentioned.  And if
we use an 'a' field, then we can be consistent here between the
aggregate URL and the per-media URLs.

Precept has made a local extension to SDP to control the media source
for multicast video servers playing scheduled programs:

    a=source: <server> live
    a=source: <server> screen
    a=source: <server> file <list of files> [loop]

Something similar (choose a keyword) could be used to specify the URL:

    a=source-url: rtsp://server.com/twister/video

This could appear in both the session-global section of an SDP
metafile to supply the aggregate URL as well as in the per-media
sections.

> it isn't ready to serve).

What I was arguing at length about before Munich was to make sure
n-1-n would work as well as 1-1-n (I think, if I'm getting the
nomenclature right).  A client can always elect 1-n-n by doing
separate RTSP sessions for each medium, and the server can refuse with
the "Only aggregate control" error response.

> media URLs to address a host other than the originating RTSP host.

I don't think we need to take this step.  Clients that don't want to
implement their own coordination of streams coming from separate
servers can readily determine (from the host portions of the per-media
URLs being different) when a session requires it, and can put up an
error message or take other appropriate action.  If important clients
take this stand, then authors won't create sessions using separate
servers.  But the protocol need not legislate one way or the other.

> RTCP goes to for each stream).

The transport information in the SETUP will tell where the media will
come from and hence where the RTCP should be returned to.

							-- Steve

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 10 Sep 1997 10:12:17 -0400

> decide when to do a DESCRIBE?

Initially, DESCRIBE was just for per-stream initialization information,
so my assumption was that the client knew from the media type that it
needed additional information. If it got PT=0 (PCMU), it wouldn't
bother, if it got some proprietary format that needs external data to
get started, it would ask.

For multi-stream session descriptions that have only a global URL, the
client would also know from the lack of information on individual
streams that it needs to ask the server to DESCRIBE.

> aggregate URL and the per-media URLs.
I thought Mark had suggested the c= version; earlier informal discussion
centered around either a new letter (something I proposed a while back)
or an a= attribute. I'd like to hear Mark's side of the story...

Another argument: Is there a scenario where both RTSP URL and media
information is needed? I think a case can be made for that, e.g., for
multicast, where we could have passive clients (without RTSP capability
even), just taking c= information as is, and 'remote control' clients
that have the ability to interact with the stream via RTSP, suitably
coordinated, naturally.
 
Given the case for needing both pieces of information on occasion,
overloading c= does seem a bad idea.

Henning

---

From: Stephen Casner <[email-masked]>
Date: Wed, 10 Sep 1997 10:01:13 -0700 ()

Henning,

> streams that it needs to ask the server to DESCRIBE.

Right.  So I think a=rtsp:DESCRIBE is not needed.

> or an a= attribute. I'd like to hear Mark's side of the story...

Yes, I heard that the c=IN URL idea came from Mark.  It could be that
he was passing a brainstone on that one (an expression I heard for the
first time recently :)

I, too, would like to hear more from Mark on this.

> overloading c= does seem a bad idea.

Agreed.  I think perhaps the main reason this was suggested is that in
the typical unicast RTSP case, the address information on the c= line
is not useful (except perhaps for the count of addresses for layered
coding, as I pointed out).  So, we might want a more compact version
of the c= when no address is supplied.
							-- Steve

---

From: Jeff Smith <[email-masked]>
Date: Wed, 10 Sep 1997 10:57:21 -0700

|I thought Mark had suggested the c= version; earlier informal discussion
|centered around either a new letter (something I proposed a while back)
|or an a= attribute. I'd like to hear Mark's side of the story...

Likewise.

|
|Another argument: Is there a scenario where both RTSP URL and media
|information is needed? I think a case can be made for that, e.g., for
|multicast, where we could have passive clients (without RTSP capability
|even), just taking c= information as is, and 'remote control' clients
|that have the ability to interact with the stream via RTSP, suitably
|coordinated, naturally.

This is exactly the case I'm designing for... playing back into a
session with one (or more) controllers and one (or more) "passive"
listeners (who do not speak RTSP, nor need to).

| 
|Given the case for needing both pieces of information on occasion,
|overloading c= does seem a bad idea.
|
|Henning
|

js

---

From: Mark Handley <[email-masked]>
Date: Wed, 10 Sep 1997 17:39:30 -0400

>he was passing a brainstone on that one (an expression I heard for the

I lost a couple of weeks of mail recently, so have lost touch with the
whole RTSP discussion.  The c=IN URL idea was mine, suggested at 2am
the night before the MMUSIC meeting.  The alternative Rob was
suggesting was to have a null c= line and an attribute to give the
URL.  The null c= field was a pretty good indication that SDP was
being used badly.

The "c=IN URL..." syntax is definitely cleaner in the context Rob
described it to me.  The "c=" line gives the connection destination,
and a URL basically gives a request destination, so the usage didn't
seem too far out from the intention of the SDP field.  

But I haven't followed the DESCRIBE discussion at all, so I don't know
what the issues are.  The use of "c=IN URL" didn't seem like a great
idea, but didn't seem terrible either at the time.  Can someone
summarise for me why this might be a bad idea?

Mark

---

From: Stephen Casner <[email-masked]>
Date: Wed, 10 Sep 1997 16:22:44 -0700 ()

Mark,

> The c=IN URL idea was mine, suggested at 2am
> URL.

This is what I am suggesting again.

> The null c= field was a pretty good indication that SDP was
> being used badly.

Well, I agree there is a rough fit between SDP and RTSP that centers
on this notion of separation of media description and transport
information.  Because SDP carries both and RTSP wants them separated,
we have the friction between DESCRIBE and SETUP that has been
mentioned several times.  The description of the Transport header
field says that the presentation description may provide all the
necessary information so the SETUP doesn't need to carry the Transport
header.  Conversely, Henning has mentioned that he wants to not
require a DESCRIBE at all in cases where some session description was
provided by another means (e.g., SDP returned via HTTP) in which case
only the SETUP is done and the addressing comes from the Transport
header.

> summarise for me why this might be a bad idea?

The URL is the destination of the RTSP connection, but it is not the
destination of the media being described by the remainder of the SDP
session description.  The URL is more the source of the media, so that
was the first thing that bothered me.  This doesn't mean the idea is
terrible, but it also means the idea might not be right.

My second issue is whether other information on the c= line might
still be needed.  My example was that for layered encodings, the "/n"
suffix gives the number of layers.  Perhaps that information would go
to the Transport header, though I don't think it has been considered
yet.

Jeff Smith made a stronger point that there may be cases where you
want to include an RTSP URL in a session description that needs to
also specify a destination address.  Jeff said:

Similarly, in the remainder of Henning's message from which you were
quoting mentions another scenario where you would need both an address
and a URL in an SDP file (though maybe not in a DESCRIBE response):

    I think a case can be made for that, e.g., for multicast, where we
    could have passive clients (without RTSP capability even), just
    taking c= information as is, and 'remote control' clients that
    have the ability to interact with the stream via RTSP, suitably
    coordinated, naturally.

If we need to have both pieces of information in some uses of SDP,
then I think we want the URL information to be provided by a means
other than c= so that the URL is provided in the same way in all uses
of SDP.
							-- Steve