Subject: RE: [MMUSIC] RTSP: Minutes telecon 14th of October 2003

From: Thomas Zeng <[email-masked]>
Date: Sun, 26 Oct 2003 22:44:48 -0800

Magnus:

Our use case is best handled by a feature-tag, I think.  Let me clarify:
even if "time=" is deprecated
in Range header in the core spec, we can still "resurrect" it in a extension
to RTSP protocol, as long as
we address any ambuguity (I believe we can)?

More embedded.

thanks,
thomas

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2003 1:33 AM
> To: Thomas Zeng
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003
> 
> 
> Hi Thomas,
> 
> If you have a use cases for this, I think it is possible to keep the 
> timed functionality, under the condition that you provide all 
> necessary 
> specification text to solve the problems with timed PLAYs.

We will either propose timed PLAY or timed PLAYLIST_PLAY.
> 
> I would also like to have some more information about use case.
> 
The use case involves server-side playlist play, where one may desire to
have the option to jump to a new
item in the playlist, but only at the end of the current item.
> The big problem with the timed requests are the following:
> 
> - Are they allowed to be stacked, are multiple possible to be 
> requested 
> for later execution? If yes, the real problems exist.

No, only outstanding timed request is allowed. That is, the stack size is 1.
> 
> - If you use timed requests how does the interaction happens with the 
> state machine. When are the state transition made, when the 
> request is 
> received or when it is executed.

The first PLAY is always executed immediately. So state transition is no
issue.
In another words, timed PLAY is only in PLAYING state for clip transition.
> 
> - How is errors at the time of execution handled?
Error will be reported via event report (say via SET_PARAMETER or ANNOUNCE).
> 
> - If multiple requests are allowed, how does one handle if 
> two request 
> collide.

Again, only one timed request is allowed.
> 
> - How do you stop a timed request, between acceptance and execution?
> 
By sending another PLAY or PLAYLIST_PLAY.
> These are probably not all the problems, simply the ones I 
> can remember 
> of the top of my head.
> 
> So please provide a solution proposal so we can discuss and 
> review if it 
> solves the problems in a satisfactory way.
> 
> cheers
> 
> Magnus
> 
> Thomas Zeng wrote:
> 
> > Magnus:
> > 
> > During one of the telecon for RTSP, I recall that a 
> decision was made to 
> > deprecate "time=" parameter in Range header.
> > 
> > We have found a use case in the context of playlist 
> support, where we would
> > like to use
> > "time=" parameter in Range header in the PLAY request as designed in
> > RFC2326, quoted below:
> > 
> > 10.5 PLAY
> > 
> > ...
> > 
> >    The Range header may also contain a time parameter. This 
> parameter
> >    specifies a time in UTC at which the playback should 
> start. If the
> >    message is received after the specified time, playback is started
> >    immediately. The time parameter may be used to aid in 
> synchronization
> >    of streams obtained from different sources.
> > 
> > 
> > 
> > In light of this, would it be possible to retain this "time 
> parameter"?
> > 
> -- 
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2003 09:59:40 +0100

Hi Thomas,

I don't think there will be any problem with later writing a extension 
draft resolving the problems and how one likes this to work. Through the 
use of a feature tag and a the Require header the client can ensure that 
the server interprets the timed field correctly in such requests. Please 
note that I am not removing the syntactical element, rather declaring it 
as shall not be used in the core spec for other purposes then REDIRECT.

I hope you look over the possible solutions for playlist to find what is 
a good solution.

If one take the simple approach only having the desire to delay the 
start of the playback the problems would not be to hard to solve. 
However it would be simpler if one haves a separate extension draft for 
this rather than using the core specification, which I interprets as 
being your intention.

Cheers

Magnus

-- 

Magnus Westerlund