idnits 2.17.1 draft-ietf-avt-rtp-interop-07.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 7 longer pages, the longest (page 1) being 65 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 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 1889 (ref. '2') (Obsoleted by RFC 3550) == Outdated reference: A later version (-13) exists of draft-ietf-avt-profile-new-08 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-avt-rtptest-04 ** Downref: Normative reference to an Informational draft: draft-ietf-avt-rtptest (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Colin Perkins 2 USC/ISI 4 RTP Interoperability Statement 6 draft-ietf-avt-rtp-interop-07.txt 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and 18 may be updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet-Drafts as reference material or to cite 20 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 rem-conf@es.net. 33 Abstract 35 It is required to demonstrate interoperability of RTP implementations 36 in order to move the RTP specification to draft standard. This memo 37 outlines those features to be tested, as the first stage of an 38 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 47 of that protocol. Further, in cases where one or more options or 48 features have not been demonstrated in at least two interoperable 49 implementations, the specification may advance to the draft standard 50 level only if those options or features are removed. The Real-time 51 Transport Protocol, RTP, was originally specified in RFC1889 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 54 to conduct such an interoperability demonstration. 56 This memo describes the set of features and options of the RTP specification 57 which need to be tested as a basis for this demonstration. Due to the 58 nature of RTP there are necessarily two types of test described: those 59 which directly affect the interoperability of implementations at a ``bits 60 on the wire level'' and those which affect scalability and safety of the 61 protocol but do not directly affect interoperability. A related memo [4] 62 describes a testing framework which may aid with interoperability testing. 64 This memo is for information only and does not specify a standard 65 of any kind. 67 2 Features and options required to demonstrate interoperability 69 In order to demonstrate interoperability it is required to produce 70 a statement of interoperability for each feature noted below. Such 71 a statement should note the pair of implementations tested, including 72 version numbers, and a pass/fail statement for each feature. It 73 is not expected that every implementation will implement every feature, 74 but each feature needs to be demonstrated by some pair of applications. 76 Note that some of these tests depend on the particular profile used, 77 or upon options in that profile. For example, it will be necessary 78 to test audio and video applications operating under [3] separately. 80 1. Interoperable exchange of data packets using the basic RTP header 81 with no header extension, padding or CSRC list. 83 o PASS: rat vs vat 85 o PASS: IP/TV vs vat/vic 87 2. Interoperable exchange of data packets which use padding. 89 o PASS: IP/TV vs rat 91 3. Interoperable exchange of data packets which use a header extension. 92 There are three possibilities here: a) if both implementations 93 use a header extension in the same manner, it should be verified 94 that the receiver correctly receives the information contained 95 in the extension header; b) If the sender uses a header extension 96 and the receiver does not, it should be verified that the receiver 97 ignores the extension; c) If neither implementation implements 98 an extended header, this test is considered a failure. 100 o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2 102 4. Interoperable exchange of data packets using the marker bit as 103 specified in the profile. 105 o PASS: rat vs vat 107 o PASS: IP/TV vs vic 109 5. Interoperable exchange of data packets using the payload type 110 field to differentiate multiple payload formats according to 111 a profile definition. 113 o PASS: rat vs vat 115 o PASS: IP/TV vs vat/vic 117 6. Interoperable exchange of data packets containing a CSRC list. 119 o PASS: rat vs vat 121 o PASS: IP/TV vs vat/vic 123 7. Interoperable exchange of RTCP packets, which must be compound 124 packets containing at least an initial SR or RR packet and an 125 SDES CNAME packet. Other RTCP packet types may be included, 126 but this is not required for this test. 128 o PASS: rat vs vat 130 o PASS: IP/TV vs vat/vic 132 8. Interoperable exchange of sender report packets when the receiver 133 of the sender reports is not also a sender (ie: sender reports 134 which only contain sender info, with no report blocks). 136 o PASS: rat vs vat 138 o PASS: IP/TV vs vat/vic 140 9. Interoperable exchange of sender report packets when the receiver 141 of the sender reports is also a sender (ie: sender reports 142 which contain one or more report blocks). 144 o PASS: rat vs vat 146 o PASS: IP/TV vs vat/vic (IP/TV never sends SR with report 147 blocks, but does successfully receive them from vic/vat). 149 10. Interoperable exchange of receiver report packets. 151 o PASS: rat vs vat 153 o PASS: IP/TV vs vat/vic 155 11. Interoperable exchange of receiver report packets when not receiving 156 data (ie: the empty receiver report which has to be sent first 157 in each compound RTCP packet when no-participants are transmitting 158 data). 160 o PASS: rat vs vat 162 o PASS: IP/TV vs vat/vic 164 12. Interoperable and correct choice of CNAME, according to the rules 165 in the RTP specification and profile (applications using the 166 audio/video profile [3] under IPv4 should typically generate 167 a CNAME of the form `example@10.0.0.1', or `10.0.0.1' if they 168 are on a machine which no concept of usernames). 170 o PASS: rat vs vat 172 o PASS: IP/TV vs vat/vic 174 13. Interoperable exchange of source description packets containing 175 a CNAME item. 177 o PASS: rat vs vat 179 o PASS: IP/TV vs vat/vic 181 14. Interoperable exchange of source description packets containing 182 a NAME item. 184 o PASS: rat vs vat 186 o PASS: IP/TV vs vat/vic 188 15. Interoperable exchange of source description packets containing 189 an EMAIL item. 191 o PASS: rat vs vat 193 o PASS: IP/TV vs vat/vic 195 16. Interoperable exchange of source description packets containing 196 a PHONE item. 198 o PASS: rat vs vat 200 o PASS: IP/TV vs vat/vic 202 17. Interoperable exchange of source description packets containing 203 a LOC item. 205 o PASS: rat vs vat 207 o PASS: IP/TV vs vat/vic 209 18. Interoperable exchange of source description packets containing 210 a TOOL item. 212 o PASS: rat vs vat 214 o PASS: IP/TV vs vat/vic 216 19. Interoperable exchange of source description packets containing 217 a NOTE item. 219 o PASS: rat vs vat 221 o PASS: IP/TV vs vat/vic 223 20. Interoperable exchange of source description packets containing 224 a PRIV item. 226 o FAIL: need to test rtplib against rtpdump? 228 o FAIL: Ericsson have an implementation, Magnus Westerlund 229 will test against rat. 231 21. Interoperable exchange of BYE packets containing a single SSRC. 233 o PASS: rat vs vat 235 o PASS: IP/TV vs vat/vic 237 22. Interoperable exchange of BYE packets containing multiple SSRCs. 239 o FAIL: rat can send these, but vat only accepts the first 240 SSRC 242 o FAIL: IP/TV sends only one SSRC in BYE, but should accept 243 multiple 245 o FAIL: need to test rat-3.0.x against rtplib 247 23. Interoperable exchange of BYE packets containing the optional 248 reason for leaving text. 250 o PASS: tested IP/TV sending to vat. Also rtplib generates 251 and displays them. 253 24. Interoperable exchange of application defined RTCP packets. As 254 with the RTP header extension this test takes two forms: if 255 both implementations implement the same application defined packet 256 it should be verified that those packets can be interoperably 257 exchanged. If only one implementation uses application defined 258 packets, it should be verified that the other implementation 259 can receive compound RTCP packets containing an APP packet whilst 260 ignoring the APP packet. If neither implementation implements 261 APP packets this test is considered a failure. 263 o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2 265 25. Interoperable exchange of encrypted RTP packets using DES encryption 266 in CBC mode. 268 o PASS: rat vs vat 270 26. Interoperable exchange of encrypted RTCP packets using DES encryption 271 in CBC mode. 273 o PASS (sort of): rat vs vat (vat gets the padding wrong 274 in some cases, but mostly it works). 276 3 Features and options relating to scalability 278 In addition to the basic interoperability tests, RTP includes a number of 279 features relating to scaling of the protocol to large groups. Since these 280 features are those which have undergone the greatest change in the update 281 of the RTP specification, it is considered important to demonstrate their 282 correct implementation. However, since these changes do not affect the 283 bits-on-the-wire behaviour of the protocol, it is not possible to perform a 284 traditional interoperability test. As an alternative to such testing we 285 require that multiple independent implementations complete the following 286 demonstrations. 288 1. Demonstrate correct implementation of basic RTCP transmission 289 rules: periodic transmission of RTCP packets at the minimum 290 (5 second) interval and randomisation of the transmission interval. 292 o PASS: rat, IP/TV 294 2. Demonstrate correct implementation of the RTCP step join backoff 295 algorithm as a receiver. 297 o PASS: rat, rtplib 299 3. Demonstrate correct implementation of the RTCP step join backoff 300 algorithm as a sender. 302 o PASS: rat, rtplib 304 4. Demonstrate correct steady state scaling of the RTCP interval 305 acording to the group size. 307 o PASS: rat, IP/TV 309 5. Demonstrate correct steady state scaling of the RTCP interval 310 acording to the group size with compensation for the number of 311 senders. 313 o PASS: rat, IP/TV 315 6. Demonstrate correct implementation of the RTCP reverse reconsideration 316 algorithm. 318 o FAIL: rat is correct, 320 o FAIL: Ericsson have an implementation: Magnus Westerlund 321 is testing... 323 7. Demonstrate correct implementation of the RTCP BYE reconsideration 324 algorithm. 326 o FAIL: Ericsson have an implementation: Magnus Westerlund 327 is testing... 329 8. Demonstrate correct implementation of the RTCP member timeout 330 algorithm. 332 o PASS: IP/TV, vat, rat 334 o FAIL: Ericsson have an implementation: Magnus Westerlund 335 is testing... 337 9. Demonstrate random choice of SSRC. 339 o PASS: rat, IP/TV, LiveCaster 341 10. Demonstrate random selection of initial RTP sequence number. 343 o PASS: rat, LiveCaster 345 11. Demonstrate random selection of initial RTP timestamp. 347 o PASS: rat, LiveCaster 349 12. Demonstrate correct implementation of the SSRC collision/loop 350 detection algorithm. 352 o PASS: IP/TV, vat 354 13. Demonstrate correct generation of reception report statistics 355 in SR/RR packets. 357 o PASS: rat, IP/TV 359 14. Demonstrate correct generation of the sender info block in SR 360 packets. 362 o PASS: rat, IP/TV 364 4 Author's Address 366 Colin Perkins 367 USC Information Sciences Institute 368 4350 North Fairfax Drive 369 Suite 620 370 Arlington, VA 22203 371 USA 373 Email: csp@isi.edu 375 5 References 377 [1] S. Bradner, ``The Internet Standards Process -- Revision 3'', 378 RFC2026, Internet Engineering Task Force, October 1996. 380 [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: A 381 Transport Protocol to Real-Time Applications'', RFC1889, Internet 382 Engineering Task Force, January 1996. 384 [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 385 Minimal Control'', draft-ietf-avt-profile-new-08.txt, January 2000. 387 [4] C. S. Perkins, J. Rosenberg and H. Schulzrinne, ``RTP Testing 388 Strategies'', draft-ietf-avt-rtptest-04.txt, November 2000.