Subject: Re: RTSP URL issues

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 24 Jul 1997 18:30:16 -0700

>On the surface this sounds good to us at PN. And in fact we think we can
>make this work... Unfortunately according to the URI group this is
>illegal. The specific illegality of this technique is highlighted when
>we consider the CGI case. If the DESCRIBE url had been...
>
>  rtsp://server/cgi-bin/movie.cgi/someparams/audio
>
>Then the rules of URI parsing (according to the URI group) say that
>"/someparams/audio" gets passed to the cgi-bin script.

Crikey, it isn't the URI rules: that is the definition of the CGI interface.
Similar rules exist for the other server-side APIs, because in general
it is a good thing to be able to donate parts of the server namespace
to modular handlers.

>My concern is that the media server doesn't know whether that last
>"/xxx" is a param for the cgi or the stream identifier.

Then it isn't a media server, period.  You cannot say that a new protocol
element is required just because the server might have lost control
over its own namespace -- that is absurd.

....Roy

---

From: Stephen Casner <[email-masked]>
Date: Fri, 25 Jul 1997 00:13:21 -0700 (PDT)

Let me apologize in case my previous message seemed a bit flippant --
it was composed too late at night.

> 1-1-n is by definition NOT used for separate files. The first "1" in
> 1-1-n means container file, check Rob's very first post on the subject.

I agree that this is how the term was originally defined, but I have
interpreted several of the ensuing messages to redefine the first
digit to be "presentation", for example Anup's nice summary of 11
July.  So, let me just delete that term and ask my question again:

    If we use the stream ID approach, how are we going to construct
    the presentation aggregation when the media streams are in
    separate files?

Several people have identified a need for aggregate control, and I
accept this as a valid requirement.  The RTSP spec hints at it but
doesn't complete the job.  Anup's summary identifies the need for
aggregate control as one of three separate issues that are being
discussed together here.

> When multiple files are used you are talking about "n" in the first
> item. It seems to me that the spec is clear (and to date the
> conversations have been clear) that the only way to handle "n" files is
> with "n" rtsp sessions. So this is the n-n-n case that was dismissed
> from the discussion early on as "already doable".

Yes, n-n-n is already doable, but so far as I can tell, there is no
mechanism for aggregate control in that situation.  Do you agree?

I believe the proposal to use stream IDs implies that aggregate
control is only possible if all the media are contained in a single
container file.  I don't think that is acceptable.  Over the life of
the RTSP protocol there may be many ways that media data is stored,
for example as assets some database system.  That is a local matter
for the server.

> Why do we keep talking about containers as the special case? Containers
> are the general case... All media files contain N streams. For some
> media files, like audio, N=1. I think any solution that treats
> containers as the special case is destined to be more complicated than
> it needs to be.

I've been saying exactly that container files should _not_ be a
special case, that the client shouldn't have to know or care.  The
media elements should be addressed by the URL whether they are in a
container file or not.

> The _more_ general solution is to recognize that all files are
> containers, and that targeting (i.e. which RTP packets go to which port)
> information has to be an URL for the "file" combined with a "token" of
> some kind to identify the stream within the file.

OK, you're suggesting that we always use a URL plus a stream ID.  That
would seem to restore consistency, except that when the data is in
multiple files you need to use different URLs for each, implying
separate RTSP sessions and no means to refer to the aggregate of the
streams.

> Let's assume that there is no file at this location, or that the server
> attempted to open the file and discovered that there is no file.
> 
> As I understand the suggestion, it would mean that the server should now
> "cut off" the "/audio" part of the URL and attempt to find a resource at
> "/movie". Let's say that indeed there is such a resource, and the server
> now knows it should use the "/audio" part that it cut off to act as a
> stream selector from within the container.

I would expect instead that the server would process the elements of
the resource pathname in order.  If "movie" is a directory, then it
looks for "audio" in that directory.  If "movie" is a file, then it
checks to see if that file is a container file of the appropriate type
such that "audio" makes sense as a selector for part of the file.

> The specific illegality of this technique is highlighted when

I would expect the CGI script to consume the part that composes it's
parameters and return the rest.  Yes, one could specify a syntax for
the parameters such that it was ambiguous whether "audio" was a
parameter or a track selector, but that would be an erroneous design.

> Another aspect of this problem is available when you examine the media
> server's support for mount points. Let's say I have the following
> setup...
> 
>   local /usr/admin/media/content mounted at /
>   local /usr/brad/media   mounted at /coolstuff

