INTERNET-DRAFT Eric Fleischman draft-fleischman-asf-rtp-record-00 Anders Klemets Microsoft Corporation November 14, 1997 Expires: May 14, 1998 Recording MBone Sessions to ASF Files 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 two approaches by which multimedia data (e.g., MBone conferences), transmitted using the Real-Time Protocol (RTP), may be recorded to Advanced Streaming Format (ASF) files. The first method requires a minimum amount of buffering at the recording station but results in recordings which identically preserve the received content including out of order packets, network ''jitter'', etc. The second approach requires buffering at the recording station but results in enhanced recordings (i.e., higher percentage of correctly ordered packets, elimination of a percentage of received jitter, potential recovery of a percentage of lost packets). Both approaches record all received RTP content and the relevant subset of RTCP information. This recording occurs transparently to the MBone conference or RTP session, and does not involve any alterations to normal RTP, RTCP, or ASF use. E. Fleischman and A. Klemets [Page 1]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 1. Introduction The MBone is the part of the Internet that supports IP multicast, and thus permits efficient many-to-many communication. It is used extensively for multimedia conferencing. Such conferences usually have the property that tight coordination of conference membership is not necessary; to receive a conference, a user at an MBone site only has to know the conference's multicast group address and the UDP ports for the conference data streams. The specific MBone conferences addressed by this document are those which use the Real-time Transport Protocol (RTP, see [1]). In addition, the mechanisms described within this document also support unicast RTP uses. This document describes two methods for recording multimedia data that is transmitted using the Real-Time Transport Protocol (RTP, see [1]) into Advanced Streaming Format (ASF; see [2]) files. The approach is independent of the network protocol used to transmit RTP packets and supports the recording of both unicasted and multicasted sessions. Data thus recorded may subsequently be played back by recreating the original RTP packets and transmitting them using either unicast or multicast techniques. A recording can also be played back locally, using a suitable playback tool. Playback can be controlled using RTSP [4] or other comparable stream control mechanisms. 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 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 also does not address the encapsulation of specific media types, but instead defers it to various profile specifications. ASF is an extensible file format for recording optionally synchronized multimedia streams. The format is not tied to any particular media type or compression scheme. Similarly, the file format was designed to be operating system and data communications protocol independent. 2. ASF Overview E. Fleischman and A. Klemets [Page 2]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 The Advanced Streaming Format is defined in [2]. An ASF file consists of three top-level objects: The Header Object, the Data Object and, optionally, the Index Object. The Header Object provides global information about the file as a whole as well as specific information about the multimedia data stored within the Data Object. This latter content provides the information necessary to correctly interpret each of the media streams found within the Data Object. The Header Object is a container for other objects that provide the following specific functions: * File Properties Object -- describes the global file attributes. * Stream Properties Object -- defines a media stream, its characteristics, and the information needed to decode that stream. * Content Description Object -- contains all bibliographic information, which may be either general for the file as a whole or stream specific. * Component Download Object -- provides information on playback components. * Stream Group Object -- logically groups media streams together into specific rendering contexts. * Scaleable Object -- defines scalability relationships among (scaleable) media streams containing bands. * Prioritization Object -- defines the relative prioritization between media streams. * Mutual Exclusion Object -- defines exclusion relationships between media streams (e.g., language selection) * Inter-Media Dependency Object -- defines dependency relationships among mixed media streams. * Rating Object -- provides the W3C PICS ([5], [6]) rating of the file. * Index Parameters Object -- supplies the information necessary to regenerate the index of an ASF file. * Language List Object -- supplies Language Identifier information that is used by several other ASF objects. The Data Object contains all the data for each of the recorded media streams. This data is stored in the form of ASF Data Units. In the general case, ASF Data Units are designed to be directly insertable into the payloads of data communications transport protocols in order to be streamed across the network. Each ASF Data Unit is of variable length, and contains data for only one media stream. Data units are sorted within the Data Object based on the time at which they should be delivered (send time). Due to the way Data Units are sorted, consecutive Data Units may contain data from different media streams. E. Fleischman and A. Klemets [Page 3]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 ASF media streams logically (in the general case) consist of sub- elements that are referred to as objects. What an object happens to be in a given media stream is entirely media stream dependent (e.g., it is a specific image within an image media stream, a frame within a (non- scalable) video stream, etc). The Index Object contains a time-based index into the multimedia data of an ASF file. The time interval that each index entry represents is set at authoring time and stored in the Index Object. Since it is not required to index into every media stream in a file, a list of the media streams that are indexed follows the time interval value. Each index entry consists of one data unit offset per media stream being indexed. This information allows stream-specific index operations to occur. A minimal ASF implementation consists of a Header Object containing solely a File Properties Object, one Stream Properties object, and one Language List Object as well as a Data Object containing only a single ASF data unit. 3. Recording MBone Sessions The process of recording MBONE sessions may be viewed as optionally consisting of four steps: Step 1 -- Create the ASF Header Object, which will provide the context for correctly interpreting the data that may subsequently be recorded. Step 2 -- Record one or more RTP streams into the ASF Data Object. Step 3 -- Optionally post-process the ASF Header Object to ensure that it is as complete and as efficiently stored as possible Step 4 -- Optionally create an ASF Index Object. 3.1. Preparing ASF Header Information The ASF Header Object contains various other objects that contain information about the media streams in the Data Object. It is often desirable to create an ASF Header Object before the transmission that is to be recorded has begun. This would be appropriate if information is already available that describes the RTP sources that are to be recorded. Such information might be obtained through SDP [7], RTSP [4], or some other non-RTP means. It is also possible to add information to the ASF Header Object as new information is learned during the recording E. Fleischman and A. Klemets [Page 4]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 of the RTP traffic. ASF requires that an instance of the Stream Properties Object (SPO) must be defined to describe each media stream recorded within the Data Object. A media stream generally corresponds to an RTP source in an RTP session. RTP sources, in turn, are identified by the value of the SSRC field in the RTP header. The IP address and port number to which the data is sent identifies RTP sessions. On the MBone, most applications send audio and video on separate RTP sessions, and thus audio and video would be recorded as two separate media streams. However, all RTP packets that belong to a media stream are expected to have identical RTP Payload Type fields. If an RTP source changes the value it is using for the RTP Payload Type field :mid-session", then RTP packets with the new (i.e., different) Payload Type fields should be stored as a different media stream within ASF with its own unique SPO. It is recommended that the relationship between streams that compose the traffic from a single RTP source be associated by grouping them via the ASF Header Object's Stream Group Object. While the session announcement will generally provide enough information to construct an initial File Properties Object (FPO) and some of the necessary SPOs before the session begins, loosely controlled (MBone) conferences can permit additional participants to join the conference. Therefore, provision should be made to anticipate the possibility of additional speakers joining the session. A recommended way to satisfy this provision is to reserve space within the ASF Header Object via the ASF Placeholder Object (See Appendix A) where additional ASF objects may be written (e.g., additional SPOs) as the MBone session dynamically progresses. Static RTP Payload Types may be handled in one of two ways: 1. Static RTP Payload Types should be translated into the equivalent ASF standard media type (see Section 8 of [2]) using the equivalent ASF codec (e.g., see Reference [10]), if known. 2. Alternatively, they can be recorded as RTP Media Types as defined in Appendix B. Dynamic RTP Payload Types may be handled in one of three ways: 1. The dynamic RTP payload type should be translated into the equivalent ASF standard media type (see Section 8 of [2]) using the equivalent ASF codec, if known. This means that the recorder will need to identify the actual codec used by that dynamic RTP Payload Type instance based upon the available information. The identity of this E. Fleischman and A. Klemets [Page 5]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 codec will then need to be expressed as a specific ASF UUID identifier (e.g., see Reference [10]) within the SPO's Codec ID field. 2. Alternatively, the recorder can translate the dynamic RTP payload type to the appropriate static RTP payload type, if any and record it as an RTP Media Type as defined in Appendix B. 3. Alternatively, the recorder can record it as a dynamic RTP payload type as defined in Appendix B. RTP payload types, which can not be deciphered by any of the above approaches, should be ignored (i.e., that media stream can not be recorded). Note that if the RTP payload is translated into the equivalent ASF standard media type, an inverse transformation will need to be applied by a playback device, if the recording is retransmitted as RTP packets. 3.2. Two Recording Approaches The capabilities of local systems vary. For this reason, the document suggests that limited capability systems seek to record data via the Packet Capture Mode, which is described in section 3.2.1. More capable systems are recommended to use the Record Structure Mode, described in section 3.2.2. 3.2.1. Packet Capture Mode (Limited Buffering) The Packet Capture Mode recording alternative seeks to write RTP data as it is received to the ASF Data Object on the disk. The clock of the recording computer is used to determine the ASF Data Unit's Send Time value. The Send Time value is calculated by subtracting the multimedia session's start time (as recorded by the recording computer) from the recording computer's current time and converting the result into millisecond units. The RTP timestamp is directly written as the ASF Data Unit's Presentation Time value, again making the necessary conversions to account for the fact that the initial RTP timestamp value is random while the initial ASF Send Time and Presentation Time values are zero. The granularity of the Presentation Time units (i.e., the Presentation Time Numerator and Presentation Time Denominator fields within the SPO) should be set to the clock granularity for that RTP source. ASF's default presentation time granularity (i.e., a millisecond) should initially be used for those cases in which the actual clock granularity E. Fleischman and A. Klemets [Page 6]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 is not known. The value of the Presentation Time Flags within the SPO for this media stream shall thus be configured to be "11" (i.e., Full Data Unit Presentation Time). RTCP Sender Reports (SR) for the RTP source being recorded can be used to calculate the clock granularity of the source. This is useful if the clock granularity is otherwise unknown. It is also possible to use Sender Reports to detect skews between the clock granularity used by the source, and the granularity that is given by the RTP Payload Type specification or profile. If such a skew is detected, the Rational Time Values (i.e., Presentation Time Numerator and Presentation Time Denominator fields) of the SPO should be altered accordingly. This approach has the advantage of being simple and direct to implement. It has the following disadvantages: * Jitter is preserved - and repeated re-recordings of the same contents by this manner may exacerbate the jitter on each subsequent recording. * Out-of-order packets remain out of order. 3.2.2. Record Structure Mode (Buffering) The Record Structure Mode requires that packets be buffered a finite amount of time (e.g., 5 seconds) before being written to disk. Packets within the buffer should be correctly ordered. Packet holes occurring within the buffer interval should be filled by retransmitted packets (if any). Within this approach, the value of the RTP Timestamp field is used to compute the send time. Since the RTP timestamp starts at a random value, while the ASF Send Time and Presentation Time start at zero, a conversion into appropriate ASF Send Time values must be made. The send time is stored with a 1-millisecond granularity. The appropriate RTP Payload Type specification or profile gives the granularity of the RTP Timestamp. RTCP Sender Reports (SR) may be used calculate the granularity of the RTP Timestamp if it is otherwise unknown. Sender Reports can also be used to detect skews between the RTP Timestamp granularity and the granularity specified in the RTP Payload Type specification or profile. If such a skew is detected, the send time values for currently buffered packets of that media type have to be altered (retaining their millisecond granularities) to correctly reflect the skew. E. Fleischman and A. Klemets [Page 7]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 The following values should be recorded within the Stream Properties Object for the media streams recorded by this approach: The clock frequency of the RTP payload type should be appropriately recorded into the Presentation Time Numerator and Presentation Time Denominator fields. The Presentation Time Flag value should have the value of "01" and the Presentation Time Delta field should have a value of zero. This means that both the ASF send time and presentation time have the same value and that subsequent RTP retransmissions of this data will contain only one timestamp (i.e., RTP's timestamp). This approach has the advantage of correcting some of the received jitter, correctly sorting some of the out-of-order packets, and potentially filling in some lost packets (assuming a retransmission scheme is used). The disadvantage of this approach is that it is more complex to implement. This is particularly the case if the RTP payload type's clock frequency is not known ahead of time and has to be subsequently learned via RTCP transmissions. In addition, it requires additional buffering on the recording computer. 3.3. Recording MBONE Sessions The following translations from RTP packet fields to ASF data fields are identical for both recording approaches. 3.3.1. RTP Mixers and Translators The combined streams resulting from Mixers and Translators need to be demultiplexed back into their original component streams when being recorded into ASF, if possible. If this is not possible, then copies of the RTP packet containing data that is attributed to multiple sources need to be stored into each of these sources' media streams (i.e., ASF Data Units). In either case, these streams may be optionally re-mixed when they are subsequently replayed from the ASF files depending upon local implementation considerations. 3.3.2. RTP Packet Information The RTP Header's Payload Type field combined with the SSRC is used to determine the ASF Stream Number value for that media stream. This Stream Number value identifies which SPO instance should be used to define this media stream. This value is recorded into the Stream Number field of the ASF Data Unit. The Version field in the RTP header is not recorded into the ASF file E. Fleischman and A. Klemets [Page 8]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 unless it is a version other than 2. If the Version field in the RTP header is other than 2, the RTP version number should be recorded into the ASF Header Object's Content Description Object (CDO; see Section 5.4 of [2]) using a value of 73 for the Field Type field. The Padding bit, and the Padding field that is present if the bit is set, is not recorded. If an RTP packet where the Padding bit was set is received, the padding field should be removed from the RTP payload. Padding may be regenerated when retransmitting the recording, if necessary. SSRC information should be written into the CDO as an aid for remembering the association between an SSRC and a Media Stream. This will also permit the original sequence number to be optionally recreated once the recorded data is retransmitted. The 32-bit SSRC value will need to be converted into a string when it is stored into the Value field of the CDO. When storing the SSRC as a Unicode string, the SSRC is treated as an unsigned 32-bit integer, and it must be converted to the local byte order (i.e., host byte order). The value of the Field Type field is 70. Because the initial RTP timestamp value is a random value, the initial RTP timestamp value should also be recorded into the CDO. This will permit the original timestamp sequence to be optionally recreated once the recorded data is retransmitted. The 32-bit timestamp value will need to be converted into a Unicode string when it is recorded into the Value field of the CDO. The value of the CDO's Field Type field is 71. The initial RTP Sequence Number value should be recorded into the CDO. This will permit the original number to be optionally recreated once the recorded data is retransmitted. The 16-bit Sequence Number value will need to be converted into a Unicode string when it is stored within the Value field of the CDO. When storing the Sequence Number as a string, the Sequence Number is treated as an unsigned 16-bit integer, and it must be converted to the local byte order (i.e., host byte order). The value of the Field Type field is 72. It should be noted that ASF's concept of Object Number differs from RTP's concept of Sequence Number although they are both used to identify out-of-order and missing information. [Note: earlier versions of the ASF spec used the term "ObjectID" instead of "Object Number".] The former identifies specific media stream "objects" as a part of a fragmentation and grouping schema. What an object happens to be in a given media E. Fleischman and A. Klemets [Page 9]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 stream is entirely media stream dependent (e.g., it is a specific image within an image media stream, a frame within a (non-scalable) video stream, etc). Since object fragmentation occurs within a specific RTP Payload Type instance and RTP headers do not indicate this type of information, an identical translation of the original Object Number semantics would require a decoding of the media stream. The value of pursuing this type of overhead is highly questionable, especially when the ultimate goal of identifying missing or out-of-order information is common between the two approaches. Therefore, the RTP sequence number should be directly mapped into the ASF's Object Number field of the ASF Data Unit. Since the 16-bit Sequence Number starts at a random interval while the 8-bit Object Number starts at zero, the mapping between the Sequence Number and Object ID needs to reflect this difference (e.g., Current-Sequence-Number value minus Original Sequence-Number value = Object Number) and account for the fact that Object Numbers "wrap around" to zero every 2^8th packet and Sequence Numbers "wrap around" when their value hits 2^16. If the CSRC fields within the RTP header are demultiplexed into their original component streams when being recorded, then the CSRC fields are not recorded. If, however, this is not possible, then the CSRC information should be written into the ASF Data Unit's extension field as described below. If the RTP payload has been converted into an "equivalent ASF standard media type" (see Section 3.1), then the RTP Extension Object described by the next paragraph is optional. However, if the RTP Media Type described in Appendix B has been used to record the data, then the RTP Extension Object is required to be used if either the RTP Header's M-bit or the RTP Header's eXtension (X) bit are ever set within that stream, or if CSRC information is ever needed to be recorded within that media stream. The RTP Extension Object permits exact copies of the original RTP packets to be regenerated, if desired. The RTP Extension Object is an instance of the Extension Object that is described within Section 5.3.1 of [2]. Extension Objects are associated with a specific media stream's SPO and indicate the semantics and format of specific data (i.e., in this case RTP Packet Header data) that is stored on a per packet basis within the Extension Data field of the ASF Data Unit (see Section 6.1 of [2]). The RTP Extension Object is defined as follows: * The value of the Extension Data Size field is 0xFFFF * The UUID value of the Extension System field is {96800c63-4c94-11d1- 837b-0080c7a37f95}. E. Fleischman and A. Klemets [Page 10]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 These definitions indicate that this recording shall follow the "variable length" extension data encoding format (i.e., one bit length field followed by the extension data) within the Extension Data field of the ASF Data Unit. In the case of the RTP Extension Object, the Extension Data field of the ASF Data Unit has the following syntax: Field Name: Size: Extension Length 8 bits - Size in bytes of the Extension Data and Flag fields (i.e. sizeof (Extension Data) + 1) Flag 8 bits X-bit 1 bit (LSB) -- contains the RTP Header's X-bit value CSRC Count 4 bits -- contains the RTP Header's CC value M-bit 1 bit -- contains the RTP Header's M-bit value Reserved 2 bits (MSB) Extension Data RTP Header CSRC list, if any, followed by Extension Data, if any The "variable length" encoding means that if either the X bit is set or the CSRC Count has a non-zero value, then the Extension length, flag, and RTP header extension data are written into the Extension Data field of the ASF Data Unit. If both the X bit is cleared and the CSRC Count has a zero value, then only the extension length and flag fields are written to the Extension Data field of the ASF Data Unit. If both the X- bit is set and the CSRC Count field has a non-zero value, then the CSRC list of the RTP Header appears first immediately followed by the RTP Header Extension data within the Extension Data field. These fields are arranged in big-endian order (also known as network byte order). 3.3.3. RTCP Packet Information RR and BYE packets are not recorded into ASF files. Clock skew information obtained from SR packets is used for the timestamp calculations described in Sections 3.3.1 and 3.3.2. Other information contained in SR packets, except for APP and SDES information, is not recorded. SDES information is stored in the ASF Header Object's Content Description Object (CDO). Appropriate SDES items (i.e., "CNAME", "NAME", "EMAIL", "PHONE", "LOC", "TOOL", "NOTE", and "PRIV") shall be written into the CDO as described by Appendix C. Synchronization relationships between media streams containing the same CNAME value should be retained via associating them by ASF's Inter-Media Dependency Object (Section E. Fleischman and A. Klemets [Page 11]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 5.12 of [2]). APP information should be handled in one of two ways. 1. If the recorder understands (through out-of-band mechanisms outside of the scope of both ASF and RTP) that the APP information contains script commands or invocations, which correspond to either the ASF Header Object's Script Command Object (see section 5.5 of [2]) or to a Command Media stream type (see section 8.7 of [2]), then the recorder can convert the APP information into the appropriate ASF constructs. 2. If the recorder does not understand the APP information then that information should be appropriately recorded "as is" into the ASF Header Object's Script Command Object. If the values of the SDES fields from a particular RTP source change during the recording, it is recommended that the CDO contain the initial value for the SDES field. Subsequent values of the SDES fields should then be recorded as a separate media stream, via the mechanisms described in Appendix D. 3.4. Optional Post-Processing of the ASF Header Whenever live recordings are made, the Live Bit must be set in ASF's File Properties Object. This signifies that certain fields in the ASF File Properties Object and the Stream Properties Object(s) are invalid and should be ignored. In addition, these same files are likely to also contain the ASF Placeholder Object (see Appendix A). It is highly recommended, but not required, that post-processing be done to ASF files to clear the Live Bit, remove the ASF Placeholder Object, and to write valid data into the fields which are invalid when the Live Bit is set. 3.5. Optional Creation of the ASF Index Object ASF uses the Index Parameters Object in the ASF Header to identify the parameters and media streams whose data will be indexed. This object is described in Section 5.14 of [2]. If the Index Parameters Object does not yet exist for this file, then it needs to be constructed before the Index Object is built. Using the information contained within the Index Parameters Object, the Index Object is constructed as defined in Section 7 of [2]. 3.6. Playback of the Recorded RTP Data Recorded media streams are stored into the ASF Data Object as ASF Data Units (see Section 6.1 of [2]). Each ASF Data Unit contains a "header E. Fleischman and A. Klemets [Page 12]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 field" together with the media data which is being stored. The payload of each RTP packet comprises the media data stored within the ASF Data Unit. The RTP header itself is not stored but its content is mapped into the SPO, CDO, and the header field of the ASF Data Unit. The ASF file contains sufficient information to play back the recorded data, either locally or via a remote playback device. When RTP packets are recorded into the ASF file using the RTP Media Type (see Appendix B), sufficient information exists to regenerate RTP packets with the same SSRC and sequence numbers as the original packets, if desired. Additionally, it is possible to regenerate RTCP SDES and APP packets with the same content as those sent by the original RTP source. This permits recorded data to be retransmitted into an existing MBone conference, for example, in such a manner that it may appear that the data originates from the original RTP source. This specification does not define a required feature set for playback devices. For example, even though it is possible to retransmit the recorded data using RTP, playback devices are not required to do so. Appendix A. ASF Placeholder Object Definition "Loosely controlled" sessions permit participants to enter and leave without membership control or parameter negotiation. Since one can not always predict how many participants will speak, nor what media types they will use, a mechanism is needed to reserve space within the Header Object so that new Header Objects (e.g., Stream Properties Objects) may be readily added to the header when needed without requiring the header to be re-written. The purpose of the ASF Placeholder Object is to fulfill this "place holder" function. New header objects are added into the space reserved by the ASF Placeholder Object. The ASF Placeholder Object will then reduce the amount of space it is reserving by the amount taken by the new object(s). ASF Placeholder Objects are ignored (skipped over) when ASF Header Information is conveyed to remote nodes. Even so, it is recommended that they be removed by post processing (see section 3.4) to make more compact files. E. Fleischman and A. Klemets [Page 13]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 The ASF Placeholder Object is defined as follows: Field Name: Size: Value: Object ID 128 bits This field contains the following UUID value: {D6E22A0F-35DA-11d1-9034- 00A0C90349BE} Object Size 64 bits The size of this object in bytes (i.e., Reserved field value + 24) Reserved (Object Size - 24) * 8 bits Reserved space Appendix B. RTP Media Type ASF has defined standard media types for Audio, Video, Image, Timecode, Text, MIDI, Command, and Media-Objects (Hotspots) in Section 8 of [2]. Implementations, which support these types of media streams, are expected to implement them in the manner defined within the ASF standard. MBone content, which is stored within ASF, is therefore expected to be mapped into the standard ASF media streams format whenever possible. However, occasions will exist when it will not be possible to conform to this requirement. Possible reasons include the following: * The recorder may not be aware of which media type is associated with an RTP Payload Type (i.e., whether the RTP Payload Type is referring to Audio, Video, or some other media type). * The recorder may not know which ASF-defined codec corresponds to the codec assumed by the RTP Payload Type and therefore it would be unable to complete the mapping into a standard ASF media type. * The RTP Payload Type may indicate an interleaved data stream (e.g., video and audio combined into a single stream). No standard ASF media type has yet been defined for such interleaved data. * The RTP Payload Type may indicate a media type which is not among the standard ASF Media Types. For these reasons and others, a provision must exist to record MBone data as a distinct RTP Media Type. This appendix defines the format of RTP Media Type. The RTP Media Type is defined within the Stream Properties Object (SPO) by placing the UUID value {96800c65-4c94-11d1-837b-0080c7a37f95} into the Stream Type field. The following information is then stored as Type- E. Fleischman and A. Klemets [Page 14]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 Specific Data field within the SPO: Field Name: Field Type: Size (bits): Description: Payload Type UINT 8 The Payload Type value indicated by the RTP header. Profile Size UINT 16 Size in bytes of the Profile field. Profile UINT8 ? ASCII string identifying the Profile which has defined the Payload Type. (E.g., "AVP" for the profile defined by [3] and [9].) An empty string is used if the profile is not known. Announcement ID Size UINT 16 Size in bytes of the Announcement ID field. Announcement ID UINT8 ? MIME Type of the session announcement mechanism used. (E.g., "application/x-sdp" for SDP [7] announcements.) Announcement Size UINT 16 Size in bytes of the Announcement field. Announcement UINT8 ? ASCII string containing the definition for this media stream. (E.g., for SDP [7] announcements, this would contain the entire rtpmap entry for this media stream.) All ASCII strings in the RTP Media Type are terminated by a NULL character. These fields should be stored in little-endian byte order (i.e., the orientation used in the ASF Header Object). The final four fields (i.e., Announcement ID Size, Announcement ID, Announcement Size, and Announcement) are used to convey information about the dynamic RTP payload type. This information might have been available to the recording device through non-RTP means. Examples of possible sources of such information include session descriptions, such as SDP [7], and presentation descriptions [4]. However, if a static RTP Payload Type is being specified, both the Announcement ID Size and the Announcement Size fields may have a value of zero indicating that the Announcement ID and Announcement fields have not been specified. The rest of the SPO should be specified as indicated in Section 3.2 E. Fleischman and A. Klemets [Page 15]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 above. The received RTP data of this media stream is stored into the ASF Data Object as described in Section 3.2 and Section 3.3 above. Appendix C. Recording SDES Information Section 5.4 of [2] describes the syntax and semantics of the Content Description Object (CDO) within the ASF Header Object. This object consists of an array of Description Records containing four logical entries: 1. A Field Type value which identifies the semantics of the entry. Each SDES packet may be recorded to the CDO using the following pre- defined Field Type (unsigned integer) values: SDES entry: Field Type Value: CNAME 61 NAME 62 EMAIL 63 PHONE 64 LOC 65 TOOL 66 NOTE 67 PRIV 68 2. Stream Number to identify to which media stream this CDO entry refers. 3. Name - Name of the entry. This field is redundant to the Field Type value and therefore the field is frequently not used. However, applications may optionally use this field for language "localization" reasons (e.g., to translate the entry into a specific target language). 4. Value - the information conveyed by the specific SDES message (e.g., User and domain name in a CNAME packet). Appendix D. SDES Media Streams Section 3.3.3 stated that the first instance of a specific SDES RTCP instance (i.e., a specific SDES item associated with a specific RTP source identifier; e.g., a CNAME value for a specific SSRC) should be recorded into the Content Description Object (CDO). The Stream Number field within the CDO should refer to the media stream associated with the RTP source identifier (i.e., SSRC/CSRC field of section 6.4 of [1]) E. Fleischman and A. Klemets [Page 16]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 of that SDES packet chunk. The CDO has provisions for storing only one SDES type instance (e.g., only one instance of a CNAME) for any given media stream. Therefore, subsequent instances of the same SDES type for that media stream will need to be recorded as a distinct "media stream" if that information is to be preserved. This appendix defines how to create such an SDES media stream. An SDES media stream consists of SDES information written into the ASF Data Object via the mechanisms described in section 3.2. Each SDES media stream records SDES information from only one RTP source identifier. A Stream Properties Object (SPO) is constructed for each SDES media stream. That SDES media stream should also be associated with (i.e., synchronized with) the media stream containing the RTP data of that same RTP source identifier via the ASF Header Object's Inter-Media Dependency Object. The SPO for a SDES media stream should be constructed as follows: * The UUID of the SDES Media Stream is {96800c62-4c94-11d1-837b- 0080c7a37f95}. This value should be written into the Stream Type field of ASF's Stream Properties Object (SPO) to identify SDES Media Streams. * The value of the Type-Specific Data Length field within the SPO is zero (i.e., no Type-Specific Data). The format of an SDES Media Stream consists of one or more instances (per ASF Data Unit) of the following structure: Field Name: Field Type: Size (bits): Description: Type Array Size UINT 16 Size in bytes of the Type Array Value Array Size UINT 16 Size in bytes of the Value Array Type Array UINT8 ? UTF-2 string [8] identifying the specific SDES type instance (e.g., "CNAME") Value Array UINT8 ? UTF-2 string [8] containing the SDES value (e.g., "user and domain name" for a CNAME) E. Fleischman and A. Klemets [Page 17]
Internet Draft draft-fleischman-asf-rtp-record-00 November 14, 1997 Authors Address Eric Fleischman E-mail: ericfl@microsoft.com and Anders Klemets E-mail: anderskl@microsoft.com Microsoft Corporation 1 Microsoft Way Redmond, WA 98052-8300 USA References: 1 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson., "RTP : A Transport Protocol for Real-Time Applications", IETF RFC 1889, January 1996. 2 Microsoft Corporation, "Advanced Streaming Format (ASF) Specification", http://www.microsoft.com/asf/specs.htm, September 1997. 3 H. Schulzrinne, "RTP Profile for Audio and Video Conference with Minimal Control", IETF RFC 1890, January 1996. 4 H. Schulzrinne, A. Rao, and R. Lanphier "Real Time Streaming Protocol (RTSP)", work in progress. 5 J. Miller, P. Resnick, and D. Singer, "Rating Services and Rating Systems (and Their Machine Readable Descriptions)," World Wide Web Consortium http://www.w3.org/PICS/services.html, May 5 1996. 6 T. Krauskopf, J. Miller, P. Resnick, and G. W. Treese, "Label Syntax and Communication Protocols," World Wide Web Consortium http://www.w3.org/PICS/labels.html, May 5 1996. 7 M. Handley, V. Jacobson, "SDP: Session Description Protocol", work in progress. 8 International Standards Organization, "ISO/IEC DIS 10646-1:1993 information technology - universal multiple-octet coded character set (UCS) - part I: Architecture and basic multilingual plane," 1993. 9 "RTP Payload types (PT) for standard audio and video encodings", ftp://ftp.isi.edu/in-notes/iana/assignments/rtp-av-payload-types 10 "ASF Codec GUIDs", http://www.microsoft.com/asf/guids.htm E. Fleischman and A. Klemets [Page 18]