idnits 2.17.1 draft-ietf-megaco-protocol-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 147 longer pages, the longest (page 42) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 150 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** There are 175 instances of too long lines in the document, the longest one being 75 characters in excess of 72. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 883 has weird spacing: '...signals are n...' == Line 1086 has weird spacing: '...roperty speci...' == Line 1242 has weird spacing: '...sts for the M...' == Line 1276 has weird spacing: '... native withi...' == Line 1361 has weird spacing: '...ockStep and t...' == (9 more instances...) -- 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? 'ErrorDescriptor' on line 2296 looks like a reference -- Missing reference section? 'ServiceChangeDescriptor' on line 2328 looks like a reference -- Missing reference section? 'RFC2402' on line 3080 looks like a reference -- Missing reference section? 'RFC2406' on line 3040 looks like a reference -- Missing reference section? 'RFC2409' on line 3046 looks like a reference -- Missing reference section? 'RFC 2234' on line 4538 looks like a reference -- Missing reference section? 'DOT' on line 4958 looks like a reference -- Missing reference section? 'LF' on line 5066 looks like a reference -- Missing reference section? 'RFC 1889' on line 6556 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Fernando Cuervo 2 INTERNET DRAFT Nortel Networks 3 February 21, 2000 Bryan Hill 4 Expires August 21, 2000 Gotham Networks 5 Nancy Greene 6 Nortel Networks 7 Christian Huitema 8 Telcordia Technologies 9 Abdallah Rayhan 10 Nortel Networks 11 Brian Rosen 12 Marconi 13 John Segers 14 Lucent Technologies 16 Megaco Protocol 18 Status of this document 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other groups 25 may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This document will expire in July 2000. 40 Internet draft MEGACO Protocol February 21, 2000 42 1. SCOPE ..................................................... 8 43 2. REFERENCES ................................................ 8 44 2.1. Normative references ................................. 8 45 2.2. Informative references ............................... 10 46 3. DEFINITIONS ............................................... 11 47 4. ABBREVIATIONS ............................................. 12 48 5. CONVENTIONS ............................................... 12 49 6. CONNECTION MODEL .......................................... 12 50 6.1. Contexts ............................................. 15 51 6.1.1. Context Attributes and Descriptors .............. 16 52 6.1.2. Creating, Deleting and Modifying Contexts ....... 16 53 6.2. Terminations ......................................... 16 54 6.2.1. Termination Dynamics ............................ 17 55 6.2.2. TerminationIDs .................................. 17 56 6.2.3. Packages ........................................ 18 57 6.2.4. Termination Properties and Descriptors .......... 18 58 6.2.5. Root Termination ................................ 20 59 7. COMMANDS .................................................. 21 60 7.1. Descriptors .......................................... 22 61 7.1.1. Specifying Parameters ........................... 22 62 7.1.2. Modem Descriptor ................................ 23 63 7.1.3. Multiplex Descriptor ............................ 23 64 7.1.4. Media Descriptor ................................ 23 65 7.1.5. Termination State Descriptor .................... 24 66 7.1.6. Stream Descriptor ............................... 24 67 7.1.7. LocalControl Descriptor ......................... 25 68 7.1.8. Local and Remote Descriptors .................... 26 69 7.1.9. Events Descriptor ............................... 29 70 7.1.10. EventBuffer Descriptor ......................... 31 71 7.1.11. Signals Descriptor ............................. 31 72 7.1.12. Audit Descriptor ............................... 33 73 7.1.13. ServiceChange Descriptor ....................... 34 74 7.1.14. DigitMap Descriptor ............................ 34 75 7.1.15. Statistics Descriptor .......................... 39 76 7.1.16. Packages Descriptor ............................ 39 77 7.1.17. ObservedEvents Descriptor ...................... 39 78 7.1.18. Topology Descriptor ............................ 39 79 7.2. Command Application Programming Interface ............ 42 80 7.2.1. Add ............................................. 42 81 7.2.2. Modify .......................................... 44 82 7.2.3. Subtract ........................................ 44 83 7.2.4. Move ............................................ 45 84 7.2.5. AuditValue ...................................... 46 85 7.2.6. AuditCapabilities ............................... 48 86 7.2.7. Notify .......................................... 49 87 7.2.8. ServiceChange ................................... 49 88 7.2.9. Manipulating and Auditing Context Attributes .... 53 89 7.2.10. Generic Command Syntax ......................... 54 91 Internet draft MEGACO Protocol February 21, 2000 93 7.3. Command Error Codes .................................. 54 94 8. TRANSACTIONS .............................................. 56 95 8.1. Common Parameters .................................... 57 96 8.1.1. Transaction Identifiers ......................... 57 97 8.1.2. Context Identifiers ............................. 57 98 8.2. Transaction Application Programming Interface ........ 58 99 8.2.1. TransactionRequest .............................. 58 100 8.2.2. TransactionReply ................................ 58 101 8.2.3. TransactionPending .............................. 59 102 8.3. Messages ............................................. 60 103 9. TRANSPORT ................................................. 60 104 9.1. Ordering of Commands ................................. 61 105 9.2. Protection against Restart Avalanche ................. 62 106 10. SECURITY CONSIDERATIONS .................................. 63 107 10.1. Protection of Protocol Connections .................. 63 108 10.2. Interim AH scheme ................................... 64 109 10.3. Protection of Media Connections ..................... 65 110 11. MG-MGC CONTROL INTERFACE ................................. 65 111 11.1. Multiple Virtual MGs ................................ 66 112 11.2. Cold Start .......................................... 67 113 11.3. Negotiation of Protocol Version ..................... 67 114 11.4. Failure of an MG .................................... 68 115 11.5. Failure of an MGC ................................... 68 116 12. PACKAGE DEFINITION ....................................... 69 117 12.1. Guidelines for defining packages .................... 70 118 12.1.1. Package ........................................ 70 119 12.1.2. Properties ..................................... 71 120 12.1.3. Events ......................................... 71 121 12.1.4. Signals ........................................ 72 122 12.1.5. Statistics ..................................... 72 123 12.1.6. Procedures ..................................... 72 124 12.2. Guidelines to defining Properties, Statistics and .. 72 125 12.3. Lists ............................................... 73 126 12.4. Identifiers ......................................... 73 127 12.5. Package Registration ................................ 73 128 13. IANA CONSIDERATIONS ...................................... 73 129 13.1. Packages ............................................ 73 130 13.2. Error Codes ......................................... 74 131 13.3. ServiceChange Reasons ............................... 74 132 ANNEX A BINARY ENCODING OF THE PROTOCOL (NORMATIVE) ........... 76 133 A.1. Coding of wildcards .................................. 76 134 A.2. ASN.1 syntax specification ........................... 78 135 A.3. Digit maps and path names ............................ 93 136 ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE) ............. 94 137 B.1. Coding of wildcards .................................. 95 138 B.2. ABNF specification ................................... 95 139 ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE) ..........106 141 Internet draft MEGACO Protocol February 21, 2000 143 C.1. General Media Attributes .............................107 144 C.2. Mux Properties .......................................107 145 C.3. General Bearer Properties ............................107 146 C.4. General ATM Properties ...............................108 147 C.5. Frame Relay ..........................................108 148 C.6. IP ...................................................109 149 C.7. ATM AAL2 .............................................109 150 C.8. ATM AAL1 .............................................109 151 C.9. Bearer Capabilities ..................................110 152 C.10. AAL5 Properties .....................................111 153 C.11. SDP Equivalents .....................................112 154 C.12. H.245 ...............................................112 155 ANNEX D TRANSPORT OVER IP (NORMATIVE) .........................112 156 D.1. Transport over IP/UDP using Application Level ........112 157 D.1.1. Providing At-Most-Once Functionality ............113 158 D.1.2. Transaction identifiers and three-way handshake 113 159 D.1.2.1. Transaction identifiers ....................113 160 D.1.2.2. Three-way handshake ........................114 161 D.1.3. Computing retransmission timers .................114 162 D.1.4. Provisional responses ...........................115 163 D.1.5. Repeating Requests, Responses and ...............116 164 D.2. using TCP ............................................117 165 D.2.1. Providing the At-Most-Once functionality ........117 166 D.2.2. Transaction identifiers and three way handshake 118 167 D.2.3. Computing retransmission timers .................118 168 D.2.4. Provisional responses ...........................118 169 D.2.5. Ordering of commands ............................118 170 ANNEX E BASIC PACKAGES ........................................118 171 E.1. Generic ..............................................118 172 E.1.1. Properties ......................................119 173 E.1.2. Events ..........................................119 174 E.3.1. Properties ......................................122 175 E.3.2. Events ..........................................123 176 E.3.3. Signals .........................................123 177 E.3.4. Statistics ......................................123 178 E.3.5. Procedures ......................................123 179 E.4. Tone Detection Package ...............................123 180 E.4.1. Properties ......................................124 181 E.4.2. Events ..........................................124 182 E.4.3. Signals .........................................125 183 E.4.4. Statistics ......................................125 184 E.4.5. Procedures ......................................125 185 E.5. Basic DTMF Generator Package .........................125 186 E.5.1. Properties ......................................126 187 E.5.2. Events ..........................................126 189 Internet draft MEGACO Protocol February 21, 2000 191 E.5.3. Signals .........................................126 192 E.5.4. Statistics ......................................127 193 E.5.5. Procedures ......................................127 194 E.6. DTMF detection Package ...............................127 195 E.6.1. Properties ......................................128 196 E.6.2. Events ..........................................128 197 E.6.3. Signals .........................................128 198 E.6.4. Statistics ......................................129 199 E.6.5. Procedures ......................................129 200 E.7. Call Progress Tones Generator Package ................129 201 E.7.1. Properties ......................................129 202 E.7.2. Events ..........................................129 203 E.7.3. Signals .........................................129 204 E.7.4. Statistics ......................................130 205 E.7.5. Procedures ......................................130 206 E.8. Call Progress Tones Detection Package ................130 207 E.8.1. Properties ......................................130 208 E.8.2. Events ..........................................130 209 E.8.3. Signals .........................................130 210 E.8.4. Statistics ......................................131 211 E.8.5. Procedures ......................................131 212 E.9. Analog Line Supervision Package ......................131 213 E.9.1. Properties ......................................131 214 E.9.2. Events ..........................................131 215 E.9.3. Signals .........................................132 216 E.9.4. Statistics ......................................132 217 E.9.5. Procedures ......................................132 218 E.10. Basic Continuity Package ............................132 219 E.10.1. Properties .....................................133 220 E.10.2. Events .........................................133 221 E.10.3. Signals ........................................133 222 E.10.4. Statistics .....................................133 223 E.10.5. Procedures .....................................134 224 E.11. Network Package .....................................134 225 E.11.1. Properties .....................................134 226 E.11.2. Events .........................................134 227 E.11.3. Signals ........................................135 228 E.11.4. Statistics .....................................135 229 E.11.5. Procedures .....................................136 230 E.12. RTP Package .........................................136 231 E.12.1. Properties .....................................136 232 E.12.2. Events .........................................136 233 E.12.3. Signals ........................................137 234 E.12.4. Statistics .....................................137 235 E.12.5. Procedures .....................................137 236 E.13. TDM Circuit Package ................................137 237 E.13.1. Properties .....................................138 238 E.13.2. Events .........................................138 240 Internet draft MEGACO Protocol February 21, 2000 242 E.13.3. Signals ........................................138 243 E.13.4. Statistics .....................................138 244 E.13.5. Procedures .....................................138 245 APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) ..............139 246 A.1. Residential Gateway to Residential Gateway Call .....139 247 A.1.1. Programming Residential GW Analog Line .........139 248 A.1.2. Collecting Originator Digits ....................141 250 Internet draft MEGACO Protocol February 21, 2000 252 TABLE OF FIGURES 253 Figure 1 Example of MEGACOH.248 Connection Model................13 254 Figure 2 Example Call Waiting Scenario / Alerting Applied to T1.14 255 Figure 3 Example Call Waiting Scenario / Answer by T1...........15 256 Figure 4 Example topologies......................... ...........41 257 Figure 5 Transactions, Actions and Commands.....................56 259 Internet draft MEGACO Protocol February 21, 2000 261 1. SCOPE 263 MEGACO defines the protocols used between elements of a physically 264 decomposed multimedia gateway. There are no functional differences from 265 a system view between a decomposed gateway, with distributed sub- 266 components potentially on more than one physical device, and a monol- 267 ithic gateway such as described in H.246. This document does not define 268 how gateways, multipoint control units or integrated voice response 269 units (IVRs) work. Instead it creates a general framework that is suit- 270 able for these applications. 272 Packet network interfaces may include IP, ATM or possibly others. The 273 interfaces will support a variety of SCN signalling systems, including 274 tone signalling, ISDN, ISUP, QSIG, and GSM. National variants of these 275 signalling systems will be supported where applicable. 277 The protocol definition in this document is common text with ITU Recom- 278 mendation H.248. 280 2. REFERENCES 282 2.1. Normative references 284 ITU-T Recommendation H.225.0 (1998): "Call Signalling Protocols and 285 Media Stream Packetization for Packet Based Multimedia Communications 286 Systems". 288 ITU-T Recommendation H.235 (02/98): "Security and encryption for H- 289 Series (H.323 and other H.245-based) multimedia terminals". 291 ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia Com- 292 munication". 294 ITU-T Recommendation H.323 (1998): "Packet Based Multimedia Communica- 295 tion Systems". 297 ITU-T Recommendation I.363.1 (08/96), "B-ISDN ATM Adaptation Layer 298 specification: Type 1 AAL". 300 ITU-T Recommendation I.363.2 (09/97), "B-ISDN ATM Adaptation Layer 301 specification: Type 2 AAL". 303 ITU-T Recommendation I.366.1 (06/98), "Segmentation and Reassembly Ser- 304 vice Specific Convergence Sublayer for the AAL type 2". 306 ITU-T Recommendation I.366.2 (02/99), "AAL type 2 service specific con- 307 vergence sublayer for trunking". 309 Internet draft MEGACO Protocol February 21, 2000 311 ITU-T Recommendation I.371 (08/96), "Traffic control and congestion con- 312 trol in B- ISDN". 314 ITU-T Recommendation Q.763 (09/97), "Signalling System No. 7 - ISDN user 315 part formats and codes". 317 ITU-T Recommendation Q.765, "Signalling System No. 7 - Application tran- 318 sport mechanism". 320 ITU-T Recommendation Q.931 (05/98): "Digital Subscriber Signalling Sys- 321 tem No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification 322 for Basic Call Control". 324 ITU-T Recommendation Q.2630.1 (1999), "AAL Type 2 Signalling Protocol 325 (Capability Set 1)". 327 ITU-T Recommendation Q.2931 (10/95), "Broadband Integrated Services 328 Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 2 329 (DSS 2) - User- Network Interface (UNI) - Layer 3 specification for 330 basic call/connection control". 332 ITU-T Recommendation Q.2941.1 (09/97), "Digital Subscriber Signalling 333 System No. 2 - Generic Identifier Transport". 335 ITU-T Recommendation Q.2961 (10/95), "Broadband integrated services 336 digital network (B-ISDN) - Digital subscriber signalling system no.2 337 (DSS 2) - additional traffic parameters". 339 ITU-T Recommendation Q.2961.2 (06/97), "Digital subscriber signalling 340 system No. 2 - Additional traffic parameters: Support of ATM transfer 341 capability in the broadband bearer capability information element." 343 ITU-T Recommendation X.213 (11/1995), "Information technology - Open 344 System Interconnection - Network service definition plus Amendment 1 345 (08/1997), Addition of the Internet protocol address format identifier". 347 ITU-T Recommendation V.76 (08/96), "Generic multiplexer using V.42 348 LAPM-based procedures". 350 ITU-T Recommendation X.680 (1997): "Information technology-Abstract Syn- 351 tax Notation One (ASN.1): Specification of basic notation". 353 ITU-T Recommendation H.246 (1998), "Interworking of H-series multimedia 354 terminals with H-series multimedia terminals and voice/voiceband termi- 355 nals on GSTN and ISDN". 357 RFC 1006, "ISO Transport Service on top of the TCP, Version 3", Marshall 358 T. Rose, Dwight E. Cass, May 1987. 360 Internet draft MEGACO Protocol February 21, 2000 362 RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", D. Crocker, 363 P. Overell, November 1997. 365 RFC 2327, "SDP: Session Description Protocol", M. Handley, V. Jacobson, 366 April 1998. 368 RFC 2402, "IP Authentication Header", S. Kent, R. Atkinson, November 369 1998. 371 RFC 2406, "IP Encapsulating Security Payload (ESP)", S. Kent, R. Atkin- 372 son, November 1998. 374 2.2. Informative references 376 ITU-T Recommendation E.180/Q.35 (1998): "Technical characteristics of 377 tones for the telephone service". 379 CCITT Recommendation G.711 (1988), "Pulse Code Modulation (PCM) of voice 380 frequencies". 382 ITU-T Recommendation H.221 (05/99),"Frame structure for a 64 to 1920 383 kbit/s channel in audiovisual teleservices". 385 ITU-T Recommendation H.223 (1996), "Multiplexing protocol for low bit 386 rate multimedia communication". 388 ITU-T Recommendation Q.724 (1988): "Signalling procedures". 390 RFC 768, "User Datagram Protocol", J.Postel, August 1980. 392 RFC 791, "Internet protocol", J.Postel, September 1981. 394 RFC 793, "TRANSMISSION CONTROL PROTOCOL", J.Postel, September 1981. 396 RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", H. 397 Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996. 399 RFC 1890, "RTP Profile for Audio and Video Conferences with Minimal Con- 400 trol", H. Schulzrinne, January 1996. 402 RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. 403 Atkinson, November 1998. 405 RFC 2543, " SIP: Session Initiation Protocol", M. Handley, H. 406 Schulzrinne, E. Schooler, J. Rosenberg, March 1999. 408 RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", S. Deer- 409 ing, R. Hinden, December 1998. 411 Internet draft MEGACO Protocol February 21, 2000 413 3. DEFINITIONS 415 Access Gateway: A type of gateway that provides a User to Network Inter- 416 face (UNI) such as ISDN. 418 Descriptor: A syntactic element of the protocol that groups related pro- 419 perties. For instance, the properties of a media flow on the MG can be 420 set by the MGC by including the appropriate descriptor in a command. 422 Media Gateway (MG): The media gateway converts media provided in one 423 type of network to the format required in another type of network. For 424 example, a MG could terminate bearer channels from a switched circuit 425 network (e.g., DS0s) and media streams from a packet network (e.g., RTP 426 streams in an IP network). This gateway may be capable of processing 427 audio, video and T.120 alone or in any combination, and will be capable 428 of full duplex media translations. The MG may also play audio/video mes- 429 sages and performs other IVR functions, or may perform media conferenc- 430 ing. 432 Media Gateway Controller (MGC): Controls the parts of the call state 433 that pertain to connection control for media channels in a MG. 435 Multipoint Control Unit (MCU): An entity that controls the setup and 436 coordination of a multi- user conference that typically includes pro- 437 cessing of audio, video and data. 439 Residential Gateway: A gateway that interworks an analogue line to a 440 packet network. A residential gateway typically contains one or two 441 analogue lines and is located at the customer premises. 443 SCN FAS Signalling Gateway: This function contains the SCN Signalling 444 Interface that terminates SS7, ISDN or other signalling links where the 445 call control channel and bearer channels are collocated in the same phy- 446 sical span. 448 SCN NFAS Signalling Gateway: This function contains the SCN Signalling 449 Interface that terminates SS7 or other signalling links where the call 450 control channels are separated from bearer channels. 452 Stream: Bidirectional media or control flow received/sent by a media 453 gateway as part of a call or conference. 455 Trunk: A communication channel between two switching systems such as a 456 DS0 on a T1 or E1 line. 458 Trunking Gateway: A gateway between SCN network and packet network that 459 typically terminates a large number of digital circuits. 461 Internet draft MEGACO Protocol February 21, 2000 463 4. ABBREVIATIONS 465 This recommendation defines the following terms. 466 ATM Asynchronous Transfer Mode 467 BRI Basic Rate Interface 468 CAS Channel Associated Signalling 469 DTMF Dual Tone Multi-Frequency 470 FAS Facility Associated Signalling 471 GW GateWay 472 IANA Internet Assigned Numbers Authority 473 IP Internet Protocol 474 ISUP ISDN User Part 475 MG Media Gateway 476 MGC Media Gateway Controller 477 NFAS Non-Facility Associated Signalling 478 PRI Primary Rate Interface 479 PSTN Public Switched Telephone Network 480 QoS Quality of Service 481 RTP Real-time Transport Protocol 482 SCN Switched Circuit Network 483 SG Signalling Gateway 484 SS7 Signalling System No. 7 486 5. CONVENTIONS 488 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 489 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 490 document are to be interpreted as described in RFC2119. 492 6. CONNECTION MODEL 494 The connection model for the protocol describes the logical entities, or 495 objects, within the Media Gateway that can be controlled by the Media 496 Gateway Controller. The main abstractions used in the connection model 497 are Terminations and Contexts. 499 A Termination sources and/or sinks one or more streams. In a multimedia 500 conference, a Termination can be multimedia and sources or sinks multi- 501 ple media streams. The media stream parameters, as well as modem, and 502 bearer parameters are encapsulated within the Termination. 504 A Context is an association between a collection of Terminations. There 505 is a special type of Context, the null Context, which contains all Ter- 506 minations that are not associated to any other Termination. For 507 instance, in a decomposed access gateway, all idle lines are represented 508 by Terminations in the null Context. 510 Following is a graphical depiction of these concepts. The diagram of 512 Internet draft MEGACO Protocol February 21, 2000 514 Figure 1 gives several examples and is not meant to be an all-inclusive 515 illustration. The asterisk box in each of the Contexts represents the 516 logical association of Terminations implied by the Context. 518 +------------------------------------------------------+ 519 |Media Gateway | 520 | +-------------------------------------------------+ | 521 | |Context +-------------+ | | 522 | | | Termination | | | 523 | | |-------------| | | 524 | | +-------------+ +->| SCN Bearer |<---+-> 525 | | | Termination | +-----+ | | Channel | | | 526 | | |-------------| | |---+ +-------------+ | | 527 <-+--->| RTP Stream |---| * | | | 528 | | | | | |---+ +-------------+ | | 529 | | +-------------+ +-----+ | | Termination | | | 530 | | | |-------------| | | 531 | | +->| SCN Bearer |<---+-> 532 | | | Channel | | | 533 | | +-------------+ | | 534 | +-------------------------------------------------+ | 535 | | 536 | | 537 | +------------------------------+ | 538 | |Context | | 539 | +-------------+ | +-------------+ | | 540 | | Termination | | +-----+ | Termination | | | 541 | |-------------| | | | |-------------| | | 542 <-+->| SCN Bearer | | | * |------| SCN Bearer |<---+-> 543 | | Channel | | | | | Channel | | | 544 | +-------------+ | +-----+ +-------------+ | | 545 | +------------------------------+ | 546 | | 547 | | 548 | +-------------------------------------------------+ | 549 | |Context | | 550 | | +-------------+ +-------------+ | | 551 | | | Termination | +-----+ | Termination | | | 552 | | |-------------| | | |-------------| | | 553 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> 554 | | | Channel | | | | Channel | | | 555 | | +-------------+ +-----+ +-------------+ | | 556 | +-------------------------------------------------+ | 557 | ___________________________________________________ | 558 +------------------------------------------------------+ 559 Figure 1: Example of MEGACO Connection Model 561 Internet draft MEGACO Protocol February 21, 2000 563 The example below shows an example of one way to accomplish a call- 564 waiting scenario in a decomposed access gateway, illustrating the relo- 565 cation of a Termination between Contexts. Terminations T1 and T2 belong 566 to Context C1 in a two-way audio call. A second audio call is waiting 567 for T1 from Termination T3. T3 is alone in Context C2. T1 accepts the 568 call from T3, placing T2 on hold. This action results in T1 moving into 569 Context C2, as shown below. 571 +------------------------------------------------------+ 572 |Media Gateway | 573 | +-------------------------------------------------+ | 574 | |Context C1 | | 575 | | +-------------+ +-------------+ | | 576 | | | Term. T2 | +-----+ | Term. T1 | | | 577 | | |-------------| | | |-------------| | | 578 <-+--->| RTP Stream |---| * |------| SCN Bearer |<---+-> 579 | | | | | | | Channel | | | 580 | | +-------------+ +-----+ +-------------+ | | 581 | +-------------------------------------------------+ | 582 | | 583 | +-------------------------------------------------+ | 584 | |Context C2 | | 585 | | +-------------+ | | 586 | | +-----+ | Term. T3 | | | 587 | | | | |-------------| | | 588 | | | * |------| SCN Bearer |<---+-> 589 | | | | | Channel | | | 590 | | +-----+ +-------------+ | | 591 | +-------------------------------------------------+ | 592 +------------------------------------------------------+ 593 Figure 2 Example Call Waiting Scenario / Alerting Applied to T1 595 Internet draft MEGACO Protocol February 21, 2000 597 +------------------------------------------------------+ 598 |Media Gateway | 599 | +-------------------------------------------------+ | 600 | |Context C1 | | 601 | | +-------------+ | | 602 | | | Term. T2 | +-----+ | | 603 | | |-------------| | | | | 604 <-+--->| RTP Stream |---| * | | | 605 | | | | | | | | 606 | | +-------------+ +-----+ | | 607 | +-------------------------------------------------+ | 608 | | 609 | +-------------------------------------------------+ | 610 | |Context C2 | | 611 | | +-------------+ +-------------+ | | 612 | | | Term. T1 | +-----+ | Term. T3 | | | 613 | | |-------------| | | |-------------| | | 614 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> 615 | | | Channel | | | | Channel | | | 616 | | +-------------+ +-----+ +-------------+ | | 617 | +-------------------------------------------------+ | 618 +------------------------------------------------------+ 619 Figure 3. Example Call Waiting Scenario / Answer by T1 621 6.1. Contexts 623 A Context is an association between a number of Terminations. The Con- 624 text describes the topology (who hears/sees whom) and the media mixing 625 and/or switching parameters if more than two Terminations are involved 626 in the association. 628 There is a special Context called the null Context. It contains Termina- 629 tions that are not associated to any other Termination. Terminations in 630 the null Context can have their parameters examined or modified, and may 631 have events detected on them. 633 In general, an Add command is used to add Terminations to Contexts. If 634 the MGC does not specify an existing Context to which the Termination is 635 to be added, the MG creates a new Context. A Termination may be removed 636 from a Context with a Subtract command, and a Termination may be moved 637 from one Context to another with a Move command. A Termination SHALL 638 exist in only one Context at a time. 640 The maximum number of Terminations in a Context is a MG property. Media 641 gateways that offer only point-to-point connectivity might allow at most 642 two Terminations per Context. Media gateways that support multipoint 644 Internet draft MEGACO Protocol February 21, 2000 646 conferences might allow three or more terminations per Context. 648 6.1.1. Context Attributes and Descriptors 650 The attributes of Contexts are: 652 * ContextID. 654 * The topology (who hears/sees whom). The topology of a Context 655 describes the flow of media between the Terminations within a Con- 656 text. In contrast, the mode of a Termination (send/receive/...) 657 describes the flow of the media at the ingress/egress of the media 658 gateway. 660 * The priority is used for a context in order to provide the MG with 661 information about a certain precedence handling for a context. The 662 MGC can also use the priority to control autonomously the traffic 663 precedence in the MG in a smooth way in certain situations (e.g. 664 restart), when a lot of contexts must be handled simultaneously. 666 * An indicator for an emergency call is also provided to allow a 667 preference handling in the MG. 669 6.1.2. Creating, Deleting and Modifying Contexts 671 The protocol can be used to (implicitly) create Contexts and modify the 672 parameter values of existing Contexts. The protocol has commands to add 673 Terminations to Contexts, subtract them from Contexts, and to move Ter- 674 minations between Contexts. Contexts are deleted implicitly when the 675 last remaining Termination is subtracted or moved out. 677 6.2. Terminations 679 A Termination is a logical entity on a MG that sources and/or sinks 680 media and/or control streams. A Termination is described by a number of 681 characterizing Properties, which are grouped in a set of Descriptors 682 that are included in commands. Terminations have unique identities (Ter- 683 minationIDs), assigned by the MG at the time of their creation. 685 Terminations representing physical entities have a semi-permanent 686 existence. For example, a Termination representing a TDM channel might 687 exist for as long as it is provisioned in the gateway. Terminations 688 representing ephemeral information flows, such as RTP flows, would usu- 689 ally exist only for the duration of their use. 691 Ephemeral Terminations are created by means of an Add command. They are 692 destroyed by means of a Subtract command. In contrast, when a physical 693 Termination is Added to or Subtracted from a Context, it is taken from 695 Internet draft MEGACO Protocol February 21, 2000 697 or to the null Context, respectively. 699 Terminations may have signals applied to them. Signals are MG generated 700 media streams such as tones and announcements as well as line signals 701 such as hookswitch. Terminations may be programmed to detect Events, 702 the occurrence of which can trigger notification messages to the MGC, or 703 action by the MG. Statistics may be accumulated on a Termination. 704 Statistics are reported to the MGC upon request (by means of the Audit- 705 Value command, see section 7.2.5) and when the Termination is taken out 706 of the call it is in. 708 Multimedia gateways may process multiplexed media streams. For example, 709 Recommendation H.221 describes a frame structure for multiple media 710 streams multiplexed on a number of digital 64 kbit/s channels. Such a 711 case is handled in the connection model in the following way. For every 712 bearer channel that carries part of the multiplexed streams, there is a 713 Termination. The Terminations that source/sink the digital channels are 714 connected to a separate Termination called the multiplexing Termination. 715 This Termination describes the multiplex used (e.g. how the H.221 frames 716 are carried over the digital channels used). The MuxDescriptor is used 717 to this end. If multiple media are carried, this Termination contains 718 multiple StreamDescriptors. The media streams can be associated with 719 streams sourced/sunk by other Terminations in the Context. 721 Terminations may be created which represent multiplexed bearers, such as 722 an ATM AAL2. When a new multiplexed bearer is to be created, an ephem- 723 eral termination is created in a context established for this purpose. 724 When the termination is subtracted, the multiplexed bearer is destroyed. 726 6.2.1. Termination Dynamics 728 The protocol can be used to create new Terminations and to modify pro- 729 perty values of existing Terminations. These modifications include the 730 possibility of adding or removing events and/or signals. The Termina- 731 tion properties, and events and signals are described in the ensuing 732 sections. An MGC can only release/modify terminations and the resources 733 that the termination represents which it has previously seized via, 734 e.g., the Add command. 736 6.2.2. TerminationIDs 738 Terminations are referenced by a TerminationID, which is an arbitrary 739 schema chosen by the MG. 741 TerminationIDs of physical Terminations are provisioned in the Media 742 Gateway. The TerminationIDs may be chosen to have structure. For 743 instance, a TerminationID may consist of trunk group and a trunk within 744 the group. 746 Internet draft MEGACO Protocol February 21, 2000 748 A wildcarding mechanism using two types of wildcards can be used with 749 TerminationIDs. The two wildcards are ALL and CHOOSE. The former is 750 used to address multiple Terminations at once, while the latter is used 751 to indicate to a media gateway that it must select a Termination satis- 752 fying the partially specified TerminationID. This allows, for instance, 753 that a MGC instructs a MG to choose a circuit within a trunk group. 755 When ALL is used in the TerminationID of a command, the effect is ident- 756 ical to repeating the command with each of the matching TerminationIDs. 757 Since each of these commands may generate a response, the size of the 758 entire response may be large. If individual responses are not required, 759 a wildcard response may be requested. In such a case, a single response 760 is generated, which contains the UNION of all of the individual 761 responses which otherwise would have been generated, with duplicate 762 values suppressed. Wildcard response may be particularly useful in the 763 Audit commands. 765 The encoding of the wildcarding mechanism is detailed in Annexes A and 766 B. 768 6.2.3. Packages 770 Different types of gateways may implement Terminations that have widely 771 differing characteristics. Variations in Terminations are accommodated 772 in the protocol by allowing Terminations to have optional Properties, 773 Events, Signals and Statistics implemented by MGs. 775 In order to achieve MG/MGC interoperability, such options are grouped 776 into Packages, and a Termination realizes a set of such Packages. More 777 information on definition of packages can be found in section 12. An 778 MGC can audit a Termination to determine which Packages it realizes. 780 Properties, Events, Signals and Statistics defined in Packages, as well 781 as parameters to them, are referenced by identifiers (Ids). Identifiers 782 are scoped. For each package, PropertyIds, EventIds, SignalIds, Statis- 783 ticsIds and ParameterIds have unique name spaces and the same identifier 784 may be used in each of them. Two PropertyIds in different packages may 785 also have the same identifier, etc. 787 6.2.4. Termination Properties and Descriptors 789 Terminations have properties. The properties have unique PropertyIDs. 790 Most properties have default values. When a Termination is created, 791 properties get their default values, unless the controller specifically 792 sets a different value. The default value of a property of a physical 793 Termination can be changed by setting it to a different value when the 794 Termination is in the null Context. Every time such a Termination 795 returns to the null Context, the values of its properties are reset to 797 Internet draft MEGACO Protocol February 21, 2000 799 this default value. 801 There are a number of common properties for Terminations and properties 802 specific to media streams. The common properties are also called the 803 termination state properties. For each media stream, there are local 804 properties and properties of the received and transmitted flows. 806 Properties not included in the base protocol are defined in Packages. 807 These properties are referred to by a name consisting of the PackageName 808 and a PropertyId. Most properties have default values described in the 809 Package description. Properties may be read-only or read/write. The pos- 810 sible values of a property may be audited, as can their current values. 811 For properties that are read/write, the MGC can set their values. A 812 property may be declared as "Global" which has a single value shared by 813 all terminations realizing the package. Related properties are grouped 814 into descriptors for convenience. 816 When a Termination is Added to a Context, the value of its read/write 817 properties can be set by including the appropriate descriptors as param- 818 eters to the Add command. Properties not mentioned in the command 819 retain their prior values. Similarly, a property of a Termination in a 820 Context may have its value changed by the Modify command. Properties 821 not mentioned in the Modify command retain their prior values. Proper- 822 ties may also have their values changed when a Termination is moved from 823 one Context to another as a result of a Move command. In some cases, 824 descriptors are returned as output from a command. The following table 825 lists all of the possible Descriptors and their use. Not all descrip- 826 tors are legal as input or output parameters to every command. 828 _________________________________________________________________________ 829 |Descriptor Name |Description | 830 |__________________|____________________________________________________| 831 |Modem |Identifies modem type and properties when | 832 | |applicable | 833 |__________________|____________________________________________________| 834 |Mux |Describes multiplex type for multimedia terminations| 835 | |(e.g. H.221, H.223, H.225.0) and Terminations | 836 | |forming the input mux. | 837 |__________________|____________________________________________________| 838 |Media |A list of media stream specifications (see 7.1.4) | 839 |__________________|____________________________________________________| 840 |TerminationState |Properties of a Termination (which can be defined in| 841 | |Packages) that are not stream specific. | 842 |__________________|____________________________________________________| 843 |Stream |A list of remote/local/localControl descriptors for | 844 | |a single stream | |__________________|____________________________________________________| 845 |Local |Contains properties that specify the media flows | 847 Internet draft MEGACO Protocol February 21, 2000 849 | |that MG receives from the remote entity. | 850 |__________________|____________________________________________________| 851 | | | 852 |Remote |Contains properties that specify the media flows | 853 | |that the MG sends to the remote entity. | |__________________|____________________________________________________| 854 |LocalControl |Contains properties (which can be defined in | 855 | |packages) that are of interest between the MG and | 856 | |the MGC | |__________________|____________________________________________________| 857 |Events |Describes events to be detected by the MG and what | 858 | |to do when an event is detected | |__________________|____________________________________________________| 859 |EventBuffer |Describes events to be detected by the MG when Event| 860 | |Buffering is active | |__________________|____________________________________________________| 861 |Signals |Describes signals and/or actions to be applied (e.g.| 862 | |Busy Tone) to the Terminations | |__________________|____________________________________________________| 863 |Audit |In Audit commands, identifies which information is | 864 | |desired | 865 |__________________|____________________________________________________| 866 |Packages |In AuditValue, returns a list of Packages realized | 867 | |by a Termination | |__________________|____________________________________________________| 868 |DigitMap |Instructions for handling DTMF tones at the MG | 869 |__________________|____________________________________________________| 870 |ServiceChange |In ServiceChange, what, why service change occurred,| 871 | |etc. | 872 |__________________|____________________________________________________| 873 |ObservedEvents |In Notify or AuditValue, report of events observed | 874 |__________________|____________________________________________________| 875 |Statistics |In Subtract and Audit, Report of Statistics kept on | 876 | |a Termination. | |__________________|____________________________________________________| 878 6.2.5. Root Termination 880 Occasionally, a command must refer to the entire gateway, rather than a 881 termination within it. A special TerminationID, "Root" is reserved for 882 this purpose. Packages may be defined on Root. Root thus may have pro- 883 perties and events (signals are not appropriate for root). Accord- 884 ingly, the root TerminationID may appear in: 886 * a Modify command - to change a property or set an event 888 * a Notify command - to report an event 890 * an AuditValue return - to examine the values of properties imple- 891 mented on root 893 * an AuditCapability - to determine what properties of root are 894 implemented a ServiceChange - to declare the gateway in or out of 895 service Any other use of the root TerminationID is an error. 897 Internet draft MEGACO Protocol February 21, 2000 899 7. COMMANDS 901 The protocol provides commands for manipulating the logical entities of 902 the protocol connection model, Contexts and Terminations. Commands pro- 903 vide control at the finest level of granularity supported by the proto- 904 col. For example, Commands exist to add Terminations to a Context, 905 modify Terminations, subtract Terminations from a Context, and audit 906 properties of Contexts or Terminations. Commands provide for complete 907 control of the properties of Contexts and Terminations. This includes 908 specifying which events a Termination is to report, which 909 signals/actions are to be applied to a Termination and specifying the 910 topology of a Context (who hears/sees whom). 912 Most commands are for the specific use of the Media Gateway Controller 913 as command initiator in controlling Media Gateways as command 914 responders. The exceptions are the Notify and ServiceChange commands: 915 Notify is sent from Media Gateway to Media Gateway Controller, and Ser- 916 viceChange may be sent by either entity. Below is an overview of the 917 commands; they are explained in more detail in section 7.2. 919 1. Add. The Add command adds a termination to a context. The Add com- 920 mand on the first Termination in a Context is used to create a Con- 921 text. 923 2. Modify. The Modify command modifies the properties, events and sig- 924 nals of a termination. 926 3. Subtract. The Subtract command disconnects a Termination from its 927 Context and returns statistics on the Termination's participation 928 in the Context. The Subtract command on the last Termination in a 929 Context deletes the Context. 931 4. Move. The Move command atomically moves a Termination to another 932 context. 934 5. AuditValue. The AuditValue command returns the current state of 935 properties, events, signals and statistics of Terminations. 937 6. AuditCapabilities. The AuditCapabilities command returns all the 938 possible values for Termination properties, events and signals 939 allowed by the Media Gateway. 941 7. Notify. The Notify command allows the Media Gateway to inform the 942 Media Gateway Controller of the occurrence of events in the Media 943 Gateway. 945 8. ServiceChange. The ServiceChange Command allows the Media Gateway 946 to notify the Media Gateway Controller that a Termination or group 948 Internet draft MEGACO Protocol February 21, 2000 950 of Terminations is about to be taken out of service or has just 951 been returned to service. ServiceChange is also used by the MG to 952 announce its availability to an MGC (registration), and to notify 953 the MGC of impending or completed restart of the MG. The MGC may 954 announce a handover to the MG by sending it a ServiceChange com- 955 mand. The MGC may also use ServiceChange to instruct the MG to 956 take a Termination or group of Terminations in or out of service. 957 These commands are detailed in sections 7.2.1 through 7.2.8 959 7.1. Descriptors 961 The parameters to a command are termed Descriptors. A Descriptor con- 962 sists of a name and a list of items. Some items may have values. Many 963 Commands share common Descriptors. This subsection enumerates these 964 Descriptors. Descriptors may be returned as output from a command. 965 Parameters and parameter usage specific to a given Command type are 966 described in the subsection that describes the Command. 968 7.1.1. Specifying Parameters 970 Command parameters are structured into a number of descriptors. In gen- 971 eral, the text format of descriptors is 972 DescriptorName={parm=value, parm=value....} 974 Parameters may be fully specified, over-specified or under-specified: 976 1. Fully specified parameters have a single, unambiguous value that 977 the command initiator is instructing the command responder to use 978 for the specified parameter. 980 2. Under-specified parameters, using the CHOOSE value, allow the com- 981 mand responder to choose any value it can support. 983 3. Over-specified parameters have a list of potential values. The 984 list order specifies the command initiator's order of preference of 985 selection. The command responder chooses one value from the 986 offered list and returns that value to the command initiator. 987 Unspecified mandatory parameters (i.e. mandatory parameters not 988 specified in a descriptor) result in the command responder retain- 989 ing the previous value for that parameter. Unspecified optional 990 parameters result in the command responder using the default value 991 of the parameter. Whenever a parameter is underspecified or over- 992 specified, the descriptor containing the value chosen by the 993 responder is included as output from the command. 995 Each command specifies the TerminationId the command operates on. This 996 TerminationId may be "wildcarded". When the TerminationId of a command 997 is wildcarded, the effect shall be as if the command was repeated with 999 Internet draft MEGACO Protocol February 21, 2000 1001 each of the TerminationIds matched. 1003 7.1.2. Modem Descriptor 1005 The Modem descriptor specifies the modem type and parameters, if any, 1006 required for use in e.g. H.324 and text conversation. The descriptor 1007 includes the following modem types: V.18, V.22, V.22bis, V.32, V.32bis, 1008 V.34, V.90, V.91, Synchronous ISDN, and allows for extensions. By 1009 default, no modem descriptor is present in a Termination. 1011 7.1.3. Multiplex Descriptor 1013 In multimedia calls, a number of media streams are carried on a (possi- 1014 bly different) number of bearers. The multiplex descriptor associates 1015 the media and the bearers. The descriptor includes the multiplex type: 1017 * H.221 1019 * H.223, 1021 * H.226, 1023 * V.76, 1025 * Possible Extensions and a set of TerminationIDs representing the 1026 multiplexed inputs, in order. For example: 1028 Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22} 1030 7.1.4. Media Descriptor 1032 The Media Descriptor specifies the parameters for all the media streams. 1033 These parameters are structured into two descriptors, a Termination 1034 State Descriptor, which specifies the properties of a termination that 1035 are not stream dependent, and one or more Stream Descriptors each of 1036 which describes a single media stream. 1038 A stream is identified by a StreamID. The StreamID is used to link the 1039 streams in a Context that belong together. Multiple streams exiting a 1040 termination shall be synchronized with each other. Within the Stream 1041 Descriptor, there are up to three subsidiary descriptors, LocalControl, 1042 Local, and Remote. The relationship between these descriptors is thus: 1044 Media Descriptor 1045 TerminationStateDescriptor 1046 Stream Descriptor 1047 LocalControl Descriptor 1048 Local Descriptor 1050 Internet draft MEGACO Protocol February 21, 2000 1052 Remote Descriptor 1054 As a convenience a LocalControl, Local, or Remote descriptor may be 1055 included in the Media Descriptor without an enclosing Stream descriptor. 1056 In this case, the StreamID is assumed to be 1. 1058 7.1.5. Termination State Descriptor 1060 The Termination State Descriptor contains the ServiceStates property, 1061 the EventBufferControl property and properties of a termination (defined 1062 in Packages) that are not stream specific. 1064 The ServiceStates property describes the overall state of the termina- 1065 tion (not stream-specific). A Termination can be in one of the follow- 1066 ing states: "test", "out of service", or "in service". The "test" state 1067 indicates that the termination is being tested. The state "out of ser- 1068 vice" indicates that the termination cannot be used for traffic. The 1069 state "in service" indicates that a termination can be used or is being 1070 used for normal traffic. "in service" is the default state. 1072 Values assigned to Properties may be simple values 1073 (integer/string/enumeration) or may be underspecified, where more than 1074 one value is supplied and the MG may make a choice: 1076 * Alternative Values - multiple values in a list, one of which must 1077 be selected 1079 * Ranges - minimum and maximum values, any value between min and max 1080 must be selected, boundary values included 1082 * Greater Than/Less Than - value must be greater/less than specified 1083 value 1085 * CHOOSE Wildcard - the MG chooses from the allowed values for the 1086 property The EventBufferControl property specifies whether events 1087 are buffered following detection of an event in the Events Descrip- 1088 tor, or processed immediately. See section 7.1.9 for details. 1090 7.1.6. Stream Descriptor 1092 A Stream descriptor specifies the parameters of a single bi-directional 1093 stream. These parameters are structured into three descriptors: one 1094 that contains termination properties specific to a stream and one each 1095 for local and remote flows. The Stream Descriptor includes a StreamID 1096 which identifies the stream. Streams are created by specifying a new 1097 StreamID on one of the terminations in a Context. A stream is deleted by 1098 setting empty Local and Remote descriptors for the stream with 1100 Internet draft MEGACO Protocol February 21, 2000 1102 ReserveGroup and ReserveValue in LocalControl set to "false" on all ter- 1103 minations in the context that previously supported that stream. 1105 StreamIDs are of local significance between MGC and MG and they are 1106 assigned by the MGC. Within a context, StreamID is a means by which to 1107 indicate which media flows are interconnected: streams with the same 1108 StreamID are connected. 1110 If a termination is moved from one context to another, the effect on the 1111 context to which the termination is moved is the same as in the case 1112 that a new termination were added with the same StreamIDs as the moved 1113 termination. 1115 7.1.7. LocalControl Descriptor 1117 The LocalControl Descriptor contains the Mode property, the ReserveGroup 1118 and ReserveValue properties and properties of a termination (defined in 1119 Packages) that are stream specific, and are of interest between the MG 1120 and the MGC. Values of properties may be underspecified as in section 1121 7.1.1. 1123 The allowed values for the mode property are send-only, receive-only, 1124 send/receive, inactive and loop-back. "Send" and "receive" are with 1125 respect to the exterior of the context, so that, for example, a stream 1126 set to mode=sendonly does not pass received media into the context. 1127 Signals and Events are not affected by mode. The boolean-valued Reserve 1128 properties, ReserveValue and ReserveGroup, of a Termination indicate 1129 what the MG is expected to do when it receives a local and/or remote 1130 descriptor. 1132 If the value of a Reserve property is True, the MG SHALL reserve 1133 resources for all alternatives specified in the local and/or remote 1134 descriptors for which it currently has resources available. It SHALL 1135 respond with the alternatives for which it reserves resources. If it 1136 cannot not support any of the alternatives, it SHALL respond with a 1137 reply to the MGC that contains empty local and/or remote descriptors. 1139 If the value of a Reserve property is False, the MG SHALL choose one of 1140 the alternatives specified in the local descriptor (if present) and one 1141 of the alternatives specified in the remote descriptor (if present). If 1142 the MG has not yet reserved resources to support the selected alterna- 1143 tive, it SHALL reserve the resources. If, on the other hand, it already 1144 reserved resources for the Termination addressed (because of a prior 1145 exchange with ReserveValue and/or ReserveGroup equal to True), it SHALL 1146 release any excess resources it reserved previously. Finally, the MG 1147 shall send a reply to the MGC containing the alternatives for the local 1148 and/or remote descriptor that it selected. If the MG does not have suf- 1149 ficient resources to support any of the alternatives specified, is SHALL 1151 Internet draft MEGACO Protocol February 21, 2000 1153 respond with error 510 (insufficient resources). 1155 The default value of ReserveValue and ReserveGroup is False. 1157 A new setting of the LocalControl Descriptor completely replaces the 1158 previous setting of that descriptor in the MG. Thus to retain informa- 1159 tion from the previous setting the MGC must include that information in 1160 the new setting. If the MGC wishes to delete some information from the 1161 existing descriptor, it merely resends the descriptor (in a Modify com- 1162 mand) with the unwanted information stripped out. 1164 7.1.8. Local and Remote Descriptors 1166 The MGC uses Local and Remote descriptors to reserve and commit MG 1167 resources for media decoding and encoding for the given Stream(s) and 1168 Termination to which they apply. The MG includes these descriptors in 1169 its response to indicate what it is actually prepared to support. The 1170 MG SHALL include additional properties and their values in its response 1171 if these properties are mandatory yet not present in the requests made 1172 by the MGC (e.g., by specifying detailed video encoding parameters where 1173 the MGC only specified the payload type). 1175 Local refers to the media received by the MG and Remote refers to the 1176 media sent by the MG. 1178 When text encoding the protocol, the descriptors consist of session 1179 descriptions as defined in SDP (RFC2327). In session descriptions sent 1180 from the MGC to the MG, the following exceptions to the syntax of RFC 1181 2327 are allowed: 1183 * the "s=", "t=" and "o=" lines are optional, 1185 * the use of CHOOSE is allowed in place of a single parameter value, 1186 and 1188 * the use of alternatives is allowed in place of a single parameter 1189 value. 1191 * When multiple session descriptions are provided in one descriptor, 1192 the "v=" lines are required as delimiters; otherwise they are 1193 optional in session descriptions sent to the MG. Implementations 1194 shall accept session descriptions that are fully conformant to 1195 RFC2327. When binary encoding the protocol the descriptor consists 1196 of groups of properties (tag-value pairs) as specified in Annex C. 1197 Each such group may contain the parameters of a session descrip- 1198 tion. 1200 Below, the semantics of the local and remote descriptors are specified 1202 Internet draft MEGACO Protocol February 21, 2000 1204 in detail. The specification consists of two parts. The first part 1205 specifies the interpretation of the contents of the descriptor. The 1206 second part specifies the actions the MG must take upon receiving the 1207 local and remote descriptors. The actions to be taken by the MG depend 1208 on the values of the ReserveValue and ReserveGroup properties of the 1209 LocalControl descriptor. 1211 Either the local or the remote descriptor or both may be 1213 * unspecified (i.e., absent), 1215 * empty, 1217 * underspecified through use of CHOOSE in a property value, 1219 * fully specified, or 1221 * overspecified through presentation of multiple groups of properties 1222 and possibly multiple property values in one or more of these 1223 groups. Where the descriptors have been passed from the MGC to the 1224 MG, they are interpreted according to the rules given in section 1225 7.1.1, with the following additional comments for clarification: 1227 (a) An unspecified Local or Remote descriptor is considered to be a 1228 missing mandatory parameter. It requires the MG to use whatever 1229 was last specified for that descriptor. It is possible that there 1230 was no previously-specified value, in which case the descriptor 1231 concerned is ignored in further processing of the command. 1233 (b) An empty Local (Remote) descriptor in a message from the MGC signi- 1234 fies a request to release any resources reserved for the media flow 1235 received (sent). 1237 (c) If multiple groups of properties are present in a Local or Remote 1238 descriptor or multiple values within a group, the order of prefer- 1239 ence is descending. 1241 (d) Underspecified or overspecified properties within a group of pro- 1242 perties sent by the MGC are requests for the MG to choose one or 1243 more values which it can support for each of those properties. In 1244 case of an overspecified property, the list of values is in des- 1245 cending order of preference. 1247 Subject to the above rules, subsequent action depends on the values of 1248 the ReserveValue and ReserveGroup properties in LocalControl. If 1249 ReserveGroup is true, the MG reserves the resources required to support 1250 any of the requested property group alternatives that it can currently 1251 support. If ReserveValue is true, the MG reserves the resources 1253 Internet draft MEGACO Protocol February 21, 2000 1255 required to support any of the requested property value alternatives 1256 that it can currently support. 1258 NOTE - If a Local or Remote descriptor contains multiple groups of pro- 1259 perties, and ReserveGroup is true, then the MG is requested to reserve 1260 resources so that it can decode or encode the media stream according to 1261 any of the alternatives. For instance, if the Local descriptor contains 1262 two groups of properties, one specifying packetized G.711 A-law audio 1263 and the other G.723.1 audio, the MG reserves resources so that it can 1264 decode one audio stream encoded in either G.711 A-law format or G.723.1 1265 format. The MG does not have to reserve resources to decode two audio 1266 streams simultaneously, one encoded in G.711 A-law and one in G.723.1. 1267 The intention for the use of ReserveValue is analogous. If Reserve- 1268 Group is true or ReserveValue is true, then the following rules apply. 1270 * If the MG has insufficient resources to support all alternatives 1271 requested by the MGC and the MGC requested resources in both Local 1272 and Remote, the MG should reserve resources to support at least 1273 one alternative each within Local and Remote. 1275 * If the MG has insufficient resources to support at least one alter- 1276 native within a Local (Remote) descriptor received from the MGC, 1277 it shall return an empty Local (Remote) in response. 1279 * In its response to the MGC, when the MGC included Local and Remote 1280 descriptors, the MG SHALL include Local and Remote descriptors for 1281 all groups of properties and property values it reserved resources 1282 for. If the MG is incapable of supporting at least one of the 1283 alternatives within the Local (Remote) descriptor received from the 1284 MGC, it SHALL return an empty Local (Remote) descriptor. 1286 * If the Mode property of the LocalControl descriptor is RecvOnly or 1287 SendRecv, the MG must be prepared to receive media encoded accord- 1288 ing to any of the alternatives included in its response to the MGC. 1289 If ReserveGroup is False and ReserveValue is false, then the MG 1290 SHOULD apply the following rules to resolve Local and Remote to a 1291 single alternative each: 1293 * The MG chooses the first alternative in Local for which it is able 1294 to support at least one alternative in Remote. 1296 * If the MG is unable to support at least one Local and one Remote 1297 alternative, it returns Error 510 (Insufficient Resources). 1299 * The MG returns its selected alternative in each of Local and 1300 Remote. A new setting of a Local or Remote Descriptor completely 1301 replaces the previous setting of that descriptor in the MG. Thus 1302 to retain information from the previous setting the MGC must 1304 Internet draft MEGACO Protocol February 21, 2000 1306 include that information in the new setting. If the MGC wishes to 1307 delete some information from the existing descriptor, it merely 1308 resends the descriptor (in a Modify command) with the unwanted 1309 information stripped out. 1311 7.1.9. Events Descriptor 1313 The EventsDescriptor parameter contains a RequestIdentifier and a list 1314 of events that the Media Gateway is requested to detect and report. The 1315 RequestIdentifier is used to correlate the request with the notifica- 1316 tions that it may trigger. Requested events include, for example, fax 1317 tones, continuity test results, and on-hook and off-hook transitions. 1319 Each event in the descriptor contains the Event name, an optional 1320 streamID, an optional KeepActive flag, and optional parameters. The 1321 Event name consists of a Package Name (where the event is defined) and 1322 an EventID. The ALL wildcard may be used for the EventID, indicating 1323 that all events from the specified package have to be detected. The 1324 default streamID is 0, indicating that the event to be detected is not 1325 related to a particular media stream. Events can have parameters. This 1326 allows a single event description to have some variation in meaning 1327 without creating large numbers of individual events. Further event 1328 parameters are defined in the package. 1330 The default action of the MG, when it detects an event in the Events 1331 Descriptor, is to send a Notify command to the MG. Any other action is 1332 for further study. 1334 If the value of the EventBufferControl property equals LockStep, follow- 1335 ing detection of such an event, normal handling of events is suspended. 1336 Any event which is subsequently detected and occurs in the EventBuffer 1337 Descriptor is added to the end of the EventBuffer (a FIFO queue), along 1338 with the time that it was detected. The MG SHALL wait for a new 1339 EventsDescriptor to be loaded. A new EventsDescriptor can be loaded 1340 either as the result of receiving a command with a new EventsDescriptor, 1341 or by activating an embedded EventsDescriptor. 1343 If EventBufferControl equals Off, the MG continues processing based on 1344 the active EventsDescriptor. 1346 In the case that an embedded EventsDescriptor being activated, the MG 1347 continues event processing based on the newly activated EventsDescriptor 1348 (Note - for purposes of EventBuffer handling, activation of an embedded 1349 EventsDescriptor is equivalent to receipt of a new EventsDescriptor). 1351 When the MG receives a command with a new EventsDescriptor, one or more 1352 events may have been buffered in the EventBuffer in the MG. The value of 1353 EventBufferControl then determines how the MG treats such buffered 1355 Internet draft MEGACO Protocol February 21, 2000 1357 events. 1359 Case 1 1361 If EventBufferControl = LockStep and the MG receives a new 1362 EventsDescriptor it will check the FIFO EventBuffer and take the follow- 1363 ing actions: 1365 1. If the EventBuffer is empty, the MG waits for detection of events 1366 based on the new EventsDescriptor. 1368 2. If the EventBuffer is non-empty, the MG processes the FIFO queue 1369 starting with the first event: 1371 - If the event in the queue is in the events listed in the new 1372 EventsDescriptor, the default action of the MG is to send a Notify 1373 command to the MGC and remove the event from the EventBuffer. Any 1374 other action is for further study. The time stamp of the Notify 1375 shall be the time the event was actually 1377 * detected. The MG then waits for a new EventsDescriptor. While 1378 waiting for a new EventsDescriptor, any events matching the 1379 EventsBufferDescriptor will be placed in the EventBuffer and the 1380 event processing will repeat from step 1. 1382 * If the event is not in the new EventsDescriptor, the MG SHALL dis- 1383 card the event and repeat from step 1. 1385 Case 2 1387 If EventBufferControl equals Off and the MG receives a new 1388 EventsDescriptor, it processes new events with the new EventsDescriptor. 1390 If the MG receives a command instructing it to set the value of 1391 EventBufferControl to Off, all events in the EventBuffer SHALL be dis- 1392 carded. 1394 The MG may report several events in a single Transaction as long as this 1395 does not unnecessarily delay the reporting of individual events. 1397 For procedures regarding transmitting the Notify command, refer to the 1398 appropriate annex for specific transport considerations. 1400 The default value of EventBufferControl is Off. 1402 Note - Since the EventBufferControl property is in the TerminationSta- 1403 teDescriptor, the MG might receive a command that changes the EventBuf- 1404 ferControl property and does not include an EventsDescriptor. 1406 Internet draft MEGACO Protocol February 21, 2000 1408 Normally, detection of an event shall cause any active signals to stop. 1409 When KeepActive is specified in the event, the MG shall not interrupt 1410 any signals active on the Termination on which the event is detected. 1412 An event can include an Embedded Signals descriptor and/or an Embedded 1413 Events Descriptor which, if present, replaces the current Signals/Events 1414 descriptor when the event is detected. It is possible, for example, to 1415 specify that the dial-tone Signal be generated when an off-hook Event is 1416 detected, or that the dial-tone Signal be stopped when a digit is 1417 detected. A media gateway controller shall not send EventsDescriptors 1418 with an event both marked KeepActive and containing an embedded Sig- 1419 nalsDescriptor. 1421 Only one level of embedding is permitted. An embedded EventsDescriptor 1422 SHALL NOT contain another embedded EventsDescriptor; an embedded 1423 EventsDescriptor may contain an embedded SignalsDescriptor. 1425 An EventsDescriptor received by a media gateway replaces any previous 1426 Events Descriptor. Event notification in process shall complete, and 1427 events detected after the command containing the new EventsDescriptor 1428 executes, shall be processed according to the new EventsDescriptor. 1430 7.1.10. EventBuffer Descriptor 1432 The EventBuffer Descriptor contains a list of events, with their parame- 1433 ters if any, that the MG is requested to detect and buffer when 1434 EventBufferControl equals LockStep (see 7.1.9). 1436 7.1.11. Signals Descriptor 1438 A SignalsDescriptor is a parameter that contains the set of signals that 1439 the Media Gateway is asked to apply to a Termination. A SignalsDescrip- 1440 tor contains a number of signals and/or sequential signal lists. A Sig- 1441 nalsDescriptor may contain zero signals and sequential signal lists. 1442 Support of sequential signal lists is optional. 1444 Signals are defined in packages. Signals shall be named with a Package 1445 name (in which the signal is defined) and a SignalID. No wildcard shall 1446 be used in the SignalID. Signals that occur in a SignalsDescriptor have 1447 an optional StreamID parameter (default is 0, to indicate that the sig- 1448 nal is not related to a particular media stream), an optional signal 1449 type (see below), an optional duration and possibly parameters defined 1450 in the package that defines the signal. This allows a single signal to 1451 have some variation in meaning, obviating the need to create large 1452 numbers of individual signals. Finally, the optional parameter 1453 "notifyCompletion" allows a MGC to indicate that it wishes to be noti- 1454 fied when the signal finishes playout. When the MGC enables the signal 1455 completion event (see section E.1.2) in an Events Descriptor, that event 1457 Internet draft MEGACO Protocol February 21, 2000 1459 is detected whenever a signal terminates and "notifyCompletion" for that 1460 signal is set to TRUE. The signal completion event of section E.1.2 has 1461 a parameter that indicates how the signal terminated: it played to com- 1462 pletion, it was interrupted by an event, it was halted because a new 1463 SignalsDescriptor arrived, or the signal did not complete for some other 1464 reason. 1466 The duration is an integer value that is expressed in hundredths of a 1467 second. 1469 There are three types of signals: 1471 * on/off - the signal lasts until it is turned off, 1473 * timeout - the signal lasts until it is turned off or a specific 1474 period of time elapses, 1476 * brief - the signal duration is so short that it will stop on its 1477 own unless a new signal is applied that causes it to stop; no 1478 timeout value is needed. 1480 If the signal type is specified in a SignalsDescriptor, it overrides the 1481 default signal type (see Section 12.1.4). If duration is specified for 1482 an on/off signal, it SHALL be ignored. 1484 A sequential signal list consists of a signal list identifier, a 1485 sequence of signals to be played sequentially, and a signal type. Only 1486 the trailing element of the sequence of signals in a sequential signal 1487 list may be an on/off signal. If the trailing element of the sequence 1488 is an on/off signal, the signal type of the sequential signal list shall 1489 be on/off as well. If the sequence of signals in a sequential signal 1490 list contains signals of type timeout and the trailing element is not of 1491 type on/off, the type of the sequential signal list SHALL be set to 1492 timeout. The duration of a sequential signal list with type timeout is 1493 the sum of the durations of the signals it contains. If the sequence of 1494 signals in a sequential signal list contains only signals of type brief, 1495 the type of the sequential signal list SHALL be set to brief. A signal 1496 list is treated as a single signal of the specified type when played 1497 out. 1499 Multiple signals and sequential signal lists in the same SignalsDescrip- 1500 tor shall be played simultaneously. 1502 Signals are defined as proceeding from the termination towards the exte- 1503 rior of the Context unless otherwise specified in a package. When the 1504 same Signal is applied to multiple Terminations within one Transaction, 1505 the MG should consider using the same resource to generate these Sig- 1506 nals. 1508 Internet draft MEGACO Protocol February 21, 2000 1510 Production of a Signal on a Termination is stopped by application of a 1511 new SignalsDescriptor, or detection of an Event on the Termination (see 1512 section 7.1.9). 1514 A new SignalsDescriptor replaces any existing SignalsDescriptor. Any 1515 signals applied to the Termination not in the replacement descriptor 1516 shall be stopped, and new signals are applied, except as follows. Sig- 1517 nals present in the replacement descriptor and containing the KeepActive 1518 flagshall be continued if they are currently playing and have not 1519 already completed. If a replacement signal descriptor contains a signal 1520 that is not currently playing and contains the KeepActive flag, that 1521 signal SHALL be ignored. If the replacement descriptor contains a 1522 sequential signal list with the same identifier as the existing descrip- 1523 tor, then 1525 * the signal type and sequence of signals in the sequential signal 1526 list in the replacement descriptor shall be ignored, and 1528 * the playing of the signals in the sequential signal list in the 1529 existing descriptor shall not be interrupted. 1531 7.1.12. Audit Descriptor 1533 The Audit Descriptor specifies what information is to be audited. The 1534 Audit Descriptor specifies the list of descriptors to be returned. 1535 Audit may be used in any command to force the return of a descriptor 1536 even if the descriptor in the command was not present, or had no under- 1537 specified parameters. Possible items in the Audit Descriptor are: 1539 ________________ 1540 | Modem | 1541 |________________| 1542 | Mux | 1543 |________________| 1544 | Events | 1545 |________________| 1546 | Media | 1547 |________________| 1548 | Signals | 1549 |________________| 1550 | ObservedEvents | 1551 |________________| 1552 | DigitMap | 1553 |________________| 1554 | Statistics | 1555 |________________| 1556 | Packages | 1558 Internet draft MEGACO Protocol February 21, 2000 1560 |_______________| 1561 | EventBuffer | 1562 |_______________| 1564 Audit may be empty, in which case, no descriptors are returned. This is 1565 useful in Subtract, to inhibit return of statistics, especially when 1566 using wildcard. 1568 7.1.13. ServiceChange Descriptor 1570 The ServiceChangeDescriptor contains the following parameters: 1572 * ServiceChangeMethod 1574 * ServiceChangeReason 1576 * ServiceChangeAddress 1578 * ServiceChangeDelay 1580 * ServiceChangeProfile 1582 * ServiceChangeVersion 1584 * ServiceChangeMGCId 1586 * TimeStamp 1588 See section 7.2.8 1590 7.1.14. DigitMap Descriptor 1592 A DigitMap is a dialing plan resident in the Media Gateway used for 1593 detecting and reporting digit events received on a Termination. The 1594 DigitMap Descriptor contains a DigitMap name and the DigitMap to be 1595 assigned. A digit map may be preloaded into the MG by management action 1596 and referenced by name in an EventsDescriptor, may be defined dynami- 1597 cally and subsequently referenced by name, or the actual digitmap itself 1598 may be specified in the EventsDescriptor. It is permissible for a digit 1599 map completion event within an Events Descriptor to refer by name to a 1600 DigitMap which is defined by a DigitMap Descriptor within the same com- 1601 mand, regardless of the transmitted order of the respective descriptors. 1603 DigitMaps defined in a DigitMapDescriptor can occur in any of the stan- 1604 dard Termination manipulation Commands of the protocol. A DigitMap, 1605 once defined, can be used on all Terminations specified by the (possibly 1606 wildcarded) TerminationID in such a command. DigitMaps defined on the 1608 Internet draft MEGACO Protocol February 21, 2000 1610 root Termination are global and can be used on every Termination in the 1611 MG, provided that a DigitMap with the same name has not been defined on 1612 the given Termination. When a DigitMap is defined dynamically in a 1613 DigitMap Descriptor: 1615 * A new DigitMap is created by specifying a name that is not yet 1616 defined. The value shall be present. 1618 * A DigitMap value is updated by supplying a new value for a name 1619 that is already defined. Terminations presently using the digitmap 1620 shall continue to use the old definition; subsequent EventsDescrip- 1621 tors specifying the name, including any EventsDescriptor in the 1622 command containing the DigitMap descriptor, shall use the new one. 1624 * A DigitMap is deleted by supplying an empty value for a name that 1625 is already defined. Terminations presently using the digitmap shall 1626 continue to use the old definition. 1628 The collection of digits according to a DigitMap may be protected by 1629 three timers, viz. a start timer (T), short timer (S), and long timer 1630 (L). 1632 1. The start timer (T) is used prior to any digits having been dialed. 1634 2. If the Media Gateway can determine that at least one more digit is 1635 needed for a digit string to match any of the allowed patterns in 1636 the digit map, then the interdigit timer value should be set to a 1637 long (L) duration (e.g. 16 seconds). 1639 3. If the digit string has matched one of the patterns in a digit map, 1640 but it is possible that more digits could be received which would 1641 cause a match with a different pattern, then instead of reporting 1642 the match immediately, the MG must apply the short timer (S) and 1643 wait for more digits. 1645 The timers are configurable parameters to a DigitMap. The Start timer 1646 is started at the beginning of every digit map use, but can be overrid- 1647 den. 1649 The formal syntax of the digit map is described by the DigitMap rule in 1650 the formal syntax description of the protocol (see Annex A and Annex B). 1651 A DigitMap, according to this syntax, is defined either by a string or 1652 by a list of strings. Each string in the list is an alternative event 1653 sequence, specified either as a sequence of digit map symbols or as a 1654 regular expression of digit map symbols. These digit map symbols, the 1655 digits "0" through "9" and letters "A" through a maximum value depending 1656 on the signalling system concerned, but never exceeding "K", correspond 1658 Internet draft MEGACO Protocol February 21, 2000 1660 to specified events within a package which has been designated in the 1661 Events Descriptor on the termination to which the digit map is being 1662 applied. (The mapping between events and digit map symbols is defined 1663 in the documentation for packages associated with channel-associated 1664 signalling systems such as DTMF, MF, or R2. Digits "0" through "9" MUST 1665 be mapped to the corresponding digit events within the signalling system 1666 concerned. Letters should be allocated in logical fashion, facilitating 1667 the use of range notation for alternative events.) 1669 The letter "x" is used as a wildcard, designating any event correspond- 1670 ing to symbols in the range "0"-"9". The string may also contain expli- 1671 cit ranges and, more generally, explicit sets of symbols, designating 1672 alternative events any one of which satisfies that position of the digit 1673 map. Finally, the dot symbol "." stands for zero or more repetitions of 1674 the event selector (event, range of events, set of alternative events, 1675 or wildcard) that precedes it. As a consequence of the third timing 1676 rule above, inter-event timing while matching the dot symbol uses the 1677 short timer by default. 1679 In addition to these event symbols, the string may contain "S" and "L" 1680 inter-event timing specifiers and the "Z" duration modifier. "S" and 1681 "L" respectively indicate that the MG should use the short (S) timer or 1682 the long (L) timer for subsequent events, over-riding the timing rules 1683 described above. A timer specifier following a dot specifies inter-event 1684 timing for all events matching the dot as well as for subsequent events. 1685 If an explicit timing specifier is in effect in one alternative event 1686 sequence, but none is given in any other candidate alternative, the 1687 timer value set by the explicit timing specifier must be used. If all 1688 sequences with explicit timing controls are dropped from the candidate 1689 set, timing reverts to the default rules given above. Finally, if con- 1690 flicting timing specifiers are in effect in different alternative 1691 sequences, the results are undefined. 1693 A "Z" designates a long duration event: placed in front of the symbol(s) 1694 designating the event(s) which satisfy a given digit position, it indi- 1695 cates that that position is satisfied only if the duration of the event 1696 exceeds the long-duration threshold. The value of this threshold is 1697 assumed to be provisioned in the MG. A digit map is active while the 1698 events descriptor which invoked it is active and it has not completed. 1699 A digit map completes when: 1701 * a timer has expired, or 1703 * an alternative event sequence has been matched and no other alter- 1704 native event sequence in the digit map could be matched through 1705 detection of an additional event (unambiguous match), or 1707 * an event has been detected such that a match to a complete 1709 Internet draft MEGACO Protocol February 21, 2000 1711 alternative event sequence of the digit map will be impossible no 1712 matter what additional events are received. 1714 Upon completion, a digit map completion event as defined in the package 1715 providing the events being mapped into the digit map shall be generated. 1716 At that point the digit map is deactivated. Subsequent events in the 1717 package are processed as per the currently active event processing 1718 mechanisms. 1720 Pending completion, successive events shall be processed according to 1721 the following rules: 1723 1. The "current dial string", an internal variable, is initially 1724 empty. The set of candidate alternative event sequences includes 1725 all of the alternatives specified in the digit map. 1727 2. At each step, a timer is set to wait for the next event, based 1728 either on the default timing rules given above or on explicit tim- 1729 ing specified in one or more alternative event sequences. If the 1730 timer expires and a member of the candidate set of alternatives is 1731 fully satisfied, a timeout completion with full match is reported. 1732 If the timer expires and part or none of any candidate alternative 1733 is satisfied, a timeout completion with partial match is reported. 1735 3. If an event is detected before the timer expires, it is mapped to a 1736 digit string symbol and provisionally added to the end of the 1737 current dial string. The duration of the event (long or not long) 1738 is noted if and only if this is relevant in the current symbol 1739 position (because at least one of the candidate alternative event 1740 sequences includes the "Z" modifier at this position in the 1741 sequence). 1743 4. The current dial string is compared to the candidate alternative 1744 event sequences. If and only if a sequence expecting a long- 1745 duration event at this position is matched (i.e. the event had long 1746 duration and met the specification for this position), then any 1747 alternative event sequences not specifying a long duration event at 1748 this position are discarded, and the current dial string is modi- 1749 fied by inserting a "Z" in front of the symbol representing the 1750 latest event. Any sequence expecting a long-duration event at this 1751 position but not matching the observed event is discarded from the 1752 candidate set. If alternative event sequences not specifying a 1753 long duration event in the given position remain in the candidate 1754 set after application of the above rules, the observed event dura- 1755 tion is treated as irrelevant in assessing matches to them. If 1756 exactly one candidate remains, a completion event is generated 1757 indicating an unambiguous match. If no candidates remain, the 1758 latest event is removed from the current dial string and a 1760 Internet draft MEGACO Protocol February 21, 2000 1762 completion event is generated indicating full match if one of the 1763 candidates from the previous step was fully satisfied before the 1764 latest event was detected, or partial match otherwise. The event 1765 removed from the current dial string will then be reported as per 1766 the currently active event processing mechanisms. 1768 5. If no completion event is reported out of step 5 (because the can- 1769 didate set still contains more than one alternative event 1770 sequence), processing returns to step 2. A digit map is activated 1771 whenever a new event descriptor is applied to the termination or 1772 embedded event descriptor is activated, and that event descriptor 1773 contains a digit map completion event which itself contains a digit 1774 map parameter. Each new activation of a digit map begins at step 1 1775 of the above procedure, with a clear current dial string. Any pre- 1776 vious contents of the current dial string from an earlier activa- 1777 tion are lost. While the digit map is activated, detection is 1778 enabled for all events defined in the package containing the speci- 1779 fied digit map completion event. Normal event behaviour (e.g. 1780 stopping of signals unless the digit completion event has the 1781 KeepActive flag enabled) continues to apply for each such event 1782 detected, except that the events in the package containing the 1783 specified digit map completion event other than the completion 1784 event itself are not individually notified. Note that if a package 1785 contains a digit map completion event, then an event specification 1786 consisting of the package name with a wildcarded ItemID (Property 1787 Name) will activate a digit map if the event includes a digit map 1788 parameter. Regardless of whether a digit map is activated, this 1789 form of event specification will cause the individual events to be 1790 reported to the MGC as they are detected. 1792 As an example, consider the following dial plan: 1794 _____________________________________________________________________ 1795 | 0 | Local operator | 1796 | 00 | Long distance operator | 1797 | xxxx | Local extension number(starts with 1-7)| 1798 | 8xxxxxxx | Local number | 1799 | #xxxxxxx | Off-site extension | 1800 | *xx | Star services | 1801 | 91xxxxxxxxxx | Long distance number | 1802 | 9011 + up to 15 digits | International number | 1803 |__________________________|_________________________________________| 1805 If the DTMF detection package described in Annex E (section E.6) is used 1806 to collect the dialled digits, then the dialling plan shown above 1807 results in the following digit map: 1809 Internet draft MEGACO Protocol February 21, 2000 1811 (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.) 1813 7.1.15. Statistics Descriptor 1815 The Statistics parameter provides information describing the status and 1816 usage of a Termination during its existence within a specific Context. 1817 There is a set of standard statistics kept for each termination where 1818 appropriate (number of octets sent and received for example). The par- 1819 ticular statistical properties that are reported for a given Termination 1820 are determined by the Packages realized by the Termination. By default, 1821 statistics are reported when the Termination is Subtracted from the Con- 1822 text. This behavior can be overridden by including an empty Audit- 1823 Descriptor in the Subtract command. Statistics may also be returned 1824 from the AuditValue command, or any Add/Move/Modify command using the 1825 Audit descriptor. 1827 Statistics are cumulative; reporting Statistics does not reset them. 1828 Statistics are reset when a Termination is Subtracted from a Context. 1830 7.1.16. Packages Descriptor 1832 Used only with the AuditValue command, the PackageDescriptor returns a 1833 list of Packages realized by the Termination. 1835 7.1.17. ObservedEvents Descriptor 1837 ObservedEvents is supplied with the Notify command to inform the MGC of 1838 which event(s) were detected. Used with the AuditValue command, the 1839 ObservedEventsDescriptor returns events in the event buffer which have 1840 not been Notified. ObservedEvents contains the RequestIdentifier of the 1841 EventsDescriptor that triggered the notification, the event(s) detected 1842 and the detection time(s). Detection times are reported with a precision 1843 of hundredths of a second. Time is expressed in UTC. 1845 7.1.18. Topology Descriptor 1847 A topology descriptor is used to specify flow directions between termi- 1848 nations in a Context. Contrary to the descriptors in previous sections, 1849 the topology descriptor applies to a Context instead of a Termination. 1850 The default topology of a Context is that each termination's transmis- 1851 sion is received by all other terminations. The Topology Descriptor is 1852 optional to implement. 1854 The Topology Descriptor occurs before the commands in an action. It is 1855 possible to have an action containing only a Topology Descriptor, pro- 1856 vided that the context to which the action applies already exists. 1858 A topology descriptor consists of a sequence of triples of the form (T1, 1860 Internet draft MEGACO Protocol February 21, 2000 1862 T2, association). T1 and T2 specify Terminations within the Context, 1863 possibly using the ALL or CHOOSE wildcard. The association specifies 1864 how media flows between these two Terminations as follows. 1866 * (T1, T2, isolate) means that the Terminations matching T2 do not 1867 receive media from the Terminations matching T1, nor vice versa. 1869 * (T1, T2, oneway) means that the Terminations that match T2 receive 1870 media from the Terminations matching T1, but not vice versa. In 1871 this case use of the ALL wildcard such that there are Terminations 1872 that match both T1 and T2 is not allowed. 1874 * (T1, T2, bothway) means that the Terminations matching T2 receive 1875 media from the Terminations matching T1, and vice versa. In this 1876 case it is allowed to use wildcards such that there are Termina- 1877 tions that match both T1 and T2. However, if there is a Termina- 1878 tion that matches both, no loopback is introduced; loopbacks are 1879 created by setting the TerminationMode. 1881 CHOOSE wildcards may be used in T1 and T2 as well, under the following 1882 restrictions: 1884 * the action (see section 8) of which the topology descriptor is part 1885 contains an Add command in which a CHOOSE wildcard is used; 1887 * if a CHOOSE wildcard occurs in T1 or T2, then a partial name SHALL 1888 NOT be specified. The CHOOSE wildcard in a topology descriptor 1889 matches the TerminationID that the MG assigns in the first Add com- 1890 mand that uses a CHOOSE wildcard in the same action. An existing 1891 Termination that matches T1 or T2 in the Context to which a Termi- 1892 nation is added, is connected to the newly added Termination as 1893 specified by the topology descriptor. The default association when 1894 a termination is not mentioned in the Topology descriptor is both- 1895 way (if T3 is added to a context with T1 and T2 with topology 1896 (T3,T1,oneway) it will be connected bothway to T2). 1898 The figure below and the table following it show some examples of the 1899 effect of including topology descriptors in actions. In these examples 1900 it is assumed that the topology descriptors are applied in sequence. 1902 Internet draft MEGACO Protocol February 21, 2000 1904 Context 1 Context 2 Context 3 1905 +------------------+ +------------------+ +------------------+ 1906 | +----+ | | +----+ | | +----+ | 1907 | | T2 | | | | T2 | | | | T2 | | 1908 | +----+ | | +----+ | | +----+ | 1909 | ^ ^ | | ^ | | ^ | 1910 | | | | | | | | | | 1911 | +--+ +--+ | | +---+ | | +--+ | 1912 | | | | | | | | | | 1913 | v v | | v | | | | 1914 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1915 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | 1916 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1917 +------------------+ +------------------+ +------------------+ 1918 1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway 1919 Context 1 Context 2 Context 3 1921 +------------------+ +------------------+ +------------------+ 1922 | +----+ | | +----+ | | +----+ | 1923 | | T2 | | | | T2 | | | | T2 | | 1924 | +----+ | | +----+ | | +----+ | 1925 | | | | ^ | | ^ ^ | 1926 | | | | | | | | | | 1927 | +--+ | | +---+ | | +--+ +--+ | 1928 | | | | | | | | | | 1929 | v | | v | | v v | 1930 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1931 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | 1932 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1933 +------------------+ +------------------+ +------------------+ 1934 1. T2, T3 oneway 2. T2, T3 bothway 3. T1, T2 bothway 1936 Figure 4: Example topologies 1938 Internet draft MEGACO Protocol February 21, 2000 1940 _______________________________________________________________________ 1941 |Topology | Description | 1942 |_________|____________________________________________________________| 1943 |1 |No topology descriptors. When no topology descriptors are | 1944 | |included, all terminations have a both way connection to all| 1945 | |other terminations. | 1946 |_________|____________________________________________________________| 1947 |2 |T1, T2, Isolate. Removes the connection between T1 and T2. | 1948 | |T3 has a both way connection with both T1 and T2. | 1949 |_________|____________________________________________________________| 1950 |3 |T3, T2, oneway. A oneway connection from T3 to T2 (i.e. T2 | 1951 | |receives media flow from T3). A bothway connection between | 1952 | |T1 and T3. | 1953 |_________|____________________________________________________________| 1954 |4 |T2, T3, oneway. A oneway connection between T2 to T3. | 1955 | |T1 and T3 remain bothway connected | 1956 |_________|____________________________________________________________| 1957 |5 |T2, T3 bothway. T2 is bothway connected to T3. | 1958 | |This results in the same as 2. | 1959 |_________|____________________________________________________________| 1960 |6 |T1, T2 bothway. (T2, T3 bothway and T1,T3 bothway may be | 1961 | |implied or explicit). terminations have a bothway | 1962 |_________|____________________________________________________________| 1964 A oneway connection must implemented in such a way that the other Termi- 1965 nations in the Context are not aware of the change in topology. 1967 7.2. Command Application Programming Interface 1969 Following is an Application Programming Interface (API) describing the 1970 Commands of the protocol. This API is shown to illustrate the Commands 1971 and their parameters and is not intended to specify implementation (e.g. 1972 via use of blocking function calls). It describes the input parameters 1973 in parentheses after the command name and the return values in front of 1974 the Command. This is only for descriptive purposes; the actual Command 1975 syntax and encoding are specified in later subsections. All parameters 1976 enclosed by square brackets ([. . . ]) are considered optional. 1978 7.2.1. Add 1980 TerminationID 1981 [,MediaDescriptor] 1982 [,ModemDescriptor] 1983 [,MuxDescriptor] 1984 [,EventsDescriptor] 1985 [,SignalsDescriptor] 1987 Internet draft MEGACO Protocol February 21, 2000 1989 [,DigitMapDescriptor] 1990 [,ObservedEventsDescriptor] 1991 [,EventBufferDescriptor] 1992 [,StatisticsDescriptor] 1993 [,PackagesDescriptor] 1994 Add( TerminationID 1995 [, MediaDescriptor] 1996 [, ModemDescriptor] 1997 [, MuxDescriptor] 1998 [, EventsDescriptor] 1999 [, SignalsDescriptor] 2000 [, DigitMapDescriptor] 2001 [, AuditDescriptor] 2002 ) 2004 The TerminationID specifies the termination to be added to the Context. 2005 The Termination is either created, or taken from the null Context. For 2006 an existing Termination, the TerminationID would be specific. For a 2007 Termination that does not yet exist, the TerminationID is specified as 2008 CHOOSE in the command. The new TerminationID will be returned. Wild- 2009 cards may be used in an Add, but such usage would be unusual. If the 2010 wildcard matches more than one TerminationID, all possible matches are 2011 attempted, with results reported for each one. The order of attempts 2012 when multiple TerminationIDs match is not specified. 2014 The optional MediaDescriptor describes all media streams. 2016 The optional ModemDescriptor and MuxDescriptor specify a modem and mul- 2017 tiplexer if applicable. For convenience, if a Multiplex Descriptor is 2018 present in an Add command and lists any Terminations that are not 2019 currently in the Context, such Terminations are added to the context as 2020 if individual Add commands listing the Terminations were invoked. If an 2021 error occurs on such an implied Add, error 471 - Implied Add for Multi- 2022 plex failure shall be returned and further processing of the command 2023 shall cease. 2025 The EventsDescriptor parameter is optional. If present, it provides the 2026 list of events that should be detected on the Termination. 2028 The SignalsDescriptor parameter is optional. If present, it provides 2029 the list of signals that should be applied to the Termination. 2031 The DigitMapDescriptor parameter is optional. If present, defines a 2032 DigitMap definition that may be used in an EventsDescriptor. 2034 The AuditDescriptor is optional. If present, the command will return 2035 descriptors as specified in the AuditDescriptor. 2037 Internet draft MEGACO Protocol February 21, 2000 2039 All descriptors that can be modified could be returned by MG if a param- 2040 eter was underspecified or overspecified. ObservedEvents, Statistics, 2041 and Packages, and the EventBuffer Descriptors are returned only if 2042 requested in the AuditDescriptor. Add SHALL NOT be used on a Termina- 2043 tion with a serviceState of "OutofService". 2045 7.2.2. Modify 2047 TerminationID 2048 [,MediaDescriptor] 2049 [,ModemDescriptor] 2050 [,MuxDescriptor] 2051 [,EventsDescriptor] 2052 [,SignalsDescriptor] 2053 [,DigitMapDescriptor] 2054 [,ObservedEventsDescriptor] 2055 [,EventBufferDescriptor] 2056 [,StatisticsDescriptor] 2057 [,PackagesDescriptor] 2058 Modify( TerminationID 2059 [, MediaDescriptor] 2060 [, ModemDescriptor] 2061 [, MuxDescriptor] 2062 [, EventsDescriptor] 2063 [, SignalsDescriptor] 2064 [, DigitMapDescriptor] 2065 [, AuditDescriptor] 2066 ) 2068 The TerminationID may be specific if a single Termination in the Context 2069 is to be modified. Use of wildcards in the TerminationID may be 2070 appropriate for some operations. If the wildcard matches more than one 2071 TerminationID, all possible matches are attempted, with results reported 2072 for each one. The order of attempts when multiple TerminationIDs match 2073 is not specified. The CHOOSE option is an error, as the Modify command 2074 may only be used on existing Terminations. 2076 The remaining parameters to Modify are the same as those to Add. Possi- 2077 ble return values are the same as those to Add. 2079 7.2.3. Subtract 2081 The Subtract Command disconnects a Termination from its Context and 2082 returns statistics on the Termination's participation in the Context. 2084 TerminationID 2086 Internet draft MEGACO Protocol February 21, 2000 2088 [,MediaDescriptor] 2089 [,ModemDescriptor] 2090 [,MuxDescriptor] 2091 [,EventsDescriptor] 2092 [,SignalsDescriptor] 2093 [,DigitMapDescriptor] 2094 [,ObservedEventsDescriptor] 2095 [,EventBufferDescriptor] 2096 [,StatisticsDescriptor] 2097 [,PackagesDescriptor] 2098 Subtract(TerminationID 2099 [, AuditDescriptor] 2100 ) 2102 TerminationID in the input parameters represents the Termination that is 2103 being subtracted. The TerminationID may be specific or may be a wild- 2104 card value indicating that all (or a set of related) Terminations in the 2105 Context of the Subtract Command are to be subtracted. If the wildcard 2106 matches more than one TerminationID, all possible matches are attempted, 2107 with results reported for each one. The order of attempts when multiple 2108 TerminationIDs match is not specified. The CHOOSE option is an error, as 2109 the Subtract command may only be used on existing Terminations. ALL may 2110 be used as the ContextID as well as the TerminationId in a Subtract, 2111 which would have the effect of deleting all contexts, deleting all 2112 ephemeral terminations, and returning all physical terminations to Null 2113 context. 2115 By default, the Statistics parameter is returned to report information 2116 collected on the Termination or Terminations specified in the Command. 2117 The information reported applies to the Termination's or Terminations' 2118 existence in the Context from which it or they are being subtracted. 2120 The AuditDescriptor is optional. If present, the command will return 2121 descriptors as specified in the AuditDescriptor. Possible return 2122 values are the same as those to Add. 2124 When a provisioned Termination is Subtracted from a context, its pro- 2125 perty values shall revert to: 2127 * the default value, if specified for the property and not overridden 2128 by provisioning, 2130 * otherwise, the provisioned value. 2132 7.2.4. Move 2134 The Move Command moves a Termination to another Context from its current 2136 Internet draft MEGACO Protocol February 21, 2000 2138 Context in one atomic operation. The Move command is the only command 2139 that refers to a Termination in a Context different from that to which 2140 the command is applied. The Move command shall not be used to move Ter- 2141 minations to or from the null Context. 2143 TerminationID 2144 [,MediaDescriptor] 2145 [,ModemDescriptor] 2146 [,MuxDescriptor] 2147 [,EventsDescriptor] 2148 [,SignalsDescriptor] 2149 [,DigitMapDescriptor] 2150 [,ObservedEventsDescriptor] 2151 [,EventBufferDescriptor] 2152 [,StatisticsDescriptor] 2153 [,PackagesDescriptor] 2154 Move( TerminationID 2155 [, MediaDescriptor] 2156 [, ModemDescriptor] 2157 [, MuxDescriptor] 2158 [, EventsDescriptor] 2159 [, SignalsDescriptor] 2160 [, DigitMapDescriptor] 2161 [, AuditDescriptor] 2162 ) 2164 The TerminationID specifies the Termination to be moved. It may be 2165 wildcarded. If the wildcard matches more than one TerminationID, all 2166 possible matches are attempted, with results reported for each one. The 2167 order of attempts when multiple TerminationIDs match is not specified. 2168 By convention, the Termination is subtracted from its previous Context. 2169 The Context to which the Termination is moved is indicated by the target 2170 ContextId in the Action. If the last remaining Termination is moved out 2171 of a Context, the Context is deleted. 2173 The remaining descriptors are processed as in the Modify Command. The 2174 AuditDescriptor with the Statistics option, for example, would return 2175 statistics on the Termination just prior to the Move. Possible descrip- 2176 tors returned from Move are the same as for Add. Move SHALL NOT be used 2177 on a Termination with a serviceState of "OutofService". 2179 7.2.5. AuditValue 2181 The AuditValue Command returns the current values of properties, events, 2182 signals and statistics associated with Terminations. 2184 Internet draft MEGACO Protocol February 21, 2000 2186 TerminationID 2187 [,MediaDescriptor] 2188 [,ModemDescriptor] 2189 [,MuxDescriptor] 2190 [,EventsDescriptor] 2191 [,SignalsDescriptor] 2192 [,DigitMapDescriptor] 2193 [,ObservedEventsDescriptor] 2194 [,EventBufferDescriptor] 2195 [,StatisticsDescriptor] 2196 [,PackagesDescriptor] 2197 AuditValue(TerminationID, 2198 AuditDescriptor 2199 ) 2201 TerminationID may be specific or wildcarded. If the wildcard matches 2202 more than one TerminationID, all possible matches are attempted, with 2203 results reported for each one. The order of attempts when multiple Ter- 2204 minationIDs match is not specified. If a wildcarded response is 2205 requested, only one command return is generated, with the contents con- 2206 taining the union of the values of all Terminations matching the wild- 2207 card. This convention may reduce the volume of data required to audit a 2208 group of Terminations. Use of CHOOSE is an error. 2210 The appropriate descriptors, with the current values for the Termina- 2211 tion, are returned from AuditValue. Values appearing in multiple 2212 instances of a descriptor are defined to be alternate values supported, 2213 with each parameter in a descriptor considered independent. 2215 ObservedEvents returns a list of events in the EventBuffer, Packages- 2216 Descriptor returns a list of packages realized by the Termination. 2217 DigitMapDescriptor returns the name or value of the current DigitMap for 2218 the Termination. DigitMap requested in an AuditValue command with Ter- 2219 minationID ALL returns all DigitMaps in the gateway. Statistics returns 2220 the current values of all statistics being kept on the Termination. 2221 Specifying an empty Audit Descriptor results in only the TerminationID 2222 being returned. This may be useful to get a list of TerminationIDs when 2223 used with wildcard. 2225 AuditValue results depend on the Context, viz. specific, null, or wild- 2226 carded. The TerminationID may be specific, or wildcarded. 2228 The following illustrates other information that can be obtained with 2229 the Audit Command: 2231 ________________________________________________________________________ 2232 |ContextID |TerminationID| Information Obtained | 2234 Internet draft MEGACO Protocol February 21, 2000 2236 |Specific | wildcard |Audit of matching Terminations in a Context| 2237 |Specific | specific |Audit of a single Termination in a Context | 2238 |Null | Root |Audit of Media Gateway state and events | 2239 |Null | wildcard |Audit of all matching Terminations in the | 2240 | | | Null context | 2241 |Null | specific |Audit of a single Termination outside of | 2242 | | |any Context | 2243 |All | wildcard |Audit of all matching Terminations and the | 2244 | | |Context to which they are associated | 2245 |All | Root | List of all ContextIds | 2246 |____________|_____________|___________________________________________| 2248 7.2.6. AuditCapabilities 2250 The AuditCapabilities Command returns the possible values of properties, 2251 events, signals and statistics associated with Terminations. 2253 TerminationID 2254 [,MediaDescriptor] 2255 [,ModemDescriptor] 2256 [,MuxDescriptor] 2257 [,EventsDescriptor] 2258 [,SignalsDescriptor] 2259 [,ObservedEventsDescriptor] 2260 [,EventBufferDescriptor] 2261 [,StatisticsDescriptor] 2262 AuditCapabilities(TerminationID, 2263 AuditDescriptor) 2265 The appropriate descriptors, with the possible values for the Termina- 2266 tion are returned from AuditCapabilities. Descriptors may be repeated 2267 where there are multiple possible values. values. If a wildcarded 2268 response is requested, only one command return is generated, with the 2269 contents containing the union of the values of all Terminations matching 2270 the wildcard. This convention may reduce the volume of data required to 2271 audit a group of Terminations. 2273 Interpretation of what capabilities are requested for various values of 2274 ContextID and TerminationID is the same as in AuditValue. 2276 The EventsDescriptor returns the list of possible events on the Termina- 2277 tion together with the list of all possible values for the 2278 EventsDescriptor Parameters. The SignalsDescriptor returns the list of 2279 possible signals that could be applied to the Termination together with 2280 the list of all possible values for the Signals Parameters. Statis- 2281 ticsDescriptor returns the names of the statistics being kept on the 2283 Internet draft MEGACO Protocol February 21, 2000 2285 termination. ObservedEventsDescriptor returns the names of active 2286 events on the termination. DigitMap and Packages are not legal in 2287 AuditCapability 2289 7.2.7. Notify 2291 The Notify Command allows the Media Gateway to notify the Media Gateway 2292 Controller of events occurring within the Media Gateway. 2294 Notify(TerminationID, 2295 ObservedEventsDescriptor, 2296 [ErrorDescriptor]) 2298 The TerminationID parameter specifies the Termination issuing the Notify 2299 Command. The TerminationID shall be a fully qualified name. 2301 The ObservedEventsDescriptor contains the RequestID and a list of events 2302 that the Media Gateway detected in the order that they were detected. 2303 Each event in the list is accompanied by parameters associated with the 2304 event and an indication of the time that the event was detected. Pro- 2305 cedures for sending Notify commands with RequestID equal to 0 are for 2306 further study. 2308 Notify Commands with RequestID not equal to 0 shall occur only as the 2309 result of detection of an event specified by an Events Descriptor which 2310 is active on the termination concerned. The RequestID returns the 2311 RequestID parameter of the EventsDescriptor that triggered the Notify 2312 Command. It is used to correlate the notification with the request that 2313 triggered it. The events in the list must have been requested via the 2314 triggering EventsDescriptor or embedded events descriptor unless the 2315 RequestID is 0 (which is for further study). 2317 7.2.8. ServiceChange 2319 The ServiceChange Command allows the Media Gateway to notify the Media 2320 Gateway Controller that a Termination or group of Terminations is about 2321 to be taken out of service or has just been returned to service. The 2322 Media Gateway Controller may indicate that Termination(s) shall be taken 2323 out of or returned to service. The Media Gateway may notify the MGC 2324 that the capability of a Termination has changed. It also allows a MGC 2325 to hand over control of a MG to another MGC. 2327 TerminationID, 2328 [ServiceChangeDescriptor] 2329 ServiceChange(TerminationID, 2330 ServiceChangeDescriptor 2331 ) 2333 Internet draft MEGACO Protocol February 21, 2000 2335 The TerminationID parameter specifies the Termination(s) that are taken 2336 out of or returned to service. Wildcarding of Termination names is per- 2337 mitted, with the exception that the CHOOSE mechanism shall not be used. 2338 Use of the "Root" TerminationID indicates a ServiceChange affecting the 2339 entire Media Gateway. 2341 The ServiceChangeDescriptor contains the following parameters as 2342 required: 2344 * ServiceChangeMethod 2346 * ServiceChangeReason 2348 * ServiceChangeDelay 2350 * ServiceChangeAddress 2352 * ServiceChangeProfile 2354 * ServiceChangeVersion 2356 * ServiceChangeMgcId 2358 * TimeStamp 2360 The ServiceChangeMethod parameter specifies the type of ServiceChange 2361 that will or has occurred: 2363 1) Graceful - indicates that the specified Terminations will be taken 2364 out of service after the specified ServiceChangeDelay; established 2365 connections are not yet affected, but the Media Gateway Controller 2366 should refrain from establishing new connections and should attempt 2367 to gracefully tear down existing connections. The MG should set 2368 termination serviceState at the expiry of ServiceChangeDelay or the 2369 removal of the termination from an active context (whichever is 2370 first), to "out of service". 2372 2) Forced - indicates that the specified Terminations were taken 2373 abruptly out of service and any established connections associated 2374 with them were lost. The MGC is responsible for cleaning up the 2375 context (if any) with which the failed termination is associated. 2376 At a minimum the termination shall be subtracted from the context. 2377 The termination serviceState should be "out of service". 2379 3) Restart - indicates that service will be restored on the specified 2380 Terminations after expiration of the ServiceChangeDelay. The ser- 2381 viceState should be set to "inService" upon expiry of Servi- 2382 ceChangeDelay. 2384 Internet draft MEGACO Protocol February 21, 2000 2386 4) Disconnected - always applied with the Root TerminationID, indi- 2387 cates that the MG lost communication with the MGC, but it was sub- 2388 sequently restored. Since MG state may have changed, the MGC may 2389 wish to use the Audit command to resynchronize its state with the 2390 MG's. 2392 5) Handoff - sent from the MGC to the MG, this reason indicates that 2393 the MGC is going out of service and a new MGC association must be 2394 established. Sent from the MG to the MGC, this indicates that the 2395 MG is attempting to establish a new association in accordance with 2396 a Handoff received from the MGC with which it was previously asso- 2397 ciated. 2399 6) Failover - sent from MG to MGC to indicate the primary MG is out of 2400 service and a secondary MG is taking over. 2402 7) Another value whose meaning is mutually understood between the MG 2403 and the MGC. The ServiceChangeReason parameter specifies the rea- 2404 son why the ServiceChange has or will occur. It consists of an 2405 alphanumeric token (IANA registered) and an explanatory string. 2407 The optional ServiceChangeAddress parameter specifies the address (e.g., 2408 IP port number for IP networks) to be used for subsequent communica- 2409 tions. It can be specified in the input parameter descriptor or the 2410 returned result descriptor. ServiceChangeAddress and ServiceChangeMgcId 2411 parameters must not both be present in the ServiceChangeDescriptor or 2412 the ServiceChangeResultDescriptor. The serviceChangeAddress provides an 2413 address to be used within the context of the association currently being 2414 negotiated, while the ServiceChangeMgcId provides an alternate address 2415 where the MG should seek to establish another association. 2417 The optional ServiceChangeDelay parameter is expressed in seconds. If 2418 the delay is absent or set to zero, the delay value should be considered 2419 to be null. In the case of a "graceful" ServiceChangeMethod, a null 2420 delay indicates that the Media Gateway Controller should wait for the 2421 natural removal of existing connections and should not establish new 2422 connections. . For "graceful" only, a null delay means the MG must not 2423 set serviceState "out of service" until the termination is in the null 2424 context. 2426 The optional ServiceChangeProfile parameter specifies the Profile (if 2427 any) of the protocol supported. The ServiceChangeProfile includes the 2428 version of the profile supported. 2430 The optional ServiceChangeVersion parameter contains the protocol ver- 2431 sion and is used if protocol version negotiation occurs (see section 2432 11.3). 2434 Internet draft MEGACO Protocol February 21, 2000 2436 The optional TimeStamp parameter specifies the actual time as kept by 2437 the sender. It can be used by the responder to determine how its notion 2438 of time differs from that of its correspondent. TimeStamp is sent with a 2439 precision of hundredths of a second, and is expressed in UTC. 2441 The optional Extension parameter may contain any value whose meaning is 2442 mutually understood by the MG and MGC. 2444 A ServiceChange Command specifying the "Root" for the TerminationID and 2445 ServiceChangeMethod equal to Restart is a registration command by which 2446 a Media Gateway announces its existence to the Media Gateway Controller. 2447 The Media Gateway is expected to be provisioned with the name of one 2448 primary and optionally some number of alternate Media Gateway Controll- 2449 ers. Acknowledgement of the ServiceChange Command completes the 2450 registration process. The MG may specify the transport ServiceChangeAd- 2451 dress to be used by the MGC for sending messages in the ServiceChangeAd- 2452 dress parameter in the input ServiceChangeDescriptor. The MG may specify 2453 an address in the ServiceChangeAddress parameter of the ServiceChange 2454 request, and the MGC may also do so in the ServiceChange reply. In 2455 either case, the recipient must use the supplied address as the destina- 2456 tion for all subsequent transaction requests within the association. At 2457 the same time, as indicated in section 9, transaction replies and pend- 2458 ing indications must be sent to the address from which the corresponding 2459 rquests originated. This must be done even if it implies extra messag- 2460 ing because commands and responses cannot be packed together. The 2461 TimeStamp parameter shall be sent with a registration command and its 2462 response. 2464 The Media Gateway Controller may return an ServiceChangeMgcId parameter 2465 that describes the Media Gateway Controller that should preferably be 2466 contacted for further service by the Media Gateway. In this case the 2467 Media Gateway shall reissue the ServiceChange command to the new Media 2468 Gateway Controller. The Gateway specified in an ServiceChangeMgcId, if 2469 provided, shall be contacted before any further alternate MGCs. On a 2470 HandOff message from MGC to MG, the ServiceChangeMgcId is the new MGC 2471 that will take over from the current MGC. 2473 The return from ServiceChange is empty except when the Root termina- 2474 tionID is used. In that case it includes the following parameters as 2475 required: 2477 * ServiceChangeAddress, if the responding MGC wishes to specify an 2478 new destination for messages from the MG for the remainder of the 2479 association; 2481 * ServiceChangeMgcId, if the responding MGC does not wish to sustain 2482 an association with the MG; 2484 Internet draft MEGACO Protocol February 21, 2000 2486 * ServiceChangeProfile, if the responder wishes to negotiate the pro- 2487 file to be used for the association; 2489 * ServiceChangeVersion, if the responder wishes to negotiate the ver- 2490 sion of the protocol to be used for the association. 2492 The following ServiceChangeReasons are defined. This list may be 2493 extended by an IANA registration as outlined in section 13.3 2495 900 Service Restored 2496 901 Cold Boot 2497 902 Warm Boot 2498 903 MGC Directed Change 2499 904 Termination malfunctioning 2500 905 Termination taken out of service 2501 906 Loss of lower layer connectivity (e.g. downstream 2502 sync) 2503 907 Transmission Failure 2504 908 MG Impending Failure 2505 909 MGC Impending Failure 2506 910 Media Capability Failure 2507 911 Modem Capability Failure 2508 912 Mux Capability Failure 2509 913 Signal Capability Failure 2510 914 Event Capability Failure 2511 915 State Loss 2513 7.2.9. Manipulating and Auditing Context Attributes 2515 The commands of the protocol as discussed in the preceding sections 2516 apply to terminations. This section specifies how contexts are manipu- 2517 lated and audited. 2519 Commands are grouped into actions (see section 8). An action applies to 2520 one context. In addition to commands, an action may contain context 2521 manipulation and auditing instructions. 2523 An action request sent to a MG may include a request to audit attributes 2524 of a context. An action may also include a request to change the attri- 2525 butes of a context. 2527 The context properties that may be included in an action reply are used 2528 to return information to a MGC. This can be information requested by an 2529 audit of context attributes or details of the effect of manipulation of 2530 a context. 2532 Internet draft MEGACO Protocol February 21, 2000 2534 If a MG receives an action which contains both a request to audit con- 2535 text attributes and a request to manipulate those attributes, the 2536 response SHALL include the values of the attributes after processing the 2537 manipulation request. 2539 7.2.10. Generic Command Syntax 2541 The protocol can be encoded in a binary format or in a text format. 2542 MGCs should support both encoding formats. MGs may support both for- 2543 mats. 2545 The protocol syntax for the binary format of the protocol is defined in 2546 Annex A. Annex C specifies the encoding of the Local and Remote 2547 descriptors for use with the binary format. 2549 A complete ABNF of the text encoding of the protocol per RFC2234 is 2550 given in Annex B. SDP is used as the encoding of the Local and Remote 2551 Descriptors for use with the text encoding as modified in section 7.1.8. 2553 7.3. Command Error Codes 2555 Errors consist of an IANA registered error code and an explanatory 2556 string. Sending the explanatory string is optional. Implementations 2557 are encouraged to append diagnostic information to the end of the 2558 string. 2560 When a MG reports an error to a MGC, it does so in an error descriptor. 2561 An error descriptor consists of an error code and optionally the associ- 2562 ated explanatory string. 2564 The identified error codes are: 2566 400 - Bad Request 2567 401 - Protocol Error 2568 402 - Unauthorized 2569 403 - Syntax Error in Transaction 2570 404 - Syntax Error in TransactionReply 2571 405 - Syntax Error in TransactionPending 2572 406 - Version Not Supported 2573 410 - Incorrect identifier 2574 411 - The transaction refers to an unknown ContextId 2575 412 - No ContextIDs available 2577 421 - Unknown action or illegal combination of actions 2578 422 - Syntax Error in Action 2579 430 - Unknown TerminationID 2580 431 - No TerminationID matched a wildcard 2582 Internet draft MEGACO Protocol February 21, 2000 2584 432 - Out of TerminationIDs or No TerminationID available 2585 433 - TerminationID is already in a Context 2586 440 - Unsupported or unknown Package 2587 441 - Missing RemoteDescriptor 2588 442 - Syntax Error in Command 2589 443 - Unsupported or Unknown Command 2590 444 - Unsupported or Unknown Descriptor 2591 445 - Unsupported or Unknown Property 2592 446 - Unsupported or Unknown Parameter 2593 447 - Descriptor not legal in this command 2594 448 - Descriptor appears twice in a command 2595 450 - No such property in this package 2596 451 - No such event in this package 2597 452 - No such signal in this package 2598 453 - No such statistic in this package 2599 454 - No such parameter value in this package 2600 455 - Parameter illegal in this Descriptor 2601 456 - Parameter or Property appears twice in this Descriptor 2602 461 - TransactionIDs in Reply do not match Request 2603 462 - Commands in Transaction Reply do not match commands in request 2604 463 - TerminationID of Transaction Reply does not match request 2605 464 - Missing reply in Transaction Reply 2606 465 - TransactionID in Transaction Pending does not match any open 2607 request 2608 466 - Illegal Duplicate Transaction Request 2609 467 - Illegal Duplicate Transaction Reply 2610 471 - Implied Add for Multiplex failure 2612 500 - Internal Gateway Error 2613 501 - Not Implemented 2614 502 - Not ready. 2615 503 - Service Unavailable 2616 504 - Command Received from unauthorized entity 2617 505 - Command Received before Restart Response 2618 510 - Insufficient resources 2619 512 - Media Gateway unequipped to detect requested Event 2620 513 - Media Gateway unequipped to generate requested Signals 2621 514 - Media Gateway cannot send the specified announcement 2622 515 - Unsupported Media Type 2623 517 - Unsupported or invalid mode 2624 518 - Event buffer full 2625 519 - Out of space to store digit map 2626 520 - Media Gateway does not have a digit map 2627 521 - Termination is "ServiceChangeing" 2628 526 - Insufficient bandwidth 2629 529 - Internal hardware failure 2630 530 - Temporary Network failure 2631 531 - Permanent Network failure 2632 581 - Does Not Exist 2634 Internet draft MEGACO Protocol February 21, 2000 2636 8. TRANSACTIONS 2638 Commands between the Media Gateway Controller and the Media Gateway are 2639 grouped into Transactions, each of which is identified by a Transac- 2640 tionID. Transactions consist of one or more Actions. An Action con- 2641 sists of a series of Commands that are limited to operating within a 2642 single Context. Consequently each Action typically specifies a Contex- 2643 tID. However, there are two circumstances where a specific ContextID is 2644 not provided with an Action. One is the case of modification of a Ter- 2645 mination outside of a Context. The other is where the controller 2646 requests the gateway to create a new Context. Following is a graphic 2647 representation of the Transaction, Action and Command relationships. 2649 +----------------------------------------------------------+ 2650 | Transaction x | 2651 | +----------------------------------------------------+ | 2652 | | Action 1 | | 2653 | | +---------+ +---------+ +---------+ +---------+ | | 2654 | | | Command | | Command | | Command | | Command | | | 2655 | | | 1 | | 2 | | 3 | | 4 | | | 2656 | | +---------+ +---------+ +---------+ +---------+ | | 2657 | +----------------------------------------------------+ | 2658 | | 2659 | +----------------------------------------------------+ | 2660 | | Action 2 | | 2661 | | +---------+ | | 2662 | | | Command | | | 2663 | | | 1 | | | 2664 | | +---------+ | | 2665 | +----------------------------------------------------+ | 2666 | | 2667 | +----------------------------------------------------+ | 2668 | | Action 3 | | 2669 | | +---------+ +---------+ +---------+ | | 2670 | | | Command | | Command | | Command | | | 2671 | | | 1 | | 2 | | 3 | | | 2672 | | +---------+ +---------+ +---------+ | | 2673 | +----------------------------------------------------+ | 2674 +----------------------------------------------------------+ 2675 Figure 5 Transactions, Actions and Commands 2677 Transactions are presented as TransactionRequests. Corresponding 2678 responses to a TransactionRequest are received in a single reply, possi- 2679 bly preceded by a number of TransactionPending messages (see section 2680 8.2.3). 2682 Internet draft MEGACO Protocol February 21, 2000 2684 Transactions guarantee ordered Command processing. That is, Commands 2685 within a Transaction are executed sequentially. Ordering of Transactions 2686 is NOT guaranteed - transactions may be executed in any order, or simul- 2687 taneously. 2689 At the first failing Command in a Transaction, processing of the remain- 2690 ing Commands in that Transaction stops. If a command contains a wild- 2691 carded TerminationID, the command is attempted with each of the actual 2692 TerminationIDs matching the wildcard. A response within the Transac- 2693 tionReply is included for each matching TerminationID, even if one or 2694 more instances generated an error. If any TerminationID matching a 2695 wildcard results in an error when executed, any commands following the 2696 wildcarded command are not attempted. Commands may be marked as 2697 "Optional" which can override this behaviour - if a command marked as 2698 Optional results in an error, subsequent commands in the Transaction 2699 will be executed. 2701 A TransactionReply includes the results for all of the Commands in the 2702 corresponding TransactionRequest. The TransactionReply includes the 2703 return values for the Commands that were executed successfully, and the 2704 Command and error descriptor for any Command that failed. Transaction- 2705 Pending is used to periodically notify the receiver that a Transaction 2706 has not completed yet, but is actively being processed. 2708 Applications SHOULD implement an application level timer per transac- 2709 tion. Expiration of the timer should cause a retransmission of the 2710 request. Receipt of a Reply should cancel the timer. Receipt of Pending 2711 should restart the timer. 2713 8.1. Common Parameters 2715 8.1.1. Transaction Identifiers 2717 Transactions are identified by a TransactionID, which is assigned by 2718 sender and is unique within the scope of the sender. 2720 8.1.2. Context Identifiers 2722 Contexts are identified by a ContextID, which is assigned by the Media 2723 Gateway and is unique within the scope of the Media Gateway. The Media 2724 Gateway Controller shall use the ContextID supplied by the Media Gateway 2725 in all subsequent Transactions relating to that Context. The protocol 2726 makes reference to a distinguished value that may be used by the Media 2727 Gateway Controller when referring to a Termination that is currently not 2728 associated with a Context, namely the null ContextID. 2730 The CHOOSE wildcard is used to request that the Media Gateway create a 2732 Internet draft MEGACO Protocol February 21, 2000 2734 new Context. The MGC shall not use partially specified ContextIDs con- 2735 taining the CHOOSE wildcard. The MGC may use the ALL wildcard to 2736 address all Contexts on the MG. 2738 8.2. Transaction Application Programming Interface 2740 Following is an Application Programming Interface (API) describing the 2741 Transactions of the protocol. This API is shown to illustrate the Tran- 2742 sactions and their parameters and is not intended to specify implementa- 2743 tion (e.g. via use of blocking function calls). It will describe the 2744 input parameters and return values expected to be used by the various 2745 Transactions of the protocol from a very high level. Transaction syntax 2746 and encodings are specified in later subsections. 2748 8.2.1. TransactionRequest 2750 The TransactionRequest is invoked by the sender. There is one Transac- 2751 tion per request invocation. A request contains one or more Actions, 2752 each of which specifies its target Context and one or more Commands per 2753 Context. 2755 TransactionRequest(TransactionId { 2756 ContextID {Command ... Command}, 2757 . . . 2758 ContextID {Command ... Command } }) 2760 The TransactionID parameter must specify a value for later correlation 2761 with the TransactionReply or TransactionPending response from the 2762 receiver. 2764 The ContextID parameter must specify a value to pertain to all Commands 2765 that follow up to either the next specification of a ContextID parameter 2766 or the end of the TransactionRequest, whichever comes first. 2768 The Command parameter represents one of the Commands mentioned in the 2769 "Command Details" subsection titled "Application Programming Interface". 2771 8.2.2. TransactionReply 2773 The TransactionReply is invoked by the receiver. There is one reply 2774 invocation per transaction. A reply contains one or more Actions, each 2775 of which must specify its target Context and one or more Responses per 2776 Context. 2778 TransactionReply(TransactionID { 2779 ContextID { Response ... Response }, 2780 . . . 2782 Internet draft MEGACO Protocol February 21, 2000 2784 ContextID { Response ... Response } }) 2786 The TransactionID parameter must be the same as that of the correspond- 2787 ing TransactionRequest. 2789 The ContextID parameter must specify a value to pertain to all Responses 2790 for the action. The ContextID may be specific or null. 2792 Each of the Response parameters represents a return value as mentioned 2793 in section 7.2, or an error descriptor if the command execution encoun- 2794 tered an error. Commands after the point of failure are not processed 2795 and, therefore, Responses are not issued for them. 2797 An exception to this occurs if a command has been marked as optional in 2798 the Transaction request. If the optional command generates an error, 2799 the transaction still continues to execute, so the Reply would, in this 2800 case, have Responses after an Error. 2802 If the receiver encounters an error in processing a ContextID, the 2803 requested Action response will consist of the context ID and a single 2804 error descriptor, 422 Syntax Error in Action. 2806 If the receiver encounters an error such that it cannot determine a 2807 legal Action, it will return a TransactionReply consisting of the Tran- 2808 sactionID and a single error descriptor, 422 Syntax Error in Action. If 2809 the end of an action cannot be reliably determined but one or more 2810 Actions can be parsed, it will process them and then send 422 Syntax 2811 Error in Action as the last action for the transaction. If the receiver 2812 encounters an error such that is cannot determine a legal Transaction, 2813 it will return a TransactionReply with a null TransactionID and a single 2814 error descriptor (403 Syntax Error in Transaction). 2816 If the end of a transaction can not be reliably determined and one or 2817 more Actions can be parsed, it will process them and then return 403 2818 Syntax Error in Transaction as the last action reply for the transac- 2819 tion. If no Actions can be parsed, it will return 403 Syntax Error in 2820 Transaction as the only reply 2822 If the terminationID cannot be reliably determined it will send 442 Syn- 2823 tax Error in Command as the action reply. 2825 If the end of a command cannot be reliably determined it will return 442 2826 Syntax Error in Transaction as the reply to the last action it can 2827 parse. 2829 8.2.3. TransactionPending 2831 The receiver invokes the TransactionPending. A TransactionPending 2833 Internet draft MEGACO Protocol February 21, 2000 2835 indicates that the Transaction is actively being processed, but has not 2836 been completed. It is used to prevent the sender from assuming the 2837 TransactionRequest was lost where the Transaction will take some time to 2838 complete. 2840 TransactionPending(TransactionID { } ) 2842 The TransactionID parameter must be the same as that of the correspond- 2843 ing TransactionRequest. A property of root (normalMGExecutionTime) is 2844 settable by the MGC to indicate the interval within which the MGC 2845 expects a response to any transaction from the MG. Another property 2846 (normalMGCExecutionTime) is settable by the MGC to indicate the interval 2847 within which the MG should expects a response to any transaction from 2848 the MGC. Senders may receive more than one TransactionPending for a 2849 command. If a duplicate request is received when pending, the responder 2850 may send a duplicate pending immediately, or continue waiting for its 2851 timer to trigger another Transaction Pending. 2853 8.3. Messages 2855 Multiple Transactions can be concatenated into a Message. Messages have 2856 a header, which includes the identity of the sender. The Message Iden- 2857 tifier (MID) of a message is set to a provisioned name (e.g. domain 2858 address/domain name/device name) of the entity transmitting the message. 2859 Domain name is a suggested default. 2861 Every Message contains a Version Number identifying the version of the 2862 protocol the message conforms to. Versions consist of one or two 2863 digits, beginning with version 1 for the present version of the proto- 2864 col. 2866 The transactions in a message are treated independently. There is no 2867 order implied, there is no application or protocol acknowledgement of a 2868 message. 2870 9. TRANSPORT 2872 The transport mechanism for the protocol should allow the reliable tran- 2873 sport of transactions between an MGC and MG. The transport shall remain 2874 independent of what particular commands are being sent and shall be 2875 applicable to all application states. There are several transports 2876 defined for the protocol, which are defined in normative Annexes to this 2877 document. Additional Transports may be defined as additional annexes in 2878 subsequent editions of this document, or in separate documents. For 2879 transport of the protocol over IP, MGCs shall implement both TCP and 2880 UDP/ALF, an MG shall implement TCP or UDP/ALF or both. 2882 The MG is provisioned with a name or address (such as DNS name or IP 2884 Internet draft MEGACO Protocol February 21, 2000 2886 address) of a primary and zero or more secondary MGCs (see section 2887 7.2.8) that is the address the MG uses to send messages to the MGC. If 2888 TCP or UDP is used as the protocol transport and the port to which the 2889 initial ServiceChange request is to be sent is not otherwise known, that 2890 request should be sent to the default port number for the protocol. 2891 This port number is 2944 for text-encoded operation or 2945 for binary- 2892 encoded operation, for either UDP or TCP. The MGC receives the message 2893 containing the ServiceChange request from the MG and can determine the 2894 MG's address from it. As described in section 7.2.8, either the MG or 2895 the MGC may supply an address in the ServiceChangeAddress parameter to 2896 which subsequent transaction requests must be addressed, but responses 2897 (including the response to the initial ServiceChange request) must 2898 always be sent back to the address which was the source of the 2899 corresponding request. 2901 9.1. Ordering of Commands 2903 This document does not mandate that the underlying transport protocol 2904 guarantees the sequencing of transactions sent to an entity. This pro- 2905 perty tends to maximize the timeliness of actions, but it has a few 2906 drawbacks. For example: 2908 * Notify commands may be delayed and arrive at the MGC after the 2909 transmission of a new command changing the EventsDescriptor 2911 * If a new command is transmitted before a previous one is ack- 2912 nowledged, there is no guarantee that prior command will be exe- 2913 cuted before the new one. 2915 Media Gateway Controllers that want to guarantee consistent operation of 2916 the Media Gateway may use the following rules. These rules are with 2917 respect to commands that are in different transactions. Commands that 2918 are in the same transaction are executed in order (see section 8). 2920 1. When a Media Gateway handles several Terminations, commands per- 2921 taining to the different Terminations may be sent in parallel, for 2922 example following a model where each Termination (or group of Ter- 2923 minations) is controlled by its own process or its own thread. 2925 2. On a Termination, there should normally be at most one outstanding 2926 command (Add or Modify or Move), unless the outstanding commands 2927 are in the same transaction. However, a Subtract command may be 2928 issued at any time. In consequence, a Media Gateway may sometimes 2929 receive a Modify command that applies to a previously subtracted 2930 Termination. Such commands should be ignored, and an error code 2931 should be returned. 2933 3. On a given Termination, there should normally be at most one 2935 Internet draft MEGACO Protocol February 21, 2000 2937 outstanding Notify command at any time. 2939 4. In some cases, an implicitly or explicitly wildcarded Subtract com- 2940 mand that applies to a group of Terminations may step in front of a 2941 pending Add command. The Media Gateway Controller should individu- 2942 ally delete all Terminations for which an Add command was pending 2943 at the time of the global Subtract command. Also, new Add commands 2944 for Terminations named by the wild-carding (or implied in a Multi- 2945 plex descriptor) should not be sent until the wild-carded Subtract 2946 command is acknowledged. 2948 5. AuditValue and AuditCapability are not subject to any sequencing. 2950 6. ServiceChange shall always be the first command sent by a MG as 2951 defined by the restart procedure. Any other command or response 2952 must be delivered after this ServiceChange command. 2954 These rules do not affect the command responder, which should always 2955 respond to commands. 2957 9.2. Protection against Restart Avalanche 2959 In the event that a large number of Media Gateways are powered on simul- 2960 taneously and they were to all initiate a ServiceChange transaction, the 2961 Media Gateway Controller would very likely be swamped, leading to mes- 2962 sage losses and network congestion during the critical period of service 2963 restoration. In order to prevent such avalanches, the following behavior 2964 is suggested: 2966 1. When a Media Gateway is powered on, it should initiate a restart 2967 timer to a random value, uniformly distributed between 0 and a max- 2968 imum waiting delay (MWD). Care should be taken to avoid synchroni- 2969 city of the random number generation between multiple Media Gate- 2970 ways that would use the same algorithm. 2972 2. The Media Gateway should then wait for either the end of this timer 2973 or the detection of a local user activity, such as for example an 2974 off-hook transition on a residential Media Gateway. 2976 3. When the timer elapses, or when an activity is detected, the Media 2977 Gateway should initiate the restart procedure. 2979 The restart procedure simply requires the MG to guarantee that the first 2980 message that the Media Gateway Controller sees from this MG is a Servi- 2981 ceChange message informing the Media Gateway Controller about the res- 2982 tart 2984 Note - The value of MWD is a configuration parameter that depends on the 2986 Internet draft MEGACO Protocol February 21, 2000 2988 type of the Media Gateway. The following reasoning may be used to deter- 2989 mine the value of this delay on residential gateways. 2991 Media Gateway Controllers are typically dimensioned to handle the peak 2992 hour traffic load, during which, in average, 10% of the lines will be 2993 busy, placing calls whose average duration is typically 3 minutes. The 2994 processing of a call typically involves 5 to 6 Media Gateway Controller 2995 transactions between each Media Gateway and the Media Gateway Con- 2996 troller. This simple calculation shows that the Media Gateway Con- 2997 troller is expected to handle 5 to 6 transactions for each Termination, 2998 every 30 minutes on average, or, to put it otherwise, about one transac- 2999 tion per Termination every 5 to 6 minutes on average. This suggests 3000 that a reasonable value of MWD for a residential gateway would be 10 to 3001 12 minutes. In the absence of explicit configuration, residential gate- 3002 ways should adopt a value of 600 seconds for MWD. 3004 The same reasoning suggests that the value of MWD should be much shorter 3005 for trunking gateways or for business gateways, because they handle a 3006 large number of Terminations, and also because the usage rate of these 3007 Terminations is much higher than 10% during the peak busy hour, a typi- 3008 cal value being 60%. These Terminations, during the peak hour, are this 3009 expected to contribute about one transaction per minute to the Media 3010 Gateway Controller load. A reasonable algorithm is to make the value of 3011 MWD per "trunk" Termination six times shorter than the MWD per residen- 3012 tial gateway, and also inversely proportional to the number of Termina- 3013 tions that are being restarted. For example MWD should be set to 2.5 3014 seconds for a gateway that handles a T1 line, or to 60 milliseconds for 3015 a gateway that handles a T3 line. 3017 10. SECURITY CONSIDERATIONS 3019 This section covers security when using the protocol in an IP environ- 3020 ment. 3022 10.1. Protection of Protocol Connections 3024 A security mechanism is clearly needed to prevent unauthorized entities 3025 from using the protocol defined in this document for setting up unau- 3026 thorized calls or interfering with authorized calls. The security 3027 mechanism for the protocol when transported over IP networks is IPsec 3028 [RFC2401 to RFC2411]. 3030 The AH header [RFC2402] affords data origin authentication, connection- 3031 less integrity and optional anti-replay protection of messages passed 3032 between the MG and the MGC. The ESP header [RFC2406] provides confiden- 3033 tiality of messages, if desired. For instance, the ESP encryption ser- 3034 vice should be requested if the session descriptions are used to carry 3035 session keys, as defined in SDP. 3037 Internet draft MEGACO Protocol February 21, 2000 3039 Implementations of the protocol defined in this document employing the 3040 ESP header SHALL comply with section 5 of [RFC2406], which defines a 3041 minimum set of algorithms for integrity checking and encryption. Simi- 3042 larly, implementations employing the AH header SHALL comply with section 3043 5 of [RFC2402], which defines a minimum set of algorithms for integrity 3044 checking using manual keys. 3046 Implementations SHOULD use IKE [RFC2409] to permit more robust keying 3047 options. Implementations employing IKE SHOULD support authentication 3048 with RSA signatures and RSA public key encryption. 3050 10.2. Interim AH scheme 3052 Implementation of IPsec requires that the AH or ESP header be inserted 3053 immediately after the IP header. This cannot be easily done at the 3054 application level. Therefore, this presents a deployment problem for 3055 the protocol defined in this document where the underlying network 3056 implementation does not support IPsec. 3058 As an interim solution, an optional AH header is defined within the 3059 MEGACO protocol header. The header fields are exactly those of the SPI, 3060 SEQUENCE NUMBER and DATA fields as defined in [RFC2402]. The semantics 3061 of the header fields are the same as the "transport mode" of [RFC2402], 3062 except for the calculation of the Integrity Check value (ICV). In IPsec, 3063 the ICV is calculated over the entire IP packet including the IP header. 3064 This prevents spoofing of the IP addresses. To retain the same func- 3065 tionality, the ICV calculation should be performed across the entire 3066 transaction prepended by a synthesized IP header consisting of a 32 bit 3067 source IP address, a 32 bit destination address and an 16 bit UDP 3068 encoded as 10 hex digits. When the interim AH mechanism is employed when 3069 TCP is the transport Layer, the UDP Port above becomes the TCP port, and 3070 all other operations are the same. 3072 Implementations of the MEGACO protocol SHALL implement IPsec where the 3073 underlying operating system and the transport network supports IPsec. 3074 Implementations of the protocol using IPv4 SHALL implement the interim 3075 AH scheme. However, this interim scheme SHALL NOT be used when the 3076 underlying network layer supports IPsec. IPv6 implementations are 3077 assumed to support IPsec and SHALL NOT use the interim AH scheme. 3079 All implementations of the interim AH mechanism SHALL comply with sec- 3080 tion 5 of [RFC2402] which defines a minimum set of algorithms for 3081 integrity checking using manual keys. 3083 The interim AH interim scheme does not provide protection against eaves- 3084 dropping; thus forbidding third parties from monitoring the connections 3085 set up by a given termination. Also, it does not provide protection 3086 against replay attacks. These procedures do not necessarily protect 3088 Internet draft MEGACO Protocol February 21, 2000 3090 against denial of service attacks by misbehaving MGs or misbehaving 3091 MGCs. However, they will provide an identification of these misbehaving 3092 entities, which should then be deprived of their authorization through 3093 maintenance procedures. 3095 10.3. Protection of Media Connections 3097 The protocol allows the MGC to provide MGs with "session keys" that can 3098 be used to encrypt the audio messages, protecting against eavesdropping. 3100 A specific problem of packet networks is "uncontrolled barge-in". This 3101 attack can be performed by directing media packets to the IP address and 3102 UDP port used by a connection. If no protection is implemented, the 3103 packets must be decompressed and the signals must be played on the "line 3104 side". 3106 A basic protection against this attack is to only accept packets from 3107 known sources, checking for example that the IP source address and UDP 3108 source port match the values announced in the Remote Descriptor. This 3109 has two inconveniences: it slows down connection establishment and it 3110 can be fooled by source spoofing: 3112 * To enable the address-based protection, the MGC must obtain the 3113 remote session description of the egress MG and pass it to the 3114 ingress MG. This requires at least one network roundtrip, and 3115 leaves us with a dilemma: either allow the call to proceed without 3116 waiting for the round trip to complete, and risk for example, 3117 "clipping" a remote announcement, or wait for the full roundtrip 3118 and settle for slower call-set-up procedures. 3120 * Source spoofing is only effective if the attacker can obtain valid 3121 pairs of source destination addresses and ports, for example by 3122 listening to a fraction of the traffic. To fight source spoofing, 3123 one could try to control all access points to the network. But 3124 this is in practice very hard to achieve. 3126 An alternative to checking the source address is to encrypt and authen- 3127 ticate the packets, using a secret key that is conveyed during the call 3128 set-up procedure. This will not slow down the call set- up, and provides 3129 strong protection against address spoofing. 3131 11. MG-MGC CONTROL INTERFACE 3133 The control association between MG and MGC is initiated at MG cold 3134 start, and announced by a ServiceChange message, but can be changed by 3135 subsequent events, such as failures or manual service events. While the 3136 protocol does not have an explicit mechanism to support multiple MGCs 3137 controlling a physical MG, it has been designed to support the multiple 3139 Internet draft MEGACO Protocol February 21, 2000 3141 logical MG (within a single physical MG) that can be associated with 3142 different MGCs. 3144 11.1. Multiple Virtual MGs 3146 A physical Media Gateway may be partitioned into one or more Virtual 3147 MGs. A virtual MG consists of a set of statically partitioned physical 3148 Terminations and/or sets of ephemeral Terminations. A physical Termina- 3149 tion is controlled by one MGC. The model does not require that other 3150 resources be statically allocated, just Terminations. The mechanism for 3151 allocating Terminations to virtual MGs is a management method outside 3152 the scope of the protocol. Each of the virtual MGs appears to the MGC 3153 as a complete MG client. 3155 A physical MG may have only one network interface, which must be shared 3156 across virtual MGs. In such a case, the packet/cell side Termination is 3157 shared. It should be noted however, that in use, such interfaces 3158 require an ephemeral instance of the Termination to be created per flow, 3159 and thus sharing the Termination is straightforward. This mechanism 3160 does lead to a complication, namely that the MG must always know which 3161 of its controlling MGCs should be notified if an event occurs on the 3162 interface. 3164 In normal operation, the Virtual MG will be instructed by the MGC to 3165 create network flows (if it is the originating side), or to expect flow 3166 requests (if it is the terminating side), and no confusion will arise. 3167 However, if an unexpected event occurs, the Virtual MG must know what to 3168 do with respect to the physical resources it is controlling. 3170 If recovering from the event requires manipulation of a physical 3171 interface's state, only one MGC should do so. These issues are resolved 3172 by allowing any of the MGCs to create EventsDescriptors to be notified 3173 of such events, but only one MGC can have read/write access to the phy- 3174 sical interface properties; all other MGCs have read-only access. The 3175 management mechanism is used to designate which MGC has read/write capa- 3176 bility, and is designated the Master MGC. 3178 Each virtual MG has its own Root Termination. In most cases the values 3179 for the properties of the Root Termination are independently settable by 3180 each MGC. Where there can only be one value, the parameter is read-only 3181 to all but the Master MGC. 3183 ServiceChange may only be applied to a Termination or set of Termina- 3184 tions partitioned to the Virtual MG or created (in the case of ephemeral 3185 Terminations) by that Virtual MG. 3187 Internet draft MEGACO Protocol February 21, 2000 3189 11.2. Cold Start 3191 A MG is pre-provisioned by a management mechanism outside the scope of 3192 this protocol with a Primary and (optionally) an ordered list of Secon- 3193 dary MGCs. Upon a cold start of the MG, it will issue a ServiceChange 3194 command with a "Restart" method, on the Root Termination to its primary 3195 MGC. If the MGC accepts the MG, it will send a Transaction Accept, with 3196 the ServiceChangeMgcId set to itself. If the MG receives an Servi- 3197 ceChangeMgcId not equal to the MGC it contacted, it sends a Servi- 3198 ceChange to the MGC specified in the ServiceChangeMgcId. It continues 3199 this process until it gets a controlling MGC to accept its registration, 3200 or it fails to get a reply. Upon failure to obtain a reply, either from 3201 the Primary MGC, or a designated successor, the MG tries its pre- 3202 provisioned Secondary MGCs, in order. If the MG is unable to comply and 3203 it has established a transport connection to the MGC, it should close 3204 that connection. In any event, it should reject all subsequent requests 3205 from the MGC with Error 406 Version Not Supported. 3207 It is possible that the reply to a ServiceChange with Restart will be 3208 lost, and a command will be received by the MG prior to the receipt of 3209 the ServiceChange response. The MG shall issue error 505 - Command 3210 Received before Restart Response. 3212 11.3. Negotiation of Protocol Version 3214 The first ServiceChange command from an MG shall contain the version 3215 number of the protocol supported by the MG in the ServiceChangeVersion 3216 parameter. Upon receiving such a message, if the MGC supports only a 3217 lower version, then the MGC shall send a ServiceChangeReply with the 3218 lower version and thereafter all the messages between MG and MGC shall 3219 conform to the lower version of the protocol. If the MG is unable to 3220 comply and it has established a transport connection to the MGC, it 3221 should close that connection. In any event, it should reject all subse- 3222 quent requests from the MGC with Error 406 Version Not supported. 3224 If the MGC supports a higher version than the MG but is able to support 3225 the lower version proposed by the MG, it shall send a ServiceChangeReply 3226 with the lower version and thereafter all the messages between MG and 3227 MGC shall conform to the lower version of the protocol. If the MGC is 3228 unable to comply, it shall reject the association, with Error 406 Ver- 3229 sion Not Supported. 3231 Protocol version negotiation may also occur at "handoff" and "failover" 3232 ServiceChanges. 3234 When extending the protocol with new versions, the following rules 3235 should be followed. 3237 Internet draft MEGACO Protocol February 21, 2000 3239 1. Existing protocol elements, i.e., procedures, parameters, descrip- 3240 tor, property, values, should not be changed unless a protocol 3241 error needs to be corrected or it becomes necessary to change the 3242 operation of the service that is being supported by the protocol. 3244 2. The semantics of a command, a parameter, descriptor, property, 3245 value should not be changed. 3247 3. Established rules for formatting and encoding messages and parame- 3248 ters should not be modified. 3250 4. When information elements are found to be obsolete they can be 3251 marked as not used. However, the identifier for that information 3252 element will be marked as reserved. In that way it can not be used 3253 in future versions. 3255 11.4. Failure of an MG 3257 If a MG fails, but is capable of sending a message to the MGC, it sends 3258 a ServiceChange with an appropriate method (graceful or forced) and 3259 specifies the Root TerminationID. When it returns to service, it sends 3260 a ServiceChange with a "Restart" method. 3262 Allowing the MGC to send duplicate messages to both MGs accommodates 3263 pairs of MGs that are capable of redundant failover of one of the MGs. 3264 Only the Working MG shall accept or reject transactions. Upon failover, 3265 the Primary MG sends a ServiceChange command with a "Failover" method 3266 and a "MG Impending Failure" reason. The MGC then uses the primary MG 3267 as the active MG. When the error condition is repaired, the Working MG 3268 can send a "ServiceChange" with a "Restart" method. 3270 11.5. Failure of an MGC 3272 If the MG detects a failure of its controlling MGC, it attempts to con- 3273 tact the next MGC on its pre-provisioned list. It starts its attempts 3274 at the beginning (Primary MGC), unless that was the MGC that failed, in 3275 which case it starts at its first Secondary MGC. It sends a Servi- 3276 ceChange message with a "Failover" method and a " MGC Impending Failure" 3277 reason. 3279 In partial failure, or manual maintenance reasons, an MGC may wish to 3280 direct its controlled MGs to use a different MGC. To do so, it sends a 3281 ServiceChange method to the MG with a "HandOff" method, and its desig- 3282 nated replacement in ServiceChangeMgcId. The MG should send a Servi- 3283 ceChange message with a "Handoff" method and a "MGC directed change" 3284 reason to the designated MGC. If it fails to get a reply, or fails to 3285 see an Audit command subsequently, it should behave as if its MGC 3286 failed, and start contacting secondary MGCs. If the MG is unable to 3288 Internet draft MEGACO Protocol February 21, 2000 3290 establish a control relationship with any MGC, it shall wait a random 3291 amount of time as described in section 9.2 and then start contacting its 3292 primary, and if necessary, its secondary MGCs again. 3294 No recommendation is made on how the MGCs involved in the Handoff main- 3295 tain state information; this is considered to be out of scope of this 3296 recommendation. The MGC and MG may take the following steps when Handoff 3297 occurs. When the MGC initiates a HandOff, the handover should be tran- 3298 sparent to Operations on the Media Gateway. Transactions can be exe- 3299 cuted in any order, and could be in progress when the ServiceChange is 3300 executed. Accordingly, commands in progress continue, transaction 3301 replies are sent to the new MGC (after a new control association is 3302 established), and the MG should expect outstanding transaction replies 3303 from the new MGC. No new messages shall be sent to the new MGC until 3304 the control association is established. Repeated transaction requests 3305 shall be directed to the new MGC. The MG shall maintain state on all 3306 terminations and contexts. 3308 It is possible that the MGC could be implemented in such a way that a 3309 failed MGC is replaced by a working MGC where the identity of the new 3310 MGC is the same as the failed one. In such a case, ServiceChangeMgcId 3311 would be specified with the previous value and the MG shall behave as if 3312 the value was changed, and send a ServiceChange message, as above. 3314 Pairs of MGCs that are capable of redundant failover can notify the con- 3315 trolled MGs of the failover by the above mechanism. 3317 12. PACKAGE DEFINITION 3319 The primary mechanism for extension is by means of Packages. Packages 3320 define additional Properties, Events, Signals and Statistics that may 3321 occur on Terminations. 3323 Packages defined by IETF will appear in separate RFCs. 3325 Packages defined by ITU-T may appear in the relevant recommendations 3326 (e.g. as annexes). 3328 1. A public document or a standard forum document, which can be refer- 3329 enced as the document that describes the package following the 3330 guideline above, should be specified. 3332 2. The document shall specify the version of the Package that it 3333 describes. 3335 3. The document should be available on a public web server and should 3336 have a stable URL. The site should provide a mechanism to provide 3337 comments and appropriate responses should be returned. 3339 Internet draft MEGACO Protocol February 21, 2000 3341 12.1. Guidelines for defining packages 3343 Packages define Properties, Events, Signals, and Statistics. 3345 Packages may also define new error codes according to the guidelines 3346 given in section 13.2. This is a matter of documentary convenience: the 3347 package documentation is submitted to IANA in support of the error code 3348 registration. If a package is modified, it is unnecessary to provide 3349 IANA with a new document reference in support of the error code unless 3350 the description of the error code itself is modified. 3352 Names of all such defined constructs shall consist of the PackageID 3353 (which uniquely identifies the package) and the ID of the item (which 3354 uniquely identifies the item in that package). In the text encoding the 3355 two shall be separated by a forward slash ("/") character. Example: 3356 togen/playtone is the text encoding to refer to the play tone signal in 3357 the tone generation package. 3359 A Package will contain the following sections: 3361 12.1.1. Package 3363 Overall description of the package, specifying: 3365 Package Name: only descriptive, 3366 PackageID: Is an identifier 3367 Description: 3368 Version: 3369 A new version of a package can only add additional 3370 Properties, Events, Signals, Statistics and new possible 3371 values for an existing parameter described in the 3372 package. No deletions or modifications shall be allowed. 3373 A version is an integer in the range from 1 to 99. 3374 Extends (Optional): 3375 A package may extend an existing package. The version of 3376 the original package must be specified. When a package 3377 extends another package it shall only add additional 3378 Properties, Events, Signals, Statistics and new possible 3379 values for an existing parameter described in the original 3380 package. An extended package shall not redefine or 3381 overload a name defined in the original package. 3382 Hence, if package B version 1 extends package A version 1, 3383 version 2 of B will not be able to extend the A version 2 3384 if A version 2 defines a name already in B version 1. 3386 Internet draft MEGACO Protocol February 21, 2000 3388 12.1.2. Properties 3390 Properties defined by the package, specifying: 3392 Property Name: only descriptive. 3393 PropertyID: Is an identifier 3394 Description: 3395 Type: One of: 3396 String: UTF-8 string 3397 Integer: 4 byte signed integer 3398 Double: 8 byte signed integer 3399 Character: Unicode UTF-8 encoding of a single letter. 3400 Could be more than one octet. 3401 Enumeration: One of a list of possible unique values (See 12.3) 3402 Sub-list: A list of several values from a list 3403 Boolean 3404 Possible Values: 3405 Defined in: 3406 Which descriptor the property is defined in. LocalControl 3407 is for stream dependent properties. TerminationState is for 3408 stream independent properties. 3409 Characteristics: Read / Write or both, and (optionally), global: 3410 Indicates whether a property is read-only, or read-write, 3411 and if it is global. If Global is omitted, the property 3412 is not global. If a property is declared as global, 3413 the value of the property is shared by all terminations 3414 realizing the package. 3416 12.1.3. Events 3418 Events defined by the package, specifying: 3420 Event name: only descriptive. 3421 EventID: Is an identifier 3422 Description: 3423 EventsDescriptor Parameters: 3424 Parameters used by the MGC to configure the event, 3425 and found in the EventsDescriptor. See section 12.2. 3426 ObservedEventsDescriptor Parameters: 3427 Parameters returned to the MGC in Notify requests and in 3428 replies to command requests from the MGC that audit 3429 ObservedEventsDescriptor, and found in the 3430 ObservedEventsDescriptor. See section 12.2. 3432 Internet draft MEGACO Protocol February 21, 2000 3434 12.1.4. Signals 3436 Signals defined by the package, specifying: 3438 Signal Name: only descriptive. 3439 SignalID: Is an identifier. SignalID is used in a 3440 SignalsDescriptor 3441 Description 3442 SignalType: One of: 3443 OO (On/Off) 3444 TO (TimeOut) 3445 BR (Brief) 3447 Note:SignalType may be defined such that it is dependent on the 3448 value of one or more parameters. Signals that would be played 3449 with SignalType BR should have a default duration. The package has 3450 to define the default duration and signalType. 3452 Duration: in hundredths of seconds 3453 Additional Parameters: See section 12.2 3455 12.1.5. Statistics 3457 Statistics defined by the package, specifying: 3459 Statistic name: only descriptive. 3460 StatisticID: Is an identifier 3461 StatisticID is used in a StatisticsDescriptor 3462 Description 3463 Units: unit of measure, e.g. milliseconds, packets 3465 12.1.6. Procedures 3467 Additional guidance on the use of the package. 3469 12.2. Guidelines to defining Properties, Statistics and Parameters to 3470 Events and Signals. 3472 Parameter Name: only descriptive 3473 ParameterID: Is an identifier 3474 Type: One of: 3475 String: UTF-8 octet string 3476 Integer: 4 octet signed integer 3477 Double: 8 octet signed integer 3478 Character: Unicode UTF-8 encoding of a single letter. 3480 Internet draft MEGACO Protocol February 21, 2000 3482 Could be more than one octet. 3483 Enumeration: One of a list of possible unique values 3484 (See 12.3) 3485 Sub-list: A list of several values from a list 3486 Boolean 3487 Possible values: 3488 Description: 3490 12.3. Lists 3492 Possible values for parameters include enumerations. Enumerations may 3493 be defined in a list. It is recommended that the list be IANA 3494 registered so that packages that extend the list can be defined without 3495 concern for conflicting names. 3497 12.4. Identifiers 3499 Identifiers in text encoding shall be strings of up to 64 characters, 3500 containing no spaces, starting with an alphanumeric character and con- 3501 sisting of alphanumeric characters and / or digits, and possibly includ- 3502 ing the special character underscore ("_"). Identifiers in binary 3503 encoding are 2 octets long. Both text and binary values shall be speci- 3504 fied for each identifier, including identifiers used as values in 3505 enumerated types. 3507 12.5. Package Registration 3509 A package can be registered with IANA for interoperability reasons. See 3510 section 13 for IANA considerations. 3512 13. IANA CONSIDERATIONS 3514 13.1. Packages 3516 The following considerations SHALL be met to register a package with 3517 IANA: 3519 1. A unique string name, unique serial number and version number is 3520 registered for each package. The string name is used with text 3521 encoding. The serial number shall be used with binary encoding. 3522 Serial Numbers 60000-64565 are reserved for private use. Serial 3523 number 0 is reserved. 3525 2. A contact name, email and postal addresses for that contact shall 3526 be specified. The contact information shall be updated by the 3527 defining organization as necessary. 3529 Internet draft MEGACO Protocol February 21, 2000 3531 3. A reference to a document that describes the package, which should 3532 be public: The document shall specify the version of the Package 3533 that it describes. If the document is public, it should be located 3534 on a public web server and should have a stable URL. The site 3535 should provide a mechanism to provide comments and appropriate 3536 responses should be returned. 3538 4. Packages registered by other than recognized standards bodies shall 3539 have a minimum package name length of 8 characters 3541 5. All other package names are first come-first served if all other 3542 conditions are met 3544 13.2. Error Codes 3546 The following considerations SHALL be met to register an error code with 3547 IANA: 3549 1. An error number and a one line (80 character maximum) string is 3550 registered for each error. 3552 2. A complete description of the conditions under which the error is 3553 detected shall be included in a publicly available document. The 3554 description shall be sufficiently clear to differentiate the error 3555 from all other existing error codes. 3557 3. The document should be available on a public web server and should 3558 have a stable URL. 3560 4. Error numbers registered by recognized standards bodies shall have 3561 3 or 4 character error numbers. 3563 5. Error numbers registered by all other organizations or individuals 3564 shall have 4 character error numbers. 3566 6. An error number shall not be redefined, nor modified except by the 3567 organization or individual that originally defined it, or their 3568 successors or assigns. 3570 13.3. ServiceChange Reasons 3572 The following considerations SHALL be met to register service change 3573 reason with IANA: 3575 1. A one phrase, 80-character maximum, unique reason code is 3576 registered for each reason. 3578 2. A complete description of the conditions under which the reason is 3580 Internet draft MEGACO Protocol February 21, 2000 3582 used is detected shall be included in a publicly available docu- 3583 ment. The description shall be sufficiently clear to differentiate 3584 the reason from all other existing reasons. 3586 3. The document should be available on a public web server and should 3587 have a stable URL. 3589 14. CONTACT INFORMATION 3591 IETF Editor 3592 Brian Rosen 3593 Marconi 3594 1000 FORE Drive 3595 Warrendale, PA 15086 3596 U.S.A. 3597 Phone: +1 724-742-6826 3598 Email: brosen@fore.com 3599 ITU Editor 3600 John Segers 3601 Lucent Technologies 3602 Room HE 306 3603 Dept. Forward Looking Work 3604 P.O. Box 18, 1270 AA Huizen 3605 Netherlands 3606 Phone: +31 35 687 4724 3607 Email: jsegers@lucent.com 3609 Additional IETF Authors 3610 Fernando Cuervo 3611 Nortel Networks 3612 P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7 3613 Canada 3614 Email: cuervo@nortelnetworks.com 3616 Bryan Hill 3617 Gotham Networks 3618 15 Discovery Way 3619 Acton, MA 01720 3620 USA 3621 Phone: +1 978-263-6890 3622 Email: bhill@gothamnetworks.com 3624 Christian Huitema 3625 Telcordia Technologies 3626 MCC 1J236B 3627 445 South Street 3628 Morristown, NJ 07960 3629 U.S.A. 3631 Internet draft MEGACO Protocol February 21, 2000 3633 Phone: +1 973-829-4266 3634 EMail: huitema@research.telcordia.com 3636 Nancy Greene 3637 Nortel Networks 3638 P.O. Box 3511 Stn C 3639 Ottawa, ON, K1Y 4H7 3640 Canada 3641 Phone: +1 514-271-7221 3642 Email: ngreene@nortelnetworks.com 3644 Abdallah Rayhan 3645 Nortel Networks 3646 P.O. Box 3511 Stn C 3647 Ottawa, ON, K1Y 4H7 3648 Canada 3649 Phone: +1 613-763-9611 3650 Email: arayhan@nortelnetworks.com 3652 ANNEX A BINARY ENCODING OF THE PROTOCOL (NORMATIVE) 3654 This Annex specifies the syntax of messages using the notation defined 3655 in ASN.1 [ITU-T Recommendation X.680 (1997): Information Technology - 3656 Abstract Syntax Notation One (ASN.1) - Specification of basic nota- 3657 tion.]. Messages shall be encoded for transmission by applying the basic 3658 encoding rules specified in [ITU-T Recommendation X.690(1994) Informa- 3659 tion Technology - ASN.1 Encoding Rules: Specification of Basic 3660 Encoding Rules (BER)]. 3662 A.1. Coding of wildcards 3664 The use of wildcards ALL and CHOOSE is allowed in the protocol. This 3665 allows a MGC to partially specify Termination IDs and let the MG choose 3666 from the values that conform to the partial specification. Termination 3667 IDs may encode a hierarchy of names. This hierarchy is provisioned. For 3668 instance, a TerminationID may consist of a trunk group, a trunk within 3669 the group and a circuit. Wildcarding must be possible at all levels. 3670 The following paragraphs explain how this is achieved. 3672 The ASN.1 description uses octet strings of up to 8 octets in length for 3673 Termination IDs. This means that Termination IDs consist of at most 64 3674 bits. A fully specified Termination ID may be preceded by a sequence of 3675 wildcarding fields. A wildcarding field is octet in length. Bit 7 (the 3676 most significant bit) of this octet specifies what type of wildcarding 3677 is invoked: if the bit value equals 1, then the ALL wildcard is used; 3678 if the bit value if 0, then the CHOOSE wildcard is used. Bit 6 of the 3680 Internet draft MEGACO Protocol February 21, 2000 3682 wildcarding field specifies whether the wildcarding pertains to one 3683 level in the hierarchical naming scheme (bit value 0) or to the level of 3684 the hierarchy specified in the wildcarding field plus all lower levels 3685 (bit value 1). Bits 0 through 5 of the wildcarding field specify the 3686 bit position in the Termination ID at which the starts. 3688 We illustrate this scheme with some examples. In these examples, the 3689 most significant bit in a string of bits appears on the left hand side. 3691 Assume that Termination IDs are three octets long and that each octet 3692 represents a level in a hierarchical naming scheme. A valid Termination 3693 ID is 3695 00000001 00011110 01010101. 3697 Addressing ALL names with prefix 00000001 00011110 is done as follows: 3699 wildcarding field: 10000111 3701 Termination ID: 00000001 00011110 xxxxxxxx. 3703 The values of the bits labeled "x" is irrelevant and shall be ignored by 3704 the receiver. 3706 Indicating to the receiver that is must choose a name with 00011110 as 3707 the second octet is done as follows: 3709 wildcarding fields: 00010111 followed by 00000111 3711 Termination ID: xxxxxxxx 00011110 xxxxxxxx. The first wild- 3712 card field indicates a CHOOSE wildcard for the level in the naming 3713 hierarchy starting at bit 23, the highest level in our assumed nam- 3714 ing scheme. The second wildcard field indicates a CHOOSE wildcard 3715 for the level in the naming hierarchy starting at bit 7, the lowest 3716 level in our assumed naming scheme. 3718 Finally, a CHOOSE-wildcarded name with the highest level of the name 3719 equal to 00000001 is specified as follows: 3721 wildcard field: 01001111 3723 Termination ID: 0000001 xxxxxxxx xxxxxxxx . 3725 Bit value 1 at bit position 6 of the first octet of the wildcard field 3726 indicates that the wildcarding pertains to the specified level in the 3727 naming hierarchy and all lower levels. 3729 Context IDs may also be wildcarded. In the case of Context IDs, 3731 Internet draft MEGACO Protocol February 21, 2000 3733 however, specifying partial names is not allowed. Context ID 0x0 SHALL 3734 be used to indicate the NULL Context, Context ID 0xFFFFFFFE SHALL be 3735 used to indicate a CHOOSE wildcard, and Context ID 0xFFFFFFFF SHALL be 3736 used to indicate an ALL wildcard. 3738 TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT Ter- 3739 mination. 3741 A.2. ASN.1 syntax specification 3743 This section contains the ASN.1 specification of the H.248 protocol syn- 3744 tax. 3746 NOTE In case a transport mechanism is used that employs application 3747 level framing, the definition of Transaction below changes. Refer 3748 to the annex defining the transport mechanism for the definition 3749 that applies in that case. 3751 NOTE The ASN.1 specification below contains a clause defining Termina- 3752 tionIDList as a sequence of TerminationIDs. The length of this 3753 sequence SHALL be one. The SEQUENCE OF construct is present only 3754 to allow future extensions. 3756 MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::= 3757 BEGIN 3759 MegacoMessage ::= SEQUENCE 3760 { 3761 authHeader AuthenticationHeader OPTIONAL, 3762 mess Message 3763 } 3765 AuthenticationHeader ::= SEQUENCE 3766 { 3767 secParmIndex SecurityParmIndex, 3768 seqNum SequenceNum, 3769 ad AuthData 3770 } 3772 SecurityParmIndex ::= OCTET STRING(SIZE(4)) 3774 SequenceNum ::= OCTET STRING(SIZE(4)) 3776 AuthData ::= OCTET STRING (SIZE (16..32)) 3778 Message ::= SEQUENCE 3780 Internet draft MEGACO Protocol February 21, 2000 3782 { 3783 version INTEGER(0..99), 3784 -- The version of the protocol defined here is equal to 1. 3785 mId MId,-- Name/address of message originator 3786 messageBodyCHOICE 3787 { 3788 messageErrorErrorDescriptor, 3789 transactions SEQUENCE OF Transaction 3790 }, 3791 ... 3792 } 3794 MId ::= CHOICE 3795 { 3796 ip4Address IP4Address, 3797 ip6AddressIP6Address, 3798 domainName DomainName, 3799 deviceName PathName, 3800 mtpAddressOCTET STRING(SIZE(2)), 3801 -- Addressing structure of mtpAddress: 3802 -- 15 0 3803 -- | PC | NI | 3804 -- 14 bits 2 bits 3805 ... 3806 } 3808 DomainName ::= SEQUENCE 3809 { 3810 name IA5String, 3811 -- The name starts with an alphanumeric digit followed by a 3812 -- sequence of alphanumeric digits, hyphens and dots. No two 3813 -- dots shall occur consecutively. 3814 portNumberINTEGER(0..65535) OPTIONAL 3815 } 3817 IP4Address ::= SEQUENCE 3818 { 3819 addressOCTET STRING (SIZE(4)), 3820 portNumberINTEGER(0..65535) OPTIONAL 3821 } 3823 IP6Address ::= SEQUENCE 3824 { 3825 addressOCTET STRING (SIZE(16)), 3826 portNumberINTEGER(0..65535) OPTIONAL 3827 } 3829 PathName ::= IA5String(SIZE (1..64)) 3831 Internet draft MEGACO Protocol February 21, 2000 3833 -- See section A.3 3835 Transaction ::= CHOICE 3836 { 3837 transactionRequest TransactionRequest, 3838 transactionPending TransactionPending, 3839 transactionReply TransactionReply, 3840 transactionResponseAckTransactionResponseAck, 3841 -- use of response acks is dependent on underlying transport 3842 ... 3843 } 3845 TransactionId ::= INTEGER(0..4294967295) -- 32 bit unsigned integer 3847 TransactionRequest ::= SEQUENCE 3848 { 3849 transactionId TransactionId, 3850 actions SEQUENCE OF ActionRequest, 3851 ... 3852 } 3854 TransactionPending ::= SEQUENCE 3855 { 3856 transactionId TransactionId, 3857 ... 3858 } 3860 TransactionReply ::= SEQUENCE 3861 { 3862 transactionId TransactionId, 3863 transactionResult CHOICE 3864 { 3865 transactionErrorErrorDescriptor, 3866 actionRepliesSEQUENCE OF ActionReply 3867 }, 3868 ... 3869 } 3871 TransactionResponseAck ::= SEQUENCE 3872 { 3873 firstAckTransactionId, 3874 lastAckTransactionId OPTIONAL 3875 } 3877 ErrorDescriptor ::= SEQUENCE 3878 { 3879 errorCode ErrorCode, 3880 errorText ErrorText OPTIONAL 3882 Internet draft MEGACO Protocol February 21, 2000 3884 } 3886 ErrorCode ::= INTEGER(0..65535) 3887 -- See section 13 for IANA considerations w.r.t. error codes 3889 ErrorText ::= IA5String 3891 ContextID ::= INTEGER(0..4294967295) 3893 -- Context NULL Value: 0 3894 -- Context CHOOSE Value: 429467294 (0xFFFFFFFE) 3895 -- Context ALL Value: 4294967295 (0xFFFFFFFF) 3897 ActionRequest ::= SEQUENCE 3898 { 3899 contextIdContextID, 3900 contextRequestContextRequest OPTIONAL, 3901 contextAttrAuditReqContextAttrAuditRequest OPTIONAL, 3902 commandRequestsSEQUENCE OF CommandRequest 3903 } 3905 ActionReply ::= SEQUENCE 3906 { 3907 contextId ContextID, 3908 errorDescriptorErrorDescriptor OPTIONAL, 3909 contextReplyContextRequest OPTIONAL, 3910 commandReply SEQUENCE OF CommandReply 3911 } 3913 ContextRequest ::= SEQUENCE 3914 { 3915 priorityINTEGER(0..15) OPTIONAL, 3916 emergencyBOOLEAN OPTIONAL, 3917 topologyReqSEQUENCE OF TopologyRequest OPTIONAL, 3918 ... 3919 } 3921 ContextAttrAuditRequest ::= SEQUENCE 3922 { 3923 topologyNULL OPTIONAL, 3924 emergencyNULL OPTIONAL, 3925 priorityNULL OPTIONAL, 3926 ... 3927 } 3929 CommandRequest ::= SEQUENCE 3930 { 3932 Internet draft MEGACO Protocol February 21, 2000 3934 commandCommand, 3935 optionalNULL OPTIONAL, 3936 wildcardReturnNULL OPTIONAL, 3937 ... 3938 } 3940 Command ::= CHOICE 3941 { 3942 addReq AmmRequest, 3943 moveReq AmmRequest, 3944 modReq AmmRequest, 3945 -- Add, Move, Modify requests have the same parameters 3946 subtractReq SubtractRequest, 3947 auditCapRequest AuditRequest, 3948 auditValueRequest AuditRequest, 3949 notifyReq NotifyRequest, 3950 serviceChangeReq ServiceChangeRequest, 3951 ... 3952 } 3954 CommandReply ::= CHOICE 3955 { 3956 addReply AmmsReply, 3957 moveReply AmmsReply, 3958 modReply AmmsReply, 3959 subtractReply AmmsReply, 3960 -- Add, Move, Modify, Subtract replies have the same parameters 3961 auditCapReply AuditReply, 3962 auditValueReply AuditReply, 3963 notifyReply NotifyReply, 3964 serviceChangeReply ServiceChangeReply, 3965 ... 3966 } 3968 TopologyRequest ::= SEQUENCE 3969 { 3970 terminationFrom TerminationID, 3971 terminationTo TerminationID, 3972 topologyDirection ENUMERATED 3973 { 3974 bothway(0), 3975 isolate(1), 3976 oneway(2) 3977 } 3978 } 3980 AmmRequest ::= SEQUENCE 3981 { 3983 Internet draft MEGACO Protocol February 21, 2000 3985 terminationID TerminationIDList, 3986 mediaDescriptor MediaDescriptor OPTIONAL, 3987 modemDescriptor ModemDescriptor OPTIONAL, 3988 muxDescriptor MuxDescriptor OPTIONAL, 3989 eventsDescriptor EventsDescriptor OPTIONAL, 3990 eventBufferDescriptorEventBufferDescriptor OPTIONAL, 3991 signalsDescriptor SignalsDescriptor OPTIONAL, 3992 digitMapDescriptor DigitMapDescriptor OPTIONAL, 3993 auditDescriptor AuditDescriptor OPTIONAL, 3994 ... 3995 } 3997 AmmsReply ::= SEQUENCE 3998 { 3999 terminationID TerminationIDList, 4000 terminationAudit TerminationAudit OPTIONAL 4001 } 4003 SubtractRequest ::= SEQUENCE 4004 { 4005 terminationID TerminationIDList, 4006 auditDescriptor AuditDescriptor OPTIONAL, 4007 ... 4008 } 4010 AuditRequest ::= SEQUENCE 4011 { 4012 terminationIDTerminationID, 4013 auditDescriptorAuditDescriptor, 4014 ... 4015 } 4017 AuditReply ::= SEQUENCE 4018 { 4019 terminationIDTerminationID, 4020 auditResultAuditResult 4021 } 4023 AuditResult ::= CHOICE 4024 { 4025 contextAuditResultTerminationIDList, 4026 terminationAuditResultTerminationAudit 4027 } 4029 AuditDescriptor ::= SEQUENCE 4030 { 4032 Internet draft MEGACO Protocol February 21, 2000 4034 auditTokenBIT STRING 4035 { 4036 muxToken(0), modemToken(1), mediaToken(2), 4037 eventsToken(3), signalsToken(4), 4038 digitMapToken(5), statsToken(6), 4039 observedEventsToken(7), 4040 packagesToken(8), eventBufferToken(9) 4041 } OPTIONAL, 4042 ... 4043 } 4045 TerminationAudit ::= SEQUENCE OF AuditReturnParameter 4047 AuditReturnParameter ::= CHOICE 4048 { 4049 errorDescriptorErrorDescriptor, 4050 mediaDescriptor MediaDescriptor, 4051 modemDescriptor ModemDescriptor, 4052 muxDescriptor MuxDescriptor, 4053 eventsDescriptor EventsDescriptor, 4054 eventBufferDescriptorEventBufferDescriptor, 4055 signalsDescriptor SignalsDescriptor, 4056 digitMapDescriptor DigitMapDescriptor, 4057 observedEventsDescriptor ObservedEventsDescriptor, 4058 statisticsDescriptor StatisticsDescriptor, 4059 packagesDescriptor PackagesDescriptor, 4060 ... 4061 } 4063 NotifyRequest ::= SEQUENCE 4064 { 4065 terminationID TerminationIDList, 4066 observedEventsDescriptor ObservedEventsDescriptor, 4067 errorDescriptorErrorDescriptor OPTIONAL, 4068 ... 4069 } 4071 NotifyReply ::= SEQUENCE 4072 { 4073 terminationID TerminationIDList OPTIONAL, 4074 errorDescriptor ErrorDescriptor OPTIONAL, 4075 ... 4076 } 4078 ObservedEventsDescriptor ::= SEQUENCE 4079 { 4080 requestId RequestID, 4081 observedEventLst SEQUENCE OF ObservedEvent 4083 Internet draft MEGACO Protocol February 21, 2000 4085 } 4087 ObservedEvent ::= SEQUENCE 4088 { 4089 eventNameEventName, 4090 streamIDStreamID OPTIONAL, 4091 eventParListSEQUENCE OF EventParameter, 4092 timeNotation TimeNotation OPTIONAL 4093 } 4095 EventName ::= PkgdName 4097 EventParameter ::= SEQUENCE 4098 { 4099 eventParameterNameName, 4100 value Value 4101 } 4103 ServiceChangeRequest ::= SEQUENCE 4104 { 4105 terminationID TerminationIDList, 4106 serviceChangeParms ServiceChangeParm, 4107 ... 4108 } 4110 ServiceChangeReply ::= SEQUENCE 4111 { 4112 terminationID TerminationIDList, 4113 serviceChangeResult ServiceChangeResult, 4114 ... 4115 } 4117 -- For ServiceChangeResult, no parameters are mandatory. Hence the 4118 -- distinction between ServiceChangeParm and ServiceChangeResParm. 4120 ServiceChangeResult ::= CHOICE 4121 { 4122 errorDescriptor ErrorDescriptor, 4123 serviceChangeResParms ServiceChangeResParm 4124 } 4126 WildcardField ::= OCTET STRING(SIZE(1)) 4128 TerminationID ::= SEQUENCE 4129 { 4130 wildcardSEQUENCE OF WildcardField, 4131 idOCTET STRING(SIZE(1..8)) 4132 } 4134 Internet draft MEGACO Protocol February 21, 2000 4136 -- See Section A.1 for explanation of wildcarding mechanism. 4137 -- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination. 4139 TerminationIDList ::= SEQUENCE OF TerminationID 4141 MediaDescriptor ::= SEQUENCE 4142 { 4144 termStateDescrTerminationStateDescriptor OPTIONAL, 4145 streamsCHOICE 4146 { 4147 oneStreamStreamParms, 4148 multiStreamSEQUENCE OF StreamDescriptor 4149 }, 4150 ... 4151 } 4153 StreamDescriptor ::= SEQUENCE 4154 { 4155 streamID StreamID, 4156 streamParmsStreamParms 4157 } 4159 StreamParms ::= SEQUENCE 4160 { 4161 localControlDescriptor LocalControlDescriptor OPTIONAL, 4162 localDescriptor LocalRemoteDescriptor OPTIONAL, 4163 remoteDescriptor LocalRemoteDescriptor OPTIONAL, 4164 ... 4165 } 4167 LocalControlDescriptor ::= SEQUENCE 4168 { 4169 streamMode StreamMode OPTIONAL, 4170 reserveBOOLEAN, 4171 propertyParms SEQUENCE OF PropertyParm, 4172 ... 4173 } 4175 StreamMode ::= ENUMERATED 4176 { 4177 sendOnly(0), 4178 recvOnly(1), 4179 sendRecv(2), 4180 inactive(3), 4181 loopBack(4), 4182 ... 4183 } 4185 Internet draft MEGACO Protocol February 21, 2000 4187 -- In PropertyParm, value is a SEQUENCE OF octet string. When sent 4188 -- by an MGC the interpretation is as follows: 4189 -- empty sequence means CHOOSE 4190 -- one element sequence specifies value 4191 -- longer sequence means "choose one of the values" 4192 -- The relation field may only be selected if the value sequence 4193 -- has length 1. It indicates that the MG has to choose a value 4194 -- for the property. E.g., x > 3 (using the greaterThan 4195 -- value for relation) instructs the MG to choose any value larger 4196 -- than 3 for property x. 4197 -- The range field may only be selected if the value sequence 4198 -- has length 2. It indicates that the MG has to choose a value 4199 -- in the range between the first octet in the value sequence and 4200 -- the trailing octet in the value sequence, including the 4201 -- boundary values. 4202 -- When sent by the MG, only responses to an AuditCapability request 4203 -- may contain multiple values, a range, or a relation field. 4205 PropertyParm ::= SEQUENCE 4206 { 4207 name PkgdName, 4208 value SEQUENCE OF OCTET STRING, 4209 extraInfoCHOICE 4210 { 4211 relationRelation, 4212 rangeBOOLEAN 4213 } OPTIONAL 4215 } 4217 Name ::= OCTET STRING(SIZE(2)) 4219 PkgdName ::= OCTET STRING(SIZE(4)) 4220 -- represents Package Name (2 octets) plus Property Name (2 octets) 4221 -- To wildcard a package use 0xFFFF for first two octets, choose 4222 -- is not allowed. To reference native property tag specified in 4223 -- Annex C, use 0x0000 as first two octets. 4224 -- Wildcarding of Package Name is permitted only if Property Name is 4225 -- also wildcarded. 4227 Relation ::= ENUMERATED 4228 { 4229 greaterThan(0), 4230 smallerThan(1), 4231 unequalTo(2), 4232 ... 4233 } 4235 Internet draft MEGACO Protocol February 21, 2000 4237 LocalRemoteDescriptor ::= SEQUENCE 4238 { 4239 propGrpsSEQUENCE OF PropertyGroup, 4240 ... 4241 } 4243 PropertyGroup ::= SEQUENCE OF PropertyParm 4245 TerminationStateDescriptor ::= SEQUENCE 4246 { 4247 propertyParms SEQUENCE OF PropertyParm, 4248 eventBufferControl EventBufferControl OPTIONAL, 4249 serviceState ServiceState OPTIONAL, 4250 ... 4251 } 4253 EventBufferControl ::= ENUMERATED 4254 { 4255 Off(0), 4256 LockStep(1), 4257 ... 4258 } 4260 ServiceState ::= ENUMERATED 4261 { 4262 test(0), 4263 outOfSvc(1), 4264 inSvc(2), 4265 ... 4266 } 4268 MuxDescriptor ::= SEQUENCE 4269 { 4270 muxType MuxType, 4271 termList SEQUENCE OF TerminationID, 4272 nonStandardDataNonStandardData OPTIONAL, 4273 ... 4274 } 4276 MuxType ::= ENUMERATED 4277 { 4278 h221(0), 4279 h223(1), 4280 h226(2), 4281 v76(3), 4282 ... 4283 } 4285 Internet draft MEGACO Protocol February 21, 2000 4287 StreamID ::= INTEGER(0..65535) -- 16 bit unsigned integer 4289 EventsDescriptor ::= SEQUENCE 4290 { 4291 requestID RequestID, 4292 eventList SEQUENCE OF RequestedEvent 4293 } 4295 RequestedEvent ::= SEQUENCE 4296 { 4297 pkgdName PkgdName, 4298 streamIDStreamID OPTIONAL, 4299 eventAction RequestedActions OPTIONAL, 4300 evParList SEQUENCE OF EventParameter 4301 } 4303 RequestedActions ::= SEQUENCE 4304 { 4305 keepActiveBOOLEAN, 4306 eventDMEventDM OPTIONAL, 4307 secondEvent SecondEventsDescriptor OPTIONAL, 4308 signalsDescriptor SignalsDescriptor OPTIONAL, 4309 ... 4310 } 4312 EventDM ::= CHOICE 4313 { digitMapNameDigitMapName, 4314 digitMapValueDigitMapValue 4315 } 4317 SecondEventsDescriptor ::= SEQUENCE 4318 { 4319 requestID RequestID, 4320 eventList SEQUENCE OF SecondRequestedEvent 4321 } 4323 SecondRequestedEvent ::= SEQUENCE 4324 { 4325 pkgdName PkgdName, 4326 streamIDStreamID OPTIONAL, 4327 eventAction SecondRequestedActions OPTIONAL, 4328 evParList SEQUENCE OF EventParameter 4329 } 4331 SecondRequestedActions ::= SEQUENCE 4332 { 4333 keepActiveBOOLEAN, 4335 Internet draft MEGACO Protocol February 21, 2000 4337 eventDMEventDM OPTIONAL, 4338 signalsDescriptor SignalsDescriptor OPTIONAL, 4339 ... 4340 } 4342 EventBufferDescriptor ::= SEQUENCE OF ObservedEvent 4344 SignalsDescriptor ::= SEQUENCE OF SignalRequest 4346 SignalRequest ::=CHOICE 4347 { 4348 signalSignal, 4349 seqSigListSeqSigList 4350 } 4352 SeqSigList ::= SEQUENCE 4353 { 4354 idINTEGER(0..65535), 4355 signalListSEQUENCE OF Signal 4356 } 4358 Signal ::= SEQUENCE 4359 { 4360 signalName SignalName, 4361 streamIDStreamID OPTIONAL, 4362 sigTypeSignalType OPTIONAL, 4363 durationINTEGER (0..65535) OPTIONAL, 4364 notifyCompletionBOOLEAN OPTIONAL, 4365 keepActiveBOOLEAN OPTIONAL, 4366 sigParList SEQUENCE OF SigParameter 4367 } 4369 SignalType ::= ENUMERATED 4370 { 4371 brief(0), 4372 onOff(1), 4373 timeOut(2), 4374 ... 4375 } 4377 SignalName ::= PkgdName 4379 SigParameter ::= SEQUENCE 4380 { 4381 sigParameterName Name, 4382 value Value 4383 } 4385 Internet draft MEGACO Protocol February 21, 2000 4387 RequestID ::= INTEGER(0..4294967295) -- 32 bit unsigned integer 4389 ModemDescriptor ::= SEQUENCE 4390 { 4391 mtl SEQUENCE OF ModemType, 4392 mpl SEQUENCE OF PropertyParm,nonStandardData 4393 NonStandardData OPTIONAL 4394 } 4396 ModemType ::= ENUMERATED 4397 { 4398 v18(0), 4399 v22(1), 4400 v22bis(2), 4401 v32(3), 4402 v32bis(4), 4403 v34(5), 4404 v90(6), 4405 v91(7), 4406 synchISDN(8), 4407 ... 4408 } 4410 DigitMapDescriptor ::= SEQUENCE 4411 { 4412 digitMapName DigitMapName, 4413 digitMapValue DigitMapValue 4414 } 4416 DigitMapName ::= Name 4418 DigitMapValue ::= SEQUENCE 4419 { 4420 startTimer INTEGER(0..99) OPTIONAL, 4421 shortTimer INTEGER(0..99) OPTIONAL, 4422 longTimer INTEGER(0..99) OPTIONAL, 4423 digitMapBody IA5String 4424 -- See Section A.3 for explanation of digit map syntax 4425 } 4427 ServiceChangeParm ::= SEQUENCE 4428 { 4429 serviceChangeMethod ServiceChangeMethod, 4430 serviceChangeAddressServiceChangeAddress OPTIONAL, 4431 serviceChangeVersionINTEGER(0..99) OPTIONAL, 4432 serviceChangeProfile ServiceChangeProfile OPTIONAL, 4433 serviceChangeReason Value, 4434 serviceChangeDelay INTEGER(0..4294967295) OPTIONAL, 4436 Internet draft MEGACO Protocol February 21, 2000 4438 -- 32 bit unsigned integer 4439 serviceChangeMgcId MId OPTIONAL, 4440 timeStampTimeNotation OPTIONAL, 4441 nonStandardDataNonStandardData OPTIONAL, 4442 } 4444 ServiceChangeAddress ::= CHOICE 4445 { 4446 portNumberINTEGER(0..65535), -- TCP/UDP port number 4447 ip4Address IP4Address, 4448 ip6AddressIP6Address, 4449 domainName DomainName, 4450 deviceName PathName, 4451 mtpAddressOCTET STRING(SIZE(2)), 4452 ... 4453 } 4455 ServiceChangeResParm ::= SEQUENCE 4456 { 4457 serviceChangeMgcId MId OPTIONAL, 4458 serviceChangeAddressServiceChangeAddress OPTIONAL, 4459 serviceChangeVersionINTEGER(0..99) OPTIONAL, 4460 serviceChangeProfileServiceChangeProfile OPTIONAL 4461 } 4463 ServiceChangeMethod ::= ENUMERATED 4464 { 4465 failover(0), 4466 forced(1), 4467 graceful(2), 4468 restart(3), 4469 disconnected(4), 4470 handOff(5), 4471 ... 4472 } 4474 ServiceChangeProfile ::= SEQUENCE 4475 { 4476 profileName Name, 4477 version INTEGER(0..99) 4478 } 4480 PackagesDescriptor ::= SEQUENCE OF PackagesItem 4482 PackagesItem ::= SEQUENCE 4483 { 4484 packageNameName, 4485 packageVersionINTEGER(0..99) 4487 Internet draft MEGACO Protocol February 21, 2000 4489 } 4491 StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter 4493 StatisticsParameter ::= SEQUENCE 4494 { 4495 statName PkgdName, 4496 statValue Value 4497 } 4499 NonStandardData ::= SEQUENCE 4500 { 4501 nonStandardIdentifierNonStandardIdentifier, 4502 dataOCTET STRING 4503 } 4505 NonStandardIdentifier::= CHOICE 4506 { 4507 objectOBJECT IDENTIFIER, 4508 h221NonStandardH221NonStandard, 4509 experimentalIA5STRING(SIZE(8)), 4510 -- first two characters should be "X-" or "X+" 4511 ... 4512 } 4514 H221NonStandard ::= SEQUENCE 4515 { t35CountryCodeINTEGER(0..255), -- country, as per T.35 4516 t35ExtensionINTEGER(0..255), -- assigned nationally 4517 manufacturerCodeINTEGER(0..65535), -- assigned nationally 4518 ... 4519 } 4521 TimeNotation ::= SEQUENCE 4522 { 4523 date IA5String(SIZE(8)), -- yyyymmdd format 4524 time IA5String(SIZE(8)) -- hhmmssss format 4525 } 4527 Value ::= OCTET STRING 4529 END 4531 A.3. Digit maps and path names 4533 >From a syntactic viewpoint, digit maps are strings with syntactic res- 4534 trictions imposed upon them. The syntax of valid digit maps is specified 4536 Internet draft MEGACO Protocol February 21, 2000 4538 in ABNF [RFC 2234]. The syntax for digit maps presented in this section 4539 is for illustrative purposes only. The definition of digitMap in Annex B 4540 takes precedence in the case of differences between the two. 4542 digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")" 4543 LWSP) 4544 digitStringList = digitString *( LWSP "/" LWSP digitString ) 4545 digitString = 1*(digitStringElement) 4546 digitStringElement = digitPosition [DOT] 4547 digitPosition = digitMapLetter / digitMapRange 4548 digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) 4549 digitLetter = *((DIGIT "-" DIGIT) /digitMapLetter) 4550 digitMapLetter = DIGIT ;digits 0-9 4551 / %x41-4B / %x61-6B ;a-k and A-K 4552 / "L" / "S" ;Inter-event timers 4553 ;(long, short) 4554 / "Z" ;Long duration event 4555 LWSP = *(WSP / COMMENT / EOL) 4556 WSP = SP / HTAB 4557 COMMENT = ";" *(SafeChar / RestChar / WSP) EOL 4558 EOL = (CR [LF]) / LF 4559 SP = %x20 4560 HTAB = %x09 4561 CR = %x0D 4562 LF = %x0A 4563 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" / 4564 "'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / " 4565 "(" / ")" / "%" / "." 4566 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" / 4567 "<" / ">" / "=" / %x22 4568 DIGIT = %x30-39 ; digits 0 through 9 4569 ALPHA = %x41-5A / %x61-7A ; A-Z, a-z 4571 A path name is also a string with syntactic restrictions imposed upon 4572 it. The ABNF production defining it is copied from Annex B. 4574 PathName = NAME *(["/"] ["*"] ["@"] (ALPHA / DIGIT)) ["*"] 4575 NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 4577 ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE) 4579 Internet draft MEGACO Protocol February 21, 2000 4581 B.1. Coding of wildcards 4583 In a text encoding of the protocol, while TerminationIDs are arbitrary, 4584 by judicious choice of names, the wildcard character, "*" may be made 4585 more useful. When the wildcard character is encountered, it will 4586 "match" all TerminationIDs having the same previous and following char- 4587 acters (if appropriate). For example, if there were TerminationIDs of 4588 R13/3/1, R13/3/2 and R13/3/3, the TerminationID R13/3/* would match all 4589 of them. There are some circumstances where ALL Terminations must be 4590 referred to. The TerminationID "*" suffices, and is referred to as ALL. 4591 The CHOOSE TerminationID "$" may be used to signal to the MG that it has 4592 to create an ephemeral Termination or select an idle physical Termina- 4593 tion. 4595 B.2. ABNF specification 4597 The protocol syntax is presented in ABNF according to RFC2234. 4599 megacoMessage = LWSP [authenticationHeader SEP ] message 4601 authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON 4602 SequenceNum COLON AuthData 4604 SecurityParmIndex = "0x" 8(HEXDIG) 4605 SequenceNum = "0x" 8(HEXDIG) 4606 AuthData = "0x" 32*64(HEXDIG) 4608 message = MegacopToken SLASH Version SEP mId SEP messageBody 4610 messageBody = ( errorDescriptor / transactionList ) 4612 transactionList = 1*( transactionRequest / transactionReply / 4613 transactionPending) 4615 transactionPending = PendingToken EQUAL TransactionID LBRKT 4616 RBRKT 4618 transactionResponseAck = ResponseAckToken LBRKT transactionAck 4619 *(COMMA transactionAck) RBRKT 4620 transactionAck = transactionID / (transactionID "-" transactionID) 4622 transactionRequest = TransToken EQUAL TransactionID LBRKT 4623 actionRequest *(COMMA actionRequest) RBRKT 4625 actionRequest = CtxToken EQUAL ContextID LBRKT (( 4626 contextRequest [COMMA commandRequestList]) 4627 / commandRequestList) RBRKT 4629 Internet draft MEGACO Protocol February 21, 2000 4631 contextRequest = ((contextProperties [COMMA contextAudit]) 4632 / contextAudit) 4634 contextProperties = contextProperty *(COMMA contextProperty) 4636 ; at-most-once 4637 contextProperty = (topologyDescriptor / priority / EmergencyToken) 4639 contextAudit = ContextAuditToken LBRKT 4640 contextAuditProperties *(COMMA 4641 contextAuditProperties) RBRKT 4643 ; at-most-once 4644 contextAuditProperties = ( TopologyToken / EmergencyToken / 4645 PriorityToken ) 4647 commandRequestList= ["O-"] commandRequest *(COMMA ["O-"]commandRequest) 4649 commandRequest = ( ammRequest / subtractRequest / auditRequest / 4650 notifyRequest / serviceChangeRequest) 4652 transactionReply = ReplyToken EQUAL TransactionID LBRKT 4653 ( errorDescriptor / actionReplyList ) RBRKT 4655 actionReplyList = actionReply *(COMMA actionReply ) 4657 actionReply = CtxToken EQUAL ContextID LBRKT 4658 ( errorDescriptor / commandReply ) RBRKT 4660 commandReply = (( contextProperties [COMMA commandReplyList] ) / 4661 commandReplyList ) 4663 commandReplyList = commandReplys *(COMMA commandReplys ) 4665 commandReplys = (serviceChangeReply / auditReply / ammsReply / 4666 notifyReply ) 4668 ;Add Move and Modify have the same request parameters 4669 ammRequest = (AddToken / MoveToken / ModifyToken ) EQUAL 4670 TerminationID [LBRKT ammParameter *(COMMA 4671 ammParameter) RBRKT] 4673 ;at-most-once 4674 ammParameter = (mediaDescriptor / modemDescriptor / 4675 muxDescriptor / eventsDescriptor / 4676 signalsDescriptor / digitMapDescriptor / 4677 eventBufferDescriptor / auditDescriptor) 4679 Internet draft MEGACO Protocol February 21, 2000 4681 ammsReply = (AddToken / MoveToken / ModifyToken / 4682 SubtractToken ) EQUAL TerminationID [ LBRKT 4683 terminationAudit RBRKT ] 4685 subtractRequest = ["W-"] SubtractToken EQUAL TerminationID 4686 [ LBRKT auditDescriptor RBRKT] 4688 auditRequest = ["W-"] (AuditValueToken / AuditCapToken ) EQUAL 4689 TerminationID LBRKT auditDescriptor RBRKT 4691 auditReply = (AuditValueToken / AuditCapToken ) 4692 ( contextTerminationAudit / auditOther) 4694 auditOther = EQUAL TerminationID LBRKT 4695 terminationAudit RBRKT 4697 terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) 4699 contextTerminationAudit = EQUAL CtxToken ( terminationIDList / 4700 LBRKT errorDescriptor RBRKT ) 4701 ;at-most-once except errorDescriptor 4702 auditReturnParameter = (mediaDescriptor / modemDescriptor / 4703 muxDescriptor / eventsDescriptor / 4704 signalsDescriptor / digitMapDescriptor / 4705 observedEventsDescriptor / eventBufferDescriptor / 4706 statisticsDescriptor / packagesDescriptor / 4707 errorDescriptor ) 4709 auditDescriptor = AuditToken LBRKT [ auditItem 4710 *(COMMA auditItem) ] RBRKT 4712 notifyRequest = NotifyToken EQUAL TerminationID 4713 LBRKT ( observedEventsDescriptor 4714 [ COMMA errorDescriptor ] ) RBRKT 4716 notifyReply = NotifyToken EQUAL TerminationID 4717 [ LBRKT errorDescriptor RBRKT ] 4719 serviceChangeRequest = ServiceChangeToken EQUAL TerminationID 4720 LBRKT serviceChangeDescriptor RBRKT 4722 serviceChangeReply = ServiceChangeToken EQUAL TerminationID 4723 [LBRKT (errorDescriptor / 4724 serviceChangeReplyDescriptor) RBRKT] 4726 errorDescriptor = ErrorToken EQUAL ErrorCode 4727 LBRKT [quotedString] RBRKT 4729 Internet draft MEGACO Protocol February 21, 2000 4731 ErrorCode = 1*4(DIGIT) ; could be extended 4733 TransactionID = UINT32 4735 mId = (( domainAddress / domainName ) 4736 [":" portNumber]) / mtpAddress / deviceName 4738 ; ABNF allows two or more consecutive "." although it is meaningless 4739 ; in a domain name. 4740 domainName = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" / 4741 ".") ">" 4742 deviceName = pathNAME 4744 ContextID = (UINT32 / "*" / "-" / "$") 4746 domainAddress = "[" (IPv4address / IPv6address) "]" 4747 ;RFC2373 contains the definition of IP6Addresses. 4748 IPv6address = hexpart [ ":" IPv4address ] 4749 IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex 4750 V4hex = 1*3(DIGIT) ; "0".."225" 4751 ; this production, while occurring in RFC2373, is not referenced 4752 ; IPv6prefix = hexpart SLASH 1*2DIGIT 4753 hexpart = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq 4754 hexseq = hex4 *( ":" hex4) 4755 hex4 = 1*4HEXDIG 4757 portNumber = UINT16 4759 ; An mtp address is two octets long 4760 mtpAddress = MTPToken LBRKT octetString RBRKT 4762 terminationIDList = LBRKT TerminationID *(COMMA TerminationID) RBRKT 4764 ; Total length of pathNAME must not exceed 64 chars. 4765 pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" 4766 ) 4767 ["@" pathDomainName ] 4769 ; ABNF allows two or more consecutive "." although it is meaningless 4770 ; in a path domain name. 4771 pathDomainName = (ALPHA / DIGIT / "*" ) 4772 *63(ALPHA / DIGIT / "-" / "*" / ".") 4774 TerminationID = "ROOT" / pathNAME / "$" / "*" 4776 mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT 4778 ; at-most-once per item 4780 Internet draft MEGACO Protocol February 21, 2000 4782 ; and either streamParm or streamDescriptor but not both 4783 mediaParm = (streamParm / streamDescriptor / 4784 terminationStateDescriptor) 4786 ; at-most-once 4787 streamParm = ( localDescriptor / remoteDescriptor / 4788 localControlDescriptor ) 4790 streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm 4791 *(COMMA streamParm) RBRKT 4793 localControlDescriptor = LocalControlToken LBRKT localParm 4794 *(COMMA localParm) RBRKT 4796 ; at-most-once per item 4797 localParm = ( streamMode / propertyParm / reservedValueMode 4798 / reservedGroupMode ) 4800 reservedValueMode = ReservedValueToken EQUAL ( "ON" / "OFF" ) 4801 reservedGroupMode = ReservedGroupToken EQUAL ( "ON" / "OFF" ) 4803 streamMode = ModeToken EQUAL streamModes 4805 streamModes = (SendonlyToken / RecvonlyToken / SendrecvToken / 4806 InactiveToken / LoopbackToken ) 4808 propertyParm = pkgdName parmValue 4809 parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) 4810 alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT / 4811 LSBRKT VALUE DOT DOT VALUE RSBRKT ) 4813 INEQUAL = LWSP (">" / "<" / "#" ) LWSP 4814 LSBRKT = LWSP "[" LWSP 4815 RSBRKT = LWSP "]" LWSP 4817 localDescriptor = LocalToken LBRKT octetString RBRKT 4819 remoteDescriptor = RemoteToken LBRKT octetString RBRKT 4821 eventBufferDescriptor= EventBufferToken LBRKT observedEvent 4822 *( COMMA observedEvent ) RBRKT 4824 eventBufferControl = BufferToken EQUAL ( "OFF" / LockStepToken ) 4826 terminationStateDescriptor = TerminationStateToken LBRKT 4827 terminationStateParm *( COMMA terminationStateParm ) RBRKT 4829 ; at-most-once per item 4831 Internet draft MEGACO Protocol February 21, 2000 4833 terminationStateParm =(propertyParm / serviceStates / eventBufferControl 4834 ) 4836 serviceStates = ServiceStatesToken EQUAL ( TestToken / 4837 OutOfSvcToken / InSvcToken ) 4839 muxDescriptor = MuxToken EQUAL MuxType terminationIDList 4841 MuxType = ( H221Token / H223Token / H226Token / V76Token 4842 extensionParameter ) 4844 StreamID = UINT16 4845 pkgdName = (PackageName SLASH ItemID) ;specific item 4846 / (PackageName SLASH "*") ;all events in package 4847 / ("*" SLASH "*") ; all events supported by the MG 4848 PackageName = NAME 4849 ItemID = NAME 4851 eventsDescriptor = EventsToken EQUAL RequestID LBRKT 4852 requestedEvent *( COMMA requestedEvent ) RBRKT 4854 requestedEvent = pkgdName [ LBRKT eventParameter 4855 *( COMMA eventParameter ) RBRKT ] 4857 ; at-most-once each of KeepActiveToken , eventDM and eventStream 4858 ;at most one of either embedWithSig or embedNoSig but not both 4859 ;KeepActiveToken and embedWithSig must not both be present 4860 eventParameter = ( embedWithSig / embedNoSig / KeepActiveToken 4861 /eventDM / eventStream / eventOther ) 4863 embedWithSig = EmbedToken LBRKT signalsDescriptor 4864 [COMMA embedFirst ] RBRKT 4865 embedNoSig = EmbedToken LBRKT embedFirst RBRKT 4867 ; at-most-once of each 4868 embedFirst = EventsToken EQUAL RequestID LBRKT 4869 secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT 4871 secondRequestedEvent = pkgdName [ LBRKT secondEventParameter 4872 *( COMMA secondEventParameter ) RBRKT ] 4874 ; at-most-once each of embedSig , KeepActiveToken, eventDM or 4875 ; eventStream 4876 ; KeepActiveToken and embedSig must not both be present 4877 secondEventParameter = ( EmbedSig / KeepActiveToken / eventDM / 4878 eventStream / eventOther ) 4880 embedSig = EmbedToken LBRKT signalsDescriptor RBRKT 4882 Internet draft MEGACO Protocol February 21, 2000 4884 eventStream = StreamToken EQUAL StreamID 4886 eventOther = eventParameterName parmValue 4888 eventParameterName = NAME 4890 eventDM = DigitMapToken ((EQUAL digitMapName ) / 4891 (LBRKT digitMapValue RBRKT )) 4893 signalsDescriptor = SignalsToken LBRKT [ signalParm 4894 *(COMMA signalParm)] RBRKT 4896 signalParm = signalList / signalRequest 4898 signalRequest = signalName [ LBRKT sigParameter 4899 *(COMMA sigParameter) RBRKT ] 4901 signalList = SignalListToken EQUAL signalListId LBRKT 4902 signalListParm *(COMMA signalListParm) RBRKT 4904 signalListId = UINT16 4906 ;exactly once signalType, at most once duration and every signal 4907 ;parameter 4908 signalListParm = signalRequest 4910 signalName = pkgdName 4911 ;at-most-once sigStream, at-most-once sigSignalType, 4912 ;at-most-once sigDuration, every signalParameterName at most once 4913 sigParameter = sigStream / sigSignalType / sigDuration / sigOther 4914 / notifyCompletion / KeepActiveToken 4915 sigStream = StreamToken EQUAL StreamID 4916 sigOther = sigParameterName parmValue 4917 sigParameterName = NAME 4918 sigSignalType = SignalTypeToken EQUAL signalType 4919 signalType = (OnOffToken / TimeOutToken / BriefToken) 4920 sigDuration = DurationToken EQUAL UINT16 4921 notifyCompletion = NotifyCompletionToken EQUAL ("ON" / "OFF") 4923 observedEventsDescriptor = ObservedEventsToken EQUAL RequestID 4924 LBRKT observedEvent *(COMMA observedEvent) RBRKT 4926 ;time per event, because it might be buffered 4927 observedEvent = [ TimeStamp LWSP COLON] LWSP 4928 pkgdName [ LBRKT observedEventParameter 4929 *(COMMA observedEventParameter) RBRKT ] 4931 ;at-most-once eventStream, every eventParameterName at most once 4933 Internet draft MEGACO Protocol February 21, 2000 4935 observedEventParameter = eventStream / eventOther 4937 RequestID = UINT32 4939 modemDescriptor = ModemToken (( EQUAL modemType) / 4940 (LSBRKT modemType *(COMMA modemType) RSBRKT)) 4941 [ LBRKT NAME parmValue 4942 *(COMMA NAME parmValue) RBRKT ] 4944 ; at-most-once 4945 modemType = (V32bisToken / V22bisToken / V18Token / 4946 V22Token / V32Token / V34Token / V90Token / 4947 V91Token / SynchISDNToken / extensionParameter) 4949 digitMapDescriptor = DigitMapToken EQUAL digitMapName 4950 ( LBRKT digitMapValue RBRKT ) 4951 digitMapName = NAME 4952 digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA] 4953 ["L" COLON Timer COMMA] digitMap 4954 Timer = 1*2DIGIT 4955 digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")" LWSP) 4956 digitStringList = digitString *( LWSP "|" LWSP digitString ) 4957 digitString = 1*(digitStringElement) 4958 digitStringElement = digitPosition [DOT] 4959 digitPosition = digitMapLetter / digitMapRange 4960 digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) 4961 digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter) 4962 digitMapLetter = DIGIT ;Basic event symbols 4963 / %x41-4B / %x61-6B ; a-k, A-K 4964 / "L" / "S" ;Inter-event timers (long, short) 4965 "Z" ;Long duration modifier 4967 ;at-most-once 4968 auditItem = ( MuxToken / ModemToken / MediaToken / 4969 SignalsToken / EventBufferToken / 4970 DigitMapToken / StatsToken / EventsToken / 4971 ObservedEventsToken / PackagesToken ) 4973 serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm 4974 *(COMMA serviceChangeParm) RBRKT 4976 serviceChangeParm = (serviceChangeMethod / serviceChangeReason / 4977 serviceChangeDelay / serviceChangeAddress / 4978 serviceChangeProfile / extension / TimeStamp / 4979 serviceChangeMgcId / serviceChangeVersion ) 4981 serviceChangeReplyDescriptor = ServicesToken LBRKT 4982 servChgReplyParm *(COMMA servChgReplyParm) RBRKT 4984 Internet draft MEGACO Protocol February 21, 2000 4986 ;at-most-once. Version is REQUIRED on first ServiceChange response 4987 servChgReplyParm = (serviceChangeAddress / serviceChangeMgcId / 4988 serviceChangeProfile / serviceChangeVersion ) 4989 serviceChangeMethod = MethodToken EQUAL (FailoverToken / 4990 ForcedToken / GracefulToken / RestartToken / 4991 DisconnectedToken / HandOffToken / 4992 extensionParameter) 4994 serviceChangeReason = ReasonToken EQUAL VALUE 4995 serviceChangeDelay = DelayToken EQUAL UINT32 4996 serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE 4997 serviceChangeMgcId = MgcIdToken EQUAL mId 4998 serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version 4999 serviceChangeVersion = VersionToken EQUAL Version 5000 extension = extensionParameter parmValue 5002 packagesDescriptor = PackagesToken LBRKT packagesItem 5003 *(COMMA packagesItem) RBRKT 5005 Version = 1*2(DIGIT) 5006 packagesItem = NAME "-" UINT16 5008 TimeStamp = Date "T" Time ; per ISO 8601:1988 5009 ; Date = yyyymmdd 5010 Date = 8(DIGIT) 5011 ; Time = hhmmssss 5012 Time = 8(DIGIT) 5013 statisticsDescriptor = StatsToken LBRKT statisticsParameter 5014 *(COMMA statisticsParameter ) RBRKT 5016 ;at-most-once per item 5017 statisticsParameter = pkgdName EQUAL VALUE 5019 topologyDescriptor = TopologyToken LBRKT terminationA COMMA 5020 terminationB COMMA topologyDirection RBRKT 5021 terminationA = TerminationID 5022 terminationB = TerminationID 5023 topologyDirection = BothwayToken / IsolateToken / OnewayToken 5025 priority = PriorityToken EQUAL UINT16 5027 extensionParameter = "X" ("-" / "+") 1*6(ALPHA / DIGIT) 5029 ; octetString is used to describe SDP defined in RFC2327. 5030 ; Caution should be taken if CRLF in RFC2327 is used. 5031 ; To be safe, use EOL in this ABNF. 5032 ; Whenever "}" appears in SDP, it is escaped by " 5033 octetString = *(nonEscapeChar) 5035 Internet draft MEGACO Protocol February 21, 2000 5037 nonEscapeChar = ( "" / %x01-7C / %x7E-FF ) 5038 quotedString = DQUOTE 1*(SafeChar / RestChar/ WSP) DQUOTE 5040 UINT16 = 1*5(DIGIT) ; %x0-FFFF 5041 UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF 5043 NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 5044 VALUE = quotedString / 1*(SafeChar) 5045 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / 5046 "!" / "_" / "/" / "'" / "?" / "@" / 5047 "^" / "`" / "~" / "*" / "$" / " 5048 "(" / ")" / "%" / "|" / "." 5050 EQUAL = LWSP %x3D LWSP ; "=" 5051 COLON = %x3A ; ":" 5052 LBRKT = LWSP %x7B LWSP ; "{" 5053 RBRKT = LWSP %x7D LWSP ; "}" 5054 COMMA = LWSP %x2C LWSP ; "," 5055 DOT = %x2E ; "." 5056 SLASH = %x2F ; "/" 5057 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 5058 DIGIT = %x30-39 ; 0-9 5059 DQUOTE = %x22 ; " (Double Quote) 5060 HEXDIG = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" ) 5061 SP = %x20 ; space 5062 HTAB = %x09 ; horizontal tab 5063 CR = %x0D ; Carriage return 5064 LF = %x0A ; linefeed 5065 LWSP = *( WSP / COMMENT / EOL ) 5066 EOL = (CR [LF] / LF ) 5067 WSP = SP / HTAB ; white space 5068 SEP = ( WSP / EOL / COMMENT) LWSP 5069 COMMENT = ";" *(SafeChar/ RestChar / WSP / %x22) EOL 5070 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" / 5071 "<" / ">" / "=" 5073 AddToken = ("Add" / "A") 5074 AuditToken = ("Audit" / "AT") 5075 AuditCapToken = ("AuditCapability" / "AC") 5076 AuditValueToken = ("AuditValue" / "AV") 5077 AuthToken = ("Authentication" / "AU") 5078 BothwayToken = ("Bothway" / "BW") 5079 BriefToken = ("Brief" / "BR") 5080 BufferToken = ("Buffer" / "BF") 5081 CtxToken = ("Context" / "C") 5082 ContextAuditToken = ("ContextAudit" / "CA") 5083 DigitMapToken = ("DigitMap" / "DM") 5085 Internet draft MEGACO Protocol February 21, 2000 5087 DiscardToken = ("Discard" / "DS") 5088 DisconnectedToken = ("Disconnected" / "DC") 5089 DelayToken = ("Delay" / "DL") 5090 DurationToken = ("Duration" / "DR") 5091 EmbedToken = ("Embed" / "EB") 5092 EmergencyToken = ("Emergency" / "EM") 5093 ErrorToken = ("Error" / "ER") 5094 EventBufferToken = ("EventBuffer" / "EB") 5095 EventsToken = ("Events" / "E") 5096 FailoverToken = ("Failover" / "FL") 5097 ForcedToken = ("Forced" / "FO") 5098 GracefulToken = ("Graceful" / "GR") 5099 H221Token = ("H221" ) 5100 H223Token = ("H223" ) 5101 H226Token = ("H226" ) 5102 HandOffToken = ("HandOff" / "HO") 5103 InactiveToken = ("Inactive" / "IN") 5104 IsolateToken = ("Isolate" / "IS") 5105 InSvcToken = ("InService" / "IV") 5106 KeepActiveToken = ("KeepActive" / "KA") 5107 LocalToken = ("Local" / "L") 5108 LocalControlToken = ("LocalControl" / "O") 5109 LockStepToken = ("LockStep" / "SP") 5110 LoopbackToken = ("Loopback" / "LB") 5111 MediaToken = ("Media" / "M") 5112 MegacopToken = ("MEGACO" / "!") 5113 MethodToken = ("Method" / "MT") 5114 MgcIdToken = ("MgcIdToTry" / "MG") 5115 ModeToken = ("Mode" / "MO") 5116 ModifyToken = ("Modify" / "MF") 5117 ModemToken = ("Modem" / "MD") 5118 MoveToken = ("Move" / "MV") 5119 MTPToken = ("MTP") 5120 MuxToken = ("Mux" / "MX") 5121 NotifyToken = ("Notify" / "N") 5122 NotifyCompletionToken = ("NotifyCompletion" / "NC") 5123 ObservedEventsToken = ("ObservedEvents" / "OE") 5124 OnewayToken = ("Oneway" / "OW") 5125 OnOffToken = ("OnOff" / "OO") 5126 OutOfSvcToken = ("OutOfService" / "OS") 5127 PackagesToken = ("Packages" / "PG") 5128 PendingToken = ("Pending" / "PN") 5129 PriorityToken = ("Priority" / "PR") 5130 ProfileToken = ("Profile" / "PF") 5131 ReasonToken = ("Reason" / "RE") 5132 RecvonlyToken = ("ReceiveOnly" / "RC") 5133 ReplyToken = ("Reply" / "P") 5134 RestartToken = ("Restart" / "RS") 5136 Internet draft MEGACO Protocol February 21, 2000 5138 RemoteToken = ("Remote" / "R") 5139 ReservedGroupToken = ("ReservedGroup" / "RG") 5140 ReservedValueToken = ("ReservedValue" / "RV") 5141 SendonlyToken = ("SendOnly" / "SO") 5142 SendrecvToken = ("SendReceive" / "SR") 5143 ServicesToken = ("Services" / "SV") 5144 ServiceStatesToken = ("ServiceStates" / "SI") 5145 ServiceChangeToken = ("ServiceChange" / "SC") 5146 ServiceChangeAddressToken = ("ServiceChangeAddress" / "AD") 5147 SignalListToken = ("SignalList" / "SL") 5148 SignalsToken = ("Signals" / "SG") 5149 SignalTypeToken = ("SignalType" / "SY") 5150 StatsToken = ("Statistics" / "SA") 5151 StreamToken = ("Stream" / "ST") 5152 SubtractToken = ("Subtract" / "S") 5153 SynchISDNToken = ("SynchISDN" / "SN") 5154 TerminationStateToken = ("TerminationState" / "TS") 5155 TestToken = ("Test" / "TE") 5156 TimeOutToken = ("TimeOut" / "TO") 5157 TopologyToken = ("Topology" / "TP") 5158 TransToken = ("Transaction" / "T") 5159 ResponseAckToken = ("TransactionResponseAck"/ "K") 5160 V18Token = ("V18") 5161 V22Token = ("V22") 5162 V22bisToken = ("V22b") 5163 V32Token = ("V32") 5164 V32bisToken = ("V32b") 5165 V34Token = ("V34") 5166 V76Token = ("V76") 5167 V90Token = ("V90") 5168 V91Token = ("V91") 5170 ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE) 5172 Parameters for Local descriptors and Remote descriptors are specified as 5173 tag-value pairs if binary encoding is used for the protocol. This annex 5174 contains the property names (PropertyID), the tags (Property Tag), type 5175 of the property (Type) and the values (Value).Values presented in the 5176 Value field when the field contains references shall be regarded as 5177 "information". The reference contains the normative values. If a value 5178 field does not contain a reference then the values in that field can be 5179 considered as "normative". 5181 Tags are given as hexadecimal numbers in this annex. When setting the 5182 value of a property, a MGC may underspecify the value according to one 5184 Internet draft MEGACO Protocol February 21, 2000 5186 of the mechanisms specified in section 7.1.1. 5188 For type "enumeration" the value is represented by the value in brack- 5189 ets, e.g., Send(0), Receive(1). 5191 C.1. General Media Attributes 5193 ________________________________________________________________________ 5194 |PropertyID | Tag | Type | Value | 5195 |Media |1001 |Enumeration|Audio(0), Video(1) ,Data(2), | 5196 |TransMode |1002 |Enumeration|Send(0), Receive(1), Send&Receive(2) | 5197 |NumChan |1003 |UINT | 0-255 | 5198 |SamplingRate |1004 |UINT | 0-2^32 | 5199 |Bitrate |1005 |Integer |(0..4294967295) Note-units of 100 bit | 5200 |Acodec |1006 |Octet str |Audio Codec Type | 5201 |Samplepp |1007 |UINT |Maximum samples/fr per packet:0-65535 | 5202 |Silencesupp |1008 |BOOLEAN |Silence Suppression | 5203 |Encrypttype |1009 |Octet str |Ref.: rec. H.245 | 5204 |Encryptkey |100A |Octet str |SIZE(0..65535) Encryption key | 5205 |Echocanc |100B |Enumeration|Echo Canceller:Off(0),G.165(1),G168(2)| 5206 |Gain |100C |UINT |Gain in db: 0-65535 | 5207 |Jitterbuff |100D |UINT |Jitter buffer size in ms: 0-65535 | 5208 |PropDelay |100E |UINT | Propagation Delay: 0..65535 | 5209 |RTPpayload |100F |integer |Payload type in RTP Profile | 5210 |_____________|_____|___________|______________________________________| 5212 C.2. Mux Properties 5214 _________________________________________________________________________ 5215 |PropertyID| Tag | Type | Value | 5216 |H.221 | 2001 | Octet string| H222LogicalChannelParameters | 5217 |H223 | 2002 | Octet string| H223LogicalChannelParameters | 5218 |V76 | 2003 | Octet String| V76LogicalChannelParameters | 5219 |H2250 | 2004 | Octet String| H2250LogicalChannelParameters| 5220 |__________|____________|______________|________________________________| 5222 C.3. General Bearer Properties 5224 _____________________________________________________________________ 5225 | PropertyID| Tag | Type | Value | 5226 | Mediatx | 3001 | Enumeration| Media Transport Type | 5227 | BIR | 3002 | 4 OCTET | Value depends on transport | 5228 | NSAP | 3003 | 1-20 OCTETS| Ref: ITU X.213 Annex A | 5229 |___________|____________|_____________|_____________________________| 5231 Internet draft MEGACO Protocol February 21, 2000 5233 C.4. General ATM Properties 5235 _________________________________________________________________ 5236 | PropertyID| Tag | Type | Value | 5237 | AESA | 4001| 20 OCTETS | ATM End System Address | 5238 | VPVC | 4002| 2x16b int | VPC-VCI | 5239 | SC | 4003| 4 bits | Service Category | 5240 | BCOB | 4004| 5b integer | Broadband Bearer Class | 5241 | BBTC | 4005| octet | Broadband Transfer Capability| 5242 | ATC | 4006| Enumeration| I.371 ATM Traffic Cap. | 5243 | STC | 4007| 2 bits | Susceptibility to clipping | 5244 | UPCC | 4008| 2 bits | User Plane Connection config | 5245 | PCR0 | 4009| 24b integer| Peak Cell Rate CLP=0 | 5246 | SCR0 | 400A| 24b integer| Sustainable Cell Rate CLP=0 | 5247 | MBS0 | 400B| 24b integer| Maximum Burst Size CLP=0 | 5248 | PCR1 | 400C| 24b integer| Peak Cell Rate CLP=0+1 | 5249 | SCR2 | 400D| 24b integer| Sustain. Cell Rate CLP=0+1 | 5250 | MBS3 | 400E| 24b integer| Maximum Burst Size CLP=0+1 | 5251 | BEI | 400F| Boolean | Best Effort Indicator | 5252 | TI | 4010| Boolean | Tagging | 5253 | FD | 4011| Boolean | Frame Discard | 5254 | FCDV | 4012| 24b integer| Forward P-P CDV | 5255 | BCDV | 4013| 24b integer| Backward P-P CDV | 5256 | FCLR0 | 4014| 8b integer | Fwd Cell Loss Ratio CLP=0 | 5257 | BCLR0 | 4015| 8b integer | Bkwd P-P CLR CLP=0 | 5258 | FCLR1 | 4016| 8b integer | Fwd Cell Loss Ratio CLP=0+1 | 5259 | BCLR1 | 4017| 8b integer | Bkwd P-P CLR CLP=0+1 | 5260 | FCDV | 4018| 24b integer| Fwd Cell Delay Variation | 5261 | BCDV | 4019| 24b integer| Bkwd Cell Delay Variation | 5262 | FACDV | 401A| 24b integer| Fwd Acceptable P-P-P CDV | 5263 | BACDV | 401B| 24b integer| Bkwd Acceptable P-P CDV | 5264 | FCCDV | 401C| 24b integer| Fwd Cumulative P-P CDV | 5265 | BCCDV | 401D| 24b integer| Bkwd Cumulative P-P CDV | 5266 | FCLR | 401E| 8b integer | Acceptable Fwd CLR | 5267 | BCLR | 401F| 8b integer | Acceptable Bkwd CLR | 5268 | EETD | 4020| 16b integer| End-to-end transit delay | 5269 | Mediatx | 4021| | AAL Type | 5270 | QosClass | 4022| Integer | 0-4 Qos Class | 5271 | AALtype | 4023| 1 OCTET | AAL Type Reference | 5272 |___________|______|_____________|_______________________________| 5274 C.5. Frame Relay 5276 Internet draft MEGACO Protocol February 21, 2000 5278 ______________________________________________________________________ 5279 | PropertyID| Tag | Type | Value | 5280 | DLCI | 5001| Unsigned Integer| Data link connection id | 5281 | CID | 5002| Unsigned Integer| sub-channel id. | 5282 | SID | 5003| Unsigned Integer| silence insertion descriptor | 5283 | Payload | 5004| Unsigned Integer| Primary Payload Type | 5284 |___________|______|__________________|_______________________________| 5286 C.6. IP 5288 ________________________________________________________________ 5289 | PropertyID| Tag | Type | Value | 5290 | IPv4 | 6001 | 32 BITS | Ipv4Address | 5291 | IPv6 | 6002 | 128 BITS | IPv6 Address | 5292 | Port | 6003 | Unsigned Int| Port | 5293 | Porttype | 6004 | Enumerated | TCP(0),UDP(1),SCTP(2)| 5294 | UDP | 6004 | Boolean | | 5295 |___________|____________|______________|_______________________| 5297 C.7. ATM AAL2 5299 _______________________________________________________________________________ 5300 |PropertyID| Tag | Type | Value | 5301 |AESA | 7001 | 20 OCTETS | AAL2 service endpoint address | 5302 |BIR | See C.3| 4 OCTETS | Served user generated reference | 5303 |ALC | 7002 | 12 OCTETS | AAL2 link | 5304 |SSCS | 7003 | 8..14 OCTETS | Service specific convergence sublayer | 5305 |SUT | 7004 | 1..254 octets| Served user transport param | 5306 |TCI | 7005 | BOOLEAN | Test connection | 5307 |Timer_CU | 7006 | 32b integer | Timer-CU | 5308 |MaxCPSSDU | 7007 | 8b integer | Max. Common Part Sublayer SDU | 5309 |SCLP | 7008 | Boolean | Set Cell Local PriorityLP bit | 5310 |EETR | 7009 | Boolean | End to End Timing Required | 5311 |CID | 700A | 8 bits | subchannel id | 5312 |__________|_________|_______________|________________________________________| 5314 C.8. ATM AAL1 5316 Internet draft MEGACO Protocol February 21, 2000 5318 ________________________________________________________________________________ 5319 |PropertyID| Tag | Type | Value | 5320 |BIR | See Table C.3| 4 OCTETS | GIT(Generic Identifier Transport)| 5321 |AAL1ST | 8001 | 1 OCTET | AAL1 Subtype: | 5322 |8002 | 1 OCTET | CBR Rate | | 5323 |SCRI | 8003 | 1 OCTET | Source Clock Frequency Recovery | 5324 |ECM | 8004 | 1 OCTET | Error Correction Method | 5325 |SDTB | 8005 | 16b integer | Structured Data Transfer Blcksize| 5326 |PFCI | 8006 | 8b integer | Partially filled cells identifier| 5327 |EETR | See Table C.7| See Table C.7| | 5328 |__________|_______________|_______________|___________________________________| 5330 C.9. Bearer Capabilities 5332 Internet draft MEGACO Protocol February 21, 2000 5334 ________________________________________________________________________ 5335 |PropertyID | Tag | Type | Value | 5336 |TMR | 9001| 1 OCTET | Transmission Medium Requirement | 5337 |TMRSR | 9002| 1 OCTET | Trans. Medium Requirement Subrate| 5338 |Contcheck | 9003| BOOLEAN | Continuity Check | 5339 |ITC | 9004| 5 BITS | Information Transfer Capability | 5340 |TransMode | 9005| 2 BITS | Transfer Mode | 5341 |TransRate | 9006| 5 BITS | Transfer Rate | 5342 |MULT | 9007| 7 BITS | Rate Multiplier | 5343 |USI | 9008| 5 BITS | User Information Layer 1 Protocol| 5344 |Syncasync | 9009| BOOLEAN | Synchronous-Asynchronous | 5345 |Userrate | 900B| 5 BITS | User Rate Reference | 5346 |INTRATE | 900C| 2 BITS | Intermediate Rate | 5347 |Nictx | 900D| BOOLEAN | Tx Network Independent Clock | 5348 |Nicrx | 900E| BOOLEAN | Rx Network independent clock | 5349 |Flowconttx | 900F| BOOLEAN | Tx Flow Control | 5350 |Flowcontrx | 9010| BOOLEAN | Rx Flow control | 5351 |Rateadapthdr | 9011| BOOLEAN | Rate adapt header-no header | 5352 |Multiframe | 9012| BOOLEAN | Multiple frame estab. | 5353 |OPMODE | 9013| BOOLEAN | Mode of operation | 5354 |Llidnegot | 9014| BOOLEAN | Logical link identifier neg. | 5355 |Assign | 9015| BOOLEAN | Assignor-assignee | 5356 |Inbandneg | 9016| BOOLEAN | In-band or out-band negotiation | 5357 |Stopbits | 9017| 2 BITS | Number of stop bits | 5358 |Databits | 9018| 2 BIT | Number of data bits | 5359 |Parity | 9019| 3 BIT | Parity information | 5360 |Duplexmode | 901A| BOOLEAN | Mode duplex | 5361 |Modem | 901B| 6 BIT | Modem Type | 5362 |layer2prot | 901C| 5 BIT | User info layer 2 protocol | 5363 |layer3prot | 901D| 5 BIT | User info layer 3 protocol | 5364 |addlayer3prot| 901E| OCTET | Addl User Info L3 protocol | 5365 |DialledN | 901F| 30 OCTETS | Dialled Number | 5366 |DiallingN | 9020| 30 OCTETS | Dialling Number | 5367 |ECHOCI | 9021| Enumeration| Echo Control Information | 5368 |NCI | 9022| 1 OCTET | Nature of Connection Indicators | 5369 |_____________|______|_____________|___________________________________| 5371 C.10. AAL5 Properties 5373 ______________________________________________________________________ 5374 | PropertyID| Tag | Type | Value | 5375 | FMSDU | A001 | 32b integer| Forward Maximum CPCS-SDU Size: | 5376 | BMSDU | A002 | 2b integer | Backwards Maximum CPCS-SDU Size| 5377 | SSCS | See C.7| See C.7 | See table C. | 5378 | SC | See C.4| See C.4 | See table C.4 | 5379 |___________|_________|_____________|_________________________________| 5381 Internet draft MEGACO Protocol February 21, 2000 5383 C.11. SDP Equivalents 5385 ______________________________________________________________ 5386 | PropertyID| Tag | Type | Value | 5387 | SDP_V | B001| STRING| Protocol Version | 5388 | SDP_O | B002| STRING| Owner-creator and session ID | 5389 | SDP_S | B003| STRING| Sesson name | 5390 | SDP_I | B004| STRING| Session identifier | 5391 | SDP_U | B005| STRING| URI of descriptor | 5392 | SDC_E | B006| STRING| email address | 5393 | SDP_P | B007| STRING| phone number | 5394 | SDP_C | B008| STRING| Connection information | 5395 | SDP_B | B009| STRING| Bandwidth Information | 5396 | SDP_Z | B00A| STRING| time zone adjustment | 5397 | SDP_K | B00B| STRING| Encryption Key | 5398 | SDP_A | B00C| STRING| Zero or more session attributes| 5399 | SDP_T | B00D| STRING| Active Session Time | 5400 | SDP_R | B00E| STRING| Zero or more repeat times | 5401 |___________|______|________|_________________________________| 5403 C.12. H.245 5405 ________________________________________________________________________ 5406 |OLC | C001| octet string| H.245 OpenLogicalChannel structure. | 5407 |OLCack| C002| octet string| H.245 OpenLogicalChannelAck structure.| 5408 |OLCcnf| C003| octet string| OpenLogicalChannelConfirm structure. | 5409 |OLCrej| C004| octet string| OpenLogicalChannelReject structure. | 5410 |CLC | C005| octet string| CloseLogicalChannel structure. | 5411 |CLCack| C006| octet string| CloseLogicalChannelAck structure. | 5412 |______|______|______________|_________________________________________| 5414 ANNEX D TRANSPORT OVER IP (NORMATIVE) 5416 D.1. Transport over IP/UDP using Application Level Framing 5418 Protocol messages defined in this document may be transmitted over UDP. 5419 When no port is provided by the peer (see section 7.2.8), commands 5420 should be sent to the default port number, 2944 for text-encoded opera- 5421 tion or 2945 for binary-encoded operation. Responses must be sent to 5422 the address and port from which the corresponding commands were sent 5423 except if the response is to a handoff or failover, in which case the 5424 procedures of 11.5 apply. 5426 Implementors using IP/UDP with ALF should be aware of the restrictions 5427 of the MTU on the maximum message size. 5429 Internet draft MEGACO Protocol February 21, 2000 5431 D.1.1. Providing At-Most-Once Functionality 5433 Messages, being carried over UDP, may be subject to losses. In the 5434 absence of a timely response, commands are repeated. Most commands are 5435 not idempotent. The state of the MG would become unpredictable if, for 5436 example, Add commands were executed several times. The transmission 5437 procedures shall thus provide an "At- Most-Once" functionality. 5439 Peer protocol entities are expected to keep in memory a list of the 5440 responses that they sent to recent transactions and a list of the tran- 5441 sactions that are currently outstanding. The transaction identifier of 5442 each incoming message is compared to the transaction identifiers of the 5443 recent responses sent to the same MId. If a match is found, the entity 5444 does not execute the transaction, but simply repeats the response. If no 5445 match is found, the message will be compared to the list of currently 5446 outstanding transactions. If a match is found in that list, indicating a 5447 duplicate transaction, the entity does not execute the transaction (see 5448 section 8.2.3 for procedures on sending TransactionPending). 5450 The procedure uses a long timer value, noted LONG-TIMER in the follow- 5451 ing. The timer should be set larger than the maximum duration of a 5452 transaction, which should take into account the maximum number of 5453 repetitions, the maximum value of the repetition timer and the maximum 5454 propagation delay of a packet in the network. A suggested value is 30 5455 seconds. 5457 The copy of the responses may be destroyed either LONG-TIMER seconds 5458 after the response is issued, or when the entity receives a confirmation 5459 that the response has been received, through the "Response Acknowledge- 5460 ment parameter". For transactions that are acknowledged through this 5461 parameter, the entity shall keep a copy of the transaction-id for LONG- 5462 TIMER seconds after the response is issued, in order to detect and 5463 ignore duplicate copies of the transaction request that could be pro- 5464 duced by the network. 5466 D.1.2. Transaction identifiers and three-way handshake 5468 D.1.2.1. Transaction identifiers 5470 Transaction identifiers are 32 bit integer numbers. A Media Gateway 5471 Controller may decide to use a specific number space for each of the MGs 5472 that they manage, or to use the same number space for all MGs that 5473 belong to some arbitrary group. MGCs may decide to share the load of 5474 managing a large MG between several independent processes. These 5475 processes will share the same transaction number space. There are mul- 5476 tiple possible implementations of this sharing, such as having a cen- 5477 tralized allocation of transaction identifiers, or pre-allocating non- 5478 overlapping ranges of identifiers to different processes. The 5480 Internet draft MEGACO Protocol February 21, 2000 5482 implementations shall guarantee that unique transaction identifiers are 5483 allocated to all transactions that originate from a logical MGC (identi- 5484 cal mId). MGs can simply detect duplicate transactions by looking at the 5485 transaction identifier and mId only. 5487 D.1.2.2. Three-way handshake 5489 The TransactionResponse Acknowledgement parameter can be found in any 5490 message. It carries a set of "confirmed transaction-id ranges". Entities 5491 may choose to delete the copies of the responses to transactions whose 5492 id is included in "confirmed transaction-id ranges" received in the 5493 transaction response messages. They should silently discard further com- 5494 mands when the transaction-id falls within these ranges. 5496 The "confirmed transaction-id ranges" values shall not be used if more 5497 than LONG-TIMER seconds have elapsed since the MG issued its last 5498 response to that MGC, or when a MG resumes operation. In this situa- 5499 tion, transactions should be accepted and processed, without any test on 5500 the transaction-id. 5502 Messages that carry the "Transaction Response Acknowledgement" parameter 5503 may be transmitted in any order. The entity shall retain the "confirmed 5504 transaction-id ranges" receivedfor LONG-TIMER seconds. 5506 In the binary encoding, if only the firstAck is present in a response 5507 acknowledgement (see Annex A.2), only one transaction is acknowledged. 5508 If both firstAck and lastAck are present, then the range of transactions 5509 from firstAck to lastAck is acknowledged. In the text encoding, a hor- 5510 izontal dash is used to indicate a range of transactions being ack- 5511 nowledged (see Annex B.2). 5513 D.1.3. Computing retransmission timers 5515 It is the responsibility of the requesting entity to provide suitable 5516 time outs for all outstanding transactions, and to retry transactions 5517 when time outs have been exceeded. Furthermore, when repeated transac- 5518 tions fail to be acknowledged, it is the responsibility of the request- 5519 ing entity to seek redundant services and/or clear existing or pending 5520 connections. 5522 The specification purposely avoids specifying any value for the 5523 retransmission timers. These values are typically network dependent. The 5524 retransmission timers should normally estimate the timer value by 5525 measuring the time spent between the sending of a command and the return 5526 of a response. 5528 Note - One possibility is to use the algorithm implemented in TCP-IP, 5529 which uses two variables: 5531 Internet draft MEGACO Protocol February 21, 2000 5533 * The average acknowledgement delay, AAD, estimated through an 5534 exponentially smoothed average of the observed delays. 5536 * The average deviation, ADEV, estimated through an exponentially 5537 smoothed average of the absolute value of the difference between 5538 the observed delay and the current average. The retransmission 5539 timer, in TCP, is set to the sum of the average delay plus N times 5540 the average deviation. The maximum value of the timer should how- 5541 ever be bounded for the protocol defined in this document, in order 5542 to guarantee that no repeated packet would be received by the gate- 5543 ways after LONG-TIMER seconds. A suggested maximum value is 4 5544 seconds. 5546 After any retransmission, the entity should do the following: 5548 * It should double the estimated value of the average delay, AAD 5550 * It should compute a random value, uniformly distributed between 0.5 5551 AAD and AAD 5553 * It should set the retransmission timer to the sum of that random 5554 value and N times the average deviation. 5556 This procedure has two effects. Because it includes an exponentially 5557 increasing component, it will automatically slow down the stream of mes- 5558 sages in case of congestion. Because it includes a random component, it 5559 will break the potential synchronization between notifications triggered 5560 by the same external event. 5562 D.1.4. Provisional responses 5564 Executing some transactions may require a long time. Long execution 5565 times may interact with the timer based retransmission procedure. This 5566 may result either in an inordinate number of retransmissions, or in 5567 timer values that become too long to be efficient. Entities that can 5568 predict that a transaction will require a long execution time may send a 5569 provisional response, "Transaction Pending". 5571 Entities that receive a Transaction Pending shall switch to a different 5572 repetition timer for repeating requests. The root termination has a 5573 property (ProvisionalResponseTimerValue), which can be set to the 5574 requested maximum number of milliseconds between receipt of a command 5575 and transmission of the TransactionPending response. Upon receipt of a 5576 final response, an immediate confirmation shall be sent, and normal 5577 repetition timers shall be used thereafter. Receipt of a Transaction 5578 Pending after receipt of a reply shall be ignored. 5580 Internet draft MEGACO Protocol February 21, 2000 5582 D.1.5. Repeating Requests, Responses and Acknowledgements 5584 The protocol is organized as a set of transactions, each of which is 5585 composed request and a response, commonly referred to as an acknowledge- 5586 ment. The protocol messages, being carried over UDP, may be subject to 5587 losses. In the absence of a timely response, transactions are repeated. 5588 Entities are expected to keep in memory a list of the responses that 5589 they sent to recent transactions, i.e. a list of all the responses they 5590 sent over the last LONG-TIMER seconds, and a list of the transactions 5591 that are currently being executed. 5593 The repetition mechanism is used to guard against three types of possi- 5594 ble errors: 5596 * transmission errors, when for example a packet is lost due to noise 5597 on a line or congestion in a queue; 5599 * component failure, when for example an interface to a entity 5600 becomes unavailable; 5602 * entity failure, when for example an entire entity become unavail- 5603 able. 5605 The entities should be able to derive from the past history an estimate 5606 of the packet loss rate due to transmission errors. In a properly con- 5607 figured system, this loss rate should be kept very low, typically less 5608 than 1%. If a Media Gateway Controller or a Media Gateway has to repeat 5609 a message more than a few times, it is very legitimate to assume that 5610 something else than a transmission error is occurring. For example, 5611 given a loss rate of 1%, the probability that five consecutive transmis- 5612 sion attempts fail is 1 in 100 billion, an event that should occur less 5613 than once every 10 days for a Media Gateway Controller that processes 1 5614 000 transactions per second. (Indeed, the number of repetition that is 5615 considered excessive should be a function of the prevailing packet loss 5616 rate.) We should note that the "suspicion threshold", which we will call 5617 "Max1", is normally lower than the "disconnection threshold", which 5618 should be set to a larger value. 5620 A classic retransmission algorithm would simply count the number of suc- 5621 cessive repetitions, and conclude that the association is broken after 5622 retransmitting the packet an excessive number of times (typically 5623 between 7 and 11 times.) In order to account for the possibility of an 5624 undetected or in-progress "failover", we modify the classic algorithm so 5625 that if the Media Gateway receives a valid ServiceChange message 5626 announcing a failover, it will start transmitting outstanding commands 5627 to that new MGC. Responses to commands are still transmitted to the 5628 source address of the command. 5630 Internet draft MEGACO Protocol February 21, 2000 5632 In order to automatically adapt to network load, this document specifies 5633 exponentially increasing timers. If the initial timer is set to 200 5634 milliseconds, the loss of a fifth retransmission will be detected after 5635 about 6 seconds. This is probably an acceptable waiting delay to detect 5636 a failover. The repetitions should continue after that delay not only in 5637 order to perhaps overcome a transient connectivity problem, but also in 5638 order to allow some more time for the execution of a failover - waiting 5639 a total delay of 30 seconds is probably acceptable. 5641 It is, however, important that the maximum delay of retransmissions be 5642 bounded. Prior to any retransmission, it is checked that the time 5643 elapsed since the sending of the initial datagram is no greater than T- 5644 MAX. If more than T-MAX time has elapsed, the MG concludes that the MGC 5645 has failed, and it begins its recovery process. When the MG establishes 5646 a new control association, it can retransmit to the new MGC. Alterna- 5647 tively, a MG may use a ServiceChange with ServiceChangeMethod equal to 5648 disconnected to inform the new MGC that the MG lost one or more transac- 5649 tions. The value T-MAX is related to the LONG-TIMER value: the LONG- 5650 TIMER value is obtained by adding to T-MAX the maximum propagation delay 5651 in the network. 5653 D.2. using TCP 5655 Protocol messages as defined in this document may be transmitted over 5656 TCP. When no port is specified by the other side (see section 7.2.8), 5657 the commands should be sent to the default port. The defined protocol 5658 has messages as the unit of transfer, while TCP is a stream-oriented 5659 protocol. TPKT, according to RFC1006 SHALL be used to delineate mes- 5660 sages within the TCP stream. 5662 In a transaction-oriented protocol, there are still ways for transaction 5663 requests or responses to be lost. As such, it is recommended that enti- 5664 ties using TCP transport implement application level timers for each 5665 request and each response, similar to those specified for application 5666 level framing over UDP. 5668 D.2.1. Providing the At-Most-Once functionality 5670 Messages, being carried over TCP, are not subject to transport losses, 5671 but loss of a transaction request or its reply may nonetheless be noted 5672 in real implementations. In the absence of a timely response, commands 5673 are repeated. Most commands are not idempotent. The state of the MG 5674 would become unpredictable if, for example, Add commands were executed 5675 several times. 5677 To guard against such losses, it is recommended that entities follow the 5678 procedures in section D.1.1 5680 Internet draft MEGACO Protocol February 21, 2000 5682 D.2.2. Transaction identifiers and three way handshake 5684 For the same reasons, it is possible that transaction replies may be 5685 lost even with a reliable delivery protocol such as TCP. It is recom- 5686 mended that entities follow the procedures in section D.1.2.2. 5688 D.2.3. Computing retransmission timers 5690 With reliable delivery, the incidence of loss of a transaction request 5691 or reply is expected to be very low. Therefore, only simple timer 5692 mechanisms are required. Exponential back-off algorithms should not be 5693 necessary, although they could be employed where, as in an MGC, the code 5694 to do so is already required, since MGCs must implement ALF/UDP as well 5695 as TCP. 5697 D.2.4. Provisional responses 5699 As with UDP, executing some transactions may require a long time. Enti- 5700 ties that can predict that a transaction will require a long execution 5701 time may send a provisional response, "Transaction Pending". They should 5702 send this response if they receive a repetition of a transaction that is 5703 still being executed. 5705 Entities that receive a Transaction Pending shall switch to a longer 5706 repetition timer for that transaction. 5708 Entities shall retain Transactions and replies until they are confirmed. 5709 The basic procedure of section D.1.4 should be followed, but simple 5710 timer values should be sufficient. There is no need to send an immediate 5711 confirmation upon receipt of a final response. 5713 D.2.5. Ordering of commands 5715 TCP provides ordered delivery of transactions. No special procedures 5716 are required. It should be noted that ALF/UDP allows sending entity to 5717 modify its behavior under congestion, and in particular, could reorder 5718 transactions when congestion is encountered. TCP could not achieve the 5719 same results. 5721 ANNEX E BASIC PACKAGES 5723 This Annex contains definitions of some packages for use with MEGACO. 5725 E.1. Generic 5727 PackageID: g (0x000e) 5728 Version: 1 5729 Extends: None 5731 Internet draft MEGACO Protocol February 21, 2000 5733 Description: 5734 Generic package for commonly encountered items 5736 E.1.1. Properties 5738 None 5740 E.1.2. Events 5742 Cause 5743 EventID: cause (0x0001) 5744 Generic error event 5745 Event Descriptor Parameters: 5746 General Cause 5747 ParameterID: Generalcause (0x0001) 5748 This parameter groups the failures into six groups, 5749 which the MGC may act upon. 5750 Possible values: Enumerated, 5751 "NR" Normal Release (0x0001) 5752 "UR" Unavailable Resources (0x0002) 5753 "FT" Failure, Temporary (0x0003) 5754 "FP" Failure, Permanent (0x0004) 5755 "IW" Interworking Error (0x0005) 5756 "UN" Unsupported (0x0006) 5757 Failure Cause 5758 ParameterID: Failurecause (0x0002) 5759 Possible Values: OCTET STRING 5760 Description: The Release Cause is the value generated 5761 by the Released equipment, i.e. a released network 5762 connection. The concerned value is defined in the 5763 appropriate bearer control protocol. 5764 Signal Completion 5765 EventID: sc (0x0002) 5766 Indicates termination of one or more signals for which the 5767 notifyCompletion parameter was set to "ON". For further 5768 procedural description, see sections 7.1.11, 7.1.17, and 7.2.7. 5770 ObservedEvents Descriptor parameters: 5771 Signal Identity 5772 ParameterID: SigID (0x0001) 5773 This parameter identifies the signals which have terminated. 5774 Type: list 5775 Possible values: a list of signals and/or sequential 5776 signal lists which have terminated. A signal outside 5777 of a sequential signal list shall be identified using 5778 the pkgdName syntax without wildcarding. An 5779 individual signal inside of a sequential signal list 5781 Internet draft MEGACO Protocol February 21, 2000 5783 shall be identified using the sequential signal list 5784 syntax with the correct signal list identifier, 5785 enclosing the name of the specific signal which 5786 terminated in pkgdName syntax. 5788 Termination Method 5789 ParameterID: Meth (0x0002) 5790 Indicates the means by which the signal terminated. 5791 Type: enumeration 5792 Possible values: 5793 "TO" (0x0001) Duration expired 5794 "EV" (0x0002) Interrupted by event 5795 "SD" (0x0003) Halted by new Signals Descriptor 5796 "NC" (0x0004) Not completed, other cause 5798 Internet draft MEGACO Protocol February 21, 2000 5800 E.1.3. Signals 5802 None 5804 E.1.4. Statistics 5806 None 5808 E.2. Base Root Package 5810 Base Root Package 5812 PackageID: root (0x000f) 5813 Version: 1 5814 Extends: None 5815 Description: 5816 This package defines Gateway wide properties. 5818 E.2.1. Properties 5820 MaxNrOfContexts 5821 PropertyID: maxNumberOfContexts (0x0001) 5822 The value of this property gives the maximum number of 5823 contexts that can exist at any time. The NULL context 5824 is not included in this number. 5825 Type: Double 5826 Possible values: 1 and up 5827 MaxTerminationsPerContext 5828 PropertyID: maxTerminationsPerContext (0x0002) 5829 The maximum number of allowed terminations in a context, 5830 see section 6.1 5831 Type: Integer 5832 Possible Values: any integer 5833 Defined In: TerminationState 5834 normalMGExecutionTime 5835 PropertyId: normalMGExecutionTime (0x0003) 5836 Settable by the MGC to indicate the interval within which 5837 the MGC expects a response to any transaction from 5838 the MG (exclusive of network delay) 5839 Type: Integer 5840 Possible Values: any integer, represents milliseconds 5841 normalMGCExecutionTime 5842 PropertyId: normalMGCExecutionTime (0x0004) 5843 Settable by the MGC to indicate the interval within which 5844 the MG should expects a response to any transaction 5845 from the MGC (exclusive of network delay) 5847 Internet draft MEGACO Protocol February 21, 2000 5849 Type: Integer 5850 Possible Values: any integer, represents milliseconds 5851 ProvisionalResponseTimerValue 5852 PropertyId: ProvisionalResponseTimerValue (0x0005) 5853 Indicates the time within which to expect a Pending 5854 Response if a Transaction cannot be completed. 5855 Initially set to normalMGExecutionTime or 5856 normalMGCExecutionTime as appropriate, plus network 5857 delay, but may be lowered. 5859 E.2.2. Events 5861 None 5863 E.2.3. Signals 5865 None 5867 E.2.4. Statistics 5869 None 5871 E.2.5. Procedures 5873 None 5875 E.3. Tone Generator Package 5877 PackageID: tonegen (0x0001) 5878 Version: 1 5879 Extends: None 5880 Description: 5881 This package defines signals to generate audio tones. 5882 This package does not specify parameter values. It is 5883 intended to be extendable. Generally, tones are defined 5884 as an individual signal with a parameter, ind, 5885 representing "interdigit" time delay, and a tone id to 5886 be used with playtones. A tone id should be kept 5887 consistent with any tone generation for the same tone. 5888 MGs are expected to be provisioned with the characteristics 5889 of appropriate tones for the country in which the MG is located. 5891 E.3.1. Properties 5893 None 5895 Internet draft MEGACO Protocol February 21, 2000 5897 E.3.2. Events 5899 None 5901 E.3.3. Signals 5903 Play tone 5905 SignalID: pt (0x0001) 5906 Plays audio tone over an audio channel 5907 Signal Type: Brief 5908 Duration: Provisioned 5909 Additional Parameters: 5910 Tone id list 5911 ParameterID: tl (0x0001) 5912 Type: list of tone ids. 5913 List of tones to be played in sequence. 5914 The list SHALL contain one or more tone ids. 5915 Inter signal duration 5916 ParameterID: ind (0x0002) 5917 Type: integer. 5918 Timeout between two consecutive tones in milliseconds 5920 No tone ids are specified in this package. Packages that extend this 5921 package can add possible values for tone id as well as adding individual 5922 tone signals 5924 E.3.4. Statistics 5926 None 5928 E.3.5. Procedures 5930 None 5932 E.4. Tone Detection Package 5934 PackageID: tonedet (0x0002) 5935 Version: 1 5936 Extends: None 5937 This Package defines events for audio tone detection. 5938 Tones are selected by name (tone id). MGs are expected 5939 to be provisioned with the characteristics of appropriate 5940 tones for the country in which the MG is located. 5942 This package does not specify parameter values. It is intended to be 5944 Internet draft MEGACO Protocol February 21, 2000 5946 extendable. 5948 E.4.1. Properties 5950 None 5952 E.4.2. Events 5954 Start tone detected 5955 EventID: std, 0x0001 5956 Detects the start of a tone. The characteristics of positive 5957 tone detection is implementation dependent. 5958 EventsDescriptor parameters: 5959 Tone id list 5960 ParameterID: tl (0x0001) 5961 Type: list of tone ids 5962 Possible values: The only tone id defined in this 5963 package is "wild card" which is "*" in 5964 text encoding and 0x0000 in binary. 5965 Extensions to this package would add 5966 possible values for tone id. 5967 If tl is "wild card", any tone id is detected 5968 ObservedEventsDescriptor parameters: 5969 Tone id 5970 ParameterID: tid (0x0003) 5971 Type: Enumeration 5972 Possible values: "wildcard" as defined above is the 5973 only value defined in this package. Extensions 5974 to this package would add additional possible 5975 values for tone id 5976 End tone detected 5977 EventID: etd, 0x0002 5978 Detects the end of a tone. 5979 EventDescriptor parameters: 5980 Tone id list 5981 ParameterID: tl (0x0001) 5982 Type: enumeration or list of enumerated types 5983 Possible values: No possible values are specified 5984 in this package. Extensions to this package 5985 would add possible values for tone id 5986 ObservedEventsDescriptor parameters: 5987 Tone id 5988 ParameterID: tid (0x0003) 5989 Type: Enumeration 5990 Possible values: "wildcard" as defined above is the 5991 only value defined in this package. 5992 Extensions to this package would add possible 5993 values for tone id 5995 Internet draft MEGACO Protocol February 21, 2000 5997 Duration 5998 ParameterId: dur (0x0002) 5999 Type: integer, in milliseconds 6000 This parameter contains the duration of the tone 6001 from first detection until it stopped. 6002 Long tone detected 6003 EventID: ltd, 0x0003 6004 Detects that a tone has been playing for at least a certain 6005 amount of time 6006 EventDescriptor parameters: 6007 Tone id list 6008 ParameterID: tl (0x0001) 6009 Type: enumeration or list 6010 Possible values: "wildcard" as defined above is the 6011 only value defined in this package. Extensions 6012 to this package would add possible values for 6013 tone id 6014 Duration: 6015 ParameterID: dur (0x0002) 6016 Type: integer, duration to test against 6017 Possible values: any legal integer, expressed in 6018 milliseconds 6019 ObservedEventsDescriptor parameters: 6020 Tone id: 6021 ParameterID: tid (0x0003) 6022 Possible values: No possible values are specified 6023 in this package. Extensions to this package 6024 would add possible values for tone id 6026 E.4.3. Signals 6028 None 6030 E.4.4. Statistics 6032 None 6034 E.4.5. Procedures 6036 None 6038 E.5. Basic DTMF Generator Package 6040 PackageID: dg (0x0003) 6041 Version: 1 6042 Extends: tonegen version 1 6043 This package defines the basic DTMF tones as signals and 6045 Internet draft MEGACO Protocol February 21, 2000 6047 extends the allowed values of parameter tl of playtone 6048 in tonegen. 6050 E.5.1. Properties 6052 None 6054 E.5.2. Events 6056 None 6058 E.5.3. Signals 6060 dtmf character 0 6061 SignalID: d0 (0x0010) 6062 Generate DTMF 0 tone. The physical characteristic of DTMF 0 6063 is defined in the gateway. 6064 Signal Type: Brief 6065 Duration: Provisioned 6066 Additional Parameters: 6067 None 6068 Additional Values: 6069 d0 (0x0010) is defined as a toneid for playtone 6071 The other dtmf characters are specified in exactly the same way. A 6072 table with all signal names and signal IDs is included. Note that each 6073 dtmf character is defined as both a signal and a toneid, thus extending 6074 the basic tone generation package. Also note that dtmf SignalIds are 6075 different from the names used in a digit map. 6077 ________________________________ 6078 Signal Name Signal ID 6079 dtmf character 0 d1 (0x0010) 6080 dtmf character 1 d1 (0x0011) 6081 dtmf character 2 d2 (0x0012) 6082 dtmf character 3 d3 (0x0013) 6083 dtmf character 4 d4 (0x0014) 6084 dtmf character 5 d5 (0x0015) 6085 dtmf character 6 d6 (0x0016) 6086 dtmf character 7 d7 (0x0017) 6087 dtmf character 8 d8 (0x0018) 6088 dtmf character 9 d9 (0x0019) 6089 dtmf character * ds (0x0020) 6090 dtmf character # do (0x0021) 6091 dtmf character A da (0x001a) 6092 dtmf character B db (0x001b) 6093 dtmf character C dc (0x001c) 6095 Internet draft MEGACO Protocol February 21, 2000 6097 | dtmf character D| dd (0x001d)| 6098 |_________________|_____________| 6100 E.5.4. Statistics 6102 None 6104 E.5.5. Procedures 6106 None 6108 E.6. DTMF detection Package 6110 PackageID: dd (0x0004) 6111 Version: 1 6112 Extends: tonedet version 1 6113 This package defines the basic DTMF tones detection. 6114 This Package extends the possible values of tone id 6115 in the "start tone detected" "end tone detected" 6116 and "long tone detected" events. 6118 Additional tone id values are all tone ids described in package dg 6119 (basic DTMF generator package). 6121 The following table maps DTMF events to digit map symbols as described 6122 in section 7.1.14. 6124 _________________________________ 6125 | DTMF Event | Symbol | 6126 | d0 | "0" | 6127 | d1 | "1" | 6128 | d2 | "2" | 6129 | d3 | "3" | 6130 | d4 | "4" | 6131 | d5 | "5" | 6132 | d6 | "6" | 6133 | d7 | "7" | 6134 | d8 | "8" | 6135 | d9 | "9" | 6136 | da | "A" or "a"| 6137 | db | "B" or "b"| 6138 | dc | "C" or "c"| 6139 | dd | "D" or "d"| 6140 | ds | "E" or "e"| 6141 | do | "F" or "f"| 6142 |___________________|____________| 6144 Internet draft MEGACO Protocol February 21, 2000 6146 E.6.1. Properties 6148 None 6150 E.6.2. Events 6152 DTMF digits 6153 EventIds are defined with the same names as the SignalIds 6154 defined in the table found in section E.5.3 6156 DigitMap Completion Event 6157 EventID: ce, 0x0001 6158 Generated when a digit map completes as described in section 6159 7.1.14. 6161 EventsDescriptor parameters: digit map processing is activated 6162 only if a digit map parameter is present, specifying a 6163 digit map by name or by value. Other parameters such as 6164 a KeepActive flag or embedded Events or Signals Descriptors may be present.. 6166 ObservedEventsDescriptor parameters: 6167 DigitString 6168 ParameterID: ds (0x0001) 6169 Type: string of digit map symbols (possibly empty) 6170 returned as a quotedString 6171 Possible values: any sequence of the characters "0" through 6172 "9", "A" through "F", and the long duration modifier "L". 6173 Description: the portion of the current dial string as 6174 described in section 7.1.14 which matched part or all 6175 of an alternative event sequence specified in the digit map. 6177 Termination Method 6178 ParameterID: Meth (0x0003) 6179 Type: enumeration 6180 Possible values: 6181 "UM" (0x0001) Unambiguous match 6182 "PM" (0x0002) Partial match, completion by timer expiry 6183 or unmatched event 6184 "FM" (0x0003) Full match, completion by timer expiry 6185 or unmatched event 6186 Description: indicates the reason for generation of the event. 6187 See the procedure in section 7.1.14. 6189 E.6.3. Signals 6191 None 6193 Internet draft MEGACO Protocol February 21, 2000 6195 E.6.4. Statistics 6197 None 6199 E.6.5. Procedures 6201 None 6203 E.7. Call Progress Tones Generator Package 6205 PackageID: cg, 0x0005 6206 Version: 1 6207 Extends: tonegen version 1 6208 This package defines the basic call progress tones as signals 6209 and extends the allowed values of the tl parameter of 6210 playtone in tonegen. 6212 E.7.1. Properties 6214 None 6216 E.7.2. Events 6218 None 6220 E.7.3. Signals 6222 Dial Tone 6223 SignaID: dt (0x0030) 6224 Generate dial tone. The physical characteristic of dial tone 6225 is available in the gateway. 6226 Signal Type: Timeout 6227 Duration: Provisioned 6228 Additional Parameters: 6229 None 6230 Additional Values 6231 dt (0x0030) is defined as a tone id for playtone 6233 The other tones of this package are defined in exactly the same way. A 6234 table with all signal names and signal IDs is included. Note that each 6235 tone is defined as both a signal and a toneid, thus extending the basic 6236 tone generation package. 6237 l | l. 6238 Signal Name!Signal ID/tone id Dial Tone!dt (0x0030) Ringing Tone!rt 6239 (0x0031) Busy Tone!bt (0x0032) Congestion Tone!ct (0x0033) Special 6240 Information Tone!sit(0x0034) Warning Tone!wt (0x0035) Payphone 6242 Internet draft MEGACO Protocol February 21, 2000 6244 Recognition Tone!pt (0x0036) Call Waiting Tone!cw (0x0037) Caller Wait- 6245 ing Tone!cr (0x0038) 6247 E.7.4. Statistics 6249 None 6251 E.7.5. Procedures 6253 NOTE - The required set of tone ids corresponds to those defined in 6254 Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)]. See 6255 E.180 for definition of the meanings of these tones. 6257 E.8. Call Progress Tones Detection Package 6259 PackageID: cd (0x0006) 6260 Version: 1 6261 Extends: tonedet version 1 6262 This package defines the basic call progress detection tones. 6263 This Package extends the possible values of tone id 6264 in the "start tone detected", "end tone detected" and 6265 "long tone detected" events. 6266 Additional values 6267 tone id values are defined for start tone detected, 6268 end tone detected and long tone detected with 6269 the same values as those in package cg (call 6270 progress tones generation package). 6272 The required set of tone ids corresponds to Recommendation E.180/Q.35 6273 [ITU-T Recommendation E.180/Q.35 (1998)]. See Recommendation E.180/Q.35 6274 for definition of the meanings of these tones. 6276 E.8.1. Properties 6278 none 6280 E.8.2. Events 6282 Events are defined as in the call progress tones generator package (cg) 6283 for the tones listed in the table of section E.7.3 6285 E.8.3. Signals 6287 none 6289 Internet draft MEGACO Protocol February 21, 2000 6291 E.8.4. Statistics 6293 none 6295 E.8.5. Procedures 6297 none 6299 E.9. Analog Line Supervision Package 6301 PackageID: al, 0x0009 6302 Version: 1 6303 Extends: None 6304 This package defines events and signals for an analog line. 6306 E.9.1. Properties 6308 None 6310 E.9.2. Events 6312 onhook 6313 EventID: on (0x0004) 6314 Detects handset going on hook. Whenever an events descriptor 6315 is activated that requests monitoring for an on-hook event 6316 and the line is already on-hook, then the MG immediately 6317 generate an on-hook event. 6318 EventDescriptor parameters 6319 None 6320 ObservedEventsDescriptor parameters 6321 None 6322 offhook 6323 EventID: of (0x0005) 6324 Detects handset going off hook. Whenever an events descriptor 6325 is activated that requests monitoring for an off-hook event 6326 and the line is already off-hook, then the MG immediately 6327 generate an off-hook event. 6328 EventDescriptor parameters 6329 None 6330 ObservedEventsDescriptor parameters 6331 None 6332 flashhook 6333 EventID: fl, 0x0006 6334 Detects handset flash. A flash occurs when an onhook is 6335 followed by an offhook between a minimum and 6336 maximum duration. 6337 EventDescriptor parameters 6338 Minimum duration 6340 Internet draft MEGACO Protocol February 21, 2000 6342 ParameterID: mindur (0x0004) 6343 Type: integer in milliseconds 6344 Default value is provisioned 6345 Maximum duration 6346 ParameterID: maxdur (0x0005) 6347 Type: integer in milliseconds 6348 Default value is provisioned 6349 ObservedEventsDescriptor parameters 6350 None 6352 E.9.3. Signals 6354 ring 6355 SignalID: ri, 0x0002 6356 Applies ringing on the line 6357 Signal Type: TimeOut 6358 Duration: Provisioned 6359 Additional Parameters: 6360 Cadence 6361 ParameterID: cad (0x0006) 6362 Type: list of integers representing durations of 6363 alternating on and off segments, constituting 6364 a complete ringing cycle starting with an on. 6365 Units in milliseconds 6366 Default is fixed or provisioned. Restricted function 6367 MGs may ignore cadence values they are 6368 incapable of generating. 6369 Frequency 6370 ParameterID: freq (0x0007) 6371 Type: integer in Hz 6372 Default is fixed or provisioned. Restricted function 6373 MGs may ignore frequency values they are 6374 incapable of generating. 6376 E.9.4. Statistics 6378 None 6380 E.9.5. Procedures 6382 None 6384 E.10. Basic Continuity Package 6386 PackageID: ct (0x000a) 6387 Version: 1 6389 Internet draft MEGACO Protocol February 21, 2000 6391 Extends: None 6392 This package defines events and signals for continuity test. 6393 The continuity test includes provision of either a loopback 6394 or transceiver functionality. 6396 E.10.1. Properties 6398 None 6400 E.10.2. Events 6402 Completion 6403 EventID: cmp, 0x0005 6404 This event detects test completion of continuity test. 6405 EventDescriptor parameters 6406 None 6407 ObservedEventsDescriptor parameters 6408 Result 6409 ParameterID: res (0x0008) 6410 Type: Enumeration 6411 Possible values: success (0x0001), failure (0x0000) 6413 E.10.3. Signals 6415 Continuity Test 6416 SignalID: ct (0x0003) 6417 Initiates sending of continuity test tone on the termination 6418 to which it is applied. 6419 Signal Type: Timeout 6420 Default value is provisioned 6421 Additional Parameters: 6422 None 6423 Respond 6424 SignalID: rsp (0x0004) 6425 The signal is used to respond to a continuity test 6426 See section E.5.10 for further explanation. 6427 Signal Type: TimeOut 6428 Default duration is provisioned 6429 Additional Parameters: 6430 None 6432 E.10.4. Statistics 6434 None 6436 Internet draft MEGACO Protocol February 21, 2000 6438 E.10.5. Procedures 6440 When a MGC wants to initiate a continuity test, it sends a command to 6441 the MG containing a signals descriptor with the ct signal, and an events 6442 descriptor containing the cmp event. Upon reception of a command con- 6443 taining the ct signal and cmp event, the MG initiates the continuity 6444 test tone for the specified termination. If the return tone is detected 6445 before the signal times out, the cmp event shall be generated with the 6446 value of the result parameter equal to success. In all other cases, the 6447 cmp event shall be generated with the value of the result parameter 6448 equal to failure. When a MGC wants the MG to respond to a continuity 6449 test, it sends a command to the MG containing a signals descriptor with 6450 the rsp signal. Upon reception of a command with the rsp signal, the MG 6451 awaits reception of the continuity test tone. When the tone is received 6452 before the rsp signal times out, the MG returns the applicable return 6453 tone. If the rsp signal times out, the MG removes the detection and the 6454 return tone (if that was playing). When a continuity test is performed 6455 on a termination, no echo devices or codecs shall be active on that ter- 6456 mination. Performing voice path assurance as part of continuity testing 6457 is provisioned by bilateral agreement between network operators. 6459 E.11. Network Package 6461 PackageID: nt (0x000b) 6462 Version: 1 6463 Extends: None 6464 This package defines properties of network terminations 6465 independent of network type. 6467 E.11.1. Properties 6469 Maximum Jitter Buffer 6470 PropertyID: jit (0x0007) 6471 This property puts a maximum size on the jitter buffer. 6472 Type: integer in milliseconds 6473 Possible Values: This property is specified in milliseconds. 6474 Defined In: LocalControlDescriptor 6475 Characteristics: read/write 6477 E.11.2. Events 6479 network failure 6480 EventID: netfail, 0x0005 6481 The termination generates this event upon detection of a 6482 failure due to external or internal network reasons. 6484 Internet draft MEGACO Protocol February 21, 2000 6486 EventDescriptor parameters 6487 None 6488 ObservedEventsDescriptor parameters 6489 cause 6490 ParameterID: cs (0x0001) 6491 Type: String 6492 Possible values: any text string 6493 This parameter may be included with the failure 6494 event to provide diagnostic information on the 6495 reason of failure. 6496 quality alert 6497 EventID: qualert, 0x0006 6498 This property allows the MG to indicate a loss of quality 6499 of the network connection. The MG may do this by 6500 measuring packet loss, interarrival jitter, propogation 6501 delay and then indicating this using a percentage of 6502 quality loss. 6503 EventDescriptor parameters 6504 Threshold 6505 ParameterId: th (0x0001) 6506 Type: integer 6507 Possible Values: threshold for percent of quality 6508 loss measured, calculated based on a 6509 provisioned method, that could take into 6510 consideration packet loss, jitter, and delay 6511 for example. Event is triggered when 6512 calculation exceeds the threshold. 6513 ObservedEventsDescriptor parameters 6514 Threshold 6515 ParameterId: th (0x0001) 6516 Type: integer 6517 Possible Values: percent of quality loss measured, 6518 calculated based on a provisioned method, 6519 that could take into consideration packet loss, 6520 jitter, and delay for example. 6522 E.11.3. Signals 6524 none 6526 E.11.4. Statistics 6528 Duration 6529 StatisticsID: dur (0x0001) 6530 Description: Provides duration of time the termination has 6531 been in the context. 6532 Type: Double, in milliseconds 6534 Internet draft MEGACO Protocol February 21, 2000 6536 Octets Sent 6537 StatisticID: os (0x0002) 6538 Type: double 6539 Possible Values: any 64 bit integer 6540 Octets Received 6541 StatisticID: or (0x0003) 6542 Type: double 6543 Possible Values: any 64 bit integer 6545 E.11.5. Procedures 6547 none 6549 E.12. RTP Package 6551 PackageID: rtp (0x000c) 6552 Version: 1 6553 Extends: Network Package version 1 6554 This package is used to support packet based multimedia 6555 data transfer by means of the Real-time Transport Protocol 6556 (RTP) [RFC 1889]. 6558 E.12.1. Properties 6560 None 6562 E.12.2. Events 6564 Payload Transition 6565 EventID: pltrans, 0x0001 6566 This event detects and notifies when there is a transition 6567 of the RTP payload format from one format to another. 6568 EventDescriptor parameters 6569 None 6570 ObservedEventsDescriptor parameters 6571 ParameterName: rtppayload 6572 ParameterID: rtppltype, 0x01 6573 Type: list of enumerated types. 6574 Possible values: The encoding method shall be 6575 specified by using one or several valid 6576 encoding names, as defined in the RTP AV 6577 Profile or registered with IANA. 6579 Internet draft MEGACO Protocol February 21, 2000 6581 E.12.3. Signals 6583 None 6585 E.12.4. Statistics 6587 Packets Sent 6588 StatisticID: ps (0x0004) 6589 Type: double 6590 Possible Values: any 64 bit integer 6591 Packets Received 6592 StatisticID: pr (0x0005) 6593 Type: double 6594 Possible Values: any 64 bit integer 6595 Packet Loss 6596 StatisticID: pl (0x0006) 6597 Describes the current rate of packet loss on an RTP stream, 6598 as defined in IETF RFC 1889. Packet loss is expressed as 6599 percentage value: number of packets lost in the interval 6600 between two reception reports, divided by the number of 6601 packets expected during that interval. 6602 Type: double 6603 Possible Values: a 32 bit whole number and a 32 bit fraction. 6604 Jitter 6605 StatisticID: jit (0x0007) 6606 Requests the current value of the interarrival jitter 6607 on an RTP stream as defined in IETF RFC 1889. 6608 Jitter measures the variation in interarrival time 6609 for RTP data packets. 6610 Delay 6611 StatisticID:delay (0x0008) 6612 Requests the current value of packet propagation delay 6613 expressed in timestamp units. Same as average latency. 6615 E.12.5. Procedures 6617 none 6619 E.13. TDM Circuit Package 6621 PackageID: tdmc (0x000d) 6622 Version: 1 6623 Extends: Network Package version 1 6624 This package is used to support TDM circuit terminations. 6626 Internet draft MEGACO Protocol February 21, 2000 6628 E.13.1. Properties 6630 Echo Cancellation 6631 PropertyID: ec (0x0008) 6632 By default, the telephony gateways always perform 6633 echo cancellation. 6634 However, it is necessary, for some calls, to turn 6635 off these operations. 6636 Type: boolean 6637 Possible Values: 6638 "on" (when the echo cancellation isrequested) and 6639 "off (when it is turned off.) 6640 The default "on". 6641 Defined In: LocalControlDescriptor 6642 Characteristics: read/write 6644 Gain Control 6645 PropertyID: gain (0x000a) 6646 Gain control, or usage of of signal level adaptation and 6647 noise level reduction is used to adapt the level of 6648 the signal. However, it is necessary, for example 6649 for modem calls, to turn off this function. 6650 Type: enumeration (integer) 6651 Possible Values: 6652 The gain control parameter may either be specified 6653 as "automatic" (0xffffffff), or as an explicit number 6654 of decibels of gain (any other integer value). 6655 The default is provisioned in the MG. 6656 Defined In: LocalControlDescriptor 6657 Characteristics: read/write 6659 E.13.2. Events 6661 none 6663 E.13.3. Signals 6665 none 6667 E.13.4. Statistics 6669 None 6671 E.13.5. Procedures 6673 None 6675 Internet draft MEGACO Protocol February 21, 2000 6677 APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) 6679 All Megaco implementors must read the normative part of this document 6680 carefully before implementing from it. No one should use the examples in 6681 this section as stand-alone explanations of how to create protocol mes- 6682 sages. 6684 The examples in this section use SDP for encoding of the Local and 6685 Remote stream descriptors. SDP is defined in RFC 2327. If there is any 6686 discrepancy between the SDP in the examples, and RFC 2327, the RFC 6687 should be consulted for correctness. Audio profiles used are those 6688 defined in RFC 1890, and others registered with IANA. For example, G.711 6689 A-law is called PCMA in the SDP, and is assigned profile 0. G.723 is 6690 profile 4, and H263 is profile 34. See also http://www.isi.edu/in- 6691 notes/iana/assignments/rtp-parameters 6693 A.1. Residential Gateway to Residential Gateway Call 6695 This example scenario illustrates the use of the elements of the proto- 6696 col to set up a Residential Gateway to Residential Gateway call over an 6697 IP-based network. For simplicity, this example assumes that both 6698 Residential Gateways involved in the call are controlled by the same 6699 Media Gateway Controller. 6701 A.1.1. Programming Residential GW Analog Line Terminations for Idle 6702 Behavior 6704 The following illustrates the API invocations from the Media Gateway 6705 Controller and Media Gateways to get the Terminations in this scenario 6706 programmed for idle behavior. Both the originating and terminating 6707 Media Gateways have idle AnalogLine Terminations programmed to look for 6708 call initiation events (i.e.-offhook) by using the Modify Command with 6709 the appropriate parameters. The null Context is used to indicate that 6710 the Terminations are not yet involved in a Context. The ROOT termination 6711 is used to indicate the entire MG instead of a termination within the 6712 MG. 6714 In this example, MG1 has the IP address 124.124.124.222, MG2 is 6715 125.125.125.111, and the MGC is 123.123.123.4. The default Megaco port 6716 is 55555 for all three. 6718 1. An MG registers with an MGC using the ServiceChange command: 6720 MG1 to MGC: 6721 MEGACO/1 [124.124.124.222] 6722 Transaction = 9998 { 6723 Context = - { 6724 ServiceChange = ROOT {Services { 6726 Internet draft MEGACO Protocol February 21, 2000 6728 Method=Restart, 6729 ServiceChangeAddress=55555, Profile=ResGW/1} 6730 } 6731 } 6732 } 6734 2. The MGC sends a reply: 6736 MGC to MG1: 6737 MEGACO/1 [123.123.123.4]:55555 6738 Reply = 9998 { 6739 Context = - {ServiceChange = ROOT { 6740 Services {ServiceChangeAddress=55555, Profile=ResGW/1} } } 6741 } 6743 3. The MGC programs a Termination in the NULL context. The termina- 6744 tionId is A4444, the streamId is 1, the requestId in the Events 6745 descriptor is 2222. The mId is the identifier of the sender of 6746 this message, in this case, it is the IP address and port 6747 [123.123.123.4]:55555. Mode for this stream is set to SendReceive. 6748 "al" is the analog line supervision package. 6750 MGC to MG1: 6751 MEGACO/1 [123.123.123.4]:55555 6752 Transaction = 9999 { 6753 Context = - { 6754 Modify = A4444 { 6755 Media { Stream = 1 { 6756 LocalControl { 6757 Mode = SendReceive, 6758 ds0/gain=2, ; in dB, 6759 ds0/ec=G165 6760 }, 6761 Local { 6762 v=0 6763 c=IN IP4 $ 6764 m=audio $ RTP/AVP 0 6765 a=fmtp:PCMU VAD=X-NNVAD ; special voice activity 6766 ; detection algorithm 6767 } 6768 } 6769 }, 6770 Events = 2222 {al/of} 6771 } 6772 } 6773 } 6775 Internet draft MEGACO Protocol February 21, 2000 6777 The dialplan script could have been loaded into the MG previously. Its 6778 function would be to wait for the OffHook, turn on dialtone and start 6779 collecting DTMF digits. However in this example, we use the digit map, 6780 which is put into place after the offhook is detected (step 5 below). 6782 Note that the embedded EventsDescriptor could have been used to combine 6783 steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. 6785 4. The MG1 accepts the Modify with this reply: 6787 MG1 to MGC: 6788 MEGACO/1 [124.124.124.222]:55555 6789 Reply = 9999 { 6790 Context = - {Modify = A4444} 6791 } 6793 5. A similar exchange happens between MG2 and the MGC, resulting in an 6794 idle Termination called A5555. 6796 A.1.2. Collecting Originator Digits and Initiating Termination 6798 The following builds upon the previously shown conditions. It illus- 6799 trates the transactions from the Media Gateway Controller and originat- 6800 ing Media Gateway (MG1) to get the originating Termination (A4444) 6801 through the stages of digit collection required to initiate a connection 6802 to the terminating Media Gateway (MG2). 6804 6. MG1 detects an offhook event from User 1 and reports it to the 6805 Media Gateway Controller via the Notify Command. 6807 MG1 to MGC: 6808 MEGACO/1 [124.124.124.222]:55555 6809 Transaction = 10000 { 6810 Context = - { 6811 Notify = A4444 {ObservedEvents =2222 { 6812 19990729T22000000:al/of}} 6813 } 6814 } 6816 7. And the Notify is acknowledged. 6818 MGC to MG1: 6819 MEGACO/1 [123.123.123.4]:55555 6821 Internet draft MEGACO Protocol February 21, 2000 6823 Reply = 10000 { 6824 Context = - {Notify = A4444} 6825 } 6827 8. The MGC Modifies the termination to play dial tone, to look for 6828 digits according to Dialplan0 and to look for the on-hook event 6829 now. 6831 MGC to MG1: 6832 MEGACO/1 [123.123.123.4]:55555 6833 Transaction = 10001 { 6834 Context = - { 6835 Modify = A4444 { 6836 Events = 2223 { 6837 al/on, dd/ce {DigitMap=Dialplan0} 6838 }, 6839 Signals {cg/dt}, 6840 DigitMap= Dialplan0{ 6841 (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)} 6842 } 6843 } 6844 } 6846 9. And the Modify is acknowledged. 6848 MG1 to MGC: 6849 MEGACO/1 [124.124.124.222]:55555 6850 Reply = 10001 { 6851 Context = - {Modify = A4444} 6852 } 6854 10. Next, digits are accumulated by MG1 as they are dialed by User 1. 6855 Dialtone is stopped upon detection of the first digit. When an 6856 appropriate match is made of collected digits against the currently 6857 programmed Dialplan for A4444, another Notify is sent to the Media 6858 Gateway Controller. 6860 MG1 to MGC: 6861 MEGACO/1 [124.124.124.222]:55555 6862 Transaction = 10002 { 6863 Context = - { 6864 Notify = A4444 {ObservedEvents =2223 { 6866 Internet draft MEGACO Protocol February 21, 2000 6868 19990729T22010001:dd/ce{ds="916135551212",Meth=FM}}} 6869 } 6870 } 6872 11. And the Notify is acknowledged. 6874 MGC to MG1: 6875 MEGACO/1 [123.123.123.4]:55555 6876 Reply = 10002 { 6877 Context = - {Notify = A4444} 6878 } 6880 12. The controller then analyses the digits and determines that a con- 6881 nection needs to be made from MG1 to MG2. Both the TDM termination 6882 A4444, and an RTP termination are added to a new context in MG1. 6883 Mode is ReceiveOnly since Remote descriptor values are not yet 6884 specified. Preferred codecs are in the MGC's preferred order of 6885 choice. 6887 MGC to MG1: 6888 MEGACO/1 [123.123.123.4]:55555 6889 Transaction = 10003 { 6890 Context = $ { 6891 Add = A4444, 6892 Add = $ { 6893 Media { 6894 Stream = 1 { 6895 LocalControl { 6896 Mode = ReceiveOnly, 6898 nt/jit=40, ; in ms 6899 }, 6900 Local { 6901 v=0 6902 c=IN IP4 $ 6903 m=audio $ RTP/AVP 4 6904 a=ptime:30 6905 v=0 6906 c=IN IP4 $ 6907 m=audio $ RTP/AVP 0 6908 } 6909 } 6910 } 6911 } 6913 Internet draft MEGACO Protocol February 21, 2000 6915 } 6916 } 6918 NOTE - The MGC states its preferred parameter values as a series of sdp 6919 blocks in Local. The MG fills in the Local Descriptor in the Reply. 6921 13. MG1 acknowledges the new Termination and fills in the Local IP 6922 address and UDP port. It also makes a choice for the codec based on 6923 the MGC preferences in Local. MG1 sets the RTP port to 2222. 6925 MEGACO/1 [124.124.124.222]:55555 6926 Reply = 10003 { 6927 Context = 2000 { 6928 Add = A4444, 6929 Add=A4445{ 6930 Media { 6931 Stream = 1 { 6932 Local { 6933 v=0 6934 c=IN IP4 124.124.124.222 6935 m=audio 2222 RTP/AVP 4 6936 a=ptime:30 6937 a=recvonly 6938 } ; RTP profile for G.723 is 4 6939 } 6940 } 6941 } 6942 } 6943 } 6945 14. The MGC will now associate A5555 with a new Context on MG2, and 6946 establish an RTP Stream (i.e, A5556 will be assigned), SendReceive 6947 connection through to the originating user, User 1. The MGC also 6948 sets ring on A5555. 6950 MGC to MG2: 6951 MEGACO/1 [123.123.123.4]:55555 6952 Transaction = 50003 { 6953 Context = $ { 6954 Add = A5555 { Media { 6955 Stream = 1 { 6956 LocalControl {Mode = SendReceive} }}, 6957 Events=1234{al/of} 6959 Internet draft MEGACO Protocol February 21, 2000 6961 Signals {al/ri} 6962 }, 6963 Add = $ {Media { 6964 Stream = 1 { 6965 LocalControl { 6966 Mode = SendReceive, 6967 nt/jit=40 ; in ms 6968 }, 6969 Local { 6970 v=0 6971 c=IN IP4 $ 6972 m=audio $ RTP/AVP 4 6973 a=ptime:30 6974 }, 6975 Remote { 6976 v=0 6977 c=IN IP4 124.124.124.222 6978 m=audio 2222 RTP/AVP 4 6979 a=ptime:30 6980 } ; RTP profile for G.723 is 4 6981 } 6982 } 6983 } 6984 } 6985 } 6987 15. This is acknowledged. The stream port number is different from the 6988 control port number. In this case it is 1111 (in the SDP). 6990 MG2 to MGC: 6991 MEGACO/1 [124.124.124.222]:55555 6992 Reply = 50003 { 6993 Context = 5000 { 6994 Add = A5555{}, 6995 Add = A5556{ 6996 Media { 6997 Stream = 1 { 6998 Local { 6999 v=0 7000 c=IN IP4 125.125.125.111 7001 m=audio 1111 RTP/AVP 4 7002 } 7003 } ; RTP profile for G723 is 4 7004 } 7005 } 7007 Internet draft MEGACO Protocol February 21, 2000 7009 } 7010 } 7012 16. The above IPAddr and UDPport need to be given to MG1 now. 7014 MGC to MG1: 7015 MEGACO/1 [123.123.123.4]:55555 7016 Transaction = 10005 { 7017 Context = 2000 { 7018 Modify = A4444 { 7019 Signals {cg/rt} 7020 }, 7021 Modify = A4445 { 7022 Media { 7023 Stream = 1 { 7024 Remote { 7025 v=0 7026 c=IN IP4 125.125.125.111 7027 m=audio 1111 RTP/AVP 4 7028 } 7029 } ; RTP profile for G723 is 4 7030 } 7031 } 7032 } 7033 } 7035 MG1 to MGC: 7036 MEGACO/1 [124.124.124.222]:55555 7037 Reply = 10005 { 7038 Context = 2000 {Modify = A4444, Modify = A4445} 7039 } 7041 17. The two gateways are now connected and User 1 hears the RingBack. 7042 The MG2 now waits until User2 picks up the receiver and then the 7043 two-way call is established. 7045 From MG2 to MGC: 7047 MEGACO/1 [125.125.125.111]:55555 7048 Transaction = 50005 { 7049 Context = 5000 { 7050 Notify = A5555 {ObservedEvents =1234 { 7051 19990729T22020002:al/of}} 7052 } 7054 Internet draft MEGACO Protocol February 21, 2000 7056 } 7058 From MGC to MG2: 7060 MEGACO/1 [123.123.123.4]:55555 7061 Reply = 50005 { 7062 Context = - {Notify = A5555} 7063 } 7065 From MGC to MG2: 7067 MEGACO/1 [123.123.123.4]:55555 7068 Transaction = 50006 { 7069 Context = 5000 { 7070 Modify = A5555 { 7071 Events = 1235 {al/on}, 7072 Signals { } ; to turn off ringing 7073 } 7074 } 7075 } 7077 From MG2 to MGC: 7079 MEGACO/1 [125.125.125.111]:55555 7080 Reply = 50006 { 7081 Context = 5000 {Modify = A4445} 7082 } 7084 18. Change mode on MG1 to SendReceive, and stop the ringback. 7086 MGC to MG1: 7087 MEGACO/1 [123.123.123.4]:55555 7088 Transaction = 10006 { 7089 Context = 2000 { 7090 Modify = A4445 { 7091 Media { 7092 Stream = 1 { 7093 LocalControl { 7094 Mode=SendReceive 7095 } 7096 } 7097 } 7098 }, 7099 Modify = A4444 { 7100 Signals { } 7101 } 7103 Internet draft MEGACO Protocol February 21, 2000 7105 } 7106 } 7108 from MG1 to MGC: 7109 MEGACO/1 [124.124.124.222]:55555 7110 Reply = 10006 { 7111 Context = 2000 {Modify = A4445, Modify = A4444}} 7113 19. The MGC decides to Audit the RTP termination on MG2. 7115 MEGACO/1 [123.123.123.4]:55555 7116 Transaction = 50007 { 7117 Context = - {AuditValue = A5556{ 7118 Audit{Media, DigitMap, Events, Signals, Packages, Statistics }} 7119 } 7120 } 7122 20. The MG2 replies. An RTP termination has no events nor signals, so 7123 these are left out in the reply . 7125 MEGACO/1 [125.125.125.111]:55555 7126 Reply = 50007 { 7127 Context = - { 7128 AuditValue = A5556 { 7129 Media { 7130 Stream = 1 { 7131 LocalControl { Mode = SendReceive, 7132 nt/jit=40 }, 7133 Local { 7134 v=0 7135 c=IN IP4 125.125.125.111 7136 m=audio 1111 RTP/AVP 4 7137 a=ptime:30 7138 }, 7139 Remote { 7140 v=0 7141 c=IN IP4 124.124.124.222 7142 m=audio 2222 RTP/AVP 4 7143 a=ptime:30 7144 } } }, 7145 Packages {nt-1, rtp-1}, 7146 Statistics { rtp/ps=1200, ; packets sent 7147 nt/os=62300, ; octets sent 7148 rtp/pr=700, ; packets received 7150 Internet draft MEGACO Protocol February 21, 2000 7152 nt/or=45100, ; octets received 7153 rtp/pl=0.2, ; % packet loss 7154 rtp/jit=20, 7155 rtp/delay=40 } ; avg latency 7156 } 7157 } 7158 } 7160 21. When the MGC receives an onhook signal from one of the MGs, it 7161 brings down the call. In this example, the user at MG2 hangs up 7162 first. 7164 From MG2 to MGC: 7166 MEGACO/1 [125.125.125.111]:55555 7167 Transaction = 50008 { 7168 Context = 5000 { 7169 Notify = A5555 {ObservedEvents =1235 { 7170 19990729T24020002:al/on} 7171 } 7172 } 7173 } 7175 From MGC to MG2: 7177 MEGACO/1 [123.123.123.4]:55555 7178 Reply = 50008 { 7179 Context = - {Notify = A5555} 7180 } 7182 22. The MGC now sends both MGs a Subtract to take down the call. Only 7183 the subtracts to MG2 are shown here. Each termination has its own 7184 set of statistics that it gathers. An MGC may not need to request 7185 both to be returned. A5555 is a physical termination, and A5556 is 7186 an RTP termination. 7188 From MGC to MG2: 7190 MEGACO/1 [123.123.123.4]:55555 7191 Transaction = 50009 { 7192 Context = 5000 { 7193 Subtract = A5555 {Audit{Statistics}}, 7194 Subtract = A5556 {Audit{Statistics}} 7195 } 7197 Internet draft MEGACO Protocol February 21, 2000 7199 } 7201 From MG2 to MGC: 7203 MEGACO/1 [125.125.125.111]:55555 7204 Reply = 50009 { 7205 Context = 5000 { 7206 Subtract = A5555 { 7207 Statistics { 7208 nt/os=45123, ; Octets Sent 7209 nt/dur=40 ; in seconds 7210 } 7211 }, 7212 Subtract = A5556 { 7213 Statistics { 7214 rtp/ps=1245, ; packets sent 7215 nt/os=62345, ; octets sent 7216 rtp/pr=780, ; packets received 7217 nt/or=45123, ; octets received 7218 rtp/pl=10, ; % packets lost 7219 rtp/jit=27, 7220 rtp/delay=48 ; average latency 7221 } 7222 } 7223 } 7224 } 7226 23. The MGC now sets up both MG1 and MG2 to be ready to detect the next 7227 off-hook event. See step 1. Note that this could be the default 7228 state of a termination in the null context, and if this were the 7229 case, no message need be sent from the MGC to the MG. Once a termi- 7230 nation returns to the null context, it goes back to the default 7231 termination values for that termination.