I don't know what you mean by mount points here.  In the UNIX
filesystem, if you mount something on / then the /coolstuff that was
there before is no longer visible.  Assuming the system you're
describing somehow allows the example you've given, then it allowed
you to construct an ambiguous filesystem, so you're in trouble when
trying to make a local reference to the filesystem without even
considering any URLs.

I would think the example you described is illegal.

> If the protocol REQUIRED the stream id part of the URL than this is less
> of an issue, because the server always knows that the last "/xxx" is the
> stream id. But I would imagine that this would not be a popular
> decision.
> 
> Steve, do you have a specific suggestion that addresses these concerns?

As the server works its way down the URL, when it gets to a file and
there is more left, it references an element within the file.

							-- Steve

---

From: Brad Hefta-Gaub <[email-masked]>
Date: Fri, 25 Jul 1997 02:43:27 -0700

Hurray! I am very excited by these last couple pieces of e-mail, I think
I see some real progress being made... But I have a couple
questions/comments.

Note: I need to clarify some vocabulary here, so this mail is kinda
long. My apologies in advance.

Stephen Casner wrote:

> > 1-1-n is by definition NOT used for separate files. The first "1"
> > in 1-1-n means container file, check Rob's very first post on the
> > subject.
>
> I agree that this is how the term was originally defined, but I
> have interpreted several of the ensuing messages to redefine the
> first digit to be "presentation", for example Anup's nice summary
> of 11 July.

Fair enough, I too am sometimes confused by the 1-1-1, 1-1-n... stuff as
well, but I think we need to keep our terms straight.  Let's either
agree to stick with the terms at hand or agree to new terms. I think we
should stick with the current terms and recognize the following:

We've always been talking about a single presentation... so each of the
following options are possible...

  *  1-1-1 is one presentation [assumed] of...
    one file [the first 1] (a container file) controlled by...
    a single RTSP control session [the second 1] streamed to...
    a single RTP addr/port combination [the last 1]

    It is my understanding that the group has clearly indicated
    that although this is "legal" so long as the RTP payload type
    is 101 or some "dynamic" value, it is not encouraged for QOS
    reasons. Let me state for the record that I was a big supporter
    of this technique, and through the eloquent arguments of Steve
    and Henning, I have been persuaded that this is a less than
    optimal solution. I now understand that n RTP ports is important.

  * 1-1-n is one presentation [assumed] of...
    one file [the first 1] (a container file) controlled by...
    a single RTSP control session [the second 1] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This is the topic of the "hottest" debated. In general,
    everyone seems to agree that this is needed, important,
    doable, etc. There are multiple solutions currently being
    kicked around. StreamIDs and URLs are the two basic approaches.

  * 1-n-n is one presentation [assumed] of...
    one file [the first 1] (a container file) controlled by...
    multiple RTSP control session [the middle n] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This was mentioned in Rob's first e-mail message, it seems
    to be a less than popular solution although it has received
    little discussion by the group. I would say that it is probably
    unpopular because it has all the disadvantages of n-n-n (multiple
    commands are required to seek the presentation) and would require
    a standard URL implementation, which seems a sticking point.

  * n-n-n is one presentation [assumed] of...
    multiple independent files [the first n] controlled by...
    multiple RTSP control sessions [the second n] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This is currently supported by the protocol. And in fact the
    protocol has good support for allowing this to be relatively
    efficient from a "resource" perspective, because you only
    need a single TCP connection, assuming the files are all on the
    same media server. Notice, that PN's current implementation of
    RTSP (available in the RealMedia SDK) supports this concept.
    We support multiple metafile formats (RTSL, RAM, etc.) and allow
    multiple files to be tied together as a single presentation.
    The client handles the "synchronization" of the streams
    and all is well in the world. The problem with this is that
    the client has to issue "N" pause commands, "N" seek commands,
    etc.

Now for a new term: This is what I think Anup and Steve want (and I'm a
fan of this as well.)

  * n-1-n is one presentation [assumed] of...
    multiple independent files [the first n] controlled by...
    a single RTSP control session [the middle 1] streamed to...
    multiple RTP addr/port combinations [the n at the end]

    This is not currently supported by the protocol. This would be
    basically allow a single presentation of multiple files to be
    controlled with one set of pause, seek, etc. commands. I can
    tell you that we at PN would love this feature as it would fit
    quite nicely into our current implementation. _However_ it was
    my understanding that we (the whole RTSP/confctrl gang) as a
    group decided to avoid this until a later version of the
    protocol.

