Subject: Indirection, aggregation in SDP/RTSP - reaching closure

From: [email-masked] (Anup Rao)
Date: Wed, 10 Sep 1997 20:22:32 -0700

This is an attempt to reach closure on this issue. It takes into account
the considerable discussion that has been there on this, and
conversation between the authors. I've also tried to reference and/or
answer specific points made on confctrl.

The words Stream/Presentation are as defined by RTSP, the terms
media-level and session-level are as defined by SDP.

Something up front : I've not used "c=IN URL"  since that is under
debate, but a a= attribute to specify this. This may change, but
hopefully we can iron out the indirection and aggregation issues
independantly.

Introduction :

Within an SDP description, we want to convey:-
a) That RTSP control is to be applied.
b)streams comprising the presentation and possibly media  initialization
info for each of them
c)URL(s) to be used for each stream.
d)Aggregate URL if aggregate control is possible
e)Whether to use one RTSP session or not.(ie 1-1-n vs 1-n-n)

One thing I would like to add to this list :
-Have a session-level attribute that would specify that this is a
description for a RTSP presentation. We refer to such a description as a
RTSP-SDP description. Without exception, this specifies a RTSP
presentation. This would help us differentiate it from the case where
RTSP urls were present in SDP files in some other situation, for eg.
when only one of many media within a session used RTSP control.(Such a
session is not the subject of this message and should be discussed
seperately).

We also additionally approach the problem from a slightly different
angle, ie. "what to do once you have the description regardless of where
you got it from". This adds the requirement:
-Provide an algorithm that the client can deal with once it has the SDP
file.

Details:

An RTSP-SDP session description must have the session-level attribute
a=RTSP-Presentation.

We further  classify a RTSP-SDP description as describing a
presentation  that may be of two types(ones  allowing aggregate
control,  ones that do not).  Individual streams comprising such a
presentation may come from same or different files or the same or
different servers.  However, such a condition(streams coming from
different servers)  may be recognized, and the client may refuse to
render the presentation if it sees fit.

This classification is made for the purposes of specifying an
appropriate syntax in tune with SDP semantics, and a few simple steps
that a client implementation may use to proceed when it has such a
description.  There is no restriction as to which of the two types may
be received via RTSP-DESCRIBE, HTTP, inter-office mail, whatever. Also,
the classification would appear to be  appropriate - all RTSP really
cares about is applicability of aggregate control(that implies 1-1-n),
so basing client side processing on this rather than the source of the
SDP description would provide some advantage.

Regardless of  this classification, there is a m= field for each stream
within the presentation, and (possibly) appropriate rtpmap, fmtp fields
for each stream to describe the media.

This stuff is mostly a collection of proposals put forth various people
:

A) If aggregate control is possible, then a session level
a=presentation-url: rtsp:// will exist. In addition, for each stream,  a
media-level attribute will exist. This attribute will  define how a URL
to control the stream will be constructed treating the session-level
presentation-url  field as a base URL.(This attribute is an opaque
identifier). This does not preclude aggregate control for a presentation
composed of streams coming from multiple servers.  The server specified
in the aggregate URL is required to bear the burden of coordination.
However, such a servers namespace may be designed to coordinate
aggregate control of such a presentation without having the client being
knowledgable about it. The single stream case is expressed within this
scenario by the presence of only one media stream.

Example :
a=presentation-url :  rtsp://foo/twister
m=audio 0 RTP/AVP 0
a=stream:englishaudio
m=video 0 RTP/AVP 26
a=stream:coolvideo

i) The aggregate URL is rtsp://foo/twister

ii) The two URLs used to SETUP the two streams are
rtsp://foo/twister/englishaudio and rtsp://foo/coolvideo ie. the URLs
are formed simply by concatenating the stream attribute to the base URL
specified in a=presentation-url :

iii) All the above requests are sent to foo, period. Standard URL
semantics are not broken.

iv) Note that the stream attribute is opaque. Values such as
audio.com/englishaudio and appropriate design of the name space of  the
server "foo"  may be used to achieve aggregate control of streams coming
from different servers(ie. audio.com and something else). However, this
burden rests on foo.

vi) If there is just one stream, the a=streamid attribute is omitted.

vii) In this case, only one RTSP session must be used.

