idnits 2.17.1 draft-finlayson-avt-mpa-robust-interoperability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 171. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 177. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 203 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2004) is 7142 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3119 (Obsoleted by RFC 5219) == Outdated reference: A later version (-05) exists of draft-ietf-avt-rfc3119bis-02 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ross Finlayson 2 INTERNET-DRAFT LIVE.COM 3 Expires: February 5, 2004 October 5, 2004 5 Interoperability of the "audio/mpa-robust" RTP Payload Format 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 In order for the "audio/mpa-robust" RTP payload format specification 33 to advance from Proposed Standard to Draft Standard, it is required 34 to demonstrate interoperability for all functionality described by 35 the specification. This document describes the interoperability 36 shown between different implementations of this specification. 38 1. Introduction 40 The "audio/mpa-robust" RTP payload format for MP3 audio is described 41 in RFC 3119 [3119] (and updated in [3119BIS] to correct typographical 42 errors). This payload format is an alternative to the format 43 described in RFC 2250 [2250], and performs better if there is 44 packet loss. 46 This RTP payload format specification is currently at Proposed 47 Standard. In order to advance to Draft Standard, the Internet 48 standards process [2026] requires "at least two independent and 49 interoperable implementations from different code bases," and that 50 interoperability be shown for "all of the options and features of 51 the specification." This document describes the interoperability 52 shown between three independent implementations: 53 1/ "LIVE.COM Streaming Media" project's "testMP3Streamer" 54 application [LIVEMEDIA]. 55 2/ RealNetworks' "RealPlayer 9" media player [REAL]. 56 3/ The "MPEG4IP" project's "mp4player" media player [MPEG4IP]. 57 (Despite its name, this player plays MP3 audio in addition 58 to MPEG-4 formats.) 60 2. Features Tested for Interoperability 62 RTP payloads conforming to this specification can vary in the 63 following ways: 65 1/ Descriptor size. 66 As specified by the "T" (descriptor type) flag in each ADU 67 descriptor, the descriptor size can be either 1 byte (for ADU 68 frame sizes < 64), or 2 bytes. 70 2/ Fragmentation. 71 If an "ADU frame" is too large to fit within a RTP packet, it 72 is fragmented across more than one RTP packet (each beginning with 73 an ADU descriptor. The fragmentation is indicated by the "C" 74 (continuation) flag in each ADU descriptor. 76 3/ Interleaving. 77 The high-order 11 bits of each MPEG header ('syncword') can either 78 remain at 0xFFE - which indicates that no ADU frame interleaving 79 is performed - or it can consist of an "Interleaving Sequence 80 Number" - which indicates that ADU frames are rearranged in an 81 interleaving pattern. 83 As described in the next section, we demonstrated interoperability 84 by testing each combination of these three variables. 86 3. Test Results 88 The results of the interoperability tests are shown in the table 89 below. In each case, the LIVE.COM "testMP3Streamer" application 90 was used as the transmitter, and one (or both) of the "RealPlayer 9" 91 and MPEG4IP "mp4player" applications was used as the receiver. 93 +-----------------+----------------+---------------++------+-----------+ 94 | Stream Features || Receiver | 95 +-----------------+----------------+---------------++------+-----------+ 96 | descriptor size | fragmentation? | interleaving? || Real | mp4player | 97 +-----------------+----------------+---------------++------+-----------+ 98 | 1 byte | no | no || Yes | Yes | 99 | 1 byte | no | yes || Yes | Yes | 100 | 1 byte | yes | no || No | Yes | 101 | 1 byte | yes | yes || No | Yes | 102 | 2 bytes | no | no || Yes | Yes | 103 | 2 bytes | no | yes || Yes | Yes | 104 | 2 bytes | yes | no || No | Yes | 105 | 2 bytes | yes | yes || No | Yes | 106 +-----------------+----------------+---------------++------+-----------+ 108 Note: As noted in the table, "RealPlayer 9" was unable to handle 109 fragmented ADU frames. However, because "mp4player" was able to play 110 fragmented frames from the LIVE.COM "testMP3Streamer" application, 111 this is sufficient to demonstrate interoperability of this feature 112 between two independent implementations. 114 4. Security Considerations 116 Not applicable. 118 5. Normative References 120 [3119] Finlayson, R., "A More Loss-Tolerant RTP Payload 121 Format for MP3 Audio," RFC 3119, June 2001. 123 [2026] Bradner, S., "The Internet Standards Process 124 -- Revision 3," RFC 2026, October 1996. 126 6. Informative References 128 [3119BIS] Finlayson, R., "A More Loss-Tolerant RTP Payload 129 Format for MP3 Audio," 130 draft-ietf-avt-rfc3119bis-02.txt, 131 Work in progress, February 2004. 133 [2250] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, 134 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 135 January 1998. 137 [LIVEMEDIA] "LIVE.COM Streaming Media," Live Networks, Inc., 138 . 140 [REAL] RealNetworks, Inc., . 142 [MPEG4IP] The "MPEG4IP Open Streaming Video and Audio" project, 143 . 145 7. Author's Address 147 Ross Finlayson, 148 Live Networks, Inc. (LIVE.COM) 149 650 Castro St., suite 120-196 150 Mountain View, CA 94041 152 EMail: finlayson (at) live.com 153 WWW: http://www.live.com/ 155 8. IPR Notice 157 The IETF takes no position regarding the validity or scope of any 158 Intellectual Property Rights or other rights that might be claimed 159 to pertain to the implementation or use of the technology 160 described in this document or the extent to which any license 161 under such rights might or might not be available; nor does it 162 represent that it has made any independent effort to identify any 163 such rights. Information on the procedures with respect to rights 164 in RFC documents can be found in BCP 78 and BCP 79. 166 Copies of IPR disclosures made to the IETF Secretariat and any 167 assurances of licenses to be made available, or the result of an 168 attempt made to obtain a general license or permission for the use 169 of such proprietary rights by implementers or users of this 170 specification can be obtained from the IETF on-line IPR repository 171 at http://www.ietf.org/ipr. 173 The IETF invites any interested party to bring to its attention 174 any copyrights, patents or patent applications, or other 175 proprietary rights that may cover technology that may be required 176 to implement this standard. Please address the information to the 177 IETF at ietf-ipr@ietf.org. 179 9. Copyright Notice 181 Copyright (C) The Internet Society (2004). This document is subject 182 to the rights, licenses and restrictions contained in BCP 78, and 183 except as set forth therein, the authors retain all their rights. 185 This document and the information contained herein are provided on an 186 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 187 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 188 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 189 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 190 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 191 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 193 Expires: Febrary 5, 2005