Subject: RE: RTSP 1b & e. 1-1-n & Use of SDP within RTSP

From: "Anders Klemets (VXtreme)" <[email-masked]>
Date: Fri, 5 Sep 1997 11:24:20 -0700

On Thursday, September 04, 1997 11:31 PM, Rob Lanphier
[SMTP:[email-masked]] wrote:
> >  DESCRIBE rtsp://proxy.com/rtsp://foo.com/something/other.sdp
> 
> This is *not* the way HTTP is dealing with proxies, to the best of my
> knowledge.  If a client is hooked up to a proxy, the client uses:
> 
> GET http://foo.com/something/other.html HTTP/1.1

A difference between RTSP and HTTP is that in RTSP, the "rtsp://server"
part of the URL is not dropped when connecting directly to a server.  So
why should the "rtsp://caching-server" part be dropped when connecting
to a caching server?

But I hear that "double URLs" do not conform to the correct syntax for
URLs.  So it might be better, and look nicer, if a caching server
renames the URLs of streams that it has cached.  Suppose
"rtsp://server/clip" is cached.  The caching server would rename the
URL, and the SDP description would say something like this:

c=IN URL rtsp://caching-server/cacheid=12345

I like the possibility of being able to use SDP for media indirection.
Now, how consistency across servers is implemented is outside the scope
of RTSP and SDP.  If somebody wants to tackle this problem for their
servers, then that's fine.  I don't think receiving streams from
multiple servers would be much of a problem for a client.  Personally, I
think that RTSP compliant clients should be able to play streams from
multiple servers simultaneously.  I am not sure I have heard a good
reason for why this would be so hard.

So with media indirection allowed, when the client sends a DESCRIBE to
"caching-server-1" and gets an SDP description that contains the URL
"rtsp://other-caching-server/cacheid=1234", the client would contact
"other-caching-server" directly.

If media indirection is not allowed, on the other hand, the hostname
part of an RTSP URL loses its normal meaning in the context of an SDP
description.  If URLs are to be treated as opaque strings, then things
like "rtsp://cacheid=5467" would be valid.  Maybe it's better to use
relative URLs in such a situation.

Anders

---

From: [email-masked] (Anup Rao)
Date: Fri, 05 Sep 1997 17:04:26 -0700

> I like the possibility of being able to use SDP for media indirection.

It is  the indirection via DESCRIBE responses that is being disputed,
not the use of SDP as such.

> "other-caching-server" directly.

Now this bothers me at bit. Clearly if we allow indirection via DESCRIBE
responses, this is possible. But the right way to do it would be
REDIRECT(adds a describe roundrip, but still a better way,
IMHO).Indirection in SDP descriptions obtained by SAP, HTTP, SMTP etc.
are pretty useful and  logical.  Allowing it in DESCRIBE response
maintains generality, which is nice  since such indirection is likely in
server->client ANNOUNCE messages.
However, I do agree that its implementation should be optional, and as
suggested by others,  making an explicit disctinction between the two
types (with/without indirection) is a good idea.

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

---

From: Stephen Casner <[email-masked]>
Date: Sat, 6 Sep 1997 22:51:37 -0700 (PDT)

Attempting to catch up...

On Wed, 27 Aug 1997, Rob Lanphier wrote:
> When an arbitrary stream URL is specified in a DESCRIBE response
> (perhaps to an entirely different server), the client is expected to
> still send the SETUP message corresponding to that URL to the server
> that the DESCRIBE response came from.

I believe I was one of the people espousing this position in Munich,
and I believe it was in response to a proposal that the URLs returned
in a DESCRIBE be required to reference the same host as the aggregate
URL that invoked the RTSP session.

While one would expect that most DESCRIBE responses _would_ refer to
media sources on the same host, my point was that the RTSP protocol
did not need to require this.  I said that the SETUPs would all go to
the same place because that is what is implied by the existance of the
aggregate URL that returned the DESCRIBE response.  If you have to
send SETUPs to different hosts (and get session IDs back from those
hosts and send PLAYs to those hosts), then you don't have aggregate
control.