I recommend we stick with these terms as I think most of us are now
familiar with them.

> If we use the stream ID approach, how are we going to
> construct the presentation aggregation when the media
> streams are in separate files?

I don't see this as a problem related to streamIDs vs. URLs. As a side
note, in the proposal I've been advocating, the only reason you need to
mention the stream ID is to target the stream of the container to a
particular RTP addr/port. This is why I am so keen on it being in the
822 headers, since that's where we were planning on putting transport
information anyway. This really has nothing to do with "aggregating
control".

> Several people have identified a need for aggregate control...
> Yes, n-n-n is already doable, but so far as I can tell,
> there is no mechanism for aggregate control in that
> situation.  Do you agree?

Yes.

> container file.

I disagree with your interpretation of the StreamID proposal. All that
StreamIDs are related to is the targeting of stream data to a particular
RTP addr/port. Aggregation of the playback of multiple "resources" in a
single RTSP control session is a completely different issue.

> media elements should be addressed by the URL whether they are in a

I'd like to drill down on this point a little more, mainly because I
keep hearing this "the client shouldn't care" argument. But I am having
a hard time understanding it... We all recognize that the client at
least must know that if it just asked for a container file, then it
needs to be listening to "n" RTP ports... so it seems to me that the
client _does care_. The only way I can imagine the client not needing to
know if the resource was a container or not is if the client can only
handle single "streams" in a single RTSP session.

I guess this would mean that the client would always have to drill down
to the single stream. I think I understand Roy to be suggesting this
when he says... "if you attempt to access rtsp://foo.com/movie.rm and
movie.rm is a container, then the server should ... disallow access..."

Of course if this is the route we went the we are therefor forcing "n"
RTSP control sessions for every container file. Which is exactly the
opposite of aggregate control. Based on your "aggregation" questions I
would assume you aren't a fan of this solution.

> > The _more_ general solution is to recognize that all
> > files are  containers, and that targeting (i.e. which RTP
> > packets go to which port) information has to be an URL for
> > the "file" combined with a "token" of  some kind to identify
> > the stream within the file.
>
> OK, you're suggesting that we always use a URL plus a stream
> ID.  That would seem to restore consistency...

Yes I am suggesting that we always use URLs and Stream IDs... Namely use
URLS to talk about the resource ("DESCRIBE ulr" and "SETUP url"). And we
use StreamIDs when we want to tell the server how to target the streams
of any resource to a particular RTP addr/port. This would be in the 822
header section of the SETUP command.

> ...except that when the data is in  multiple files you need to
> use different URLs for each, implying separate RTSP sessions
> and no means to refer to the aggregate of the streams.

Well, as I've said this is a different issue than stream/port
targeting... I don't see how opting to use URLs instead of streamIDs
somehow automagically gives you support for aggregation. Let's talk
about aggregation, but don't write-off streamIDs as a solution for
targeting stream/ports.

> > Let's assume that there is no file at this location...
> > As I understand the suggestion, it would mean that the
> > server should now  "cut off" the "/audio" part of the URL
> > and attempt to find a resource at "/movie"....
>
> I would expect instead that the server would process
> the elements of the resource pathname in order.  If "movie"
> is a directory, then it looks for "audio" in that directory.
> If "movie" is a file, then it checks to see if that file is a
> container file of the appropriate type such that "audio" makes
> sense as a selector for part of the file.

This is a great suggestion Steve. And I agree that this works very well
for finding streams in a container file. But, as I've pointed out above,
I think this route of identifying streams as the units of control is
only leading us further away from aggregation support.

At this point I can hear the arguments now... going something like:
"let's solve aggregation, then there is no problem forcing the setup to
be on a per stream basis"... Hmmm... maybe that makes sense... but we'd
need to solve the URL problem first...

Read on... as I still see a problem with URLs and CGI on a media server.

Roy T. Fielding wrote:

> >Then the rules of URI parsing (according to the URI group)
> >say that "/someparams/audio" gets passed to the cgi-bin
> >script.
>
> Crikey, it isn't the URI rules: that is the definition of
> the CGI interface. Similar rules exist for the other server-side
> APIs, because in general it is a good thing to be able to donate
> parts of the server namespace to modular handlers.

