Embedded Plan by LiamMessam

VIEWS: 11 PAGES: 8

									                   IETF-58 MMUSIC WG
       Signaling End-Of-Stream
               in RTSP
                           (or RTCP)
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)


                            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
                           RTSP END_OF_STREAM RTCP EOS Packet
Works for non-persistent   No, unless server can         Yes
RTSP connection ?          initiate connection (TBD)
Aggregatable?              Yes                           No
Reliable?                  Yes, assuming RTSP over No, unless RTP/AVP/TCP
                           TCP                     is used
Works for non-RTP          Yes                     No
transport (e.g., Mpeg2
transport)
Scalable in multicast      No                            Yes
transports?
                                            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

								
To top