INTERNET-DRAFT A. Klemets draft-klemets-asf-rtp-00 Microsoft Corporation October 8, 1997 Expires: April 8, 1998 RTP Payload Format for ASF Streams Status of This Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document specifies the payload format for encapsulating Advanced Streaming Format (ASF) streams in the Real-time Transport Protocol (RTP). This specification is primarily intended for ASF media types or codecs that are not already handled by other RTP payload specifications. Each ASF stream is sent with a separate RTP synchronization source ID and the streams are synchronized using standard RTP techniques. A special encapsulation scheme for ASF streams is described, where each RTP packet contains an ASF payload header and an ASF payload. This specification is primarily intended for streaming ASF streams that do not require reliable transfer. 1. Introduction This document specifies the payload format for encapsulating ASF streams in the Real-time Transport Protocol (RTP) [2]. RTP is a protocol for carrying arbitrary real-time data. Each RTP packet contains a sequence number and timestamp, which can be used by a receiver to detect losses and present the data at the right time. RTP uses a control protocol, RTCP, which can be used to synchronize A. Klemets [Page 1] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 different real-time streams. For synchronization to be possible, the streams must be transmitted such that each stream has a distinct RTP synchronization source (SSRC) identifier. RTP is most commonly used over UDP. However, it may be used with any transport protocol that detects bit errors, and that conveys the length of an RTP packet. RTP does not specify a mechanism for the reliable transfer of data. The protocol does also not address the encapsulation of specific media types, but instead defers it to various profile specifications. An RTP profile document for audio and video conferencing [3] was released together with the RTP specification. The profile defines payload types for various media types. Other documents specify additional payload types and profiles. ASF is an extensible file format for synchronized multimedia streams. The format is not tied to any particular media type or compression scheme. ASF also allows a user to create new media types. The RTP profiles and payload types that are currently defined only cover a limited set of media types. Thus, it is desirable to define a general encapsulation scheme that allows any ASF stream, regardless of its media type, to be sent as an RTP payload. This specification proposes such a scheme. The scheme is primarily intended for ASF streams that do not require reliable transmission. 2. ASF Overview The Advanced Streaming Format is defined in [1]. An ASF file consists of three top-level objects: The Header Object, the Data Object and the Index Object. The Header Object contains other objects that describe the streams that are contained in the Data Object. One of the many functions of the Header Object is to specify the media type and encoding for each stream. It may also rank or group sets of streams. An important feature of ASF is support for receiver-driven stream selection. It means that not all streams contained in an ASF file need to be part of the same multimedia presentation. The receiver, or user, of an ASF file may in some cases be expected to play only a subset of the available streams. The ASF Header Object contains various other objects that influence, or specify, stream selection. One example is the Mutual Exclusion Object, which defines a set of streams from which only one single stream should be chosen. Another example is the Prioritization Object, which is used to assign an importance ranking to streams. If a receiver can only play a limited number of streams, it can use the ranking as a suggestion for which streams to choose. A. Klemets [Page 2] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 The Data Object contains all the data for the streams that are defined in the Header Object. The internal structure of the Data Object is a sorted collection of ASF Data Units. Due to the way Data Units are sorted, consecutive Data Units may contain data from different streams. An important concept in ASF is that there are two timestamps associated with each Data Unit, the Send Time and the Presentation Time. In a system where an ASF stream is sent in real-time from a transmitter to a receiver, the Send Time value specifies when the transmitter should send a given ASF Data Unit. The Presentation Time value specifies when the ASF Data Unit should be rendered at the receiver. The use of two timestamps allows the creator of an ASF stream to control when an ASF Data Unit is sent. This is especially useful when storing data that should be transmitted in real-time, because it becomes possible to "smooth" the output of a bursty data source to generate a near-constant bit rate stream. Each stream consists of a sequence of Stream Data Objects. Each of which may correspond to a video frame or a group of audio samples, for example. There is not a one-to-one mapping between ASF Data Units and Stream Data Objects. An ASF Data Unit may contain a single, fragment, or group of Stream Data Objects. The third top-level object in an ASF file, is the Index Object. As the name implies, this object provides indexes for each stream into the Data Object. This permits random access operations on streams. 3. Transmission of ASF streams over RTP An ASF file consists of a set of objects that may in turn contain other objects. The following sections specify how these objects may be communicated to an RTP receiver. 3.1. Transmission of the ASF Header Object The interpretation of an ASF Data Unit is dependent on the media type, and other parameters, all of which are defined in the ASF Header Object. If ASF Data Units are sent over RTP, the Header Object must also be reliably communicated to the RTP receivers. However, it would be impractical to transmit the Header Object in every RTP packet, as its size may be large. The approach that has been adopted for this specification is to transmit the Header Object using non-RTP means. This means that the Header Object should be transmitted using a protocol other than RTP. A. Klemets [Page 3] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 The Header Object can be transmitted any number of times, during, prior, or even after the transmission of the Data Units. The main disadvantage with this approach is that the ASF stream that is transmitted over RTP is useless to any receiver that does not have access to the Header Object. An alternative approach, which can be described as a hybrid solution, is to break out information that is crucial for decoding the ASF stream from the Header Object, and transmit that information over RTP. Not every RTP packet would need to carry the additional information. It might suffice to include it once every couple of seconds. Additional information in the Header Object that is not directly related to decoding the stream, could be communicated through non-RTP means, or sent at a low frequency over RTCP. For an example of where this approach is used, see reference [6]. In spite of the benefits of a hybrid approach like the one just described, large parts of the ASF Header Object would have to be communicated to the receiver prior to start of the RTP transmissions. This is necessary, because in order for receiver-driven stream selection to work (see section 2), the receiver needs to be able to examine the Header Object before the RTP transmissions begin. Thus, the hybrid approach would add extra complexity, while still requiring the use of a non-RTP means distribution scheme. A possible distribution mechanism for the ASF Header Object is through the use of the Real Time Streaming Protocol (RTSP) [4]. A media server can use RTSP to provide a "Presentation Description" of streams that it is offering to transmit over RTP. Such a Presentation Description could be used to distribute the ASF Header Object. 3.2. Transmission of the ASF Index Object The purpose of the Index Object is to facilitate random access to the streams contained in the Data Object. The index entries refer to ASF Data Units in the order they are laid out in the Data Object. Hence, its primary usefulness is to the RTP transmitter, who has access to the Data Object. It is not necessary to transmit the Index Object to the RTP receiver. If the receiver wishes to save the streams in an ASF file, it can regenerate the Index Object. The Index Parameters Object, which is contained in the Header Object, provides sufficient information for the receiver to generate its own Index Object. 3.3. Transmission of the ASF Data Object The ASF Data Object consists of Data Units. Any given Data Unit only contains data belonging to a single stream. As a consequence of this A. Klemets [Page 4] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 structure, it is natural to transmit each Data Unit in an RTP packet. The data belonging to an ASF stream consists of Stream Data Objects. Data Units serve as containers for such objects. Large Stream Data Objects can be fragmented across multiple Data Units, and small ones can be grouped together in a single Data Unit. Correct playback of an ASF stream does not depend on the size or number of Data Units, as long as the Stream Data Objects can be correctly extracted from the Data Units. This means that an RTP transmitter can fragment large Data Units into smaller ones, and coalesce small Data Units into a larger one, without it affecting the logic of the ASF decoder. A Data Unit consists of a number of fields, some of which are optional. Section 4 describes an encapsulation scheme for transmitting the contents of ASF Data Units over RTP. The scheme eliminates some of the fields, and places some of them in the RTP header. Other fields are placed in an ASF Payload Header, which is defined in section 4.2. Additional fields, including the data belonging to Stream Data Objects are placed in the ASF Payload, which is defined in section 4.3. The ASF Payload Header and the ASF Payload is encapsulated in an RTP packet. 3.4. Mapping between ASF Streams and RTP Sessions In this proposal, each ASF stream is identified as a separate RTP synchronization source (SSRC). The mapping between the ASF stream number and the SSRC is established through non-RTP means. It is expected that all RTP packets carrying the ASF Payload Header will use the same RTP payload type. If a static RTP payload type is assigned for the encapsulation scheme described in this memo, it should be used. Otherwise, a dynamic payload type may be used. The transmitter and the receiver agree upon a dynamic payload type through non-RTP means. 3.5. Reliable transfer of ASF streams Each ASF stream has a set of properties associated with it. These properties are described in the Stream Properties Object, which is included in the Header Object. One of the properties is the Reliable Flag. If the Reliable Flag is set, it means that this particular stream must be carried over a reliable transport mechanism. This memo does not define such a mechanism. See reference [5] for a survey of proposed reliability enhancements to RTP. However, none of the schemes covered by the survey provide guaranteed reliability. Use of a transport protocol that guarantees reliable delivery, such as TCP, might be an alternative. But since TCP does not have real- time characteristics, and is limited to point-to-point transfers, it may not always be an appropriate choice. A. Klemets [Page 5] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 4. RTP Encapsulation Format The following figure gives a high level view of the RTP encapsulation format. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . RTP Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . ASF Payload Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . ASF Payload . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Layout of the RTP packet. The format of the ASF Payload Header and the ASF Payload is described in sections 4.2 and 4.3. 4.1. RTP Header Usage Several fields in the RTP header are assigned a special meaning in the context of this specification. The use of the fields is as follows: Payload Type: If a static payload type is assigned for this specification, its value should be used. Otherwise a dynamic payload type may be used, which should be agreed upon through non- RTP means. Marker bit (M bit): The M bit is set to 1 when the RTP packet contains one or more complete ASF Stream Data Objects, or if it contains the last fragment of a fragmented Stream Data Object. Note that the use of the M bit in this manner is redundant, since the last fragment can also be detected through Offset Into Object field and Object Size field in the ASF Payload Header. However, using the M bit in this way is conformant with the RTP payload type definitions for other frame-based payloads, which are defined in [3]. A. Klemets [Page 6] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 Timestamp: The RTP timestamp is set to the Send Time field in the ASF Data Unit. The clock frequency of the timestamp is the same as for the Send Time field, namely 1 kHz. This frequency is high enough to provide sufficient precision for RTCP jitter calculations and synchronization of streams through RTCP Sender Reports. A random constant may be added to the timestamp, in order to make known-plaintext attacks on encrypted data more difficult. The value of the constant should be communicated to the receiver through non-RTP means, so that the value of the Send Time field can be calculated at the receiver. The timestamp may also be multiplied by a non-zero factor, to ensure that the timestamp is increasing monotonically at the same rate as packets are being sent, even if ASF Data Units are being sent in reverse order or at a rate faster than their normal transmission rate. Synchronization Source (SSRC): The SSRC is chosen randomly by the RTCP transmitter. A mapping is maintained between the SSRC and the ASF stream number. This mapping is communicated to the RTP receivers through non-RTP means. If the transmitter changes the SSRC, due to the detection of an SSRC conflict or otherwise, the updated mapping must be communicated to the receivers. 4.2. ASF Payload Header An ASF Data Unit is used to generate the ASF Payload Header and the ASF Payload, which subsequently are encapsulated by the RTP header. Because ASF has been designed to support a variety of media types, there are many optional fields in an ASF Data Unit. Several of the fields are of variable size. The design of the ASF Payload Header attempts to retain the flexibility of the Data Unit, while limiting the number of ways optional header fields can be combined. An additional requirement imposed on the Payload Header is that each field should be properly aligned relative to its data type. This encapsulation format allows an ASF Stream Data Object to be fragmented across multiple RTP packets. Unlike other frame-based RTP payload types that support fragmentation, the ASF Payload Header contains an explicit field for the offset into the fragmented object, and a field for the total size of the object. Many other RTP payload formats use only the RTP M-bit to indicate fragmentation. The additional fields are required because ASF is a container for arbitrary media types. Decoders for certain media types may be able to process Stream Data Objects even if the RTP packets carrying some of the fragments have been lost. But this processing may only be possible if the position of the missing fragments can be determined, relative to the entire Stream Data Object. Hence the additional fields. A. Klemets [Page 7] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 The ASF Payload Header is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|F|G|C| RES | Object ID | Delta Presentation Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Presentation Time . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Offset Into Object . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Object Size . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Extension Data . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. ASF Payload Header format. All fields in the ASF Payload Header are in network byte order unless otherwise is stated. The fields have the following meanings: P: 1 bit. If this bit is set to 1, the Presentation Time field is present and the Delta Presentation Time field should be set to 0. A receiver must ignore the Delta Presentation Time field when this bit is 1. F: 1 bit. If this bit is set to 1, the ASF Payload contains a fragmented Stream Data Object. The Offset Into Object and Object Size fields are only present when the F bit is 1. G: 1 bit. If this bit is set to 1, the ASF Payload contains multiple Stream Data Objects. If the F bit is 1, the meaning of the G bit is undefined. C: 1 bit. This bit is set to the value of the Clean Point flag in the ASF Data Unit. If the F bit is 1, the C bit must be set to the same value on all fragments that make up the Stream Data Object. Note that if the G bit is 1, the C bit refers only to the first Stream Data Object in the ASF Payload. RES: 4 bits. This field is reserved for future use. It should be set to 0 when writing the header, and it should be ignored when the read. A. Klemets [Page 8] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 Object ID: 8 bits. This is the ID of the Stream Data Object that is contained in the ASF Payload. If the ASF payload contains multiple objects, this is the ID of the first object. Delta Presentation Time: 16 bits. If the P bit is 0, this field is used to calculate the Presentation Time of the first Stream Data Object in the ASF Payload. The field is expressed as a signed integer. Its value is calculated as the difference between the Data Unit Presentation Time and the Data Unit Send Time fields, measured in Rational Units. The definition of Rational Units is stream-specific, and it is specified in the ASF Stream Properties Object, which is part of the ASF Header Object. If the P bit is 1, the Delta Presentation Time field should be set to 0 and it should be ignored when the field is read. Presentation Time: 32 bits. This field is only present when the P bit is 1. It contains the Presentation Time of the first Stream Data Object in the ASF Payload. The field is expressed in Rational Units. The definition of Rational Units is stream- specific, and it is specified in the ASF Stream Properties Object, which is part of the ASF Header Object. Offset Into Object: 32 bits. This field is only present when the F bit is 1. The ASF Payload contains a fragment of a Stream Data Object. This field gives the offset into the Stream Data Object, measured in bytes, of the beginning of the fragment. Object Size: 32 bits. This field is only present when the F bit is 1. The ASF Payload contains a fragment of a Stream Data Object. This field gives the total length of that object, measured in bytes. Extension Data: variable size. The length of this field is stream-specific, and it is specified in the ASF Stream Properties Object, which is part of the ASF Header Object. The byte order of the data in this field is stream-specific. The Stream Number field from the ASF Data Unit is not included in the ASF Payload Header, because the Stream Number is communicated through the RTP SSRC field. The size of the ASF Payload Header depends on the value of the F and P bits, as well as the size of the Extension Data field. In spite of its variable layout, it is possible to efficiently compute the length of the ASF Payload Header, using simple bit level arithmetic. On a little-endian system, the length of the ASF Payload Header, excluding the Extension Data field, can be computed through this C-style expression: A. Klemets [Page 9] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 ((b & 0x3) + 1) << 2 The variable b is of the type "unsigned char" and holds the first byte of the ASF Payload Header. The result of the expression is measured in bytes. 4.3. ASF Payload If the F and G bits in the ASF Payload Header are both 0, the ASF Payload contains a single complete Stream Data Object. If the F bit is 1, the ASF Payload contains a partial Stream Data Object. If the F bit is 0, and the G bit is 1, the ASF Payload contains one or more complete Stream Data Objects. The Object ID field in the ASF Payload Header is the ID of the first Stream Data Object. The ID of the next object must equal the ID of the previous object plus one, modulo 256. The first Stream Data Object in the ASF Payload is preceded by a length field. Any additional Stream Data Objects are preceded by a Delta Presentation Time field, as well as a length field. The format of the ASF Payload is given below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Length | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . Stream Data Object . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Presentation Time | Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Stream Data Object . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Example of ASF Payload when F=0 and G=1. Figure 3 shows the situation when the F bit is 0 and the G bit is 1. Two Stream Data Objects are shown, but an unlimited number of Stream Data Objects may be included in the ASF Payload. All fields in the ASF Payload Header are in network byte order unless otherwise is stated. The fields have the following meanings: A. Klemets [Page 10] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 Object Length: 16 bits. This field gives the length, measured in bytes, of the Stream Data Object that follows it. Stream Data Object: variable size. The length of this field is given by the Object Length field that preceded it. The byte order of the data in this field is stream-specific. If this is not the first Stream Data Object in the ASF Payload, its Object ID value must equal the Object ID value of the previous Stream Data Object plus one, modulo 256. Delta Presentation Time: 16 bits. This field is used to calculate the Presentation Time value of the next Stream Data Object in the ASF Payload. The field is expressed as a signed integer. Its value is calculated as the difference between the Presentation Time field of the next Stream Data Object and the Presentation Time field of the previous Stream Data Object, measured in Rational Units. The definition of Rational Units is stream- specific, and it is specified in the ASF Stream Properties Object, which is part of the ASF Header Object. 5. Open issues The minimum size of the ASF Payload Header is currently four bytes. It is expected that in many cases, the Presentation Time will be equal to the Send Time, in which case the Delta Presentation Time field will be zero. If this is such a common case, it might be warranted to make the Delta Presentation Time field optional. A bit in the first byte of the ASF Payload Header would indicate whether the field is present. This would reduce the minimum size of the header to two bytes. However, this will make parsing of the Payload Header more complicated. When other optional fields are present, the Delta Presentation Field would have to be included to ensure that all fields are properly aligned. Furthermore, the ASF Payload would not be 32 bit word aligned when there are no optional fields are present in the Payload Header. A. Klemets [Page 11] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 Appendix 1. Recommendations for ASF file creators. ASF is a very flexible format, and as a consequence there are many different ways of generating an ASF-compliant file. It is possible to optimize the structure of an ASF file for special environments and applications. However, this may result in the file being streamed with less than optimal efficiency over RTP. This section addresses some issues to keep in mind in order to generate ASF files suitable for streaming over RTP. Be aware of the overhead of using high precision Rational Unit values. The Delta Presentation Time field in the ASF Payload Header expresses the difference between the Presentation Time and the Send Time, measured in Rational Units. The default definition of Rational Units corresponds to a clock frequency of 1 kHz. The largest value that can be expressed by the Delta Presentation Time field is inversely proportional to the clock frequency. When the value is too large, the 32 bit Presentation Time field must be used, thus increasing the overhead imposed by the ASF Payload Header. The default 1 kHz frequency allows a maximum value of 32 seconds to be expressed by the Delta Presentation Time field. However, a 90 kHz frequency would only allow a maximum value of 0.36 seconds. Be aware of the network MTU. The Ethernet MTU is 1500 bytes. If a minimum ASF Payload Header and transmission over UDP is assumed, this means that the largest ASF Payload that can be sent without fragmentation is 1456 bytes. If the ASF Payload to be sent is larger than this, fragmentation must be done at the RTP level, or otherwise IP will fragment the UDP datagram. In either case, it is inefficient. Do not group objects with different Clean Point flag values. Because there is only one Clean Point flag in the ASF Data Unit, it will not be possible to determine which object in such a grouping is the clean point object. Be careful when grouping objects with different Presentation Times. The Stream Properties Object defines how the Presentation Time is represented in all ASF Data Units for a given stream. If the Presentation Time is always the same as the Send Time, it is possible to specify that the Presentation Time should not be explicitly stated the ASF Data Unit. In this situation, when multiple Stream Data Objects are grouped into one Data Unit, all objects will be assigned the same Presentation Time. Thus, in this situation, grouping should only be considered for Stream Data Objects with the same Presentation Time. Otherwise, information will be lost. A. Klemets [Page 12] Internet Draft draft-klemets-asf-rtp-00 October 8, 1997 Limit any scrambling depth to 127 objects. Stream Data Objects do not have to be sent in the same order as they will be played. It is possible to interleave a stream with itself, or to "scramble" the Stream Data Objects. The Presentation Time and the Object ID is used to play the objects in the right order. But because the Object ID field is only 8 bits, the scrambling "depth", or maximum displacement of a Stream Data Object, should be limited to 127 objects. Otherwise it might be impossible to guarantee that the objects can be played in the correct order. Acknowledgements Thanks to Eric Fleischman and David del Val for useful comments. Authors Address Anders Klemets 9S/2032 Microsoft Corporation 1 Microsoft Way Redmond, WA 98052-8300 USA E-mail: anderskl@microsoft.com References [1] Microsoft Corporation, "Advanced Streaming Format (ASF) Specification", http://www.microsoft.com/asf, September 1997. [2] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real-Time Applications", IETF RFC 1889, January 1996. [3] H. Schulzrinne, et. al., "RTP Profile for Audio and Video Conference with Minimal Control", IETF RFC 1890, January 1996. [4] H. Schulzrinne, et. al., "Real Time Streaming Protocol", work in progress. [5] C. Perkins, "Options for Repair of Streaming Media", work in progress. [6] A. Jones, et. al., "RTP Payload Format for QuickTime Media Streams", work in progress. A. Klemets [Page 13]