Ouch, so I mis-spoke, I didn't mean to place blame on the URI group... I
really meant to say, hey "it's already a rule for cgi..." that once you
hit the cgi script, everything else is considered a param to the cgi.

I am 100% behind the idea of... "be[ing] able to donate parts of the
server namespace to modular handlers".... (see below)

Stephen Casner wrote:

> I would expect the CGI script to consume the part
> that composes it's parameters and return the rest.

"return the rest"... ok, I'm no cgi expert... but I don't think that it
is possible for a cgi script to "return the rest" of an url to the web
server for "further" processing. I am looking in the IIS/ISAPI
documentation right now and I can't find anything that allows this.
Certainly a cgi or an NSAPI or ISAPI plugin can ask the server for
"additional" resources, but I don't think it can say, here's the actual
resource and "by the way I didn't process the /foo/bar part of the url
so please do your mumbo jumbo on it"...

Please correct me if I'm wrong on this... please show me how a cgi
script does this. I would love to make this work.

Here's the deal, a media server can use module handles to support
fulfilling media requests. In fact PN's current RTSP implementation
supports "file system plugins" as well as "live source plugins". Both of
these technologies use "donate[d] parts of the server namespace"... and
in fact they use rules very similar to how cgi-bin on a web server
works... namely after the server has drilled down enough to know it's
talking to a modular handler, the rest of the url is handed off for the
modular handler to "handle" as it were... Now, considering that that
modular handler could in fact be a "web" oriented cgi-bin script, which
to my knowledge has no way of "handing back" the rest of the url... how
should I make this work.

If the answer is, "here's how cgis hand back the rest of the url to the
web server..." then GREAT, you have probably sold me.

> As the server works its way down the URL, when it gets to
> a file and there is more left, it references an element
> within the file.

This is a great suggestion which I believe I have shown doesn't work
when a cgi-bin is inserted in the URL. If we can make this work with
cgi-bins than I will probably be convinced.

-Brad
-----------------------------------------
Brad Hefta-Gaub
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax: (206)674-2699
email: [email-masked]
web: http://www.real.com
-----------------------------------------

---

From: Stephen Casner <[email-masked]>
Date: Sat, 26 Jul 1997 01:57:51 -0700 (PDT)

Brad,

> We've always been talking about a single presentation...

Well, sort of.  The spec defines presentation as

   Presentation: A set of one or more streams which the server allows
        the client to manipulate together. ...

The current spec, plus the changes proposed to add stream IDs,
achieves the aggregate control implied by this definition for some of
the modes you've listed but not for others (n-n-n).  So those would be
multiple presentations unless the protocol is augmented.

>     reasons.

Well, we argued against using one RTP session with multiple SSRC IDs
to multiplex separate media streams into that one RTP session.
However, sending a presentation that is one MPEG1 Systems Stream
containing both audio and video in one RTP stream using one SSRC ID is
a valid example of 1-1-1.  Personally, I prefer sending separate MPEG
elementary streams in separate RTP sessions, but others have argued
strongly for the need to send pre-multiplexed encodings such as MPEG1
Systems Streams.

>     kicked around. StreamIDs and URLs are the two basic approaches.

Not quite.  The stream ID proposal definitely falls in this category
because it uses one URL and one RTSP session total.  The URL method
could be 1-1-n if we allow 1 URL != 1 session, as Anup proposed in the
July 11 message.  If there are reasons why that should not be allowed,
then the use of multiple URLs implies multiple sessions.  To provide
the aggregate control would require some other mechanism for grouping
the sessions.  In an earlier message, I suggested that there might be
an aggregate session ID that gets created for the aggregate URL and
which implies aggregate control over the individual sessions/URLs.
That would be 1-n-n and in that scenario there would be no 1-1-n.  One
difficulty in this discussion is that details of how to do the
aggregate control have not been worked out all the way, so we haven't
decided whether 1 URL != 1 session is OK or not.

>     a standard URL implementation, which seems a sticking point.

Only a single command would be needed with an aggregate control
mechanism, as mentioned above.

>     ...multiple files to be tied together as a single presentation.

Actually, they are not a single presentation as defined above.

>     the client has to issue "N" pause commands, "N" seek commands,

This is the core problem.  I don't want the client to have to handle
the synchronization and send N commands if the streams come from
separate file, and need to behave differently if the streams come from
a common container file.  I want the client behavior (and the
protocol) to be the same in both cases.

