Subject: RE: [MMUSIC] RTSP state machine

From: Thomas Zeng <[email-masked]>
Date: Fri, 1 Mar 2002 14:31:59 -0800

Hello Tom:

You mentioned below that "all current implementations handle end of range
notification
via the transport." 

Actually sometimes it is very inconvenient for transport to know the end of
range, if the range is openned ended, e.g., "0-"(such as those for live
streaming).
Here is an example:

If media is carried by RTP over UDP, the server can send RTCP BYE packet at
the end of the
range. Since RTCP BYE is also carried over UDP, there is no guarrantee that
client will
receive it at all.

How do you propose to solve this problem without a reliable notification via
RTSP? I think someone from another company suggested TEARDOWN from S->C for
this exact purpose.

Regards,
Thomas

-----Original Message-----
From: Tom Marshall [mailto:[email-masked]]
Sent: Friday, March 01, 2002 11:04 AM
To: Magnus Westerlund
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] RTSP state machine

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

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

---

From: Jonathan Sergent <[email-masked]>
Date: Fri, 1 Mar 2002 14:39:03 -0800

On Friday, March 1, 2002, at 02:31 PM, Thomas Zeng wrote:
> I think someone from another company suggested TEARDOWN from S->C for
> this exact purpose.

I am--perhaps irrationally--scared of server-client requests.  Are there 
any known implementations of RTSP that use them?

--jss.

---

From: Tom Marshall <[email-masked]>
Date: Fri, 1 Mar 2002 17:13:35 -0800

> RTSP? I think someone from another company suggested TEARDOWN from S->C for

Why not continue sending RTCP BYE messages until the client acknowledges
with a PAUSE or TEARDOWN?  This would be consistent with the server
remaining in the play state (no automatic server state transition).

---

From: Tom Marshall <[email-masked]>
Date: Fri, 1 Mar 2002 17:15:10 -0800

> any known implementations of RTSP that use them?

I believe our implementation uses them for pings and nothing else.

---

From: Rob Lanphier <[email-masked]>
Date: Fri, 1 Mar 2002 17:53:41 -0800 (Pacific Standard Time)

> I believe our implementation uses them for pings and nothing else.

RealOne Player actually also allows for server->client REDIRECT, which is
used by some of our network infrastructure.

Rob