Subject: Re: RTSP Bakeoff issues

From: John Carlton <[email-masked]>
Date: Tue, 12 Sep 2000 11:40:42 -0700

I don't like the use "*" in place of the URL in any packet for any reason.
It can be bad for proxies if misused and its especially dangerous if you
start getting fancy with transient connections or sending commands via UDP.

For consistency can we agree to deprecate use of "*" and instead require at
least "rtsp://host[:port]"?

thanks,

John Carlton

At 09:44 AM 9/12/00 -0700, Sean Sheedy wrote:
>Ron Frederick wrote:
>>
>> > >
>> > > 2c. Finally, there were questions about whether it was legal to
allow SETUPs
>> > > for tracks from multiple different (possibly aggregate) objects in a
single
>> > > session, such that they could be controlled together using a single
PLAY
>> > > command. This seems like very useful functionality to me, but it raises
>> > > questions about what URL should be used in the PLAY command in that
case and
>> > > there are some issues that come up between this and the proposals
recently
>> > > discussed here in the RTSP extensions draft
draft-sheedy-mmusic-rtsp-ext-01.
>> > > The proposal at the bakeoff was to allow a "*" in place of the URL
in PLAY
>> > > when a Session was specified, with the meaning being to play all the
tracks
>> > > that were SETUP in that session. However, if you want to support
reuse of
>> > > a single session for multiple different sets of streams as was
described in
>> > > the extensions draft, something more complicated is going to be
required.
>> > > Further work is needed to reconcile all of these cases.
>> >
>> > What if the server returns a dynamically created aggregate URL in the
>> > SETUP response?  That way the client has an unambiguous name to use to
>> > specify the entire collection.  For example:
>> >
>> > C->S  SETUP stream1
>> > S->C  OK Session=1234 URI=myaggregate1
>> > C->S  SETUP stream2 Session=1234
>> > S->C  OK Session=1234 URI=myaggregate1
>> > C->S  PLAY Session=1234 URI=myaggregate1
>> > S->C  OK
>>
>> In a case like this, I'm still trying to understand what value the URI
>> provides at all in the "PLAY", when you already have the Session field. In
>> your example, you could do just as well leaving out the URI in the PLAY and
>> just using a "*", along with Session: 1234.
>> 
>> The one place where I could see it potentially being useful would be if you
>> wanted to set up several different pieces of content in the same session
>> with the intent of playing alternate versions of them rather than playing
>> all of them simultaneously. In that case, the URI in the PLAY could let you
>> specify which subset of the items to play. This sounds complicated to
>> implement from a server standpoint, though, and I'm not sure we'd want to
>> mandate something like that in the spec.
>
>I'm looking for a way to combine this use of "*" with that proposed in
>my draft for use when changing URI's on PLAY.  How about the following,
>which is admittedly a bit rough around the edges:
>
>A "*" for the URI always matches the session's active URI.  The active
>URI is maintained as part of the session state, and changes as the
>session changes state.  At a high level, the active URI is one of: 
>   - The currently playing URI, if in the playing state.
>   - The previously played URI, if in the ready state and a previous
>     play occurred.
>   - The collection of all SETUP URI's, if in the ready state and no
>     previous play occurred.
>
>We can explicitly specify the changes to the active URI by adding to the
>state diagram from the RFC:
>
> state       message received   next state   active URI becomes
> Init        SETUP              Ready        request
>             TEARDOWN           Init         0
> Ready       PLAY               Playing      request
>             SETUP              Ready        active + request
>             TEARDOWN           Init         0
>             RECORD             Recording    request
> Playing     PLAY               Playing      request
>             PAUSE              Ready        active (no change)
>             TEARDOWN           Init         0
>             SETUP              Playing      ???
> Recording   RECORD             Recording    request
>             PAUSE              Ready        active (no change)
>             TEARDOWN           Init         0
>             SETUP              Recording    ???
>
>Definitions:
>  active  = active URI
>  request = URI in request
>
>It's not clear to me what the proper behavior is when a SETUP is
>received in the playing or recording states.
>
>A "*" URI which matches a null URI is an error.  In other words, a
>"SETUP * ..." from init state is illegal.
>
>> > We (nCUBE) have implemented queued PLAY.  MPEG-2 doesn't have the time
>> > stamp problems, etc., on transitions, fortunately.  Even so, we've found
>> > callbacks on transitions useful for clients, who typically want to track
>> > the presentation state.
>>
>> How do you know what sequence number to return in the RTP-Info in the
case of
>> queued play, when you haven't finished playing the previous piece(s)? Also,
>> when you say that MPEG-2 doesn't have the timestamp problem, is that just
>> because all of your movies have a known length up front and a common RTP
>> clock rate, or is there something more to it than that?
>
>As Dirk has pointed out, this isn't an issue when delivering MPEG-2
>without RTP encapsulation (our usual environment).
>
>> > [clarification of session timeouts]
>> 
>> The explicit approach is definitely simplest. In addition, though, I think
>> we definitely want to allow for RTCP-based liveness, so that clients don't
>> necessarily need to keep the control connection open at all during a
>> long playing stream. I'm not really sure we need to worry much about a
>> single control connection having so many sessions that an implicit type
>> of approach is required, but if that is an issue, I think we need to very
>> clearly define how streams are associated with a given connection...
>
>After reading the rest of the discussion about this issue, I've come
>to agree that explicit references to sessions and RTCP-based
>liveness are the mechanisms appropriate for the spec.  I think the
>following still needs to be added:
>
> - A well-defined mechanism for client and server to negotiate
>   an appropriate liveness strategy.  SIP or a subset thereof
>   seems like the appropriate approach.
>
> - The option for clients to use multiple session identifiers
>   on GET_PARAMETER liveness messages.  This would minimize the
>   overhead for clients controlling multiple sessions (e.g.,
>   the bridge servers in Dirk's previous message).
>
>Sean
>
>-- 
>Sean Sheedy                                         [email-masked]
>(503) 531-6427
>
>

---

From: Sean Sheedy <[email-masked]>
Date: Wed, 13 Sep 2000 09:30:06 -0700

> least "rtsp://host[:port]"?

I like this idea.  My only concern would be breaking backward
compatibility on OPTIONS requests if it were required rather than
recommended.

Sean