>     ... _However_ it was

Yes, I think that is true.  But since you folks have re-introduced the
idea of wanting aggregate control (if all the data happens to be in a
container file), then others of us have responded saying that the
aggregate control mechanism should be independent of how the data is
stored and have taken another look at the problem.

> particular RTP addr/port.

That need arises because the previously held assumption of 1 RTSP
session for each RTP session is broken by the 1-1-n proposal.  The
motivations were, as I understand them, so that the server could know
that all the streams were being read from one file and so that all the
streams could be controlled by one PLAY command, i.e., aggregate
control.

> single RTSP control session is a completely different issue.

No.  Separate resources would imply separate URLs, and in the current
spec separate URLs implies separate RTSP control sessions.  If we
don't find a way to change that and we implement the StreamID proposal
instead, then separate resources would imply no aggregate control, but
a container file would allow aggregate control.  This is what I stated
above.

Now, since aggregate control is desirable, we want to find a way to
allow 1 URL != 1 RTSP session, or to find a way to group RTSP
sessions.  Given that we achieve this (and there have been some
methods proposed), then we want to use the same mechanism and a
uniform representation whether the media resources are in one
container file or not.  That's the issue.

> client _does care_.

NO!!  Maybe this is the key misunderstanding.  The client does not ask
for a container file, it asks for multiple media streams if the
session description says there are multiple media streams in the
session and the client wants to receive them all.  It does not (or
should not) matter whether the multiple media streams are stored in
one container file or separate files.

The other case that the client may need to know about is as in the
example of the MPEG1 Systems Stream.  There the client needs to be
able to receive the single, multiplexed RTP data stream and present
the multiple media contained therein.  That might mean demultiplexing
the individual media streams or maybe handing the combined stream to a
hardware decoder/renderer.

Some clients may be able to handle both multiplexed and separate
streams; other clients may handle only one or the other.

> movie.rm is a container, then the server should ... disallow access..."

Yes, as Anup said, the URL for the whole container would not be
SETUPable.

> RTSP control sessions for every container file.

Not if we allow 1 URL != 1 RTSP session as Anup proposed.  If we don't
allow this change, then yes.

> Which is exactly the

No.  I have suggested that it might be possible to group a set of
individual RTSP sessions for each medium under one aggregate session
with its own session ID that is used for aggregate control.  That
grouping might be established in a variety of ways.  I don't have a
preference, at least not yet, between this grouping idea or Anup's
proposal.

> Let's talk

I agree that we should talk about aggregation.  Several of us have
made suggestions as to how it would be done.  Those all result in a
method of targeting streams to ports using just URLs.  Given that
achievement, then I want to write off streamIDs because I don't want
to have two different methods for doing the same thing.  That's the
crux of this argument.

> be on a per stream basis"... Hmmm... maybe that makes sense...

"By jove, I think [he]'s got it!"

> server for "further" processing.