B) If aggregate control is not possible, a media-level a=stream-url:
field with an absolute URL will exist for each stream. The semantics of
the URL within this  field are unambiguous. The request for the URI goes
to the server specified in the URL.

Example:

m=audio 0 RTP/AVP 0
a=stream-url: rtsp://foo/twister/audio
m=video 0 RTP/AVP 26
a=stream-url: rtsp://bar/twister/video

i) In this case, n RTSP sessions must be used.
ii) This does not preclude both the URLs referencing the same RTSP
server(1-n-n case is hence expressed)

How the client should proceed :

It should proceed as follows, irrespective of whether the description
came in a DESCRIBE response or  not.

-Check whether a session-level a=presentation-url field exists. If yes,
it is case 1, else it is case 2.

Case1:
-Construct URLs for each of the streams as specified in A)
-If enough information does not exist for a stream, do a DESCRIBE on the
URL.  If the response SDP does not contain the same URL that was
DESCRIBEd, or contains more than one URL, report an error.(See
explanation on this below).
-send SETUP  for each of the streams on the same RTSP session to the
server using standard URL semantics.
-send aggregate or individual plays

Case2:
-If enough information does not exist for a stream, do a DESCRIBE on the
URL.  If the response does not contain the same URL that was DESCRIBEd,
or contains more than one URL, report an error.(See explanation on this
below).
(optional) : Check whether the two URLs reference the same server,  if
not assume that the streams are from different servers, and refuse to
play.
-send SETUP  for each of the streams on different RTSP sessions to the
server(s) using standard URL semantics.
-send play for each of the streams on different RTSP sessions

Explanation on step 2 for both cases:
This is a simplifying assumption.  It may even be argued that the SDP
file should *always* contain the media initialization information,and
therefore DESCRIBEs are never necessary.  However, allowing the DESCRIBE
here  accomodates the case where the media initialization info needs to
come from the location of the media resource itself(and that location is
not the source of the first SDP file).
Any *further*  indirection at this level would a) be glaringly in
REDIRECT territory b) serve no obvious purpose. Not putting such a
restriction may result in a situation where each subsequent DESCRIBE may
recursively  result in a description of multiple streams, making
checking for loops  and actual  rendering pretty hairy.

The question is : Should the protocol document be making this
restriction ? I believe so. It is not the protocol that is making the
restriction, really. Rather, the use of SDP in DESCRIBE responses for
indirection is being restricted for (good) reason.

Based on the above proposal, a couple of common application scnearios :

a)RTSP- SDP description embedded in html, or received in e-mail or
otherwise.

Follow directly the steps in "how the client should proceed"

Applicability : Source of SDP description and RTSP server closely
synchronized. Client should trust media initialization info if provided
and should DESCRIBE only if necessary.

 b) RTSP URL embedded somewhere :

Client does DESCRIBE on the URL, and gets a SDP file. Then follow the
steps above.

With reference to the ongoing discussion :

a) Indirection via DESCRIBE  is allowed only in the case where the
DESCRIBE is on an URL not  obtained from  a RTSP-SDP description. The
client needs to police this. With respect to Steve's earlier message
regarding two choices(ie allow indirection and not allow indirection),
this is middle ground.
b) Loop checking  issue is simple  :  It is  not applicable. Should be
applied to REDIRECT.
c) No conclusion can be made as to whether a presentation is aggregate
controlled or not based on  having a rtsp URL. However, such a
conclusion is unambiguously made when a SDP description is received.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : [email-masked]         Phone : (650) 937 3129
-----------------------------------------------------------------

---

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

Anup,

> e)Whether to use one RTSP session or not.(ie 1-1-n vs 1-n-n)

I generally agree, although I think d and e are the same and that not
all of the information necessarily needs to be conveyed explicitly.

> presentation.

How would you define an RTSP presentation?  That is, what
characteristics would distinguish a session that was an RTSP
presentation from one that wasn't?  The rtsp-03 draft says it is "a
set of one or more streams which the server allows the client ot
manipulate together".  Per that definition, an SDP file containing an
aggregate URL would be an RTSP presentation, and I guess a
single-medium SDP file would be as well.  But a 1-n-n SDP file would
not be.

> This would help us differentiate it from the case where

