idnits 2.17.00 (12 Aug 2021) /tmp/idnits50740/draft-rosen-megaco-test-profile-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: ---------------------------------------------------------------------------- ** 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. (A line matching the expected section header was found, but with an unexpected indentation: ' 2.7 Security' ) ** 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 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 135: '... Gateways SHALL implement TCP transp...' RFC 2119 keyword, line 143: '...forming Gateways SHALL support text en...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 82 has weird spacing: '...nerator tone...' == Line 83 has weird spacing: '...enerate dg ...' -- 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 12 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Megaco B. Rosen 2 Internet Draft Marconi 3 Document: draft-rosen-megaco-test-profile-00.txt 4 Category: Informational 6 Interoperability Test Profile 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 1. Abstract 28 This document describes a profile for use in interoperability 29 testing of the Megaco/H.248 protocol and a set of scenarios to try 30 increasingly difficult mechanisms in the protocol. To support early 31 phase testing, it is useful to define a simple, easy to implement 32 set of characteristics that allow initial implementations to get 33 very basic functions working. By implementing this profile, testing 34 a variety of MGs against a variety of MGCs is possible. The test 35 scenarios describe high-level behavior expected by the MGs and MGCs, 36 but not explicit message sequences. 38 Also included is a set of test messages that may be used to verify 39 early stage MG/MGC functionality. They could be used to test 40 parsers, and they can be used to assure that implementations have 41 base functionality prior to testing with devices that may not 42 produce the same messages. 44 2. Profile 46 megaco Informational - Expires January, 2001 1 47 The test profile is described as one profile, but is actually a set 48 of increasing functionality profiles. The levels are assigned a 49 numeric identifier, from Level 1 to Level 4. The scenarios specify 50 which level of the profile is required. It is possible to define 4 51 separate profiles, but many devices will implement several of the 52 levels, and it was not considered appropriate to have to reconfigure 53 the device for a specific level for each scenario. 54 Level 1 corresponds to the simplest possible gateway that can detect 55 off hook, and create a media stream, but little else 56 Level 2 corresponds to a low functionality gateway that can detect 57 DTMF and generate simple call progress tones so that basic 58 call is possible 59 Level 3 corresponds to a full functionality residential gateway with 60 local signalling/DTMF detection 61 Level 4 corresponds to a fully functional trunk gateway that is 62 similar to level 3 but supports DS0s 64 2.1 Identification 65 This profile shall be entitled "Interoperability Test Profile". 66 The version number shall be 1.0. This name shall be returned from a 67 conforming gateway when sending the ServiceChange message as part of 68 initial registration of the MG in the Profile section of the 69 ServiceChange Descriptor. 71 2.2 Packages Implemented 72 A conforming gateway shall implement at least the following 73 packages: 74 Package Name ID Ver Level Defined In 75 Network nt 1 1 Annex E 76 Analog Line Supv al 1 1 Annex E* 77 RTP rtp 1 1 Annex E* 78 Generic g 1 2 Annex E 79 Base Root root 1 2 Annex E 80 Tone Detect tonedet 1 2 Annex E 81 DTMF Detect dt 1 2 Annex E 82 Tone Generator tonegen 1 3 Annex E 83 DTMF Generate dg 1 3 Annex E 84 Continuity ct 1 4 Annex E 85 DS0 ds0 1 4 Annex E* 87 *Note: In general, increasing levels incorporate all lower level 88 requirements. Level 4 gateways however do not necessarily implement 89 analog line (they may only implement DS0). 91 Gateways not supporting RTP (for example, an MG supporting ATM AAL1) 92 need not support the RTP package, but instead would support the 93 appropriate media transport package. 95 2.3 Naming Conventions 97 2.3.1 Gateway Naming Conventions 98 The MG name, used in Registration and in the header of commands, 99 shall be the string "GATEWAY" followed by one decimal digit. The 101 megaco Informational - Expires January, 2001 2 102 digit shall be provisionable. In single MG test environments, the 103 digit will normally be zero. In multiple gateway scenarios, the 104 gateways are numbered from 0 to 9. 106 2.3.2 Controller Naming Conventions 107 The MGC name, used in Registration and in the header of commands, 108 shall be the string "CONTROLLER" followed by one decimal digit. The 109 digit shall be provisionable. In single MGC test environments, the 110 digit will normally be zero. In multiple MGC scenarios, the 111 gateways are numbered from 0 - 9. 113 2.3.3 Termination Names 115 2.3.3.1 Physical Terminations 116 There shall be two terminations _ "termA" and _termB" 118 2.3.3.2 Ephemeral Terminations 119 RTP flows shall be named "rtpA", "rtpB", _ 121 2.4 Topology Descriptor 122 A gateway conforming to this profile is not required to implement 123 Topology and MGCs expecting to control gateways meeting this 124 specification shall not assume Topology is implemented, for Levels 125 1-4. 127 NOTE: As this document evolves, Topology will be introduced. 129 2.5 Service Change Descriptor 130 For Level 1, only a Primary MGC should be provisioned (normally, 131 "GATEWAY0"). For Level 2-4, the Gateway shall allow one primary and 132 at least two secondary MGCs to be provisioned for registration. 134 2.6 Transport 135 Gateways SHALL implement TCP transport of Megaco for Levels 1-4. 136 Future scenarios will test other transports. 138 2.7 Security 139 No security mechanisms are required, but full IPSEC AH is encouraged 140 for Level 3 and 4 scenarios. 142 2.8 Encoding 143 Conforming Gateways SHALL support text encoding. 145 2.9 Media 146 IP connected gateways shall implement RTP flows with G.711 encoding. 147 ATM connected gateways shall _. 149 3. Scenarios 151 3.1 Hotel Phone 152 Requires Level 1 154 megaco Informational - Expires January, 2001 3 155 Registration should have no options, and should always succeed. No 156 Audit should be performed. When off hook is detected on termA, send 157 ring to termB. When off hook is detected on termB, stop ring, and 158 create media flow between termA and termB. When on hook is detected 159 on termA, tear down the media flow. 161 3.2 Basic Call 162 Requires Level 2 164 Registration should have no options, and should always succeed. No 165 Audit should be performed. When off hook is detected on termA, 166 establish a North American Dialing Plan digitmap. If 555-1212 is 167 called, send ring to termB. Proceed as above. 169 3.3 Normal Operation of Simple Gateway 170 Requires Level 3. 172 Use your normal registration procedures. Registration should always 173 succeed. Audit as normal. When offhook is detected on termA, 174 return dialtone to termA and establish a North American Dialing 175 Plan. If any number except 555-1212 is dialed, return error tone. 176 If 555-1212 is dialed, send ring to termB and ringback to termA. 177 When termB goes off-hook, stop ring and ringback and establish media 178 flow. When either termA or termB goes on hook, tear down media 179 flow. 181 3.4 Two Gateway Basic Call 182 Requires Level 3 184 Use your normal registration procedures for two MGs. Audit as 185 normal. Follow the same procedure as in Scenario 3.4, but construct 186 the call from MG0 termA to MG1 termB. 188 3.5 Trunk Gateway Hotel Call 189 Requires Level 4 191 Use your normal registration procedures. Registration should always 192 succeed. Audit as normal. When offhook is detected on termA 193 continuity between termA and termB. Upon completion, establish 194 ringing on termB. When termB goes off hook, establish media flow 195 between termA and termB. 197 3.6 Two Trunk Gateway Basic Call 198 Requires Level 4 200 As with Scenario 3.5, but between MG0 termA and MG1 termB. 202 3.7 Secondary Registration 203 Requires Level 1 205 megaco Informational - Expires January, 2001 4 206 Provision MG for MGC0 as primary and MGC1 as secondary. Attempt to 207 register to MGC0. MGC0 should refuse and not offer a 208 ServiceChangeMgcId. MGC1 should accept registration. 209 Repeat with provisioning MG for MGC0 as primary and no secondary. 210 Attempt to register to MGC0. MGC0 should refuse and offer MGC1 as 211 ServiceChangeMgcId. Registration to MGC1 should succeed. 213 4. Test Messages 215 218 4. References 220 1. Cuervo, et. al., _Megaco Protocol_, draft-ietf-megaco-merged- 221 01.txt, June, 2000. 223 5. Author's Addresses 225 Brian Rosen 226 Marconi 227 1000 FORE Drive 228 Phone: +1 724 742 6826 229 Email: brian.rosen@marconi.com 231 6. Full Copyright Statement 233 Copyright (C) The Internet Society July 14, 2000. All Rights 234 Reserved. This document and translations of it may be copied and 235 furnished to others, and derivative works that comment on or 236 otherwise explain it or assist in its implementation may be 237 prepared, copied, published and distributed, in whole or in part, 238 without restriction of any kind, provided that the above copyright 239 notice and this paragraph are included on all such copies and 240 derivative works. However, this document itself may not be modified 241 in any way, such as by removing the copyright notice or references 242 to the Internet Society or other Internet organizations, except as 243 needed for the purpose of developing Internet standards in which 244 case the procedures for copyrights defined in the Internet Standards 245 process must be followed, or as required to translate it into it 246 into languages other than English. 248 The limited permissions granted above are perpetual and will not be 249 revoked by the Internet Society or its successors or assigns. 251 megaco Informational - Expires January, 2001 5 252 This document and the information contained herein is provided on an 253 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 254 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 255 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 256 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 257 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 megaco Informational - Expires January, 2001 6