Sorry, I said the wrong thing.  What I should have said was: I would
expect the CGI script to consume the part that composes it's
parameters and pass the rest on to the next module (which it invokes).
I think the web server is finished when it calls the CGI script.  The
CGI script would have to invoke the media server (or the next module
in the media server if it's really a media server and not a web server
that's starting at the top of the URL).

Now, if you think about aggregate control for a minute, you'll realize
a concern.  In a private email, Henning proposed a method for
aggregate control but then said:

> I'm a little concerned about the value of aggregate control since it is
> not completely general: the client has to distinguish the (presumably
> common) case of sessions being served from a single server from those
> where different streams are coming from different servers.

Well, the client doesn't have to draw any complicated inference, if
that is what you mean.  I have proposed that when aggregate control of
the streams is possible, then the session description will contain an
aggregate URI in addition to the URI's for the individual streams
(just as the RTSP spec's definition of "presentation" says there will
be).  If aggregate control is not possible, then the presentation
description will not contain the aggregate URL so the client will know
this explicitly.

Some clients may have the flexibility to support presentations that
don't allow aggregate control, others may not.  In the latter case,
the client will know right away if the presentation requires support
for separate control and can give an error message.

Please note that the protocol allows for aggregate control even if the
streams do come from separate servers if the confederation of servers
can somehow manage to coordinate control of themselves by some means,
magic or otherwise.  In that case, the session description would
include an aggregate URI, and the server receiving control functions
as a result of that URI would be responsible for passing on the
control functions to the other servers in the confederation by
whatever behind-the-scenes means may have been established.

If there are separate servers that are not capable of coordinating
amongst themselves, then either the client would have to be flexible
enough to use separate controls or it would not be able to play that
presentation.  But the key is that the protocol doesn't have to
change.
							-- Steve

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 26 Jul 1997 22:30:57 -0700

Basically, I agree with what Steve said, though my perspective is
from the HTTP protocol and URL parsing point of view.

>that's starting at the top of the URL).

Yes, that's what I meant by donating part of the namespace.  A given
URL can only have one handler per method, and that handler must know
what those parameters mean (if it doesn't, then the handler isn't
capable of handling the request, in which case it isn't a valid "handler").
Of course, if it doesn't have any use for those parameters, then there
won't be any parameters, which is why RTSP can use a relative URL with
extra-path-based parameters on an existing server's CGI or API.

....Roy

---

From: Brad Hefta-Gaub <[email-masked]>
Date: Sun, 27 Jul 1997 17:14:52 -0700

Roy T. Fielding wrote:

> ...

I don't think you guys are listening to me. If I have current day
CGI-bin script working INSIDE MY MEDIA SERVER how can I have it "invoke
a media server" or in some way "pass the rest on to the next module". I
am not talking about something that is "cgi like", I am talking about
precisely cgi.

Roy, what do you mean by, "A given URL can only have one handler per
method"? Are you sure you agree with Steve's idea, because as I
interpret your statement, it would contradict Steve's idea. Namely Steve
assumes the cgi-bin handler will process part of the URL and then pass
it's results back to the "stream splitter handler" built into the media
server to handle the rest of the URL.

I think both of you, Steve and Roy, are hand waving around this issue.
What you don't seem to be thinking about (I can understand this
confusion from Roy since he is so focused on the HTTP perspective) is
that a cgi-bin essentially produces a "file resource" and in the case of
a media server, the media server must "analyze" this file and "break it
up" in such a way that it can send individual streams to the appropriate
RTP ports. Sure we could invent an API that is cgi like that would allow
further invocation, but the current cgi behavior does not allow this.
What I am asking for is a solution that woks with current day cgi-bin
scripts.  The StreamID proposal _does_ work with current day cgi-bin.

Imagine this URL...

  rtsp://server/somepath/something.cgi/someparams/audio
    ^      ^        ^          ^           ^        ^
    |      |        |          |           |        |
    client client   server     server      cgi      server

Notice that the above parts of the system are "interested" in the
various parts of the URL. The problem is that any parts of the URL
following the cgi script (according to how cgi scripts work) will be
sent to the cgi script, as such the server won't be able to get to the
"stream" identification portion of the URL.

Please, stop hand waving about this issue and spell out _exactly_ how
you see a current day cgi bin script working with an RTSP media server
to process these types of URLS.

I _can_ describe exactly how it would work for the StreamIDs in the 822
section proposal, since it is the same rules of interaction for a web
server.

-Brad

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 27 Jul 1997 18:38:49 -0700

I am not hand waving around the issue.  I am assuming you know enough
about how an HTTP server and CGI works to justify asking me personally
about a protocol question instead of just buying a book and figuring it
out for yourself.

The server receives a request, extracts the method and URL, selects
a handler for the request based on that, invokes the handler, and
then processes the output stream.  At no time is the server incapable
of managing its own namespace.

>server to handle the rest of the URL.

What "rest of the URL"?  Either the URL has been handled or it hasn't.
If there is no use for that other part, then there won't be any other part.
If there is a use, than something is going to use it.  In any case, the
client and the media server only care about THE FULL URL.

>scripts.  The StreamID proposal _does_ work with current day cgi-bin.

Anything works with current CGI scripts.  If the media is doing
post-processing of the output response, then absolutely anything in the
output response could be used to indicate what part of the stream is what.
If the media server is smart enough to identify each part of the movie
response as a different stream with a StreamID, then it is equally capable
of identifying them with a URL.  Likewise, since it always sees the URL
before it gets passed to the CGI script, it is always capable of generating
a URL which would identify a sub-resource within the resource.  It would
not be a relative path URL because interaction with the query part of
a potential CGI script would make that impossible.  Most likely, it would
be an encoded prefix placed at the beginning of the PATH_INFO portion,
which could then be easily removed by the media server before passing
the original path info to the CGI.  Yes, I do mean easily, since finding
the CGI script and separating it from the rest of the path is already
being done by any CGI handler.  Since the URL would have to be automatically
generated, the objections about authoring issues are irrelevant.

>  rtsp://server/somepath/something.cgi/someparams/audio

Wrong.  The server cares about the entire URL and the CGI script cares
about what it receives in the separate environment variables associated
with PATH_INFO and QUERY_STRING.  A media server is in complete control
over both what the entire URL is and what part of the entire URL it passes
to the CGI script within those two environment variables.

>to process these types of URLS.

I've done so.  If you can't see that, then I can't help you any further.
Please do not CC me on this discussion again, since it has absolutely
no relevance to the network protocol or the URL parsing algorithm -- what
you are talking about is a trivial implementation detail within the internals
of a server.  It is ridiculous to suggest that you need a protocol change
just to encapsulate a CGI script with a filtering handler.

....Roy

---

From: Bill Simpson-Young <[email-masked]>
Date: Mon, 28 Jul 1997 15:02:14 +1000

> further invocation, but the current cgi behavior does not allow this.

CGI scripts don't return just a "file resource".  They also return (unless 
header parsing's been disabled) a parsable header to the server which 
includes headers such as Content-type, Location etc.  If you have a 
cgi-like interface from the RTSP server, it should be up to the script to 
put any info about stream ids etc into the headers and then the server can 
do what it likes with them.  The server shouldn't have to extract this 
sort of information from the URL.

---

From: Stephen Casner <[email-masked]>
Date: Tue, 29 Jul 1997 11:54:23 -0700 ()

Brad,

> I don't think you guys are listening to me.

I suspect it is more a matter of not sharing the same assumptions,
some of which are unspoken.  There are many details of your
implementation that I don't know about, and it is probably not
appropriate for me to know them.

> If I have current day

Are you saying that every cgi-bin script that works with HTTP should
also work with RTSP without any changes?  That seems to me like an
unreasonable expectation because there are significant differences in
functionality between HTTP and RTSP.  I wouldn't be surprised if the
scripts need to be different.

I'm not even sure what it would mean for the same script to work with
both.  I can take a guess: if you reference an container file or
"container source" with a cgi-bin script in HTTP, then the entire
contents of that file or source would be sent back as a byte stream
over the HTTP connection.  Now, if you want to use that same cgi-bin
script and same URL with RTSP, I would think you should only expect
the same function: the whole, premultiplexed container contents would
be transmitted in one stream, perhaps over the RTSP TCP connection or
perhaps over one RTP/UDP stream.

On the other hand, if the multiple media are to be sent in different
RTP streams, then I would claim one should not expect the same URL and
the same cgi-bin script to suffice.  Additional selection and
processing need to occur beyond the identification of the source.
Perhaps you consider this to just be a transport function, but I don't
agree.

Consider a container file that includes video plus English and French
audio tracks.  The client wants the video to be played with only one
of the audio tracks, so some additional selection information is
required to be fed to the streaming module that reads the container
file and delivers the data.  That should happen in your HTTP scenario
as well, but the cgi-bin script that just finds the file will not do
the job.  If you do augment the script so that it can pass additional
selection information to the streaming module, then the same script
might work for the RTSP case as well.

There is an issue that for the HTTP case you want one URL to select
multiple streams while in the RTSP case I've argued for separate URLs
selecting the individual streams.  However, I'd claim this just
reflects the fact that HTTP and RTSP are not the same: if you want the
video and audio tracks to be kept in separate files rather than a
container file, you'd have some difficulty specifying that in one URL
for the HTTP case and feeding the necessary info to the media
streaming module to build the multiplexed stream.

> scripts.  The StreamID proposal _does_ work with current day cgi-bin.

I guess my short answer is that the expectation to take an existing
cgi-bin script from the HTTP world over to RTSP may not be reasonable
given the additional functionality we want to provide in RTSP.

>   rtsp://server/somepath/something.cgi/someparams/audio

I can imagine several ways to implement the necessary functionality in
a cgi-bin script: invoking a media streaming module directly, or using
some IPC back to the media server or some streaming daemon that's
always running.  But this is based not holding the assumption that an
existing script intended for HTTP will work with RTSP, in return for
avoiding having the data organization on the server be reflected in
the protocol and in the behavior of the client.
							-- Steve