Internet Draft Rob Lanphier February 14, 2002 RealNetworks, Inc. RTP Archiving, Delivery, and Playback (RADPLAY) Extensions for SDP draft-lanphier-radplay-00.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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 14, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines RTP Archiving, Delivery, and Playback (RADPLAY) extensions for the Session Description Protocol (SDP, [RFC 2327]). These extensions provide a standard means of archiving and delivering RTP streams via HTTP, using SDP and the commonly used "rtpdump" file format. As a result of its design, it also provides a way of delivering generic RTP streams over HTTP, thus making it a suitable replacement for approaches which rely on network-unfriendly mechanisms such as "HTTP tunneling". R. Lanphier Expires August 14, 2002 [Page 1] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 Table Of Contents 1 Introduction ................................................ 2 1.1 Requirements .............................................. 3 1.2 Non-requirements .......................................... 3 1.3 Firewall Traversal ........................................ 4 2 Architectural Overview ...................................... 5 3 Parameter Definitions for SDP ............................... 6 3.1 srcfile ................................................... 6 3.2 srcindex .................................................. 6 3.3 srctype ................................................... 6 3.4 dumpfile .................................................. 6 3.5 dumpindex ................................................. 7 3.6 dumptype .................................................. 7 4 Format Dependencies ......................................... 7 4.1 rtpdump ................................................... 7 4.2 seekindex ................................................. 7 5 Usage example ............................................... 8 6 References .................................................. 9 1 Introduction This document defines a standard means of archiving, delivering and playing RTP streams via HTTP, using extensions to the Session Description Protocol (SDP, [RFC 2327]), and using the commonly used "rtpdump" file format. This specification standardizes a set of file formats and conventions for archiving, delivering, and playing RTP streams (though not at the exclusion of more advanced formats). Several features fall out of the design of this protocol: * Simple archive format for local on-demand playback of live presentations. Currently, a typical practice in archiving is to have "rtpdump" run on individual sessions, and then play those sessions back with a tool to dump those files back onto the network. Playback engines that implement this specification would be able to play those files back locally, maintaining proper synchronization between parallel streams. * Simple archive format for HTTP-based on-demand playback of live presentations. The same technique used for local playback also works for HTTP. Additional mechanisms for efficient seeking within those files is also specified. R. Lanphier Expires August 14, 2002 [Page 2] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 * HTTP delivery of live streams. HTTP is often used as a means of getting through strict firewalls. This technique provides a clean way of doing this which uses HTTP as intended, even allowing for caching of the HTTP data (see "Firewall Traversal" below for more on this). * Simple archiving technique for live streams. Any server or proxy which implements this protocol would make it possible to archive streams using standard HTTP clients (e.g. web browsers) * Fallback mechanism for RTSP-based on-demand presentations in the event of network problems. As a result of this specification's design, it provides a way of delivering generic RTP streams over HTTP, thus making it a suitable replacement for other means of firewall traversal by streaming media systems. 1.1 Requirements This proposal is intended to fill the following requirements: * Proper use of HTTP/1.1 [RFC 2616], both in spirit and in letter * Robust delivery of RTP streams through HTTP-only firewalls * Standardized simple archiving of multi-stream presentations * Simplicity of design * Provide benefit beyond simple "firewall traversal", creating a specification that's a good idea regardless of the "firewall problem". 1.2 Non-requirements The following are NOT goals of this specification: * Container file format definition (e.g. AVI or MP4) * Archiving/delivering presentations that cannot be described with SDP * Tunneling protocol definition R. Lanphier Expires August 14, 2002 [Page 3] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 1.3 Firewall Traversal The issue of firewall traversal is a controversial subject. On one hand, there's often a desire to tunnel application-level protocols over HTTP ([RFC 2616]). This perceived need is created by network operators who place devices that violate the end-to-end principle ([END2END]), thus making it challenging to create protocols that work in this environment. Often, network administrators for enterprises will block access to all protocols other than HTTP, and then recommend that enterprise managers purchase products that conform to the arbitrarily challenging environment provided. Once one vendor relents, competitive pressures force the other vendors to follow. On the other hand, there's the need for cleanly designed protocols, and using the network as intended. It is difficult enough to design protocols that work in a world of well-meaning, competent network administrators. Designing around network administrators is a tempting exercise, but can lead to a poorly-designed norm if taken to extremes. The temptation has been so strong that there have been a number of proposals to tunnel application-level and even transport-level protocols over HTTP (including an often cited parody of the practice [RFC 3093]). R. Lanphier Expires August 14, 2002 [Page 4] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 2 Architectural Overview Here's the basic flow for RADPLAY: * Client requests the SDP file for this presentation * e.g http://foo.com/somedir/bar.sdp * This request results in an SDP file may contain any or all of the following elements: * An aggregate control line (defined in [RFC 2326], section C.1.1 "Control URL") * e.g. a=control:rtsp://foo.com/somedir/bar.mp4 * A srcfile line above the m= lines which contains the source media for the RTP stream: * e.g. a=srcfile:http://foo.com/somedir/bar.mp4 * One srcindex line per dumpfile line * e.g. a=srcindex:data:application/seekindex;20s=432 45;40s=86329;60s=... * A dumpfile line above the m= lines with the aggregate packetized data delivered via HTTP in "rtpdump" format (explained below) * e.g. a=dumpfile:http://foo.com/rtpdump/somedir/bar .mp4 * This would be available for the simplest, aggregate presentation of the stream * One dumpfile line below each m= line containing the discrete packetized stream delivered via HTTP in "rtpdump" format (explained below): * e.g. a=dumpfile:http://foo.com/rtpdump/streamid=0/ somedir/bar.mp4 * One dumpindex line per dumpfile line * e.g. a=dumpindex:data:application/seekindex;20s=43 245;40s=86329;60s=... * A c-order line above the m= line, which suggests a connection ordering. * e.g. a=c-order:control dumpfile srcfile * Default value: control srcfile dumpfile * Client attempts one or more of the following steps, either in the following order, or in the order specified in the a=c-order line. * Client makes request as specified in the control line (e.g. rtsp://foo.com/somedir/bar.mp4) * This step may fail because of connectivity issues * Client requests the stream located at the location(s) specified in the srcfile * This step may fail because the client doesn't have support for the container file format * Client makes request as specified in the dumpfile line R. Lanphier Expires August 14, 2002 [Page 5] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 3 Parameter Definitions for SDP The following are new parameters added to SDP. 3.1 srcfile The srcfile parameter is the location of the archive file associated with a particular media presentation. The archive file can be in any format, where the MIME type of the file can be determined using protocol specific means (usually the HTTP Content-type header). 3.2 srcindex If a srcindex is present, then seeking using standard HTTP Range may also be permitted by using the provided mapping of times to byte ranges. The srcindex parameter is a URI [RFC 2396] (which can be a data URL): a=srcindex:data:application/seekindex;20s=43245;40s=86329;60s =... The main reason for making this a URL is that we get the benefit of making this something that can be embedded, or fetched in parallel with the media playing back or only as needed, but as an added bonus it gives us a typing mechanism such that we can switch to a new seekindex format easily. 3.3 srctype srctype is an optional parameter providing the media type of the file referenced by srcfile. Example: a=srctype:audio/mp3 3.4 dumpfile The dumpfile parameter specifies the location of a raw packet capture of the file. Implementations SHOULD implement an rtpdump-formatted [RTPDUMP] version of a stream. The location is specified as a URI [RFC 2396]. Seeking using the dumpfile parameter is achieved through use of the HTTP Range header ([RFC 2616], section 14.35.1), and optionally as extended in RTSP ([RFC 2326], section 12.29). To seek, the client may discontinue any current HTTP GET operation, and issue a new HTTP GET operation with a byte range calculated using the index. R. Lanphier Expires August 14, 2002 [Page 6] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 3.5 dumpindex The dumpindex parameter is a seeking index corresponding to the file identified by dumpfile. This parameter behaves identically to the srcindex parameter. 3.6 dumptype dumptype is an optional parameter providing the media type of the file referenced by dumpfile. Example: a=dumptype:application/rtpdump 4 Format Dependencies These are the formats that are defined elsewhere (or should be defined elsewhere) 4.1 rtpdump A key component in this architecture is the "rtpdump" format [RTPDUMP]. "rtpdump" is an archiving tool and corresponding file format used by many in the multicast community to archive live presentations. The idea behind this proposal is that a streaming server have the capability to translate RTP streams into rtpdump files on the fly, and further have the ability to deliver those files via HTTP while the translation is occuring. ** Ed note: IETF specification for rtpdump format is needed if this specification is to advance within the IETF. ** 4.2 seekindex The "seekindex" format is a simple format for associating times with bytes, for use with HTTP byte ranges. The format needs to be very simple, for optimal use in a data: URL. The BNF is very straightforward: seekindex = (seekindex ";" seekentry)|(seekentry) seekentry = seektime "=" seekbyteindex seekbyteindex = 1*DIGIT seektime = npt-time ; defined in RTSP [RFC 2326] section 3.6 R. Lanphier Expires August 14, 2002 [Page 7] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 Example: 20s=43245;40s=86329;60s=120384 The media type for this format is "application/seekindex" ** Ed note: application/seekindex will probably need to be defined in a separate document ** 5 Usage example Here's an example SDP file that uses these extensions: v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=An on-demand audio file a=control:rtsp://media.example.com/twister.avi a=srcfile:http://media.example.com/twister.avi a=srcindex:http://media.example.com/srcindex/twister.avi m=audio 0 RTP/AVP 0 a=control:rtsp://media.example.com/twister.avi/audio.en a=dumpfile:http://media.example.com/rtpdump/twister.avi/audio.en a=dumpindex:http://media.example.com/dumpindex/twister.avi/audio.en m=video 0 RTP/AVP 31 a=control:rtsp://media.example.com/twister.avi/video a=dumpfile:http://media.example.com/rtpdump/twister.avi/video a=dumpindex:http://media.example.com/dumpindex/twister.avi/video R. Lanphier Expires August 14, 2002 [Page 8] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 Here's how it might be used by a client: * Client receives the SDP file * Client makes RTSP request as specified in the control line to rtsp://media.example.com/twister.avi * If this were to succeed, playback would begin * This step will fail in our example because some firewall administrator is only letting HTTP through * Client requests the on-demand location specified in the srcfile (http://media.example.com/twister.avi) * If the client were to support the container format (e.g. AVI), playback begins * However, in our example, playback fails because the client doesn't have support for the container file format * Client requests the audio and video separately (but in parallel) at the locations specified in the dumpfile locations * Since the client supports the codecs, and supports the rtpdump format, playback works this time * Client optionally requests the dumpindex files for each of the media 6 References [END2END] - Saltzer, J. H., Reed, D. P., and Clark, D. D. End-to-end arguments in system design. ACM TOCS 2, 4 (Nov. 1984), 277-288. [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RF C 2026, October 1996. [RFC 2326] Schulzrinne, H., Rao, A. and Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC 2327] Handley, M. and Jacobson, V., "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC 2396] Berners-Lee, T., Fielding, R.T. and Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC 2616] Fielding, R.T., Gettys, J., Mogul, J.C., Nielsen, H.F., Masinter, L., Leach, P.J. and Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC 3093] Gaynor, M. and Bradner, S., "Firewall Enhancement Protocol (FEP)", RFC 3093, 1 April 2001. R. Lanphier Expires August 14, 2002 [Page 9] Internet-Draft RADPLAY Extensions for SDP XXXX 2002 [RTPDUMP] - The "rtpdump" format, as defined in the source code of the tools available through Columbia University (URL http://www.cs.columbia.edu/IRT/software/rtptools/) Acknowledgements This document has benefitted greatly from the contributions and insights of the following people: Jeff Ayars, Brad Hefta-Gaub, Go Hori, Sean Robinson, Jeremy Worley R. Lanphier Expires August 14, 2002 [Page 10]