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

From: Stephen Casner <[email-masked]>
Date: Fri, 12 Sep 1997 01:22:32 -0700 (PDT)

Anup,

> > 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.
> 
> Thats what I meant, yes.

As I've pointed out, that is different from the definition of an RTSP
presentation in the spec.  There, a presentation implies aggregate
control.  I think we may want to keep it that way.  See below...

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

This seems like a somewhat weak motivation for adding the
session-level attribute.  After all, that attribute could also be
accidentally omitted.  My vote is to just not include it.

> Ideal response : there is something wrong with the file.
...
> Ideal response : I cannot handle this file, its out of my
> league.

How significant is the difference in these responses?

> > Right.  In particular, the first SDP file might consist of only the
> > 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.

I'm bothered by the change in definition of an RTSP presentation to
not imply aggregate control.  Although the protocol has gone through
some transformations as we've discussed aggregate control over the
last couple of months, we still have the notion that an RTSP URL maps
to a single RTSP session.  (With aggregate control, multiple URLs may
be used within one RTSP session for individual stream setup and
control, but one RTSP URL never results in the creation of more than
one RTSP session.)  If you want to have an RTSP URL return a DESCRIBE
response without an aggregate URL but with multiple stream URLs, then
this property is broken.

On the other hand, having an HTTP URL point to an SDP file with
multiple RTSP stream URLs and no aggregate control seems OK.  Maybe
that seems like a fine distinction, but it's also a distinction we
upheld for the case where the stream URLs are on different hosts (we
won't allow that in a DESCRIBE response now).  Having the DESCRIBE
response cause the creation of multiple RTSP sessions seems akin to
indirection.
							-- Steve

---

From: [email-masked] (Anup Rao)
Date: Fri, 12 Sep 1997 18:26:40 -0700

> How significant is the difference in these responses?

The difference is not significant, but is there. I'm coming from the
view that I'd rather have a client know what to expect  in the file and
then do consistency checking, rather than having it figure out what kind
of session  it is in the first place. Also, things like a null c= field,
or missing c= field, another presence of another letter could also
accomplish pretty much the same in my opinion and will suffice. So I
withdraw the need for the extra attribute.

> response without an aggregate URL but with multiple stream URLs, then

It then  becomes impossible to specify a non-aggregate control
presentation in the same way without specifying its media initialization
info.(maybe you can specify a dynamic pt and omit rtpmap - but I dont
like this option). Why the difference ?

> response cause the creation of multiple RTSP sessions seems akin to

It is not going to be possible to monitor the source of such
decsriptions, I think. That is why a source-independant way to deal with
it is useful. Even if that argument does not hold good, the relationship
to http/html (for example) should be independant of  the possibility of
aggregate control.In effect, what we are saying here that one  may get a
SDP description for an aggregate-control session by DESCRIBE, but not so
for a non-aggregate case. While I will agree there is no "RTSP" relation
between the streams in a presentation that does not have aggregate
control, making this distinction in the source of the SDP will not do us
good.

I guess there are two things we are trying to preserve :-
(second attributable to myself atleast)
- the "one RTSP URL never results in more RTSP session" elegance and
consistency.
-That the presentation abstraction is maintained in some sense. Atleast
from _high-level_ client operation and authoring point of view, whether
a presentation has aggregate control or not should not matter.

I think these are solvable, since more than one URL can be used within a
single session (pending acceptance and clarification in the document -
the document does not really preclude it) _regardless_ of whether
aggregate control is allowed or not. This is no different in the RTSP
sense than  using non-aggregate control in a case where both aggregate
and non-aggregate control are allowed. We necessarily exclude cases
where control channels have to be set up made to more than one server
and make them the 1-n-n case - I  agree that descriptions  pertaining to
such things should necessarily be prohibited in the DESCRIBE response.
(There is also the case where a client requests two random files on the
same session - in this case the server does not refuse and the client
just catches fire).

I guess I'm also saying that having a presentation URL whose only
purpose in life is to be DESCRIBEd is not bad either. That also explains
why I am seeing the use of SDP as a total description of a RTSP
presentation, independant of whether aggregate control is allowed or
not, which brings me to the last point -

What is the usefulness in having a SDP description that does not specify
stream URLs compared to just having a rtsp URL that you can do describe
on ?  I'd say none. One might argue that this allows  just specifying
that a session exists at a certain time, without providing the
initialization info. I have doubts as to whether one should provide for
such a case. If a source is willing to say a session exists  at a
certain time, it must vouch for its initialization info and say what
media are in the session,  in keeping with regular SDP usage. The other
option is not to specify the stream URL in a m= section, but rather
specify it seperately at the session-level  and then make some
correlation - this clearly seperates out the init info and the control
info.

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