Subject: RE: [MMUSIC] End of movie signalling

From: "Thomas Zeng" <[email-masked]>
Date: Thu, 3 Feb 2005 09:43:21 -0800

Hi  Spiros:

Your transport is RTP, right? Can you not use RTCP BYE to signal end-of-stream until draft-ietf-mmusic-rfc2326bis-08.txt and draft-ietf-mmusic-rtsp-announce-00.txt are ratified?

Cheers,
-thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Spiros Spirou
Sent: Thursday, February 03, 2005 4:08 AM
To: Joerg Ott
Cc: IETF mmusic WG list
Subject: 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:[email-masked]]
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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
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: "Spiros Spirou" <[email-masked]>
Date: Fri, 4 Feb 2005 09:21:19 +0100

Hi Thomas,

Thanks for the suggestion. I had thought about that but I am trying to cover
cases where the server is not implementing RTCP as well (oh yes, these heathens
do exist). Anyway, the four reasons you are mentioning in Appendix A of
draft-ietf-mmusic-rtsp-announce-00.txt against the use of RTCP BYE as an
end-of-stream signaling mechanism are certainly valid in general.

I am oriented towards maintaining a presentation clock (npt) in the client for
detecting EOS locally in the case of RFC2326 servers. This has the added feature
of being able to display to the user the running play time, remaining time etc.
just like DVD players can. I could add support for
draft-ietf-mmusic-rtsp-announce-00.txt as it progresses in order to be forwards
compatible.

Spiros

-----Original Message-----
From: Thomas Zeng [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 6:43 PM
To: Spiros Spirou; Joerg Ott
Cc: IETF mmusic WG list
Subject: RE: [MMUSIC] End of movie signalling

Hi  Spiros:

Your transport is RTP, right? Can you not use RTCP BYE to signal end-of-stream
until draft-ietf-mmusic-rfc2326bis-08.txt and
draft-ietf-mmusic-rtsp-announce-00.txt are ratified?

Cheers,
-thomas

-----Original Message-----

Hi Joerg,

Spiros

-----Original Message-----
From: Joerg Ott [mailto:[email-masked]]
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,

Joerg

client
and

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Feb 2005 10:17:33 +0100

Hi,

> Your transport is RTP, right? Can you not use RTCP BYE to signal end-of-stream until draft-ietf-mmusic-rfc2326bis-08.txt and draft-ietf-mmusic-rtsp-announce-00.txt are ratified?

I would like to point out that if one sends a RTCP BYE, that means that 
the SSRC sending the BYE is leaving the session. Thus you get some 
semantics that is not desirable by using RTCP BYE for end of stream 
notification. I know that it occurs, but in my eyes it is not a correct 
behavior and should not be endorsed.

The RTCP BYE message should comes as a result of a TEARDOWN of that RTP 
session. A SETUP that changes the RTP session, like new ports should 
also result in RTCP BYE on the old session.

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: [email-masked]