idnits 2.17.1 draft-ietf-avt-rtp-interop-05.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 4 longer pages, the longest (page 4) being 62 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 12 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.) -- The document date (22 November 2000) is 8555 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 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 INTERNET-DRAFT 22 November 2000 3 Colin Perkins 4 USC/ISI 6 RTP Interoperability Statement 8 draft-ietf-avt-rtp-interop-05.txt 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other 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 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to 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 Distribution of this document is unlimited. 32 Comments are solicited and should be addressed to the author and/or the 33 IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. 35 Abstract 37 It is required to demonstrate interoperability of RTP implementations 38 in order to move the RTP specification to draft standard. This memo 39 outlines those features to be tested, as the first stage of an 40 interoperability statement. 42 1 Introduction 44 The Internet standards process [1] places a number of requirements 45 on a standards track protocol specification. In particular, when 46 advancing a protocol from proposed standard to draft standard it 47 is necessary to demonstrate at least two independent and interoperable 48 implementations, from different code bases, of all options and features of 49 that protocol. Further, in cases where one or more options or features 50 have not been demonstrated in at least two interoperable implementations, 51 the specification may advance to the draft standard level only if those 52 options or features are removed. The Real-time Transport Protocol, RTP, 53 was originally specified in RFC1889 as a proposed standard [2]. The 54 revision of this specification for draft standard status is now well 55 underway, so it has become necessary to conduct such an interoperability 56 demonstration. 58 This memo describes the set of features and options of the RTP specification 59 which need to be tested as a basis for this demonstration. Due to the 60 nature of RTP there are necessarily two types of test described: those 61 which directly affect the interoperability of implementations at a ``bits 62 on the wire level'' and those which affect scalability and safety of the 63 protocol but do not directly affect interoperability. A related memo [4] 64 describes a testing framework which may aid with interoperability testing. 66 This memo is for information only and does not specify a standard 67 of any kind. 69 2 Features and options required to demonstrate interoperability 71 In order to demonstrate interoperability it is required to produce 72 a statement of interoperability for each feature noted below. Such 73 a statement should note the pair of implementations tested, including 74 version numbers, and a pass/fail statement for each feature. It 75 is not expected that every implementation will implement every feature, 76 but each feature needs to be demonstrated by some pair of applications. 78 Note that some of these tests depend on the particular profile used, 79 or upon options in that profile. For example, it will be necessary 80 to test audio and video applications operating under [3] separately. 82 1. Interoperable exchange of data packets using the basic RTP header 83 with no header extension, padding or CSRC list. 85 o PASS: rat vs vat 87 o PASS: IP/TV vs vat/vic 89 2. Interoperable exchange of data packets which use padding. 91 o FAIL: need to test IP/TV against Quicktime 93 3. Interoperable exchange of data packets which use a header extension. 94 There are three possibilities here: a) if both implementations 95 use a header extension in the same manner, it should be verified 96 that the receiver correctly receives the information contained 97 in the extension header; b) If the sender uses a header extension 98 and the receiver does not, it should be verified that the receiver 99 ignores the extension; c) If neither implementation implements 100 an extended header, this test is considered a failure. 102 o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2 104 4. Interoperable exchange of data packets using the marker bit as 105 specified in the profile. 107 o PASS: rat vs vat 109 o PASS: IP/TV vs vic 111 5. Interoperable exchange of data packets using the payload type 112 field to differentiate multiple payload formats according to 113 a profile definition. 115 o PASS: rat vs vat 117 o PASS: IP/TV vs vat/vic 119 6. Interoperable exchange of data packets containing a CSRC list. 121 o PASS: rat vs vat 123 o PASS: IP/TV vs vat/vic 125 7. Interoperable exchange of RTCP packets, which must be compound 126 packets containing at least an initial SR or RR packet and an 127 SDES CNAME packet. Other RTCP packet types may be included, 128 but this is not required for this test. 130 o PASS: rat vs vat 132 o PASS: IP/TV vs vat/vic 134 8. Interoperable exchange of sender report packets when the receiver 135 of the sender reports is not also a sender (ie: sender reports 136 which only contain sender info, with no report blocks). 138 o PASS: rat vs vat 140 o PASS: IP/TV vs vat/vic 142 9. Interoperable exchange of sender report packets when the receiver 143 of the sender reports is also a sender (ie: sender reports 144 which contain one or more report blocks). 146 o PASS: rat vs vat 148 o PASS: IP/TV vs vat/vic (IP/TV never sends SR with report 149 blocks, but does successfully receive them from vic/vat). 151 10. Interoperable exchange of receiver report packets. 153 o PASS: rat vs vat 155 o PASS: IP/TV vs vat/vic 157 11. Interoperable exchange of receiver report packets when not receiving 158 data (ie: the empty receiver report which has to be sent first 159 in each compound RTCP packet when no-participants are transmitting 160 data). 162 o PASS: rat vs vat 164 o PASS: IP/TV vs vat/vic 166 12. Interoperable and correct choice of CNAME, according to the rules 167 in the RTP specification and profile (applications using the 168 audio/video profile [3] under IPv4 should typically generate 169 a CNAME of the form `example@10.0.0.1', or `10.0.0.1' if they 170 are on a machine which no concept of usernames). 172 o PASS: rat vs vat 174 o PASS: IP/TV vs vat/vic 176 13. Interoperable exchange of source description packets containing 177 a CNAME item. 179 o PASS: rat vs vat 181 o PASS: IP/TV vs vat/vic 183 14. Interoperable exchange of source description packets containing 184 a NAME item. 186 o PASS: rat vs vat 188 o PASS: IP/TV vs vat/vic 190 15. Interoperable exchange of source description packets containing 191 an EMAIL item. 193 o PASS: rat vs vat 195 o PASS: IP/TV vs vat/vic 197 16. Interoperable exchange of source description packets containing 198 a PHONE item. 200 o PASS: rat vs vat 202 o PASS: IP/TV vs vat/vic 204 17. Interoperable exchange of source description packets containing 205 a LOC item. 207 o PASS: rat vs vat 209 o PASS: IP/TV vs vat/vic 211 18. Interoperable exchange of source description packets containing 212 a TOOL item. 214 o PASS: rat vs vat 216 o PASS: IP/TV vs vat/vic 218 19. Interoperable exchange of source description packets containing 219 a NOTE item. 221 o PASS: rat vs vat 223 o PASS: IP/TV vs vat/vic 225 20. Interoperable exchange of source description packets containing 226 a PRIV item. 228 o FAIL: need to test rtplib against rtpdump? 230 21. Interoperable exchange of BYE packets containing a single SSRC. 232 o PASS: rat vs vat 234 o PASS: IP/TV vs vat/vic 236 22. Interoperable exchange of BYE packets containing multiple SSRCs. 238 o FAIL: rat can send these, but vat only accepts the first 239 SSRC 241 o FAIL: IP/TV sends only one SSRC in BYE, but should accept 242 multiple 244 o FAIL: need to test rat-3.0.x against rtplib 246 23. Interoperable exchange of BYE packets containing the optional 247 reason for leaving text. 249 o FAIL: need to test IP/TV with rtplib (IP/TV will generate 250 these when an SSRC collison occurs). 252 24. Interoperable exchange of BYE packets containing the optional 253 reason for leaving text and multiple SSRCs. 255 o FAIL: does anyone implement both? 257 25. Interoperable exchange of application defined RTCP packets. As 258 with the RTP header extension this test takes two forms: if 259 both implementations implement the same application defined packet 260 it should be verified that those packets can be interoperably 261 exchanged. If only one implementation uses application defined 262 packets, it should be verified that the other implementation 263 can receive compound RTCP packets containing an APP packet whilst 264 ignoring the APP packet. If neither implementation implements 265 APP packets this test is considered a failure. 267 o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2 269 26. Interoperable exchange of encrypted RTP packets using DES encryption 270 in CBC mode. 272 o PASS: rat vs vat 274 27. Interoperable exchange of encrypted RTCP packets using DES encryption 275 in CBC mode. 277 o PASS (sort of): rat vs vat (vat gets the padding wrong 278 in some cases, but mostly it works). 280 28. Interoperable exchange of encrypted RTCP packets using DES encryption 281 in CBC mode, when those compound RTCP packets have been split 282 into an encrypted packet and an unencrypted packet. 284 o FAIL: not tested (rtplib supports this?) 286 3 Features and options relating to scalability 288 In addition to the basic interoperability tests, RTP includes a number 289 of features relating to scaling of the protocol to large groups. 290 Since these features are those which have undergone the greatest 291 change in the update of the RTP specification, it is considered important 292 to demonstrate their correct implementation. However, since these 293 changes do not affect the bits-on-the-wire behaviour of the protocol, 294 it is not possible to perform a traditional interoperability test. 295 As an alternative to such testing we require that multiple independent 296 implementations complete the following demonstrations. 298 1. Demonstrate correct implementation of basic RTCP transmission 299 rules: periodic transmission of RTCP packets at the minimum 300 (5 second) interval and randomisation of the transmission interval. 302 o PASS: rat, IP/TV 304 2. Demonstrate correct implementation of the RTCP step join backoff 305 algorithm as a receiver. 307 o FAIL: rat and rtplib support this but have not been tested 309 3. Demonstrate correct implementation of the RTCP step join backoff 310 algorithm as a sender. 312 o FAIL: rat and rtplib support this but have not been tested 314 4. Demonstrate correct steady state scaling of the RTCP interval 315 acording to the group size. 317 o PASS: rat, IP/TV 319 5. Demonstrate correct steady state scaling of the RTCP interval 320 acording to the group size with compensation for the number of 321 senders. 323 o FAIL: IP/TV works, need results for more implementations 325 6. Demonstrate correct implementation of the RTCP reverse reconsideration 326 algorithm. 328 o FAIL 330 7. Demonstrate correct implementation of the RTCP BYE reconsideration 331 algorithm. 333 o FAIL 335 8. Demonstrate correct implementation of the RTCP member timeout 336 algorithm. 338 o FAIL 340 9. Demonstrate random choice of SSRC. 342 o PASS: rat, IP/TV, LiveCaster 344 10. Demonstrate random selection of initial RTP sequence number. 346 o PASS: rat, LiveCaster 348 11. Demonstrate random selection of initial RTP timestamp. 350 o PASS: rat, LiveCaster 352 12. Demonstrate correct implementation of the SSRC collision/loop 353 detection algorithm. 355 o PASS: IP/TV, vat 357 13. Demonstrate correct generation of reception report statistics 358 in SR/RR packets. 360 o PASS: rat, IP/TV 362 14. Demonstrate correct generation of the sender info block in SR 363 packets. 365 o PASS: rat, IP/TV 367 4 Author's Address 369 Colin Perkins 370 USC Information Sciences Institute 371 4350 North Fairfax Drive 372 Suite 620 373 Arlington, VA 22203 374 USA 376 Email: csp@isi.edu 378 5 Acknowledgments 380 Thanks to Steve Casner, Jonathan Rosenberg and Bill Fenner for their 381 helpful feedback. 383 6 References 385 [1] S. Bradner, ``The Internet Standards Process -- Revision 3'', 386 RFC2026, Internet Engineering Task Force, October 1996. 388 [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: 389 A Transport Protocol to Real-Time Applications'', RFC1889, Internet 390 Engineering Task Force, January 1996. 392 [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences 393 with Minimal Control'', draft-ietf-avt-profile-new-08.txt, January 394 2000. 396 [4] C. S. Perkins, J. Rosenberg and H. Schulzrinne, ``RTP Testing 397 Strategies'', draft-ietf-avt-rtptest-04.txt, November 2000.