Megaco B. Rosen Internet Draft Marconi draft-rosen-megaco-interop-1-report-00.txt October, 2000 Category: Informational Report of the First Megaco/H.248 Interop Event Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract An interoperability test of the Megaco (RFC2885/6) protocol was held on August 28-31 in Durham, NH. An excellent turnout of many different independently developed implementations were present, and a great many of the tests were quite successful, including media flow in many cases, and several cases of testing a Media Gateway controller from one organization with two Media Gateways from different organizations. The primary purpose of the event was to assess the ability of independent development teams to create interoperable devices from the recent Proposed Standard RFCs 2885 [1] and 2886 [2]. While several discrepancies were found that resulted from differing interpretations of the documents, the level of compatibility exhibited at this first test was excellent. A secondary purpose of the event was to begin the process of moving the RFCs to draft standard status, which requires documentation of at least two implementations of each protocol element/feature. While this first event only used a subset of the protocol, quite a few of the elements and features were demonstrated by all implementations. This I-D describes the event and summarized the results. Report of the First Megaco/H.248 Interop Event Oct. 2000 2. Description of the Event 18 institutions participated in the event, with 49 registered attendees, and several staff. There were a total of 6 independently developed MGCs, and 11 MGs, plus three network analyzers. Elements to be tested were connected to a LAN. MGs and MGCs were paired for tests, which was conducted as described in the test profile provided to all participants [3]. The profile provided a number of test scenarios that involved placing calls between two nodes of a single gateway as well as between nodes on separate gateways. There were NOT specific Megaco message sequences provided. Success of a test was defined as correct completion of the message sequences as determined by both ends. All tests included tests of media flow. Most implementations used RTP on the Ethernet LAN, but one of the MG implementations had an ATM network for media. Participants included: T!Semantics,Inc Marconi Communications RadiSys Corporation Hughes Software Systems Broadcom Alcatel CCL/ITRI Ericsson Computer Science Laboratory GN Nettest Excitele ipDialog, Inc. RADCOM Equipment, Inc. Agilent Technologies ipGen Inc. Nortel Networks Pernix Radvision 3. Test Results Four of the MGs had significant problems that prevented most testing. One was only able to encode Megaco with binary, and only one of the MGCs was able to talk to it. Two implementations had great difficulty getting their transports to work, and no significant testing was completed. One institution had both an MG and MGC, but only two staff, and decided to concentrate on their MGC after a single successful test of their MG. Report of the First Megaco/H.248 Interop Event Oct. 2000 Of the remaining 6 x 8 matrix, 5 cases were those of an MG and MGC from the same institution, and were not tested. We conducted 32 pair trials, according to the test. Each test was scored by what level they successfully completed (minor errors were not counted). There were 5 tests that were scored as Failures. Primarily, these occurred because of incomplete implementations, or bugs that were not fixable at the event. For example some implementations assumed inappropriate case sensitivity and were not able to be reprogrammed to work around the problem. 5 of the tests were scored Level 1. Of these, 3 of them were by the same MG, which was not able to support any higher level testing. All of the rest achieved L3 or L4 testing (which was essential equivalent, L3 using an analog line, and L4 using a digital line). There were a few successful trials of MGC failover, and several successful trials of 2 MGs, including cases of all three elements from different institutions! There were also three protocol analyzers which _sniffed_ data from tests and attempted to decode and _pretty print_ the message traffic. 3. Documentation discrepancies noted 1. There was confusion over what to implement of TPKT. Consensus is that the 4 byte header (3 0 <16 bit message length>) was all that was required. 2. It was not clear what the MGC sends in a ServiceChange reply? The text currently states: Upon a cold start of the MG, it will issue a ServiceChange command with a "Restart" method, on the Root Termination to its primary MGC. If the MGC accepts the MG, it will send a Transaction Accept, with the ServiceChangeMgcId set to itself. Note that this implies ServiceChangeMgcId is not optional. There is, as of this writing, continuing discussion of this issue on the list, but at the least ServiceChangeMgcId will be optional, and the text will need to be changed. 3. There was confusion on case sensitivity. Consensus is that the Megaco language, including tokens, event names, signal names, parameter names, enumeration values, etc. are NOT case sensitive. Attention was noted that values in quotations may be case sensitive, and that SDP is case sensitive in most circumstances. Report of the First Megaco/H.248 Interop Event Oct. 2000 4. Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL termination in order to get media to flow? There are two questions actually: 1) Is there a default state of MODE (text is silent) 2) Should the MG demand a media descriptor before allowing media flow? Consensus is that: 1) The default for MODE is Inactive 2) MGCs should always send a media descriptor, with at least a MODE setting 3) MGs should not depend on 2) 5. There is an error in the text in section 10.2 Interim AH scheme in the sentence: ...........To retain the same functionality, the ICV calculation should be performed across the entire transaction prepended by a synthesized IP header consisting of a 32 bit source IP address, a 32 bit destination address and a 16 bit UDP destination port encoded as 10 hex digits. The error is "10 hex digits". It should be 20 hex digits, representing 10 bytes (4 source, 4 dest, 2 port). 6. An MG should always accept a command which has no descriptors, assuming that the contextId and the terminationIds are legal. It's a NOP, but it's legal. Someone tried to send Context= - {Subtract=*{}}. That's not legal (can't subtract from null context}. 7. In the protocol, Appendix A, in the first example, step 3 Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=fmtp:PCMU VAD=X-NNVAD ; special voice activity ; detection algorithm 1) There is no IP address. Choose is really wrong, especially because the response doesn't return an address 2) the m line is incorrect, it's not RTP 3) the a line has some sense, but it really would make more sense to have this be a parameter defined in the al package. Clearly, if you send SDP, you need a c and an m line, but using IP is just wrong. Report of the First Megaco/H.248 Interop Event Oct. 2000 We can either make them parameters, and then SDP wouldn't be used in most cases, or we can extend SDP to have a more sane c and m line. At the very least, the c line should specify a legal IP address, and not choose. 8. If you repeat a modify, what happens? Other than subtract or add, it's a NOP. Add/Subtract is an error. The specific command set MODE to the same value it was. Might unnecessarily consume cycles, but should be legal. 9. Suppose all you want to specify in a ServiceChangeAddress is a port number, that is, the IP address doesn't change, but the port does. The ABNF states: serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE This is because it could be IP, ATM, FR, MPLS.... The example shows just a port number. Should that be legal? Should you have to specify the IP address as x.x.x.x:p? 10. While it was legal, it was a surprise to some that Media=termId{Local.... Is legal and you don't have to say Media=termId{Stream=1{Local... ABNF clearly allows this. There was an MGC implementation that did this, and an MG that got confused. 4. Protocol elements tested No detailed examination of the message sequences was made, however, the following Megaco elements were tested: Commands ServiceChange Add Subtract Modify AuditValue AuditCapability Notify Descriptors Media Report of the First Megaco/H.248 Interop Event Oct. 2000 Local Remote TerminationState LocalControl ServiceChange Audit DigitMap Events Signals Transport UDP TCP (with TPKT) Features Registration Failover Ephemeral termination creation and destruction Context creation and destruction Unnamed digitmaps Parameters to Events Parameters to Signals _ 5. References 1 Rosen, et al. _Megaco Protocol version 0.8_, RFC 2885, August, 2000 3 Rosen, B., _Interoperability Test Profile_, draft-rosen-test- profile-00.txt, August 2000 6. Acknowledgments Marconi was the host of this event. Jennifer Mendola of Marconi provided the bulk of the logistical support. The event was co- sponsored by the Multiservice Switching Forum and the International Softswitch Consortium. Alysia Johnson and Carol Waller of the MSF as well as Paul Ritchie and Micaela Giehat of ISC were very helpful to us. The event was held at the University of New Hampshire's Interoperability Lab. Dr. William Lenharth is the director of the lab, and was instrumental in arranging the facility made available for this event. Ben Schultz and Ray LaRocca of the IOL staff provided leadership in setting up the test area, and the network used by the participants. 11. Author's Addresses Report of the First Megaco/H.248 Interop Event Oct. 2000 Brian Rosen Marconi 1000 FORE Drive Warrendale, PA 15086 USA Phone: +1 (724) 742-6826 Email: brian.rosen@marconi.com Report of the First Megaco/H.248 Interop Event Oct. 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into