Network Working Group Magnus Westerlund INTERNET-DRAFT Kristofer Dovstam Expires: January 2002 Ericsson, Sweden Frank Hartung Uwe Horn Ericsson, Germany July 12, 2001 Generic RTP Payload Format for Time-lined Static Media 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This Internet Draft discusses an RTP payload format for time-lined static media. "Time-lined static media" means static media objects like pictures and text extended by timing information. Applications that would benefit from such a payload format are for instance slideshow streaming and streaming of subtitled video and audio. We discuss the important requirements for a payload format and propose a specification that suits those requirements. Westerlund [Page 1] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 TABLE OF CONTENTS 1. Introduction........................................................2 2. Usage scenarios.....................................................3 2.1. Image slideshow...................................................3 2.2. Subtitled video and audio streams.................................4 3. Problems of existing approach.......................................5 4. Requirements........................................................6 5. Proposal for an RTP Payload Format for time-lined static media......7 5.1. RTP Header Usage..................................................7 5.2. Header Formats....................................................8 5.2.1. Object Identifier Header........................................8 5.2.2. Duration Header.................................................9 5.2.3. Data Header.....................................................9 5.2.4. Offset Headers (ByteOffset).....................................9 5.3. Compound payload.................................................10 6. Media Profiles.....................................................11 6.1. JPEG.............................................................11 6.1.1. Resilient transport............................................11 6.1.2. Profile specific headers.......................................12 6.1.3. Payload format header usage:...................................12 6.2. TEXT.............................................................13 6.2.1. Resilient transport............................................13 6.2.2. Profile Specific Headers.......................................13 6.2.3. Payload format header usage:...................................14 7. Congestion Control.................................................14 8. Security Consideration.............................................15 8.1. Confidentiality..................................................15 8.2. Authentication...................................................15 9. IANA Considerations................................................15 10. MIME type registration............................................15 11. Author's Addresses................................................16 12. References........................................................16 1. Introduction Today, content creators have various options to specify complex multimedia presentations composed of different media types and synchronized along a global timeline. SMIL [1] for instance is a powerful tool that allows one to define the spatial and temporal layout of multimedia presentations that contain video, audio, still images, text, and other media elements. In addition to SMIL, there are a couple of file format specifications that also allow one to create synchronized multimedia presentations, composed of a mix of different media types. Westerlund et al. [Page 2] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 Media types are usually classified into static and continuous media. Continuous media types are characterized by an intrinsic time line resulting from taking media samples at regular time intervals. Video and audio are typical examples for continuous media types. Static media types differ from continuous media types in the sense that they do not possess an intrinsic time line. Examples of static media types are still images and plain text. In addition to static and continuous media one can identify a third media type, which we call "time-lined static media". With time-lined static media we mean static media objects like pictures and text with added timing information such that the presentation of a series of static media objects can be synchronized with a global timeline. Application scenarios that would benefit from such an RTP [3] payload format are for instance slideshow streaming and subtitled video and audio streams. Today, there exist various RTP payload formats that can be used to packetize data belonging to continuous media elements. Static media types, like an image in an HTML page, are usually transferred via HTTP. However, as we will see later, using TCP [2] based HTTP for time-lined static media has many drawbacks, especially if synchronization with a continuous media streams is required. Therefore, streaming of time-lined static media objects should be done based on RTP over UDP similar to streaming of continuous media. In the following, we will first discuss in more detail some usage scenarios that would benefit from an RTP payload format for time- lined static media. After that, we will list some important requirements of such a payload format. Finally, we propose a specification of a payload format for time-lined static media that takes the identified requirements into account. 2. Usage scenarios This section discusses in more detail two use cases that would benefit from a payload format for time-lined static media objects, namely slideshow streaming and video and audio streaming with subtitles. 2.1. Image slideshow A slideshow in its simplest form is characterized by a series of images with a defined presentation start time and duration for each image. Usually the time-lined images are accompanied by a synchronized audio track. Westerlund et al. [Page 3] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 / \ Media | Elements| | Image 1 | #### Image 2 | ######### Image 3 | ##### Image 4 | ########## Audio | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------> time Figure 1 Figure 1 gives an example for a series of images synchronized with audio. The vertical axis denotes the different media elements; the horizontal axis represents the time line. In the shown example audio starts first. After three time units the first image appears and stays visible for 4 time units, followed by the second image which stays visible for 9 time units and so on. 2.2. Subtitled video and audio streams Subtitling is characterized by combining continuous media types like video with audio or audio only with time-lined static text elements. Fig. 2 gives an example that starts with video and audio. The first subtitle appears after three time units and remains visible for four time units. After a short period where no subtitle at all is shown, subtitle 2 is shown over a period of 5 time units and so on. / \ Media | Elements| | ST 1 | #### ST 2 | ##### ST 3 | ##### ST 4 | ### Audio | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Video | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------> time Figure 2 Westerlund et al. [Page 4] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 3. Problems of existing approach As mentioned in the introduction, there is currently no RTP payload specification that could be used for time-lined static media elements. The workaround today is to transfer each of the static media objects in separate files via TCP or HTTP to the client, where the timing information is added. For instance, a slideshow application defined in SMIL would use HTTP/TCP for the images, with timing information coming from the SMIL file, and if audio is present as well, use RTP/UDP for streaming the audio. However, this "hybrid" approach has a couple of drawbacks, which are listed in the following: - TCP is not suited for real-time transmission scenarios TCP guarantees error-free delivery of data between a sender and a receiver over best effort networks by employing a specific retransmission mechanism. However, the requirements of real-time streaming applications are not addressed by TCP. For streaming timely delivery of data is more important than error-free delivery of data. This is a well-known fact and has lead to the development of RTP [3]. - TCP is not suited for multicast scenarios In a multicast distributed multimedia session it is not recommended that the receivers use TCP to fetch static media. If the group were large, this would create an enormous load on the server holding the static media. Instead a method that can take advantage of multicast network is needed. In the past, plenty of work has been done on achieving reliable transport over multicast, e.g. SRM [5]. There is today ongoing work on standardizing solutions in the IETF Reliable Multicast Transportation (RMT) working group. Note that this payload format is not intended to replace such mechanisms, instead it can be used to achieve simple unreliable transport of static media that can tolerate some losses. - Protocol mix prevents unified congestion control The need for congestion control in the context of real-time media delivery becomes more and more important. In this context a unified congestion control approach on session level is more appropriate compared to using different congestion control mechanisms for time- lined static (TCP) and continuous (RTP/UDP) media elements. Westerlund et al. [Page 5] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 - Protocol mix prevents unified bandwidth adaptation The division of responsibility for transport of media between a server and a client also complicates bandwidth adaptation. Audio and video will be streamed down from the server to the client. The client fetches static media from the server. If also the static media are streamed to the client, the server can more easily ensure an optimal quality of the overall presentation under the presence of a bandwidth constraint. We therefore propose to introduce a new RTP payload type suitable for static media types. In the following section we will discuss some important requirements of such a payload format before we are going to describe our specification proposal for such a payload format. 4. Requirements A payload format for time-lined static media types should fulfill the following requirements: - Timing information The availability of timing information in the media packet(s) is crucial. It can be used for many transmission related purposes, like optimal scheduling of RTP packets at the application server. Timing information also tells the client application when and for how long a specific static media object should be presented to the user. - Applicable to any kind of static media The payload format SHOULD be generic enough to be applicable to any kind of static media. - Support for Application Level Framing (ALF) The payload format SHOULD support packetization of data according to the needs of the application [6]. An application might for instance want to packetize the data belonging to one static object in a way that is most resilient against packet losses. - Support for object identifiers It SHOULD be possible for client applications to reference each object in a series of time-lined media objects by a unique identifier. For instance in a layout specification file one might want to specify different spatial locations for each of the time- lined objects. How this can be done for instance within SMIL [1] is however out of the scope of this document. Westerlund et al. [Page 6] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 - Error resilience The payload specification SHOULD support the employment of forward error correction (FEC) mechanisms as described in RFC 2733 [7]. It SHOULD also be possible to use the RTP retransmission methods that are currently under discussion within IETF [10][11][12]. Also the employment of application-level error concealment methods for lost packets SHOULD NOT be prevented. - Multicast capabilities The payload format specification SHOULD allow streaming of time-lined static media objects using multicasting. 5. Proposal for an RTP Payload Format for time-lined static media This RTP payload format is supposed to be applicable to all kind of static media types. We therefore use a header format that is specified by a payload "framework" together with several payload profiles. The payload framework is independent of the media type and defines a number of basic headers that can be used. Payload profiles are media type dependent and define how to use the framework. Typically, a payload profile defines which headers of the payload framework are used, and MAY also specify new headers. A payload profile also specifies and MAY give recommendations on how to packetize data of the specific media type according to the ALF [6] principle. It may also propose error recovery mechanisms for improved error resilience against packet losses. 5.1. RTP Header Usage The first part of an RTP packet is the fixed RTP header. The three fields set by the application in the fixed RTP header, timestamp, marker bit and payload type are explained here. For this payload format these fields should be interpreted and defined as following: Timestamp: The timestamp is used for identifying the time when the object shall be used by the receiver(s). The timestamp MUST be identical for all packets being part of the same object, i.e. the timestamp is used for binding packets to the correct object. If two different objects are going to be used at the same time, they MUST have different timestamps. To minimize the effect of this rule, the timestamp difference between these objects is RECOMMENDED to be a single timestamp unit. The timestamp rate is either defined, dynamically Westerlund et al. [Page 7] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 during session setup, e.g. in SDP [4], or by a profile. Marker bit (M bit): The marker bit is used to indicate the last packet of an object. Payload Type (PT): The payload type is set dynamically and out of band in accordance with current practice. Different payload types SHALL be established for each media profile that is used in a multimedia session. 5.2. Header Formats This section defines a number of general headers that can be used by any profile. All headers start with an eight-bit identifier. These identifiers are taken from two different number spaces. The numbers 0-127 are used a common number space, identifying general headers and must be registered with IANA. Numbers 128-255 represent the profile specific range. Each profile is responsible for assigning the header numbers uniquely within this space. A Header SHALL only be present a single time in the each packet, unless the interpretation of multiple instances is defined in the header format or a profile. Some headers may contain information that is essential for the whole object and not only for the actual packet. To reduce the probability that this essential information is lost due to a single packet loss, it is recommended to employ appropriate FEC mechanisms. In the simplest case, important headers should be repeated in multiple packets belonging to the same object. 5.2.1. Object Identifier Header The object identifier header (OID) is used by applications to name different objects within a stream. The exact meaning of the OID is profile and/or application dependent. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hd.type (1) | Len | Object Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : (Variable len. 0-255) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Westerlund et al. [Page 8] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 Len: Number of bytes that the object identifier consists of. Valid lengths are 0-255, where 0 is allowed but lacks purpose. Object Identifier: Byte stream used for identifying the object that this packet is part of. The interpretation of the content of this field is profile or/and application specific. 5.2.2. Duration Header This header is used to express the duration for which the object is to be used at the receiver, in timestamp units. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hd.type (2) | Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Duration: The length of the time this object is to be used, expressed in RTP Timestamp units. 5.2.3. Data Header This header is used to carry object data. It MUST be the last header used in the packet, since it lacks a length field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hd.type (0) | Data (until end of payload) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data: A byte stream of object data, which MUST be byte aligned. If the object's data prior to packetization in this header is not byte aligned, the profile is responsible for defining how to do it. 5.2.4. Offset Headers (ByteOffset) A Fragmented byte stream needs indicators for where the data in each packet belongs in the stream. This header gives an offset from the start of the byte stream. The offset is of the first byte in the fragmented data present in the packet. Westerlund et al. [Page 9] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 16-bit offset field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hd.type (3) | Offset (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32-bit offset field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hd.type (4) | Offset (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Offset: The offset in bytes from the start of the object that the first byte in the data block shall be located. 5.3. Compound payload A complete payload consists of one or more headers and their content. Which headers that are used is profile and application dependent. The order of the headers have no importance, except for the data header and its data block, that MUST be located last in the payload. If a receiver encounters an unknown payload header the depacketization SHOULD be halted. Valid headers positioned before the unknown MAY be used. The reason it cannot simply be ignored is that the size is unknown. An example packet could look like this. -------------- | RTP header | -------------- <- RTP payload begins | OID header | -------------- | ByteOffset | -------------- | Data head. | -------------- | Data | -------------- Westerlund et al. [Page 10] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 This example starts with the RTP header, which gives information about which payload format and profile that is used in the PT field. The timestamp gives information about when this object is to be presented. The marker bit tells when the last packet in an object has been received. Looking at the start of the payload the header type field gives that it is an Object Identifier. The length field of the OID gives how long to read before the next payload header begins. The byte offset header is of fixed length and after it is the data header. Directly after the header the data begins and runs to the end of the payload. 6. Media Profiles For each media type that is going to use this payload format, a profile MUST be defined. A profile SHALL consists of the following: - Definition of which of the general headers that are required, or optional. Any unlisted header is prohibited - Any definitions and numbering of profile specific headers. - How to fragment an object to large for a single packet. - Requirements and recommendations on how to improve the error resilience of the media objects. - A security consideration - MIME Registration of the profile In the following we give examples for appropriate media profiles for JPEG images and text. 6.1. JPEG Images, and especially JPEG, are widely used in multimedia presentations. This profile describes how to transport image objects in the form of JPEG coded images. The purpose of this profile is different than the RTP payload format defined for motion JPEG in RFC 2035 [14] The JPEG file should conform to the JPEG standard defined in ITU-T Rec. T.81 | ISO/IEC 10918-1:1992 and the JPEG File Interchange Format, JFIF. The images are transported in the data and the JPEG file should end with an End-Of-Image, EOI, marker segment signaled as 0xFFD9 [13]. 6.1.1. Resilient transport A JPEG image might not be possible to fragment into sizes suitable for transport over IP networks without converting the bit stream. Westerlund et al. [Page 11] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 To achieve images that can be fragmented according to the ALF principle the image MUST be created using restart markers. This marker makes it possible for the decoder to restart the decoding even if previous segments were lost. Also Restart Interval Definition (DRI), see B.2.4.4 in [13], SHOULD be used in a way that allows a decoder to compute the spatial area that is affected by a lost fragment. The JPEG file header contains information that is absolutely necessary for the decoding process. To ensure that this vital information reaches the receiver, it SHOULD be repeated in each packet. The relevant JPEG header information that needs to be duplicated is labeled "Tables/Misc." and "Frame Header" (see B.2.4 and B.2.2 in [13]). 6.1.2. Profile specific headers JPEG image header (JPEGhdr) This header is used for repeating the header information in packets that do not carry the header information in their data section. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hd.type (128) | Length | JPEG Header Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (Variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: The length in bytes of the JPEG Header Data. JPEG Header Data: The data that MUST be copied into this header is: Any information belonging to those parts of the bit stream labeled "Tables/Misc." mentioned in section B.2.4, and "Frame Header" in section B.2.2 in [13]. This means that the JPEG header data includes all bytes starting with the first byte after the SOI (start of image marker) until the scan starts. 6.1.3. Payload format header usage: Any application using this profile MUST follow the table below defining the usage of headers. Westerlund et al. [Page 12] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 Headers Required Optional ---------------------------------------------- Data x OID x Duration x ByteOffset x JPEGhdr x Each image is an object and fragmented if needed. The fragmentation SHOULD be done at a restart marker. The ByteOffset header is used to indicate where in each byte stream a fragment belongs. A JPEG image header SHOULD be added to all packets to ensure that this essential header information reaches the receiver. 6.2. TEXT Time-lined text is typically used in subtitling, presentations, advertisements, etc. Text streamed separate from other media will give a greater flexibility in terms of language as well as spatial and temporal control. This profile describes how to transport text objects in the form of strings. Each string consists of one or more lines. The text strings are transported in the data part and SHALL also be NULL terminated. The encoding of text shall be ISO 10 646-1 code with UTF-8 transformation. 6.2.1. Resilient transport To make transport of text objects resilient against transport errors the following measures can be taken. The use of code based FEC, e.g. RFC 2733 [7] is RECOMMENDED to be calculated over a single object. This will reduce the extra delay that any recovery packet will result in. The use of FEC over an object consisting of a single packet MAY give no advantage at all, compared to repeating the packet one or several times. It is RECOMMENDED to use retransmission [10][11][12] whenever it is possible. 6.2.2. Profile Specific Headers Text Fragmentation header This header is used to fragment text objects that are larger then one packet (which is not the case for e.g. subtitling as mentioned earlier, but can be the case for other applications). It has a row Westerlund et al. [Page 13] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 and column offset used to place it in the correct position. A row is equal to a text line and ends by a new line marker. The column number is equal to which characters in order it is on the line, since the last new line marker. A Text object MAY be fragmented at any character, but it is RECOMMENDED to do fragmentation between sentences or even more preferably between paragraphs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hd.type (128) | Row Offset | Col. Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Row Offset: 14 bits used to give a row offset into the text object, i.e. the line in the text object which this packet's data start on. Column Offset: 10 bits giving which character on the line that the text in the data part shall start on. 6.2.3. Payload format header usage: Any application using this profile MUST follow the table below defining the usage of headers. Headers Required Optional Prohibited ---------------------------------------------------------- Data x OID x Duration x ByteOffset x TextFrag x When fragmenting text objects it MUST be done using the TextFrag header and not the ByteOffset header that would be a possibility. The reason is that in the event of packet loss the fragment can be placed on the correct row and character. Thus maintaining correct layout for all received fragments. 7. Congestion Control The need of congestion control for data transported with RTP has to be considered. Some of the static media that can be transported by this payload format have the possibility to adapt the size of each object by trading size against quality. For example, an image can be compressed to different sizes and corresponding qualities, and the different versions can be sent alternatively. Attempting to use more than the available bandwidth SHOULD be avoided. If FEC is used, there is a need to regulate the amount, so that the FEC itself does not Westerlund et al. [Page 14] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 worsen the problem. Therefore, it is RECOMMENDED that applications using this payload also implement congestion control. The actual mechanism for congestion control is not specified but should be suitable for real-time flows, e.g. "Equation-Based Congestion Control for Unicast Applications" [8]. For a more unified congestion control between streams the congestion manager [15] can be used. 8. Security Consideration RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3]. This implies that confidentiality of the media streams is achieved by encryption. Because the payload format is arranged end-to-end, encryption MAY be performed after encapsulation so there is no conflict between the two operations. This payload type and the profiles specified within this document does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat. This MUST be considered and stated for all new profiles created. Otherwise the main security issues are confidentiality and authentication of the media itself. The payload format itself does not have any support for security. These issues have to be solved by a payload external mechanism, e.g. SRTP [9]. 8.1. Confidentiality To achieve confidentiality of the transported media, all RTP payload bits MUST be encrypted. 8.2. Authentication To authenticate the sender of the media an external mechanism has to be added. It is RECOMMENDED that such a mechanism protect all the payload bits. To prevent a man in the middle from tampering with the packetization of the media data, also the RTP header SHOULD be protected. Tampering with the RTP header could result in erroneous depacketization/decoding that will lower media quality. 9. IANA Considerations [TBW] 10. MIME type registration [TBW] Westerlund et al. [Page 15] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 11. Author's Addresses Magnus Westerlund Tel: +46 8 4048287 Ericsson Research Email: Magnus.Westerlund@ericsson.com Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN Kristofer Dovstam Tel: +46 8 7641788 Ericsson Research Email: Kristofer.Dovstam@era.ericsson.se Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN Frank Hartung Tel: +49 2407 575389 Ericsson Research Email: Frank.Hartung@eed.ericsson.se Ericsson Eurolab Deutschland GmbH Ericsson Allee 1 D-52134 Herzogenrath, GERMANY Uwe Horn Tel: +49 2407 5757834 Ericsson Research Email: Uwe.Horn@eed.ericsson.se Ericsson Eurolab Deutschland GmbH Ericsson Allee 1 D-52134 Herzogenrath, GERMANY 12. References [1] Synchronized Multimedia Integration Language(SMIL 2.0) Specification, work in progress, http://www.w3.org/TR/2001/PR- smil20-20010605/, June 2001 [2] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [3] IETF RFC1889, "RTP: A Transport Protocol for Real-Time Applications". [4] IETF RFC 2327, "Session Description Protocol (SDP)". [5] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L., "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", IEEE/ACM Transactions on Networking, December 1997, Volume 5, Number 6, pp. 784-803. [6] D. Clark, D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proc. ACM SIGCOMM'90, 1990. [7] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, IETF, December 1999. Westerlund et al. [Page 16] INTERNET-DRAFT RTP Payload Format for Static Media July 12, 2001 [8] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000, Stockholm, Sweden. [9] R. Blom, et al., "The Secure Real Time Transport Protocol", IETF WG draft, draft-ietf-avt-srtp-00.txt, February 2001, Work in progress. [10] Stephan Wenger and Joerg Ott, "RTCP-based Feedback: Concepts and Message Timing Rules", draft-wenger-avt-rtcp-feedback-02.txt, IETF, March 2001, Work in progress. [11] Shigeru Fukunaga, et al., "Low Delay RTCP Feedback Format", draft-fukunaga-low-delay-rtcp-02.txt, IETF, February 2001, Work in progress. [12] Miyazaki et al., "RTP Retransmission Payload Format", IETF WG draft, draft-ietf-avt-rtp-selret-01.txt, February 2001, Work in progress. [13] ISO/IEC 10918-1, Information technology - Digital compression and coding of continuous-tone still images requirements and guidelines. [14] L. Berc, et al., "RTP Payload Format for JPEG-compressed Video", RFC 2035, IETF, October 1996. [15] H. Balakrishnan and S. Seshan, "The Congestion Manager", RFC 3124, IETF, June 2001. This Internet-Draft expires in January 2002. Westerlund et al. [Page 17]