Subject: Re: [MMUSIC] RTSP state machine

From: Tom Marshall <[email-masked]>
Date: Fri, 1 Mar 2002 11:03:41 -0800

On Thu, Feb 28, 2002 at 05:51:04PM +0100, Magnus Westerlund wrote:
> Hi Rob, Tom and Jonathan,
> 
> I have reconsidered about removing pause state and I can agree that it is
> unnecessary. I attach an updated version of the state machine without the paused
> state. Instead I replaced it with setting of the pause point or as I have called it
> in the state machine resume point (RP). I think that is a better name for it.
> 
> I do believe we have the following  issues regarding pause, play and reaching end
> of media or range.
> 
> - When a presentation reaches end of media or range. Shall it automatically return
> to ready state?
> 
> - When a presentation reaches end of media. What shall the resume point be set to?
> 
> - When reaching end of a range, should the resume point be set to 0 or end of
> range?
> 
> - Should we add a end of clip/range notification.
> 
> I will start with the last issue. I do believe such a mechanism is need for more
> than this reason to signal the state transition. It will also be good for the
> buffer handling, retransmission, adaptation, and notification to user. So I do
> agree that we should add one

I believe that all current implementations handle end of range notification
via the transport.  I don't understand how adding it to the control channel
will be good for the things you say.  It seems to me that an end of range in
the control channel would just duplicate existing functionality.

> Then I do believe you are suggesting a control model like a old tape player, I have
> always thought of it in terms of CD player control. All my CD players return to the
> beginning of the disc when reaching end.

I had not thought about the control in relation to any physical model.  But
yes, I suppose it is closer to the tape player than the CD player.

Rewinding on end of media isn't really that bad of an idea and I could see
where it might be desirable.  But I really think it's a bad idea to rewind
at end of range.  Where do you rewind to?  The start of range, or time zero? 
It just seems messy.

> But one thing we really do need to
> consider is backwards compatibility. Will an RFC 2326 implemented client be able to
> use a server that would requires a pause before each play after the first? I would
> guess that it would get into trouble. Also how should this work relative to queued
> play? Even if we remove as suggested I belive it will be difficult to combine this
> model with that. Therefore I would like to have automatic return to state READY.

I still don't like the idea of an automatic state transition.  If the server
allows the client to issue a PLAY while in the playing state, the clients
which expect queued play will still function but not exactly as expected. 
Has anyone written a client that expects the server to queue plays?

An automatic state transition means that the client must then be prepared to
handle a 455 error to infer that the server reached the end of clip while
its PAUSE message was in transit.  This is a very strong signal to me that
the design is not correct.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Mar 2002 09:29:34 +0100

Hi Tom,

>the control channel would just duplicate existing functionality.
I don't agree that there is a good mechanism for handling end of stream 
or range mechanism. People are talking about RTCP bye, but to my best 
knowledge this message is used for a different reason. You only send 
RTCP bye when the source of the RTCP bye is ending its participant in 
the RTP session. After a RTCP bye that SSRC which has been used is 
blocked as ending for a couple of  RTCP report intervals. So our 
implementation only sends bye when the client does teardown on a media 
stream. So what is the mechanism that all current implementations handle?

>at end of range.  Where do you rewind to?  The start of range, or time zero? 

Yes, It will be messy unless you specify it. If we have strong 
indications that nobody requires this behavior, we can specify that a 
server shall not rewind the media. I would be more satisfied after 
hearing the opinion of the others that has implemented it with automatic 
rewind. 

>>play? Even if we remove as suggested I believe it will be difficult to combine this
I agree that this is a flaw in the current design. The question is it 
possible to fix to something better without totally changing the 
protocol? Without automatic state transitions a client that assumes 
state transition will only be able to issue a single play. I am 
concerned that this is a to big change.

>the design is not correct.
 Your client still must be prepared to handle that, for example if the 
server sends a REDIRECT and while that is in transition, receives a play 
request.

Cheers

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/T/VA
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Tom Marshall <[email-masked]>
Date: Tue, 5 Mar 2002 13:45:18 -0800

> concerned that this is a to big change.

How is the automatic state transition related to removing the queued play? 
If some client expects queued play to work, it will issue a second PLAY
request while already playing.  I see two options for the server in this
case.  It can either refuse the request and send an error back, or it can
honor the request and move the play position to the beginning of the new
request.  I think the latter would be the better choice.

> server sends a REDIRECT and while that is in transition, receives a play 

Yes that is a good point.  RFC2326 says that a client MUST send a TEARDOWN
after receiving a REDIRECT, but it also says that the state changes to Init. 
This is covered in the old state table by saying that a TEARDOWN in the Init
state goes back to the Init state.  I don't see such a line in the new
proposed state table.

I think it makes more sense for the state to remain unchanged, so that the
client's TEARDOWN is what moves the state back to Init.  The server is free
to stop sending packets (if currently playing) while waiting for the
client's TEARDOWN, just as if it had hit the end of a PLAY range.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Mar 2002 15:38:34 +0100

Hi Tom,

The outcome of this discussion seems to be that removing the automatic 
state transitions will simplify the protocol and avoid a lot of special 
cases. So lets work with that assumption and see what implications that 
will have for a client and the backwards compatibility. Then I have a 
question to all you, how should we treat the timed requests? They will 
effect the state but not at the time of reception but at the time of 
execution.

I and a colleague had a discussion and he questioned what entity the 
state machine actually belongs to. In RFC 2326 there are two state 
machines, the client's and the server's, but shouldn't there only be 
one, the session's. The clients state machine is mimic of the session's 
where it tries to keep track of the state in the session. Due to this 
fact shouldn't it actually be simpler if the responses had a state 
header which reports the state of the session after request had been 
performed. This of course is equally complicated for timed requests.

>request.  I think the latter would be the better choice.
I was in fact not thinking of queued plays. The scenario I was trying to 
convey was the following: Client issues the first play in the session. 
Lets the media play to the end. Without automatic state transitions you 
will have to issue the following commands to restart the stream from the 
beginning, PAUSE, PLAY 0-. With an old implementation that is not aware 
the fact that it needs to use PAUSE to return to ready before issuing a 
new PLAY it can't restart. But I believe it will work fine unless the 
media reaches the end.

Your comment about queued play is also of interest and an issue to 
resolve. If the server responds with an error message, it is at least 
clear that queued plays is not supported and it will not change the 
current state. If we use your proposal, we will in fact create an 
alternative way of saying PAUSE, PLAY. In that case we can as well 
define that play is accepted during state PLAYING and will have the 
effect of PAUSE, PLAY. I don't think this a very good solution and will 
be counterproductive in our work to clarify the protocol. The 
indications is that queued play is at the moment a feature not 
implemented in any clients, it that will prevail I would argue for 
cleanly cut out queued plays and mandate that a server should respond 
with "455 Method not valid in this state".

>client's TEARDOWN, just as if it had hit the end of a PLAY range.
Yet another issue to resolve. I have not so far got around to adding 
REDIRECT, ANNOUNCE and RECORD to the state machine.  I added ANNOUNCE to 
the list as it is unclear if you need to receive a session description 
before being able to do record.  I have so far no experience with 
implementation of record, but my guess is that it will need 
clarification also.

Should the session change state when the server issues the REDIRECT to a 
redirecting state? What behavior should the state in that case result 
in? Also how do we handle the REDIRECT with range? Is it possible to 
avoid doing the redirect in some way, for example by pausing before the 
range point is reached?

Regards 

Magnus Westerlund