idnits 2.17.1 draft-ietf-megaco-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 85 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 86 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 171 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 720: '... that name. MGs MAY refuse a request ...' RFC 2119 keyword, line 1403: '...detected. The MG MUST NOT send an unso...' RFC 2119 keyword, line 1686: '...RESERVED" fields MUST be set to "zero"...' RFC 2119 keyword, line 1721: '...O protocol using IPv4 MUST support the...' RFC 2119 keyword, line 1722: '... Implementations SHOULD implement IPSE...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1414 has weird spacing: '...way, is about...' == Line 1533 has weird spacing: '...e where diffe...' == Line 2082 has weird spacing: '...dl dial-tone...' == Line 2524 has weird spacing: '...to/from a par...' == Line 2876 has weird spacing: '...ponding notif...' -- 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'SignalDescriptor' on line 404 looks like a reference -- Missing reference section? 'DigitMapDescriptor' on line 1279 looks like a reference -- Missing reference section? 'RemoteTerminationDescriptor' on line 1272 looks like a reference -- Missing reference section? 'Capabilities' on line 1304 looks like a reference -- Missing reference section? 'Statistics' on line 1305 looks like a reference -- Missing reference section? 'MGCIdentity' on line 1417 looks like a reference -- Missing reference section? 'ServiceChangeDelay' on line 1421 looks like a reference -- Missing reference section? 'RFC2401' on line 1666 looks like a reference -- Missing reference section? 'RFC2402' on line 1729 looks like a reference -- Missing reference section? 'RFC2406' on line 1735 looks like a reference -- Missing reference section? 'RFC2409' on line 1731 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Fernando Cuervo 3 INTERNET DRAFT Nortel Networks 4 April 16, 1999 Christian Huitema 5 Expires October 16, 1999 Telcordia Technologies 6 Keith Kelly 7 NetSpeak 8 Brian Rosen 9 FORE Systems 10 Paul Sijben 11 Lucent Technologies 12 Eric Zimmerer 13 Level 3 Communications 15 MEGACO Protocol 17 Status of this document 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference material 29 or to cite them other than as "work in progress." 31 To view the entire list of current Internet-Drafts, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 34 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 35 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 37 IMPORTANT NOTE 39 This version of the draft has been rushed so that members of the WG not 40 part of the small design team that created this document could have 41 early input to the design process. The last few sections of the document 42 have not been reviewed by the team, and are largely lifted from other 43 documents, especially the MGCP document. The design team did not reach 45 Internet draft MEGACO Protocol April 16, 1999 47 consensus on several major issues, including how the protocol messages 48 will be encoded. This has complicated text in several areas. The latter 49 sections (the un-reviewed ones) make assumptions on encoding which have 50 not been agreed to. The team feels that presenting the information con- 51 tained in these sections will assist readers to understand the proposal 52 in greater depth, and thus chose to leave the text as is. 54 Abstract 56 This document is an early draft of a proposed protocol that can be used 57 to control a Media Gateway (MG) from an external controller called a 58 Media Gateway Controller (MGC). 60 The document is organized into the following major sections: 62 * The Introduction section presents a high-level overview of the pro- 63 tocol. It discusses the connection model used and provides an 64 example call flow to help illustrate the protocol's functionality. 66 * The Commands section presents a description of each of the opera- 67 tions supported along with their parameters. 69 * The Security section presents the security requirements of the pro- 70 tocol and describes its usage of IP security services (IPSEC). 72 * The Syntax section presents the syntactical elements of the proto- 73 col independent of its encoding. 75 * The Transport section presents how the protocol is carried on a 76 packet network and describes the reliability and fail-over mechan- 77 isms that it supports. 79 * The Event Packages and Termination Classes section describes the 80 elements of commonly implemented devices and services. 82 Internet draft MEGACO Protocol April 16, 1999 84 Table of Contents Page 86 1. Introduction .............................................. 5 87 1.1. High Level Description of the Protocol ............... 5 88 1.1.1. Connection Model ................................ 5 89 1.1.2. Terminations .................................... 8 90 1.1.3. Termination Capabilities ........................ 8 91 1.1.4. Instantiation of a Termination An MG realizes ... 9 92 1.1.5. Termination Dynamics ............................ 9 93 1.1.6. Issuing Commands in Transactions ................ 11 94 1.1.7. Sample Command Flow ............................. 12 95 2. Commands .................................................. 15 96 2.1. Names and Common Parameters .......................... 16 97 2.1.1. Context Identifiers ............................. 16 98 2.1.2. Termination Names ............................... 16 99 2.1.3. Specifying Properties ........................... 17 100 2.1.4. Termination State Properties .................... 18 101 2.1.5. Termination Descriptors ......................... 19 102 2.1.6. Events, Signals and Packages .................... 19 103 2.1.7. SignalDescriptors ............................... 20 104 2.1.8. EventDescriptors ................................ 21 105 2.1.9. Digit Maps ...................................... 21 106 2.1.10. Statistics ..................................... 23 107 2.2. Termination Management Commands ...................... 24 108 2.2.1. Add ............................................. 24 109 2.2.2. Modify .......................................... 25 110 2.2.3. Subtract ........................................ 27 111 2.2.4. Move ............................................ 28 112 2.2.5. Audit ........................................... 28 113 2.3. MG-Issued Commands ................................... 30 114 2.3.1. Notify .......................................... 30 115 2.3.2. ServiceChange ................................... 31 116 2.4. The following table lists the defined commands, and .. 33 117 3. MG-MGC Control Associations ............................... 33 118 3.1. Multiple MGCs per MG ................................. 33 119 3.2. Cold Start ........................................... 34 120 3.3. Upon failure to obtain a reply, either from the ...... 35 121 3.4. Failover ............................................. 35 122 3.4.1. Failure of an MG ................................ 35 123 3.4.2. Failure of an MGC ............................... 35 124 3.5. Error Codes .......................................... 36 125 4. Security Considerations ................................... 36 126 4.1. Protection of Media Connections ...................... 38 127 5. Syntax .................................................... 40 128 5.1. Termination Names .................................... 44 129 5.2. Events, Signals and Packages ......................... 45 130 5.3. Digit Maps ........................................... 47 131 5.4. Statistics ........................................... 48 133 Internet draft MEGACO Protocol April 16, 1999 135 5.5. Examples ............................................. 51 136 5.5.1. Example Add transaction: ........................ 52 137 5.5.2. Example response to Add transaction: ............ 52 138 5.5.3. Example Modify transaction: ..................... 52 139 5.5.4. Example Subtract transaction: ................... 52 140 5.6. Transaction Response Codes ........................... 53 141 5.6.1. Transaction Response Success Codes .............. 53 142 5.6.2. Transaction Response Reject Codes ............... 53 143 6. Transport ................................................. 54 144 6.1. Transport capabilities, and relationship to Transport 54 145 7. Event Packages and Termination Classes .................... 55 146 7.1. Basic Event Packages ................................. 56 147 7.1.1. Generic Media Event Package ..................... 56 148 7.1.2. DTMF Event Package .............................. 57 149 7.1.3. MF Event Package ................................ 60 150 7.1.4. Trunk Event Package ............................. 61 151 7.1.5. Line Event Package .............................. 62 152 7.1.6. Handset emulation Event Package ................. 66 153 7.1.7. RTP Event Package ............................... 67 154 7.1.8. Network Access Server Event Package ............. 68 155 7.1.9. Announcement Server Event Package ............... 69 156 7.1.10. Script Event Package ........................... 70 157 7.2. Basic Termination Classes ............................ 71 158 7.2.1. DS0 Terminations ................................ 71 159 7.2.2. Analog Terminations ............................. 72 160 7.2.3. RTP Audio Terminations .......................... 74 161 7.2.4. ATM audio Terminations .......................... 78 162 7.2.5. Network access service Termination .............. 80 163 8. Acknowledgements .......................................... 84 164 9. References ................................................ 84 165 10. Authors' Addresses ....................................... 85 167 Internet draft MEGACO Protocol April 16, 1999 169 1. Introduction 171 This document describes the MEGACO protocol for controlling Media Gate- 172 ways from external call control elements called Media Gateway Controll- 173 ers. 175 1.1. High Level Description of the Protocol 177 This section describes the model and main concepts upon which the MEGACO 178 Protocol is built. It is intended to familiarize the reader with the 179 model, terminology and working concepts of the protocol. This section's 180 contents are illustrative and do not intend to supersede information 181 contained in later sections of this document. Where discrepancies may 182 exist, the later sections shall be assumed to contain the correct infor- 183 mation. 185 1.1.1. Connection Model 187 The connection model for the MEGACO protocol is described using just two 188 abstractions, Terminations and Contexts. Terminations (T) are entities 189 representing physical endpoints, such as analog loops or timeslots on a 190 TDM channel, as well as more ephemeral representations of flow termina- 191 tions, such as RTP streams. 193 Internet draft MEGACO Protocol April 16, 1999 195 *======================================================* 196 | Media Gateway | 197 | +-----------------------------------+ | 198 | | Context +---+ | | 199 | | | T | | | 200 | +---+ | +-+-+ | | 201 | | T | | | | | 202 | +---+ | +---+ +-+ +---+ | | 203 | | | T +---------+M+---------| T | | | 204 | | +---+ +-+ +---+ | | 205 | | | | | 206 | | +-+-+ | | 207 | | | T | | | 208 | | +---+ | | 209 | +-----------------------------------+ | 210 | | 211 | +----------------------+ +---------------+ | 212 | | Context | | Context | | 213 | | +---+ +-+ | | +---+ +-+ | | 214 | | | T +---------+M+ | | | T +----+M+ | | 215 | | +---+ +-+ | | +---+ +-+ | | 216 | | | | +---------------+ | 217 | | +-+-+ | | 218 | | | T | | | 219 | | +---+ | | 220 | +----------------------+ | 221 *======================================================* 223 Examples of Contexts and Terminations Within an MG 225 Contexts represent a star configuration (i.e.-a variable number of 226 interconnected nodes) of Terminations of a single media type. Audio 227 connections are modeled by viewing the Context as a mixing bridge (M). 228 For connections involving other media types and for mixed media gate- 229 ways, the Context's behavior will be described as an extension to the 230 protocol. There are commands to Add Terminations to a Context, Subtract 231 Terminations from a Context, and Move Terminations between two Contexts. 233 A Context must have at least one Termination and a Termination may 234 belong to no more than one Context at a given time. A Context is 235 created by the Add of its first Termination and is destroyed by a Sub- 236 tract of its last remaining Termination. It is possible to move a Ter- 237 mination from one Context to another with the use of the Move command. 238 It is also possible for a Termination to exist outside of a Context. 240 Internet draft MEGACO Protocol April 16, 1999 242 A Media Gateway may limit the number of Terminations that it supports in 243 a given Context. For example, a limit of two might exist for very sim- 244 ple gateways. A limit of three might be common for gateways that sup- 245 port a three-way calling but not multi-way calling of any larger propor- 246 tions. 248 To illustrate the use of a Context, consider a Media Gateway that pro- 249 vides media adaptation between the PSTN and a VoIP network. In this 250 case a typical Context might contain two Terminations, one representing 251 a PSTN trunk (a DS0 Termination) and the other an RTP Stream Termina- 252 tion. A PSTN hairpin connection would be represented by a Context with 253 two DS0 Terminations in it. A three-way call and larger conferences 254 would be represented by a Context with three or more Terminations in it. 256 The use of Contexts to represent conferences is very powerful since it 257 enables a description of the conference dynamics that is not restricted 258 in any way by the order in which Terminations are added or subtracted. 259 For instance, no special operations are required when a participant in a 260 conference drops out. Its Termination may be subtracted without affect- 261 ing the connectivity of the Terminations remaining in the conference. 263 The call-waiting scenario shown below illustrates the use of the Move 264 command to relocate a Termination between Contexts. In this example, 265 Terminations T1 and T2 belong initially to Context C1. T1 might be the 266 line side of a residential gateway, while T2 could represent an RTP 267 Stream Termination. When T1 is connected to T2 in Context C1 a new call 268 arrives for T1 from Termination T3. T3 is placed in Context C2. After 269 alerting is applied to T1 in Context C1 and T1 provides signaling to 270 accept the waiting call, T1 is moved from C1 to C2 through use of the 271 Move command. The active call is represented now by C2 and the call on 272 hold is represented by C1. 274 Internet draft MEGACO Protocol April 16, 1999 276 Call Waiting Scenario: 278 Initial Call 279 +-C1--------------------+ 280 | +---+ +-+ +---+ | 281 | |T1 +---+M+---| T2| | 282 | +---+ +-+ +---+ | 283 +-----------------------+ 285 New Call Arrives 287 +-C1--------------------+ +-C2--------------------+ 288 | +---+ +-+ +---+ | | +-+ +---+ | 289 | |T1 +---+M+---| T2| | | +M+---| T3| | 290 | +---+ +-+ +---+ | | +-+ +---+ | 291 +-----------------------+ +-----------------------+ 293 Waiting Call Answered 295 +-C1--------------------+ +-C2--------------------+ 296 | +-+ +---+ | | +---+ +-+ +---+ | 297 | +M+---| T2| | | |T1 +---+M+---| T3| | 298 | +-+ +---+ | | +---+ +-+ +---+ | 299 +-----------------------+ +-----------------------+ 301 1.1.2. Terminations 303 A Termination representing a physical device may be permanently instan- 304 tiated and can exist outside of a Context. Terminations representing 305 packet flows are typically ephemeral and are created within a Context as 306 a byproduct of an Add command. 308 All Terminations, ephemeral or not, are named entities and are members 309 of their specific TerminationClass. Names are hierarchical. Termina- 310 tion names may be "underspecified" by the MGC and subsequently given a 311 unique name (i.e.-the last component of the hierarchical name will be 312 unique) by the Media Gateway. Wildcards may be used in the specifica- 313 tion of a name. Section [2.1.2] describes in detail the structure and 314 properties of entity names used in the MEGACO Protocol. 316 1.1.3. Termination Capabilities 318 Membership in a TerminationClass determines the capabilities of a Termi- 319 nation. The TerminationClass defines the default values and allowable 321 Internet draft MEGACO Protocol April 16, 1999 323 ranges for the Termination's capabilities. Capabilities include: 325 * Properties, such as Termination address, media parameters, security 326 parameters, etc. These are grouped into Profiles. 328 * Events and Signals that a Termination supports. These are grouped 329 in Packages. 331 * Statistics that are kept for Terminations of this Class 333 A TerminationClass is described by a list of Profiles, Packages and 334 statistics that it implements. TerminationClasses, Profiles and Packages 335 cannot be created or modified using the commands of the Megaco protocol, 336 but this document defines several commonly implemented ones. 338 The capabilities of a Termination can be obtained using the Audit com- 339 mand. 341 1.1.4. Instantiation of a Termination An MG realizes instances of a 342 TerminationClass. The Terminations are instantiated for each "port" on 343 an MG, and are instantiated by the MG when it restarts (or potentially 344 by some administrative provisioning means outside the scope of the Pro- 345 tocol). For Physical Terminations, all instances of a Termination are 346 instantiated by the MG when it restarts (or potentially by some adminis- 347 trative provisioning means). Ephemeral Terminations are instantiated by 348 the Add command, and destroyed by the Subtract command. 350 The "highest order" (first component of a hierarchical name) termination 351 has a full set of properties that can be altered by the MGC; they 352 represent default values for fully instantiated Terminations. The Pro- 353 file defines the initial default values assumed by the Termination upon 354 MG restart. 356 1.1.5. Termination Dynamics 358 As Terminations are Added or Moved it is necessary to specify state and 359 media parameters for, Events to be detected on, and Signals to be 360 applied to such Terminations within the Context in which they exist. It 361 may also be necessary during the life of a Termination within a Context 362 to Modify these properties. 364 For Terminations representing physical entities it might also be desir- 365 able to Modify their properties as they are Subtracted from a Context. 366 This may be the case if a configuration different to the one provided by 367 the defaults is needed. Such Terminations may have their properties 368 Modified outside of their existence within a Context. 370 The protocol assumes that it is the MG that is responsible for creating 372 Internet draft MEGACO Protocol April 16, 1999 374 the network connection to the other side of the call. The MGC directs 375 that it do so by, for example, creating an RTP termination, which would 376 have the side effect of causing the MG to create an RTP flow to the 377 other party. On an ATM network using SVCs, it is the MG that would use, 378 for example, UNI to create a bearer connection. 380 The Add, Subtract, Move and Modify commands may affect the following 381 sets of properties: 383 * TerminationState: A list of properties that define the state of the 384 Termination, but which are not directly linked to the description 385 of a media flow, to an Event list or to a Signal list. 387 * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists 388 of properties describing the processing of the media flow in each 389 direction. 391 * EventsDescriptor: A list of Events that should be detected on the 392 Termination. 394 * SignalDescriptor: A list of Signals that should be applied on the 395 Termination. 397 For example, the Add Command has the following form: 399 Add(TerminationId, 400 [LocalTerminationState,] 401 [LocalTerminationDescriptor,] 402 [RemoteTerminationDescriptor,] 403 [EventsDescriptor,] 404 [SignalDescriptor]) 406 All parameters listed are optional except for the TerminationId. This 407 allows each command to specify exactly what needs to be modified. Addi- 408 tionally, some parameters may not be required for certain TerminationC- 409 lasses. For instance, DS0s do not use RemoteTerminationDescriptors. 410 These descriptors are used only for packet TerminationClasses. 412 A Termination is programmed to look for specific Events through the 413 EventsDescriptor, which is a parameter to Add, Modify and Subtract. 414 When a Termination detects an Event that matches the types of Events it 415 is programmed to detect, the MG generates a Notify command. 417 The MG can generate a ServiceChange message. ServiceChange has a number 418 of uses: Registration of an MG with an MGC, notification of imminent 419 downtime for one or more Terminations, notification that one or more 421 Internet draft MEGACO Protocol April 16, 1999 423 Terminations has already gone out of service, and notification that one 424 or more Terminations have been brought back into service. 426 Detailed definitions of Commands and their Responses are provided in 427 Section 2. 429 1.1.6. Issuing Commands in Transactions 431 The protocol has been designed to allow multiple Commands to be packed 432 in single TransactionRequest. The corresponding Responses are received 433 in a single Transaction reply. There are two types of replies, a Tran- 434 sactionAccept and a TransactionReject. A Transaction allows Commands to 435 share fate and guarantees ordered processing. Multiple Transactions 436 may, in turn, be packed into a single message. 438 Commands in a Transaction are executed sequentially according to an "all 439 or nothing rule". That is, a TransactionAccept includes successful 440 Responses for ALL the Commands in the corresponding TransactionRequest. 441 A TransactionReject is sent when one of the Commands included in the 442 Transaction fails. Responses for the Commands in a TransactionReject 443 are issued as follows: 445 * All Commands before the point of failure in the Command sequence 446 should have a Response equal to "non-executed". 448 * The failed Command should have a Response with a Reason Code. 450 * Commands after the point of failure are not processed and, there- 451 fore, Responses are not issued for them. 453 The parsing mechanism described in the coding section (section 3) speci- 454 fies how responses or reason codes are associated with individual Com- 455 mands. 457 When a MGC issues Commands to a MG, a Context must always be specified. 458 This is quite natural for Add and Subtract. For Modify Commands on a 459 Termination that is not in a Context, the null Context must be speci- 460 fied, which changes the default values of properties for that Termina- 461 tion. A Move Command clearly involves two Contexts, however only the 462 target Context needs to be specified (i.e. the Move has the semantics of 463 "Move-To"). Within a Transaction, all Commands that apply to a Context 464 must appear after the ContextId parameter. 466 The following lines illustrate (i.e., syntax is ad-hoc and actions some- 467 what simplified) the use of Transactions in the call-waiting example of 468 section 1.1.1. The Transaction that creates the second Context, applies 469 Signals to Termination T1 (to indicate call-waiting) and detects Events 470 from T1 (to swap the call) is formed as follows: 472 Internet draft MEGACO Protocol April 16, 1999 474 Transaction(TransactionId=12345 475 ContextId=* Add(T3) 476 ContextId=C1 Modify(T1, EventDescriptor, SignalDescriptor) ) 478 The Commands in this Transaction are processed sequentially. First, the 479 MG creates a Context to Add T3. Second, T1 is programmed to Signal the 480 waiting call and collect the Events that operate the call-waiting 481 feature. 483 The next Transaction shows the Commands issued by the MGC to swap the 484 Terminations. 486 Transaction(TransactionId=12346 487 ContextId=C2 Move(T1) Modify(T3, TerminationState) 488 ContextId=C1 Modify(T2, TerminationState) ) 490 Again, the Commands in this Transaction are processed sequentially. 491 First, the MG moves T1 from C1 into C2. Then it modifies the Mode of T3 492 to Sendrecv. Finally, T2 in C1 is set to Receive Mode. 494 1.1.7. Sample Command Flow 496 This section presents an illustration of the use of the protocol Com- 497 mands to establish a communication between two Residential Gateways over 498 an IP trunking network, both MGs are under the control of the same MGC. 500 Internet draft MEGACO Protocol April 16, 1999 502 |Step | User | ResMG | MGC | ResMGr | User | 503 |_____|___________|_____________|________________|_____________|___________| 504 | 0| | <------CTX=null,Modify(T1) | | 505 | | | Resp-------------> | | | 506 | | | (Ok,ready, looking for Off-hook) | | 507 | 1| Off-hook | Notify----------------> | | | 508 | | | | (off-hook recorded) | | 509 | | | <--------------Resp(Ok)| | | 510 | 2|Acc Digits | | | | | 511 | | | | | | | 512 | 3|DgtsColct'd| Notify -----------> | | | 513 | 4| | <--------------Resp(Ok)| | | 514 | | | | | | | 515 | 5| | <------CTX=* ADD(T1) | | | 516 | | | | ADD(RTP/* LocalDesc) | | 517 | 6| | CTX=C1 ---------> | | | 518 | | | Resp(Ok) | | | | 519 | | | Resp(RTP/Id,LocalDesc,RemoteDesc | | 520 | | | | | | | 521 | 7| | |CTX=* ADD(T1r)---------> | | 522 | | | | ADD(RTPr/*,LocalDesc,RemoteDesc) | 523 | | | | | | | 524 | 8| | | <---------------CTX=C1r | | 525 | | | | | Resp(Ok) | | 526 | | | Resp(RTP/Id,LocalDesc,RemoteDesc) | | 527 | | | | | | | 528 | 9| | |CTX=C1r --------------> | | 529 | | | | Modify(T1r,SignalList=Ring) | 530 | | | | | | | 531 | | | | | | | 532 | 10| | | <---------------CTX=C1r | Ring | 533 | | | | | Resp(Ok) | | 534 | | | | | | | 535 | 11| | <-------CTX=C1 Modify(T1, SignalList=Ringback) | 536 | | | | Modify(RTP/Id,LocalDesc,RemoteDesc) 537 | 12| Ring-Back | CTX=C1 ---------> | | | 538 | | | Resp(Ok) | | | | 539 | | | Resp(RTP/Id,LocalDesc,RemoteDesc) | | 540 | | | | | | | 541 | 13| | | <------------- Notify | Off-hook | 542 | 14| | | Resp(Ok)----------> | | 543 | | | | | | | 544 | | | | | | | 545 | 15| | <------CTX=C1 Modify(T1,TerminalState=Sendrcv | 546 | | | | | SignalList) | | 547 | 16| | CTX=C1 ---------> | | | 548 | | | Resp(Ok) | | | | 550 Internet draft MEGACO Protocol April 16, 1999 552 CTX = ContextID 554 Step 0: 555 The MGC issues a Modify Command to request that T1 detect an Off- 556 hook and proceed with digit collection 558 Step 1: 559 The Off-hook is detected, the Notify Command is issued and the 560 Off-hook recorded for billing purposes. 562 Step 2: 563 The Termination collects and accumulates digits according to an 564 appropriate digit map. 566 Step 3: 567 The collected digits are sent to the MGC in a Notify Command. 569 Step 4: 570 The MGC acknowledges the digit string. 572 Step 5: 573 After determining that the digit string is valid to initiate a 574 call, the MGC uses the Add Command to create a Context that 575 includes T1 and a yet unnamed ephemeral packet Termination (RTP/*). 576 The RTP Termination receives only a LocalTerminationDescriptor that 577 specifies, for instance, a choice of codecs. 579 Step 6: 580 The reply to the Add Command includes a named Context (C1) and a 581 named RTP Termination (RTP/Id) with its LocalTerminationDescriptor 582 including supported Codecs and the receiving RTP port. 584 Step 7: 585 The MGC can now instruct the remote Residential MG to Add the Ter- 586 mination that corresponds to the dialed string (e.g., T1r) and a 587 corresponding RTP Termination in a Context. The information 588 returned in T1's LocalTerminationDescriptor is passed to the remote 589 Residential MG in the RemoteTerminationDescriptor. The LocalTer- 590 minationDescriptor specifies the Codecs for T1r. 592 Step 8: 593 The reply to the Add Command includes a named Context (C1r) and a 594 named RTP Termination (RTP/Idr) with its LocalTerminationDescriptor 595 including supported Codecs and the receiving RTP port. 597 Step 9: 598 The MGC can now request that Ringing be applied on T1r. The Modify 600 Internet draft MEGACO Protocol April 16, 1999 602 Command is used for this. Looking for Off-hook is simultaneously 603 programmed in T1r. 605 Step 10: 606 The Response indicating that Ringing is applied is sent to the MGC. 608 Step 11: 609 Two Modify commands are issued in this Transaction. The first 610 requests that Ring-back be applied to T1. The second provides the 611 RemoteTerminationDescriptor, which indicates the remote RTP receiv- 612 ing port. 614 Step 12: 615 The TransactionReply acknowledges that Ringback is being applied 616 and the RTP parameter settings have been updated. 618 Step 13: 619 The remote user goes off-hook. A Notify Command conveys that 620 information to the MGC. It is assumed that the off-hook command has 621 an associated action that cancels ringing. 623 Step 14: 624 The Notify is acknowledged by the MGC. 626 Step 15: 627 The MGC issues a Modify Command to T1 to set the two-way talk path 628 and cancel ringback. 630 Step 16: 631 The MG acknowledges that the call set up is complete. 633 2. Commands 635 Commands from the MGC to the MG are grouped into Transactions, each of 636 which requires a Transaction ID. Transactions consist of one or more 637 Actions. Each Action is limited to operate within a single Context and 638 consequently must specify a ContextID. There are two circumstances 639 where a specific ContextID is not provided. One is the case of modifi- 640 cation of a Termination outside of a Context. The other is where the 641 controller requests the gateway to create a new Context. Each of these 642 two cases has a distinguished value for ContextID 644 An Action consists of a series of Commands (Add, Subtract, Modify, Move, 645 etc.). These Commands have very similar parameters, which may include: 647 * TerminationState: A list of properties that define the state of the 648 Termination, but which are not directly linked to the description 649 of a media flow, to an Event list, or to a Signal list. This 651 Internet draft MEGACO Protocol April 16, 1999 653 includes a description of the media handling at the Termination 654 (e.g., the Mode parameter that indicates loopback, COT, etc.) and a 655 description of the handling of accumulated Events that are pending 656 for processing (i.e., "buffered events"). 658 * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists 659 of properties describing the processing of the media flow in each 660 direction. These are expressed in the form of SDPdescriptors[ref]. 662 * EventsDescriptor: A list of Events that should be detected on the 663 Termination. These Events must be supported by the Package(s) of 664 the TerminationClass. The EventDescriptor can be augmented by a 665 DigitMap. 667 * SignalDescriptor: A list of Signals that should be applied on the 668 Termination. These Signals must be supported by the Package(s) of 669 the TerminationClass. 671 * A DigitMapDescriptor, which creates, deletes, or redefines a Digit 672 Map. A Digit Map is a concise description of how an MG is to han- 673 dle a series of events from the detection of tones (such as from 674 DTMF tone detection). 676 Responses which return information do so in the form of a LocalTermina- 677 tionDescriptor, RemoteTerminationDescriptor, or a Statistics summary. 679 2.1. Names and Common Parameters 681 2.1.1. Context Identifiers 683 Contexts are identified by a ContextID, which is assigned by the Media 684 Gateway and is unique within the scope of the Media Gateway. The proto- 685 col makes reference to two distinguished values: 687 * The null Context, which is used to refer to a Termination outside 688 of a Context. When used with a Modify Command, such a reference 689 changes the default values for the Termination. 691 * The "unspecified" Context, which is used to request that the MG 692 create a new Context. The actual ContextID must be returned to the 693 MGC for subsequent use. 695 2.1.2. Termination Names 697 Names for Terminations (called a "TerminationID") are hierarchical. A 698 separation character delimits the components of a name from one another. 699 An example name in a Termination Class that implements a channelized T3 700 is "com1/3/17". This name refers to a T3 called "com1", the "3" 702 Internet draft MEGACO Protocol April 16, 1999 704 specifies a specific DS1 in the T3. The "17" specifies a specific DS0 705 in the DS1. 707 There is a special Termination called "Root". Root refers to the MG 708 itself. 710 TerminationIDs in Commands may use wildcards. Two wildcard constructs 711 are provided: "all" and "choose". The "all" construct allows a Command 712 to specify all possible values of a component. One can, for example, 713 use "all" to refer to all DS1s of a T3 (com1/*). 715 When an Ephemeral Termination is to be created, the TerminationID may 716 given with the last component specified as "choose". The MG would 717 create a fully instantiated Termination and supply a unique name which 718 must be returned to the MGC and be used for subsequent Transactions. 719 The MGC may supply a unique TerminationID, in which case the MG is 720 obliged to use that name. MGs MAY refuse a request to choose a name, in 721 which case they must return an appropriate error code 723 2.1.3. Specifying Properties 725 Commands may include descriptors. Each descriptor has a set of legal 726 properties that may be included, which is part of the definition of the 727 Termination Class (properties legal for TerminationState, LocalTermina- 728 tionDescriptor and RemoteTerminationDescriptor), or Package (properties 729 legal for EventDescriptor or SignalDescriptor). In a descriptor, each 730 of the properties may be fully specified, under-specified, or unspeci- 731 fied. 733 * Fully specified properties have a single, unambiguous value that 734 the MGC instruct the MG to use for the specified parameter 736 * Under-specified properties have a list of potential values. The MG 737 chooses one value from the offered list, and returns the value it 738 chose to the MGC. A common example is choice of codec. The MGC 739 may allow the MG to choose from G.729a, G.723 or G.711. The MG's 740 choice may be limited based on availability of DSP resources at the 741 time the request was made. The order in which the MGC presents 742 choices to the MG represents the MGCs order of preference for the 743 values offered, which the MG is encouraged, but not obligated to 744 respect. 746 * Unspecified properties (legal properties which do not occur in the 747 descriptor) result in the MG retaining the previous value for that 748 parameter. Each property has a default value, which is the value 749 assumed by the property when it is not part of a context, or when 750 the Termination is added to a Context but not assigned a specific 751 value when added. Default values can be changed by the MGC. 753 Internet draft MEGACO Protocol April 16, 1999 755 2.1.4. Termination State Properties 757 TerminationState groups a list of properties that define the state of 758 the Termination, but are not directly linked to a media flow, to an 759 Event list or to a Signal list. These properties are: 761 * TerminationMode 763 * EventBufferProcessing 765 * EventBufferNotification 767 The TerminationMode parameter indicates the relation between the Termi- 768 nation and the "star" connection of the Context. The mode are "send 769 only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), 770 "inactive" (inactive), "outofservice" and "test" (test). 772 The handling of the media received on the Termination is determined by 773 the TerminationMode parameter value: 775 * Termination whose mode is "send", or "send/receive" receive the 776 signals mixed in the Context, according to media specific rules - 777 audio Terminations for example, will receive the sum of the audio 778 flows coming from all other Terminations, excluding those coming 779 from this specific Termination. 781 * The "test" mode is used during maintenance and continuity test 782 operations. There are several defined Packages that implement vari- 783 ous forms of tests that can be applied to a Termination. 785 The optional EventBufferProcessing and EventBufferNotification descrip- 786 tors specifies the handling of "buffered" Events, i.e. Events that have 787 been detected by the MG before the arrival of an EventsDescriptor, but 788 have not yet been notified to the MGC. 790 * EventBufferProcessing specifies whether the buffered Events should 791 be processed or discarded (the default is to process them.) 793 * EventBufferNotification specifies whether the MG is expected to 794 generate at most one notification (step by step), or multiple 795 notifications (loop), in response to this request (the default is 796 at most one.) 798 2.1.5. Termination Descriptors 800 The LocalTerminationDescriptor and RemoteTerminationDescriptor parame- 801 ters describe the processing of the media flow in each of the direc- 802 tions. The actual properties of each descriptor depend on the Profiles 804 Internet draft MEGACO Protocol April 16, 1999 806 specified for Termination Class. Examples of Termination Classes are 807 RTP, Analog, DS0. For an RTP Termination, for example, some of the pro- 808 perties might be: 810 * IP address, 812 * UDP ports (RTP and RTCP), 814 * Encoding Method, 816 * Packetization period, 818 The LocalTerminationDescriptor and RemoteTerminationDescriptor are 819 described in the form of an SDP descriptor which is part of the defini- 820 tion of a Profile. These sets of properties can be enhanced by vendor 821 specific optional or mandatory extensions. Properties in the LocalTer- 822 minationDescriptor and the RemoteTerminationDescriptor may be fully 823 specified, under-specified or (by omission) unspecified as described 824 above. 826 2.1.6. Events, Signals and Packages 828 The MGC may ask to be notified about certain Events occurring on a Ter- 829 mination, e.g. off-hook Events, and a MGC may request certain Signals to 830 be applied to a Termination, e.g. dial-tone. 832 Events and Signals are grouped in Packages within which they share the 833 same namespace which we refer to as Event names. Packages are groupings 834 of the Events and that are related. For instance, one Package may sup- 835 port a certain group of Events and Signals for Simple analog access 836 lines, and another Package may support another group of Events and Sig- 837 nals for video lines. One or more Packages may applicable for a given 838 Termination Class, and part of the description of the Termination Class 839 consists of a list of supported Packages. 841 Event names are composed of two logical parts, a Package name and an 842 Event name. Examples of Package names are DTMF, MF, Trunk or Line. Exam- 843 ples of Event names are off hook, flash hook or "0" (the digit zero). 845 This document defines a basic set of Package names and Event names. 846 Additional Package names and Event names can be registered with the 847 IANA. A Package definition shall define the name of the Package, and the 848 definition of each Event belonging to the Package. The Event definition 849 shall include the precise name of the Event (i.e., the code used in the 850 MEGACO protocol), a plain text definition of the Event, and, went 851 appropriate, the precise definition of the corresponding Signals, for 852 example the exact frequencies of audio signal such as dial tones or DTMF 853 tones. 855 Internet draft MEGACO Protocol April 16, 1999 857 Signals are divided into different types depending on their behavior: 859 * On/off (OO) 860 Once applied, these Signals last forever until they are turned off. 861 This may happen either as the result of an Event or a new SignalRe- 862 quests (see later). 864 * Time-out (TO) 865 Once applied, these Signals last until they are either turned off 866 (by an Event or SignalRequests) or a Signal specific period of time 867 has elapsed. Depending on Package specifications, a Signal that 868 times out may generate an "operation complete" Event. 870 * Brief (BR) 871 The duration of these Signals is so short, that they stop on their 872 own. If an Event occurs the Signal will not stop, however if a new 873 SignalRequests is applied, the Signal will stop. 875 TO Signals are normally used to alert the Terminations' users, to signal 876 them that they are expected to perform a specific action, such as hang 877 down the phone (ringing). Transmission of these Signals should typically 878 be interrupted as soon as the first of the requested Events has been 879 produced. 881 2.1.7. SignalDescriptors 883 A SignalDescriptor is a parameter that contains the set of Signals that 884 the MG is asked to apply to the Termination, such as, for example ring- 885 ing, or continuity tones. Signals are identified by their name, which is 886 an Event name, (and thus part of a Package)and may be qualified by pro- 887 perties. 889 If a Signal has already been attached to this Termination, the previous 890 Signal is removed, and the specified one is attached. No Events which 891 would have occurred on the previous Signal will be generated subsequent 892 to a command that modifies the Signal descriptor, although the MGC may 893 not have received an Event from the previous Signal prior to sending the 894 command, and in fact the MG may have detected such an Event, but may not 895 have notified the MGC of it when it receives the new command. The 896 behavior of the MG in such a circumstance is not defined. It may send 897 the notification, or it may flush it. 899 2.1.8. EventDescriptors 901 The EventDescriptor parameter contains a RequestIdentifier and a list of 902 Events that the MG is requested to detect and report. Such Events 903 include, for example, fax tones, continuity tones, or on-hook transi- 904 tion. The RequestIdentifier is used to correlate this request with the 906 Internet draft MEGACO Protocol April 16, 1999 908 notifications that it may trigger. 910 To each Event is associated a notification action and an optional set of 911 embedded Events and Signal descriptors. The notification actions are: 913 * Notify the Event immediately, together with the accumulated list of 914 observed Events, 916 * Accumulate the Event in an Event buffer, but don't notify yet, 918 * Accumulate according to a specified Digit Map, 920 * Treat the Event according to a specific script, 922 * Ignore the Event. (Events that are not specified in the descriptor 923 are, by default, ignored.) 925 The embedded Signal descriptor, if present, is used as a replacement for 926 the current Signal descriptor. It is possible, for example, to specify 927 that the dial-tone Signal be generated when an off-hook Event is 928 detected, or that the dial-tone Signal be stopped when a digit is 929 detected. If no embedded Signal descriptor is specified, the production 930 of Signals continues as specified in the command. 932 The embedded Events descriptor, if present, is used as a replacement for 933 the current Event descriptor. It is possible, for example, to specify 934 that DTMF digit collection starts as soon as an off-hook Event is 935 detected. 937 MEGACO Protocol implementations must be able to support at least one 938 level of embedding. An embedded Events descriptor that respects this 939 limitation shall not contain another Embedded Events descriptor. 941 2.1.9. Digit Maps 943 The MGC can ask the MG to collect digits dialed by the user. This facil- 944 ity is intended to be used with residential gateways to collect the 945 numbers that a user dials; it may also be used with trunking gateways 946 and access gateways alike, to collect the access codes, credit card 947 numbers and other numbers requested by call control services. 949 An alternative procedure is for the MG to notify the MGC of the dialed 950 digits, as soon as they are dialed. However, such a procedure generates 951 a large number of interactions. It is preferable to accumulate the 952 dialed numbers in a buffer, and to transmit them in a single message. 954 The problem with this accumulation approach, however, is that it is hard 955 for the gateway to predict how many digits it needs to accumulate before 957 Internet draft MEGACO Protocol April 16, 1999 959 transmission. For example, using the phone on our desk, we can dial the 960 following numbers: 962 _______________________________________________________ 963 | 0 | Local operator | 964 | 00 | Long distance operator | 965 | xxxx | Local extension number | 966 | 8xxxxxxx | Local number | 967 | #xxxxxxx | Shortcut to local number at| 968 | | other corporate sites | 969 | *xx | Star services | 970 | 91xxxxxxxxxx | Long distance number | 971 | 9011 + up to 15 digits| International number | 972 |________________________|_____________________________| 974 The solution to this problem is to load the MG with a digit map that 975 correspond to the dial plan. 977 A digit map is defined by a name and a value. The name is "visible" 978 within a scope, which can be the gateway itself, a hierarchical group of 979 Terminations, or a specific Termination. Digit maps are provisioned 980 through standard Termination management operations such as Add, Modify, 981 Subtract or Move. The scope of the digit map is determined by the name 982 of the Termination to which the command is applied: 984 * If the command is applied to the "all" wildcarded Termination, the 985 digit map is visible within the scope of the MG, 987 * If the command is applied to a hierarchical name such as "Com1/3", 988 the digit map becomes visible within all Terminations whose name 989 begins with the specified prefix. 991 The DigitMapDescriptor contains a set of Digit Maps names and values to 992 be assigned: 994 * A new digit map is created by specifying a name that is not yet 995 defined at this level of the naming hierarchy. The value must be 996 present. 998 * A digit map value is updated by supplying a new value for a name 999 that is already defined at this level of the naming hierarchy. 1000 Terminations using the map in an EventDescriptor when it is modi- 1001 fied continue to use the old value. Subsequent EventDescriptors 1002 mentioning the DigitMap use the new value. 1004 * A digit map is deleted by supplying an empty value for a name that 1005 is already defined at this level of the naming hierarchy. A 1007 Internet draft MEGACO Protocol April 16, 1999 1009 wildcard naming convention can be used to delete all the digit maps 1010 associated with a specific Termination. 1012 The MGC can determine defined digit maps with the Audit command. 1014 The collection of digits according to a digit map may be protected by an 1015 "interdigit timer", which can take two values: 1017 - If the gateway can determine that at least one more digit is 1018 requested for the digit string to match any of the allowed patterns 1019 in the digit map, then the timer value should be set to a long 1020 duration, such as 16 seconds. 1022 - If the digit map specifies that a variable number of additional 1023 digits may be needed (the "." indication at the end of a string), 1024 then the timer value should be set to a medium duration, such as 8 1025 seconds. 1027 The "long interdigit timer" and the "short interdigit timer" are parame- 1028 ters associated with a digit map. 1030 The digit map mechanism is only used to reduce the number of messages 1031 between the MG and the MGC. It does not interpret or translate dialed 1032 digits. The MGC is free to not employ digit maps, and to request an 1033 Event notification per digit. 1035 2.1.10. Statistics 1037 The MG may maintain statistics that describe the status of the Termina- 1038 tion. The precise properties of the statistics depends on the Class of 1039 the Termination. 1041 In the RTP class, the properties might include: 1043 * Number of packets sent: 1045 * Number of octets sent: 1047 * Number of packets received: 1049 * Number of octets received: 1051 * Number of packets lost: 1053 * Interarrival jitter: 1055 Internet draft MEGACO Protocol April 16, 1999 1057 2.2. Termination Management Commands 1059 2.2.1. Add 1061 The Add commands adds a Termination to a Context. 1063 [TerminationId,] 1064 [LocalTerminationDescriptor,] 1065 [RemoteTerminationDescriptor,] 1066 <--- Add(TerminationId, 1067 [TerminationState,] 1068 [LocalTerminationDescriptor,] 1069 [RemoteTerminationDescriptor,] 1070 [EventsDescriptor,] 1071 [SignalDescriptor,] 1072 [DigitMapDescriptor]) 1074 TerminationId is the name of the Termination that is being added to the 1075 Context. The TerminationId may be under-specified by using the "choose" 1076 wildcard convention. This convention must be used for packet Termina- 1077 tions. If the TerminationId is under-specified, the actual identifier 1078 must be assigned by the MG and its complete value returned in the 1079 response. 1081 The TerminationState properties can be fully specified or unspecified by 1082 the MGC. The MG uses the specified value when it is present. The pro- 1083 perty is unmodified if it is not mentioned 1085 The LocalTerminationDescriptor properties can be either fully specified, 1086 under-specified or unspecified by the MGC. The MGC may under-specify a 1087 parameter by providing a loose specification, such as a list of allowed 1088 encoding methods or a range of packetization periods. When the value 1089 are under-specified, the MG returns a fully qualified LocalTermination- 1090 Descriptor. When a value is unspecified, the MG does not change the 1091 value of a property. Since properties not in a Context have default 1092 values, unspecified properties in an Add will have default values. 1094 The RemoteTerminationDescriptor is the descriptor for the remote side of 1095 a Termination, for example on the other side of the IP network. It 1096 includes the same fields as in the LocalTerminationDescriptor, i.e. the 1097 fields that describe a session according to the SDP standard. This 1098 descriptor may be omitted when the information for the remote end is not 1099 known yet. This information may be provided later via a Modify command. 1101 Under-specified properties in RemoteTerminationDescriptor is possible 1102 where the remote side has offered a choice, but the MG may have resource 1103 restrictions which prevent the MGC from being able to make the choice. 1105 Internet draft MEGACO Protocol April 16, 1999 1107 When the value of any properties in the descriptor are under-specified, 1108 the MG returns a fully qualified RemoteTerminationDescriptor. When a 1109 value is unspecified, the MG does not change the value as described 1110 above. 1112 Physical Terminations typically would not have a RemoteTermination- 1113 Descriptor, but the Termination Class defines whether it does or does 1114 not in all cases 1116 After receiving an Add command that did not include a RemoteTermination- 1117 Descriptor, a MG is in an ambiguous situation. Because it has received a 1118 LocalTerminationDescriptor parameter, it can potentially receive pack- 1119 ets. Because it has not yet received the RemoteTerminationDescriptor of 1120 the other MG, it does not know whether the packets that it receives have 1121 been authorized by the MGC. It must thus navigate between two risks, 1122 i.e. clipping some important announcements or listening to potentially 1123 unintelligible, or unauthorized data. The behavior of the MG is deter- 1124 mined by the value of the Termination Mode element of the Termination- 1125 State parameter: 1127 * If the mode was set to ReceiveOnly, the MG should accept the voice 1128 signals and transmit them through the Termination. 1130 * If the mode was set to Inactive, Loopback, Continuity Test, the MG 1131 should ignore the voice signals. 1133 Note that the mode values SendReceive and SendOnly don't make sense in 1134 this situation. They should be treated as errors, and the command should 1135 be rejected. 1137 The EventsDescriptor parameter, if present, provides the list of Events 1138 that should be detected on the Termination. 1140 The SignalDescriptor parameter, if present, provides the list of Signals 1141 that should be produced on the Termination. 1143 The command may also include a DigitMapDescriptor. Each parameter 1144 describes the name and the value of a digit map in the Context of the 1145 Termination. 1147 2.2.2. Modify 1149 The Modify command modifies the properties of a Termination. 1151 [LocalTerminationDescriptor,] 1152 [RemoteTerminationDescriptor,] 1153 <--- Modify(TerminationId, 1154 [TerminationState,] 1156 Internet draft MEGACO Protocol April 16, 1999 1158 [LocalTerminationDescriptor,] 1159 [RemoteTerminationDescriptor,] 1160 [EventsDescriptor,] 1161 [SignalDescriptor,] 1162 [DigitMapDescriptor]) 1164 TerminationId is the name of the Termination whose properties are being 1165 modified. The TerminationId may not be under-specified. 1167 The Modify command takes place within the Context to which the Termina- 1168 tion belongs, or within the "null" Context when modifications are to be 1169 made to the default values for the Termination. 1171 The TerminationState properties can be fully specified or unspecified by 1172 the MGC. The MG uses the specified value when it is present, the previ- 1173 ous value otherwise. 1175 The LocalTerminationDescriptor properties can be either fully specified, 1176 under-specified or unspecified by the MGC. The MGC may under-specify a 1177 parameter by providing a loose specification, such as a list of allowed 1178 encoding methods or a range of packetization periods. When the value 1179 are under-specified, the MG returns a fully qualified LocalTermination- 1180 Descriptor. When a value is unspecified, the MG retains the previous 1181 value. 1183 The RemoteTerminationDescriptor properties can be either fully speci- 1184 fied, under-specified, or left unspecified by the MGC. When a value is 1185 unspecified, the MG keeps the previous value. A value is under- 1186 specified, the MG performs a selection and returns a RemoteTermination- 1187 Descriptor that documents the choices made. 1189 The EventsDescriptor parameter, if present, provides the list of Events 1190 that should be detected on the Termination. 1192 The SignalDescriptor parameter, of present, provides the list of signals 1193 that should be produced on the Termination. 1195 The command may also include a DigitMapDescriptor. Each parameter 1196 describes the name and the value of a digit map. 1198 Modify of a Termination in the null Context changes the default values 1199 for TerminationState, LocalTerminationDescriptor, RemoteTermination- 1200 Descriptor, EventsDescriptor, and SignalDescriptor on that Termination. 1201 Modify of a wildcarded termination ID in the null Context changes all 1202 instances of the Termination covered by the wildcard specification. 1204 Internet draft MEGACO Protocol April 16, 1999 1206 Modify of a TerminationID where only a subset of the hierarchy is named 1207 (such as "com1/3" where com1 represents a channelized T3 as described 1208 above), changes properties assigned to the logical unit covered by the 1209 name specified. In the example, changing "com1/3"'s "linecode = B8ZS" 1210 would alter the line coding of one of the DS1s in the T3 to B8ZS. Simi- 1211 larly, changing the linecode of "com1/*" would change the line coding 1212 for all DS1s in the T3. 1214 Modify can also be used to program the MG to Notify the MGC at particu- 1215 lar intervals if no other communication is occurring between the MGC and 1216 the MG. This has the effect of providing a heartbeat message from the 1217 MG to the MGC. 1219 2.2.3. Subtract 1221 The Subtract commands disconnects a Termination from a Context and 1222 returns statistics on it. 1224 Statistics | 1225 *[TerminationId, 1226 Statistics] 1227 <---- Subtract(TerminationId, 1228 [TerminationState,] 1229 [EventsDescriptor,] 1230 [SignalDescriptor,] 1231 [DigitMapDescriptor]) 1233 TerminationId is the name of the Termination whose properties are being 1234 modified. The TerminationId is either a fully specified value, or a 1235 wildcard value indicating that all the terminations of a given Context 1236 shall be removed. 1238 When all Terminations have been removed from a specified Context, that 1239 Context is deleted by the MG. 1241 Ephemeral Terminations are deleted when they are removed from their Con- 1242 text. The Subtract command, when applied to an Ephemeral Termination, 1243 shall not have any other parameter than the TerminationId. 1245 The LocalTerminationDescriptor and RemoteTerminationDescriptor of a per- 1246 manent termination are reset to their default value when the termination 1247 is removed from its Context. 1249 When applied to a Physical Termination, the Subtract command may include 1250 TerminationState, EventsDescriptor, SignalDescriptor and DigitMap- 1251 Descriptor parameters. These parameters are processed as defined in the 1253 Internet draft MEGACO Protocol April 16, 1999 1255 Modify command assuming a "null" Context, that is, they change the 1256 default values of the Termination. 1258 The command returns the statistics that were observed on the Termina- 1259 tion. When a wildcard is used, the command returns a Termination iden- 1260 tifier and statistics for each of the Terminations whose name matched 1261 the wildcard. 1263 2.2.4. Move 1265 The Move command moves a Termination to another Context. The Termination 1266 is removed from its old Context and is added to the new Context as an 1267 atomic operation. While this action appears similar to the packaging of 1268 a subtract and an add command, it does not have the side effect of 1269 deleting an Ephemeral Termination that the subtract command would cause. 1271 [LocalTerminationDescriptor,] 1272 [RemoteTerminationDescriptor] 1273 <-- Move(TerminationId, 1274 [TerminationState,] 1275 [LocalTerminationDescriptor,] 1276 [RemoteTerminationDescriptor,] 1277 [EventsDescriptor,] 1278 [SignalDescriptor,] 1279 [DigitMapDescriptor]) 1281 The TerminationId is the fully specified name of a Termination that is 1282 being moved into the Context specified for the transaction. The termi- 1283 nation is subtracted from its previous Context. If it was the last Ter- 1284 mination in this previous Context, that Context is deleted. A Context 1285 with only one Termination is permitted. 1287 The TerminationState, LocalTerminationDescriptor, RemoteTermination- 1288 Descriptor, EventsDescriptor, SignalDescriptor, and DigitMapDescriptor 1289 parameters are processed as in the Modify command. Management Commands 1291 2.2.5. Audit 1293 The Audit request returns properties associated with Terminations: 1295 Internet draft MEGACO Protocol April 16, 1999 1297 [TerminationId,] 1298 [TerminationState,] 1299 [LocalTerminationDescriptor,] 1300 [RemoteTerminationDescriptor,] 1301 [EventsDescriptor,] 1302 [SignalDescriptor,] 1303 [DigitMapDescriptor,] 1304 [Capabilities] 1305 [Statistics] 1306 <-- Audit (TerminationId, 1307 RequestedInfo) 1309 The TerminationId is the name of the termination that is being audited. 1310 The wildcard convention may be used. The command shall be applied either 1311 in the null Context, for Terminations that are not part of an active 1312 Context, or in the specific Context of the Termination(s). 1314 The (possibly empty) RequestedInfo parameter describes the information 1315 that is requested for the TerminationId specified. The following Termi- 1316 nation info can be audited with this command: 1318 TerminationState, LocalTerminationDescriptor, RemoteTermination- 1319 Descriptor, EventsDescriptor, SignalDescriptor, ObservedEvents 1320 DigitMapDescriptor, Statistics and Capabilities. 1322 The TerminationState, LocalTerminationDescriptor, RemoteTermination- 1323 Descriptor, EventsDescriptor, SignalDescriptor, ObservedEvents and 1324 DigitMapDescriptor values are the values currently used by the Termina- 1325 tion. ObservedEvents is as defined in Notify. 1327 The Capabilities parameter returns values such as compression algo- 1328 rithms, packetization period, connection networks that the MG is ready 1329 to support for that Termination. In addition, the option can also be 1330 used to return the Event Packages that the Termination supports, and the 1331 list of TerminationState parameter values that the MG is ready to sup- 1332 port for that Termination. 1334 The Statistics parameter returns the current state of the Termination 1335 statistics that would be generated on a Subtract. This option provides 1336 mid-call statistics. 1338 If the RequestedInfo parameter is empty, Audit returns the TerminationID 1339 only. Combining this with using null and unspecified for ContextID and 1340 wildcarding TerminationID, the Audit command can return a wide variety 1341 of information: 1343 Internet draft MEGACO Protocol April 16, 1999 1345 _________________________________________________________________________ 1346 |ContextID TerminationID Returns | 1347 |_______________________________________________________________________| 1348 |Specific all List of terminations in a Context | 1349 |Specific wildcard List of terminations in a Context, | 1350 | whose name matches the wildcard | 1351 |Null Root name Audit of MG (base state & Events) | 1352 |Null all List of all Terminations in the MG | 1353 |Null all/ List of all "highest order" Terminations | 1354 |Null wildcard List of all Terminations whose | 1355 | name matches the wildcard. | 1356 |unspecified Root name Audit of MG (null Context) | 1357 |unspecified all List of all Terminations in the MG | 1358 | and the Context[s] to which they are | 1359 | associated (maybe null) | 1360 |unspecified all/ List of all "highest order" Terminations,| 1361 | in the Context to which they are | 1362 | associated (maybe null) | 1363 |unspecified wildcard List of all Terminations whose | 1364 | name matches the wildcard, in the | 1365 | Context[s] to which they are | 1366 | associated (maybe null) | 1367 |_______________________________________________________________________| 1369 The MGC can effect a "Are you alive" poll by using the Audit command on 1370 the null Context with the Root name as the TerminationID and an empty 1371 RequestedInfo. This will result in a short response from the MG. 1373 2.3. MG-Issued Commands 1375 2.3.1. Notify 1377 Notify (TerminationId, 1378 ObservedEvents) 1380 TerminationId is the name for the Termination in the MG which is issuing 1381 the Notify command, as defined in section 2.1.2. The identifier must be 1382 a fully qualified termination identifier. The local part of the name 1383 must not use the wildcard convention. 1385 ObservedEvents is a parameter that contains a RequestIdentifier and a 1386 list of events that the MG detected in the order they have been 1387 detected. The RequestIdentifier repeats the RequestIdentifier parameter 1388 of the EventDescriptor that triggered this notification. It is used to 1389 correlate this notification with the request that triggered it. 1391 Internet draft MEGACO Protocol April 16, 1999 1393 The Events in the list must be reported in the order in which they were 1394 detected. The list may only contain the identification of Events that 1395 were requested in the RequestedEvents parameter of the triggering 1396 EventsDescriptor. It must contain the Events that were either accumu- 1397 lated (but not notified) or treated according to digit map (but no match 1398 yet), and the final Event that triggered the detection or provided a 1399 final match in the digit map. 1401 Each element in the list must contain the name of the Event, and may 1402 also contains properties associated with the Event and a notation of the 1403 time at which the Event was detected. The MG MUST NOT send an unsoli- 1404 cited notify. 1406 There is an Event defined for all MGs that can be programmed with an 1407 interval. This Event can be used for a "heart beat" notify message from 1408 MG to MGC. Use of this Event is optional by the MGC. Any message sent 1409 by the MG to the MGC restarts the timer for the Event. 1411 2.3.2. ServiceChange 1413 The ServiceChange command is used by the MG to signal that a Termina- 1414 tion, or a group of Terminations, or the entire gateway, is about to be 1415 taken out of service, or has been brought back in to service. 1417 [MGCIdentity] 1418 <------- ServiceChange ( TerminationId, 1419 ServiceChangeMethod, 1420 ServiceChangeReason, 1421 [ServiceChangeDelay]) 1423 The TerminationId identifies the Terminations that are taken in or out 1424 of service. The "all" wildcard convention may be used to apply the com- 1425 mand to a group of Terminations, such as for example all Terminations 1426 that are attached to a specified interface, or even all Terminations 1427 that are attached to a given MG. The "choose" wildcard convention shall 1428 not be used. Hierarchical names can be used to specify that an element 1429 of a MG, such as for example a digital multiplex, is being brought out 1430 of service. The Root keyword indicates the gateway itself is restart- 1431 ing. 1433 The ServiceChangeMethod parameter specifies the type of ServiceChange. 1434 Three values have been defined: 1436 * A "graceful" ServiceChange method indicates that the specified Ter- 1437 minations will Be taken out of service after the specified delay. 1438 The established connections are not yet affected, but the MGC 1439 should refrain from establishing new connections, and should try to 1441 Internet draft MEGACO Protocol April 16, 1999 1443 gracefully tear down the existing connections. If is sent with the 1444 Root TerminationID, this message indicates the MG itself will be 1445 going out of service. 1447 * A "forced" ServiceChange method indicates that the specified Termi- 1448 nations were taken abruptly out of service. The established connec- 1449 tions, if any, are lost, although the Contexts are maintained. The 1450 MGC should Subtract the Terminations which could return available 1451 statistics. If is sent with the Root TerminationID, this message 1452 indicates the MG itself is out of service. 1454 * A "Restart" method indicates that service will be restored on the 1455 Terminations after the specified ServiceChangeDelay The Termina- 1456 tions are not currently attached to any Context. If sent with the 1457 Root TerminationID, the MG is announcing its availability to the 1458 MGC. 1460 * A "Disconnected" method, always applied with the Root Termina- 1461 tionID, indicates that the MG lost communication with the MGC, but 1462 it was subsequently restored. Since MG state may have changed, the 1463 MGC may wish to use the Audit command to resynchronize its state 1464 with the MG's. 1466 ServiceChangeReason supplies the reason why the Termination is being 1467 taken out of service or brought back into service. 1469 The optional ServiceChangeDelay parameter is expressed as a number of 1470 seconds. If the number is absent, the delay value should be considered 1471 null. In the case of the "graceful" method, a null delay indicates that 1472 the MGC should simply wait for the natural termination of the existing 1473 connections, without establishing new connections. The ServiceChangeDe- 1474 lay is always considered null in the case of the "forced" method. 1476 The MGC may return an MGCIdentity parameter that describes the MGC that 1477 should preferably be contacted by the MG. In this case the MG must 1478 reissue the ServiceChange command to the new MGCIdentity 1480 The ServiceChange command specifying the Root keyword for the Termina- 1481 tionId is the registration command by which an MG announces its 1482 existence to the MGC. The MG is expected to be provisioned with the 1483 name of one primary and some number of alternate MGCs. The Servi- 1484 ceChange method shall be "forced". Acknowledgement of the ServiceChange 1485 completes the registration process. 1487 If an MG knows that a Termination is about to go out of service, it can 1488 issue a ServiceChange with ServiceChangeMethod set to "graceful", and 1489 specify a ServiceChangeDelay. If an MG has just detected that a Termina- 1490 tion or a set of Terminations has just gone out of service, it issues a 1492 Internet draft MEGACO Protocol April 16, 1999 1494 ServiceChange with ServiceChangeMethod set to "forced". 1496 An MGC may inform an MG that it should send subsequent commands to 1497 another MGC by returning the identity of a new MGC when responding to 1498 ServiceChange. The MG may need to reissue ServiceChange to the new MGC. 1500 2.4. The following table lists the defined commands, and the available 1501 input parameters. An "X" denotes the parameter is legal for the command 1503 __________________________________________________________________ 1504 __________________________________________________________________ 1505 | Add Sub Mdfy Move Audt Ntfy SvcChng| 1506 | TermID X X X X X X X | 1507 | TermState X X X X | 1508 | LocalTermDesc X X X X | 1509 | RemoteTermDesc X X X X | 1510 | EventsDesc X X X X | 1511 | SignalDesc X X X X | 1512 | DigitMapDescr X X X X | 1513 | RequestedInfo X | 1514 | ObservedEvents X | 1515 | SvcChngMethod X | 1516 | SvcChngReason X | 1517 | SvcChngDelay X | 1518 |_________________________________________________________________| 1520 3. MG-MGC Control Associations 1522 An MG is under control of (one or more) MGCs. The control association 1523 between MG and MGC is initiated at MG cold start, and announced by a 1524 ServiceChange message, but can be changed by subsequent events, such as 1525 failures or manual service events. While the protocol does not have an 1526 explicit mechanism to support multiple MGCs controlling an MG, it has 1527 been designed to support the following model, which has impacts on how 1528 protocol mechanisms are used in such a case. 1530 3.1. Multiple MGCs per MG 1532 There are several circumstances where it is desired that an MG be con- 1533 trolled by more than one MGC. One is the case where different MGCs 1534 have varying abilities, for example, one MGC may be capable of SS7 1535 interwork, another may only be capable of H.323 interwork. A physical 1536 MG may need some of it's trunks controlled by SS7, while others are con- 1537 trolled by H.323. 1539 The model supported by the protocol is statically allocated partitioning 1540 of Terminations. In this model, a physical MG can be thought of as 1542 Internet draft MEGACO Protocol April 16, 1999 1544 multiple virtual MGs, each with a non-intersecting set of Terminations. 1545 The model does not require that other resources be statically allocated, 1546 just Terminations. The mechanism for allocating Terminations to virtual 1547 MGs is a management method outside the scope of the protocol. Each of 1548 the virtual MGs appears to the MGC as a complete implementation of the 1549 MEGACOP client. 1551 In many cases, a physical MG may have only one network interface, which 1552 Must be shared across virtual MGs. In such a case, the packet/cell side 1553 Termination is shared. It should be noted however, that in use, such 1554 interfaces require an ephemeral instance of the Termination to be 1555 instantiated per flow, and thus sharing the Termination is straightfor- 1556 ward. This mechanism does lead to a complication, namely that the MG 1557 must always know which of its controlling MGCs should be notified if an 1558 event occurs on the interface. 1560 In normal operation, the MG will be instructed by the MGC to create net- 1561 work flows (if it is the originating side), or to expect flow requests 1562 (if it is the terminating side), and no confusion will arise. However, 1563 if an unexpected event occurs, the MG must know what to do. 1565 If recovering from the event requires manipulation of the interface 1566 state, there can be only one MGC who can do so. These issues are 1567 resolved by allowing any of the MGCs to create EventDescriptors to be 1568 notified of such events, but only one MGC can have read/write access to 1569 the physical interface properties; all other MGCs have read-only access. 1570 The management mechanism is used to designate which MGC has read/write 1571 capability, and is designated the Master MGC. 1573 Each virtual MG has it's own Root Termination. In most cases the values 1574 for the properties of the Root Termination are independently settable by 1575 each MGC. Where there can only be one value, the parameter is read-only 1576 to all but the Master MGC. 1578 3.2. Cold Start 1580 An MG is pre-provisioned by a management mechanism outside the scope of 1581 This protocol with a Primary and (optionally) an ordered list of Secon- 1582 dary MGCs. Upon a cold start of the MG, it will issue a ServiceChange 1583 command with a "Restart" method, on the Root Termination to it's primary 1584 MGC. If the MGC accepts the MG, it will send a Transaction Accept, with 1585 the MGCIdenty set to itself. If the MG recieves an an MGCIdentity not 1586 equal to the MGC it contacted, it sends a ServiceChange to the MGC 1587 specified in the MGCIdentity. It continues this process until it gets a 1588 controlling MGC to accept its registration, or it fails to get a reply. 1590 Internet draft MEGACO Protocol April 16, 1999 1592 3.3. Upon failure to obtain a reply, either from the Primary MGC, or a 1593 designated successor, the MG tries it's pre-provisioned Secondary MGCs, 1594 in order. 1596 3.4. Failover 1598 3.4.1. Failure of an MG 1600 If an MG fails, but is capable of sending a message to the MGC, it sends 1601 a ServiceChange with an appropriate method (graceful or forced) and 1602 specifies the root TerminationID. When it returns to service, it sends 1603 a ServiceChange with a "Restart" method. 1605 Pairs of MGs that are capable of redundant failover of one of the MGs 1606 are accommodated by allowing the MGC to send duplicate messages to both 1607 MGs. Only the Working MG must accept or reject transactions. Upon 1608 failover, the Protect MG sends a ServiceChange command with a "Failover" 1609 method and a "Failed MG" reason. The MGC then uses the Protect MG as 1610 the active MG, and only it must accept/reject transactions. When the 1611 error condition is repaired, the Working MG can send a "ServiceChange" 1612 with a "Restart" method. 1614 3.4.2. Failure of an MGC 1616 If the MG notices a failure of it's controlling MGC, it attempts to con- 1617 tact the next MGC on its pre-provisioned list. It starts it's attempts 1618 at the beginning (Primary MGC), unless that was the MGC that failed, in 1619 which case it starts at it's first Secondary MGC. It sends a Servi- 1620 ceChange message with a "Failover" method and a "Failed MGC" reason. 1622 In partial failure, or manual maintenance reasons, an MGC may wish to 1623 Direct its controlled MGs to use a different MGC. To do so, it sets the 1624 "ControllingMGC" property of the root Termination to its new MGC. As a 1625 side effect, the MG should send a ServiceChange message with a "Forced" 1626 method and a "MGC directed change" reason to the designated MGC. If it 1627 fails to get a reply, or fails to see an Audit command subsequently, it 1628 should behave as if it's MGC failed, and start contacting secondary 1629 MGCs. 1631 When the MGC initiates a failover, the handover should be transparent to 1632 Operations on the gateway. Commands in progress continue, transaction 1633 replies are sent to the new MGC, and the MG should expect outstanding 1634 transaction replies from the new MGC. All connections should stay up. 1636 It is possible that the MGC could be implemented in such a way that a 1637 failed MGC is replaced by a working MGC where the identity of the new 1638 MGC is the same as the failed one. In such a case, "ControllingMGC" 1639 would be replaced with the previous value. In such a case, the MG shall 1641 Internet draft MEGACO Protocol April 16, 1999 1643 behave as if the value was changed, and send a ServiceChange message, as 1644 above. 1646 Pairs of MGCs that are capable of redundant failover can notify the con- 1647 trolled MGs of the failover by the above mechanism. 1649 3.5. Error Codes 1651 All MEGACO Protocol commands are acknowledged. The acknowledgment car- 1652 ries a return code, which indicates the status of the command. The 1653 return code is value for which three ranges have been defined: 1655 * successful completion, 1657 * transient error, 1659 * permanent error. 1661 4. Security Considerations 1663 If unauthorized entities could use the MEGACO protocol, they would be 1664 able to set-up unauthorized calls, or to interfere with authorized 1665 calls. The primary security mechanism employed by the protocol is IPSEC 1666 [RFC2401]. Support of the AH header [RFC2402] affords authentication 1667 and integrity protection on messages passed between the MG and the MGC. 1668 Support of the ESP header [RFC2406] can provide confidentiality of mes- 1669 sages if desired. 1671 Implementation of IPSEC requires that the AH and ESP headers be inserted 1672 between the IP and UDP headers. This presents an implementation problem 1673 for MEGACO protocol implementations where the underlying network imple- 1674 mentation does not support IPSEC. As an interim solution, the MEGACO 1675 protocol defines an optional AH header within the protocol header. The 1676 header fields are exactly those of the AH header as defined in 1677 [RFC2402]. The semantics of the header fields are the same as the 1678 "transport mode" of [RFC2402], except for the calculation of the 1679 Integrity Check Value (ICV). In IPSEC, the ICV is calculated over the 1680 entire IP packet including the IP header. This prevents spoofing of the 1681 IP addresses. To retain the same functionality, the ICV calculation 1682 should be performed across the entire MEGACOP message prepended by a 1683 synthesized IP header consisting of a 32 bit source IP address, a 32 bit 1684 destination address and an 16 bit UDP port in the MSBs of a 32 bit word. 1685 The Authentication Data is assumed to be zero as in [RFC2402]. The 1686 "Next Header" and "RESERVED" fields MUST be set to "zero". 1688 The ICV calculation is thus performed over a structure that would look 1689 like: 1691 Internet draft MEGACO Protocol April 16, 1999 1693 0 1 2 3 1694 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Source IP Address | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Destination IP Address | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | UDP Port | RESERVED | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Next Header | Payload Len | RESERVED | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Security Parameters Index (SPI) | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Sequence Number Field | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | | 1709 + Authentication Data (variable) + 1710 | | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | | 1713 + message contents (variable) + 1714 | | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 When the AH-within-MEGACO mechanism is employed when TCP is the tran- 1718 sport Layer for MEGACOP, the UDP Port above becomes the TCP port, and 1719 all other operations are the same. 1721 Implementations of the MEGACO protocol using IPv4 MUST support the 1722 interim AH-within-MEGACO scheme. Implementations SHOULD implement IPSEC 1723 AH header if the underlying network system supports it. Implementations 1724 MAY support the ESP header. IPSEC and AH-within-MEGACO MUST NOT be used 1725 at the same time. IPv6 Implementations are assumed to have IPSEC imple- 1726 mentations and MUST NOT use the AH-within-MEGACO scheme. 1728 When employing the AH header, either in IPSEC or AH-within-MEGACO, all 1729 implementations of the protocol MUST implement section 5 of [RFC2402] 1730 which defines a minimum set of algorithms for integrity checking using 1731 manual keys. MECACOP implementations SHOULD implement IKE [RFC2409] to 1732 permit more robust keying options. MEGACOP implementations employing 1733 IKE SHOULD implement RSA signatures and authentication with RSA public 1734 key encryption. MECACOP implementations employing the ESP header 1735 [RFC2406] MUST implement section 6 of [RFC2406] which defines a minimum 1736 set of algorithms for integrity checking and encryption. 1738 NOTE: The AH-within-MEGACO scheme is defined as interim. The next 1740 Internet draft MEGACO Protocol April 16, 1999 1742 version of this protocol is likely to deprecate it (backwards compati- 1743 bility?). 1745 Adequate protection of the connections must be achieved if the MG and 1746 the MGC only accept messages for which authentication services of the AH 1747 header have been configured. Employing the ESP header for encryption 1748 service must provide additional protection against eavesdropping, thus 1749 forbidding third parties from monitoring the connections set up by a 1750 given Termination 1752 The encryption service should also be requested if the session descrip- 1753 tions are used to carry session keys, as defined in SDP. 1755 These procedures do not necessarily protect against denial of service 1756 attacks by misbehaving MGs or misbehaving MGCs. However, they will pro- 1757 vide an identification of these misbehaving entities, which should then 1758 be deprived of their authorization through maintenance procedures. 1760 Also note that the use of NAT (Network Address Translation) interferes 1761 with the operation IPSEC and IPSEC-like mechanisms, as they modify IP 1762 addresses and port numbers, and thus invalidate the ICV calculations. 1763 It is possible to use IPSEC between the point at which NAT is applied 1764 and the outside party. 1766 4.1. Protection of Media Connections 1768 The protocol allows the MGC to provide MGs with "session keys" that can 1769 be used to encrypt the audio messages, protecting against eavesdropping. 1771 A specific problem of packet networks is "uncontrolled barge-in." This 1772 attack can be performed by directing media packets to the IP address and 1773 UDP port used by a connection. If no protection is implemented, the 1774 packets must be decompressed and the signals must be played on the "line 1775 side". 1777 A basic protection against this attack is to only accept packets from 1778 known sources, checking for example that the IP source address and UDP 1779 source port match the values announced in the RemoteTerminationDescrip- 1780 tor But this has two inconveniences: it slows down connection establish- 1781 ment and it can be fooled by source spoofing: 1783 * To enable the address-based protection, the MGC must obtain the 1784 remote session description of the egress MG and pass it to the 1785 ingress MG. This requires at least one network roundtrip, and 1786 leaves us with a dilemma: either allow the call to proceed without 1787 waiting for the round trip to complete, and risk for example, 1788 "clipping" a remote announcement, or wait for the full roundtrip 1789 and settle for slower call-set-up procedures. 1791 Internet draft MEGACO Protocol April 16, 1999 1793 * Source spoofing is only effective if the attacker can obtain valid 1794 pairs of source destination addresses and ports, for example by 1795 listening to a fraction of the traffic. To fight source spoofing, 1796 one could try to control all access points to the network. But 1797 this is in practice very hard to achieve. 1799 An alternative to checking the source address is to encrypt and authen- 1800 ticate the packets, using a secret key that is conveyed during the call 1801 set-up procedure. This will not slow down the call set-up, and provides 1802 strong protection against address spoofing. 1804 Internet draft MEGACO Protocol April 16, 1999 1806 5. Syntax 1808 Editor's Note: In this edition of the document, a decision has not 1809 been made on the encoding of the protocol. The following EBNF 1810 description is therefore somewhat awkward. Productions with the word 1811 "Token" are not defined. In an ASCII encoding, they would typically be 1812 some kind of keyword and a separator. In a binary encoding, they would 1813 be a code. The productions use the terms "digit", as in 9DIGIT, which 1814 would be understood as a 9 character numeric string in ASCII, or a 32 bit 1815 number in binary, although there may be small differences in coding 1816 when the decision is actually made. The syntax leaves out separators and 1817 whitespace which would be necessary in an ASCII encoding. It leaves out 1818 length fields, which may be necessary in a binary encoding. 1820 megacoMessage = authenticatedMessage / message 1822 authenticatedMessage = authToken authenticationHeader message 1824 authenticationHeader = ; as defined in RFC [] 1826 message = SystemID *(transactionRequest / transactionAccept / 1827 transactionReject) 1828 ; question of whether SystemID is there at all 1829 ; Version might be in registration in msg header if here 1831 transactionRequest = transToken transactionId 1*Action 1832 transactionAccept = acceptToken transactionId 1*ActionAccept 1833 transactionReject = rejectToken transactionId 1*ActionReject 1835 ActionAccept = ctxToken contextId *commandAccept 1836 commandAccept = commandName [terminationId] *(parameters) 1838 ActionReject = ctxToken contextID *commandReject 1839 CommandReject = commandName [terminationID] errorMessage 1840 errorMessage = errorCode errorText 1841 errorCode = OCTET STRING(3) ;could be extended 1842 errorText = OCTET STRING 1844 transactionId = INTEGER32 1845 SystemId = domainName [":" portNumber] 1846 domainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821 1847 portNumber = INTEGER16 ;should this be 5digit, 16 bit? 1849 version = megacopToken Version Profile 1850 Version = OCTET STRING 1851 Profile = OCTET STRING ;need explanation 1853 Action = ctxToken contextId 1*command 1855 Internet draft MEGACO Protocol April 16, 1999 1857 contextId = nullToken / unspecifiedToken / INTEGER32 1859 command = commandName terminationId parameters 1861 commandName = (addToken / 1862 subtractToken / 1863 modifyToken / 1864 moveToken / 1865 auditToken / 1866 notifyToken / 1867 serviceChangeToken ) 1869 terminationId = "." / LocalNamePart / 1870 LocalNamePart *("/"LocalNamePart) 1872 LocalNamePart = AnyNameToken / AllNameToken / NameString 1874 AnyName = "$" 1876 AllNames = "*" 1878 NameString = 1*(SuitableCharacters) 1880 parameters = ([ TSToken TerminationState ] 1881 [LTToken LocalTerminationDescriptor ] 1882 [RTToken RemoteTerminationDescriptor ] 1883 [EDToken EventsDescriptor ] 1884 [SDToken SignalDescriptor ] 1885 [DMToken DigitMapDescriptor ] 1886 [RIToken RequestedInfo ] 1887 [RMToken ServiceChangeMethod ] 1888 [RDToken ServiceChangeDelay ] 1889 [OEToken ObservedEvents ] 1890 [STToken Statistics ] 1891 [CpToken Capabilities ] 1892 [MiToken MGCIdentity ] 1893 *[extensionParameterToken parameterValue] ]) ;fix 1894 TerminationState = stateParameter ;leftover production for bracketing 1895 stateParameter = ([modeToken TerminationMode] 1896 [bufferedEventHandlingToken BufferedEventHandling ]) 1897 ;fix, there are 2 of them 1898 TerminationMode = sendonlyToken / recvonlyToken / sendrecvToken / 1899 inactiveToken / loopbackToken / conttestToken / OutOfService 1900 BufferedEventHandling = loopControl / processControl / ;fix 1901 (loopControl processControl ) 1902 loopControl = stepToken / loopToken 1903 processControl = processToken / discardToken 1905 Internet draft MEGACO Protocol April 16, 1999 1907 LocalTerminationDescriptor = TerminationDescriptor 1908 RemoteTerminationDescriptor = TerminationDescriptor 1910 eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange) 1911 packageName = 1*(SuitableCharacters) 1912 eventId = 1*(SuitableCharacters) ;could be an Integer32 1913 EventsDescriptor = [requestedEvent 0*(requestedEvent)] 1914 requestedEvent = eventName [0*(eventParameters)] [requestedActions] 1915 eventParameters = *(parameterName parameterValue) 1916 requestId = INTEGER32 1918 eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" / 1919 (DIGIT "-" DIGIT)/(DTMFLetter "-" DTMFLetter)) "]" 1920 ;may want to remove the above 1922 requestedActions = requestedAction [ embeddedSignalEvent ] 1923 [ mediaAction ] 1924 requestedAction = NotifyActionToken / AccumlateToken / 1925 AccumulateByDigitMapToken digitMapName / 1926 ScriptToken scriptName 1927 embeddedSignalEvent = [EventDescriptorToken EventsDescriptor ] 1928 [SignalDescriptorToken SignalDescriptor ] 1929 mediaAction = SToken 1931 SignalDescriptor = [ SignalRequest 0*(SignalRequest) ] 1932 SignalRequest = eventName [eventParameters ] 1933 eventParameters = eventParameter 0*( eventParameter ) 1934 eventParameter = eventParameterString / quotedString 1935 eventParameterString = 1*() 1937 DigitMapDescriptor = digitMapName DigitMapValue 1938 digitMapName = STRING 1939 DigitMapValue = ["L:" longTimer ","] ["M:" mediumTimer ","] DigitMap 1940 longTimer = 1*2DIGIT 1941 shortTimer = 1*2DIGIT 1942 DigitMap = DigitString / "(" DigitStringList ")" 1943 DigitStringList = DigitString *( "|" StringList ) 1944 DigitString = 1*(DigitStringElement) 1945 DigitStringElement = DigitPosition ["."] 1946 DigitPosition = DigitMapLetter / DigitMapRange 1947 DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / MFSig / "T" 1948 MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3" / 1949 DigitMapRange = "x" / "[" DigitLetters "]" 1950 DigitLetter = *((DIGIT "-" DIGIT ) / DigitMapLetter) 1952 RequestedInfo = [infoCode 0*(infoCode)] 1953 infoCode = TerminationStateToken / LocalTermDescToken / RemoteTermDescToken / 1954 EventDeccToken / SignalDescToken / 1956 Internet draft MEGACO Protocol April 16, 1999 1958 DigMapToken / StatsToken / ObsrvdEvntsToken CapsToken / 1959 ServiceChangeMethod = GracefulToken / ForcedToken / RestartToken / FailoverToken 1960 ServiceChangeDelay = INTEGER32 1962 ObservedEvents = (requestId [ observedEvent *(observedEvent) ]) 1963 observedEvent = [ TimeNotation ] SignalRequest 1964 TimeNotation= INTEGER64; 64 bits NTP time stamp ? 1966 Statistics = [StatisticsParameter 0*( StatisticsParameter ) ] 1967 StatisticsParameter = ( PktsSentToken packetsSent ) 1968 / ( OctetsSentToken octetsSent ) 1969 / ( PktsRecvdToken packetsReceived ) 1970 / ( OctetsRecvdToken octetsReceived ) 1971 / ( PktsLostToken packetsLost ) 1972 / ( JitterToken jitter ) 1973 / ( AvgLatencyToken averageLatency ) 1974 / ( StatisticsParameterExtensionName 1975 StatisticsParameterExtensionValue ) 1976 packetsSent = INTEGER64 1977 octetsSent = INTEGER64 1978 packetsReceived = INTEGER64 1979 octetsReceived = INTEGER64 1980 packetsLost = INTEGER32 1981 jitter = INTEGER32 1982 averageLatency = INTEGER32 1983 StatisticsParameterExtensionName = "X" "-" 2*ALPHA ;fix 1984 StatisticsParameterExtensionValue = INTEGER32 1986 extensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT) 1987 parameterString = 1*(%x20-7F) 1989 Capabilities = ;not defined yet 1991 MGCIdentity = SystemId 1993 SuitableCharacter= DIGIT / ALPHA / "+" / "-" / "_" / "&" / 1994 "!" / "'" / "|" / "=" / "#" / "?" / "/" / 1995 "." / "$" / "*" / ";" / "@" / "[" / "]" / 1996 "^" / "`" / "{" / "}" / "~" 1997 quotedString = DQUOTE visibleString 1998 0*(quoteEscape visibleString) DQUOTE 1999 quoteEscape = DQUOTE DQUOTE 2000 visibleString = (%x00-21 / %x23-FF) 2002 TerminationDescriptor = ;Undecided, could be SDP as in RFC 2327 2004 Internet draft MEGACO Protocol April 16, 1999 2006 5.1. Termination Names 2008 Each command contains a unique Termination name. The following rules for 2009 construction and interpretation of the Termination names MUST be sup- 2010 ported: 2012 1) The individual terms of the naming path MUST be separated by a sin- 2013 gle slash ("/", ASCII 2F hex). 2015 2) The individual terms are character strings composed of letters, 2016 digits or other printable characters, with the exception of charac- 2017 ters used as delimiters ("/", "@"), characters used for wildcarding 2018 ("*", "$") and white spaces. 2020 3) Wild-carding is represented either by an asterisk ("*") or a dollar 2021 sign ("$") for the terms of the naming path which are to be wild- 2022 carded. Thus, if the full naming path looks like 2024 term1/term2/term3 2026 then the Termination name looks like this depending on which terms 2027 are wild- carded: 2029 */term2/term3 if term1 is wild-carded 2030 term1/*/term3 if term2 is wild-carded 2031 term1/term2/* if term3 is wild-carded 2032 term1/*/* if term2 and term3 are wild-carded, 2033 etc. 2035 In each of these examples a dollar sign could have appeared instead 2036 of an asterisk. 2038 4) A term represented by an asterisk is to be interpreted as: "use ALL 2039 values of this term known within the scope of the Media Gateway". 2040 A term represented by a dollar sign is to be interpreted as: "use 2041 ANY ONE value of this term known within the scope of the Media 2042 Gateway". The description of a specific command may add further 2043 criteria for selection within the general rules given here. 2045 Internet draft MEGACO Protocol April 16, 1999 2047 Examples of TerminationId: 2049 /MG7.network.com/com1/channel1 ; fully qualified Termination name 2051 ; one channel on device "com1" 2053 ; channels on device "com1" 2055 ; all devices on MG 2057 ; on all devices on MG 2059 When an Ephemeral Termination is to be created, the desired termination 2060 type is specified as the first component of the name with "/$" con- 2061 catenated on the name. For example, "RTP/$" would request a new Termi- 2062 nation from the RTP Termination Class. 2064 5.2. Events, Signals and Packages 2066 Event names are case insensitive and are composed of two logical parts, 2067 a Package name and an Event name. Both names are strings of letters, 2068 hyphens and digits, with the restriction that hyphens shall never be the 2069 first or last characters in a name. Package or Event names are not case 2070 sensitive - values such as "hu", "Hu", "HU" or "hU" should be considered 2071 equal. 2073 In textual representations, the Package name, when present, is separated 2074 from the Event name by a slash ("/"). The Package name is in fact 2075 optional. Each termination-type has a default Package associated with 2076 it, and if the Package name is excluded from the Event name, the default 2077 Package name for that termination-type is assumed. For example, for an 2078 analog access line, the following two Event names are equal: 2080 l/dl dial-tone in the line Package for an analog access line. 2082 dl dial-tone in the line Package (default) for an analog access line. 2084 This document defines a basic set of Package names and Event names. 2085 Additional Package names and Event names can be registered with the 2086 IANA. A Package definition shall define the name of the Package, and the 2087 definition of each Event belonging to the Package. The Event definition 2088 shall include the precise name of the Event (i.e., the code used in the 2089 MEGACO protocol), a plain text definition of the Event, and, went 2090 appropriate, the precise definition of the corresponding signals, for 2091 example the exact frequencies of audio signal such as dial tones or DTMF 2093 Internet draft MEGACO Protocol April 16, 1999 2095 tones. 2097 In addition, implementers can gain experience by using experimental 2098 Packages. The names of experimental Packages must start with the two 2099 characters "x-"; the IANA shall not register Package names that start 2100 with these characters. 2102 Digits, or letters, are supported in many Packages, notably "DTMF", "MF" 2103 and "pulse". Digits and letters are defined by the rules "Digit" and 2104 "Letter" in the definition of digit maps. This definition refers to the 2105 digits (0 to 9), to the asterisk or star ("*") and orthotrope, number or 2106 pound sign ("#"), and to the letters "A", "B", "C" and "D", as well as 2107 the timer indication "T". These letters can be combined in "digit 2108 string" that represent the keys that a user punched on a dial. In addi- 2109 tion, the letter "X" can be used to represent all digits, and the sign 2110 "$" can be used in wildcard notations. The need to easily express the 2111 digit strings has a consequence on the form of Event names: 2113 An Event name that does not denote a digit should always contain at 2114 least one character that is neither a digit, nor one of the letters 2115 A, B, C, D, T or X. (Such names should not contain the special 2116 signs "*", "#", "/" or "$".) 2118 An MGC may often have to ask a MG to detect a group of Events. Two con- 2119 ventions can be used to denote such groups: 2121 * The wildcard convention can be used to detect any Event belonging 2122 to a Package, or a given Event in many Packages, or Event any Event 2123 in any Package supported by the MG. 2125 * The regular expression Range notation can be used to detect a range 2126 of digits. 2128 The star sign (*) can be used as a wildcard instead of a Package name, 2129 and the dollar sign ("$") or the keyword "all" can be used as a wildcard 2130 instead of an Event name: 2132 A name such as "foo/all" denotes all Events in Package "foo" 2133 A name such as "*/bar" denotes the Event "bar" in any Package sup- 2134 ported by the MG 2135 The names "*" or "*/all" denote all Events supported by the MG. 2137 The MGC can ask an MG to detect a set of digits or letters either by 2138 individually describing those letters, or by using the "range" notation 2139 defined in the syntax of digit strings. For example, the MGC can: 2141 Use the letter "x" to denote "any letter or digit." 2142 Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound 2144 Internet draft MEGACO Protocol April 16, 1999 2146 sign. 2148 Events and Signals are described in Packages. The Package description 2149 must provide, for each Event, the following information: 2151 * The description of the Event and its purpose, which should mean the 2152 actual Signal that is generated by the client (i.e., xx ms FSK 2153 tone) as well as the resulting user observed result (i.e., MW light 2154 on/off). 2156 * The detailed characteristics of the Event, such as for example fre- 2157 quencies and amplitude of audio signals, modulations and repeti- 2158 tions, 2160 * The typical and maximum duration of the Event. 2162 Package descriptions should describe, for all Signals, their type (OO, 2163 TO, BR). They should also describe the maximum duration of the TO Sig- 2164 nals. 2166 5.3. Digit Maps 2168 A digit map is expressed using a syntax derived from the Unix system 2169 command, egrep. For example, the dial plan described above in section 2 2170 results in the following digit map: 2172 (0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) 2174 The "DigitMapValue" rule of protocol syntax describes a format that con- 2175 tains three parameters: 2177 * An optional notation of a "Long Timer," in seconds, 2179 * An optional notation of a "Medium Timer," in seconds, 2181 * The actual expression of the map. 2183 The timer parameters are optional. When they are not specified, default 2184 values are assumed. Suggested default values are 16 seconds for the 2185 long timer, 8 seconds for the medium timer. 2187 A DigitMap, according to this syntax, is defined either by a "string" or 2188 by a list of strings. Each string in the list is an alternative number- 2189 ing scheme. Each element in the string is composed of a set of string 2190 elements, each of which can optionally be followed by a repetition char- 2191 acter. The possible elements are: 2193 Internet draft MEGACO Protocol April 16, 1999 2195 * A digit, 2197 * The special characters "#" and "*" (number sign and star sign), 2199 * The letters A, B, C or D, 2201 * The symbols "K0", "K1", "K2", "S0", "S1", "S2" and "S3", which may 2202 be used in MF signalling, 2204 * A range notation such as "[0-9]" or "[0-9*#]", that would be 2205 matched by a single occurence of any letter in the range, 2207 * The character "x", that would be matched by any digit between 0 and 2208 9. 2210 Each element may be followed by the repetition symbol "." (dot), to 2211 denote a variable number of occurences of the position. 2213 A MG that detects digits, letters or timers must: 2215 1) Add the Event parameter code as a token to the end of an internal 2216 state variable called the "current dial string" 2218 2) Apply the current dial string to the digit map table, attempting a 2219 match to each regular expression in the Digit Map in lexical order 2221 3) If the result is under-qualified (partially matches at least one 2222 entry in the digit map), do nothing further. 2224 If the result matches, or is over-qualified (i.e. no further digits 2225 could possibly produce a match), notify the currently accumulated Events 2226 to the MGC, in the order in which they occurred. 2228 When an MG is unable to store a digit map, it shall return an error to 2229 the MGC. 2231 5.4. Statistics 2233 The MG may maintain statistics that describe the status of the Termina- 2234 tion. The precise properties of the statistics depends on the Class of 2235 the Termination. 2237 In the RTP Class, the some the properties are: 2239 Number of packets sent: 2240 The total number of RTP data packets transmitted by the sender 2241 since starting transmission on this connection. The count is not 2242 reset if the sender changes its synchronization source identifier 2244 Internet draft MEGACO Protocol April 16, 1999 2246 (SSRC, as defined in RTP), for example as a result of a Modify com- 2247 mand. The value is zero if the connection was set in "receive only" 2248 mode. 2250 Number of octets sent: 2251 The total number of payload octets (i.e., not including header or 2252 padding) transmitted in RTP data packets by the sender since start- 2253 ing transmission on this connection. The count is not reset if the 2254 sender changes its SSRC identifier, for example as a result of a 2255 Modify command. The value is zero if the connection was set in 2256 "receive only" mode. 2258 Number of packets received: 2259 The total number of RTP data packets received by the sender since 2260 starting reception on this connection. The count includes packets 2261 received from different SSRC, if the sender used several values. 2262 The value is zero if the connection was set in "send only" mode. 2264 Number of octets received: 2265 The total number of payload octets (i.e., not including header or 2266 padding) transmitted in RTP data packets by the sender since start- 2267 ing transmission on this connection. The count includes packets 2268 received from different SSRC, if the sender used several values. 2269 The value is zero if the connection was set in "send only" mode. 2271 Number of packets lost: 2272 The total number of RTP data packets that have been lost since the 2273 creation of the RTP connection. This number is defined to be the 2274 number of packets expected less the number of packets actually 2275 received, where the number of packets received includes any which 2276 are late or duplicates. The count includes packets received from 2277 different SSRC, if the sender used several values. Thus packets 2278 that arrive late are not counted as lost, and the loss may be nega- 2279 tive if there are duplicates. The count includes packets received 2280 from different SSRC, if the sender used several values. The number 2281 of packets expected is defined to be the extended last sequence 2282 number received, as defined next, less the initial sequence number 2283 received. The count includes packets received from different SSRC, 2284 if the sender used several values. The value is zero if the connec- 2285 tion was set in "send only" mode. This property is omitted if the 2286 connection was set in "data" mode. 2288 Interarrival jitter: 2289 An estimate of the statistical variance of the RTP data packet 2290 interarrival time measured in milliseconds and expressed as an 2291 unsigned integer. The interarrival jitter J is defined to be the 2292 mean deviation (smoothed absolute value) of the difference D in 2293 packet spacing at the receiver compared to the sender for a pair of 2295 Internet draft MEGACO Protocol April 16, 1999 2297 packets. Detailed computation algorithms are found in RFC 1889. The 2298 count includes packets received from different SSRC, if the sender 2299 used several values. The value is zero if the connection was set in 2300 "send only" mode. This property is omitted if the connection was 2301 set in "data" mode. 2303 Average transmission delay: 2304 An estimate of the network latency, expressed in milliseconds. This 2305 is the average value of the difference between the NTP timestamp 2306 indicated by the senders of the RTCP messages and the NTP timestamp 2307 of the receivers, measured when this messages are received. The 2308 average is obtained by summing all the estimates, then dividing by 2309 the number of RTCP messages that have been received. This property 2310 is omitted if the connection was set in "data" mode. 2311 When the MG's clock is not synchronized by NTP, the latency value 2312 can be computed as one half of the round trip delay, as measured 2313 through RTCP. 2314 When the MG cannot compute the one way delay or the round trip 2315 delay, the property conveys a null value. 2317 For a detailed definition of these variables, refer to RFC 1889. 2319 When the connection was set up over an ATM network, the meaning of these 2320 properties may change: 2322 Number of packets sent: 2323 The total number of ATM cells transmitted since starting transmis- 2324 sion on this connection. 2326 Number of octets sent: 2327 The total number of payload octets transmitted in ATM cells. 2329 Number of packets received: 2330 The total number of ATM cells received since starting reception on 2331 this connection. 2333 Number of octets received: 2334 The total number of payload octets received in ATM cells. 2336 Number of packets lost: 2337 Should be determined as the number of cells lost, or set to zero if 2338 the adaptation layer does not enable the MG to assess losses. 2340 Interarrival jitter: 2341 Should be understood as the interarrival jitter between ATM cells. 2343 Average transmission delay: 2344 The MG may not be able to assess this property over an ATM network. 2346 Internet draft MEGACO Protocol April 16, 1999 2348 It could simply report a null value. 2350 When the Termination is of type TDM or analog, the meaning of these pro- 2351 perties is defined as follow: 2353 Number of packets sent: 2354 Not significant. 2356 Number of octets sent: 2357 The total number of payload octets transmitted over the local con- 2358 nection. 2360 Number of packets received: 2361 Not significant. 2363 Number of octets received: 2364 The total number of payload octets received over the connection. 2366 Number of packets lost: 2367 Not significant. A value of zero is assumed. 2369 Interarrival jitter: 2370 Not significant. A value of zero is assumed. 2372 Average transmission delay: 2373 Not significant. A value of zero is assumed. 2375 5.5. Examples 2377 The following examples use, for practical reasons, a text representation 2378 of the MEGACO protocol. This representation assumes the following token 2379 definitions: 2381 __________________________________________________ 2382 | TRAN | transToken | 2383 | ACPT | acceptToken | 2384 | MEGACO | megacopToken | 2385 | CTX | ctxToken | 2386 | ADD | addToken | 2387 | SUBTRACT| subtractToken | 2388 | MODIFY | modifyToken | 2389 | TS | TSToken (TerminationState) | 2390 | LT | LTToken (LocalTerminationDescriptor) | 2391 | RT | RTToken (RemoteTerminationDescriptor)| 2392 |_________|_______________________________________| 2394 Internet draft MEGACO Protocol April 16, 1999 2396 5.5.1. Example Add transaction: 2398 TRAN 12345678 MGC1.network.com:12345 MEGACOP 1.0 2399 CTX= -1 2400 ADD= circuitgroup1/5 2401 LS= {m=recvonly 2402 } 2403 ADD= RTP/ANY 2404 LS= {m=sendrecv 2405 } 2406 LT= {v=0 2407 c=IN IP4 100.100.100.089 2408 m=audio ANY RTP/AVP 0 2409 } 2410 RT= {v=0 2411 c=IN IP4 200.200.200.133 2412 m=audio 4321 RTP/AVP 0 2413 } 2415 5.5.2. Example response to Add transaction: 2417 ACPT 12345678 MG1.network.com:12345 MEGACOP 1.0 2418 CTX= 12344321 2419 ADD= circuitgroup1/5 2420 ADD= RTP/7777 2421 LT= {v=0 2422 c=IN IP4 100.100.100.089 2423 m=audio 3456 RTP/AVP 0 2424 } 2426 5.5.3. Example Modify transaction: 2428 TRAN 12345672 MGC1.network.com:12345 MEGACOP 1.0 2429 CTX= 12344321 2430 MODIFY= circuitgroup1/5 2431 LS= {m=sendrecv 2432 } 2434 5.5.4. Example Subtract transaction: 2436 TRAN 12345673 MGC1.network.com:12345 MEGACOP 1.0 2437 CTX= 12344321 2438 SUBTRACT= circuitgroup1/5 2439 SUBTRACT= RTP/7777 2441 Internet draft MEGACO Protocol April 16, 1999 2443 5.6. Transaction Response Codes 2445 All MegacoP transactions return a transaction response code which ack- 2446 nowledges the command(s) sent and returns a code indicating the success 2447 or failure of the command. 2449 The transaction response code is an integer number, the first digit of 2450 which indicates the class of the Response Code. 2452 2xx: Success -- the transaction was successfully received, understood, and 2453 all commands were executed; 2455 4xx: Protocol reject -- the transaction received could not be understood; 2457 5xx: Execution reject -- the transaction received could not be executed; 2459 MEGACOP Transaction Response Codes are extensible. MEGACOP applica- 2460 tions are not required to understand the meaning of all registered 2461 response codes, though such understanding is obviously desirable. How- 2462 ever, applications MUST understand the class of any response code, as 2463 indicated by the first digit, and treat any unrecognized response code 2464 as being equivalent to the x00 response code of that class. 2466 5.6.1. Transaction Response Success Codes 2468 Success = "200" ; The requested transaction was executed nor- 2469 mally 2471 5.6.2. Transaction Response Reject Codes 2473 Protocol-Reject = "400" ; Bad Request 2474 Protocol-Reject = "400" ; Bad Request 2475 / "401" ; Unauthorized 2476 / "411" ; Length Required 2477 / "415" ; Incorrect identifier 2478 / "416" ; The transaction refers to an unknown ContextId 2479 / "418" ; Unsupported or unknown Package 2480 / "422" ; No such Event or signal 2481 / "423" ; Unknown action or illegal combination of actions 2482 / "425" ; Unknown TerminationID 2483 / "427" ; Missing RemoteTerminationDescriptor 2484 / "484" ; Action Incomplete 2485 / "485" ; Action Ambiguous 2487 Execution-Reject = "500" ; Internal Gateway Error 2488 / "501" ; Not Implemented 2489 / "502" ; Not ready. 2491 Internet draft MEGACO Protocol April 16, 1999 2493 / "503" ; Service Unavailable 2494 / "504" ; Gateway Time-out 2495 / "505" ; MEGACOP Version not supported 2496 / "509" ; Resource Conflict 2497 / "510" ; Insufficient resources 2498 / "512" ; Gateway unequipped to detect requested Event 2499 / "513" ; Gateway unequipped to generate requested Signals 2500 / "514" ; Gateway cannot send the specified announcement 2501 / "515" ; Unsupported Media Type 2502 / "517" ; Unsupported or invalid mode 2503 / "519" ; Gateway does not have a digit map 2504 / "520" ; Termination is "ServiceChangeing" 2505 / "526" ; Insufficient bandwidth 2506 / "581" ; Does Not Exist 2508 6. Transport 2510 The transport mechanism for MEGACOP has not been chosen. It is likely 2511 that TCP will be an option. If the SIGTRAN transport mechanism is suit- 2512 able for MEGACO, that may be specified. It may be necessary to specify 2513 a transport protocol in this specification. Either the SIGTRAN mechan- 2514 ism or a MEGACO specified mechanism will be optional on the MG and 2515 required on the MGC. 2517 6.1. Transport capabilities, and relationship to Transport Layer 2519 Requirements for transport of the MEGACO protocol include: 2521 1) Reliable delivery of commands/responses. 2523 2) Ordered delivery of commands/responses to a particular "control 2524 stream", this implies ordered delivery of commands to/from a par- 2525 ticular Termination or Context, but not necessarily ordered 2526 across Terminations or Contexts. 2528 3) Limited maximum time to deliver commands. 2530 4) Rapid detection of failure in a control stream. 2532 5) Ability to achieve very high fanout from MGC to MGs. 2534 6) Ability to handle multiple MGCs controlling individual MGs in a 2535 distributed system and vice versa. However this must be optional 2536 so that smaller/simpler systems can be efficiently implemented. 2538 7) Ability for the application to initiate flushing of messages 2540 Internet draft MEGACO Protocol April 16, 1999 2542 successfully sent through the transport, for example to back off 2543 for failover handling. 2545 Since transport needs are the same in all application states and 2546 independent of what particular commands are being sent, it is logical to 2547 think of the reliable transport as a separate layer, as shown below. 2548 However, there is no accepted IETF protocol which focuses on the needs 2549 of real time control as is needed by the MEGACO protocol. Therefore, the 2550 mechanisms to provide the required characteristics of the reliable tran- 2551 sport should be directly included in the MEGACO protocol layer. However, 2552 It might be desirable to standardize the transport interface (marked in 2553 the figure by - . - . - ). This is discussed in section [4.z.z]. 2555 MEGACO Protocol layer: 2556 Gateway control | Termination-related signalling 2557 - . - . - . - . - . - . - . - . - . - . - . - . - 2558 Reliable transport 2559 ------------------------------------------------- 2560 UDP 2561 ------------------------------------------------- 2562 IP 2563 ------------------------------------------------- 2564 Ethernet, ATM, SONET, ... 2566 Any message goes between one MG and one MGC. This has implications on 2567 MG or MGC "farms". 2569 7. Event Packages and Termination Classes 2571 Termination Classes are defined by: 2573 * A plain text description of the purpose of the Termination Class, 2575 * An SDP profile describing which SDP attributes are used in the the 2576 Local and Remote Termination descriptors, 2578 * A default value for the Local and Remote Termination descriptions, 2580 * The definition of statistics that can be collected on the Termina- 2581 tion, 2583 * A list of Events and Signals that are defined for the Termination, 2585 The Events and Signals are grouped in "Event Packages", some of which 2586 may apply to different Termination Classes. The list of Events and Sig- 2587 nals applicable for a Termination Class must thus be defined by the list 2588 of applicable Event Packages. 2590 Internet draft MEGACO Protocol April 16, 1999 2592 In this section, we will describe the most common Event Packages, and 2593 then the most common Termination Classes. More Packages and Classes can 2594 be defined in additional documents. 2596 7.1. Basic Event Packages 2598 The list of basic Event Packages includes the following: 2600 _________________________________________ 2601 | Package | name | 2602 |______________________________|_________| 2603 | Generic Media Package | G | 2604 | DTMF Package | D | 2605 | MF Package | M | 2606 | Trunk Package | T | 2607 | Line Package | L | 2608 | Handset Package | H | 2609 | RTP Package | R | 2610 | Network Access Server Package| N | 2611 | Announcement Server Package | A | 2612 | Script Package | Script| 2613 |______________________________|_________| 2615 In the tables of Events for each Package, there are five columns: 2616 Symbol: the unique symbol used for the Event 2617 Definition: a short description of the Event 2619 R: an x appears in this column is the Event can be Requested by 2620 the call agent. 2622 S: if nothing appears in this column for an Event, then the Event 2623 cannot be signaled on command by the call agent. Otherwise, 2624 the following symbols identify the type of Event: 2626 OO On/Off Signal. The Signal is turned on until commanded 2627 by the call agent to turn it off, and vice versa. 2629 TO Timeout Signal. The Signal lasts for a given duration 2630 unless it is superseded by a new Signal. 2632 BR Brief Signal. The Event has a short, known duration. 2634 Duration: specifies the duration of TO Signals. 2636 7.1.1. Generic Media Event Package 2638 Package Name: G 2640 Internet draft MEGACO Protocol April 16, 1999 2642 The generic media Package group the Events and Signals that can be 2643 observed on several types of Terminations, such as trunking gateways, 2644 access gateways or residential gateways. 2646 ______________________________________________________________________ 2647 | Symbol | Definition | R | S Duration | 2648 |__________|_____________________________|_____|______________________| 2649 | mt | Modem detected | x | | 2650 | fn | CalliNg Fax tone detected | x | | 2651 | fd | CalleD Fax tone detected | x | | 2652 | ld | Long duration connection | x | | 2653 | pat(###) | Pattern ### detected | x | OO | 2654 | rt | Ringback tone | | TO | 2655 | rbk(###) | ring back on connection | | TO 180 seconds | 2656 | cf | Confirm tone | | BR | 2657 | cg | Network Congestion tone | | TO | 2658 | it | Intercept tone | | OO | 2659 | pt | Preemption tone | | OO | 2660 | of | report failure | x | | 2661 |__________|_____________________________|_____|______________________| 2663 The Signals are defined as follow: 2665 The pattern definition can be used for specific algorithms such as 2666 answering machine detection, tone detection, and the like. 2668 Ring back tone (rt) 2669 an Audible Ring Tone, a combination of two AC tones with frequen- 2670 cies of 440 and 480 Hertz and levels of -19 dBm each, to give a 2671 combined level of -16 dBm. The cadence for Audible Ring Tone is 2 2672 seconds on followed by 4 seconds off. See GR- 506-CORE - LSSGR: 2673 SIGNALING, Section 17.2.5. 2675 Ring back on connection 2676 A ring back tone, applied to the connection whose identifier is 2677 passed as a property. 2679 The "long duration connection" is detected when a connection has been 2680 established for more than 1 hour. 2682 7.1.2. DTMF Event Package 2684 Package name: D 2686 Internet draft MEGACO Protocol April 16, 1999 2688 _______________________________________________________________ 2689 | Symbol | Definition | R | S Duration | 2690 |________|___________________________|_____|___________________| 2691 | 0 | DTMF 0 | x | BR | 2692 | 1 | DTMF 1 | x | BR | 2693 | 2 | DTMF 2 | x | BR | 2694 | 3 | DTMF 3 | x | BR | 2695 | 4 | DTMF 4 | x | BR | 2696 | 5 | DTMF 5 | x | BR | 2697 | 6 | DTMF 6 | x | BR | 2698 | 7 | DTMF 7 | x | BR | 2699 | 8 | DTMF 8 | x | BR | 2700 | 9 | DTMF 9 | x | BR | 2701 | # | DTMF # | x | BR | 2702 | * | DTMF * | x | BR | 2703 | A | DTMF A | x | BR | 2704 | B | DTMF B | x | BR | 2705 | C | DTMF C | x | BR | 2706 | D | DTMF D | x | BR | 2707 | L | long duration indicator | x | 2 seconds| 2708 | X | Wildcard, match | x | | 2709 | | any digit 0-9 | | | 2710 | T | Interdigit timer | x | 4 seconds| 2711 | of | report failure | x | | 2712 |________|___________________________|_____|___________________| 2714 The "interdigit timer" occurs when a long delay is observed after the 2715 end of a digit detection. The Event can only be observed if the Termi- 2716 nation is trying to acquire digits. Note that the definition of this 2717 timer requires further study. In fact, the timer should take two dif- 2718 ferent values, depending of the digit map and the digit string: 2720 - If the gateway can determine that at least one more digit is 2721 requested for the digit string to match any of the allowed patterns 2722 in the digit map, then the timer value should be set to a long 2723 duration, such as 16 seconds. 2725 - If the digit map specifies that a variable number of additional 2726 digits may be needed (the "." indication at the end of a string), 2727 then the timer value should be set to a medium duration, such as 8 2728 seconds. 2730 - In some rare cases, such as optional additional digits, the timer 2731 should be set to a short duration, 4 seconds. The current digit 2732 map syntax does not allow for a distinction between the "medium" 2733 and "short" timer conditions, which implies that, in the current 2734 version, there is no way to request a short timer. 2736 Internet draft MEGACO Protocol April 16, 1999 2738 The "long duration indicator" is observed when a DTMF signal is produced 2739 for a duration larger than two seconds. In this case, the gateway will 2740 detect two successive Events: first, when the Signal has been recog- 2741 nized, the DTMF signal, and then, 2 seconds later, the long duration 2742 signal. 2744 Internet draft MEGACO Protocol April 16, 1999 2746 7.1.3. MF Event Package 2748 Package Name: M 2750 ________________________________________________________ 2751 | Symbol | Definition | R | S Duration | 2752 |________|____________________|_____|___________________| 2753 | 0 | MF 0 | x | BR | 2754 | 1 | MF 1 | x | BR | 2755 | 2 | MF 2 | x | BR | 2756 | 3 | MF 3 | x | BR | 2757 | 4 | MF 4 | x | BR | 2758 | 5 | MF 5 | x | BR | 2759 | 6 | MF 6 | x | BR | 2760 | 7 | MF 7 | x | BR | 2761 | 8 | MF 8 | x | BR | 2762 | 9 | MF 9 | x | BR | 2763 | X | Wildcard, match | x | | 2764 | | any digit 0-9 | | | 2765 | T | Interdigit timer | x | 4 seconds| 2766 | K0 | MF K0 or KP | x | BR | 2767 | K1 | MF K1 | x | BR | 2768 | K2 | MF K2 | x | BR | 2769 | S0 | MF S0 or ST | x | BR | 2770 | S1 | MF S1 | x | BR | 2771 | S2 | MF S2 | x | BR | 2772 | S3 | MF S3 | x | BR | 2773 | wk | Wink | x | BR | 2774 | wko | Wink off | x | BR | 2775 | is | Incoming seizure | x | OO | 2776 | rs | Return seizure | x | OO | 2777 | us | Unseize circuit | x | OO | 2778 | of | report failure | x | | 2779 |________|____________________|_____|___________________| 2781 The definition of the MF Package Events is as follow: 2783 Wink 2784 A transition from unseized to seized to unseized trunk states 2785 within a specified period. Typical seizure period is 100-350 2786 msec.) 2788 Incoming seizure 2789 Incoming indication of call attempt. 2791 Return seizure: 2792 Seizure in response to outgoing seizure. 2794 Internet draft MEGACO Protocol April 16, 1999 2796 Unseize circuit: 2797 Unseizure of a circuit at the end of a call. 2799 Wink off: 2800 A Signal used in operator services trunks. A transition from 2801 seized to unseized to seized trunk states within a specified period 2802 of 100-350 ms. (To be checked) 2804 7.1.4. Trunk Event Package 2806 Package Name: T 2808 _____________________________________________________________________ 2809 | Symbol | Definition | R | S Duration | 2810 |________|________________________________|_____|____________________| 2811 | co1 | Continuity tone (single tone,| x | OO | 2812 | | or return tone) | | | 2813 | co2 | Continuity test (go tone, | x | OO | 2814 | | in dual tone procedures) | | | 2815 | lb | Loopback | | OO | 2816 | om | Old Milliwatt Tone (1000 Hz) | x | OO | 2817 | nm | New Milliwatt Tone (1004 Hz) | x | OO | 2818 | tl | Test Line | x | OO | 2819 | zz | No circuit | x | OO | 2820 | as | Answer Supervision | x | OO | 2821 | ro | Reorder Tone | x | TO 30 seconds| 2822 | of | report failure | x | | 2823 |________|________________________________|_____|____________________| 2825 The definition of the trunk Package Signal Events is as follow: 2827 Continuity Tone (co1): 2828 A tone at 2010 + or - 30 Hz. 2830 Continuity Test (co2): 2831 A tone at the 1780 + or - 30 Hz. 2833 Milliwatt Tones: 2834 Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz) 2836 Line Test: 2837 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0 2838 + or -- 0.5dB). 2840 No circuit: 2841 (that annoying tri-tone, low to high) 2843 Internet draft MEGACO Protocol April 16, 1999 2845 Answer Supervision: 2847 Reorder Tone: 2848 Reorder tone is a combination of two AC tones with frequencies of 2849 480 and 620 Hertz and levels of -24 dBm each, to give a combined 2850 level of -21 dBm. The cadence for Station Busy Tone is 0.25 2851 seconds on followed by 0.25 seconds off, repeating continuously. 2852 See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7. 2854 The continuity tones are used when the call agent wants to initiate a 2855 continuity test. There are two types of tests, single tone and dual 2856 tone. The Call agent is expected to know, through provisioning informa- 2857 tion, which test should be applied to a given Termination. For example, 2858 the controller that wants to initiate a single frequency test will send 2859 to the gateway a command of the form: 2861 RQNT 1234 epx-t1/17@tgw2.example.net 2862 X: AB123FE0 2863 S: co1 2864 R: co1 2866 If it wanted instead to initiate a dual-tone test, it would send the 2867 command: 2869 RQNT 1234 epx-t1/17@tgw2.example.net 2870 X: AB123FE0 2871 S: co2 2872 R: co1 2874 The gateway would send the requested signal, and in both cases would 2875 look for the return of the 2010 Hz tone (co1). When it detects that 2876 tone, it must send the corresponding notification. 2878 The tones are of type OO: the gateway must keep sending them until it 2879 receives a new notification request. 2881 7.1.5. Line Event Package 2883 Package Name: L 2885 Internet draft MEGACO Protocol April 16, 1999 2887 __________________________________________________________________________ 2888 |Symbol | Definition | R | S Duration | 2889 |_____________|______________________________|_____|_____________________| 2890 |adsi(string) | adsi display | | BR | 2891 |vmwi | visual message | | TO | 2892 | | waiting indicator | | | 2893 |hd | Off hook transition | x | | 2894 |hu | On hook transition | x | | 2895 |hf | Flash hook | x | | 2896 |aw | Answer tone | x | OO | 2897 |bz | Busy tone | | TO 30 seconds | 2898 |ci(string) | Caller-id | | BR | 2899 |wt | Call Waiting tone | | TO 30 seconds | 2900 |dl | Dial tone | | TO 16 seconds | 2901 |mwi | Message waiting ind. | | TO 16 seconds | 2902 |nbz | Network busy | x | OO | 2903 | | (fast cycle busy) | | | 2904 |rg | Ringing | | TO 180 seconds| 2905 |r0, r1, r2, | Distinctive ringing | | TO 180 seconds| 2906 |r3, r4, r5, | | | | 2907 |r6 or r7 | | | | 2908 |rs | Ringsplash | | BR | 2909 |p | Prompt tone | x | BR | 2910 |e | Error tone | x | BR | 2911 |sdl | Stutter dialtone | | TO 16 seconds | 2912 |v | Alerting Tone | | OO | 2913 |y | Recorder Warning Tone | | OO | 2914 |sit | SIT tone | | | 2915 |z | Calling Card Service Tone | | OO | 2916 |oc | Report on completion | x | | 2917 |ot | Off hook warning tone | | TO indefinite | 2918 |s(###) | Distinctive tone pattern | x | BR | 2919 |of | report failure | x | | 2920 |_____________|______________________________|_____|_____________________| 2922 The definition of the tones is as follow: 2924 Dial tone: 2925 A combined 350 + 440 Hz tone. 2927 Visual Message Waiting Indicator 2928 The transmission of the VMWI messages must conform to the require- 2929 ments in Section 2.3.2, "On-hook Data Transmission Not Associated 2930 with Ringing" in TR-H- 000030 and the CPE guidelines in SR-TSV- 2931 002476. VMWI messages must only be sent from the SPCS when the line 2932 is idle. If new messages arrive while the line is busy, the VMWI 2933 indicator message must be delayed until the line goes back to the 2935 Internet draft MEGACO Protocol April 16, 1999 2937 idle state. The CA should periodically refresh the CPE's visual 2938 indicator. See TR-NWT-001401 - Visual Message Waiting Indicator 2939 Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission 2940 Interface. 2942 Message waiting Indicator 2943 See GR-506-CORE, 17.2.3. 2945 Alerting Tone: 2946 a 440 Hz Tone of 2 second duration followed by 1/2 second of tone 2947 every 10 seconds. 2949 Rig splash 2950 Ringsplash, also known as "Reminder ring" is a burst of ringing 2951 that may be applied to the physical forwarding line (when idle) to 2952 indicate that a call has been forwarded and to remind the user that 2953 a CF subfeature is active. In the US, it is defined to be a 0.5(- 2954 0,+0.1) second burst of power ringing. See TR- TSY-000586 - Call 2955 Forwarding Subfeatures. 2957 Call waiting tone 2958 Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting 2959 feature is defined in TR-TSY-000571. By defining "wt" as a TO Sig- 2960 nal you are really defining the feature which seems wrong to me 2961 (given the spirit of MGCP), hence the definition of "wt" as a BR 2962 Signal in ECS, per GR-506-CORE. Also, it turns out that there is 2963 actually four different call waiting tone patterns (see GR-506- 2964 CORE, 14.2) so we should really have wt1, wt2, wt3, wt4, or some 2965 parameterization. 2967 Recorder Warning Tone: 2968 1400 Hz of Tone of 0.5 second duration every 15 seconds. 2970 SIT tone: 2971 used for indicating a line is out of service. 2973 Calling Card Service Tone: 2974 60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone), 2975 decaying exponentially with a time constant of 200 ms. 2977 Distinctive tone pattern: 2978 where ### is any number between 000 and 999, inclusive. Can be 2979 used for distinctive ringing, customized dial tone, etc. 2981 Report on completion 2982 The report on completion Event is detected when the gateway was 2983 asked to perform one or several Signals of type TO on the Termina- 2984 tion, and when these Signals were completed without being stopped 2986 Internet draft MEGACO Protocol April 16, 1999 2988 by the detection of a requested Event such as off-hook transition 2989 or dialed digit. The completion report may carry as property the 2990 name of the Signal that came to the end of its live time, as in: 2992 O: L/oc(L/dl) 2994 Ring back on connection 2995 A ring back tone, applied to the connection whose identifier is 2996 passed as a property. 2998 We should note that many of these definitions vary from country to coun- 2999 try. The frequencies listed above are the one in use in North America. 3000 There is a need to accommodate different tone sets in different coun- 3001 tries, and there is still an ongoing debate on the best way to meet that 3002 requirement: 3004 * One solution is to define different Event Packages specifying for 3005 example the German dial-tone as "L-DE/DL". 3007 * Another solution is to use a management interface to specify on an 3008 end-point basis which frequency shall be associated to what tone. 3010 Internet draft MEGACO Protocol April 16, 1999 3012 7.1.6. Handset emulation Event Package 3014 Package Name: H 3016 __________________________________________________________________________ 3017 |Symbol | Definition | R | S Duration | 3018 |_____________|______________________________|_____|_____________________| 3019 |adsi(string) | adsi display | x | BR | 3020 |tdd | | | | 3021 |vmwi | | | | 3022 |hd | Off hook transition | x | OO | 3023 |hu | On hook transition | x | OO | 3024 |hf | Flash hook | x | BR | 3025 |aw | Answer tone | x | OO | 3026 |bz | Busy tone | x | OO | 3027 |wt | Call Waiting tone | x | TO 30 seconds | 3028 |dl | Dial tone (350 + 440 Hz) | x | TO 120 seconds| 3029 |nbz | Network busy | x | OO | 3030 | | (fast cycle busy) | | | 3031 |rg | Ringing | x | TO 30 seconds | 3032 |r0, r1, r2, | Distinctive ringing | x | TO 30 seconds | 3033 |r3, r4, r5, | | | | 3034 |r6 or r7 | | | | 3035 |p | Prompt tone | x | BR | 3036 |e | Error tone | x | BR | 3037 |sdl | Stutter dialtone | x | TO 16 seconds | 3038 |v | Alerting Tone | x | OO | 3039 |y | Recorder Warning Tone | x | OO | 3040 |t | SIT tone | x | | 3041 |z | Calling Card Service Tone | x | OO | 3042 |oc | Report on completion | x | | 3043 |ot | Off hook warning tone | x | OO | 3044 |s(###) | Distinctive tone pattern | x | BR | 3045 |of | report failure | x | | 3046 |_____________|______________________________|_____|_____________________| 3048 The handset emulation Package is an extension of the line Package, to be 3049 used when the gateway is capable of emulating a handset. The difference 3050 with the line Package is that Events such as "off hook" can be signalled 3051 as well as detected. 3053 Internet draft MEGACO Protocol April 16, 1999 3055 7.1.7. RTP Event Package 3057 Package Name: R 3059 _________________________________________________________________ 3060 | Symbol | Definition | R | S Duration| 3061 |_________|______________________________|_____|_________________| 3062 | UC | Used codec changed | x | | 3063 | SR(###) | Sampling rate changed | x | | 3064 | JI(###) | Jitter buffer size changed | x | | 3065 | PL(###) | Packet loss exceeded | x | | 3066 | qa | Quality alert | x | | 3067 | of | report failure | x | | 3068 |_________|______________________________|_____|_________________| 3070 Codec Changed: 3071 Codec changed to hexadecimal codec number enclosed in parenthesis, 3072 as in UC(15), to indicate the codec was changed to PCM mu-law. 3073 Codec Numbers are specified in RFC 1890, or in a new definition of 3074 the audio profiles for RTP that replaces this RFC. Some implemen- 3075 tations of media gateways may not allow the codec to be changed 3076 upon command from the call agent. codec changed to codec hexade- 3077 cimal ##. 3079 Sampling Rate Changed: 3080 Sampling rate changed to decimal number in milliseconds enclosed in 3081 parenthesis, as in SR(20), to indicate the sampling rate was 3082 changed to 20 milliseconds. Some implementations of media gateways 3083 may not allow the sampling rate to be changed upon command from a 3084 call agent. 3086 Jitter Buffer Size Changed: 3087 When the media gateway has the ability to automatically adjust the 3088 depth of the jitter buffer for received RTP streams, it is useful 3089 for the media gateway controller to receive notification that the 3090 media gateway has automatically increased its jitter buffer size to 3091 accommodate increased or decreased variability in network latency. 3092 The syntax for requesting notification is "JI", which tells the 3093 media gateway that the controller wants notification of any jitter 3094 buffer size changes. The syntax for notification from the media 3095 gateway to the controller is "JI(####)", where the #### is the new 3096 size of the jitter buffer, in milliseconds. 3098 Packet Loss Exceeded: 3099 Packet loss rate exceed the threshold of the specified decimal 3100 number of packets per 100,000 packets, where the packet loss number 3101 is contained in parenthesis. For example, PL(10) indicates packets 3103 Internet draft MEGACO Protocol April 16, 1999 3105 are being dropped at a rate of 1 in 10,000 packets. 3107 Quality alert 3108 The packet loss rate or the combination of delay and jitter exceed 3109 a specified quality threshold. 3111 7.1.8. Network Access Server Event Package 3113 Package Name: N 3115 ____________________________________________________________ 3116 | Symbol | Definition | R | S Duration| 3117 |________|__________________________|_____|_________________| 3118 | pa | Packet arrival | x | | 3119 | cbk | Call back request | x | | 3120 | cl | Carrier lost | x | | 3121 | au | Authorization succeeded| x | | 3122 | ax | Authorization denied | x | | 3123 | of | Report failure | x | | 3124 |________|__________________________|_____|_________________| 3126 The packet arrival Event is used to notify that at least one packet was 3127 recently sent to an Internet address that is observed by an Termination. 3128 The Event report includes the Internet address, in standard ASCII encod- 3129 ing, between parenthesis: 3131 O: pa(192.96.41.1) 3133 The call back Event is used to notify that a call back has been 3134 requested during the initial phase of a data connection. The Event 3135 report includes the identification of the user that should be called 3136 back, between parenthesis: 3138 O: cbk(user25) 3140 Internet draft MEGACO Protocol April 16, 1999 3142 7.1.9. Announcement Server Event Package 3144 Package Name: A 3146 ___________________________________________________________________ 3147 | Symbol | Definition | R | S Duration| 3148 |________________|________________________|_____|__________________| 3149 | ann(url,parms) | Play an announcement | | TO variable| 3150 | oc | Report on completion | x | | 3151 | of | Report failure | x | | 3152 |________________|________________________|_____|__________________| 3154 The announcement action is qualified by an URL name and by a set of ini- 3155 tial properties as in for example: 3157 S: ann(http://scripts.example.net/all-lines-busy.au) 3159 The "operation complete" Event must be detected when the announcement is 3160 played out. If the announcement cannot be played out, an operation 3161 failure Event can be returned. The failure may be explained by a com- 3162 mentary, as in: 3164 O: A/of(file not found) 3166 Internet draft MEGACO Protocol April 16, 1999 3168 7.1.10. Script Event Package 3170 Package Name: Script 3172 ______________________________________________________________ 3173 | Symbol | Definition | R | S | Duration| 3174 |___________|________________________|_____|______|___________| 3175 | java(url) | Load a java script | | TO | variable| 3176 | perl(url) | Load a perl script | | TO | variable| 3177 | tcl(url) | Load a TCL script | | TO | variable| 3178 | xml(url) | Load an XML script | | TO | variable| 3179 | oc | Report on completion | x | | | 3180 | of | Report failure | x | | | 3181 |___________|________________________|_____|______|___________| 3183 The "language" action define is qualified by an URL name and by a set of 3184 initial properties as in for example: 3186 S: script/java(http://scripts.example.net/credit-card.java,long,1234) 3188 The current definition defines keywords for the most common languages. 3189 More languages may be defined in further version of this documents. For 3190 each language, an API specification must describe how the scripts can 3191 issue local "notificationRequest" commands, and receive the correspond- 3192 ing notifications. 3194 The script produces an output which consists of one or several text 3195 string, separated by commas. The text string are reported as a commen- 3196 tary in the report on completion, as in for example: 3198 O: script/oc(21223456794567,9738234567) 3200 The failure report may also return a string, as in: 3202 O: script/oc(21223456794567,9738234567) 3204 The definition of the script environment and the specific actions in 3205 that environment are for further study. 3207 Internet draft MEGACO Protocol April 16, 1999 3209 7.2. Basic Termination Classes 3211 We define the following basic Termination types and profiles: 3213 * DS0 Termination, 3215 * Analog Termination, 3217 * RTP Termination, 3219 * ATM Termination, 3221 * Network Access Termination. 3223 Editors' note: These are only the most basic Termination types. There is 3224 an obvious need to also define digital multiplexes (T1, E1, T3, E3) and 3225 the Events that they support. 3227 7.2.1. DS0 Terminations 3229 DS0 Terminations are digital circuits, providing a 64kbits (8bit times 8 3230 KHz) service. Such Terminations are commonly used for interoffice 3231 trunks. 3233 DS0 Terminations are always described in a symmetric fashion. The 3234 RemoteTerminationDescriptor parameter is never used. 3236 The LocalTerminationDescriptor may be used to specify the encoding of 3237 the media. This parameter is described using SDP, with the following 3238 conventions: 3240 * The connection data line is not used. A placeholder (c=LOCAL) can 3241 be used if this is required for compliance with the SDP syntax. 3243 * The "m=audio" property must specify a port number, which must 3244 always be set to 0, the type of protocol, always set to the keyword 3245 DS0, and the type of encoding, using the same conventions used for 3246 RTP (RTP payload numbers.) The type of encoding should normally be 3247 set to 0 (PCM, mu law) or to 8 (PCM, A law). 3249 * The "a=echo" attribute must specify whether the gateway performs 3250 echo cancellation. The property can have two values, "a:echo:on" 3251 (when the echo cancellation is requested) and "a:echo:off" (when it 3252 is turned off.) 3254 * The gain control attribute, encoded as the keyword "gc", followed 3255 by a colon a value which can be either the keyword "auto" or a 3256 decimal number (positive or negative) representing the number of 3258 Internet draft MEGACO Protocol April 16, 1999 3260 decibels of gain. 3262 An example of specification could be: 3264 v=0 3265 c=LOCAL 3266 m=audio 0 DS0 0 3267 a=echo:on 3269 The default configuration option is to use the mu-law encoding, with 3270 gain control set to auto, and to apply echo cancellation. (We could 3271 define a variant of the DS0 Class which would, by default, use A-law 3272 encoding.) 3274 Gateways are expected to be able to collect the following statistics on 3275 Terminations of the DS0 Class: 3277 Number of octets sent, number of octets received 3278 The number of octet sent or received is equal to the duration of 3279 the Termination, in seconds, multiplied by the sampling frequency, 3280 8000 Hz. 3282 Terminations of the DS0 Class are expected to provide the following sup- 3283 port for Event Packages: 3285 _______________________________________________________________________ 3286 |Package | name | support in DS0 Class | 3287 |______________________|__________|___________________________________| 3288 |Generic Media Package | G | Mandatory | 3289 |Trunk Package | T | Mandatory | 3290 |DTMF Package | D | Optional (for credit cards, etc)| 3291 |MF Package | M | Optional (for MF trunks) | 3292 |Announcement | A | Optional (when gateway | 3293 |Server Package | | can play announcement on DS0) | 3294 |Script Package | Script | Optional | 3295 |______________________|__________|___________________________________| 3297 7.2.2. Analog Terminations 3299 Analog terminations are analog circuits, typically connected through an 3300 RJ11 interface. Such Terminations are commonly found in residential 3301 gateways. 3303 Analog Terminations are always described in a symmetric fashion. The 3304 RemoteTerminationDescriptor parameter is never used. 3306 Internet draft MEGACO Protocol April 16, 1999 3308 The LocalTerminationDescriptor may be used to specify the encoding of 3309 the media. This parameter is described using SDP, with the following 3310 conventions: 3312 * The connection data line is not used. A placeholder (c=LOCAL) can 3313 be used if this is required for compliance with the SDP syntax. 3315 * The "m=audio" property is only used for conformance with the SDP 3316 syntax. It is set to a conventional value, specifying a null port, 3317 an ANALOG type and a null type of encoding. 3319 * The "a=echo" attribute must specify whether the gateway performs 3320 echo cancellation. The property can have two values, "a:echo:on" 3321 (when the echo cancellation is requested) and "a:echo:off" (when it 3322 is turned off.) 3324 * The gain control attribute, encoded as the keyword "gc", followed 3325 by a colon a value which can be either the keyword "auto" or a 3326 decimal number (positive or negative) representing the number of 3327 decibels of gain. 3329 An example of specification could be: 3331 v=0 3332 c=LOCAL 3333 m=audio 0 ANALOG 0 3334 a=echo:on 3336 The default configuration option is to apply echo cancellation, and to 3337 have gain control set to auto. 3339 Gateways are expected to be able to collect the following statistics on 3340 Terminations of the analog Class: 3342 Number of octets sent, number of octets received 3343 The number of octet sent or received is equal to the duration of 3344 the Termination, in seconds, multiplied by the sampling frequency, 3345 8000 Hz. 3347 Terminations of the analog Class are expected to provide the following 3348 support for Event Packages: 3350 Internet draft MEGACO Protocol April 16, 1999 3352 ____________________________________________________________________ 3353 | Package | name | support in analog Class | 3354 |_______________________|__________|________________________________| 3355 | Generic Media Package | G | Mandatory | 3356 | DTMF Package | D | Mandatory | 3357 | Line Package | L | Mandatory | 3358 | Handset Package | H | Optional (when gateway | 3359 | | | can set outgoing calls on | 3360 | | | the analog Termination) | 3361 | Announcement | A | Optional (when gateway | 3362 | Server Package | | can play announcements on the| 3363 | | | Termination) | 3364 | Script Package | Script | Optional | 3365 |_______________________|__________|________________________________| 3367 7.2.3. RTP Audio Terminations 3369 RTP Terminations are use to describe the local Termination of packet 3370 connections established through the RTP, UDP and IP protocols. The RTP 3371 Audio Termination Class is applied when the RTP Terminations convey an 3372 audio media. (Other Termination Classes may be used for other media, 3373 such as video.) 3375 The encoding of the media in point to point RTP Terminations is 3376 described by two sets of properties, the LocalTerminationDescriptor and 3377 the RemoteTerminationDescriptor. Both are described using SDP, with the 3378 following conventions: 3380 * The IP address of the remote gateway (in commands) or of the local 3381 gateway (in responses), or multicast address of the audio confer- 3382 ence, encoded as an SDP "connection data" parameter. This parameter 3383 specifies the IP address that must be used to exchange RTP packets. 3385 * Media description field (m) specifying the audio media, the tran- 3386 sport port used for receiving RTP packets by the remote gateway 3387 (commands) or by the local gateway (responses) , the RTP/AVP tran- 3388 sport, and the list of formats that the gateway must accept. This 3389 list should normally always include the code 0 (reserved for G.711, 3390 mu law). 3392 * Optionally, RTPMAP attributes that define the encoding of dynamic 3393 audio formats, 3395 * Optionally, a packetization period (packet time) attribute (Ptime) 3396 defining the duration of the packet, 3398 * Optionally, an encryption key attribute ("k"), specifying the 3400 Internet draft MEGACO Protocol April 16, 1999 3402 encryption and the key for the RTP packets, as defined in SDP. 3404 * Optionally, an attribute defining the type of connection (sendonly, 3405 recvonly, sendrecv, inactive). Note that this attribute does not 3406 have a direct relation with the "Mode" property of the Termination. 3407 In fact, the SDP type of connection will most of the time be set to 3408 "sendrecv", regardless of the value used for the Termination. 3409 Other values will only be used rarely, for example in the case of 3410 information or announcement servers that need to establish one way 3411 connections. 3413 An example of specification could be: 3415 v=0 3416 c=IN IP4 128.96.41.1 3417 m=audio 3456 RTP/AVP 0 96 3418 a=rtpmap:96 G726-32/8000 3420 The default configuration for the LocalTerminationDescriptor is to use 3421 one of the IP addresses of the gateway, to select a UDP port for RTP, 3422 and to use the PCM mu-law algorithm. 3424 Gateways are expected to be able to collect the following statistics on 3425 Terminations of the RTP Class: 3427 Number of packets sent: 3428 The total number of RTP data packets transmitted by the sender 3429 since starting transmission on this connection. The count is not 3430 reset if the sender changes its synchronization source identifier 3431 (SSRC, as defined in RTP), for example as a result of a Modify com- 3432 mand. The value is zero if the connection was set in "receive only" 3433 mode. 3435 Number of octets sent: 3436 The total number of payload octets (i.e., not including header or 3437 padding) transmitted in RTP data packets by the sender since start- 3438 ing transmission on this connection. The count is not reset if the 3439 sender changes its SSRC identifier, for example as a result of a 3440 Modify command. The value is zero if the connection was set in 3441 "receive only" mode. 3443 Number of packets received: 3444 The total number of RTP data packets received by the sender since 3445 starting reception on this connection. The count includes packets 3446 received from different SSRC, if the sender used several values. 3447 The value is zero if the connection was set in "send only" mode. 3449 Internet draft MEGACO Protocol April 16, 1999 3451 Number of octets received: 3452 The total number of payload octets (i.e., not including header or 3453 padding) transmitted in RTP data packets by the sender since start- 3454 ing transmission on this connection. The count includes packets 3455 received from different SSRC, if the sender used several values. 3456 The value is zero if the connection was set in "send only" mode. 3458 Number of packets lost: 3459 The total number of RTP data packets that have been lost since the 3460 beginning of reception. This number is defined to be the number of 3461 packets expected less the number of packets actually received, 3462 where the number of packets received includes any which are late or 3463 duplicates. The count includes packets received from different 3464 SSRC, if the sender used several values. Thus packets that arrive 3465 late are not counted as lost, and the loss may be negative if there 3466 are duplicates. The count includes packets received from different 3467 SSRC, if the sender used several values. The number of packets 3468 expected is defined to be the extended last sequence number 3469 received, as defined next, less the initial sequence number 3470 received. The count includes packets received from different SSRC, 3471 if the sender used several values. The value is zero if the connec- 3472 tion was set in "send only" mode. This property is omitted if the 3473 connection was set in "data" mode. 3475 Interarrival jitter: 3476 An estimate of the statistical variance of the RTP data packet 3477 interarrival time measured in milliseconds and expressed as an 3478 unsigned integer. The interarrival jitter J is defined to be the 3479 mean deviation (smoothed absolute value) of the difference D in 3480 packet spacing at the receiver compared to the sender for a pair of 3481 packets. Detailed computation algorithms are found in RFC 1889. The 3482 count includes packets received from different SSRC, if the sender 3483 used several values. The value is zero if the connection was set in 3484 "send only" mode. This property is omitted if the connection was 3485 set in "data" mode. 3487 Average transmission delay: 3488 An estimate of the network latency, expressed in milliseconds. This 3489 is the average value of the difference between the NTP timestamp 3490 indicated by the senders of the RTCP messages and the NTP timestamp 3491 of the receivers, measured when this messages are received. The 3492 average is obtained by summing all the estimates, then dividing by 3493 the number of RTCP messages that have been received. This property 3494 is omitted if the connection was set in "data" mode. 3495 When the MG's clock is not synchronized by NTP, the latency value 3496 can be computed as one half of the round trip delay, as measured 3497 through RTCP. 3498 When the MG cannot compute the one way delay or the round trip 3500 Internet draft MEGACO Protocol April 16, 1999 3502 delay, the property conveys a null value. 3504 For a detailed definition of these variables, refer to RFC 1889. 3506 Internet draft MEGACO Protocol April 16, 1999 3508 Terminations of the RTP Class are expected to provide the following sup- 3509 port for Event Packages: 3511 _____________________________________________________________ 3512 | Package | name | support in RTP Class | 3513 |_______________________|__________|_________________________| 3514 | RTP Package | R | Mandatory | 3515 | Generic Media Package | G | Mandatory | 3516 | DTMF Package | D | Optional (e.g. in | 3517 | | | IVR units) | 3518 | Announcement | A | Optional (when gateway| 3519 | Server Package | | can play announcement | 3520 | | | on RTP) | 3521 | Script Package | Script | Optional | 3522 |_______________________|__________|_________________________| 3524 7.2.4. ATM audio Terminations 3526 ATM Terminations are use to describe the local Termination of packet 3527 connections established over ATM networks. The RTP Audio Termination 3528 Class is applied when the RTP Terminations convey an audio media. (Other 3529 Termination Classes may be used for other media, such as video.) 3531 The encoding of the media in point to point RTP Terminations is 3532 described by two sets of properties, the LocalTerminationDescriptor and 3533 the RemoteTerminationDescriptor. Both are described using SDP, with the 3534 following conventions: 3536 * The "c=" property of SDP to specifies an address in the ATM family, 3537 the ATM addressing variant (NSAP, UNI, E.164) and the ATM address. 3539 * The "m=audio" property must specify the audio encoding and, if 3540 needed, the VPI and VCI. 3542 * Additional attributes properties (a=) will be used to specify the 3543 ATM coding variants, such as the type of adaptation layer and the 3544 error correction or loss compensation algorithms. 3546 An example of SDP payload for an ATM connection could be: 3548 v=0 3549 c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe 3550 m=audio 5/1002 ATM/AVP G.711u 3551 a=connection_type:AAL2 3553 The default configuration for the LocalTerminationDescriptor is to use 3555 Internet draft MEGACO Protocol April 16, 1999 3557 one of the ATM addresses of the gateway, to select a VPI and a VCI, and 3558 to use the PCM mu-law algorithm. 3560 Gateways are expected to be able to collect the following statistics on 3561 Terminations of the ATM Class: 3563 Number of packets sent: 3564 The total number of ATM cells transmitted since starting transmis- 3565 sion on this connection. 3567 Number of octets sent: 3568 The total number of payload octets transmitted in ATM cells. 3570 Number of packets received: 3571 The total number of ATM cells received since starting reception on 3572 this connection. 3574 Number of octets received: 3575 The total number of payload octets received in ATM cells. 3577 Number of packets lost: 3578 Should be determined as the number of cells lost, or set to zero if 3579 the adaptation layer does not enable the MG to assess losses. 3581 Interarrival jitter: 3582 The interarrival jitter between ATM cells. 3584 Average transmission delay: 3585 The MG may not be able to assess this property over an ATM network. 3586 It could simply report a null value. 3588 Internet draft MEGACO Protocol April 16, 1999 3590 Terminations of the ATM Class are expected to provide the following sup- 3591 port for Event Packages: 3593 _____________________________________________________________ 3594 | Package | name | support in ATM Class | 3595 |_______________________|__________|_________________________| 3596 | ATM Package | A | Mandatory | 3597 | Generic Media Package | G | Mandatory | 3598 | DTMF Package | D | Optional (e.g. in | 3599 | | | IVR units) | 3600 | Announcement | A | Optional (when gateway| 3601 | Server Package | | can play announcement | 3602 | | | on ATM) | 3603 | Script Package | Script | Optional | 3604 |_______________________|__________|_________________________| 3606 7.2.5. Network access service Termination 3608 (Editor's note: this Package definition is really a place holder. 3609 It will most probably have to be extensively reworked by the WG.) 3611 A network access service (NAS) Termination describes the attachment of 3612 the Context to a network access service such as a generic Internet 3613 access or a tunnel to a private network server. 3615 The NAS Termination is described by a single LocalTerminationDescriptor 3616 parameter. The RemoteTerminationDescriptor parameter is not used. The 3617 LocalTerminationDescriptor is described using SDP with the following 3618 conventions: 3620 * Media description field (m) specifying the network access media, 3621 identified by the code "m=nas/xxxx", where "xxxx" describes the 3622 access control method that should be used for parameterizing the 3623 network access, as specified below. The field may also specify the 3624 port that should be used for contacting the server, as specified in 3625 the SDP syntax. 3627 * Connection address property (c=) specifying the address, or the 3628 domain name, of the server that implement the access control 3629 method. This property may also be specified at the session level. 3631 * Optionally, a bearer type attribute (a=bearer:) describing the type 3632 of data connection to be used, including the modem type. 3634 * Optionally, a framing type attribute (a=framing:) describing the 3635 type of framing that will be used on the channel. 3637 Internet draft MEGACO Protocol April 16, 1999 3639 * Optionally, attributes describing the called number (a=dialed:), 3640 the number to which the call was delivered (a=called:) and the cal- 3641 ling number (a=dialing:). 3643 * Optionally, attributes describing the range of addresses that could 3644 be used by the dialup client on its LAN (a=subnet:). 3646 * Optionally, an encryption key, encoded as specified in the SDP 3647 protocol(k=). 3649 The connection address shall be encoded as specified in the SDP stan- 3650 dard. It must be used in conjunction with the port specified in the 3651 media line to access a server, whose type must be one of: 3653 __________________________________________________________ 3654 | Method name| Method description | 3655 |____________|____________________________________________| 3656 | radius | Authentication according | 3657 | | to the Radius protocol. | 3658 | tacacs | Authentication according | 3659 | | to the TACACS+ protocol. | 3660 | diameter | Authentication according | 3661 | | to the Diameter protocol. | 3662 | l2tp | Level 2 tunneling protocol. | 3663 | | The address and port are those of the LNS.| 3664 | login | Local login. (There is normally | 3665 | | no server for that method.) | 3666 | none | No authentication required. | 3667 | | (The call was probably vetted | 3668 | | by the Call Agent.) | 3669 |____________|____________________________________________| 3671 If needed, the gateway may use the key specified in the announcement to 3672 access the service. That key, in particular, may be used for the estab- 3673 lishment of an L2TP tunnel. 3675 The bearer attribute is composed of a bearer name and an optional exten- 3676 sion. The bearer type specifies the type of modulation (modem name) or, 3677 in the case of digital connections, the type of ISDN service (8 bits, 7 3678 bits). When an extension is present, it is separated from the bearer 3679 name by a single slash (/). The valid values of the bearer attribute 3680 are defined in the following table: 3682 Internet draft MEGACO Protocol April 16, 1999 3684 ____________________________________________________________________ 3685 | Type of bearer description | Example of values | 3686 |_________________________________|_________________________________| 3687 | ITU modem standard | V.32, V.34, V.90. | 3688 | ITU modem standard qualified | v.90/3com, | 3689 | by a manufacturer name | v.90/rockwell, | 3690 | | v.90/xxx | 3691 | Well known modem types | X2, K56flex | 3692 | ISDN transparent access, 64 kbps| ISDN64 | 3693 | ISDN64 + V.110 | ISDN64/V.110 | 3694 | ISDN64 + V.120 | ISDN64/V.120 | 3695 | ISDN transparent access, 56 kbps| ISDN56 | 3696 | Informal identification | (Requires coordination between | 3697 | | the Call Agent and the gateway)| 3698 |_________________________________|_________________________________| 3700 The valid values of the framing attribute are defined in the following 3701 table: 3703 _________________________________________________ 3704 | Type of framing description| Example of values| 3705 |____________________________|___________________| 3706 | PPP, asynchronous framing | ppp-asynch | 3707 | PPP, HDLC framing | ppp-hdlc | 3708 | SLIP, asynchronous | slip | 3709 | Asynchronous, no framing | asynch | 3710 |____________________________|___________________| 3712 The network access authentication property provides instructions on the 3713 access control that should be exercized for the data call. This optional 3714 attribute is encoded as: 3716 "a=subnet:"
3717 "/" 3719 Where the properties "network type", "address type", and "connection 3720 address" are formatted as defined for the connection address property 3721 (c=) in SDP, and where the "prefix length" is a decimal representation 3722 of the number of bits in the prefix. 3724 Examples of SDP announcement for the network access service could be: 3726 v=0 3727 m=nas/radius 3728 c=IN IP4 radius.example.net 3730 Internet draft MEGACO Protocol April 16, 1999 3732 a=bearer:v.34 3733 a=framing:ppp-asynch 3734 a=dialed:18001234567 3735 a=called:12345678901 3736 a=dialing:12340567890 3738 v=0 3739 m=nas/none 3740 c=IN IP4 128.96.41.1 3741 a=subnet:IN IP4 123.45.67.64/26 3742 a=bearer:isdn64 3743 a=framing:ppp-sync 3744 a=dialed:18001234567 3745 a=dialing:2345678901 3747 v=0 3748 c=IN IP4 access.example.net 3749 m=nas/l2tp 3750 k=clear:some-shared-secret 3751 a=bearer:v.32 3752 a=framing:ppp-asynch 3753 a=dialed:18001234567 3754 a=dialing:2345678901 3756 There is no default value of the properties defined for this Termination 3757 Class.(Editor's note: we may have to define more specific Classes, such 3758 as "Internet Access", for which the defaults would apply.) 3760 The following statistics can be collected on NAS Terminations: 3762 Number of packets sent: 3763 The total number of NAS packets transmitted since starting 3764 transmission on this connection. 3766 Number of octets sent: 3767 The total number of octets transmitted in NAS packets. 3769 Number of packets received: 3770 The total number of packets received since starting reception on 3771 this connection. 3773 Number of octets received: 3774 The total number of octets received in NAS packets. 3776 Terminations of the NAS Class are expected to provide the following sup- 3777 port for Event Packages: 3779 Internet draft MEGACO Protocol April 16, 1999 3781 ______________________________________________ 3782 | Package | name | support in NAS Class| 3783 |____________|________|_______________________| 3784 | NAS Package| N | Mandatory | 3785 |____________|________|_______________________| 3787 8. Acknowledgements 3789 The authors would like to thank the fine crews of the numerous airlines 3790 that carried them around the world to a succession of interesting meet- 3791 ings, their family members whom they left alone during said meetings, 3792 their colleagues and their staff. 3794 We would also like to extend special thanks to the members of the MEGACO 3795 design team, Nancy-M Greene, Glen Freundlich, David Auerbach, Rex Col- 3796 dren, Dave Oran, Flemming Andreassen, Hong Liu, Michael Ramalho, Gur 3797 Kimchi, Graeme Gibbs, Brian Hill, Ike Elliott, Bob Bell, and Matt Hol- 3798 dredge. 3800 In fact, we would like to thank all the members of the MEGACO working 3801 group, and its chair, Tom Taylor. 3803 9. References 3805 * Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A 3806 Transport Protocol for Real-Time Applications", RFC 1889, January 3807 1996. 3809 * Schulzrinne, H., "RTP Profile for Audio and Video Conferences with 3810 Minimal Control", RFC 1890, January 1996 3812 * Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC 3813 2327, April 1998. 3815 * Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 3816 "Session Initiation Protocol (SIP)", RFC 2543, March 1999. 3818 * Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 3819 Protocol (RTSP)", RFC 2326, April 1998. 3821 * ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN 3822 USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; 3823 modified at Helsinki, 1993) 3825 * ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIG- 3826 NALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga- 3827 Torremolinos, 1984; modified at Helsinki, 1993) 3829 Internet draft MEGACO Protocol April 16, 1999 3831 * ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA COM- 3832 MUNICATIONS SYSTEMS." 3834 * ITU-T, Recommendation H.225, "Call Signaling Protocols and Media 3835 Stream Packetization for Packet Based Multimedia Communications 3836 Systems." 3838 * ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR MUL- 3839 TIMEDIA COMMUNICATION." 3841 * Atkinson, R., "Security Architecture for the Internet Protocol." 3842 RFC 2401, November 1998. 3844 * Atkinson, R., "IP Authentication Header." RFC 2402, December 1998. 3846 * Atkinson, R., "IP Encapsulating Security Payload (ESP)." RFC 2406, 3847 November 1998. 3849 * Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: 3850 ABNF", RFC 2234, November 1997. 3852 10. Authors' Addresses 3854 Fernando Cuervo, 3855 Nortel Networks 3856 Ottawa, ON, Canada 3857 EMail: cuervo@nortelnetworks.com 3859 Christian Huitema 3860 Telcordia Technologies 3861 445 South Street 3862 Morristown, NJ 07960 3863 EMail: huitema@research.telcordia.com 3865 Keith Kelly 3866 NetSpeak Corporation 3867 902 Clint Moore Road, Suite 104 3868 Boca Raton, FL 33487 3869 EMail: keith@netspeak.com 3871 Brian Rosen 3872 FORE Systems 3873 1000 FORE Drive 3874 Warrendale, PA 15086 3875 EMail: brosen@eng.fore.com 3877 Paul Sijben 3878 Lucent Technologies 3880 Internet draft MEGACO Protocol April 16, 1999 3882 PO box 18 3883 1270 AA Huizen 3884 the Netherlands 3885 Phone: +31 35 687 4774 3886 Email: sijben@lucent.com 3888 Eric Zimmerer 3889 Level3 Communications 3890 1450 Infinite Drive 3891 Louisville, CO 80027 3892 EMail: eric.zimmerer@level3.com