Hi,

Do agree with Sean that Play while playing is a good feature. However it 
  do surface the issues RTSP has with the state machine and state 
transitions.

First of all I would like to inform on a what Sean and I have written on 
this method usage. PLAY request can be received by the server in play 
state. The new request replaces the previous request, and work in fact 
the same way a PAUSE, PLAY pipelined request would work. I have also 
added a proposal to have the new PLAY request having an open start point 
(npt=-30) to allow one to continue playing where one currently are, and 
basically only change the rest of the range header. This would allow one 
to replace a PLAY request with Range:npt=0- with a NPT header saying 
npt=-50;npt=20-30;npt=200-300 as long as this request arrives before the 
server has passed 50. This can in fact be used to implement queued play 
without the issue of having the list of jumps needing to be handled on 
the server side. As I see it has very little implementation burden.

Back to RTSP and its state machine. With this PLAY in play state 
mechanism the difference between ready and play state is not as clear as 
one would desire. A lot of what one can do in ready is also possible in 
play state. The issues as I see it with the RTSP state machine is that 
one really would like to have it drop to ready state as soon as it has 
finished playing. However this would require that the server could send 
asynchronous messages to indicate that state transition. Otherwise and 
the reason that state machine looks like it currently does, is to avoid 
the server initiate implicit state transitions in cases where it doesn't 
result in session termination.

Unfortunately I don't see any easy way out of this dilemma. The 
alternatives are as I see it:

1. Introduce these messages into RTSP. However this is quite a serious 
change which I don't know if we can muster the energy for. However this 
would resolve the end of stream issues.

2. Let the end_of_stream draft resolve the issue.

3. Do nothing to the state machine and except that the states are not a 
straightforward as one would expect.

4. Introduce a recovery mechanism that could introduce explicit state 
indication to inform the client about which state the server was when 
receiving the request and failed to handled it and which state it ends 
up in after successful execution of a request. One could even introduce 
a required-state header that ensures that the request only is executed 
in the state one currently is in.

 From a protocol perspective I would think that doing both 1 and 4 would 
be the best. However I a bit worried about introducing these at this stage.

Feedback solicited.

Cheers

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: magnus.westerlund@ericsson.com

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic