80 likes | 284 Views
IETF-58 MMUSIC WG. In IETF I-D database: draft-ietf-zeng-rtsp-end-of-stream-00.txt (on mmusic mailing list: draft-ietf-zeng-mmusic-end-of-stream-01.txt). Signaling End-Of-Stream in RTSP (or RTCP). Thomas Zeng P. Greg Sherwood PacketVideo Corp, Nov, 2003. Background.
E N D
IETF-58 MMUSIC WG In IETF I-D database: draft-ietf-zeng-rtsp-end-of-stream-00.txt (on mmusic mailing list: draft-ietf-zeng-mmusic-end-of-stream-01.txt) Signaling End-Of-Stream in RTSP(or RTCP) Thomas Zeng P. Greg Sherwood PacketVideo Corp, Nov, 2003
Background • Work triggered by the awkwardness of “BYE” • Tasked to create Strawman proposal in Vienna • Lately this work has been “energized” by the desire for server to “push” different types of information to client: • END_OF_STREAM with ending packet number • Session descriptions (and their updates) • Error events • Another background: Sean Sheedy had a “announce” based EOS draft a few years ago, and Ron Frederick had mentioned “Stream done event” in the “RTSP bake-off” report as well (about 3 years ago) • http://www.ietf.org/proceedings/00jul/00july-131.htm 2 7-Nov-03
Background (cont’d) • BYE RTCP packet has been widely used for streaming server to announce “EOS” event • EOS: the end of stream is reached and/or play request has been fulfilled. • Drawbacks of using “BYE”: • “BYE” de-allocates SSRC, thus preventing re-play w/o SETUP again • “BYE” packet may be unreliable (e.g., when carried over UDP) • “BYE” cannot not be aggregated • If BYE is not used and server does nothing to signal EOS, then: • Clients rely on the close Range to figure out when RTP packets are over • If no end range, which is the case for live streaming (or end range is provided in PLAY response but server has to end early due to error) • The client’s transport handler will know if no RTP packet is forth-coming, but the cost can be one or more of the following: • extra delay and/or erroneous requests for re-transmission • even re-buffering if video has low frame rate 3 7-Nov-03
Strawman Proposal Using RTSP • As an extension to RTSP, use a S->C method w/ a feature tag: • Recent suggestion is to use ANNOUNCE instead of a new method name • This method announces EOS event, with optional information on actual range served and the sequence number(s) of the ending RTP packet(s) • MUST include Notice header ( a new header) for event type • Do we need SDP as body of this method? • Request URL can be either aggregate or non-aggregate URI • Opportunity exists to generalize this as a method for server to push other kind of info to client • Need to work out how server can initiate connection to client 4 7-Nov-03
Example of RTSP conversation S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 CSeq: 10 Session: 12345678 Notice: End-Of-Stream Reason: 2000 End of range reached Range: npt=0-200; bytes=0-200000 RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102 C->S: RTSP/1.0 200 OK CSeq: 10 Session: 12345678 /* Second play can reuse SSRC: */ C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 Supported: method.eos CSeq: 110 Session: 12345678 Range: 0-200 5 7-Nov-03
Strawman Proposal Using RTCP • Define a new RTCP packet type (type 205), which has format similar to BYE (but added ending seq no. per SSRC), except it does not mean “leaving the RTP session” • Instead, it means “I am going to stop sending RTP packet until you issue a new PLAY” • RTCP extension really belongs to AVT WG ! • 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • |V=2|P| SC | PT=EOS=205 | length | • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- • | SSRC/CSRC | repeat • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SC times • | extended RTP sequence number | • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- • : ... : • +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ • (opt) | length | reason for EOS ... • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 7-Nov-03
Pros and Cons of The Two Proposals 7 7-Nov-03
What Next • Propose to expand the scope of this draft to cover ANNOUNCE as an extension to RTSP core spec • Pushes events such as EOS • Pushes Session Descriptions as did RFC2326 • Change name of draft to “…rtsp-announce-…” • Work out how server contact client host • Dual-roled host: client to upstream, server to downstream • Acceptable as MMUSIC WG work item? • ANNOUNCE has been taken out of RTSP core spec (rfc2326bis) 8 7-Nov-03