idnits 2.17.1 draft-ietf-avt-rtp-interop-00.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 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 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 12 instances of too long lines in the document, the longest one being 3 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-05 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-avt-rtptest-00 ** Downref: Normative reference to an Informational draft: draft-ietf-avt-rtptest (ref. '4') -- No information found for draft-ietf-avt-rtcptest - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Colin Perkins 2 University College London 4 RTP Interoperability Statement 5 draft-ietf-avt-rtp-interop-00.txt 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other groups 14 may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months and 17 may be updated, replaced, or obsoleted by other documents at any time. It 18 is inappropriate to use Internet-Drafts as reference material or to cite 19 them other than as work in progress. 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Distribution of this document is unlimited. 29 Comments are solicited and should be addressed to the author and/or the 30 IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. 32 Abstract 34 It is required to demonstrate interoperability of RTP implementations 35 in order to move the RTP specification to draft standard. This memo 36 outlines those features to be tested, as the first stage of an 37 interoperability statement. 39 1 Introduction 41 The Internet standards process [1] places a number of requirements 42 on a standards track protocol specification. In particular, when 43 advancing a protocol from proposed standard to draft standard it 44 is necessary to demonstrate at least two indpendent and interoperable 45 implementations, from different code bases, of all options and features 46 of that protocol. Further, in cases where one or more options or 47 features have not been demonstrated in at least two interoperable 48 implementations, the specification may advance to the draft standard 49 level only if those options or features are removed. The Real-time 50 Transport Protocol, RTP, was originally specified in RFC1889 as a 51 proposed standard [2]. The revision of this specification for draft 52 standard status is well underway, so it has become necessary to conduct 53 such an interoperability demonstration. 55 This memo describes the set of features and options of the RTP 56 specification as a basis for this demonstration. Due to the nature of RTP 57 there are necessarily two types of test feature described: those which 58 directly affect the interoperability of implementations at a "bits on the 59 wire level", and those which affect scalability and safety of the protocol 60 but do not directly affect interoperability. Two related memos [4,5] 61 describe a testing framework which may aid with interoperability testing. 63 This memo is for information only and does not specify a standard 64 of any kind. 66 2 Features and options required to demonstrate interoperability 68 In order to demonstrate interoperability it is required to produce 69 a statement of interoperability for each feature noted below. Such 70 a statement of interoperabiity should note the pair of implementations 71 tested, and a pass/fail statement for each feature. It is not expected 72 that every implementation will implement every feature, but each feature 73 needs to be demonstrated by some pair of applications. 75 Note that some of these tests depend on the particular profile used, 76 or upon options in that profile. For example, it will be necessary 77 to test audio and video applications operating under [3] separately. 79 1.Interoperable exchange of data packets using the basic RTP header 80 with no extension, padding or CSRC list 82 2.Interoperable exchange of data packets which use padding 84 3.Interoperable exchange of data packets which use a header extension. 85 There are three possibilities here: a) if both implementations 86 use a header extension in the same manner, it should be verified 87 that the receiver correctly receives the information contained 88 in the extension header; b) If the sender uses a header extension 89 and the receiver does not, it should be verified that the receiver 90 ignores the extension; c) If neither implementation implements 91 an extended header, this test is considered a failure. 93 4.Interoperable exchange of data packets using the marker bit as 94 specified in the profile. 96 5.Interoperable exchange of data packets using the payload type 97 field to differentiate multiple payload formats according to 98 a profile definition. 100 6.Interoperable exchange of data packets containing a CSRC list 102 7.Interoperable exchange of sender report packets when the receiver 103 of the sender reports is not also a sender (ie: sender reports 104 which only contain sender info, with no report blocks). 106 8.Interoperable exchange of sender report packets when the receiver 107 of the sender reports is also a sender (ie: sender reports 108 which contain one or more report blocks). 110 9.Interoperable exchange of receiver report packets. 112 10.Interoperable exchange of receiver report packets when not receiving 113 data (ie: the empty receiver report which hs to be sent first 114 in each compound RTCP packet when no-participants are transmitting 115 data). 117 11.Interoperable exchange of source description packets containing 118 a CNAME item. 120 12.Interoperable exchange of source description packets containing 121 a NAME item. 123 13.Interoperable exchange of source description packets containing 124 a EMAIL item. 126 14.Interoperable exchange of source description packets containing 127 a PHONE item. 129 15.Interoperable exchange of source description packets containing 130 a LOC item. 132 16.Interoperable exchange of source description packets containing 133 a TOOL item. 135 17.Interoperable exchange of source description packets containing 136 a NOTE item. 138 18.Interoperable exchange of source description packets containing 139 a PRIV item. 141 19.Interoperable exchange of BYE packets. 143 20.Interoperable exchange of BYE packets containing multiple SSRCs. 145 21.Interoperable exchange of BYE packets containing the optional 146 reason for leaving text. 148 22.Interoperable exchange of application defined RTCP packets. As 149 with the RTP header extension this test takes two forms: if 150 both implementations implement the same application defined packet 151 it should be verified that those packets can be interoperably 152 exchanged. If only one implementation uses application defined 153 packets, it should be verified that the other implementation 154 can receive compound RTCP packets containing an APP packet whilst 155 ignoring the APP packet. If neither implementation implements 156 APP packets this test is considered a failure. 158 23.Interoperable exchange of encrypted RTP packets using DES encryption 159 in CBC mode. 161 24.Interoperable exchange of encrypted RTCP packets using DES encryption 162 in CBC mode. 164 3 Features and options relating to scalability 166 In addition to the basic interoperability tests, RTP includes a number 167 of features relating to scaling of the protocol to large groups. 168 Since these features are those which have undergone the greatest 169 change in the update of the RTP specification, it is considered important 170 to demonstrate their correct implementation. However, since these 171 changes do not affect the bits-on-the-wire behaviour of the protocol, 172 it is not possible to perform a traditional interoperability test. 173 As an alternative we require that multiple independent implementations 174 complete the following demonstrations. 176 1.Demonstrate correct implementation of basic RTCP transmission 177 rules: periodic transmission of RTCP packets at the minimum 178 (5 second) interval and randomisation of the transmission interval. 180 2.Demonstrate correct implementation of the RTCP step join backoff 181 algorithm as a receiver. 183 3.Demonstrate correct implementation of the RTCP step join backoff 184 algorithm as a sender. 186 4.Demonstrate correct steady state scaling of the RTCP interval 187 acording to the group size. 189 5.Demonstrate correct steady state scaling of the RTCP interval 190 acording to the group size with compensation for the number of 191 senders. 193 6.Demonstrate correct implementation of the RTCP reverse reconsideration 194 algorithm. 196 7.Demonstrate correct implementation of the RTCP BYE reconsideration 197 algorithm. 199 8.Demonstrate correct implementation of the RTCP member timeout 200 algorithm. 202 9.Demonstrate random choice of SSRC. 204 10.Demonstrate correct implementation of the SSRC collision detection 205 algorithm. 207 4 Author's Address 209 Colin Perkins 210 Department of Computer Science 211 University College London 212 Gower Street 213 London WC1E 6BT 214 United Kingdom 216 Email: c.perkins@cs.ucl.ac.uk 218 5 References 220 [1] S. Bradner, ``The Internet Standards Process -- Revision 3'', 221 RFC2026, Internet Engineering Task Force, October 1996. 223 [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: 224 A Transport Protocol to Real-Time Applications'', RFC1889, Internet 225 Engineering Task Force, January 1996. 227 [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences 228 with Minimal Control'', draft-ietf-avt-profile-new-05.txt, February 229 1999. 231 [4] C. Perkins, ``RTP Testing Strategies'', draft-ietf-avt-rtptest-00.txt, 232 June 1999. 234 [5] J. Rosenberg, ``Conformance tests for RTP Scalability Algorithms'', 235 draft-ietf-avt-rtcptest-01.txt, June 1999.