Subject: [MMUSIC] FW: draft-zeng-mmusic-rtsp-end-of-stream-01.txt

From: Thomas Zeng <[email-masked]>
Date: Mon, 27 Oct 2003 20:17:32 -0800

Dear AVT and MMUSIC members:

Last night, I submitted revision 01 of the strawman End-Of-Stream proposal,
which is the action assigned to me during IETF-57.
See forwarded email.

In this revision, I added "Appendix A" to describe a new RTCP packet for
singalling EOS: the RTCP EOS packet.
My intention is to  present both RTSP EOS and RTCP EOS, and open to the
group to debate whether one or both of them (or none
of them) should be standardized.

Note that in my view defining a special RTP packet is inferior to new RTCP
EOS packet, because RTCP is more suitable for control purposes.
Therefor I didn't present an RTP based EOS solution. The final decision is
up to the group.

As always, your comments are highly appreciated.

Given the differing opinions on EOS signalling, I'd like to request a 15
minutes time slot during MMUSIC session on Nov.14 to
present these alternatives to the group. I will send a separate email to
MMUSIC chairs shortly.

Another note:
   In Appendix A, the sequence number of the ending RTP packet is given for
each SSRC/CSRC in the new RTCP EOS packet. 
It appears to be enough and I don't see a need to also put RTP time of the
ending RTP timestamp in the RTCP EOS packet.

AVT mailing list is CC'ed since if we opt for a new RTCP EOS packet, AVT
would be the WG to get approval.

Thanks,
- thomas

>  -----Original Message-----
> From: 	Thomas Zeng  
> Sent:	Sunday, October 26, 2003 10:34 PM
> To:	[email-masked]'
> Subject:	draft-zeng-mmusic-rtsp-end-of-stream-01.txt
> 
>  <<draft-zeng-mmusic-rtsp-end-of-stream-01.txt>>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Oct 2003 10:12:46 +0100

Hi,

If you have comments on this, lets discuss this on the MMUSIC list. So 
no future cross postings.

Cheers

Magnus

Thomas Zeng wrote:

