idnits 2.17.1 draft-ietf-avt-profile-interop-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1890 (ref. '2') (Obsoleted by RFC 3551) ** Obsolete normative reference: RFC 1889 (ref. '3') (Obsoleted by RFC 3550) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Colin Perkins 2 USC/ISI 4 RTP Audio/Video Profile Interoperability Statement 6 draft-ietf-avt-profile-interop-06.txt 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at 19 any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as work in progress. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this document is unlimited. 30 Comments are solicited and should be addressed to the author and/or the 31 IETF Audio/Video Transport working group's mailing list at avt@ietf.org 33 Abstract 35 It is required to demonstrate interoperability of implementations 36 in order to move the RTP audio/video profile to draft standard. 37 This memo outlines those features to be tested, as the first 38 stage of an interoperability statement. 40 1 Introduction 42 The Internet standards process [1] places a number of requirements 43 on a standards track protocol specification. In particular, when 44 advancing a protocol from proposed standard to draft standard it 45 is necessary to demonstrate at least two independent and interoperable 46 implementations, from different code bases, of all options and features of 47 that protocol. Further, in cases where one or more options or features 48 have not been demonstrated in at least two interoperable implementations, 49 the specification may advance to the draft standard level only if those 50 options or features are removed. The RTP Profile for Audio and Video 51 Conferences with Minimal Control was originally specified in RFC1890 as a 52 proposed standard [2]. The revision of this specification for draft 53 standard status is now well underway, so it has become necessary to conduct 54 such an interoperability demonstration. 56 This memo describes the set of features and options of the RTP Audio/Video 57 profile which need to be tested as a basis for this demonstration. 59 This memo is for information only and does not specify a standard 60 of any kind. 62 2 Features and options required to demonstrate interoperability 64 In order to demonstrate interoperability it is required to produce 65 a statement of interoperability for each feature noted below. Such 66 a statement should note the pair of implementations tested, including 67 version numbers, and a pass/fail statement for each feature. It 68 is not expected that every implementation will implement every feature, 69 but each feature needs to be demonstrated by some pair of applications. 71 The RTP specification [3] enumerates a number of items that can be 72 specified or modified by a profile. Those modified from the defaults 73 by the audio/video profile are as follows, and interoperable behaviour 74 must be demonstrated: 76 1. Exchange of RTCP packets with the default RTCP reporting interval. 78 o PASS: rat, IP/TV 80 2. Exchange of RTCP packets with a modified RTCP reporting interval 81 as selected by a different fraction of the session bandwidth 82 (the means by which this interval is signalled are outside of 83 the scope of this memo, but one such mechanism should be demonstrated). 85 o PASS: IP/TV, rtplib 87 3. Implementations must send RTCP packets containing an SDES CNAME 88 in every reporting interval. 90 o PASS: rat, IP/TV 92 4. Other SDES items must be sent every third interval, with NAME 93 every 7 of 8 times within that slot and any other SDES items 94 cycically taking up the 8th slot. 96 o PASS: rat, IP/TV 98 5. Interoperable selection of `pass phrase' for encryption and exchange 99 of media using DES encryption. This must include mapping of 100 the pass phrase to the canonical form. 102 o FAIL: NeVoT does this, need to test... 104 6. Interoperable transport of RTP via unicast UDP 106 o PASS: rat, vat, vic, IP/TV 108 7. Interoperable transport of RTP via multicast UDP 110 o PASS: rat, vat, vic, IP/TV 112 8. Interoperable transport of RTP via TCP using the encapsulation 113 defined in section 7 of [2]. 115 o FAIL: Real have it? 117 The primary purpose of the audio/video profile is to define the mapping 118 from payload format to payload type number. Accordingly, the majority 119 of the work needed to demonstrate interoperability consists of testing 120 that media data is exchanged in an interoperable manner using the 121 full range of codecs enumerated in the profile. 123 The following codecs are assigned static payload types. It should 124 be verified that interoperable implementations exist for each static 125 payload type: 127 1. The 8kHz PCMU codec (payload type 0) 129 o PASS: rat, vat, fphone, IP/TV, Nuera. 131 2. The 8kHz 1016 codec (payload type 1) 133 o FAIL 135 3. The 8kHz G726-32 codec (payload type 2) 137 o PASS: rat vs Ericsson (tested by Magnus Westerlund) 139 4. The 8kHz GSM codec (payload type 3) 141 o PASS: rat, vat, fphone, IP/TV 143 5. The 8kHz G723 codec (payload type 4) 145 o PASS: AudioCodes has performed Interoperability of its G.723.1 146 coder with Microsoft NetMeeting, Telogy (a TI company), VocalTec 147 as well as several other companies (reported by Yehuda Herskovitz). 149 o PASS: Also implementations by Nuera, Meridian 1 ITG, BCM 150 and Matra 6500, Microsoft Netmeeting, Cisco. (Reported by 151 Tom Taylor). 153 o PASS: Nortel Meridian ITG with Acer, Arelnet, Cisco IOS gateway, 154 CU-SeeMe (MCU and endpoint), Dataconnection (MCU and endpoint), 155 Delta Information Systems, First Virtual Corporation, Intel 156 Internet Phone, Avaya Definity, Lucent Alchemy, Microsoft 157 Netmeeting, Radcom, Radvision L2W Gateway, Samsung Si, Sony 158 Contact. Nortel Business Communication Manager and Nortel 159 Matra 6500 would have similar interoperability list. 161 6. The 8kHz DVI4 codec (payload type 5) 163 o PASS: rat, vat, fphone, IP/TV 165 7. The 16kHz DVI4 codec (payload type 6) 167 o PASS: QuickTime vs rat 169 8. The 8kHz LPC codec (payload type 7) 171 o PASS: rat, vat, fphone 173 9. The 8kHz PCMA codec (payload type 8) 175 o PASS: Nuera with Lucent 177 10. The 8kHz G722 codec (payload type 9) 179 o PASS: Accord have tested with Polycom, VCON and PictureTel. 180 RealAudio have an implementation, also. 182 11. The 44.1kHz stereo L16 codec (payload type 10) 184 o PASS: RealNetworks with QuickTime 186 12. The 44.1kHz mono L16 codec (payload type 11) 188 o PASS: RealNetworks with QuickTime 190 13. The 8kHz QCELP codec (payload type 12) 192 o PASS: RealNetworks with QuickTime 194 14. The 8kHz CN codec (payload type 13) 196 o RESERVED: no need to test for now? 198 15. The MPA codec (payload type 14) 200 o PASS: IP/TV, PixStream, Minerva, LiveCaster 202 16. The 8kHz G728 codec (payload type 15) 204 o PASS: Accord have tested with Polycom, VCON and PictureTel. 205 Nuera have an implementation, also. 207 17. The 11.025kHz DVI4 codec (payload type 16) 209 o PASS: QuickTime vs rat 211 18. The 22.050kHz DVI4 codec (payload type 17) 213 o PASS: QuickTime vs rat 215 19. The 8kHz G729 codec (payload type 18) 217 o PASS: Nuera vs Cisco, Nortel, VegaStream (SIP Bakeoff 5) 219 The following codecs use dynamic payload types. It should be verified 220 that some non-RTP means can be used to assign a dynamic payload type 221 to be used by implementations, and that those implementations can 222 then interwork. 224 1. The GSM-HR codec 226 o FAIL: Cisco have an impl? Dinesh Nambisan (dineshn@cisco.com) 228 2. The GSM-EFR codec 230 o PASS: Tested implementations by Magnus Westerlund at Ericsson 231 and Ari Lakaniemi at Nokia. Also implementations by Nuera 232 (Maroula Bratakos ) and Cisco (Ling 233 Niu) exist. 235 3. The L8 codec 237 o PASS: RealNetworks with QuickTime 239 4. The RED codec 241 o PASS: rat, fphone 243 5. The VDVI codec 245 o PASS: rat, fphone 247 Similarly, interoperable implementation of the following video codecs 248 with static payload type numbers must be demonstrated: 250 1. The CellB codec (payload type 25) 252 o PASS: JMF 2.1, VIC 2.8-1.1.3 from UCL, ShowMeTV, NV 254 2. The JPEG codec (payload type 26) 256 o PASS: ShowMeTV, Quicktime, vic. 258 3. The nv codec (payload type 28) 260 o PASS: nv and vic (confirmed by Ron Frederick) 262 4. The H261 codec (payload type 31) 264 o PASS: IP/TV, vic, VCON, Polycom 266 5. The MPV codec (payload type 32) 268 o PASS: IP/TV, PixStream, Minerva 270 6. The MP2T codec (payload type 33) 272 o PASS: Cisco have a pre-release implementation which receives 273 from the Optibase Media GateWay 3100 v1.0 (Humphrey Liu 274 ). Sun also have an implementation, and are 275 willing to test (Jonathan Sergent ) 277 7. The H263 codec (payload type 34) 279 o PASS: PictureTel with Vtel, Polycom, etc. (Lulin Chen) 281 The following codecs use dynamic payload types. It should be verified 282 that some non-RTP means can be used to assign a dynamic payload type 283 to be used by implementations, and that those implementations can 284 then interwork. 286 1. The BT656 codec 288 o FAIL: Cabo has an implementation 290 2. The H263-1998 codec 292 o PASS: RealNetworks with QuickTime 294 3. The MP1S codec 296 o FAIL: quicktime has it, anyone else? 2NetFX? Optivision? 298 4. The MP2P codec 300 o FAIL: quicktime has it, anyone else? 2NetFX? Optivision? 302 5. The BMPEG codec 304 o FAIL 306 Implementations must also demonstrate interoperable use of the marker 307 bit. That is, the M bit is set on the first packet of each talkspurt 308 for audio and on the last packet of each frame for video. 310 3 Author's Address 312 Colin Perkins 313 USC Information Sciences Institute 314 3811 North Fairfax Drive 315 Suite 200 316 Arlington, VA 22203 317 USA 318 Email: csp@isi.edu 320 4 References 322 [1] S. Bradner, ``The Internet Standards Process -- Revision 3'', 323 RFC2026, Internet Engineering Task Force, October 1996. 325 [2] H. Schulzrinne, S. Casner, ``RTP Profile for Audio and Video 326 Conferences with Minimal Control'', RFC1890, Internet Engineering 327 Task Force, January 1996. 329 [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: 330 A Transport Protocol to Real-Time Applications'', RFC1889, Internet 331 Engineering Task Force, January 1996.