RE: [MMUSIC] End of movie signalling

Hi Joerg,

Thanks for the pointers. Reading between the lines, I would say that there is no
provisioned mechanism for signaling end-of-stream using RFC2326 means only.
Implementations wishing to be backwards compatible should probably revert to
costly tricks. Is this correct?

Spiros

-----Original Message-----
From: Joerg Ott [mailto:jo@informatik.uni-bremen.de]
Sent: Thursday, February 03, 2005 10:23 AM
To: Spiros Spirou
Cc: IETF mmusic WG list; Joerg Ott
Subject: Re: [MMUSIC] End of movie signalling

Hi Spiros,

what you are looking for is being addressed in an addition to the
revised RTSP spec: draft-ietf-mmusic-rtsp-announce-00.txt defines
a generic announcement mechanism that, among other uses, the server
can use to signal end-of-stream to the client.

Please also take a look draft-ietf-mmusic-rfc2326bis-08.txt,
the updated RTSP spec that is supposed to override RFC 2326 in the
not too distant future.

Joerg

>
> Hi,
>
> In a VoD scenario, I am trying to find a STANDARD way to detect the end of a
> movie in the client in order to free the associated resources for control
> (RTSP), transport (RTP) and play-out.
>
> RFC 2326 states that when the server reaches the end of the movie it "...
> reverts from state Playing ... to state Ready ...". From there "... it MAY
> revert to Init and tear down the RTSP session if it has not received
> \"wellness\" information, such as RTCP reports or RTSP commands, from the
client
> for a defined interval, with a default of one minute." Both of these state
> changes happen without sending any notification to the client.
>
> Now, the client could detect the end of movie on its own by maintaining a
> presentation clock, set initially by the Range header in the PLAY reply.
> However, this would probably involve polling, which seems incorrect given the
> usual scarcity of resources in the client platform. A variant of this method
> would be to poll the server by sending PLAY requests without a Range header
and
> reading the current presentation time in the Range header of the reply. This
> adds waste of bandwidth to the waste of local resources.
>
> Any ideas?
>
> Spiros
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>

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