It's good to think about other situations.  So, perhaps the answer you
intended for my question above is that a session in which all of the
streams are under RTSP control is an RTSP presentation, but otherwise
not.  That's well defined, but what will the recipient of the SDP file
do with that bit of information?  If there was a client that could
only handle RTSP-controlled streams, I guess it could use this bit to
reject an SDP file that wasn't an RTSP presentation.

On the other hand, one could also identify an RTSP presentation by the
presence of an RTSP URL for streams.  Even if the SDP file passed the
1-bit test for our hypothetical client, the client will still have to
verify that it has a URL for each stream.  So I haven't figured out
yet what good the session-level attribute would provide.

> -Provide an algorithm that the client can deal with once it has the SDP

OK, that would be a motivation for not having anything implicit in the
arrival method.  Of course, to save bits, one could leave out what was
implicit and add it at the client, but we probably don't need to argue
about bits here.

> An RTSP-SDP session description must have the session-level attribute

As above, I'd like to know what this will achieve.

> render the presentation if it sees fit.

All fine.

> SDP description would provide some advantage.

Agreed that aggregate control should be possible with an SDP
description received via a method other than RTSP-DESCRIBE.

> for each stream to describe the media.

Right.  The m= is the necessary separator for stream info.  We don't
need to have a c= for each stream.

> a=presentation-url: rtsp:// will exist.

I agree that a session-level URL specifier should be there.  However,
I would like the session-level and media-level URL specifiers to be
the same.  It could be a=rtsp-url, or more general if something like
the a=source I've mentioned makes sense, or it could be a new letter
to the left of the = sign.

> In addition, for each stream,  a media-level attribute will exist. 

Fine.

> This attribute will  define how a URL
> identifier).

Not fine.  I believe this should be a real URL here, too, which may
well be relative.  In essense, what you are doing is forcing this
attribute to be a relative URL, but it may not be the case that the
stream URLs are relative to the aggregate URL for the n-1-n case (RTSP
session with aggregate control and streams coming from separate files,
usually on the same server).  So let's allow relative URLs but not
force them.  I don't see any need to make this case (aggregate
control) different from the next one (no aggregate control) where you
do have a URL.

> This does not preclude aggregate control for a presentation

Agree to all.

> semantics are not broken.

If there are real URLs as I propose, then the client will have to
verify that the URLs point to foo.  I acknowledge that extra cost, but
I believe the consistency would be worth it.  A client that can handle
non-aggregate control needs to have code to check if the URLs are on
the same host anyway to know whether or not it can share RTSP
connections.

Forcing a relative URL precludes the error of having the URL reference
another host, but introduces the error of finding a=stream-url when
you were expecting a=stream.

> vi) If there is just one stream, the a=streamid attribute is omitted.

This can still be true if real URLs are used.

> to the server specified in the URL.

Fine.  We don't need two different attributes (a=stream and
a=stream-url) to signal the difference between aggregate and
non-aggregate control since the presence of the aggregate URL at the
session does that.

> it is case 1, else it is case 2.

Right.

> explanation on this below).

If additional information is needed, why not do a DESCRIBE on the
aggregate URL and get it all at once?

> -send aggregate or individual plays

Fine.

> not assume that the streams are from different servers, and refuse to

(I assume that by "two URLs" you mean audio and video since if you
meant the URL before the DESCRIBE and in the response then verifying
that the URLs are the same already verifies that the reference the
same server.)

Yes, this could be an option, but the hard part for a client is
handling non-aggregate control.  Given that capability, the only
difference with multiple servers is that the individual PLAYs have to
go over different RTSP connections.  So I don't see a reason why a
client would want to refuse.

> -send play for each of the streams on different RTSP sessions

Fine.

> not the source of the first SDP file).

Right.  In particular, the first SDP file might consist of only the
minimum more than the aggregate URL, with no media information at all.

> checking for loops  and actual  rendering pretty hairy.

Fine.  This is the point where requiring all the information to be
explicit is a disadvantage because you have to check it.  A DESCRIBE
response on an aggregate URL need not include that aggregate URL (but
would need to include stream URLs), and a DESCRIBE response on a
stream URL need not include the stream URL.

> restriction ? I believe so.

The examples of this restriction that you gave were when doing a
DESCRIBE on a stream URL, should we insist that the DESCRIBE response
not carry a different URL.  I don't think anyone would argue with
that.  As you say, removing this restriction would serve no obvious
purpose. 

