idnits 2.17.00 (12 Aug 2021) /tmp/idnits55148/draft-rosen-megaco-interop-1-report-00.txt: ** The Abstract section seems to be numbered 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '... 4. Is it REQUIRED that the MGC send...' 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: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 39 looks like a reference -- Missing reference section? '2' on line 39 looks like a reference -- Missing reference section? '3' on line 58 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Megaco B. Rosen 3 Internet Draft Marconi 4 draft-rosen-megaco-interop-1-report-00.txt October, 2000 5 Category: Informational 7 Report of the First Megaco/H.248 Interop Event 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 [1]. 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- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 22 The list of current Internet-Drafts can be accessed at 23 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 1. Abstract 29 An interoperability test of the Megaco (RFC2885/6) protocol was held 30 on August 28-31 in Durham, NH. An excellent turnout of many 31 different independently developed implementations were present, and 32 a great many of the tests were quite successful, including media 33 flow in many cases, and several cases of testing a Media Gateway 34 controller from one organization with two Media Gateways from 35 different organizations. 37 The primary purpose of the event was to assess the ability of 38 independent development teams to create interoperable devices from 39 the recent Proposed Standard RFCs 2885 [1] and 2886 [2]. While 40 several discrepancies were found that resulted from differing 41 interpretations of the documents, the level of compatibility 42 exhibited at this first test was excellent. A secondary purpose of 43 the event was to begin the process of moving the RFCs to draft 44 standard status, which requires documentation of at least two 45 implementations of each protocol element/feature. While this first 46 event only used a subset of the protocol, quite a few of the 47 elements and features were demonstrated by all implementations. 49 This I-D describes the event and summarized the results. 51 2. Description of the Event 53 18 institutions participated in the event, with 49 registered 54 attendees, and several staff. There were a total of 6 independently 55 developed MGCs, and 11 MGs, plus three network analyzers. Elements 56 to be tested were connected to a LAN. MGs and MGCs were paired for 57 tests, which was conducted as described in the test profile provided 58 to all participants [3]. The profile provided a number of test 59 scenarios that involved placing calls between two nodes of a single 60 gateway as well as between nodes on separate gateways. There were 61 NOT specific Megaco message sequences provided. Success of a test 62 was defined as correct completion of the message sequences as 63 determined by both ends. All tests included tests of media flow. 64 Most implementations used RTP on the Ethernet LAN, but one of the MG 65 implementations had an ATM network for media. 67 Participants included: 69 T!Semantics,Inc 70 Marconi Communications 71 RadiSys Corporation 72 Hughes Software Systems 74 Broadcom 75 Alcatel 76 CCL/ITRI 77 Ericsson Computer Science Laboratory 78 GN Nettest 79 Excitele 80 ipDialog, Inc. 81 RADCOM Equipment, Inc. 83 Agilent Technologies 84 ipGen Inc. 85 Nortel Networks 86 Pernix 87 Radvision 89 3. Test Results 91 Four of the MGs had significant problems that prevented most 92 testing. One was only able to encode Megaco with binary, and only 93 one of the MGCs was able to talk to it. Two implementations had 94 great difficulty getting their transports to work, and no 95 significant testing was completed. One institution had both an MG 96 and MGC, but only two staff, and decided to concentrate on their MGC 97 after a single successful test of their MG. 99 Of the remaining 6 x 8 matrix, 5 cases were those of an MG and MGC 100 from the same institution, and were not tested. We conducted 32 101 pair trials, according to the test. Each test was scored by what 102 level they successfully completed (minor errors were not counted). 103 There were 5 tests that were scored as Failures. Primarily, these 104 occurred because of incomplete implementations, or bugs that were 105 not fixable at the event. For example some implementations assumed 106 inappropriate case sensitivity and were not able to be reprogrammed 107 to work around the problem. 5 of the tests were scored Level 1. 108 Of these, 3 of them were by the same MG, which was not able to 109 support any higher level testing. All of the rest achieved L3 or L4 110 testing (which was essential equivalent, L3 using an analog line, 111 and L4 using a digital line). There were a few successful trials of 112 MGC failover, and several successful trials of 2 MGs, including 113 cases of all three elements from different institutions! 115 There were also three protocol analyzers which _sniffed_ data from 116 tests and attempted to decode and _pretty print_ the message 117 traffic. 119 3. Documentation discrepancies noted 121 1. There was confusion over what to implement of TPKT. Consensus is 122 that the 4 byte header (3 0 <16 bit message length>) was all 123 that was required. 124 2. It was not clear what the MGC sends in a ServiceChange reply? 126 The text currently states: 127 Upon a cold start of the MG, it will issue a 128 ServiceChange command with a "Restart" method, on the Root 130 Termination to its primary MGC. If the MGC accepts the MG, 131 it will send a Transaction Accept, with the ServiceChangeMgcId 132 set to itself. 134 Note that this implies ServiceChangeMgcId is not optional. 136 There is, as of this writing, continuing discussion of this issue 137 on the list, but at the least ServiceChangeMgcId will be 138 optional, and the text will need to be changed. 140 3. There was confusion on case sensitivity. Consensus is that the 141 Megaco language, including tokens, event names, signal names, 142 parameter names, enumeration values, etc. are NOT case sensitive. 143 Attention was noted that values in quotations may be case 144 sensitive, and that SDP is case sensitive in most circumstances. 146 4. Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL 147 termination in order to get media to flow? 149 There are two questions actually: 150 1) Is there a default state of MODE (text is silent) 151 2) Should the MG demand a media descriptor before allowing media 153 flow? 155 Consensus is that: 156 1) The default for MODE is Inactive 157 2) MGCs should always send a media descriptor, with at least a 158 MODE setting 159 3) MGs should not depend on 2) 161 5. There is an error in the text in section 10.2 Interim AH scheme 162 in the sentence: 163 ...........To retain the same functionality, the ICV 165 calculation should be performed across the entire transaction 166 prepended by a synthesized IP header consisting of a 32 bit 167 source IP address, a 32 bit destination address and a 16 bit 168 UDP destination port encoded as 10 hex digits. 170 The error is "10 hex digits". It should be 20 hex digits, 171 representing 10 bytes (4 source, 4 dest, 2 port). 173 6. An MG should always accept a command which has no descriptors, 174 assuming that the contextId and the terminationIds are legal. 175 It's a NOP, but it's legal. Someone tried to send Context= - 176 {Subtract=*{}}. That's not legal (can't subtract from null 177 context}. 179 7. In the protocol, Appendix A, in the first example, step 3 181 Local { 182 v=0 183 c=IN IP4 $ 184 m=audio $ RTP/AVP 0 185 a=fmtp:PCMU VAD=X-NNVAD ; special voice activity 186 ; detection algorithm 188 1) There is no IP address. Choose is really wrong, especially 189 because the response doesn't return an address 190 2) the m line is incorrect, it's not RTP 192 3) the a line has some sense, but it really would make more 193 sense to have this be a parameter defined in the al package. 195 Clearly, if you send SDP, you need a c and an m line, but using 196 IP is just wrong. 198 We can either make them parameters, and then SDP wouldn't be 199 used in most cases, or we can extend SDP to have a more sane c 200 and m line. 202 At the very least, the c line should specify a legal IP 203 address, and not choose. 205 8. If you repeat a modify, what happens? 207 Other than subtract or add, it's a NOP. 208 Add/Subtract is an error. 210 The specific command set MODE to the same value it was. 211 Might unnecessarily consume cycles, but should be legal. 213 9. Suppose all you want to specify in a ServiceChangeAddress is a 214 port number, that is, the IP address doesn't change, but the port 215 does. 217 The ABNF states: 218 serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE 220 This is because it could be IP, ATM, FR, MPLS.... 222 The example shows just a port number. 224 Should that be legal? Should you have to specify the IP address 225 as x.x.x.x:p? 227 10. While it was legal, it was a surprise to some that 229 Media=termId{Local.... 231 Is legal and you don't have to say 232 Media=termId{Stream=1{Local... 234 ABNF clearly allows this. There was an MGC implementation that 235 did this, and an MG that got confused. 237 4. Protocol elements tested 239 No detailed examination of the message sequences was made, however, 240 the following Megaco elements were tested: 241 Commands 242 ServiceChange 243 Add 244 Subtract 245 Modify 246 AuditValue 247 AuditCapability 248 Notify 249 Descriptors 250 Media 251 Local 252 Remote 253 TerminationState 254 LocalControl 255 ServiceChange 256 Audit 257 DigitMap 258 Events 259 Signals 260 Transport 261 UDP 262 TCP (with TPKT) 263 Features 264 Registration 265 Failover 266 Ephemeral termination creation and destruction 267 Context creation and destruction 268 Unnamed digitmaps 269 Parameters to Events 270 Parameters to Signals 271 _ 273 5. References 275 1 Rosen, et al. _Megaco Protocol version 0.8_, RFC 2885, August, 276 2000 278 3 Rosen, B., _Interoperability Test Profile_, draft-rosen-test- 279 profile-00.txt, August 2000 281 6. Acknowledgments 283 Marconi was the host of this event. Jennifer Mendola of Marconi 284 provided the bulk of the logistical support. The event was co- 285 sponsored by the Multiservice Switching Forum and the International 286 Softswitch Consortium. Alysia Johnson and Carol Waller of the MSF 287 as well as Paul Ritchie and Micaela Giehat of ISC were very helpful 288 to us. 290 The event was held at the University of New Hampshire's 291 Interoperability Lab. Dr. William Lenharth is the director of the 292 lab, and was instrumental in arranging the facility made available 293 for this event. Ben Schultz and Ray LaRocca of the IOL staff 294 provided leadership in setting up the test area, and the network 295 used by the participants. 297 11. Author's Addresses 298 Brian Rosen 299 Marconi 300 1000 FORE Drive 301 Warrendale, PA 15086 302 USA 304 Phone: +1 (724) 742-6826 305 Email: brian.rosen@marconi.com 306 Full Copyright Statement 308 "Copyright (C) The Internet Society (date). All Rights Reserved. 309 This document and translations of it may be copied and furnished to 310 others, and derivative works that comment on or otherwise explain it 311 or assist in its implmentation may be prepared, copied, published 312 and distributed, in whole or in part, without restriction of any 313 kind, provided that the above copyright notice and this paragraph 314 are included on all such copies and derivative works. However, this 315 document itself may not be modified in any way, such as by removing 316 the copyright notice or references to the Internet Society or other 317 Internet organizations, except as needed for the purpose of 318 developing Internet standards in which case the procedures for 319 copyrights defined in the Internet Standards process must be 320 followed, or as required to translate it into