It was my assumption that when the media URLs indicated other hosts,
the data would be streamed directly from those other hosts even though
the RTSP commands would all be sent to the initial host.  That initial
host would have to serve as a coordination proxy (how it does that is
not RTSP's concern).  The transport address returned by the SETUP
would indicate which host was the media source, which I was assuming
would be the same as the host portion of the URL, though I suppose
that is not a requirement.  (Would it be useful at all for
authentication, say if the session decription were signed?)

When aggregate control is not possible, either because the resources
are on multiple servers that have no coordination, or even on a single
server that isn't capable of aggregate control for some reason, then
no aggregate RTSP URL would exist.  Instead there would be only the
separate RTSP URLs for each medium, each of which would return a
DESCRIBE response only for that medium.

The piece left unanswered by this position is how to describe a
session with multiple streams which the client is required to control
separately (accepting that some clients might have that capability
while others do not).  It could be just a list of RTSP URLs, but that
list would need to be contained somewhere that could be referenced.

As Henning points out, an SDP description would be one kind of
container we would want to use for this.  But should there be a
distinction that RTSP URLs in an SDP description retrieved via HTTP
would result in (DESCRIBEs and) SETUPs being sent separately to the
addresses in the URLs whereas RTSP URLs in an SDP description
retrieved by a DESCRIBE would result in SETUPs being sent to the host
that returned the description as I proposed above?  I admit this seems
inconsistent although the rules could be well-defined.

It seems we have two choices:

1.  Disallow RTSP redirection in a DESCRIBE response.  The media URLs
    are taken as opaque identifiers that are always sent to the same
    place as the initial, aggregate URL.  Proxy coordination is
    implied if different hosts are addressed.  This is as Rob
    specified in the first message of this thread.

    We suppose that RTSP URLs may also appear in SDP files obtained by
    other means, and in that case an RTSP session would be initiated
    separately for each RTSP URL, even if multiple URLs reference the
    same host, because the separate URLs imply no aggregate control.
    If aggregate control is provided, then one aggregate RTSP URL
    would be shown.

2.  Allow RTSP redirection in a DESCRIBE response.  If different hosts
    are specified in the media URLs, the SETUPs are sent there.  This
    means the aggregate URL is not really a promise of aggregate
    control; clients that cannot handle separate control of the media
    streams will just have to halt and catch fire.

    To specify a session in which media streams will come from
    separate hosts but proxy coordination is provided, the media URLs
    are required to address the same host as the aggregate URL.  The
    format of these URLs could be up to the RTSP server, following
    several suggestions that have been made in this thread:

	rtsp://proxy.com/oneplace.com/blah/trackID=47
	rtsp://proxy.com/cacheid=12345
	rtsp://proxy.com/rtsp://foo.com/something/other.sdp

    (There seems to be some difference of opinion as to whether or not
    this third form is valid for URLs; I don't know, but if it is
    valid, I think the whole thing should be sent in the SETUP, as is
    the case for all other RTSP URLs, rather than requiring that the
    client strip off the first part.)

I could live with either of these choices, though I lean toward the
first.

What follows are a few other specific comments to messages in this
thread:

On Thu, 28 Aug 1997, Henning Schulzrinne (BL) wrote:
> (Because of that, it is probably a good idea to make Session id's
> globally unique. It certainly can't hurt.)

Globally over what space?  Do you mean they should be mondo IDs unique
across all hosts?  What would that gain?  It seems to me that there is
no aggregate control if the SETUPs are sent to multiple hosts.

On Thu, 28 Aug 1997, Rob Lanphier wrote:
> One thing that we could do is have a separate syntax for when media
> indirection is actually desired.  For instance:
...
>    c=IN URL rtsp://oneplace.com/blah/trackID=47
...
>    a=murl:rtsp://oneplace.com/blah/trackID=47

I don't like the idea of two different forms.

On Thu, 28 Aug 1997, Henning Schulzrinne (BL) wrote:
> Note that we also need a description format (RTSL, SDP) to be retrieved
> via HTTP, to find out the component sessions and

Yes, for some scenarios.  But:

> since directly
> including an rtsp:// URL in a web page is not going to be very
> useful.

Why not?  I'm missing something here.  It seems to me that having an
rtsp:// URL behind an icon on a web page is one of the most likely
usage scenarios.  This may often be an aggregate URL.

On Wed, 3 Sep 1997, Anders Klemets (VXtreme) wrote:
> If a client gets an RTSP URL from an HTML EMBED or OBJECT tag, the URL
> can look in two different ways:
> 
> rtsp://proxy.com/rtsp://foo.com/something/other.sdp
> 
> or
> 
> rtsp://foo.com/something/other.sdp
> 
> In this second case, the client needs to know, somehow, that it is
> supposed to send the RTSP DESCRIBE command to "proxy.com".  Perhaps it
> is a manual configuration parameter, or maybe a some client
> autoconfiguration protocol is used for this purpose.

Knowing that URLs received in a DESCRIBE response should be sent back
to the same host seems like a reasonable implication because of the
immediate association, but I don't understand how the suggestion here
to have a configuration parameter for the HTML case would work out.

> Note also, that unless the proxy is some sort of "virtual" proxy, i.e.
> it has multiple domain names, any RTSP commands that it gets will always
> start with "rtsp://proxy.com".  Anything else should result in a 3xx (or
> 4xx?) error code.  It was for the sole purpose of supporting virtual
> servers (e.g. "abc.com" and "cbs.com" handled by the same server) that
> we decided to transmit the "rtsp://hostname:port" portion of the URL,
> isn't that right?

If the RTSP URLs in a DESCRIBE response are not opaque, and if
different domain names of the same host are used for different media,
then the control would wind up being separate rather than aggregate.

On Thu, 4 Sep 1997, Rob Lanphier wrote:
> However, this idea that a DESCRIBE can lead to another DESCRIBE is
> also no less palatable (how many DESCRIBES does one need to do?  It should
> only have to ask for a description once for a session.).

You only need to do another DESCRIBE when an indirection has
occurred.  Presumably that chain will end.  It seems that getting
another description after the indirection is more likely to give
accurate media description information than not doing so.

On Fri, 5 Sep 1997, Anders Klemets (VXtreme) wrote:
> I don't think receiving streams from

Are you talking about media (RTP) streams coming from multiple
servers, or separate RTSP control connections to multiple servers.  I
agree that having the data come from multiple servers should make very
little difference, but separate RTSP sessions means the client must
manage synchronization of the starting and stopping.  Certainly this
can be done, it just takes more work.
							-- Steve