HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:47:33 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 10 Feb 2000 16:45:00 GMT ETag: "361e35-423f-38a2eb0c" Accept-Ranges: bytes Content-Length: 16959 Connection: close Content-Type: text/plain Internet Engineering Task Force Jay Geagan Internet Draft Mike Kellner Document: draft-periyannan-rtsp-caching-00.txt Alagu Periyannan February 10, 2000 Entera, Inc. Expires: August 10, 2000 Caching Support in Standards-based RTSP/RTP Servers 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. Abstract This document presents the issues facing streaming media caching. It proposes a set of mechanisms to enable streaming media caching between standards-based RTSP/RTP servers and proxies. Streaming media caching refers to the process through which streaming content is dynamically replicated closer to users so as to provide a better viewing experience. A list of RTSP enhancements and open issues are presented. This document is intended to be a starting point for discussion between various parties interested in standardizing the mechanism used by RTSP/RTP servers to enable streaming media caching. Geagan, Kellner, Periyannan [1] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 1. Introduction This document presents the issues facing streaming media caching. It also proposes a set of mechanisms to enable streaming media caching in standards-based streaming servers that use the RTSP [1] and RTP [2,3] protocols. Streaming media caching refers to the process through which streaming content is dynamically replicated closer to users so as to provide a better viewing experience. The replication of the content is done with the co-operation of the origin RTSP/RTP streaming server and a streaming media caching RTSP/RTP proxy that is deployed close to the users. A streaming caching proxy communicates with the origin server to pull the media data into local storage. The communication between the proxy and the origin server is achieved via a few enhancements to the RTSP protocol. Once the media data is in local storage the proxy serves subsequent clients directly via RTSP/RTP with minimal communication with the origin server. The next section presents the issues faced when solving the streaming media caching problem. The section that follows introduces multiple approaches to streaming media caching. The subsequent sections present a streaming caching proposal and discuss the open issues. 2. Streaming Caching Issues A streaming caching architecture should try to solve the following issues, - Transfer Loss A method for caching proxies to create a loss-less copy of the media from the origin server. This is a challenge since the media is normally carried over UDP. - Transformation Loss A method for caching proxies to re-create lost information present in the original media. This is an issue since the media is transformed into RTP packets that may not carry all of the information required to originate the media stream. - Cache Coherency A method for caching proxies to know when the media that is replicated locally is stale, i.e. when newer media is available at the origin server. Geagan, Kellner, Periyannan [2] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 - Access Accounting A robust mechanism for the origin servers to know about hit counts and hit durations from the caching proxies. - Authorization A method for origin servers to authorize caching proxies to serve content from cache. The authorization can be on a per-viewing basis or on a periodic (say hourly) basis. - Copy Protection Sufficient guards against rogue proxies from making unauthorized copies of media content from origin servers. Ideally, the cached content must be in a form that is only useable by proxies that participate in the access accounting and authorization mechanisms. (This is not much of an issue in web caching since web pages are not perceived as being as valuable as media content.) When solving the above issues it must be noted that the administrative/ownership domains of the origin servers, proxies and clients will not be the same in many cases. Content providers or hosting companies will usually own the origin servers, Internet service providers will usually own the caching proxies and individual users will own the streaming clients. It is also worth noting that not all issues mentioned above need to be solved to enable streaming media caching. Some content providers may not care about authorization issues. Others may not care about copy protection issues. Many of the above issues need not be solved in cases where the administrative domain of the origin servers and the proxies are the same. 3. Streaming Caching Approaches The transfer of media data between the origin server and proxy can happen using various approaches. A few of the possible approaches are presented below. Each has its advantages and disadvantages. - File Transfer The original media file is transferred from the origin server to the proxy. Proxies have complete information about the media with this approach. However, proxies need to be able to parse various file formats supported by origin servers. Solving the copy protection issue is harder in this approach since the original media file is transferred to the proxy. Geagan, Kellner, Periyannan [3] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 - Packet Recording RTP packets are recorded as they pass between a client and the origin server. With this approach there is information loss when transforming the media file to packets. There could be additional loss through packet loss since RTP is normally carried over UDP. - Packet Transfer The original media file is not transferred from the origin server to the proxy. Instead the RTP packets generated from the original media are transferred over a loss-less protocol. In addition to the RTP packets some "meta" information present in the media file but not present in the RTP packets is also transferred. Thus, Proxies have complete information about the media with this approach. This document proposes a scheme based on the Packet Transfer approach. The scheme provides a solution to many of the issues presented in section 2. 4. Proposed Mechanisms for Streaming Caching 4.1 Description The proxy contacts the origin server using RTSP and requests that the media be streamed via in-band RTP over TCP. The RTP packets are sent via TCP in a loss-less fashion, i.e. without skipping packets. A new "metachannel" is used to send additional information missing within RTP packets, such as transmission time (not presentation time), key frame flag, etc. Although some of this information may be garnered from within an RTP packet, it will be easier for a proxy to process if it is available via the metachannel in an RTP payload- format independent manner. Copy protection fears are alleviated to some extent since the original media file is not transfer to the proxy. A rogue proxy or client can already record packets given the current RTSP and RTP specifications. The metachannel only adds a few additional pieces of information used for serving the media to clients. The packets sent to the proxy is not in a form that can be easily manipulated or re- authored. Once the media is in the proxy, it can serve the stream from local cache after a few brief RTSP transactions with the origin server. These transactions provide a mechanism for cache coherency, access accounting and authorization. Geagan, Kellner, Periyannan [4] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 4.2 Caching Procedure The following steps describe the interaction between client, proxy and server, a. Client's DESCRIBE Transaction - Client sends a DESCRIBE for an RTSP URL. - Proxy passes on the DESCRIBE to the origin server. - Origin server replies with the SDP description [4]. - Proxy sends the DESCRIBE response to the client. b. Packet Transfer - Proxy compares the Last-Modified header with a previously cached copy (if any) to decide whether to re-fetch the media. - Proxy sends a SETUP on each RTSP stream with a special field in the Transport header requesting a metachannel (described below.) - Proxy sends a PLAY on each RTSP stream and starts transferring the RTP packets and metachannel data into local cache. c. Client's SETUP Transaction - Client sends a SETUP for each RTSP stream. - Proxy sends a SETUP to the origin server with a special transport type of "fromcache". d. Stream Serving from Proxy - Proxy acts like a server and interacts with the client to stream the media. - While the packet transfer operation is proceeding the proxy may decide to serve media to the client in classic non-caching pass- through mode. e. Client's TEARDOWN Transaction - Client sends a TEARDOWN - Proxy sends a TEARDOWN to the origin server 4.3 Metachannel Format The metachannel is used to send additional information that is missing within RTP packets. This information is used in conjunction with the RTP packet to serve clients from the proxy. The RTP/RTCP packets and metachannel packets are interleaved in-band within the RTSP TCP connection. A metachannel packet precedes a set of RTP packets and carries meta information for those RTP packets. Geagan, Kellner, Periyannan [5] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 The following example SETUP message is used to request RTP over TCP with a metachannel (and RTP over UDP as the alternate transport.) SETUP rtsp://foo.com/bar.mov/trackID=3 Transport: rtp/avp/tcp;interleaved=0-1;x-metachannel=2, rtp/avp;unicast;client_port=7000-7001 The RTP and RTCP packets are sent in-band on RTSP channel ID 0 and 1. The "x-metachannel=2" specifies that the metachannel is sent in- band on RTSP channel ID 2. A metachannel packet contains a non-aligned aggregation of TLVs (Type, Length and Value). The information in a metachannel packet pertains to all RTP packets that are sent following the metachannel packet. The packets on the metachannel must be interleaved appropriately on channel 2 between associated RTP packets on channel 0, i.e. correct ordering and placement of packets on channel 0 and 2 is required. The following TLVs are currently defined for metachannel packets, - Name: Relative Transmission Time Type: 1 Length: 4 bytes Description: This is a signed 32-bit number with the transmission time of the packet relative to the RTP timestamp. The timescale of this time is the same as the timescale of the RTP timestamp. - Name: Sample/Frame Flags Type: 3 Length: 4 bytes Description: These flags are attributes of the sample/frame contained in the RTP packets that follow. - I (bit 0) This is an I-Frame, i.e. a key frame or intra-coded frame. This information can also be obtained by parsing the RTP data. However, this will require RTP payload-specific knowledge at the proxy. - B (bit 1) This is a B-Frame, i.e. an inter-coded frame with forward and reverse frame-differencing. This information can also be obtained by parsing the RTP data. However, this will require RTP payload- specific knowledge at the proxy. - P (bit 2) This is a P-Frame, i.e. an inter-coded frame with reverse frame- differencing only. This information can also be obtained by parsing the RTP data. However, this will require RTP payload- specific knowledge at the proxy. Geagan, Kellner, Periyannan [6] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 - Rpt (bit 3) This is the exact copy of a previously sent frame. This flag is useful at proxies to reduce storage. - Req (bit 4) This frame is a "required" frame. It is required to decode all frames after this frame (until the next Req frame.) This flag is useful at proxies when implementing trick modes. The following TLVs are attributes of the stream. They are sent at the beginning of the stream prior to sending any RTP packets or other metachannel packets, - Name: Stream Flags Type: 4 Length: 4 bytes Description: These flags are attributes of the stream. - Rel (bit 0) This stream needs to be sent over a reliable loss-free transport. - PrefRel (bit 1) It is preferred that this stream be sent over a reliable loss-free transport. 5. RTSP Enhancements Required The following changes need to be made to RTSP servers, - Last-Modified header usage in DESCRIBE This header is required for cache coherency checking and is already part of the RTSP specification. The reason it is mentioned in this section is that it is not a required header in an RTSP-compliant implementation. - SETUP method with a special transport type of "fromcache" This is required for access logging and authentication. - New metachannel This is required to get around "transformation loss". 6. Open Issues - Copy protection Copy protection fears are alleviated to some extent but not totally solved. One could argue that this scheme provides a "hook" in origin Geagan, Kellner, Periyannan [7] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 servers to create perfect copies of media content. However, The media sent to the proxy is not in a form that can be easily manipulated or re-authored. - Enforcement of Access accounting and authorization Access accounting and authorization with the origin server is not enforced, i.e. proxies can serve content to clients without communicating with the origin servers (except the first time.) 7. Security Considerations See open issues. 8. Intellectual Property Notice The IETF and its members are hereby notified that Entera Corporation claims certain intellectual property rights, including patent rights, in regard to some or all of the specifications contained in this document. Should this specification be adopted by the IETF, Entera will agree to grant licenses to these rights to interested parties on reasonable and nondiscriminatory terms. For more information contact Entera Corporation. 9. References [1] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Streaming Protocol (RTSP)," RFC 1889, January 1996. [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, January 1996. [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control," RFC 1890, January 1996. [4] Handley, M., Jacobson, V., "SDP: Session Description Protocol," RFC 2327, April 1998. 10. Authors' Addresses Jay Geagan Entera, Inc. Email: j@entera.com Mike Kellner Entera, Inc. Email: m@entera.com Geagan, Kellner, Periyannan [8] draft-periyannan-rtsp-caching-00.txt Feb. 10, 2000 Alagu Periyannan Entera, Inc. Email: alagu@entera.com Entera, Inc. 40971 Encyclopedia Circle Fremont CA 94538 Phone: 510 770 5200 URL: http://www.entera.com Geagan, Kellner, Periyannan [9]