idnits 2.17.1 draft-ietf-avt-rtp-interop-02.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 1 longer page, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 11 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 (21 October 1999) is 8947 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-05 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-avt-rtptest-01 ** Downref: Normative reference to an Informational draft: draft-ietf-avt-rtptest (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 21 October 1999 3 Colin Perkins 4 University College London 6 RTP Interoperability Statement 7 draft-ietf-avt-rtp-interop-02.txt 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as work in progress. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this document is unlimited. 31 Comments are solicited and should be addressed to the author and/or the 32 IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. 34 Abstract 36 It is required to demonstrate interoperability of RTP implementations 37 in order to move the RTP specification to draft standard. This memo 38 outlines those features to be tested, as the first stage of an 39 interoperability statement. 41 1 Introduction 43 The Internet standards process [1] places a number of requirements 44 on a standards track protocol specification. In particular, when 45 advancing a protocol from proposed standard to draft standard it 46 is necessary to demonstrate at least two independent and interoperable 47 implementations, from different code bases, of all options and features 48 of that protocol. Further, in cases where one or more options or 49 features have not been demonstrated in at least two interoperable 50 implementations, the specification may advance to the draft standard 51 level only if those options or features are removed. The Real-time 52 Transport Protocol, RTP, was originally specified in RFC1889 as a 53 proposed standard [2]. The revision of this specification for draft 54 standard status is now well underway, so it has become necessary 55 to conduct such an interoperability demonstration. 57 This memo describes the set of features and options of the RTP specification 58 which need to be tested as a basis for this demonstration. Due to the 59 nature of RTP there are necessarily two types of test described: those 60 which directly affect the interoperability of implementations at a ``bits 61 on the wire level'' and those which affect scalability and safety of the 62 protocol but do not directly affect interoperability. A related memo [4] 63 describes a testing framework which may aid with interoperability testing. 65 This memo is for information only and does not specify a standard 66 of any kind. 68 2 Features and options required to demonstrate interoperability 70 In order to demonstrate interoperability it is required to produce 71 a statement of interoperability for each feature noted below. Such 72 a statement should note the pair of implementations tested, including 73 version numbers, and a pass/fail statement for each feature. It 74 is not expected that every implementation will implement every feature, 75 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 2.Interoperable exchange of data packets which use padding. 85 3.Interoperable exchange of data packets which use a header extension. 86 There are three possibilities here: a) if both implementations 87 use a header extension in the same manner, it should be verified 88 that the receiver correctly receives the information contained 89 in the extension header; b) If the sender uses a header extension 90 and the receiver does not, it should be verified that the receiver 91 ignores the extension; c) If neither implementation implements 92 an extended header, this test is considered a failure. 94 4.Interoperable exchange of data packets using the marker bit as 95 specified in the profile. 97 5.Interoperable exchange of data packets using the payload type 98 field to differentiate multiple payload formats according to 99 a profile definition. 101 6.Interoperable exchange of data packets containing a CSRC list. 103 7.Interoperable exchange of RTCP packets, which must be compound 104 packets containing at least an initial SR or RR packet and an 105 SDES CNAME packet. Other RTCP packet types may be included, 106 but this is not required for this test. 108 8.Interoperable exchange of sender report packets when the receiver 109 of the sender reports is not also a sender (ie: sender reports 110 which only contain sender info, with no report blocks). 112 9.Interoperable exchange of sender report packets when the receiver 113 of the sender reports is also a sender (ie: sender reports which 114 contain one or more report blocks). 116 10.Interoperable exchange of receiver report packets. 118 11.Interoperable exchange of receiver report packets when not receiving 119 data (ie: the empty receiver report which has to be sent first 120 in each compound RTCP packet when no-participants are transmitting 121 data). 123 12.Interoperable and correct choice of CNAME, according to the rules 124 in the RTP specification and profile (applications using the 125 audio/video profile [3] under IPv4 should typically generate 126 a CNAME of the form `example@10.0.0.1', or `10.0.0.1' if they 127 are on a machine which no concept of usernames). 129 13.Interoperable exchange of source description packets containing 130 a CNAME item. 132 14.Interoperable exchange of source description packets containing 133 a NAME item. 135 15.Interoperable exchange of source description packets containing 136 an EMAIL item. 138 16.Interoperable exchange of source description packets containing 139 a PHONE item. 141 17.Interoperable exchange of source description packets containing 142 a LOC item. 144 18.Interoperable exchange of source description packets containing 145 a TOOL item. 147 19.Interoperable exchange of source description packets containing 148 a NOTE item. 150 20.Interoperable exchange of source description packets containing 151 a PRIV item. 153 21.Interoperable exchange of BYE packets containing a single SSRC. 155 22.Interoperable exchange of BYE packets containing multiple SSRCs. 157 23.Interoperable exchange of BYE packets containing the optional 158 reason for leaving text. 160 24.Interoperable exchange of BYE packets containing the optional 161 reason for leaving text and multiple SSRCs. 163 25.Interoperable exchange of application defined RTCP packets. As 164 with the RTP header extension this test takes two forms: if 165 both implementations implement the same application defined packet 166 it should be verified that those packets can be interoperably 167 exchanged. If only one implementation uses application defined 168 packets, it should be verified that the other implementation 169 can receive compound RTCP packets containing an APP packet whilst 170 ignoring the APP packet. If neither implementation implements 171 APP packets this test is considered a failure. 173 26.Interoperable exchange of encrypted RTP packets using DES encryption 174 in CBC mode. 176 27.Interoperable exchange of encrypted RTCP packets using DES encryption 177 in CBC mode. 179 3 Features and options relating to scalability 181 In addition to the basic interoperability tests, RTP includes a number 182 of features relating to scaling of the protocol to large groups. 183 Since these features are those which have undergone the greatest 184 change in the update of the RTP specification, it is considered important 185 to demonstrate their correct implementation. However, since these 186 changes do not affect the bits-on-the-wire behaviour of the protocol, 187 it is not possible to perform a traditional interoperability test. 188 As an alternative to such testing we require that multiple independent 189 implementations complete the following demonstrations. 191 1.Demonstrate correct implementation of basic RTCP transmission 192 rules: periodic transmission of RTCP packets at the minimum 193 (5 second) interval and randomisation of the transmission interval. 195 2.Demonstrate correct implementation of the RTCP step join backoff 196 algorithm as a receiver. 198 3.Demonstrate correct implementation of the RTCP step join backoff 199 algorithm as a sender. 201 4.Demonstrate correct steady state scaling of the RTCP interval 202 acording to the group size. 204 5.Demonstrate correct steady state scaling of the RTCP interval 205 acording to the group size with compensation for the number of 206 senders. 208 6.Demonstrate correct implementation of the RTCP reverse reconsideration 209 algorithm. 211 7.Demonstrate correct implementation of the RTCP BYE reconsideration 212 algorithm. 214 8.Demonstrate correct implementation of the RTCP member timeout 215 algorithm. 217 9.Demonstrate random choice of SSRC. 219 10.Demonstrate random selection of initial RTP sequence number. 221 11.Demonstrate random selection of initial RTP timestamp. 223 12.Demonstrate correct implementation of the SSRC collision/loop 224 detection algorithm. 226 13.Demonstrate correct generation of reception report statistics 227 in SR/RR packets. 229 14.Demonstrate correct generation of the sender info block in SR 230 packets. 232 4 Author's Address 234 Colin Perkins 235 Department of Computer Science 236 University College London 237 Gower Street 238 London WC1E 6BT 239 United Kingdom 241 Email: c.perkins@cs.ucl.ac.uk 243 5 Acknowledgments 245 Thanks to Steve Casner, Jonathan Rosenberg and Bill Fenner for their 246 helpful feedback. 248 6 References 250 [1] S. Bradner, ``The Internet Standards Process -- Revision 3'', 251 RFC2026, Internet Engineering Task Force, October 1996. 253 [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: 254 A Transport Protocol to Real-Time Applications'', RFC1889, Internet 255 Engineering Task Force, January 1996. 257 [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 258 Minimal Control'', draft-ietf-avt-profile-new-05.txt, February 1999. 260 [4] C. S. Perkins, J. Rosenberg and H. Schulzrinne, ``RTP Testing 261 Strategies'', draft-ietf-avt-rtptest-01.txt, August 1999.