> ------------------------------------------------------------------------
> 
> 
> MMUSIC                                                     Thomas M. Zeng
>                                                          P. Greg Sherwood
> Internet-Draft                                                PacketVideo
> Expires: April 29, 2004                                     Oct  26, 2003
> 
> 
>               Signalling End Of Stream in Real Time Streaming
>                 draft-zeng-mmusic-end-of-stream-01.txt
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that other
>    groups may also distribute working documents as Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on Apr. 29, 2004.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
> 
> Abstract
> 
>    This document describes a new RTSP method called END_OF_STREAM, which 
>    extends the core RTSP protocol to enable one RTSP protocol entity to 
>    signal other entity(s) 
>    that it has no more media data to send. This request could be issued 
>    either with a 
>    non-aggregate or aggregate control URI, the latter implies that all 
>    media streams 
>    in the aggregate session have run out of media data.
> 
>    The receiver of this RTSP request is expected to reply with 200 OK 
>    response.
> 
>    Since END_OF_STREAM represents an extension to the core RTSP protocol, 
>    a feature tag,
>    "method.eos", is defined to facilitate capability negotiation using 
>    RTSP extension 
>    mechanism [RTSP_NEW].
> 
> 
> 1. Motivation
> 
>    In the core RTSP protocol [RTSP_NEW], an RTSP client relies on the
>    media transport mechanism  to signal end of stream.
> 
>    When the media transport mechanism happens to be RTP over UDP, this 
>    is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are 
>    some drawbacks with this approach:
>      
>      1. When the server sends an RTCP BYE packet with its SSRC, the 
>         server is giving up
>         the SSRC (see section 8.2 in [RTP_NEW]). The server would be 
>         required to 
>         switch to a new SSRC on a subsequent PLAY of the same media 
>         stream.
>         Since server's SSRC is only communicated in the Transport header 
>         of SETUP 
>         response, the server would not have an opportunity to send a new
>         value to 
>         the player, and the client would have to discover the SSRC from 
>         the incoming RTP packets. 
> 
>      2. RTCP BYE packet method does not offer a simple, gurranteed 
>         method of delievering
>         an end-of-stream announcement.
> 
>      3. RTCP BYE packet method does not offer the option to have a single
>         aggregate
>         end-of-stream announcemnt for all media streams in the RTSP 
>         session.
> 
>      4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot 
>         send RTCP BYE 
>         before leaving the RTP session if it has not already sent at 
>         least one RTP or RTCP packet. This is a problem under 
>         error conditions. Consider the case 
>         where an RTP session has just started (i.e., RTSP PLAY has 
>         been 
>         successfully acknowledged with an RTSP 200 OK response), and the 
>         sender attempts to 
>         retrieve media frames from its media source. The media source 
>         fails to provide any media frame due to its internal error such 
>         as file corruption. The sender should inform its receiver(s) 
>         but it cannot send BYE packets.
> 
>    The motivation to solve the above issues is particularly high for 
>    unicast streaming applications that use RTSP over TCP in the control 
>    plane, and RTP over UDP in the media transport. 
> 
>    There is also the desire to have an EOS (End Of Stream) 
>    signalling mechanism 
>    for non-RTP delivery. One such delivery is MPEG2 transport streams 
>    used in the cable TV environment. In non-IP delivery environments, 
>    the transport typically remains allocated even if no media is being 
>    delivered.  This
>    means that a client cannot watch for the server to close the
>    transport to signal the end of stream. Meanwhile,  watching for the 
>    incoming media to stop is unreliable.  Short
>    timeouts can trigger a false end of media detection if the
>    media flow is temporarily delayed.  Long timeouts introduce
>    unacceptable latencies.  Clients are unable to distinguish
>    between a normal end of stream and an error condition that
>    resulted in the media delivery stopping.
> 
>    We note that using TEARDOWN from server to client is not 
>    appropriate because:
>      1. TEARDOWN is currently not allowed from server to 
>         client [RTSP_NEW];
>      2. Even if TEARDOWN is made available in server to client 
>         direction, 
>         the definition of TEARDOWN requires that, if the request 
>         URI is 
>         aggregate, that the session must be de-allocated by the 
>         server. 
>         There are RTSP applications that use SET_PARAMETER from 
>         client to
>         server as the means to report session QoS statistics, but if
>         server uses TEARDOWN on aggregate URL to signal end of stream, 
>         the client can no longer use SET_PARAMETER with a 
>         session header. 
>      3. In general, RTSP, being a client-server protocol,
>         should let client, not server to control session state. But 
>         TEARDOWN
>         on aggregate URL will change session from PLAYING state 
>         to INIT state.
> 
>    We note that using PAUSE from server to client is not appropriate 
>    either, because PAUSE will change the state of the RTSP session.
> 
>    We note also that using ANNOUNCE from server to client is not 
>    suitable, for two reasons:
>       1. ANNOUNCE from server to client is used in RFC2326 to update 
>          session description. 
>          Extending it to indicate end-of-stream event is awkward.
>       2. ANNOUNCE is not in the core RTSP protocol [RTSP_NEW].
> 
>    There has been proposals to extend RTP or RTCP protocol to introduce
>    in-band signalling of end-of-stream events. Appendex A explains
>    one such proposal. We note that in practice both approaches 
>    (using an RTSP method or a special RTP/RTCP packet to signal
>     end-of-stream) have shown up in propriatery implemtations. 
>    Therefore it is our view that allowing both approaches 
>    is a reasonable compromise until a concensus is reached.   
> 
>    The next section describes our solution.
> 
> 3. Solution Using END_OF_STREAM method
> 
>    We introduce a new RTSP method to signal end of stream in applications
>    where an persistent RTSP connection is maintained between server 
>    and client.
>    The new method is an RTSP "extension-method" [RTSP_NEW]. It is called
>    END_OF_STREAM, and is a request from media sender
>    to receiver. In the case of RTSP client playing media streams sent by 
>    RTSP server,
>    the END_OF_STREAM is sent from server to client. In the use case where 
>    RTSP server is
>    recording media sent by RTSP client, the END_OF_STREAM requet could 
>    be sent from an
>    RTSP client to server.  
> 
>    As any other RTSP request method, END_OF_STREAM must be acknowledged 
>    with a response.
>    
>    3.1 The Definition of END_OF_STREAM
>       
>    The END_OF_STREAM request for a URI signals the fact that no more 
>    RTP packets will be
>    sent. Here is an example:
> 
>      S->C: END_OF_STREAM rtsp://foo.com/bar.avi RTSP/1.0
>            CSeq: 10
>            Session: 12345678
> 	   Range: npt=0-200
>            RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102,
>              url=rtsp://foo.com/bar.avi/streamid=1;seq=30211    
> 	   Reason: End of range reached
> 
>      C->S: RTSP/1.0 200 OK  
>            CSeq: 10
>            Session: 12345678
>     
>    An END_OF_STREAM request MUST include "CSeq", "Range" and "Session" 
>    headers.
>    It SHOULD include "RTP-Info" header.
>    The RTP-Info in server's END_OF_STREAM request
>    is used to indicate the sequence number of 
>    the ending RTP packet for each media stream.
>    
>    An END_OF_STREAM requet MAY include a new "Reason" header, 
>    defined as a 
>    string, whose purpose is to allow the server to explain why stream 
>    has ended, and whose ABNF definition is given below:
>     
>           Reason     =  "Reason" ":"   Reason-Phrase CRLF
> 
>    where:
>        -- "Reason-Phrase" is a parameter defined in section 7.1.1 of 
>           [RTSP_NEW].
> 
>    
>    Note that the server is free to use any text as "Reason-Phrase". In 
>    certain applications, the client
>    may  display the text, in its entirety, to end user to improve user
>    friendliness.
>       
>    END_OF_STREAM does not remove session ID, nor does it change the 
>    state of the RTSP session.
> 
>    END_OF_STREAM may be applied to either aggregate or non-aggregate URI.
>    
>    END_OF_STREAM does not apply if the RTSP session is not in PLAYING
>    state. If a client receives END_OF_STREAM while it is not in PLAYING 
>    state, it must reply with a 455 response: Method Not Valid in This 
>    State.
> 
>    We note that client can piggy back QoS statistics as a entity body in
>    its 200 OK response to the END_OF_STREAM request from the server.   
> 
>    3.2 Limitations
>    
>    END_OF_STREAM method is applicable only if the server has the means
>    to contact the client when it reaches the end of a media stream.
>    This may not be possible if the RTSP connection between server and
>    client is not persistent. When it is time to send END_OF_STREAM but
>    the server does not have connection to the client, the server will
>    simply skip END_OF_STREAM. That is to say, the server will not 
>    queue up the END_OF_STREAM message.
>    
> 
> 4. Feature tag
>   
>    The END_OF_STREAM feature is represented by a feature tag (see 
>    [RTSP_NEW]
>    for how to use feature tags in capability negotiations).
> 
>    The feature tag is:
> 
>           method.eos
> 
>    which means that the END_OF_STREAM method is fully supported. By 
>    fully we mean either at non-aggregate or aggregate level.
> 
> 5. Use Case
> 
>    In this example, the server sends END_OF_STREAM request to client for
>    one live media stream, because upstream source terminates the stream
>    after 200 seconds. The fact that the stream has played for 200 seconds
>    is communicated by the Range header in the END_OF_STREAM request.
> 
>      C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
> 	   Supported: method.eos
>            CSeq: 10
>            Session: 12345678
> 	   Range: 0-200
> 
>      S->C: RTSP/1.0 200 OK
> 	   Supported: method.eos
>            CSeq: 10
>            Session: 12345678
>            RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=0; rtptime=0 
> 
>      S->C: END_OF_STREAM rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
>            CSeq: 123
>            Session: 12345678
> 	   Range: npt=0-200; bytes=0-200000
>            RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102 
> 	   Reason: End of range reached
> 
>      C->S: RTSP/1.0 200 OK  
>            CSeq: 123
>            Session: 12345678
>   
>    In the END_OF_STREAM request, the client will learn that the server has 
>    completed the stream as requested (as indicated by the "End of range 
>    reached" Reason).
> 
>    From the two RTP-Info headers, one in PLAY response, one in 
>    END_OF_STREAM requst, the client can derive the total number
>    of RTP packets that the server has sent. From the npt field in the 
>    Range header, the client knows the presentation time that this stream 
>    has covered, from the server's point of view, while the byte-range field 
>    can optional inform the 
>    client how much media data, in bytes, that the server has sent. 
>  
> 5. Security Considerations
>  
>    Because there is only one new TEXT header, "Reason", added by our 
>    new RTSP method,
>    the security considerations outlined in [RTSP_NEW] apply here as well.
>      
> 6. IANA Considerations
> 
>    A new method name, and its associated feature tag need to be registered 
>    with IANA.
>     
>      -- Method name: END_OF_STREAM
>      
>      -- feature tag: method.eos
> 
> 
> 
> 
> Appendix A: Signalling End-Of-Streaming With RTCP EOD Packet
> 
> In this appendix, a new RTCP packet type is defined to signal
> end-of-stream event. 
> 
> A new RTCP packet type is prefered over profile specific extensions
> (see section 6.4.1 of  [RTP-NEW])
> because this feature is profile independent.
> 
> 1. EOS: End-Of-Stream RTCP Packet
> 
>        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                           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        extended RTP sequence number                           | 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                              ...                              :
>       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> (opt) |     length    |               reason for EOS                ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>   The EOS packet indicates that one or more sources have exhausted its
>   media data and will not send any new RTP packet, yet the source is 
>   not about to leave the session.
> 
>   packet type (PT):  8 bits
>      Contains the constant 205 to idnentify this as an RTCP EOS packet.
>  
>   source count (SC): 5 bits
>      The number of SSRC/CSRC identifiers included in this EOS packet.
>      A count value of zero is valid, but useless. For each one of 
>      them, an extended RTP sequence number is included. See below.
> 
>   extended RTP sequence number: 32 bit
>     The extended sequence number of the ending RTP packet from the 
>     source.
>     The low 16 bits contain the sequence number of the ending RTP
>     data packet from source SSRC_n, and the most significant 16
>     bits extend that sequence number with the corresponding count of
>     sequence number cycles. The RTP receiver needs to track the
>     extended sequence number to properly generate RTCP
>     RR packets, hence it can easily determine which RTP packet is the
>     ending RTP packet.
> 
> 2. Rules of sending RTCP EOS packet
> 
>   RTCP EOS packet should be sent if the source runs out of media data,
>   but is NOT about to leave the session. It may, for instance, wait
>   for the receiver to send anther RTSP PLAY request (if RTSP is the
>   session contorl protocol in use) and then re-use the SSRC to send
>   RTP packets.
> 
>   If an EOS packet is received by a mixer, the mixer SHOULD forward
>   the EOS packet with its SSRC/CSRC identifier(s) unchanged.
> 
>   Optionally,  the EOS packet MAY include an 8-bit octet count 
>   followed by that many
>   octets of text indicating the reason for ending, e.g., "End of file" 
>   or "Upstream EOS received".  The string has the same
>   encoding as that described for SDES.  If the string fills the packet
>   to the next 32-bit boundary, the string is not null terminated.  If
>   not, the EOS packet MUST be padded with null octets to the next 32-
>   bit boundary.  This padding is separate from that indicated by the P
>   bit in the RTCP header.
>   
>   When RTP is carried over un-reliable transport (e.g., UDP), an RTP 
>   source may repeatedly send RTCP EOS packets until it is assured that
>   the receiver(s) have got the event notification -- e.g., it has
>   received another RTSP PLAY request from the RTP receiver.  
> 
> ^L
> Normative References
> 
>    [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 
>          "Real Time Streaming Protocol", 
>          draft-ietf-mmusic-rfc2326bis-04.txt
> 
>    [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> 
> 
> 
> 
> 
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Acknowledgement
> 
>    Thanks to Sean Sheedy for suggesting the inclusion of "Range" header
>    and for contributing some text in the motivations section.
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> Author Addresses
> 
>    Thomas Zeng
>    PacketVideo Corp.
>    10350 Science Center Dr., Suite 210
>    San Diego, CA 92127
>    email: [email-masked]
> 
>    P. Greg Sherwood
>    PacketVideo Corp.
>    10350 Science Center Dr., Suite 210
>    San Diego, CA 92127
>    email: [email-masked]

-- 

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]

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