The more significant question we were discussing before was whether a
DESCRIBE on an aggregate URL could return stream URLs that reference a
different host, that is, whether or not to allow indirection.  In your
proposal here, you've precluded that possibility by forcing the stream
URLs under an aggregate URL to be relative.  So, that is putting the
restriction in the protocol that indirection is not allowed.  Fine.

I don't like the requirement to use relative URLs.  But I'm willing to
keep the requirement, as a protocol restriction, that the stream URLs
under an aggregate URL reference the same host.  As I argued in
Munich, the protocol should not preclude the aggregate controller from
acting as a coordination proxy for streams that come from multiple
servers.  This doesn't, but it requires the proxy to also fold the
stream URLs into its namespace, whereas that was not necessary in what
I said originally.  But this restriction, along with the presence of
the aggregate URL in the session level of SDP, is to gain the
consistency of function in SDP files whether they come from DESCRIBE
responses or HTTP.  That's a fair trade.

> DESCRIBE is on an URL not  obtained from  a RTSP-SDP description.

Actually, it can't happen.  An RTSP URL is either aggregate or
individual.  For aggregate URLs, you proposed a syntax that precluded
indirection, which I propose to relax the syntax but keep the
semantics.  For individual URLs, we agree that there is no point.

> The client needs to police this.

With the relaxed syntax I proposed, yes.

> With respect to Steve's earlier message

Well, I think it is just the choice of not allowing indirection, which
was the one I said in my summary that I favored.

> b) Loop checking  issue is simple  :  It is  not applicable. Should be

Right, this is the result of disallowing indirection.

> conclusion is unambiguously made when a SDP description is received.

Right, but you can tell from its position in an SDP file.

							-- Steve

---

From: [email-masked] (Anup Rao)
Date: Thu, 11 Sep 1997 18:53:04 -0700

Stephen Casner wrote:

> not.

Thats what I meant, yes.

> That's well defined, but what will the recipient of the SDP file

Yes, again. Also, it helps it somewhat to check validity. See below...

> yet what good the session-level attribute would provide.

It seperates out the two  cases  when the lack of rtsp url for one of
the media is accidental,   and that when it is deliberate.

A "rtsp-control-only" client would draw the distinction between these :

(accidental)
a=RTSP-Presentation
m= audio 0 RTP/AVP 0
a=source:: rtsp://....
m=video 0 RTP/AVP 26
a=rtpmap:....

Ideal response : there is something wrong with the file.

(deliberate)
m= audio 0 RTP/AVP 0
a=source:: rtsp://....
m=video 0 RTP/AVP 26
a=some-other-thing: http://(say its http streaming or somethin)

Ideal response : I cannot handle this file, its out of my
league.Arguably, the differentitation is also possible by using
something other than "source" in this case.

> to the left of the = sign.

Agreed.  Pending decision on the c= debate.

> control) different from the next one (no aggregate control) where you

OK. (but I will shed a tear for it though :) .It is a tradeoff between
mapping of the URL to the filesystem on the server side, versus a fairly
simple check on the client side. What do others think about this
particular issue ?

> non-aggregate control since the presence of the aggregate URL at the

Agreed. Pending c= discussion.

> minimum more than the aggregate URL, with no media information at all.

However,  I think such a file should not guarantee aggregate control.
(ie. in that sense it is a presentation URL, but not an aggregate URL).
ie. such a URL should preferably  have an identifier other than the one
used in a description that does have the m= sections. There are cases
where one may convey the presense of a RTSP presentation(as using SDPs
time fields that says when it is available), but the presentation may or
may not be aggregately controlled.

Example(typically retreived by non-RTSP means)

t= on 11th sept between 6 and 7 pm
a=something: rtsp://foo.com/todays-presentation

describe rtsp://foo.com/todays-presentation may result in

m=
a=source:rtsp://foo.com/presentations/audio
m=
a=source:rtsp://foo.com/presentations/video

(Regardless, I have to add this case i.e only single URL  to the "steps"
below and will do so).

> restriction in the protocol that indirection is not allowed.  Fine.

That intention  was not clear to me earlier(ie. discussion of
indirection only in DESCRIBE responses for aggregate URLs).