idnits 2.17.1 draft-ietf-megaco-protocol-00.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-18) 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 82 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 83 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 151 instances of too long lines in the document, the longest one being 17 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 1453: '...detected. The MG MUST NOT send an unso...' RFC 2119 keyword, line 1581: '...RESERVED" fields MUST be set to "zero"...' RFC 2119 keyword, line 1617: '...O protocol using IPv4 MUST support the...' RFC 2119 keyword, line 1618: '... Implementations SHOULD implement IPSE...' RFC 2119 keyword, line 1620: '... and AH-within-MEGACO MUST NOT be used...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1413 has weird spacing: '...plished by al...' == Line 1464 has weird spacing: '...way, is about...' == Line 1981 has weird spacing: '...dl dial-tone...' == Line 2424 has weird spacing: '...to/from a par...' == Line 2775 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 385 looks like a reference -- Missing reference section? 'DigitMapDescriptor' on line 1322 looks like a reference -- Missing reference section? 'RemoteTerminationDescriptor' on line 1315 looks like a reference -- Missing reference section? 'Capabilities' on line 1347 looks like a reference -- Missing reference section? 'Statistics' on line 1348 looks like a reference -- Missing reference section? 'MGCIdentity' on line 1467 looks like a reference -- Missing reference section? 'ServiceChangeDelay' on line 1471 looks like a reference -- Missing reference section? 'RFC2401' on line 1561 looks like a reference -- Missing reference section? 'RFC2402' on line 1625 looks like a reference -- Missing reference section? 'RFC2406' on line 1631 looks like a reference -- Missing reference section? 'RFC2409' on line 1627 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 March 25, 1999 Christian Huitema 5 Expires September 25, 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 Proposal 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 Proposal March 25, 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 Proposal March 25, 1999 84 Table of Contents Page 86 1. Introduction .............................................. 5 87 1.1. High Level Description of the Protocol ............... 5 89 1.1.1. Connection Model ................................ 5 90 1.1.2. Terminations .................................... 8 91 1.1.3. Termination Capabilities ........................ 8 92 1.1.4. Termination Dynamics ............................ 9 93 1.1.5. Issuing Commands in Transactions ................ 10 94 1.1.6. 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 .................... 17 101 2.1.5. Termination Descriptors ......................... 19 102 2.1.6. Events, Signals and Packages .................... 19 103 2.1.7. SignalDescriptors ............................... 21 104 2.1.8. EventDescriptors ................................ 21 105 2.1.9. Digit Maps ...................................... 23 106 2.1.10. Statistics ..................................... 24 107 2.2. Termination Management Commands ...................... 25 108 2.2.1. Add ............................................. 25 109 2.2.2. Modify .......................................... 27 110 2.2.3. Subtract ........................................ 28 111 2.2.4. Move ............................................ 29 112 2.2.5. Audit ........................................... 30 113 2.3. MG-Issued Commands ................................... 31 114 2.3.1. Notify .......................................... 31 115 2.3.2. ServiceChange ................................... 32 116 2.4. Error Codes .......................................... 34 117 3. Security Considerations ................................... 34 118 3.1. Protection of Media Connections ...................... 36 119 4. Syntax .................................................... 38 121 ****************************************************************** 122 The text in the following sections HAS NOT BEEN REVIEWED by the 123 Design team and is presented for clarity without implying 124 consensus or correctness. 125 ****************************************************************** 127 4.1. Termination Names .................................... 42 128 4.2. Events, Signals and Packages ......................... 43 129 4.3. Digit Maps ........................................... 45 130 4.4. Statistics ........................................... 46 131 4.5. Examples ............................................. 49 133 Internet draft MEGACO Protocol Proposal March 25, 1999 135 4.5.1. Example Add transaction: ........................ 50 136 4.5.2. Example response to Add transaction: ............ 50 137 4.5.3. Example Modify transaction: ..................... 50 138 4.5.4. Example Subtract transaction: ................... 50 139 4.6. Transaction Response Codes ........................... 51 140 4.6.1. Transaction Response Success Codes .............. 51 141 4.6.2. Transaction Response Reject Codes ............... 51 142 5. Transport ................................................. 52 143 5.1. Transport capabilities, and relationship to Transport 52 144 6. Event packages and termination classes .................... 53 145 6.1. Basic event packages ................................. 54 146 6.1.1. Generic Media Event package ..................... 54 147 6.1.2. DTMF event package .............................. 55 148 6.1.3. MF Event package ................................ 58 149 6.1.4. Trunk Event package ............................. 59 150 6.1.5. Line Event package .............................. 60 151 6.1.6. Handset emulation event package ................. 64 152 6.1.7. RTP Event package ............................... 65 153 6.1.8. Network Access Server Event package ............. 66 154 6.1.9. Announcement Server Event package ............... 67 155 6.1.10. Script Event package ........................... 68 156 6.2. Basic termination classes ............................ 69 157 6.2.1. DS0 Terminations ................................ 69 158 6.2.2. Analog Terminations ............................. 70 159 6.2.3. RTP Audio Terminations .......................... 71 160 6.2.4. ATM audio terminations .......................... 75 161 6.2.5. Network access service termination .............. 77 162 7. Acknowledgements .......................................... 81 163 8. References ................................................ 81 164 9. Authors' Addresses ........................................ 82 166 Internet draft MEGACO Protocol Proposal March 25, 1999 168 1. Introduction 170 This document describes the MEGACO protocol for controlling Media Gate- 171 ways from external call control elements called Media Gateway Controll- 172 ers. 174 1.1. High Level Description of the Protocol 176 This section describes the model and main concepts upon which the MEGACO 177 Protocol is built. It is intended to familiarize the reader with the 178 model, terminology and working concepts of the protocol. This section's 179 contents are illustrative and do not intend to supersede information 180 contained in later sections of this document. Where discrepancies may 181 exist, the later sections shall be assumed to contain the correct infor- 182 mation. 184 1.1.1. Connection Model 186 The connection model for the MEGACO protocol is described using just two 187 abstractions, Terminations and Contexts. Terminations are entities 188 representing physical endpoints, such as analog loops or timeslots on a 189 TDM channel, as well as more ephemeral representations of flow termina- 190 tions, such as RTP streams. 192 Internet draft MEGACO Protocol Proposal March 25, 1999 194 *======================================================* 195 | Media Gateway | 196 | +-----------------------------------+ | 197 | | Context +---+ | | 198 | | | T | | | 199 | +---+ | +-+-+ | | 200 | | T | | | | | 201 | +---+ | +---+ +-+ +---+ | | 202 | | | T +---------+ +---------| T | | | 203 | | +---+ +-+ +---+ | | 204 | | | | | 205 | | +-+-+ | | 206 | | | T | | | 207 | | +---+ | | 208 | +-----------------------------------+ | 209 | | 210 | +----------------------+ +---------------+ | 211 | | Context | | Context | | 212 | | +---+ +-+ | | +---+ +-+ | | 213 | | | T +---------+ + | | | T +----+ + | | 214 | | +---+ +-+ | | +---+ +-+ | | 215 | | | | +---------------+ | 216 | | +-+-+ | | 217 | | | T | | | 218 | | +---+ | | 219 | +----------------------+ | 220 *======================================================* 222 Examples of Contexts and Terminations Within an MG 224 Contexts represent a star configuration (i.e.-a variable number of 225 interconnected nodes) of Terminations of a single media type. Audio 226 connections are modeled by viewing the Context as a mixing bridge. For 227 connections involving other media types and for mixed media gateways, 228 the Context's behavior will be described as an extension to the proto- 229 col. There are commands to Add Terminations to a Context, Subtract Ter- 230 minations from a Context, and Move Terminations between two Contexts. 232 A Context must have at least one Termination and a Termination may 233 belong to no more than one Context at a given time. A Context is 234 created by the Add of its first Termination and is destroyed by a Sub- 235 tract of its last remaining Termination. It is possible to move a Ter- 236 mination from one Context to another with the use of the Move command. 237 It is also possible for a Termination to exist outside of a Context. 239 Internet draft MEGACO Protocol Proposal March 25, 1999 241 A Media Gateway may limit the number of Terminations that it supports in 242 a given Context. For example, a limit of two might exist for very sim- 243 ple gateways. A limit of three might be common for gateways that sup- 244 port a three-way calling but not multi-way calling of any larger propor- 245 tions. 247 To illustrate the use of a Context, consider a Media Gateway that pro- 248 vides media adaptation between the PSTN and a VoIP network. In this 249 case a typical Context might contain two Terminations, one representing 250 a PSTN trunk (a DS0 Termination) and the other an RTP Stream Termina- 251 tion. A PSTN hairpin connection would be represented by a Context with 252 two DS0 Terminations in it. A three-way call and larger conferences 253 would be represented by a Context with three or more Terminations in it. 255 The use of Contexts to represent conferences is very powerful since it 256 enables a description of the conference dynamics that is not restricted 257 in any way by the order in which Terminations are added or subtracted. 258 For instance, no special operations are required when a participant in a 259 conference drops out. Its Termination may be subtracted without affect- 260 ing the connectivity of the Terminations remaining in the conference. 262 The call-waiting scenario shown below illustrates the use of the Move 263 command to relocate a Termination between Contexts. In this example, 264 Terminations T1 and T2 belong initially to Context C1. T1 might be the 265 line side of a residential gateway, while T2 could represent an RTP 266 Stream Termination. When T1 is connected to T2 in Context C1 a new call 267 arrives for T1 from Termination T3. T3 is placed in Context C2. After 268 alerting is applied to T1 in Context C1 and T1 provides signaling to 269 accept the waiting call, T1 is moved from C1 to C2 through use of the 270 Move command. The active call is represented now by C2 and the call on 271 hold is represented by C1. 273 Internet draft MEGACO Protocol Proposal March 25, 1999 275 Call Waiting Scenario: 277 Initial Call 278 +-C1--------------------+ 279 | +---+ +-+ +---+ | 280 | |T1 +---+ +---| T2| | 282 | +---+ +-+ +---+ | 283 +-----------------------+ 285 New Call Arrives 287 +-C1--------------------+ +-C2--------------------+ 288 | +---+ +-+ +---+ | | +-+ +---+ | 289 | |T1 +---+ +---| T2| | | + +---| T3| | 290 | +---+ +-+ +---+ | | +-+ +---+ | 291 +-----------------------+ +-----------------------+ 293 Waiting Call Answered 295 +-C1--------------------+ +-C2--------------------+ 296 | +-+ +---+ | | +---+ +-+ +---+ | 297 | + +---| T2| | | |T1 +---+ +---| 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 tions are given a unique name (i.e.-the last component of the hierarchi- 311 cal name will be unique) by the Media Gateway. Wildcards may be used in 312 the specification of a name. Section [2.1.2] describes in detail the 313 structure and properties of entity names used in the MEGACO Protocol. 315 1.1.3. Termination Capabilities 317 Membership in a TerminationClass determines the Capabilities of a Termi- 318 nation. The TerminationClass provides the default values and allowable 320 Internet draft MEGACO Protocol Proposal March 25, 1999 322 ranges for the Termination's Capabilities. Capabilities include: 324 * Termination address, media parameters, security properties, etc. 325 The list of these properties is described in a Profile. 327 329 * Events and Signals that a Termination supports. They are grouped 330 in Packages. 332 It is possible for a TerminationClass to coalesce its Capabilities from 333 multiple Profiles and Packages. TerminationClasses, Profiles and Pack- 334 ages cannot be created or modified using the commands of the Megaco pro- 335 tocol. This is expected to be done via, for instance, management 336 mechanisms. The Modify command only applies to instantiated termina- 337 tions. The Capabilities values of a TerminationClass are the default 338 values for Terminations instantiated from the TerminationClass. 340 The Capabilities of a Termination can be obtained using the Audit com- 341 mand. 343 1.1.4. Termination Dynamics 345 As Terminations are Added or Moved it is necessary to specify state and 346 media parameters for, Events to be detected on, and Signals to be 347 applied to such Terminations within the Context in which they exist. It 348 may also be necessary during the life of a Termination within a Context 349 to Modify these properties. 351 For Terminations representing physical entities it might also be desir- 352 able to Modify their properties as they are Subtracted from a Context. 353 This may be the case if a configuration different to the one provided by 354 the TerminationClass defaults is needed. Such Terminations may also 355 have their properties Modified outside of their existence within a Con- 356 text. 358 The Add, Subtract, Move and Modify commands may affect the following 359 sets of properties: 361 * TerminationState: A list of properties that define the state of the 362 Termination, but which are not directly linked to the description 363 of a media flow, to an event list or to a signal list. 365 * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists 366 of properties describing the processing of the media flow in each 367 direction. 369 * EventsDescriptor: A list of events that should be detected on the 371 Internet draft MEGACO Protocol Proposal March 25, 1999 373 Termination. 375 * SignalDescriptor: A list of signals that should be applied on the 376 Termination. 378 For example, the Add Command has the following form: 380 Add(TerminationId, 381 [LocalTerminationState,] 382 [LocalTerminationDescriptor,] 383 [RemoteTerminationDescriptor,] 384 [EventsDescriptor,] 385 [SignalDescriptor]) 387 All parameters listed are optional except for the TerminationId. This 388 allows each command to specify exactly what needs to be modified. Addi- 389 tionally, some parameters may not be required for certain TerminationC- 390 lasses. For instance, DS0s do not use RemoteTerminationDescriptors. 391 These descriptors are used only for the packet TerminationClasses. 393 A Termination is programmed to look for specific events through the 394 EventsDescriptor, which is a parameter to Add, Modify and Subtract. 395 When a Termination detects an event that matches the types of events it 396 is programmed to detect, the MG generates a Notify command. 398 The MG can generate a ServiceChange message. ServiceChange has a number 399 of uses: Registration of an MG with an MGC, notification of imminent 400 downtime for one or more Terminations, notification that one or more 401 Terminations has already gone down, and notification that one or more 402 Terminations have been brought back into service. 404 Detailed definitions of Commands and their Responses are provided in 405 Section 2. 407 1.1.5. Issuing Commands in Transactions 409 The protocol has been designed to allow multiple Commands to be packed 410 in single TransactionRequest. The corresponding Responses are received 411 in a single Transaction reply. There are two types of replies, a Tran- 412 sactionAccept and a TransactionReject. A Transaction allows Commands to 413 share fate and guarantees ordered processing. 415 Commands in a Transaction are executed sequentially according to an "all 416 or nothing rule". That is, a TransactionAccept includes successful 417 Responses for ALL the Commands in the corresponding TransactionRequest. 419 Internet draft MEGACO Protocol Proposal March 25, 1999 421 A TransactionReject is sent when one of the Commands included in the 422 Transaction fails. Responses for the Commands in a TransactionReject 423 are issued as follows: 425 * All Commands before the point of failure in the Command sequence 426 should have a Response equal to "non-executed". 428 * The failed Command should have a Response with a Reason Code. 430 * Commands after the point of failure are not processed and, there- 431 fore, Responses are not issued for them. 433 The parsing mechanism described in the coding section (section 3) speci- 434 fies how responses or reason codes are associated with individual Com- 435 mands. 437 When a MGC issues Commands to a MG, a Context must always be specified. 438 This is quite natural for Add and Subtract. For Modify Commands on a 439 Termination that is not in a Context, the NULL context must be speci- 440 fied. A Move Command clearly involves two Contexts, however only the 441 target context needs to be specified. Within a Transaction, all Com- 442 mands that apply to a Context must appear after the ContextId parameter. 444 The following lines illustrate (i.e., syntax is ad-hoc and actions some- 445 what simplified) the use of Transactions in the call-waiting example of 446 section 1.1.1. The Transaction that creates the second Context, applies 447 signals to Termination T1 (to indicate call-waiting) and detects events 448 from T1 (to swap the call) is formed as follows: 450 Transaction(TransactionId=12345 451 ContextId=* Add(T3) 452 ContextId=C1 Modify(T1, EventDescriptor, SignalDescriptor) ) 454 The Commands in this Transaction are processed sequentially. First, the 455 MG creates a Context to Add T3. Second, T1 is programmed to signal the 456 waiting call and collect the events that operate the call-waiting 457 feature. 459 The next Transaction shows the Commands issued by the MGC to swap the 460 Terminations. 462 Transaction(TransactionId=12346 463 ContextId=C2 Move(T1) Modify(T3, TerminationState) 464 ContextId=C1 Modify(T2, TerminationState) ) 466 Again, the Commands in this Transaction are processed sequentially. 468 Internet draft MEGACO Protocol Proposal March 25, 1999 470 First, the MG moves T1 from C1 into C2. Then it modifies the Mode of T3 471 to Sendrecv. Finally, T2 in C1 is set to Receive Mode. 473 1.1.6. Sample Command Flow 475 This section presents an illustration of the use of the protocol Com- 476 mands to establish a communication between two Residential Gateways over 477 an IP trunking network, both MGs are under the control of the same MGC. 479 Internet draft MEGACO Protocol Proposal March 25, 1999 481 |Step | User | ResMG | MGC | ResMGr | User | 482 |_____|___________|_____________|________________|_____________|___________| 483 | 0| | <------CTX=null,Modify(T1) | | 484 | | | Resp-------------> | | | 485 | | | (Ok,ready, looking for Off-hook) | | 486 | 1| Off-hook | Notify----------------> | | | 487 | | | | (off-hook recorded) | | 488 | | | <--------------Resp(Ok)| | | 489 | 2|Acc Digits | | | | | 490 | | | | | | | 491 | 3|DgtsColct'd| Notify -----------> | | | 492 | 4| | <--------------Resp(Ok)| | | 493 | | | | | | | 494 | 5| | <------CTX=* ADD(T1) | | | 495 | | | | ADD(RTP/* LocalDesc) | | 496 | 6| | CTX=C1 ---------> | | | 497 | | | Resp(Ok) | | | | 498 | | | Resp(RTP/Id,LocalDesc,RemoteDesc | | 499 | | | | | | | 500 | 7| | |CTX=* ADD(T1r)---------> | | 501 | | | | ADD(RTPr/*,LocalDesc,RemoteDesc) | 502 | | | | | | | 503 | 8| | | <---------------CTX=C1r | | 504 | | | | | Resp(Ok) | | 505 | | | Resp(RTP/Id,LocalDesc,RemoteDesc) | | 506 | | | | | | | 507 | 9| | |CTX=C1r --------------> | | 508 | | | | Modify(T1r,SignalList=Ring) | 509 | | | | | | | 510 | | | | | | | 511 | 10| | | <---------------CTX=C1r | Ring | 512 | | | | | Resp(Ok) | | 513 | | | | | | | 514 | 11| | <-------CTX=C1 Modify(T1, SignalList=Ringback) | 515 | | | | Modify(RTP/Id,LocalDesc,RemoteDesc) 516 | 12| Ring-Back | CTX=C1 ---------> | | | 517 | | | Resp(Ok) | | | | 518 | | | Resp(RTP/Id,LocalDesc,RemoteDesc) | | 519 | | | | | | | 520 | 13| | | <------------- Notify | Off-hook | 521 | 14| | | Resp(Ok)----------> | | 522 | | | | | | | 523 | | | | | | | 524 | 15| | <------CTX=C1 Modify(T1,TerminalState=Sendrcv | 525 | | | | | SignalList) | | 526 | 16| | CTX=C1 ---------> | | | 527 | | | Resp(Ok) | | | | 529 Internet draft MEGACO Protocol Proposal March 25, 1999 531 CTX = ContextID 533 Step 0: 534 The MGC issues a Modify Command to request that T1 detect an Off- 535 hook and proceed with digit collection 537 Step 1: 538 The Off-hook is detected, the Notify Command is issued and the 539 Off-hook recorded for billing purposes. 541 Step 2: 542 The termination collects and accumulates digits according to an 543 appropriate digit map. 545 Step 3: 546 The collected digits are sent to the MGC in a Notify Command. 548 Step 4: 549 The MGC acknowledges the digit string. 551 Step 5: 552 After determining that the digit string is valid to initiate a 553 call, the MGC uses the Add Command to create a Context that 554 includes T1 and a yet unnamed ephemeral packet Termination (RTP/*). 555 The RTP Termination receives only a LocalTerminationDescriptor that 556 specifies, for instance, a choice of Codecs. 558 Step 6: 559 The reply to the Add Command includes a named Context (C1) and a 560 named RTP Termination (RTP/Id) with its LocalTerminationDescriptor 561 including supported Codecs and the receiving RTP port. 563 Step 7: 564 The MGC can now instruct the remote Residential MG to Add the ter- 565 mination that corresponds to the dialed string (e.g., T1r) and a 566 corresponding RTP Termination in a Context. The information 567 returned in T1's LocalTerminationDescriptor is passed to the remote 568 Residential MG in the RemoteTerminationDescriptor. The LocalTer- 569 minationDescriptor specifies the Codecs for T1r. 571 Step 8: 572 The reply to the Add Command includes a named Context (C1r) and a 573 named RTP Termination (RTP/Idr) with its LocalTerminationDescriptor 574 including supported Codecs and the receiving RTP port. 576 Step 9: 577 The MGC can now request that Ringing be applied on T1r. The Modify 579 Internet draft MEGACO Protocol Proposal March 25, 1999 581 Command is used for this. Looking for Off-hook is simultaneously 582 programmed in T1r. 584 Step 10: 585 The Response indicating that Ringing is applied is sent to the MGC. 587 Step 11: 588 Two Modify commands are issued in this Transaction. The first 589 requests that Ring-back be applied to T1. The second provides the 590 RemoteTerminationDescriptor, which indicates the remote RTP receiv- 591 ing port. 593 Step 12: 594 The TransactionReply acknowledges that Ringback is being applied 595 and the RTP parameter settings have been updated. 597 Step 13: 598 The remote user goes off-hook. A Notify Command conveys that 599 information to the MGC. It is assumed that the off-hook command has 600 an associated action that cancels ringing. 602 Step 14: 603 The Notify is acknowledged by the MGC. 605 Step 15: 606 The MGC issues a Modify Command to T1 to set the two-way talk path 607 and cancel ringback. 609 Step 16: 610 The MG acknowledges that the call set up is complete. 612 2. Commands 614 Commands from the MGC to the MG are grouped into Transactions, each of 615 which requires a Transaction ID. Transactions consist of one or more 616 Actions. Each Action is limited to operate within a single Context and 617 consequently must specify a ContextID. There are two circumstances 618 where a specific ContextID is not provided. One is the case of modifi- 619 cation of a Termination outside of a Context. The other is where the 620 controller requests the gateway to create a new Context. Each of these 621 two cases has a distinguished value for ContextID 623 An Action consists of a series of Commands (Add, Subtract, Modify, Move, 624 etc.). These Commands have very similar parameters, which may include: 626 * TerminationState: A list of properties that define the state of the 627 Termination, but which are not directly linked to the description 628 of a media flow, to an event list, or to a signal list. This 630 Internet draft MEGACO Protocol Proposal March 25, 1999 632 includes a description of the media handling at the Termination 633 (e.g., the Mode parameter that indicates loopback, COT, etc.) and a 634 description of the handling of accumulated events that are pending 635 for processing (i.e., "quarantined events"). 637 * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists 638 of properties describing the processing of the media flow in each 639 direction. These are expressed in the form of SDPdescriptors[ref]. 641 * EventsDescriptor: A list of Events that should be detected on the 642 Termination. These Events must be supported by the Package(s) of 643 the TerminationClass. The EventDescriptor can be augmented by a 644 DigitMap. 646 * SignalDescriptor: A list of Signals that should be applied on the 647 Termination. These Signals must be supported by the Package(s) of 648 the TerminationClass. 650 * A DigitMapDescriptor, which creates, deletes, or redefines a Digit 651 Map. A Digit Map is a concise description of how an MG is to han- 652 dle a series of events from the detection of tones (such as from 653 DTMF tone detection). 655 Responses which return information do so in the form of a LocalTermina- 656 tionDescriptor, RemoteTerminationDescriptor, or a Statistics summary. 658 2.1. Names and Common Parameters 660 2.1.1. Context Identifiers 662 Contexts are identified by a ContextID, which is assigned by the Media 663 Gateway and is unique within the scope of the Media Gateway. The proto- 664 col makes reference to two distinguished values: 666 * The "null" context, which is used to refer to a Termination outside 667 of a Context. When used with a Modify Command, such a reference 668 changes the default values for the Termination. 670 * The "unspecified" Context, which is used to request that the MG 671 create a new Context. The actual ContextID must be returned to the 672 MGC for subsequent use. 674 2.1.2. Termination Names 676 Names for Terminations are hierarchical. A separation character delim- 677 its the components of a name from one another. An example name in a 678 Termination class that implements a channelized T3 is "com1/3/17". This 679 name refers to a T3 called "com1", the "3" specifies the 3rd DS1 in the 681 Internet draft MEGACO Protocol Proposal March 25, 1999 683 T3. The "17" specifies the 17th DS0 (timeslot) in the DS1. 685 Names in Commands may use wildcards. Two wildcard constructs are pro- 686 vided: "all" and "choose". The "all" construct allows a Command to 687 specify all possible values of a name component. One can, for example, 688 use "all" to refer to all DS1s of a T3 (com1/*). 690 When an ephemeral Termination is to be created, the name is given with 691 the last component specified as "choose". The MG must create a fully 692 instantiated Termination and supply a unique name which must be returned 693 to the MGC and be used for subsequent Transactions. 695 2.1.3. Specifying Properties 697 Commands may include descriptors. Each descriptor has a set of legal 698 properties that may be included, which is part of the definition of the 699 Termination class (properties legal for TerminationState, LocalTermina- 700 tionDescriptor and RemoteTerminationDescriptor), or package (properties 701 legal for EventDescriptor or SignalDescriptor). In a descriptor, each 702 of the properties may be fully specified, under-specified, or unspeci- 703 fied. 705 * Fully specified properties have a single, unambiguous value that 706 the MGC instruct the MG to use for the specified parameter 708 * Under-specified properties have a list of potential values. The MG 709 chooses one value from the offered list, and returns the value it 710 chose to the MGC. A common example is choice of codec. The MGC 711 may allow the MG to choose from G.729a, G.723 or G.711. The MG's 712 choice may be limited based on availability of DSP resources at the 713 time the request was made. The order in which the MGC presents 714 choices to the MG represents the MGCs order of preference for the 715 values offered, which the MG is encouraged, but not obligated to 716 respect. 718 * Unspecified properties (legal properties which do not occur in the 719 descriptor) result in the MG retaining the previous value for that 720 parameter. 722 Editor's note: We need to have the syntax able to express mutually- 723 exclusive options. In other words, "I can do GSM-FR if I don't do any 724 G.729 at the same time" this is very useful for limited DSP-only dev- 725 ices, and is a requirement for H.245 semantics. 727 2.1.4. Termination State Properties 729 TerminationState groups a list of properties that define the state of 730 the Termination, but are not directly linked to a media flow, to an 732 Internet draft MEGACO Protocol Proposal March 25, 1999 734 event list or to a signal list. These properties are: 736 * TerminationMode 738 * QuarantineProcessing 740 * QuarantineNotification 742 The TerminationMode parameter indicates the relation between the Termi- 743 nation and the "star" connection of the context. The mode are "send 744 only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), 745 "inactive" (inactive), "outofservice", "loopback" and "continuity test" 746 (conttest). 748 The handling of the media received on the Termination is determined by 749 the TerminationMode parameter value: 751 * Termination whose mode is "send", "conference" or "send/receive" 752 receive the signals mixed in the context, according to media 753 specific rules - audio Terminations for example, will receive the 754 sum of the audio flows coming from all other Terminations, exclud- 755 ing those coming from this specific Termination. 757 * The "loopback" and "continuity test" modes are used during mainte- 758 nance and continuity test operations. There are two flavors of con- 759 tinuity test, one specified by ITU and one used in the US, also 760 referred to as "four wire" and "two wire". In the first case, the 761 test is a loopback test. The originating switch or MG will send a 762 tone (the go tone) on the bearer circuit and expect the terminating 763 switch or MG to loopback the circuit. If the originating entity 764 sees the same tone returned (the return tone), the COT has passed. 765 If not, the COT has failed. In the second case, the go and return 766 tones are different. The originating entity sends a certain go 767 tone. The terminating entity detects the go tone, it asserts a dif- 768 ferent return tone in the backwards direction. When the originating 769 entity detects the return tone, the COT is passed. If the originat- 770 ing entity never detects the return tone, the COT has failed. 772 Editor's Note: There is debate over whether the protocol can, or should, 773 specify all forms of testing in the mode. If it does so, a more exhaus- 774 tive list must be provided. If that is not appropriate, it may be 775 preferable to define only one mode, "test", and then define events and 776 signals for specific tests. Clearly the initiation of any test is MGC- 777 driven, this needs to be spelled out (flows explaining for SCN and 778 MEGACO originated/transit/terminated tests)] 780 The optional QuarantineProcessing and QuarantineNotification descriptors 781 specifies the handling of "quarantined" events, i.e. events that have 783 Internet draft MEGACO Protocol Proposal March 25, 1999 785 been detected by the MG before the arrival of an EventsDescriptor, but 786 have not yet been notified to the MGC. 788 * QuarantineProcessing specifies whether the quarantined events 789 should be processed or discarded (the default is to process them.) 791 * QuarantineNotification specifies whether the MG is expected to gen- 792 erate at most one notification (step by step), or multiple notifi- 793 cations (loop), in response to this request (the default is exactly 794 one.) 796 2.1.5. Termination Descriptors 798 The LocalTerminationDescriptor and RemoteTerminationDescriptor parame- 799 ters describe the processing of the media flow in each of the direc- 800 tions. The actual properties of each descriptor depend of the Termina- 801 tion class. Examples of Termination classes are RTP, Analog, DS0. For 802 an RTP Termination, for example, some of the properties might be: 804 * IP address, 806 * UDP ports (RTP and RTCP), 808 * Encoding Method, 810 * Packetization period, 812 The LocalTerminationDescriptor and RemoteTerminationDescriptor are 813 described in the form of an SDP descriptor which is part of the defini- 814 tion of the Termination class. These sets of properties can be enhanced 815 by vendor specific optional or mandatory extensions. Properties in the 816 LocalTerminationDescriptor and the RemoteTerminationDescriptor may be 817 fully specified, under-specified or (by omission) unspecified as 818 described above. 820 Editor Note: Using SDP supposes resolution of a few questions. We 821 have to make sure that we can associate a unique SDP profile for 822 each Termination class. We also have to register additional pro- 823 perties to make sure that we cover all the media types that we 824 need, and that we can support all the current variations of H.245. 825 The simultaneous and mutually-exclusive capabilities in H.245 have 826 no way of being described in SDP, as it is linear. Support of 827 H.245 is mandatory. 829 2.1.6. Events, Signals and Packages 831 The MGC may ask to be notified about certain events occurring on an Ter- 832 mination, e.g. off-hook events, and a MGC may request certain signals to 834 Internet draft MEGACO Protocol Proposal March 25, 1999 836 be applied to an Termination, e.g. dial-tone. 838 Events and signals are grouped in Packages within which they share the 839 same namespace which we refer to as event names. Packages are groupings 840 of the events and that are related. For instance, one package may sup- 841 port a certain group of events and signals for Simple analog access 842 lines, and another package may support another group of events and sig- 843 nals for video lines. One or more packages may exist for a given Termi- 844 nation class, and part of the description of the Termination class con- 845 sists of a list of supported packages. 847 Event names are composed of two logical parts, a package name and an 848 event name. Examples of package names are DTMF, MF, Trunk or Line. Exam- 849 ples of event names are off hook, flash hook or "0" (the digit zero). 851 This document defines a basic set of package names and event names. 852 Additional package names and event names can be registered with the 853 IANA. A package definition shall define the name of the package, and the 854 definition of each event belonging to the package. The event definition 855 shall include the precise name of the event (i.e., the code used in the 856 MEGACO protocol), a plain text definition of the event, and, went 857 appropriate, the precise definition of the corresponding signals, for 858 example the exact frequencies of audio signal such as dial tones or DTMF 859 tones. 861 Signals are divided into different types depending on their behavior: 863 * On/off (OO) 864 Once applied, these signals last forever until they are turned off. 865 This may happen either as the result of an event or a new SignalRe- 866 quests (see later). 868 * Time-out (TO) 869 Once applied, these signals last until they are either turned off 870 (by an event or SignalRequests) or a signal specific period of time 871 has elapsed. Depending on package specifications, a signal that 872 times out may generate an "operation complete" event. 874 * Brief (BR) 875 The duration of these signals is so short, that they stop on their 876 own. If an event occurs the signal will not stop, however if a new 877 SignalRequests is applied, the signal will stop. 879 Editor's Note: this point should be debated. One could make a case that 880 events such as strings of DTMF digits should in fact be allowed to com- 881 plete.) 883 TO signals are normally used to alert the Terminations' users, to signal 885 Internet draft MEGACO Protocol Proposal March 25, 1999 887 them that they are expected to perform a specific action, such as hang 888 down the phone (ringing). Transmission of these signals should typically 889 be interrupted as soon as the first of the requested events has been 890 produced. 892 2.1.7. SignalDescriptors 894 A SignalDescriptor is a parameter that contains the set of signals that 895 the MG is asked to apply to the Termination, such as, for example ring- 896 ing, or continuity tones. Signals are identified by their name, which is 897 an event name, (and thus part of a package)and may be qualified by pro- 898 perties. 900 If a signal has already been attached to this Termination, the previous 901 signal is removed, and the specified one is attached. No events which 902 would have occurred on the previous signal will be generated subsequent 903 to a command that modifies the signal descriptor, although the MGC may 904 not have received an event from the previous signal prior to sending the 905 command, and in fact the MG may have detected such an event, but may not 906 have notified the MGC of it when it receives the new command. The 907 behavior of the MG in such a circumstance is not defined. It may send 908 the notification, or it may flush it. 910 Editors note: we should think through this. What if you expected an 911 event after a brief signal, but never get it? Is that always okay? 912 Should we define behavior (notify or flush?). Note that the MGC always 913 has to handle either case. Possibly we define that a notify is always 914 sent, but with a "superceded" qualifier to let the MGC know that it was 915 replaced. Also, what about the case of Terminations that can handle 916 playback of more then one signal at a time? 918 2.1.8. EventDescriptors 920 The EventDescriptor parameter contains a RequestIdentifier and a list of 921 events that the MG is requested to detect and report. Such events 922 include, for example, fax tones, continuity tones, or on-hook transi- 923 tion. The RequestIdentifier is used to correlate this request with the 924 notifications that it may trigger. 926 To each event is associated a notification action, an optional set of 927 embedded events and signal descriptors, and an optional Termination 928 management action. The notification actions are: 930 * Notify the event immediately, together with the accumulated list of 931 observed events, 933 * Accumulate the event in an event buffer, but don't notify yet, 935 Internet draft MEGACO Protocol Proposal March 25, 1999 937 * Accumulate according to a specified Digit Map, 939 * Treat the event according to a specific script, 941 * Ignore the event. (Events that are not specified in the descriptor 942 are, by default, ignored.) 944 The embedded signal descriptor, if present, is used as a replacement for 945 the current signal descriptor. It is possible, for example, to specify 946 that the dial-tone signal be generated when an off-hook event is 947 detected, or that the dial-tone signal be stopped when a digit is 948 detected. If no embedded signal descriptor is specified, the production 949 of signals continues as specified in the command. 951 Editor's note: Embedded events are defined in lieu of a more robust 952 scripting mechanism. If and when such a mechanism is defined, this 953 mechanism may be deprecated or removed [backward compatibility??]. 955 The embedded events descriptor, if present, is used as a replacement for 956 the current event descriptor. It is possible, for example, to specify 957 that DTMF digit collection starts as soon as an off-hook event is 958 detected. 960 MEGACO Protocol implementations must be able to support at least one 961 level of embedding. An embedded events descriptor that respects this 962 limitation shall not contain another Embedded events descriptor. 964 Editor's note: Swap Termination is defined in lieu of a more robust 965 scripting mechanism. If and when such a mechanism is defined, this 966 mechanism may be deprecated or removed (backwards compatibility??). 967 Also, we need a way for the MG to notify (exactly) the MGC of the state 968 change 970 Only one Termination management action is defined, the Swap Termination 971 action. It can be used when a context contains more than one active Ter- 972 mination, in addition to the Termination on which the triggering event 973 is detected. The Swap Termination assumes that the Terminations are 974 assigned an order in the context. The action modifies the Termination 975 Mode parameter of the Terminations in the following fashion: 977 * The mode of the Termination on which the event is detected remains 978 unchanged. 980 * The Termination mode of the other currently active Terminations is 981 set to "inactive." 983 * The termination mode of the "next" active termination is set to 984 "send-receive." 986 Internet draft MEGACO Protocol Proposal March 25, 1999 988 This action can be used to implement call waiting, and possibly other 989 feature scenarios, without incurring a round-trip to the MGC when just 990 changing which termination is active. The EventsDescriptor can map an 991 event (usually hook flash, but could be some other event) to a local 992 function swap audio, which selects the "next" termination in a round 993 robin fashion. If there is only one termination, this action is effec- 994 tively a no-op. 996 2.1.9. Digit Maps 998 The MGC can ask the MG to collect digits dialed by the user. This facil- 999 ity is intended to be used with residential gateways to collect the 1000 numbers that a user dials; it may also be used with trunking gateways 1001 and access gateways alike, to collect the access codes, credit card 1002 numbers and other numbers requested by call control services. 1004 An alternative procedure is for the MG to notify the MGC of the dialed 1005 digits, as soon as they are dialed. However, such a procedure generates 1006 a large number of interactions. It is preferable to accumulate the 1007 dialed numbers in a buffer, and to transmit them in a single message. 1009 The problem with this accumulation approach, however, is that it is hard 1010 for the gateway to predict how many digits it needs to accumulate before 1011 transmission. For example, using the phone on our desk, we can dial the 1012 following numbers: 1014 _______________________________________________________ 1015 | 0 | Local operator | 1016 | 00 | Long distance operator | 1017 | xxxx | Local extension number | 1018 | 8xxxxxxx | Local number | 1019 | #xxxxxxx | Shortcut to local number at| 1020 | | other corporate sites | 1021 | *xx | Star services | 1022 | 91xxxxxxxxxx | Long distance number | 1023 | 9011 + up to 15 digits| International number | 1024 |________________________|_____________________________| 1026 The solution to this problem is to load the MG with a digit map that 1027 correspond to the dial plan. 1029 A digit map is defined by a name and a value. The name is "visible" 1030 within a scope, which can be the gateway itself, a hierarchical group of 1031 terminations, or a specific termination. Digit maps are provisioned 1032 through standard termination management operations such as Add, Modify, 1033 Subtract or Move. The scope of the digit map is determined by the name 1034 of the termination to which the command is applied: 1036 Internet draft MEGACO Protocol Proposal March 25, 1999 1038 * If the command is applied to the "all" wildcarded termination, the 1039 digit map is visible within the scope of the MG, 1041 * If the command is applied to a hierarchical name such as "Com1/3", 1042 the digit map becomes visible within all terminations whose name 1043 begins with the specified prefix. 1045 The DigitMapDescriptor contains a set of Digit Maps names and values to 1046 be assigned: 1048 * A new digit map is created by specifying a name that is not yet 1049 defined at this level of the naming hierarchy. The value must be 1050 present. 1052 * A digit map value is updated by supplying a new value for a name 1053 that is already defined at this level of the naming hierarchy. 1055 * A digit map is deleted by supplying an empty value for a name that 1056 is already defined at this level of the naming hierarchy. A wild- 1057 card naming convention can be used to delete all the digit maps 1058 associated with a specific termination. 1060 The MGC can determine defined digit maps with the Audit command. 1062 The collection of digits according to a digit map may be protected by an 1063 "interdigit timer", which can take two values: 1065 - If the gateway can determine that at least one more digit is 1066 requested for the digit string to match any of the allowed patterns 1067 in the digit map, then the timer value should be set to a long 1068 duration, such as 16 seconds. 1070 - If the digit map specifies that a variable number of additional 1071 digits may be needed (the "." indication at the end of a string), 1072 then the timer value should be set to a medium duration, such as 8 1073 seconds. 1075 The "long interdigit timer" and the "short interdigit timer" are parame- 1076 ters associated with a digit map. 1078 2.1.10. Statistics 1080 The MG may maintain statistics that describe the status of the termina- 1081 tion. The precise properties of the statistics depends on the class of 1082 the termination. 1084 In the RTP class, the properties might include: 1086 Internet draft MEGACO Protocol Proposal March 25, 1999 1088 * Number of packets sent: 1090 * Number of octets sent: 1092 * Number of packets received: 1094 * Number of octets received: 1096 * Number of packets lost: 1098 * Interarrival jitter: 1100 2.2. Termination Management Commands 1102 2.2.1. Add 1104 The Add commands adds a Termination to a Context. 1106 [TerminationId,] 1107 [LocalTerminationDescriptor,] 1108 [RemoteTerminationDescriptor,] 1109 <--- Add(TerminationId, 1110 [TerminationState,] 1111 [LocalTerminationDescriptor,] 1112 [RemoteTerminationDescriptor,] 1113 [EventsDescriptor,] 1114 [SignalDescriptor,] 1115 [DigitMapDescriptor]) 1117 TerminationId is the identifier of the termination that is being added 1118 to the context. The TerminationId may be under-specified by using the 1119 "choose" wildcard convention. This convention must be used for packet 1120 terminations. If the TerminationId is under-specified, the actual iden- 1121 tifier must be assigned by the MG and its complete value returned in the 1122 response. 1124 The LocalTerminationState properties can be fully specified or unspeci- 1125 fied by the MGC. The MG used the specified value when it is present, the 1126 default value for the class of termination otherwise. 1128 The LocalTerminationDescriptor properties can be either fully specified, 1129 under-specified or unspecified by the MGC. The MGC may under-specify a 1130 parameter by providing a loose specification, such as a list of allowed 1131 encoding methods or a range of packetization periods. When the value 1132 are under-specified, the MG returns a fully qualified LocalTermination- 1133 Descriptor. When a value is unspecified, the MG uses the default value 1134 specified for that class of termination. 1136 Internet draft MEGACO Protocol Proposal March 25, 1999 1138 The RemoteTerminationDescriptor is the Termination descriptor for the 1139 remote side of a Termination, for example on the other side of the IP 1140 network. It includes the same fields as in the LocalTerminationDescrip- 1141 tor, i.e. the fields that describe a session according to the SDP stan- 1142 dard. This descriptor may be omitted when the information for the remote 1143 end is not known yet. This information may be provided later via a 1144 ModifyTermination call. 1146 Under-specified properties in RemoteTerminationDescriptor is possible 1147 where the remote side has offered a choice, but the MG may have resource 1148 restrictions which prevent the MGC from being able to make the choice. 1149 When the value of any properties in the descriptor are under-specified, 1150 the MG returns a fully qualified RemoteTerminationDescriptor. When a 1151 value is unspecified, the MG uses the default value specified for that 1152 class of termination. 1154 Physical terminations typically would not have a RemoteTermination- 1155 Descriptor, but the termination class defines whether it does or does 1156 not in all cases 1158 After receiving an Add command that did not include a RemoteTermination- 1159 Descriptor, a MG is in an ambiguous situation. Because it has received a 1160 LocalTerminationDescriptor parameter, it can potentially receive pack- 1161 ets. Because it has not yet received the RemoteTerminationDescriptor of 1162 the other MG, it does not know whether the packets that it receives have 1163 been authorized by the MGC. It must thus navigate between two risks, 1164 i.e. clipping some important announcements or listening to potentially 1165 unintelligible, or unauthorized data. The behavior of the MG is deter- 1166 mined by the value of the Termination Mode element of the Termination- 1167 State parameter: 1169 * If the mode was set to ReceiveOnly, the MG should accept the voice 1170 signals and transmit them through the termination. 1172 * If the mode was set to Inactive, Loopback, Continuity Test, the MG 1173 should ignore the voice signals. 1175 Note that the mode values SendReceive and SendOnly don't make sense in 1176 this situation. They should be treated as errors, and the command should 1177 be rejected. 1179 The EventsDescriptor parameter, if present, provides the list of events 1180 that should be detected on the termination. 1182 The SignalDescriptor parameter, if present, provides the list of signals 1183 that should be produced on the termination. 1185 The command may also include a DigitMapDescriptor. Each parameter 1187 Internet draft MEGACO Protocol Proposal March 25, 1999 1189 describes the name and the value of a digit map in the context of the 1190 termination. 1192 2.2.2. Modify 1194 The Modify command modifies the properties of a Termination. 1196 [LocalTerminationDescriptor,] 1197 [RemoteTerminationDescriptor,] 1198 <--- Modify(TerminationId, 1199 [TerminationState,] 1200 [LocalTerminationDescriptor,] 1201 [RemoteTerminationDescriptor,] 1202 [EventsDescriptor,] 1203 [SignalDescriptor,] 1204 [DigitMapDescriptor]) 1206 TerminationId is the identifier of the termination whose properties are 1207 being modified. The TerminationId may not be under-specified. 1209 The Modify command takes place within the context to which the termina- 1210 tion belongs, or within the "all" context when modifications are to be 1211 made to the termination regardless of context. 1213 The TerminationState properties can be fully specified or unspecified by 1214 the MGC. The MG uses the specified value when it is present, the previ- 1215 ously specified value otherwise. 1217 The LocalTerminationDescriptor properties can be either fully specified, 1218 under-specified or unspecified by the MGC. The MGC may under-specify a 1219 parameter by providing a loose specification, such as a list of allowed 1220 encoding methods or a range of packetization periods. When the value 1221 are under-specified, the MG returns a fully qualified LocalTermination- 1222 Descriptor. When a value is unspecified, the MG keeps the value that 1223 resulted from the previous ADD or MODIFY command. 1225 The RemoteTerminationDescriptor properties can be either fully speci- 1226 fied, under-specified, or left unspecified by the MGC. When a value is 1227 unspecified, the MG keeps the value that resulted from the previous ADD 1228 or MODIFY command. A value is under-specified, the MG performs a selec- 1229 tion and returns a RemoteTerminationDescriptor that documents the 1230 choices made. 1232 The EventsDescriptor parameter, if present, provides the list of events 1233 that should be detected on the termination. 1235 Internet draft MEGACO Protocol Proposal March 25, 1999 1237 The SignalDescriptor parameter, of present, provides the list of signals 1238 that should be produced on the termination. 1240 The command may also include a DigitMapDescriptor. Each parameter 1241 describes the name and the value of a digit map in the context of the 1242 termination. 1244 Modify of a termination outside a context changes the default values for 1245 TerminationState, LocalTerminationDescriptor, RemoteTerminationDescrip- 1246 tor, EventsDescriptor, and SignalDescriptor on that termination. Modify 1247 of a wildcarded termination ID outside of a context changes all 1248 instances of the termination covered by the wildcard specification. 1250 Modify of a TerminationID where only a subset of the hierarchy is named 1251 (such as "com1/3" where com1 represents a channelized T3 as described 1252 above), changes properties assigned to the logical unit covered by the 1253 name specified. In the example, changing "com1/3"'s "linecode = B8ZS" 1254 would alter the line coding of the 3rd DS1 in the T3 to B8ZS. Simi- 1255 larly, changing the linecode of "com1/*" would change the line coding 1256 for all DS1s in the T3. 1258 Modify can also be used to program the MG to Notify the MGC at particu- 1259 lar intervals if no other communication is occurring between the MGC and 1260 the MG. This has the effect of providing a heartbeat message from the 1261 MG to the MGC. 1263 2.2.3. Subtract 1265 The Subtract commands disconnects a termination from a Context and 1266 returns statistics on the termination. 1268 Statistics | 1269 *[TerminationId, 1270 Statistics] 1271 <---- Subtract(TerminationId, 1272 [TerminationState,] --include quarantine, not mode? 1273 [EventsDescriptor,] 1274 [SignalDescriptor,] 1275 [DigitMapDescriptor]) 1277 TerminationId is the identifier of the termination whose properties are 1278 being modified. The TerminationId is either a fully specified value, or 1279 a wildcard value indicating that all the terminations of a given context 1280 shall be removed. 1282 When all terminations have been removed from a specified context, that 1284 Internet draft MEGACO Protocol Proposal March 25, 1999 1286 context is deleted by the MG. 1288 Ephemeral terminations are deleted when they are removed from their con- 1289 text. The Subtract command, when applied to an ephemeral termination, 1290 shall not have any other parameter than the TerminationId. 1292 The LocalTerminationDescriptor and RemoteTerminationDescriptor of a per- 1293 manent termination are reset to their default value when the termination 1294 is removed from its context. 1296 When applied to a permanent termination, the Subtract command may 1297 include TerminationState, EventsDescriptor, SignalDescriptor and Digit- 1298 MapDescriptor parameters. These parameters are processed as defined in 1299 the Modify command. 1301 The command returns the statistics that were observed on the termina- 1302 tion. When a wildcard is used, the command returns a termination iden- 1303 tifier and statistics for each of the terminations whose name matched 1304 the wildcard. 1306 2.2.4. Move 1308 The Move command moves a Termination to another Context. The termination 1309 is removed from its old context and is added to the new context as an 1310 atomic operation. While this action appears similar to the packaging of 1311 a subtract and an add command, it does not have the side effect of 1312 deleting an ephemeral termination that the subtract command would cause. 1314 [LocalTerminationDescriptor,] 1315 [RemoteTerminationDescriptor] 1316 <-- Move(TerminationId, 1317 [TerminationState,] 1318 [LocalTerminationDescriptor,] 1319 [RemoteTerminationDescriptor,] 1320 [EventsDescriptor,] 1321 [SignalDescriptor,] 1322 [DigitMapDescriptor]) 1324 The TerminationId is the fully specified name of a Termination that is 1325 being moved into the context specified for the transaction. The termi- 1326 nation is subtracted from its previous context. If it was the last ter- 1327 mination in this previous context, that context is deleted. A context 1328 with only one termination is permitted. 1330 The TerminationState, LocalTerminationDescriptor, RemoteTermination- 1331 Descriptor, EventsDescriptor, SignalDescriptor, and DigitMapDescriptor 1332 parameters are processed as in the Modify command. Management Commands 1334 Internet draft MEGACO Protocol Proposal March 25, 1999 1336 2.2.5. Audit 1338 The Audit request returns properties associated with terminations: 1340 [TerminationId,] 1341 [TerminationState,] 1342 [LocalTerminationDescriptor,] 1343 [RemoteTerminationDescriptor,] 1344 [EventsDescriptor,] 1345 [SignalDescriptor,] 1346 [DigitMapDescriptor,] 1347 [Capabilities] 1348 [Statistics] 1349 <-- Audit (TerminationId, 1350 RequestedInfo) 1352 The TerminationId identifies the termination that is being audited. The 1353 wildcard convention shall not be used. The command shall be applied 1354 either in the null context, for terminations that are not part of an 1355 active context, or in the specific context of the termination(s). 1357 The (possibly empty) RequestedInfo parameter describes the information 1358 that is requested for the TerminationId specified. The following termi- 1359 nation info can be audited with this command: 1361 TerminationState, LocalTerminationDescriptor, RemoteTermination- 1362 Descriptor, EventsDescriptor, SignalDescriptor, DigitMapDescriptor, 1363 Statistics and Capabilities. 1365 The TerminationState, LocalTerminationDescriptor, RemoteTermination- 1366 Descriptor, EventsDescriptor, SignalDescriptor, and DigitMapDescriptor 1367 values are the values currently used by the termination. 1369 The Capabilities parameter returns values such as compression algo- 1370 rithms, packetization period, connection networks that the MG is ready 1371 to support for that termination. In addition, the option can also be 1372 used to encode the event packages that the termination supports, and the 1373 list of TerminationState parameter values that the MG is ready to sup- 1374 port for that termination. 1376 The Statistics parameter returns the current state of the termination 1377 statistics that would be generated on a Subtract. This option provides 1378 mid-call statistics. 1380 If the RequestedInfo parameter is empty, Audit returns the TerminationID 1381 only. Combining this with using null and unspecified for ContextID and 1382 wildcarding TerminationID, the Audit command can return a wide variety 1384 Internet draft MEGACO Protocol Proposal March 25, 1999 1386 of information: 1388 _____________________________________________________________________ 1389 | ContextID TerminationID Returns | 1390 |____________________________________________________________________| 1391 | Specific all List of terminations in a Context | 1392 | Specific wildcard List of terminations in a Context, | 1393 | whose name matches the wildcard | 1394 | Null root name Audit of MG (base state & events) | 1395 | Null all List of all terminations in the MG | 1396 | Null all/ List of all "top level" terminations | 1397 | Null wildcard List of all terminations whose | 1398 | name matches the wildcard. | 1399 | unspecified root name Audit of MG (null context) | 1400 | unspecified all List of all terminations in the MG | 1401 | and the context[s] to which they are | 1402 | associated (maybe null) | 1403 | unspecified all/ List of all "top level" terminations,| 1404 | in the context to which they are | 1405 | associated (maybe null) | 1406 | unspecified wildcard List of all terminations whose | 1407 | name matches the wildcard, in the | 1408 | context[s] to which they are | 1409 | associated (maybe null) | 1410 |____________________________________________________________________| 1412 Editor's note: We need to audit the state of digit collection. This can 1413 Be accomplished by allowing an audit of the "ObservedEvents" parameter, 1414 that would return the list of events accumulated so far. 1416 The MGC can effect a "Are you alive" poll by using the Audit command on 1417 the null context with the root name as the TerminationID and an empty 1418 RequestedInfo. This will result in a short response from the MG. 1420 2.3. MG-Issued Commands 1422 2.3.1. Notify 1424 Notify (TerminationId, 1425 ObservedEvents) 1427 TerminationId is the name for the termination in the MG which is issuing 1428 the Notify command, as defined in section 2.1.1. The identifier must be 1429 a fully qualified termination identifier, including the domain name of 1430 the MG. The MG must keep the name of the MGC that requested the Notifi- 1431 cation, suitably updated by failover procedures. The local part of the 1433 Internet draft MEGACO Protocol Proposal March 25, 1999 1435 name must not use the wildcard convention. 1437 ObservedEvents is a parameter that contains a RequestIdentifier and a 1438 list of events that the MG detected in the order they have been 1439 detected. The RequestIdentifier repeats the RequestIdentifier parameter 1440 of the EventDescriptor that triggered this notification. It is used to 1441 correlate this notification with the request that triggered it. 1443 The events in the list must be reported in the order in which they were 1444 detected. The list may only contain the identification of events that 1445 were requested in the RequestedEvents parameter of the triggering 1446 EventsDescriptor. It must contain the events that were either accumu- 1447 lated (but not notified) or treated according to digit map (but no match 1448 yet), and the final event that triggered the detection or provided a 1449 final match in the digit map. 1451 Each element in the list must contain the name of the event, and may 1452 also contains properties associated with the event and a notation of the 1453 time at which the event was detected. The MG MUST NOT send an unsoli- 1454 cited notify. 1456 There is an Event defined for all MGs that can be programmed with an 1457 interval. This event can be used for a "heart beat" notify message from 1458 MG to MGC. Use of this event is optional by the MGC. Any message sent 1459 by the MG to the MGC restarts the timer for the event. 1461 2.3.2. ServiceChange 1463 The ServiceChange command is used by the MG to signal that a termina- 1464 tion, or a group of termination, or the entire gateway, is about to be 1465 taken out of service, or has been brought back in to service. 1467 [MGCIdentity] 1468 <------- ServiceChange ( TerminationId, 1469 ServiceChangeMethod, 1470 ServiceChangeReason, 1471 [ServiceChangeDelay]) 1473 The TerminationId identifies the terminations that are taken in or out 1474 of service. The "all" wildcard convention may be used to apply the com- 1475 mand to a group of terminations, such as for example all terminations 1476 that are attached to a specified interface, or even all terminations 1477 that are attached to a given MG. The "choose" wildcard convention shall 1478 not be used. Hierarchical names can be used to specify that an element 1479 of a MG, such as for example a digital multiplex, is being brought out 1480 of service. The root keyword indicates the gateway itself is restart- 1481 ing. 1483 Internet draft MEGACO Protocol Proposal March 25, 1999 1485 The ServiceChangeMethod parameter specifies the type of ServiceChange. 1486 Three values have been defined: 1488 * A "graceful" ServiceChange method indicates that the specified ter- 1489 minations will Be taken out of service after the specified delay. 1490 The established connections are not yet affected, but the MGC 1491 should refrain from establishing new connections, and should try to 1492 gracefully tear down the existing connections. 1494 * A "forced" ServiceChange method indicates that the specified termi- 1495 nations were taken abruptly out of service. The established connec- 1496 tions, if any, are lost. 1498 Editor's note: A decision must be made as to whether the MGC must Sub- 1499 tract the Terminations from the Context to get statistics, or the Servi- 1500 ceChange command automatically sends statistics, or the Audit command 1501 can be used to get statistics. 1503 * A "Restart" method indicates that service will be restored on the 1504 terminations after the specified ServiceChangeDelay The termina- 1505 tions are not currently attached to any context. 1507 ServiceChangeReason supplies the reason why the termination is being 1508 taken out of service or brought back into service. 1510 The optional ServiceChangeDelay parameter is expressed as a number of 1511 seconds. If the number is absent, the delay value should be considered 1512 null. In the case of the "graceful" method, a null delay indicates that 1513 the MGC should simply wait for the natural termination of the existing 1514 connections, without establishing new connections. The ServiceChangeDe- 1515 lay is always considered null in the case of the "forced" method. 1517 The MGC may return an MGCIdentity parameter that describes the MGC that 1518 should preferably be contacted by the MG. In this case the MG must 1519 reissue the ServiceChange command to the new MGCIdentity 1521 The ServiceChange command specifying the root keyword for the Termina- 1522 tionId is the registration command by which an MG announces its 1523 existence to the MGC. The MG is expected to be provisioned with the 1524 name of one primary and some number of alternate MGCs. The Servi- 1525 ceChange method shall be "forced". Acknowledgement of the ServiceChange 1526 completes the registration process. 1528 If an MG knows that a Termination is about to go out of service, it can 1529 issue a ServiceChange with ServiceChangeMethod set to "graceful", and 1530 specify a ServiceChangeDelay. If an MG has just detected that a Termina- 1531 tion or a set of Terminations has just gone out of service, it issues a 1532 ServiceChange with ServiceChangeMethod set to "forced". [Editor's Note: 1534 Internet draft MEGACO Protocol Proposal March 25, 1999 1536 what if the Termination(s) have just gone down, and are still out of 1537 service? don't we need to indicate that? and then the MG would issue a 1538 new ServiceChange when they are back in service] 1540 An MGC may inform an MG that it should send subsequent commands to 1541 another MGC by returning the identity of a new MGC when responding to 1542 ServiceChange. The MG may need to reissue ServiceChange to the new MGC. 1544 2.4. Error Codes 1546 All MEGACO Protocol commands are acknowledged. The acknowledgment car- 1547 ries a return code, which indicates the status of the command. The 1548 return code is value for which three ranges have been defined: 1550 * successful completion, 1552 * transient error, 1554 * permanent error. 1556 3. Security Considerations 1558 If unauthorized entities could use the MEGACO protocol, they would be 1559 able to set-up unauthorized calls, or to interfere with authorized 1560 calls. The primary security mechanism employed by the protocol is IPSEC 1561 [RFC2401]. Support of the AH header [RFC2402] affords authentication 1562 and integrity protection on messages passed between the MG and the MGC. 1563 Support of the ESP header [RFC2406] can provide confidentiality of mes- 1564 sages if desired. 1566 Implementation of IPSEC requires that the AH and ESP headers be inserted 1567 between the IP and UDP headers. This presents an implementation problem 1568 for MEGACO protocol implementations where the underlying network imple- 1569 mentation does not support IPSEC. As an interim solution, the MEGACO 1570 protocol defines an optional AH header within the protocol header. The 1571 header fields are exactly those of the AH header as defined in 1572 [RFC2402]. The semantics of the header fields are the same as the 1573 "transport mode" of [RFC2402], except for the calculation of the 1574 Integrity Check Value (ICV). In IPSEC, the ICV is calculated over the 1575 entire IP packet including the IP header. This prevents spoofing of the 1576 IP addresses. To retain the same functionality, the ICV calculation 1577 should be performed across the entire MEGACOP message prepended by a 1578 synthesized IP header consisting of a 32 bit source IP address, a 32 bit 1579 destination address and an 16 bit UDP port in the MSBs of a 32 bit word. 1580 The Authentication Data is assumed to be zero as in [RFC2402]. The 1581 "Next Header" and "RESERVED" fields MUST be set to "zero". 1583 The ICV calculation is thus performed over a structure that would look 1585 Internet draft MEGACO Protocol Proposal March 25, 1999 1587 like: 1589 0 1 2 3 1590 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 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Source IP Address | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Destination IP Address | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | UDP Port | RESERVED | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Next Header | Payload Len | RESERVED | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Security Parameters Index (SPI) | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Sequence Number Field | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | | 1605 + Authentication Data (variable) + 1606 | | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | | 1609 + message contents (variable) + 1610 | | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 When the AH-within-MEGACO mechanism is employed when TCP is the tran- 1614 sport Layer for MEGACOP, the UDP Port above becomes the TCP port, and 1615 all other operations are the same. 1617 Implementations of the MEGACO protocol using IPv4 MUST support the 1618 interim AH-within-MEGACO scheme. Implementations SHOULD implement IPSEC 1619 AH header if the underlying network system supports it. Implementations 1620 MAY support the ESP header. IPSEC and AH-within-MEGACO MUST NOT be used 1621 at the same time. IPv6 Implementations are assumed to have IPSEC imple- 1622 mentations and MUST NOT use the AH-within-MEGACO scheme. 1624 When employing the AH header, either in IPSEC or AH-within-MEGACO, all 1625 implementations of the protocol MUST implement section 5 of [RFC2402] 1626 which defines a minimum set of algorithms for integrity checking using 1627 manual keys. MECACOP implementations SHOULD implement IKE [RFC2409] to 1628 permit more robust keying options. MEGACOP implementations employing 1629 IKE SHOULD implement RSA signatures and authentication with RSA public 1630 key encryption. MECACOP implementations employing the ESP header 1631 [RFC2406] MUST implement section 6 of [RFC2406] which defines a minimum 1632 set of algorithms for integrity checking and encryption. 1634 Internet draft MEGACO Protocol Proposal March 25, 1999 1636 NOTE: The AH-within-MEGACO scheme is defined as interim. The next ver- 1637 sion of this protocol is likely to deprecate it (backwards compatibil- 1638 ity?). 1640 Adequate protection of the connections must be achieved if the MG and 1641 the MGC only accept messages for which authentication services of the AH 1642 header have been configured. Employing the ESP header for encryption 1643 service must provide additional protection against eavesdropping, thus 1644 forbidding third parties from monitoring the connections set up by a 1645 given termination 1647 The encryption service should also be requested if the session descrip- 1648 tions are used to carry session keys, as defined in SDP. 1650 These procedures do not necessarily protect against denial of service 1651 attacks by misbehaving MGs or misbehaving MGCs. However, they will pro- 1652 vide an identification of these misbehaving entities, which should then 1653 be deprived of their authorization through maintenance procedures. 1655 3.1. Protection of Media Connections 1657 The protocol allows the MGC to provide MGs with "session keys" that can 1658 be used to encrypt the audio messages, protecting against eavesdropping. 1660 A specific problem of packet networks is "uncontrolled barge-in." This 1661 attack can be performed by directing media packets to the IP address and 1662 UDP port used by a connection. If no protection is implemented, the 1663 packets must be decompressed and the signals must be played on the "line 1664 side". 1666 A basic protection against this attack is to only accept packets from 1667 known sources, checking for example that the IP source address and UDP 1668 source port match the values announced in the RemoteTerminationDescrip- 1669 tor But this has two inconveniences: it slows down connection establish- 1670 ment and it can be fooled by source spoofing: 1672 * To enable the address-based protection, the MGC must obtain the 1673 remote session description of the egress MG and pass it to the 1674 ingress MG. This requires at least one network roundtrip, and 1675 leaves us with a dilemma: either allow the call to proceed without 1676 waiting for the round trip to complete, and risk for example, 1677 "clipping" a remote announcement, or wait for the full roundtrip 1678 and settle for slower call-set-up procedures. 1680 * Source spoofing is only effective if the attacker can obtain valid 1681 pairs of source destination addresses and ports, for example by 1682 listening to a fraction of the traffic. To fight source spoofing, 1683 one could try to control all access points to the network. But 1685 Internet draft MEGACO Protocol Proposal March 25, 1999 1687 this is in practice very hard to achieve. 1689 An alternative to checking the source address is to encrypt and authen- 1690 ticate the packets, using a secret key that is conveyed during the call 1691 set-up procedure. This will not slow down the call set-up, and provides 1692 strong protection against address spoofing. 1694 Internet draft MEGACO Protocol Proposal March 25, 1999 1696 4. Syntax 1698 Editor's Note: In this edition of the document, a decision has not 1699 been made on the encoding of the protocol. The following EBNF 1700 description is therefore somewhat awkward. Productions with the word 1701 "Token" are not defined. In an ASCII encoding, they would typically be 1702 some kind of keyword and a separator. In a binary encoding, they would 1703 be a code. The productions use the terms "digit", as in 9DIGIT, which 1704 would be understood as a 9 character numeric string in ASCII, or a 32 bit 1705 number in binary, although there may be small differences in coding 1706 when the decision is actually made. The syntax leaves out separators and 1707 whitespace which would be necessary in an ASCII encoding. It leaves out 1708 length fields, which may be necessary in a binary encoding. 1710 megacoMessage = authenticatedMessage / message 1712 authenticatedMessage = authToken authenticationHeader message 1714 authenticationHeader = ; as defined in RFC [] 1716 message = SystemID *(transactionRequest / transactionAccept / 1717 transactionReject) 1718 ; question of whether SystemID is there at all 1719 ; Version might be in registration in msg header if here 1721 transactionRequest = transToken transactionId 1*Action 1722 transactionAccept = acceptToken transactionId 1*ActionAccept 1723 transactionReject = rejectToken transactionId 1*ActionReject 1725 ActionAccept = ctxToken contextId *commandAccept 1726 commandAccept = commandName [terminationId] *(parameters) 1728 ActionReject = ctxToken contextID *commandReject 1729 CommandReject = commandName [terminationID] errorMessage 1730 errorMessage = errorCode errorText 1731 errorCode = OCTET STRING(3) ;could be extended 1732 errorText = OCTET STRING 1734 transactionId = INTEGER32 1735 SystemId = domainName [":" portNumber] 1736 domainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821 1737 portNumber = INTEGER16 ;should this be 5digit, 16 bit? 1739 version = megacopToken Version Profile 1740 Version = OCTET STRING 1741 Profile = OCTET STRING ;need exlpanation 1743 Action = ctxToken contextId 1*command 1745 Internet draft MEGACO Protocol Proposal March 25, 1999 1747 contextId = nullToken / unspecifiedToken / INTEGER32 1749 command = commandName terminationId parameters 1751 commandName = (addToken / 1752 subtractToken / 1753 modifyToken / 1754 moveToken / 1755 auditToken / 1756 notifyToken / 1757 serviceChangeToken ) 1759 terminationId = "." / LocalNamePart / 1760 LocalNamePart *("/"LocalNamePart) 1762 LocalNamePart = AnyNameToken / AllNameToken / NameString 1764 AnyName = "$" 1766 AllNames = "*" 1768 NameString = 1*(SuitableCharacters) 1770 parameters = ([ TSToken TerminationState ] 1771 [LTToken LocalTerminationDescriptor ] 1772 [RTToken RemoteTerminationDescriptor ] 1773 [EDToken EventsDescriptor ] 1774 [SDToken SignalDescriptor ] 1775 [DMToken DigitMapDescriptor ] 1776 [RIToken RequestedInfo ] 1777 [RMToken ServiceChangeMethod ] 1778 [RDToken ServiceChangeDelay ] 1779 [OEToken ObservedEvents ] 1780 [STToken Statistics ] 1781 [CpToken Capabilities ] 1782 [MiToken MGCIdentity ] 1783 *[extensionParameterToken parameterValue] ]) ;fix 1784 TerminationState = stateParameter ;leftover production for bracketing 1785 stateParameter = ([modeToken TerminationMode] 1786 [quarantineHandlingToken QuarantineHandling ]) ;fix there are 2 of them 1787 TerminationMode = sendonlyToken / recvonlyToken / sendrecvToken / 1788 inactiveToken / loopbackToken / conttestToken / OutOfService 1789 QuarantineHandling = loopControl / processControl / ;fix 1790 (loopControl processControl ) 1791 loopControl = stepToken / loopToken 1792 processControl = processToken / discardToken 1794 LocalTerminationDescriptor = TerminationDescriptor 1796 Internet draft MEGACO Protocol Proposal March 25, 1999 1798 RemoteTerminationDescriptor = TerminationDescriptor 1800 eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange) 1801 packageName = 1*(SuitableCharacters) 1802 eventId = 1*(SuitableCharacters) ;could be an Integer32 1803 EventsDescriptor = [requestedEvent 0*(requestedEvent)] 1804 requestedEvent = eventName [0*(eventParameters)] [requestedActions] 1805 eventParameters = *(parameterName parameterValue) 1806 requestId = INTEGER32 1808 eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" / 1809 (DIGIT "-" DIGIT)/(DTMFLetter "-" DTMFLetter)) "]" 1810 ;may want to remove the above 1812 requestedActions = requestedAction [ embeddedSignalEvent ] 1813 [ mediaAction ] 1814 requestedAction = NotifyActionToken / AccumlateToken / 1815 AccumulateByDigitMapToken digitMapName / 1816 ScriptToken scriptName 1817 embeddedSignalEvent = [EventDescriptorToken EventsDescriptor ] 1818 [SignalDescriptorToken SignalDescriptor ] 1819 mediaAction = SToken 1821 SignalDescriptor = [ SignalRequest 0*(SignalRequest) ] 1822 SignalRequest = eventName [eventParameters ] 1823 eventParameters = eventParameter 0*( eventParameter ) 1824 eventParameter = eventParameterString / quotedString 1825 eventParameterString = 1*() 1827 DigitMapDescriptor = digitMapName DigitMapValue 1828 digitMapName = STRING 1829 DigitMapValue = ["L:" longTimer ","] ["M:" mediumTimer ","] DigitMap 1830 longTimer = 1*2DIGIT 1831 shortTimer = 1*2DIGIT 1832 DigitMap = DigitString / "(" DigitStringList ")" 1833 DigitStringList = DigitString *( "|" StringList ) 1834 DigitString = 1*(DigitStringElement) 1835 DigitStringElement = DigitPosition ["."] 1836 DigitPosition = DigitMapLetter / DigitMapRange 1837 DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / MFSig / "T" 1838 MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3" / 1839 DigitMapRange = "x" / "[" DigitLetters "]" 1840 DigitLetter = *((DIGIT "-" DIGIT ) / DigitMapLetter) 1842 RequestedInfo = [infoCode 0*(infoCode)] 1843 infoCode = TerminationStateToken / LocalTermDescToken / RemoteTermDescToken / 1844 EventDeccToken / SignalDescToken / 1845 DigMapToken / StatsToken / CapsToken / 1847 Internet draft MEGACO Protocol Proposal March 25, 1999 1849 ServiceChangeMethod = GracefulToken / ForcedToken / ServiceChangeToken 1850 ServiceChangeDelay = INTEGER32 1852 ObservedEvents = (requestId [ observedEvent *(observedEvent) ]) 1853 observedEvent = [ TimeNotation ] SignalRequest 1854 TimeNotation= INTEGER64; 64 bits NTP time stamp ? 1856 Statistics = [StatisticsParameter 0*( StatisticsParameter ) ] 1857 StatisticsParameter = ( PktsSentToken packetsSent ) 1858 / ( OctetsSentToken octetsSent ) 1859 / ( PktsRecvdToken packetsReceived ) 1860 / ( OctetsRecvdToken octetsReceived ) 1861 / ( PktsLostToken packetsLost ) 1862 / ( JitterToken jitter ) 1863 / ( AvgLatencyToken averageLatency ) 1864 / ( StatisticsParameterExtensionName 1865 StatisticsParameterExtensionValue ) 1866 packetsSent = INTEGER64 1867 octetsSent = INTEGER64 1868 packetsReceived = INTEGER64 1869 octetsReceived = INTEGER64 1870 packetsLost = INTEGER32 1871 jitter = INTEGER32 1872 averageLatency = INTEGER32 1873 StatisticsParameterExtensionName = "X" "-" 2*ALPHA ;fix 1874 StatisticsParameterExtensionValue = INTEGER32 1876 extensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT) 1877 parameterString = 1*(%x20-7F) 1879 Capabilities = ;not defined yet 1881 MGCIdentity = SystemId 1883 SuitableCharacter= DIGIT / ALPHA / "+" / "-" / "_" / "&" / 1884 "!" / "'" / "|" / "=" / "#" / "?" / "/" / 1885 "." / "$" / "*" / ";" / "@" / "[" / "]" / 1886 "^" / "`" / "{" / "}" / "~" 1887 quotedString = DQUOTE visibleString 1888 0*(quoteEscape visibleString) DQUOTE 1889 quoteEscape = DQUOTE DQUOTE 1890 visibleString = (%x00-21 / %x23-FF) 1892 TerminationDescriptor = ;Undecided, could be SDP as in RFC 2327 1894 Internet draft MEGACO Protocol Proposal March 25, 1999 1896 ************************************************************** 1897 * Editor's Note: All text following this point has not * 1898 * been reviewed by the design team. It is presented * 1899 * unedited to aid the reader in understanding the * 1900 * protocol. Implications on encoding or other unresolved * 1901 * issues should be disregarded * 1902 ************************************************************** 1904 4.1. Termination Names 1906 Each command contains a unique termination name. The following rules for 1907 construction and interpretation of the termination names MUST be sup- 1908 ported: 1910 1) The individual terms of the naming path MUST be separated by a sin- 1911 gle slash ("/", ASCII 2F hex). 1913 2) The individual terms are character strings composed of letters, 1914 digits or other printable characters, with the exception of charac- 1915 ters used as delimiters ("/", "@"), characters used for wildcarding 1916 ("*", "$") and white spaces. 1918 3) Wild-carding is represented either by an asterisk ("*") or a dollar 1919 sign ("$") for the terms of the naming path which are to be wild- 1920 carded. Thus, if the full naming path looks like 1922 term1/term2/term3 1924 then the termination name looks like this depending on which terms 1925 are wild- carded: 1927 */term2/term3 if term1 is wild-carded 1928 term1/*/term3 if term2 is wild-carded 1929 term1/term2/* if term3 is wild-carded 1930 term1/*/* if term2 and term3 are wild-carded, 1931 etc. 1933 In each of these examples a dollar sign could have appeared instead 1934 of an asterisk. 1936 4) A term represented by an asterisk is to be interpreted as: "use ALL 1937 values of this term known within the scope of the Media Gateway". 1938 A term represented by a dollar sign is to be interpreted as: "use 1939 ANY ONE value of this term known within the scope of the Media 1940 Gateway". The description of a specific command may add further 1942 Internet draft MEGACO Protocol Proposal March 25, 1999 1944 criteria for selection within the general rules given here. 1946 Examples of TerminationId: 1948 /MG7.network.com/com1/channel1 ; fully qualified termination name 1950 ; one channel on device "com1" 1952 ; channels on device "com1" 1954 ; all devices on MG 1956 ; on all devices on MG 1958 When an ephemeral termination is to be created, the termination class of 1959 the Desired termination type is specified as the first component of the 1960 name with "/$" concatenated on the class name. For example, "RTP/$" 1961 would request a new Termination from the RTP termination class 1963 4.2. Events, Signals and Packages 1965 Event names are case insensitive and are composed of two logical parts, 1966 a package name and an event name. Both names are strings of letters, 1967 hyphens and digits, with the restriction that hyphens shall never be the 1968 first or last characters in a name. Package or event names are not case 1969 sensitive - values such as "hu", "Hu", "HU" or "hU" should be considered 1970 equal. 1972 In textual representations, the package name, when present, is separated 1973 from the event name by a slash ("/"). The package name is in fact 1974 optional. Each termination-type has a default package associated with 1975 it, and if the package name is excluded from the event name, the default 1976 package name for that termination-type is assumed. For example, for an 1977 analog access line, the following two event names are equal: 1979 l/dl dial-tone in the line package for an analog access line. 1981 dl dial-tone in the line package (default) for an analog access line. 1983 This document defines a basic set of package names and event names. 1984 Additional package names and event names can be registered with the 1985 IANA. A package definition shall define the name of the package, and the 1986 definition of each event belonging to the package. The event definition 1987 shall include the precise name of the event (i.e., the code used in the 1988 MEGACO protocol), a plain text definition of the event, and, went 1989 appropriate, the precise definition of the corresponding signals, for 1991 Internet draft MEGACO Protocol Proposal March 25, 1999 1993 example the exact frequencies of audio signal such as dial tones or DTMF 1994 tones. 1996 In addition, implementers can gain experience by using experimental 1997 packages. The names of experimental packages must start with the two 1998 characters "x-"; the IANA shall not register package names that start 1999 with these characters. 2001 Digits, or letters, are supported in many packages, notably "DTMF", "MF" 2002 and "pulse". Digits and letters are defined by the rules "Digit" and 2003 "Letter" in the definition of digit maps. This definition refers to the 2004 digits (0 to 9), to the asterisk or star ("*") and orthotrope, number or 2005 pound sign ("#"), and to the letters "A", "B", "C" and "D", as well as 2006 the timer indication "T". These letters can be combined in "digit 2007 string" that represent the keys that a user punched on a dial. In addi- 2008 tion, the letter "X" can be used to represent all digits, and the sign 2009 "$" can be used in wildcard notations. The need to easily express the 2010 digit strings has a consequence on the form of event names: 2012 An event name that does not denote a digit should always contain at 2013 least one character that is neither a digit, nor one of the letters 2014 A, B, C, D, T or X. (Such names should not contain the special 2015 signs "*", "#", "/" or "$".) 2017 An MGC may often have to ask a MG to detect a group of events. Two con- 2018 ventions can be used to denote such groups: 2020 * The wildcard convention can be used to detect any event belonging 2021 to a package, or a given event in many packages, or event any event 2022 in any package supported by the MG. 2024 * The regular expression Range notation can be used to detect a range 2025 of digits. 2027 The star sign (*) can be used as a wildcard instead of a package name, 2028 and the dollar sign ("$") or the keyword "all" can be used as a wildcard 2029 instead of an event name: 2031 A name such as "foo/all" denotes all events in package "foo" 2032 A name such as "*/bar" denotes the event "bar" in any package sup- 2033 ported by the MG 2034 The names "*" or "*/all" denote all events supported by the MG. 2036 The MGC can ask an MG to detect a set of digits or letters either by 2037 individually describing those letters, or by using the "range" notation 2038 defined in the syntax of digit strings. For example, the MGC can: 2040 Use the letter "x" to denote "any letter or digit." 2042 Internet draft MEGACO Protocol Proposal March 25, 1999 2044 Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound 2045 sign. 2047 Events and signals are described in packages. The package description 2048 must provide, for each events, the following information: 2050 * The description of the event and its purpose, which should mean the 2051 actual signal that is generated by the client (i.e., xx ms FSK 2052 tone) as well as the resulting user observed result (i.e., MW light 2053 on/off). 2055 * The detailed characteristics of the event, such as for example fre- 2056 quencies and amplitude of audio signals, modulations and repeti- 2057 tions, 2059 * The typical and maximum duration of the event. 2061 Package descriptions should describe, for all signals, their type (OO, 2062 TO, BR). They should also describe the maximum duration of the TO sig- 2063 nals. 2065 4.3. Digit Maps 2067 A digit map is expressed using a syntax derived from the Unix system 2068 command, egrep. For example, the dial plan described above in section 2 2069 results in the following digit map: 2071 (0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) 2073 The "DigitMapValue" rule of protocol syntax describes a format that con- 2074 tains three parameters: 2076 * An optional notation of a "Long Timer," in seconds, 2078 * An optional notation of a "Medium Timer," in seconds, 2080 * The actual expression of the map. 2082 The timer parameters are optional. When they are not specified, default 2083 values are assumed. Suggested default values are 16 seconds for the 2084 long timer, 8 seconds for the medium timer. 2086 A DigitMap, according to this syntax, is defined either by a "string" or 2087 by a list of strings. Each string in the list is an alternative number- 2088 ing scheme. Each element in the string is composed of a set of string 2089 elements, each of which can optionally be followed by a repetition char- 2090 acter. The possible elements are: 2092 Internet draft MEGACO Protocol Proposal March 25, 1999 2094 * A digit, 2096 * The special characters "#" and "*" (number sign and star sign), 2098 * The letters A, B, C or D, 2100 * The symbols "K0", "K1", "K2", "S0", "S1", "S2" and "S3", which may 2101 be used in MF signalling, 2103 * A range notation such as "[0-9]" or "[0-9*#]", that would be 2104 matched by a single occurence of any letter in the range, 2106 * The character "x", that would be matched by any digit between 0 and 2107 9. 2109 Each element may be followed by the repetition symbol "." (dot), to 2110 denote a variable number of occurences of the position. 2112 A MG that detects digits, letters or timers must: 2114 1) Add the event parameter code as a token to the end of an internal 2115 state variable called the "current dial string" 2117 2) Apply the current dial string to the digit map table, attempting a 2118 match to each regular expression in the Digit Map in lexical order 2120 3) If the result is under-qualified (partially matches at least one 2121 entry in the digit map), do nothing further. 2123 If the result matches, or is over-qualified (i.e. no further digits 2124 could possibly produce a match), notify the currently accumulated events 2125 to the MGC, in the order in which they occurred. 2127 When an MG is unable to store a digit map, it shall return an error to 2128 the MGC. MGs must be able to store at least n*2 + 8 Digit Maps where n 2129 is the number of terminations the MG can support. 2131 4.4. Statistics 2133 The MG may maintain statistics that describe the status of the termina- 2134 tion. The precise properties of the statistics depends on the class of 2135 the termination. 2137 In the RTP class, the some the properties are: 2139 Number of packets sent: 2140 The total number of RTP data packets transmitted by the sender 2141 since starting transmission on this connection. The count is not 2143 Internet draft MEGACO Protocol Proposal March 25, 1999 2145 reset if the sender changes its synchronization source identifier 2146 (SSRC, as defined in RTP), for example as a result of a Modify com- 2147 mand. The value is zero if the connection was set in "receive only" 2148 mode. 2150 Number of octets sent: 2151 The total number of payload octets (i.e., not including header or 2152 padding) transmitted in RTP data packets by the sender since start- 2153 ing transmission on this connection. The count is not reset if the 2154 sender changes its SSRC identifier, for example as a result of a 2155 Modify command. The value is zero if the connection was set in 2156 "receive only" mode. 2158 Number of packets received: 2159 The total number of RTP data packets received by the sender since 2160 starting reception on this connection. The count includes packets 2161 received from different SSRC, if the sender used several values. 2162 The value is zero if the connection was set in "send only" mode. 2164 Number of octets received: 2165 The total number of payload octets (i.e., not including header or 2166 padding) transmitted in RTP data packets by the sender since start- 2167 ing transmission on this connection. The count includes packets 2168 received from different SSRC, if the sender used several values. 2169 The value is zero if the connection was set in "send only" mode. 2171 Number of packets lost: 2172 The total number of RTP data packets that have been lost since the 2173 creation of the RTP connection. This number is defined to be the 2174 number of packets expected less the number of packets actually 2175 received, where the number of packets received includes any which 2176 are late or duplicates. The count includes packets received from 2177 different SSRC, if the sender used several values. Thus packets 2178 that arrive late are not counted as lost, and the loss may be nega- 2179 tive if there are duplicates. The count includes packets received 2180 from different SSRC, if the sender used several values. The number 2181 of packets expected is defined to be the extended last sequence 2182 number received, as defined next, less the initial sequence number 2183 received. The count includes packets received from different SSRC, 2184 if the sender used several values. The value is zero if the connec- 2185 tion was set in "send only" mode. This property is omitted if the 2186 connection was set in "data" mode. 2188 Interarrival jitter: 2189 An estimate of the statistical variance of the RTP data packet 2190 interarrival time measured in milliseconds and expressed as an 2191 unsigned integer. The interarrival jitter J is defined to be the 2192 mean deviation (smoothed absolute value) of the difference D in 2194 Internet draft MEGACO Protocol Proposal March 25, 1999 2196 packet spacing at the receiver compared to the sender for a pair of 2197 packets. Detailed computation algorithms are found in RFC 1889. The 2198 count includes packets received from different SSRC, if the sender 2199 used several values. The value is zero if the connection was set in 2200 "send only" mode. This property is omitted if the connection was 2201 set in "data" mode. 2203 Average transmission delay: 2204 An estimate of the network latency, expressed in milliseconds. This 2205 is the average value of the difference between the NTP timestamp 2206 indicated by the senders of the RTCP messages and the NTP timestamp 2207 of the receivers, measured when this messages are received. The 2208 average is obtained by summing all the estimates, then dividing by 2209 the number of RTCP messages that have been received. This property 2210 is omitted if the connection was set in "data" mode. 2211 When the MG's clock is not synchronized by NTP, the latency value 2212 can be computed as one half of the round trip delay, as measured 2213 through RTCP. 2214 When the MG cannot compute the one way delay or the round trip 2215 delay, the property conveys a null value. 2217 For a detailed definition of these variables, refer to RFC 1889. 2219 When the connection was set up over an ATM network, the meaning of these 2220 properties may change: 2222 Number of packets sent: 2223 The total number of ATM cells transmitted since starting transmis- 2224 sion on this connection. 2226 Number of octets sent: 2227 The total number of payload octets transmitted in ATM cells. 2229 Number of packets received: 2230 The total number of ATM cells received since starting reception on 2231 this connection. 2233 Number of octets received: 2234 The total number of payload octets received in ATM cells. 2236 Number of packets lost: 2237 Should be determined as the number of cells lost, or set to zero if 2238 the adaptation layer does not enable the MG to assess losses. 2240 Interarrival jitter: 2241 Should be understood as the interarrival jitter between ATM cells. 2243 Average transmission delay: 2245 Internet draft MEGACO Protocol Proposal March 25, 1999 2247 The MG may not be able to assess this property over an ATM network. 2248 It could simply report a null value. 2250 When the termination is of type TDM or analog, the meaning of these pro- 2251 perties is defined as follow: 2253 Number of packets sent: 2254 Not significant. 2256 Number of octets sent: 2257 The total number of payload octets transmitted over the local con- 2258 nection. 2260 Number of packets received: 2261 Not significant. 2263 Number of octets received: 2264 The total number of payload octets received over the connection. 2266 Number of packets lost: 2267 Not significant. A value of zero is assumed. 2269 Interarrival jitter: 2270 Not significant. A value of zero is assumed. 2272 Average transmission delay: 2273 Not significant. A value of zero is assumed. 2275 4.5. Examples 2277 The following examples use, for practical reasons, a text representation 2278 of the MEGACO protocol. This representation assumes the following token 2279 definitions: 2281 __________________________________________________ 2282 | TRAN | transToken | 2283 | ACPT | acceptToken | 2284 | MEGACO | megacopToken | 2285 | CTX | ctxToken | 2286 | ADD | addToken | 2287 | SUBTRACT| subtractToken | 2288 | MODIFY | modifyToken | 2289 | TS | TSToken (TerminationState) | 2290 | LT | LTToken (LocalTerminationDescriptor) | 2291 | RT | RTToken (RemoteTerminationDescriptor)| 2292 |_________|_______________________________________| 2294 Internet draft MEGACO Protocol Proposal March 25, 1999 2296 4.5.1. Example Add transaction: 2298 TRAN 12345678 MGC1.network.com:12345 MEGACOP 1.0 2299 CTX= -1 2300 ADD= circuitgroup1/5 2301 LS= {m=recvonly 2302 } 2303 ADD= RTP/ANY 2304 LS= {m=sendrecv 2305 } 2306 LT= {v=0 2307 c=IN IP4 100.100.100.089 2308 m=audio ANY RTP/AVP 0 2309 } 2310 RT= {v=0 2311 c=IN IP4 200.200.200.133 2312 m=audio 4321 RTP/AVP 0 2313 } 2315 4.5.2. Example response to Add transaction: 2317 ACPT 12345678 MG1.network.com:12345 MEGACOP 1.0 2318 CTX= 12344321 2319 ADD= circuitgroup1/5 2320 ADD= RTP/7777 2321 LT= {v=0 2322 c=IN IP4 100.100.100.089 2323 m=audio 3456 RTP/AVP 0 2324 } 2326 4.5.3. Example Modify transaction: 2328 TRAN 12345672 MGC1.network.com:12345 MEGACOP 1.0 2329 CTX= 12344321 2330 MODIFY= circuitgroup1/5 2331 LS= {m=sendrecv 2332 } 2334 4.5.4. Example Subtract transaction: 2336 TRAN 12345673 MGC1.network.com:12345 MEGACOP 1.0 2337 CTX= 12344321 2338 SUBTRACT= circuitgroup1/5 2339 SUBTRACT= RTP/7777 2341 Internet draft MEGACO Protocol Proposal March 25, 1999 2343 4.6. Transaction Response Codes 2345 All MegacoP transactions return a transaction response code which ack- 2346 nowledges the command(s) sent and returns a code indicating the success 2347 or failure of the command. 2349 The transaction response code is an integer number, the first digit of 2350 which indicates the class of the Response Code. 2352 2xx: Success -- the transaction was successfully received, understood, and 2353 all commands were executed; 2355 4xx: Protocol reject -- the transaction received could not be understood; 2357 5xx: Execution reject -- the transaction received could not be executed; 2359 MEGACOP Transaction Response Codes are extensible. MEGACOP applica- 2360 tions are not required to understand the meaning of all registered 2361 response codes, though such understanding is obviously desirable. How- 2362 ever, applications MUST understand the class of any response code, as 2363 indicated by the first digit, and treat any unrecognized response code 2364 as being equivalent to the x00 response code of that class. 2366 4.6.1. Transaction Response Success Codes 2368 Success = "200" ; The requested transaction was executed nor- 2369 mally 2371 4.6.2. Transaction Response Reject Codes 2373 Protocol-Reject = "400" ; Bad Request 2374 Protocol-Reject = "400" ; Bad Request 2375 / "401" ; Unauthorized 2376 / "411" ; Length Required 2377 / "415" ; Incorrect identifier 2378 / "416" ; The transaction refers to an unknown ContextId 2379 / "418" ; Unsupported or unknown package 2380 / "422" ; No such event or signal 2381 / "423" ; Unknown action or illegal combination of actions 2382 / "425" ; Unknown TerminationID 2383 / "427" ; Missing RemoteTerminationDescriptor 2384 / "484" ; Action Incomplete 2385 / "485" ; Action Ambiguous 2387 Execution-Reject = "500" ; Internal Gateway Error 2388 / "501" ; Not Implemented 2389 / "502" ; Not ready. 2391 Internet draft MEGACO Protocol Proposal March 25, 1999 2393 / "503" ; Service Unavailable 2394 / "504" ; Gateway Time-out 2395 / "505" ; MEGACOP Version not supported 2396 / "509" ; Resource Conflict 2397 / "510" ; Insufficient resources 2398 / "512" ; Gateway unequipped to detect requested event 2399 / "513" ; Gateway unequipped to generate requested signals 2400 / "514" ; Gateway cannot send the specified announcement 2401 / "515" ; Unsupported Media Type 2402 / "517" ; Unsupported or invalid mode 2403 / "519" ; Gateway does not have a digit map 2404 / "520" ; Termination is "ServiceChangeing" 2405 / "526" ; Insufficient bandwidth 2406 / "581" ; Does Not Exist 2408 5. Transport 2410 The transport mechanism for MEGACOP has not been chosen. It is likely 2411 that TCP will be an option. If the SIGTRAN transport mechanism is suit- 2412 able for MEGACO, that may be specified. It may be necessary to specify 2413 a transport protocol in this specification. Either the SIGTRAN mechan- 2414 ism or a MEGACO specified mechanism will be optional on the MG and 2415 required on the MGC. 2417 5.1. Transport capabilities, and relationship to Transport Layer 2419 Requirements for transport of the MEGACO protocol include: 2421 1) Reliable delivery of commands/responses. 2423 2) Ordered delivery of commands/responses to a particular "control 2424 stream", this implies ordered delivery of commands to/from a par- 2425 ticular Termination or Context, but not necessarily ordered 2426 across Terminations or Contexts. 2428 3) Limited maximum time to deliver commands. 2430 4) Rapid detection of failure in a control stream. 2432 5) Ability to achieve very high fanout from MGC to MGs. 2434 6) Ability to handle multiple MGCs controlling individual MGs in a 2435 distributed system and vice versa. However this must be optional 2436 so that smaller/simpler systems can be efficiently implemented. 2438 7) Ability for the application to initiate flushing of messages 2440 Internet draft MEGACO Protocol Proposal March 25, 1999 2442 successfully sent through the transport, for example to back off 2443 for failover handling. 2445 Since transport needs are the same in all application states and 2446 independent of what particular commands are being sent, it is logical to 2447 think of the reliable transport as a separate layer, as shown below. 2448 However, there is no accepted IETF protocol which focuses on the needs 2449 of real time control as is needed by the MEGACO protocol. Therefore, the 2450 mechanisms to provide the required characteristics of the reliable tran- 2451 sport should be directly included in the MEGACO protocol layer. However, 2452 It might be desirable to standardize the transport interface (marked in 2453 the figure by - . - . - ). This is discussed in section [4.z.z]. 2455 MEGACO Protocol layer: 2456 Gateway control | Termination-related signalling 2457 - . - . - . - . - . - . - . - . - . - . - . - . - 2458 Reliable transport 2459 ------------------------------------------------- 2460 UDP 2461 ------------------------------------------------- 2462 IP 2463 ------------------------------------------------- 2464 Ethernet, ATM, SONET, ... 2466 Any message goes between one MG and one MGC. This has implications on 2467 MG or MGC "farms". 2469 6. Event packages and termination classes 2471 Termination classes are defined by: 2473 * A plain text description of the purpose of the termination class, 2475 * An SDP profile describing which SDP attributes are used in the the 2476 Local and Remote termination descriptions, 2478 * A default value for the Local and Remote termination descriptions, 2480 * The definition of statistics that can be collected on the termina- 2481 tion, 2483 * A list of events and signals that are defined for the termination, 2485 The events and signals are grouped in "event packages", some of which 2486 may apply to different termination classes. The list of events and sig- 2487 nals applicable for a termination class must thus be defined by the list 2488 of applicable event packages. 2490 Internet draft MEGACO Protocol Proposal March 25, 1999 2492 In this section, we will describe the most common event packages, and 2493 then the most common termination classes. More packages and classes can 2494 be defined in additional documents. 2496 6.1. Basic event packages 2498 The list of basic event packages includes the following: 2500 _________________________________________ 2501 | Package | name | 2502 |______________________________|_________| 2503 | Generic Media Package | G | 2504 | DTMF package | D | 2505 | MF Package | M | 2506 | Trunk Package | T | 2507 | Line Package | L | 2508 | Handset Package | H | 2509 | RTP Package | R | 2510 | Network Access Server Package| N | 2511 | Announcement Server Package | A | 2512 | Script Package | Script| 2513 |______________________________|_________| 2515 In the tables of events for each package, there are five columns: 2516 Symbol: the unique symbol used for the event 2517 Definition: a short description of the event 2519 R: an x appears in this column is the event can be Requested by 2520 the call agent. 2522 S: if nothing appears in this column for an event, then the event 2523 cannot be signaled on command by the call agent. Otherwise, 2524 the following symbols identify the type of event: 2526 OO On/Off signal. The signal is turned on until commanded 2527 by the call agent to turn it off, and vice versa. 2529 TO Timeout signal. The signal lasts for a given duration 2530 unless it is superseded by a new signal. 2532 BR Brief signal. The event has a short, known duration. 2534 Duration: specifies the duration of TO signals. 2536 6.1.1. Generic Media Event package 2538 Package Name: G 2540 Internet draft MEGACO Protocol Proposal March 25, 1999 2542 The generic media package group the events and signals that can be 2543 observed on several types of terminations, such as trunking gateways, 2544 access gateways or residential gateways. 2546 _____________________________________________________________________ 2547 | Symbol | Definition | R | S Duration | 2548 |__________|____________________________|_____|______________________| 2549 | mt | Modem detected | x | | 2550 | ft | Fax tone detected | x | | 2551 | ld | Long duration connection | x | | 2552 | pat(###) | Pattern ### detected | x | OO | 2553 | rt | Ringback tone | | TO | 2554 | rbk(###) | ring back on connection | | TO 180 seconds | 2555 | cf | Confirm tone | | BR | 2556 | cg | Network Congestion tone | | TO | 2557 | it | Intercept tone | | OO | 2558 | pt | Preemption tone | | OO | 2559 | of | report failure | x | | 2560 |__________|____________________________|_____|______________________| 2562 The signals are defined as follow: 2564 The pattern definition can be used for specific algorithms such as 2565 answering machine detection, tone detection, and the like. 2567 Ring back tone (rt) 2568 an Audible Ring Tone, a combination of two AC tones with frequen- 2569 cies of 440 and 480 Hertz and levels of -19 dBm each, to give a 2570 combined level of -16 dBm. The cadence for Audible Ring Tone is 2 2571 seconds on followed by 4 seconds off. See GR- 506-CORE - LSSGR: 2572 SIGNALING, Section 17.2.5. 2574 Ring back on connection 2575 A ring back tone, applied to the connection whose identifier is 2576 passed as a property. 2578 The "long duration connection" is detected when a connection has been 2579 established for more than 1 hour. 2581 6.1.2. DTMF event package 2583 Package name: D 2585 Internet draft MEGACO Protocol Proposal March 25, 1999 2587 _______________________________________________________________ 2588 | Symbol | Definition | R | S Duration | 2589 |________|___________________________|_____|___________________| 2590 | 0 | DTMF 0 | x | BR | 2591 | 1 | DTMF 1 | x | BR | 2592 | 2 | DTMF 2 | x | BR | 2593 | 3 | DTMF 3 | x | BR | 2594 | 4 | DTMF 4 | x | BR | 2595 | 5 | DTMF 5 | x | BR | 2596 | 6 | DTMF 6 | x | BR | 2597 | 7 | DTMF 7 | x | BR | 2598 | 8 | DTMF 8 | x | BR | 2599 | 9 | DTMF 9 | x | BR | 2600 | # | DTMF # | x | BR | 2601 | * | DTMF * | x | BR | 2602 | A | DTMF A | x | BR | 2603 | B | DTMF B | x | BR | 2604 | C | DTMF C | x | BR | 2605 | D | DTMF D | x | BR | 2606 | L | long duration indicator | x | 2 seconds| 2607 | X | Wildcard, match | x | | 2608 | | any digit 0-9 | | | 2609 | T | Interdigit timer | x | 4 seconds| 2610 | of | report failure | x | | 2611 |________|___________________________|_____|___________________| 2613 The "interdigit timer" occurs when a long delay is observed after the 2614 end of a digit detection. The event can only be observed if the termi- 2615 nation is trying to acquire digits. Note that the definition of this 2616 timer requires further study. In fact, the timer should take two dif- 2617 ferent values, depending of the digit map and the digit string: 2619 - If the gateway can determine that at least one more digit is 2620 requested for the digit string to match any of the allowed patterns 2621 in the digit map, then the timer value should be set to a long 2622 duration, such as 16 seconds. 2624 - If the digit map specifies that a variable number of additional 2625 digits may be needed (the "." indication at the end of a string), 2626 then the timer value should be set to a medium duration, such as 8 2627 seconds. 2629 - In some rare cases, such as optional additional digits, the timer 2630 should be set to a short duration, 4 seconds. The current digit 2631 map syntax does not allow for a distinction between the "medium" 2632 and "short" timer conditions, which implies that, in the current 2633 version, there is no way to request a short timer. 2635 Internet draft MEGACO Protocol Proposal March 25, 1999 2637 The "long duration indicator" is observed when a DTMF signal is produced 2638 for a duration larger than two seconds. In this case, the gateway will 2639 detect two successive events: first, when the signal has been recog- 2640 nized, the DTMF signal, and then, 2 seconds later, the long duration 2641 signal. 2643 Internet draft MEGACO Protocol Proposal March 25, 1999 2645 6.1.3. MF Event package 2647 Package Name: M 2649 ________________________________________________________ 2650 | Symbol | Definition | R | S Duration | 2651 |________|____________________|_____|___________________| 2652 | 0 | MF 0 | x | BR | 2653 | 1 | MF 1 | x | BR | 2654 | 2 | MF 2 | x | BR | 2655 | 3 | MF 3 | x | BR | 2656 | 4 | MF 4 | x | BR | 2657 | 5 | MF 5 | x | BR | 2658 | 6 | MF 6 | x | BR | 2659 | 7 | MF 7 | x | BR | 2660 | 8 | MF 8 | x | BR | 2661 | 9 | MF 9 | x | BR | 2662 | X | Wildcard, match | x | | 2663 | | any digit 0-9 | | | 2664 | T | Interdigit timer | x | 4 seconds| 2665 | K0 | MF K0 or KP | x | BR | 2666 | K1 | MF K1 | x | BR | 2667 | K2 | MF K2 | x | BR | 2668 | S0 | MF S0 or ST | x | BR | 2669 | S1 | MF S1 | x | BR | 2670 | S2 | MF S2 | x | BR | 2671 | S3 | MF S3 | x | BR | 2672 | wk | Wink | x | BR | 2673 | wko | Wink off | x | BR | 2674 | is | Incoming seizure | x | OO | 2675 | rs | Return seizure | x | OO | 2676 | us | Unseize circuit | x | OO | 2677 | of | report failure | x | | 2678 |________|____________________|_____|___________________| 2680 The definition of the MF package events is as follow: 2682 Wink 2683 A transition from unseized to seized to unseized trunk states 2684 within a specified period. Typical seizure period is 100-350 2685 msec.) 2687 Incoming seizure 2688 Incoming indication of call attempt. 2690 Return seizure: 2691 Seizure in response to outgoing seizure. 2693 Internet draft MEGACO Protocol Proposal March 25, 1999 2695 Unseize circuit: 2696 Unseizure of a circuit at the end of a call. 2698 Wink off: 2699 A signal used in operator services trunks. A transition from 2700 seized to unseized to seized trunk states within a specified period 2701 of 100-350 ms. (To be checked) 2703 6.1.4. Trunk Event package 2705 Package Name: T 2707 _____________________________________________________________________ 2708 | Symbol | Definition | R | S Duration | 2709 |________|________________________________|_____|____________________| 2710 | co1 | Continuity tone (single tone,| x | OO | 2711 | | or return tone) | | | 2712 | co2 | Continuity test (go tone, | x | OO | 2713 | | in dual tone procedures) | | | 2714 | lb | Loopback | | OO | 2715 | om | Old Milliwatt Tone (1000 Hz) | x | OO | 2716 | nm | New Milliwatt Tone (1004 Hz) | x | OO | 2717 | tl | Test Line | x | OO | 2718 | zz | No circuit | x | OO | 2719 | as | Answer Supervision | x | OO | 2720 | ro | Reorder Tone | x | TO 30 seconds| 2721 | of | report failure | x | | 2722 |________|________________________________|_____|____________________| 2724 The definition of the trunk package signal events is as follow: 2726 Continuity Tone (co1): 2727 A tone at 2010 + or - 30 Hz. 2729 Continuity Test (co2): 2730 A tone at the 1780 + or - 30 Hz. 2732 Milliwatt Tones: 2733 Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz) 2735 Line Test: 2736 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0 2737 + or -- 0.5dB). 2739 No circuit: 2740 (that annoying tri-tone, low to high) 2742 Internet draft MEGACO Protocol Proposal March 25, 1999 2744 Answer Supervision: 2746 Reorder Tone: 2747 Reorder tone is a combination of two AC tones with frequencies of 2748 480 and 620 Hertz and levels of -24 dBm each, to give a combined 2749 level of -21 dBm. The cadence for Station Busy Tone is 0.25 2750 seconds on followed by 0.25 seconds off, repeating continuously. 2751 See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7. 2753 The continuity tones are used when the call agent wants to initiate a 2754 continuity test. There are two types of tests, single tone and dual 2755 tone. The Call agent is expected to know, through provisioning informa- 2756 tion, which test should be applied to a given termination. For example, 2757 the controller that wants to initiate a single frequency test will send 2758 to the gateway a command of the form: 2760 RQNT 1234 epx-t1/17@tgw2.example.net 2761 X: AB123FE0 2762 S: co1 2763 R: co1 2765 If it wanted instead to initiate a dual-tone test, it would send the 2766 command: 2768 RQNT 1234 epx-t1/17@tgw2.example.net 2769 X: AB123FE0 2770 S: co2 2771 R: co1 2773 The gateway would send the requested signal, and in both cases would 2774 look for the return of the 2010 Hz tone (co1). When it detects that 2775 tone, it must send the corresponding notification. 2777 The tones are of type OO: the gateway must keep sending them until it 2778 receives a new notification request. 2780 6.1.5. Line Event package 2782 Package Name: L 2784 Internet draft MEGACO Protocol Proposal March 25, 1999 2786 __________________________________________________________________________ 2787 |Symbol | Definition | R | S Duration | 2788 |_____________|______________________________|_____|_____________________| 2789 |adsi(string) | adsi display | | BR | 2790 |vmwi | visual message | | TO | 2791 | | waiting indicator | | | 2792 |hd | Off hook transition | x | | 2793 |hu | On hook transition | x | | 2794 |hf | Flash hook | x | | 2795 |aw | Answer tone | x | OO | 2796 |bz | Busy tone | | TO 30 seconds | 2797 |ci(string) | Caller-id | | BR | 2798 |wt | Call Waiting tone | | TO 30 seconds | 2799 |dl | Dial tone | | TO 16 seconds | 2800 |mwi | Message waiting ind. | | TO 16 seconds | 2801 |nbz | Network busy | x | OO | 2802 | | (fast cycle busy) | | | 2803 |rg | Ringing | | TO 180 seconds| 2804 |r0, r1, r2, | Distinctive ringing | | TO 180 seconds| 2805 |r3, r4, r5, | | | | 2806 |r6 or r7 | | | | 2807 |rs | Ringsplash | | BR | 2808 |p | Prompt tone | x | BR | 2809 |e | Error tone | x | BR | 2810 |sdl | Stutter dialtone | | TO 16 seconds | 2811 |v | Alerting Tone | | OO | 2812 |y | Recorder Warning Tone | | OO | 2813 |sit | SIT tone | | | 2814 |z | Calling Card Service Tone | | OO | 2815 |oc | Report on completion | x | | 2816 |ot | Off hook warning tone | | TO indefinite | 2817 |s(###) | Distinctive tone pattern | x | BR | 2818 |of | report failure | x | | 2819 |_____________|______________________________|_____|_____________________| 2821 The definition of the tones is as follow: 2823 Dial tone: 2824 A combined 350 + 440 Hz tone. 2826 Visual Message Waiting Indicator 2827 The transmission of the VMWI messages must conform to the require- 2828 ments in Section 2.3.2, "On-hook Data Transmission Not Associated 2829 with Ringing" in TR-H- 000030 and the CPE guidelines in SR-TSV- 2830 002476. VMWI messages must only be sent from the SPCS when the line 2831 is idle. If new messages arrive while the line is busy, the VMWI 2832 indicator message must be delayed until the line goes back to the 2834 Internet draft MEGACO Protocol Proposal March 25, 1999 2836 idle state. The CA should periodically refresh the CPE's visual 2837 indicator. See TR-NWT-001401 - Visual Message Waiting Indicator 2838 Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission 2839 Interface. 2841 Message waiting Indicator 2842 See GR-506-CORE, 17.2.3. 2844 Alerting Tone: 2845 a 440 Hz Tone of 2 second duration followed by 1/2 second of tone 2846 every 10 seconds. 2848 Rig splash 2849 Ringsplash, also known as "Reminder ring" is a burst of ringing 2850 that may be applied to the physical forwarding line (when idle) to 2851 indicate that a call has been forwarded and to remind the user that 2852 a CF subfeature is active. In the US, it is defined to be a 0.5(- 2853 0,+0.1) second burst of power ringing. See TR- TSY-000586 - Call 2854 Forwarding Subfeatures. 2856 Call waiting tone 2857 Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting 2858 feature is defined in TR-TSY-000571. By defining "wt" as a TO sig- 2859 nal you are really defining the feature which seems wrong to me 2860 (given the spirit of MGCP), hence the definition of "wt" as a BR 2861 signal in ECS, per GR-506-CORE. Also, it turns out that there is 2862 actually four different call waiting tone patterns (see GR-506- 2863 CORE, 14.2) so we should really have wt1, wt2, wt3, wt4, or some 2864 parameterization. 2866 Recorder Warning Tone: 2867 1400 Hz of Tone of 0.5 second duration every 15 seconds. 2869 SIT tone: 2870 used for indicating a line is out of service. 2872 Calling Card Service Tone: 2873 60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone), 2874 decaying exponentially with a time constant of 200 ms. 2876 Distinctive tone pattern: 2877 where ### is any number between 000 and 999, inclusive. Can be 2878 used for distinctive ringing, customized dial tone, etc. 2880 Report on completion 2881 The report on completion event is detected when the gateway was 2882 asked to perform one or several signals of type TO on the termina- 2883 tion, and when these signals were completed without being stopped 2885 Internet draft MEGACO Protocol Proposal March 25, 1999 2887 by the detection of a requested event such as off-hook transition 2888 or dialed digit. The completion report may carry as property the 2889 name of the signal that came to the end of its live time, as in: 2891 O: L/oc(L/dl) 2893 Ring back on connection 2894 A ring back tone, applied to the connection whose identifier is 2895 passed as a property. 2897 We should note that many of these definitions vary from country to coun- 2898 try. The frequencies listed above are the one in use in North America. 2899 There is a need to accommodate different tone sets in different coun- 2900 tries, and there is still an ongoing debate on the best way to meet that 2901 requirement: 2903 * One solution is to define different event packages specifying for 2904 example the German dial-tone as "L-DE/DL". 2906 * Another solution is to use a management interface to specify on an 2907 end-point basis which frequency shall be associated to what tone. 2909 Internet draft MEGACO Protocol Proposal March 25, 1999 2911 6.1.6. Handset emulation event package 2913 Package Name: H 2915 __________________________________________________________________________ 2916 |Symbol | Definition | R | S Duration | 2917 |_____________|______________________________|_____|_____________________| 2918 |adsi(string) | adsi display | x | BR | 2919 |tdd | | | | 2920 |vmwi | | | | 2921 |hd | Off hook transition | x | OO | 2922 |hu | On hook transition | x | OO | 2923 |hf | Flash hook | x | BR | 2924 |aw | Answer tone | x | OO | 2925 |bz | Busy tone | x | OO | 2926 |wt | Call Waiting tone | x | TO 30 seconds | 2927 |dl | Dial tone (350 + 440 Hz) | x | TO 120 seconds| 2928 |nbz | Network busy | x | OO | 2929 | | (fast cycle busy) | | | 2930 |rg | Ringing | x | TO 30 seconds | 2931 |r0, r1, r2, | Distinctive ringing | x | TO 30 seconds | 2932 |r3, r4, r5, | | | | 2933 |r6 or r7 | | | | 2934 |p | Prompt tone | x | BR | 2935 |e | Error tone | x | BR | 2936 |sdl | Stutter dialtone | x | TO 16 seconds | 2937 |v | Alerting Tone | x | OO | 2938 |y | Recorder Warning Tone | x | OO | 2939 |t | SIT tone | x | | 2940 |z | Calling Card Service Tone | x | OO | 2941 |oc | Report on completion | x | | 2942 |ot | Off hook warning tone | x | OO | 2943 |s(###) | Distinctive tone pattern | x | BR | 2944 |of | report failure | x | | 2945 |_____________|______________________________|_____|_____________________| 2947 The handset emulation package is an extension of the line package, to be 2948 used when the gateway is capable of emulating a handset. The difference 2949 with the line package is that events such as "off hook" can be signalled 2950 as well as detected. 2952 Internet draft MEGACO Protocol Proposal March 25, 1999 2954 6.1.7. RTP Event package 2956 Package Name: R 2958 _________________________________________________________________ 2959 | Symbol | Definition | R | S Duration| 2960 |_________|______________________________|_____|_________________| 2961 | UC | Used codec changed | x | | 2962 | SR(###) | Sampling rate changed | x | | 2963 | JI(###) | Jitter buffer size changed | x | | 2964 | PL(###) | Packet loss exceeded | x | | 2965 | qa | Quality alert | x | | 2966 | of | report failure | x | | 2967 |_________|______________________________|_____|_________________| 2969 Codec Changed: 2970 Codec changed to hexadecimal codec number enclosed in parenthesis, 2971 as in UC(15), to indicate the codec was changed to PCM mu-law. 2972 Codec Numbers are specified in RFC 1890, or in a new definition of 2973 the audio profiles for RTP that replaces this RFC. Some implemen- 2974 tations of media gateways may not allow the codec to be changed 2975 upon command from the call agent. codec changed to codec hexade- 2976 cimal ##. 2978 Sampling Rate Changed: 2979 Sampling rate changed to decimal number in milliseconds enclosed in 2980 parenthesis, as in SR(20), to indicate the sampling rate was 2981 changed to 20 milliseconds. Some implementations of media gateways 2982 may not allow the sampling rate to be changed upon command from a 2983 call agent. 2985 Jitter Buffer Size Changed: 2986 When the media gateway has the ability to automatically adjust the 2987 depth of the jitter buffer for received RTP streams, it is useful 2988 for the media gateway controller to receive notification that the 2989 media gateway has automatically increased its jitter buffer size to 2990 accommodate increased or decreased variability in network latency. 2991 The syntax for requesting notification is "JI", which tells the 2992 media gateway that the controller wants notification of any jitter 2993 buffer size changes. The syntax for notification from the media 2994 gateway to the controller is "JI(####)", where the #### is the new 2995 size of the jitter buffer, in milliseconds. 2997 Packet Loss Exceeded: 2998 Packet loss rate exceed the threshold of the specified decimal 2999 number of packets per 100,000 packets, where the packet loss number 3000 is contained in parenthesis. For example, PL(10) indicates packets 3002 Internet draft MEGACO Protocol Proposal March 25, 1999 3004 are being dropped at a rate of 1 in 10,000 packets. 3006 Quality alert 3007 The packet loss rate or the combination of delay and jitter exceed 3008 a specified quality threshold. 3010 6.1.8. Network Access Server Event package 3012 Package Name: N 3014 ____________________________________________________________ 3015 | Symbol | Definition | R | S Duration| 3016 |________|__________________________|_____|_________________| 3017 | pa | Packet arrival | x | | 3018 | cbk | Call back request | x | | 3019 | cl | Carrier lost | x | | 3020 | au | Authorization succeeded| x | | 3021 | ax | Authorization denied | x | | 3022 | of | Report failure | x | | 3023 |________|__________________________|_____|_________________| 3025 The packet arrival event is used to notify that at least one packet was 3026 recently sent to an Internet address that is observed by an termination. 3027 The event report includes the Internet address, in standard ASCII encod- 3028 ing, between parenthesis: 3030 O: pa(192.96.41.1) 3032 The call back event is used to notify that a call back has been 3033 requested during the initial phase of a data connection. The event 3034 report includes the identification of the user that should be called 3035 back, between parenthesis: 3037 O: cbk(user25) 3039 Internet draft MEGACO Protocol Proposal March 25, 1999 3041 6.1.9. Announcement Server Event package 3043 Package Name: A 3045 ___________________________________________________________________ 3046 | Symbol | Definition | R | S Duration| 3047 |________________|________________________|_____|__________________| 3048 | ann(url,parms) | Play an announcement | | TO variable| 3049 | oc | Report on completion | x | | 3050 | of | Report failure | x | | 3051 |________________|________________________|_____|__________________| 3053 The announcement action is qualified by an URL name and by a set of ini- 3054 tial properties as in for example: 3056 S: ann(http://scripts.example.net/all-lines-busy.au) 3058 The "operation complete" event must be detected when the announcement is 3059 played out. If the announcement cannot be played out, an operation 3060 failure event can be returned. The failure may be explained by a com- 3061 mentary, as in: 3063 O: A/of(file not found) 3065 Internet draft MEGACO Protocol Proposal March 25, 1999 3067 6.1.10. Script Event package 3069 Package Name: Script 3071 ______________________________________________________________ 3072 | Symbol | Definition | R | S | Duration| 3073 |___________|________________________|_____|______|___________| 3074 | java(url) | Load a java script | | TO | variable| 3075 | perl(url) | Load a perl script | | TO | variable| 3076 | tcl(url) | Load a TCL script | | TO | variable| 3077 | xml(url) | Load an XML script | | TO | variable| 3078 | oc | Report on completion | x | | | 3079 | of | Report failure | x | | | 3080 |___________|________________________|_____|______|___________| 3082 The "language" action define is qualified by an URL name and by a set of 3083 initial properties as in for example: 3085 S: script/java(http://scripts.example.net/credit-card.java,long,1234) 3087 The current definition defines keywords for the most common languages. 3088 More languages may be defined in further version of this documents. For 3089 each language, an API specification must describe how the scripts can 3090 issue local "notificationRequest" commands, and receive the correspond- 3091 ing notifications. 3093 The script produces an output which consists of one or several text 3094 string, separated by commas. The text string are reported as a commen- 3095 tary in the report on completion, as in for example: 3097 O: script/oc(21223456794567,9738234567) 3099 The failure report may also return a string, as in: 3101 O: script/oc(21223456794567,9738234567) 3103 The definition of the script environment and the specific actions in 3104 that environment are for further study. 3106 Internet draft MEGACO Protocol Proposal March 25, 1999 3108 6.2. Basic termination classes 3110 We define the following basic termination types and profiles: 3112 * DS0 termination, 3114 * Analog termination, 3116 * RTP termination, 3118 * ATM termination, 3120 * Network Access Termination. 3122 Editors' note: These are only the most basic termination types. There is 3123 an obvious need to also define digital multiplexes (T1, E1, T3, E3) and 3124 the event that they support. 3126 6.2.1. DS0 Terminations 3128 DS0 terminations are digital circuits, providing a 64kbits (8bit times 8 3129 KHz) service. Such terminations are commonly used for interoffice 3130 trunks. 3132 DS0 terminations are always described in a symmetric fashion. The 3133 RemoteTerminationDescriptor parameter is never used. 3135 The LocalTerminationDescriptor may be used to specify the encoding of 3136 the media. This parameter is described using SDP, with the following 3137 conventions: 3139 * The connection data line is not used. A placeholder (c=LOCAL) can 3140 be used if this is required for compliance with the SDP syntax. 3142 * The "m=audio" property must specify a port number, which must 3143 always be set to 0, the type of protocol, always set to the keyword 3144 DS0, and the type of encoding, using the same conventions used for 3145 RTP (RTP payload numbers.) The type of encoding should normally be 3146 set to 0 (PCM, mu law) or to 8 (PCM, A law). 3148 * The "a=echo" attribute must specify whether the gateway performs 3149 echo cancellation. The property can have two values, "a:echo:on" 3150 (when the echo cancellation is requested) and "a:echo:off" (when it 3151 is turned off.) 3153 An example of specification could be: 3155 v=0 3157 Internet draft MEGACO Protocol Proposal March 25, 1999 3159 c=LOCAL 3160 m=audio 0 DS0 0 3161 a=echo:on 3163 The default configuration option is to use the mu-law encoding, and to 3164 apply echo cancellation. (We could define a variant of the DS0 class 3165 which would, by default, use A-law encoding.) 3167 Gateways are expected to be able to collect the following statistics on 3168 terminations of the DS0 class: 3170 Number of octets sent 3171 The number of octet sent is equal to the duration of the termina- 3172 tion, in seconds, multiplied by the sampling frequency, 8000 Hz. 3174 Terminations of the DS0 class are expected to provide the following sup- 3175 port for event packages: 3177 _______________________________________________________________________ 3178 |Package | name | support in DS0 class | 3179 |______________________|__________|___________________________________| 3180 |Generic Media Package | G | Mandatory | 3181 |Trunk Package | T | Mandatory | 3182 |DTMF package | D | Optional (for credit cards, etc)| 3183 |MF Package | M | Optional (for MF trunks) | 3184 |Announcement | A | Optional (when gateway | 3185 |Server Package | | can play announcement on DS0) | 3186 |Script Package | Script | Optional | 3187 |______________________|__________|___________________________________| 3189 6.2.2. Analog Terminations 3191 Analog terminations are analog circuits, typically connected through an 3192 RJ11 interface. Such terminations are commonly found in residential 3193 gateways. 3195 Analog terminations are always described in a symmetric fashion. The 3196 RemoteTerminationDescriptor parameter is never used. 3198 The LocalTerminationDescriptor may be used to specify the encoding of 3199 the media. This parameter is described using SDP, with the following 3200 conventions: 3202 * The connection data line is not used. A placeholder (c=LOCAL) can 3203 be used if this is required for compliance with the SDP syntax. 3205 Internet draft MEGACO Protocol Proposal March 25, 1999 3207 * The "m=audio" property is only used for conformance with the SDP 3208 syntax. It is set to a conventional value, specifying a null port, 3209 an ANALOG type and a null type of encoding. 3211 * The "a=echo" attribute must specify whether the gateway performs 3212 echo cancellation. The property can have two values, "a:echo:on" 3213 (when the echo cancellation is requested) and "a:echo:off" (when it 3214 is turned off.) 3216 An example of specification could be: 3218 v=0 3219 c=LOCAL 3220 m=audio 0 ANALOG 0 3221 a=echo:on 3223 The default configuration option is to apply echo cancellation. 3225 Gateways are expected to be able to collect the following statistics on 3226 terminations of the analog class: 3228 Number of octets sent 3229 The number of octet sent is equal to the duration of the termina- 3230 tion, in seconds, multiplied by the sampling frequency, 8000 Hz. 3232 Terminations of the analog class are expected to provide the following 3233 support for event packages: 3235 ____________________________________________________________________ 3236 | Package | name | support in analog class | 3237 |_______________________|__________|________________________________| 3238 | Generic Media Package | G | Mandatory | 3239 | DTMF Package | D | Mandatory | 3240 | Line Package | L | Mandatory | 3241 | Handset Package | H | Optional (when gateway | 3242 | | | can set outgoing calls on | 3243 | | | the analog termination) | 3244 | Announcement | A | Optional (when gateway | 3245 | Server Package | | can play announcements on the| 3246 | | | termination) | 3247 | Script Package | Script | Optional | 3248 |_______________________|__________|________________________________| 3250 6.2.3. RTP Audio Terminations 3252 RTP terminations are use to describe the local termination of packet 3254 Internet draft MEGACO Protocol Proposal March 25, 1999 3256 connections established through the RTP, UDP and IP protocols. The RTP 3257 Audio termination class is applied when the RTP terminations convey an 3258 audio media. (Other termination classes may be used for other media, 3259 such as video.) 3261 The encoding of the media in point to point RTP terminations is 3262 described by two sets of properties, the LocalTerminationDescriptor and 3263 the RemoteTerminationDescriptor. Both are described using SDP, with the 3264 following conventions: 3266 * The IP address of the remote gateway (in commands) or of the local 3267 gateway (in responses), or multicast address of the audio confer- 3268 ence, encoded as an SDP "connection data" parameter. This parameter 3269 specifies the IP address that must be used to exchange RTP packets. 3271 * Media description field (m) specifying the audio media, the tran- 3272 sport port used for receiving RTP packets by the remote gateway 3273 (commands) or by the local gateway (responses) , the RTP/AVP tran- 3274 sport, and the list of formats that the gateway must accept. This 3275 list should normally always include the code 0 (reserved for G.711, 3276 mu law). 3278 * Optionally, RTPMAP attributes that define the encoding of dynamic 3279 audio formats, 3281 * Optionally, a packetization period (packet time) attribute (Ptime) 3282 defining the duration of the packet, 3284 * Optionally, an encryption key attribute ("k"), specifying the 3285 encryption and the key for the RTP packets, as defined in SDP. 3287 * Optionally, an attribute defining the type of connection (sendonly, 3288 recvonly, sendrecv, inactive). Note that this attribute does not 3289 have a direct relation with the "Mode" property of the termination. 3290 In fact, the SDP type of connection will most of the time be set to 3291 "sendrecv", regardless of the value used for the termination. 3292 Other values will only be used rarely, for example in the case of 3293 information or announcement servers that need to establish one way 3294 connections. 3296 An example of specification could be: 3298 v=0 3299 c=IN IP4 128.96.41.1 3300 m=audio 3456 RTP/AVP 0 96 3301 a=rtpmap:96 G726-32/8000 3303 Internet draft MEGACO Protocol Proposal March 25, 1999 3305 {Editor's Note: in some cases, there is a need to specify the RTP 3306 and RTCP port that will be used for the reverse direction, when 3307 these ports are different from the receiving ports. One possibil- 3308 ity is to use a second "m=audio" line, optionally followed by a 3309 "c=" line.} 3311 The default configuration for the LocalTerminationDescriptor is to use 3312 one of the IP addresses of the gateway, to select a UDP port for RTP, 3313 and to use the PCM mu-law algorithm. 3315 Gateways are expected to be able to collect the following statistics on 3316 terminations of the RTP class: 3318 Number of packets sent: 3319 The total number of RTP data packets transmitted by the sender 3320 since starting transmission on this connection. The count is not 3321 reset if the sender changes its synchronization source identifier 3322 (SSRC, as defined in RTP), for example as a result of a Modify com- 3323 mand. The value is zero if the connection was set in "receive only" 3324 mode. 3326 Number of octets sent: 3327 The total number of payload octets (i.e., not including header or 3328 padding) transmitted in RTP data packets by the sender since start- 3329 ing transmission on this connection. The count is not reset if the 3330 sender changes its SSRC identifier, for example as a result of a 3331 Modify command. The value is zero if the connection was set in 3332 "receive only" mode. 3334 Number of packets received: 3335 The total number of RTP data packets received by the sender since 3336 starting reception on this connection. The count includes packets 3337 received from different SSRC, if the sender used several values. 3338 The value is zero if the connection was set in "send only" mode. 3340 Number of octets received: 3341 The total number of payload octets (i.e., not including header or 3342 padding) transmitted in RTP data packets by the sender since start- 3343 ing transmission on this connection. The count includes packets 3344 received from different SSRC, if the sender used several values. 3345 The value is zero if the connection was set in "send only" mode. 3347 Number of packets lost: 3348 The total number of RTP data packets that have been lost since the 3349 beginning of reception. This number is defined to be the number of 3350 packets expected less the number of packets actually received, 3351 where the number of packets received includes any which are late or 3352 duplicates. The count includes packets received from different 3354 Internet draft MEGACO Protocol Proposal March 25, 1999 3356 SSRC, if the sender used several values. Thus packets that arrive 3357 late are not counted as lost, and the loss may be negative if there 3358 are duplicates. The count includes packets received from different 3359 SSRC, if the sender used several values. The number of packets 3360 expected is defined to be the extended last sequence number 3361 received, as defined next, less the initial sequence number 3362 received. The count includes packets received from different SSRC, 3363 if the sender used several values. The value is zero if the connec- 3364 tion was set in "send only" mode. This property is omitted if the 3365 connection was set in "data" mode. 3367 Interarrival jitter: 3368 An estimate of the statistical variance of the RTP data packet 3369 interarrival time measured in milliseconds and expressed as an 3370 unsigned integer. The interarrival jitter J is defined to be the 3371 mean deviation (smoothed absolute value) of the difference D in 3372 packet spacing at the receiver compared to the sender for a pair of 3373 packets. Detailed computation algorithms are found in RFC 1889. The 3374 count includes packets received from different SSRC, if the sender 3375 used several values. The value is zero if the connection was set in 3376 "send only" mode. This property is omitted if the connection was 3377 set in "data" mode. 3379 Average transmission delay: 3380 An estimate of the network latency, expressed in milliseconds. This 3381 is the average value of the difference between the NTP timestamp 3382 indicated by the senders of the RTCP messages and the NTP timestamp 3383 of the receivers, measured when this messages are received. The 3384 average is obtained by summing all the estimates, then dividing by 3385 the number of RTCP messages that have been received. This property 3386 is omitted if the connection was set in "data" mode. 3387 When the MG's clock is not synchronized by NTP, the latency value 3388 can be computed as one half of the round trip delay, as measured 3389 through RTCP. 3390 When the MG cannot compute the one way delay or the round trip 3391 delay, the property conveys a null value. 3393 For a detailed definition of these variables, refer to RFC 1889. 3395 Internet draft MEGACO Protocol Proposal March 25, 1999 3397 Terminations of the RTP class are expected to provide the following sup- 3398 port for event packages: 3400 _____________________________________________________________ 3401 | Package | name | support in RTP class | 3402 |_______________________|__________|_________________________| 3403 | RTP Package | R | Mandatory | 3404 | Generic Media Package | G | Mandatory | 3405 | DTMF Package | D | Optional (e.g. in | 3406 | | | IVR units) | 3407 | Announcement | A | Optional (when gateway| 3408 | Server Package | | can play announcement | 3409 | | | on RTP) | 3410 | Script Package | Script | Optional | 3411 |_______________________|__________|_________________________| 3413 6.2.4. ATM audio terminations 3415 (Editor's note: The following description is provisional and indi- 3416 cative. It will have to be reworked on by ATM specialists.) 3418 ATM terminations are use to describe the local termination of packet 3419 connections established over ATM networks. The RTP Audio termination 3420 class is applied when the RTP terminations convey an audio media. (Other 3421 termination classes may be used for other media, such as video.) 3423 The encoding of the media in point to point RTP terminations is 3424 described by two sets of properties, the LocalTerminationDescriptor and 3425 the RemoteTerminationDescriptor. Both are described using SDP, with the 3426 following conventions: 3428 * The "c=" property of SDP to specifies an address in the ATM family, 3429 the ATM addressing variant (NSAP, UNI, E.164) and the ATM address. 3431 * The "m=audio" property must specify the audio encoding and, if 3432 needed, the VPI and VCI. 3434 * Additional attributes properties (a=) will be used to specify the 3435 ATM coding variants, such as the type of adaptation layer and the 3436 error correction or loss compensation algorithms. 3438 An example of SDP payload for an ATM connection could be: 3440 v=0 3441 c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe 3442 m=audio 5/1002 ATM/AVP G.711u 3443 a=connection_type:AAL2 3445 Internet draft MEGACO Protocol Proposal March 25, 1999 3447 The default configuration for the LocalTerminationDescriptor is to use 3448 one of the ATM addresses of the gateway, to select a VPI and a VCI, and 3449 to use the PCM mu-law algorithm. 3451 Editor's note: unclear whether we want to have exactly one ATM ter- 3452 mination type, or several, e.g. AAL1 and AAL2. 3454 Gateways are expected to be able to collect the following statistics on 3455 terminations of the ATM class: 3457 Number of packets sent: 3458 The total number of ATM cells transmitted since starting transmis- 3459 sion on this connection. 3461 Number of octets sent: 3462 The total number of payload octets transmitted in ATM cells. 3464 Number of packets received: 3465 The total number of ATM cells received since starting reception on 3466 this connection. 3468 Number of octets received: 3469 The total number of payload octets received in ATM cells. 3471 Number of packets lost: 3472 Should be determined as the number of cells lost, or set to zero if 3473 the adaptation layer does not enable the MG to assess losses. 3475 Interarrival jitter: 3476 The interarrival jitter between ATM cells. 3478 Average transmission delay: 3479 The MG may not be able to assess this property over an ATM network. 3480 It could simply report a null value. 3482 Internet draft MEGACO Protocol Proposal March 25, 1999 3484 Terminations of the ATM class are expected to provide the following sup- 3485 port for event packages: 3487 _____________________________________________________________ 3488 | Package | name | support in ATM class | 3489 |_______________________|__________|_________________________| 3490 | ATM Package | A | Mandatory | 3491 | Generic Media Package | G | Mandatory | 3492 | DTMF Package | D | Optional (e.g. in | 3493 | | | IVR units) | 3494 | Announcement | A | Optional (when gateway| 3495 | Server Package | | can play announcement | 3496 | | | on ATM) | 3497 | Script Package | Script | Optional | 3498 |_______________________|__________|_________________________| 3500 (Editor's note: the ATM event package is not yet defined.) 3502 6.2.5. Network access service termination 3504 (Editor's note: this package definition is really a place holder. 3505 It will most probably have to be extensively reworked by the WG.) 3507 A network access service (NAS) termination describes the attachment of 3508 the context to a network access service such as a generic Internet 3509 access or a tunnel to a private network server. 3511 The NAS termination is described by a single LocalTerminationDescriptor 3512 parameter. The RemoteTerminationDescriptor parameter is not used. The 3513 LocalTerminationDescriptor is described using SDP with the following 3514 conventions: 3516 * Media description field (m) specifying the network access media, 3517 identified by the code "m=nas/xxxx", where "xxxx" describes the 3518 access control method that should be used for parameterizing the 3519 network access, as specified below. The field may also specify the 3520 port that should be used for contacting the server, as specified in 3521 the SDP syntax. 3523 * Connection address property (c=) specifying the address, or the 3524 domain name, of the server that implement the access control 3525 method. This property may also be specified at the session level. 3527 * Optionally, a bearer type attribute (a=bearer:) describing the type 3528 of data connection to be used, including the modem type. 3530 * Optionally, a framing type attribute (a=framing:) describing the 3532 Internet draft MEGACO Protocol Proposal March 25, 1999 3534 type of framing that will be used on the channel. 3536 * Optionally, attributes describing the called number (a=dialed:), 3537 the number to which the call was delivered (a=called:) and the cal- 3538 ling number (a=dialing:). 3540 * Optionally, attributes describing the range of addresses that could 3541 be used by the dialup client on its LAN (a=subnet:). 3543 * Optionally, an encryption key, encoded as specified in the SDP 3544 protocol(k=). 3546 The connection address shall be encoded as specified in the SDP stan- 3547 dard. It must be used in conjunction with the port specified in the 3548 media line to access a server, whose type must be one of: 3550 __________________________________________________________ 3551 | Method name| Method description | 3552 |____________|____________________________________________| 3553 | radius | Authentication according | 3554 | | to the Radius protocol. | 3555 | tacacs | Authentication according | 3556 | | to the TACACS+ protocol. | 3557 | diameter | Authentication according | 3558 | | to the Diameter protocol. | 3559 | l2tp | Level 2 tunneling protocol. | 3560 | | The address and port are those of the LNS.| 3561 | login | Local login. (There is normally | 3562 | | no server for that method.) | 3563 | none | No authentication required. | 3564 | | (The call was probably vetted | 3565 | | by the Call Agent.) | 3566 |____________|____________________________________________| 3568 If needed, the gateway may use the key specified in the announcement to 3569 access the service. That key, in particular, may be used for the estab- 3570 lishment of an L2TP tunnel. 3572 The bearer attribute is composed of a bearer name and an optional exten- 3573 sion. The bearer type specifies the type of modulation (modem name) or, 3574 in the case of digital connections, the type of ISDN service (8 bits, 7 3575 bits). When an extension is present, it is separated from the bearer 3576 name by a single slash (/). The valid values of the bearer attribute 3577 are defined in the following table: 3579 Internet draft MEGACO Protocol Proposal March 25, 1999 3581 ____________________________________________________________________ 3582 | Type of bearer description | Example of values | 3583 |_________________________________|_________________________________| 3584 | ITU modem standard | V.32, V.34, V.90. | 3585 | ITU modem standard qualified | v.90/3com, | 3586 | by a manufacturer name | v.90/rockwell, | 3587 | | v.90/xxx | 3588 | Well known modem types | X2, K56flex | 3589 | ISDN transparent access, 64 kbps| ISDN64 | 3590 | ISDN64 + V.110 | ISDN64/V.110 | 3591 | ISDN64 + V.120 | ISDN64/V.120 | 3592 | ISDN transparent access, 56 kbps| ISDN56 | 3593 | Informal identification | (Requires coordination between | 3594 | | the Call Agent and the gateway)| 3595 |_________________________________|_________________________________| 3597 The valid values of the framing attribute are defined in the following 3598 table: 3600 _________________________________________________ 3601 | Type of framing description| Example of values| 3602 |____________________________|___________________| 3603 | PPP, asynchronous framing | ppp-asynch | 3604 | PPP, HDLC framing | ppp-hdlc | 3605 | SLIP, asynchronous | slip | 3606 | Asynchronous, no framing | asynch | 3607 |____________________________|___________________| 3609 The network access authentication property provides instructions on the 3610 access control that should be exercized for the data call. This optional 3611 attribute is encoded as: 3613 "a=subnet:"
3614 "/" 3616 Where the properties "network type", "address type", and "connection 3617 address" are formatted as defined for the connection address property 3618 (c=) in SDP, and where the "prefix length" is a decimal representation 3619 of the number of bits in the prefix. 3621 Examples of SDP announcement for the network access service could be: 3623 v=0 3624 m=nas/radius 3625 c=IN IP4 radius.example.net 3627 Internet draft MEGACO Protocol Proposal March 25, 1999 3629 a=bearer:v.34 3630 a=framing:ppp-asynch 3631 a=dialed:18001234567 3632 a=called:12345678901 3633 a=dialing:12340567890 3635 v=0 3636 m=nas/none 3637 c=IN IP4 128.96.41.1 3638 a=subnet:IN IP4 123.45.67.64/26 3639 a=bearer:isdn64 3640 a=framing:ppp-sync 3641 a=dialed:18001234567 3642 a=dialing:2345678901 3644 v=0 3645 c=IN IP4 access.example.net 3646 m=nas/l2tp 3647 k=clear:some-shared-secret 3648 a=bearer:v.32 3649 a=framing:ppp-asynch 3650 a=dialed:18001234567 3651 a=dialing:2345678901 3653 There is no default value of the properties defined for this termination 3654 class.(Editor's note: we may have to define more specific classes, such 3655 as "Internet Access", for which the defaults would apply.) 3657 The following statistics can be collected on NAS terminations: 3659 Number of packets sent: 3660 The total number of NAS packets transmitted since starting 3661 transmission on this connection. 3663 Number of octets sent: 3664 The total number of octets transmitted in NAS packets. 3666 Number of packets received: 3667 The total number of packets received since starting reception on 3668 this connection. 3670 Number of octets received: 3671 The total number of octets received in NAS packets. 3673 Terminations of the NAS class are expected to provide the following sup- 3674 port for event packages: 3676 Internet draft MEGACO Protocol Proposal March 25, 1999 3678 ______________________________________________ 3679 | Package | name | support in NAS class| 3680 |____________|________|_______________________| 3681 | NAS Package| N | Mandatory | 3682 |____________|________|_______________________| 3684 7. Acknowledgements 3686 The authors would like to thank the fine crews of the numerous airlines 3687 that carried them around the world to a succession of interesting meet- 3688 ings, their family members whom they left alone during said meetings, 3689 their colleagues and their staff. 3691 We would also like to extend special thanks to the members of the MEGACO 3692 design team, Nancy-M Greene, Glen Freundlich, David Auerbach, Rex Col- 3693 dren, Dave Oran, Flemming Andreassen, Hong Liu, Michael Ramalho, Gur 3694 Kimchi, Graeme Gibbs, Brian Hill, Ike Elliott, Bob Bell, and Matt Hol- 3695 dredge. 3697 In fact, we would like to thank all the members of the MEGACO working 3698 group, and its chair, Tom Taylor. 3700 8. References 3702 * Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A 3703 Transport Protocol for Real-Time Applications", RFC 1889, January 3704 1996. 3706 * Schulzrinne, H., "RTP Profile for Audio and Video Conferences with 3707 Minimal Control", RFC 1890, January 1996 3709 * Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC 3710 2327, April 1998. 3712 * Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 3713 "Session Initiation Protocol (SIP)", RFC 2543, March 1999. 3715 * Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 3716 Protocol (RTSP)", RFC 2326, April 1998. 3718 * ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN 3719 USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; 3720 modified at Helsinki, 1993) 3722 * ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIG- 3723 NALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga- 3724 Torremolinos, 1984; modified at Helsinki, 1993) 3726 Internet draft MEGACO Protocol Proposal March 25, 1999 3728 * ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA COM- 3729 MUNICATIONS SYSTEMS." 3731 * ITU-T, Recommendation H.225, "Call Signaling Protocols and Media 3732 Stream Packetization for Packet Based Multimedia Communications 3733 Systems." 3735 * ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR MUL- 3736 TIMEDIA COMMUNICATION." 3738 * Atkinson, R., "Security Architecture for the Internet Protocol." 3739 RFC 2401, November 1998. 3741 * Atkinson, R., "IP Authentication Header." RFC 2402, December 1998. 3743 * Atkinson, R., "IP Encapsulating Security Payload (ESP)." RFC 2406, 3744 November 1998. 3746 * Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: 3747 ABNF", RFC 2234, November 1997. 3749 9. Authors' Addresses 3751 Fernando Cuervo, 3752 Nortel Networks 3753 Ottawa, ON, Canada 3754 EMail: cuervo@nortelnetworks.com 3756 Christian Huitema 3757 Telcordia Technologies 3758 445 South Street 3759 Morristown, NJ 07960 3760 EMail: huitema@research.telcordia.com 3762 Keith Kelly 3763 NetSpeak Corporation 3764 902 Clint Moore Road, Suite 104 3765 Boca Raton, FL 33487 3766 EMail: keith@netspeak.com 3768 Brian Rosen 3769 FORE Systems 3770 1000 FORE Drive 3771 Warrendale, PA 15086 3772 EMail: brosen@eng.fore.com 3774 Paul Sijben 3775 Lucent Technologies 3777 Internet draft MEGACO Protocol Proposal March 25, 1999 3779 PO box 18 3780 1270 AA Huizen 3781 the Netherlands 3782 Phone: +31 35 687 4774 3783 Email: sijben@lucent.com 3785 Eric Zimmerer 3786 Level3 Communications 3787 1450 Infinite Drive 3788 Louisville, CO 80027 3789 EMail: eric.zimmerer@level3.com