Support For Stream Caching in Streaming Server 3 Introduction Streaming Server 3 adds new features to RTSP and RTP in order to make it as easy as possible for a caching proxy server to capture and manage a pristine copy of a media stream. Some of these features are elements of the RTSP protocol that were not supported in previous versions. Some are additions to RTSP and RTP - these extensions have already been, or will be soon, submitted to the IETF for consideration as additions to the standard. This document provides a complete description of the stream caching support added to Streaming Server 3. It is intended as a guide for RTSP / RTP caching vendors to use. Four major features have been added: 1. Speed RTSP Header Streaming Server 3 supports the RTSP Speed header wherever possible. This allows a caching proxy server to request a stream to be delivered faster than real time, so it can move a stream into the cache as quickly as possible. For complete documentation on the Speed header, see the RTSP RFC. 2. x-Transport-Options RTSP Header Streaming Server 3 supports a non-standard RTSP header, x-Transport-Options. This header has one currently supported argument, "late-tolerance". This argument allows a caching proxy to tell the server how late packets may be sent and have them still be useful to the cache. A complete description of this header, with examples, is included in this document as Appendix A. 3. RTP-Meta-Info RTP Payload Streaming Server 3 fully supports the RTP-Meta-Info RTP payload format, described separately in an Internet Draft (draft-serenyi-avt-rtp-meta-00). RTP packets of this payload type include important information such as the packet transmission time, unique packet number, and video frame type. Caching proxies can use this information to provide the same quality of service to clients as the origin server. 4. x-Packet-Range RTSP Header Streaming Server 3 supports a non-standard RTSP header, x-Packet-Range. This header is similar to the Range RTSP header, but allows the client to specify a specific range of packets instead of a range of time. This allows a caching proxy to tell the origin server to selectively retransmit only those packets which it needs to fill in holes in its cached copy of the stream. A complete description of this header, with examples, is included in this document as Appendix B. Appendix A: Description of the x-Transport-Options RTSP header. This optional header should be sent from a client to server on a SETUP, and echoed by the server. If the header is not echoed the client must assume that the server does not support this header. The body of this header contains one or more semi-colon delimited arguments. Each argument modifies the contents or delivery RTP packets for the RTP stream specified by the SETUP in a particular way. In the SETUP request, the arguments represent the options the client would like applied to the stream. In the SETUP response, the arguments represent what the server will actually apply to the RTP stream. The response may contain a subset of the arguments requested by the client. This may happen in the event the server doesn't support all the requested arguments, or some don't apply to the RTP stream specified by the SETUP. The server may also modify the values of any arguments it returns. There is currently only one possible argument for the X-Transport-Options header. More arguments may be added later in the event that more fine-grain control is required for the RTSP server's RTP streams. Argument 1: late-tolerance The value of this argument should be a positive integer, representing the number of seconds late a media packet may be sent by the server and still have it be useful to the client. It should be used as a guide to the server to make a best-effort attempt to deliver all media data not older than late-tolerance value. Example: x-Transport-Options: late-tolerance=30 If this is being passed to an RTSP server as part of a SETUP for a video stream, the server should attempt to deliver all video frames unless they are more than 30 seconds old. Frames that are older than 30 seconds can be dropped by the server because they are stale. This can be used by a caching proxy to prevent the media server from dropping frames or lowering the stream bit rate in the event it falls behind sending media data. If the caching proxy knows the duration of the media, setting late-tolerance to that value will prevent the server from ever dropping frames, allowing the cache to receive a complete copy of the media data. For a live broadcast, a caching proxy may want to do extra buffering to improve quality for its clients. The proxy could advertise the length of its buffer to the server this way. Appendix B: Description of the x-Packet-Range RTSP Header This header should be sent from a client to server on a PLAY in place of the Range header. If the server does not support this header it should respond with a 501 Header Not Implemented. The body of this header contains a start and stop packet number for this PLAY request. The specified packet numbers must be based on the packet number RTP-Meta-Info field. For information on how to request packet numbers as part of the RTP stream, see the RTP-Meta-Info payload format Internet Draft (draft-serenyi-avt-rtp-meta-00). The header format consists of two semi-colon delimited arguments. The first argument must be the packet number range, with the start and stop packet numbers separated by a '-'. The second argument must be the stream URL to which these packet numbers belong. Example: x-Packet-Range: pn=4551-4689;url=trackID3 The stop packet number must be equal to or greater than the start packet number. Otherwise, the server may return an error or simply not send any media data following the PLAY response.