idnits 2.17.1 draft-ietf-megaco-protocol-05.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 141 longer pages, the longest (page 6) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 143 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** There are 138 instances of too long lines in the document, the longest one being 81 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 606 has weird spacing: '...andling for a...' == Line 826 has weird spacing: '...signals are n...' == Line 1186 has weird spacing: '...sts for the M...' == Line 1215 has weird spacing: '... native withi...' == Line 1276 has weird spacing: '...eceived when ...' == (11 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? 'ServiceChangeDescriptor' on line 2122 looks like a reference -- Missing reference section? 'RFC2402' on line 2859 looks like a reference -- Missing reference section? 'RFC2406' on line 2816 looks like a reference -- Missing reference section? 'RFC2409' on line 2825 looks like a reference -- Missing reference section? 'RFC 2119' on line 4229 looks like a reference -- Missing reference section? 'DOT' on line 4641 looks like a reference -- Missing reference section? 'LF' on line 4749 looks like a reference -- Missing reference section? '00-27' on line 5542 looks like a reference -- Missing reference section? '0' on line 5544 looks like a reference -- Missing reference section? '3-5' on line 5544 looks like a reference -- Missing reference section? '8' on line 5544 looks like a reference -- Missing reference section? 'RFC 1889' on line 6188 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 15 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 January 27, 2000 Bryan Hill 4 Expires July 27, 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 January 27, 2000 42 1. SCOPE ..................................................... 7 43 2. REFERENCES ................................................ 7 44 2.1. Normative references ................................. 7 45 2.2. Informative references ............................... 8 46 3. DEFINITIONS ............................................... 9 47 4. ABBREVIATIONS ............................................. 10 48 5. CONVENTIONS ............................................... 10 49 6. CONNECTION MODEL .......................................... 10 50 6.1. Contexts ............................................. 14 51 6.1.1. Context Attributes and Descriptors .............. 15 52 6.1.2. Creating, Deleting and Modifying Contexts ....... 15 53 6.2. Terminations ......................................... 15 54 6.2.1. Termination Dynamics ............................ 16 55 6.2.2. TerminationIDs .................................. 16 56 6.2.3. Packages ........................................ 17 57 6.2.4. Termination Properties and Descriptors .......... 17 58 6.2.5. Root Termination ................................ 19 59 7. COMMANDS .................................................. 20 60 7.1. Descriptors .......................................... 21 61 7.1.1. Specifying Parameters ........................... 21 62 7.1.2. Modem Descriptor ................................ 22 63 7.1.3. Multiplex Descriptor ............................ 22 64 7.1.4. Media Descriptor ................................ 22 65 7.1.5. Termination State Descriptor .................... 23 66 7.1.6. Stream Descriptor ............................... 24 67 7.1.7. LocalControl Descriptor ......................... 24 68 7.1.8. Local and Remote Descriptors .................... 25 69 7.1.9. Events Descriptor ............................... 28 70 7.1.10. EventBuffer Descriptor ......................... 29 71 7.1.11. Signals Descriptor ............................. 29 72 7.1.12. Audit Descriptor ............................... 31 73 7.1.13. ServiceChange Descriptor ....................... 32 74 7.1.14. DigitMap Descriptor ............................ 32 75 7.1.15. Statistics Descriptor .......................... 34 76 7.1.16. Packages Descriptor ............................ 35 77 7.1.17. ObservedEvents Descriptor ...................... 35 78 7.1.18. Topology Descriptor ............................ 35 79 7.2. Command Application Programming Interface ............ 38 80 7.2.1. Add ............................................. 38 81 7.2.2. Modify .......................................... 40 82 7.2.3. Subtract ........................................ 41 83 7.2.4. Move ............................................ 42 84 7.2.5. AuditValue ...................................... 43 85 7.2.6. AuditCapabilities ............................... 44 86 7.2.7. Notify .......................................... 45 87 7.2.8. ServiceChange ................................... 45 88 7.2.9. Manipulating and Auditing Context Attributes .... 49 89 7.2.10. Generic Command Syntax ......................... 50 91 Internet draft MEGACO Protocol January 27, 2000 93 7.3. Command Error Codes .................................. 50 94 8. TRANSACTIONS .............................................. 52 95 8.1. Common Parameters .................................... 53 96 8.1.1. Transaction Identifiers ......................... 53 97 8.1.2. Context Identifiers ............................. 53 98 8.2. Transaction Application Programming Interface ........ 54 99 8.2.1. TransactionRequest .............................. 54 100 8.2.2. TransactionReply ................................ 54 101 8.2.3. TransactionPending .............................. 56 102 8.3. Messages ............................................. 56 103 9. TRANSPORT ................................................. 56 104 9.1. Ordering of Commands ................................. 57 105 9.2. Protection against Restart Avalanche ................. 58 106 10. SECURITY CONSIDERATIONS .................................. 59 107 10.1. Protection of Protocol Connections .................. 59 108 10.2. Interim AH scheme ................................... 60 109 10.3. Protection of Media Connections ..................... 61 110 11. MG-MGC CONTROL INTERFACE ................................. 61 111 11.1. Multiple Virtual MGs ................................ 62 112 11.2. Cold Start .......................................... 62 113 11.3. Negotiation of Protocol Version ..................... 63 114 11.4. Failure of an MG .................................... 63 115 11.5. Failure of an MGC ................................... 64 116 12. PACKAGE DEFINITION ....................................... 65 117 12.1. Guidelines for defining packages .................... 65 118 12.1.1. Package ........................................ 65 119 12.1.2. Properties ..................................... 66 120 12.1.3. Events ......................................... 66 121 12.1.4. Signals ........................................ 67 122 12.1.5. Statistics ..................................... 67 123 12.1.6. Procedures ..................................... 67 124 12.2. Guidelines to defining Properties, Statistics ....... 68 125 12.3. Lists ............................................... 68 126 12.4. Identifiers ......................................... 68 127 12.5. Package Registration ................................ 68 128 13. IANA CONSIDERATIONS ...................................... 68 129 13.1. Packages ............................................ 68 130 13.2. Error Codes ......................................... 69 131 13.3. ServiceChange Reasons ............................... 70 132 14. CONTACT INFORMATION ...................................... 70 133 ANNEX A BINARY ENCODING OF THE PROTOCOL (NORMATIVE) ........... 71 134 A.1. Coding of wildcards .................................. 71 135 A.2. ASN.1 syntax specification ........................... 73 136 A.3. Digit maps and path names ............................ 88 137 ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE) ............. 89 138 B.1. Coding of wildcards .................................. 89 139 B.2. ABNF specification ................................... 89 140 ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE) ..........100 142 Internet draft MEGACO Protocol January 27, 2000 144 C.1. General Media Attributes .............................101 145 C.2. Mux Properties .......................................101 146 C.3. General bearer properties ............................101 147 C.4. General ATM properties ...............................101 148 C.5. Frame Relay ..........................................102 149 C.6. IP ...................................................103 150 C.7. ATM AAL2 .............................................103 151 C.8. ATM AAL1 .............................................103 152 C.9. Bearer Capabilities ..................................104 153 C.10. AAL5 Properties .....................................104 154 C.11. SDP Equivalents .....................................105 155 C.12. H.245 ...............................................105 156 ANNEX D TRANSPORT OVER IP (NORMATIVE) .........................105 157 D.1. Transport over IP/UDP using Application Level ........105 158 D.1.1. Providing At-Most-Once Functionality ............105 159 D.1.2. Transaction identifiers and three-way handshake 106 160 D.1.3. Computing retransmission timers .................108 161 D.1.4. Provisional responses ...........................109 162 D.1.5. Repeating Requests, Responses and ...............109 163 D.2. Using TCP ............................................110 164 D.2.1. Providing the At-Most-Once functionality ........111 165 D.2.2. Transaction identifiers and three way handshake 111 166 D.2.3. Computing retransmission timers .................111 167 D.2.4. Provisional responses ...........................111 168 D.2.5. Ordering of commands ............................112 169 ANNEX E BASIC PACKAGES ........................................112 170 E.1. Generic ..............................................112 171 E.1.1. Properties ......................................112 172 E.1.2. Events ..........................................112 173 E.2.2. Events ..........................................116 174 E.2.3. Signals .........................................116 175 E.2.4. Statistics ......................................116 176 E.2.5. Procedures ......................................116 177 E.3. Tone Generator Package ...............................116 178 E.3.1. Properties ......................................116 179 E.3.2. Events ..........................................116 180 E.3.3. Signals .........................................116 181 E.3.4. Statistics ......................................117 182 E.3.5. Procedures ......................................117 183 E.4. Tone Detection Package ...............................117 184 E.4.1. Properties ......................................117 185 E.4.2. Events ..........................................117 186 E.4.3. Signals .........................................119 187 E.4.4. Statistics ......................................119 188 E.4.5. Procedures ......................................119 189 E.5. Basic DTMF Generator Package .........................119 190 E.5.1. Properties ......................................119 191 E.5.2. Events ..........................................119 193 Internet draft MEGACO Protocol January 27, 2000 195 E.5.3. Signals .........................................120 196 E.5.4. Statistics ......................................120 197 E.5.5. Procedures ......................................120 198 E.6. DTMF detection Package ...............................121 199 E.6.1. Properties ......................................121 200 E.6.2. Events ..........................................121 201 E.6.3. Signals .........................................121 202 E.6.4. Statistics ......................................121 203 E.6.5. Procedures ......................................121 204 E.7. Call Progress Tones Generator Package ................122 205 E.7.1. Properties ......................................122 206 E.7.2. Events ..........................................122 207 E.7.3. Signals .........................................122 208 E.7.4. Statistics ......................................122 209 E.7.5. Procedures ......................................123 210 E.8. Call Progress Tones Detection Package ................123 211 E.8.1. Properties ......................................123 212 E.8.2. Events ..........................................123 213 E.8.3. Signals .........................................123 214 E.8.4. Statistics ......................................123 215 E.8.5. Procedures ......................................123 216 E.9. Analog Line Supervision Package ......................124 217 E.9.1. Properties ......................................124 218 E.9.2. Events ..........................................124 219 E.9.3. Signals .........................................124 220 E.9.4. Statistics ......................................125 221 E.9.5. Procedures ......................................125 222 E.10. Basic Continuity Package ............................125 223 E.10.1. Properties .....................................125 224 E.10.2. Events .........................................125 225 E.10.3. Signals ........................................126 226 E.10.4. Statistics .....................................126 227 E.10.5. Procedures .....................................126 228 E.11. Network Package .....................................126 229 E.11.1. Properties .....................................127 230 E.11.2. Events .........................................127 231 E.11.3. Signals ........................................128 232 E.11.4. Statistics .....................................128 233 E.11.5. Procedures .....................................128 234 E.12. RTP Package .........................................128 235 E.12.1. Properties .....................................128 236 E.12.2. Events .........................................129 237 E.12.3. Signals ........................................129 238 E.12.4. Statistics .....................................129 239 E.12.5. Procedures .....................................130 240 E.13. DS0 Package .........................................130 241 E.13.1. Properties .....................................130 242 E.13.2. Events .........................................131 244 Internet draft MEGACO Protocol January 27, 2000 246 E.13.3. Signals ........................................131 247 E.13.4. Statistics .....................................131 248 E.13.5. Procedures .....................................131 249 APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) ..............131 250 A.1. Residential Gateway to Residential Gateway Call ......131 251 A.1.1. Programming Residential GW Analog Line ..........131 252 A.1.2. Collecting Digits and Initiating Termination.....132 254 Internet draft MEGACO Protocol January 27, 2000 256 1. SCOPE 258 MEGACO defines the protocols used between elements of a physically 259 decomposed multimedia Gateway consisting of a Media Gateway and a Media 260 Gateway Controller. There are no functional differences from a system 261 view between a decomposed gateway, with distributed sub- components 262 potentially on more than one physical device, and a monolithic gateway. 263 This document does not define how gateways, multipoint control units or 264 integrated voice response units (IVRs) work. Instead it creates a gen- 265 eral framework that is suitable for these applications. 267 Packet network interfaces may include IP, ATM or possibly others. The 268 interfaces will support a variety of SCN signalling systems, including 269 tone signalling, ISDN, ISUP, QSIG, and GSM. National variants of these 270 signalling systems will be supported where applicable. 272 The protocol definition in this document is common text with ITU Recom- 273 mendation H.248. 275 2. REFERENCES 277 2.1. Normative references 279 ITU-T Recommendation H.225.0 (1998): "Call Signalling Protocols and 280 Media Stream Packetization for Packet Based Multimedia Communications 281 Systems". 283 ITU-T Recommendation H.235 (02/98): "Security and encryption for H- 284 Series (H.323 and other H.245-based) multimedia terminals". 286 ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia Com- 287 munication". 289 ITU-T Recommendation H.323 (1998): "Packet Based Multimedia Communica- 290 tion Systems". 292 ITU-T Recommendation I.363.1 (08/96), "B-ISDN ATM Adaptation Layer 293 specification: Type 1 AAL". 295 ITU-T Recommendation I.366.1 (06/98), "Segmentation and Reassembly 297 Internet draft MEGACO Protocol January 27, 2000 299 Service Specific Convergence Sublayer for the AAL type 2". 301 ITU-T Recommendation I.366.2 (02/99), "AAL type 2 service specific con- 302 vergence sublayer for trunking". 304 ITU-T Recommendation Q.931 (05/98): "Digital Subscriber Signalling Sys- 305 tem No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification 306 for Basic Call Control" 308 ITU-T Recommendation X.680 (1997): "Information technology-Abstract Syn- 309 tax Notation One (ASN.1): Specification of basic notation". 311 ITU-T draft Recommendation H.246 (1998), "Interworking of H-series mul- 312 timedia terminals with H-series multimedia terminals and voice/voiceband 313 terminals on GSTN and ISDN". 315 RFC 1006, "ISO Transport Service on top of the TCP, Version 3", Marshall 316 T. Rose, Dwight E. Cass, May 1987. 318 RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", 319 Scott Bradner, March 1997. RFC 2234, "Augmented BNF for Syntax Specifi- 320 cations: ABNF", D. Crocker, P. Overell, November 1997. 322 RFC 2327, "SDP: Session Description Protocol", M. Handley, V. Jacobson, 323 April 1998. 325 RFC 2402, "IP Authentication Header", S. Kent, R. Atkinson, November 326 1998. 328 RFC 2406, "IP Encapsulating Security Payload (ESP)", S. Kent, R. Atkin- 329 son, November 1998. 331 2.2. Informative references 333 ITU-T Recommendation E.180/Q.35 (1998): "Technical characteristics of 334 tones for the telephone service" 336 ITU-T Recommendation Q.724 (1988): "Signalling procedures" 338 RFC 768, "User Datagram Protocol", J.Postel, August 1980. 340 RFC 793, "TRANSMISSION CONTROL PROTOCOL", J.Postel, September 1981. 342 RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", H. 343 Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996. 345 RFC 1890, "RTP Profile for Audio and Video Conferences with Minimal Con- 346 trol", H. Schulzrinne, January 1996. 348 Internet draft MEGACO Protocol January 27, 2000 350 RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. 351 Atkinson, November 1998. 353 RFC 2543, " SIP: Session Initiation Protocol", M. Handley, H. 354 Schulzrinne, E. Schooler, J. Rosenberg, March 1999. 356 RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", S. Deer- 357 ing, R. Hinden, December 1998. 359 3. DEFINITIONS 361 Access Gateway: A type of gateway that provides a User to Network Inter- 362 face (UNI) such as ISDN. 364 Descriptor: A syntactic element of the protocol that groups related pro- 365 perties. For instance, the properties of a media flow on the MG can be 366 set by the MGC by including the appropriate descriptor in a command. 368 Media Gateway (MG): The media gateway converts media provided in one 369 type of network to the format required in another type of network. For 370 example, a MG could terminate bearer channels from a switched circuit 371 network (i.e., DS0s) and media streams from a packet network (e.g., RTP 372 streams in an IP network). This gateway may be capable of processing 373 audio, video and T.120 alone or in any combination, and will be capable 374 of full duplex media translations. The MG may also play audio/video mes- 375 sages and performs other IVR functions, or may perform media conferenc- 376 ing. 378 Media Gateway Controller (MGC): Controls the parts of the call state 379 that pertain to connection control for media channels in a MG. 381 Multipoint Control Unit (MCU): An entity that controls the setup and 382 coordination of a multi- user conference that typically includes pro- 383 cessing of audio, video and data. 385 Residential Gateway: A gateway that interworks an analogue line to a 386 packet network. A residential gateway typically contains one or two 387 analogue lines and is located at the customer premises. 389 SCN FAS Signalling Gateway: This function contains the SCN Signalling 390 Interface that terminates SS7, ISDN or other signalling links where the 391 call control channel and bearer channels are collocated in the same phy- 392 sical span. 394 SCN NFAS Signalling Gateway: This function contains the SCN Signalling 395 Interface that terminates SS7 or other signalling links where the call 396 control channels are separated from bearer channels. 398 Internet draft MEGACO Protocol January 27, 2000 400 Stream: Bidirectional media or control flow received/sent by a media 401 gateway as part of a call or conference. 403 Trunk: A communication channel between two switching systems such as a 404 DS0 on a T1 or E1 line. 406 Trunking Gateway: A gateway between SCN network and packet network that 407 typically terminates a large number of digital circuits. 409 4. ABBREVIATIONS 411 This recommendation defines the following terms. 412 ATM Asynchronous Transfer Mode 413 BRI Basic Rate Interface 414 CAS Channel Associated Signalling 415 DTMF Dual Tone Multi-Frequency 416 FAS Facility Associated Signalling 417 GW GateWay 418 IP Internet Protocol 419 ISUP ISDN User Part 420 MG Media Gateway 421 MGC Media Gateway Controller 422 NFAS Non-Facility Associated Signalling 423 PRI Primary Rate Interface 424 PSTN Public Switched Telephone Network 425 QoS Quality of Service 426 RTP Real-time Transport Protocol 427 SCN Switched Circuit Network 428 SG Signalling Gateway 429 SS7 Signalling System No. 7 431 5. CONVENTIONS 433 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 434 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 435 document are to be interpreted as described in RFC2119. 437 6. CONNECTION MODEL 439 The connection model for the protocol describes the logical entities, or 440 objects, within the Media Gateway that can be controlled by the Media 441 Gateway Controller. The main abstractions used in the connection model 442 are Terminations and Contexts. 444 A Termination sources and/or sinks one or more streams. In a multimedia 445 conference, a Termination can be multimedia and sources or sinks multi- 446 ple media streams. The media stream parameters, as well as modem, and 447 bearer parameters are encapsulated within the Termination. 449 Internet draft MEGACO Protocol January 27, 2000 451 A Context is an association between a collection of Terminations. There 452 is a special type of Context, the null Context, which contains all Ter- 453 minations that are not associated to any other Termination. For 454 instance, in a decomposed access gateway, all idle lines are represented 455 by Terminations in the null Context. 457 Following is a graphical depiction of these concepts. The diagram of 458 Figure 1 gives several examples and is not meant to be an all-inclusive 459 illustration. The asterisk box in each of the Contexts represents the 460 logical association of Terminations implied by the Context. 462 Internet draft MEGACO Protocol January 27, 2000 464 +------------------------------------------------------+ 465 |Media Gateway | 466 | +-------------------------------------------------+ | 467 | |Context +-------------+ | | 468 | | | Termination | | | 469 | | |-------------| | | 470 | | +-------------+ +->| SCN Bearer |<---+-> 471 | | | Termination | +-----+ | | Channel | | | 472 | | |-------------| | |---+ +-------------+ | | 473 <-+--->| RTP Stream |---| * | | | 474 | | | | | |---+ +-------------+ | | 475 | | +-------------+ +-----+ | | Termination | | | 476 | | | |-------------| | | 477 | | +->| SCN Bearer |<---+-> 478 | | | Channel | | | 479 | | +-------------+ | | 480 | +-------------------------------------------------+ | 481 | | 482 | | 483 | +------------------------------+ | 484 | |Context | | 485 | +-------------+ | +-------------+ | | 486 | | Termination | | +-----+ | Termination | | | 487 | |-------------| | | | |-------------| | | 488 <-+->| SCN Bearer | | | * |------| SCN Bearer |<---+-> 489 | | Channel | | | | | Channel | | | 490 | +-------------+ | +-----+ +-------------+ | | 491 | +------------------------------+ | 492 | | 493 | | 494 | +-------------------------------------------------+ | 495 | |Context | | 496 | | +-------------+ +-------------+ | | 497 | | | Termination | +-----+ | Termination | | | 498 | | |-------------| | | |-------------| | | 499 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> 500 | | | Channel | | | | Channel | | | 501 | | +-------------+ +-----+ +-------------+ | | 502 | +-------------------------------------------------+ | 503 | ___________________________________________________ | 504 +------------------------------------------------------+ 505 Figure 1: Example of MEGACO Connection Model 507 The example below shows an example of one way to accomplish a call- 508 waiting scenario in a decomposed access gateway, illustrating the relo- 509 cation of a Termination between Contexts. Terminations T1 and T2 belong 510 to Context C1 in a two-way audio call. A second audio call is waiting 512 Internet draft MEGACO Protocol January 27, 2000 514 for T1 from Termination T3. T3 is alone in Context C2. T1 accepts the 515 call from T3, placing T2 on hold. This action results in T1 moving into 516 Context C2, as shown below. 518 +------------------------------------------------------+ 519 |Media Gateway | 520 | +-------------------------------------------------+ | 521 | |Context C1 | | 522 | | +-------------+ +-------------+ | | 523 | | | Term. T2 | +-----+ | Term. T1 | | | 524 | | |-------------| | | |-------------| | | 525 <-+--->| RTP Stream |---| * |------| SCN Bearer |<---+-> 526 | | | | | | | Channel | | | 527 | | +-------------+ +-----+ +-------------+ | | 528 | +-------------------------------------------------+ | 529 | | 530 | +-------------------------------------------------+ | 531 | |Context C2 | | 532 | | +-------------+ | | 533 | | +-----+ | Term. T3 | | | 534 | | | | |-------------| | | 535 | | | * |------| SCN Bearer |<---+-> 536 | | | | | Channel | | | 537 | | +-----+ +-------------+ | | 538 | +-------------------------------------------------+ | 539 +------------------------------------------------------+ 540 Figure 2 Example Call Waiting Scenario / Alerting Applied to T1 542 Internet draft MEGACO Protocol January 27, 2000 544 +------------------------------------------------------+ 545 |Media Gateway | 546 | +-------------------------------------------------+ | 547 | |Context C1 | | 548 | | +-------------+ | | 549 | | | Term. T2 | +-----+ | | 550 | | |-------------| | | | | 551 <-+--->| RTP Stream |---| * | | | 552 | | | | | | | | 553 | | +-------------+ +-----+ | | 554 | +-------------------------------------------------+ | 555 | | 556 | +-------------------------------------------------+ | 557 | |Context C2 | | 558 | | +-------------+ +-------------+ | | 559 | | | Term. T1 | +-----+ | Term. T3 | | | 560 | | |-------------| | | |-------------| | | 561 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> 562 | | | Channel | | | | Channel | | | 563 | | +-------------+ +-----+ +-------------+ | | 564 | +-------------------------------------------------+ | 565 +------------------------------------------------------+ 566 Figure 3. Example Call Waiting Scenario / Answer by T1 568 6.1. Contexts 570 A Context is an association between a number of Terminations. The Con- 571 text describes the topology (who hears/sees whom) and the media mixing 572 and/or switching parameters if more than two Terminations are involved 573 in the association. 575 There is a special Context called the null Context. It contains Termina- 576 tions that are not associated to any other Termination. Terminations in 577 the null Context can have their parameters examined or modified, and may 578 have events detected on them. 580 In general, an Add command is used to add Terminations to Contexts. If 581 the MGC does not specify an existing Context to which the Termination is 582 to be added, the MG creates a new Context. A Termination may be removed 583 from a Context with a Subtract command, and a Termination may be moved 584 from one Context to another with a Move command. A Termination SHALL 585 exist in only one Context at a time. 587 The maximum number of Terminations in a Context is a MG property. Media 588 gateways that offer only point-to-point connectivity might allow at most 589 two Terminations per Context. Media gateways that support multipoint 591 Internet draft MEGACO Protocol January 27, 2000 593 conferences might allow three or more terminations per Context. 595 6.1.1. Context Attributes and Descriptors 597 The attributes of Contexts are: 599 ContextID, a 32 bit unsigned integer chosen by the MG. The topology 600 (who hears/sees whom). The topology of a Context describes the flow of 601 media between the Terminations within a Context. In contrast, the mode 602 of a Termination (send/receive/...) describes the flow of the media at 603 the ingress/egress of the media gateway. 605 The priority is used for a context in order to provide the MG with 606 information about a certain precedence handling for a context. The MGC 607 can also use the priority to control autonomously the traffic precedence 608 in the MG in a smooth way in certain situations (e.g. restart), when a 609 lot of contexts must be handled simultaneously. 611 * An indicator for an emergency call is also provided to allow a 612 preference handling in the MG. 614 6.1.2. Creating, Deleting and Modifying Contexts 616 The protocol can be used to (implicitly) create Contexts and modify the 617 parameter values of existing Contexts. The protocol has commands to add 618 Terminations to Contexts, subtract them from Contexts, and to move Ter- 619 minations between Contexts. Contexts are deleted implicitly when the 620 last remaining Termination is subtracted or moved out. 622 6.2. Terminations 624 A Termination is a logical entity on a MG that sources and/or sinks 625 media and/or control streams. A Termination is described by a number of 626 characterizing Properties, which are grouped in a set of Descriptors 627 that are included in commands. Terminations have unique identities (Ter- 628 minationIDs), assigned by the MG at the time of their creation. 630 Terminations representing physical entities have a semi-permanent 631 existence. For example, a Termination representing a TDM channel might 632 exist for as long as it is provisioned in the gateway. Terminations 633 representing ephemeral information flows, such as RTP flows, would usu- 634 ally exist only for the duration of their use. 636 Ephemeral Terminations are created by means of an Add command. They are 637 destroyed by means of a Subtract command. In contrast, when a physical 638 Termination is Added to or Subtracted from a Context, it is taken from 639 or to the null Context, respectively. 641 Internet draft MEGACO Protocol January 27, 2000 643 Terminations may have signals applied to them. Signals are MG generated 644 media streams such as tones and announcements as well as line signals 645 such as hookswitch. Terminations may be programmed to detect Events, 646 the occurrence of which can trigger notification messages to the MGC, or 647 action by the MG. Statistics may be accumulated on a Termination. 648 Statistics are reported to the MGC upon request (by means of the Audit- 649 Value command, see section 7.2.5) and when the Termination is taken out 650 of the call it is in. 652 Multimedia gateways may process multiplexed media streams. For example, 653 Recommendation H.221 describes a frame structure for multiple media 654 streams multiplexed on a number of digital 64 kbit/s channels. Such a 655 case is handled in the connection model in the following way. For every 656 bearer channel that carries part of the multiplexed streams, there is a 657 Termination. The Terminations that source/sink the digital channels are 658 connected to a separate Termination called the multiplexing Termination. 659 This Termination describes the multiplex used (e.g. how the H.221 frames 660 are carried over the digital channels used). The MuxDescriptor is used 661 to this end. If multiple media are carried, this Termination contains 662 multiple StreamDescriptors. The media streams can be associated with 663 streams sourced/sunk by other Terminations in the Context. 665 Terminations may be created which represent multiplexed bearers, such as 666 an ATM AAL2. When a new multiplexed bearer is to be created, an ephem- 667 eral termination is created in a context established for this purpose. 668 When the termination is subtracted, the multiplexed bearer is destroyed. 670 6.2.1. Termination Dynamics 672 The protocol can be used to create new Terminations and to modify pro- 673 perty values of existing Terminations. These modifications include the 674 possibility of adding or removing events and/or signals. The Termina- 675 tion properties, and events and signals are described in the ensuing 676 sections. An MGC can only release/modify terminations and the resources 677 that the termination represents which it has previously seized via, 678 e.g., the Add command. 680 6.2.2. TerminationIDs 682 Terminations are referenced by a TerminationID, which is an arbitrary 683 schema chosen by the MG. 685 TerminationIDs of physical Terminations are provisioned in the Media 686 Gateway. The TerminationIDs may be chosen to have structure. For 687 instance, a TerminationID may consist of trunk group and a trunk within 688 the group. 690 A wildcarding mechanism using two types of wildcards can be used with 692 Internet draft MEGACO Protocol January 27, 2000 694 TerminationIDs. The two wildcards are ALL and CHOOSE. The former is 695 used to address multiple Terminations at once, while the latter is used 696 to indicate to a media gateway that it must select a Termination satis- 697 fying the partially specified TerminationID. This allows, for instance, 698 that a MGC instructs a MG to choose a circuit within a trunk group. 700 When ALL is used in the TerminationID of a command, the effect is ident- 701 ical to repeating the command with each of the matching TerminationIDs. 702 Since each of these commands may generate a response, the size of the 703 entire response may be large. If individual responses are not required, 704 a wildcard response may be requested. In such a case, a single response 705 is generated, which contains the UNION of all of the individual 706 responses which otherwise would have been generated. Wildcard response 707 may be particularly useful in the Audit commands. 709 The encoding of the wildcarding mechanism is detailed in Annexes A and 710 B. 712 6.2.3. Packages 714 Different types of gateways may implement Terminations that have widely 715 differing characteristics. Variations in Terminations are accommodated 716 in the protocol by allowing Terminations to have optional Properties, 717 Events, Signals and Statistics implemented by MGs. 719 In order to achieve MG/MGC interoperability, such options are grouped 720 into Packages, and a Termination realizes a set of such Packages. More 721 information on definition of packages can be found in section 12. An 722 MGC can audit a Termination to determine which Packages it realizes. 724 Properties, Events, Signals and Statistics defined in Packages, as well 725 as parameters to them, are referenced by identifiers (Ids). Identifiers 726 are scoped. For each package, PropertyIds, EventIds, SignalIds, Statis- 727 ticsIds and ParameterIds have unique name spaces and the same identifier 728 may be used in each of them. Two PropertyIds in different packages may 729 also have the same identifier, etc. 731 6.2.4. Termination Properties and Descriptors 733 Terminations have properties. The properties have unique PropertyIDs. 734 Most properties have default values. When a Termination is created, 735 properties get their default values, unless the controller specifically 736 sets a different value. The default value of a property of a physical 737 Termination can be changed by setting it to a different value when the 738 Termination is in the null Context. Every time such a Termination 739 returns to the null Context, the values of its properties are reset to 740 this default value. 742 Internet draft MEGACO Protocol January 27, 2000 744 There are a number of common properties for Terminations and properties 745 specific to media streams. The common properties are also called the 746 termination state properties. For each media stream, there are local 747 properties and properties of the received and transmitted flows. 749 Properties not included in the base protocol are defined in Packages. 750 These properties are referred to by a name consisting of the PackageName 751 and a PropertyId. Most properties have default values described in the 752 Package description. Properties may be read-only or read/write. The pos- 753 sible values of a property may be audited, as can their current values. 754 For properties that are read/write, the MGC can set their values. A 755 property may be declared as "Global" which has a single value shared by 756 all terminations realizing the package. Related properties are grouped 757 into descriptors for convenience. 759 When a Termination is Added to a Context, the value of its read/write 760 properties can be set by including the appropriate descriptors as param- 761 eters to the Add command. Properties not mentioned in the command 762 retain their prior values. Similarly, a property of a Termination in a 763 Context may have its value changed by the Modify command. Properties 764 not mentioned in the Modify command retain their prior values. Proper- 765 ties may also have their values changed when a Termination is moved from 766 one Context to another as a result of a Move command. In some cases, 767 descriptors are returned as output from a command. The following table 768 lists all of the possible Descriptors and their use. Not all descrip- 769 tors are legal as input or output parameters to every command. Descrip- 770 tors 772 |Descriptor Name |Description | 773 |__________________|____________________________________________________| 774 |Modem |Identifies modem type and properties when | 775 | |applicable | 776 |__________________|____________________________________________________| 777 |Mux |Describes multiplex type for multimedia terminations| 778 | |(e.g. H.221, H.223, H.225.0) and Terminations | 779 | |forming the input mux. | 780 |__________________|____________________________________________________| 781 |Media |A list of media stream specifications (see 7.1.4) | 782 |__________________|____________________________________________________| 783 |TerminationState |Properties of a Termination (which can be defined in| 784 | |Packages) that are not stream specific. | 785 |__________________|____________________________________________________| 786 |Stream |A list of remote/local/localControl descriptors for | 787 | |a single stream | |__________________|____________________________________________________| 788 |Local |Contains properties that specify the media flows | 789 | |that MG receives from the remote entity. | 790 |__________________|____________________________________________________| 791 | | | 793 Internet draft MEGACO Protocol January 27, 2000 795 |Remote |Contains properties that specify the media flows | 796 | |that the MG sends to the remote entity. | |__________________|____________________________________________________| 797 |LocalControl |Contains properties (which can be defined in | 798 | |packages) that are of interest between the MG and | 799 | |the MGC | |__________________|____________________________________________________| 800 |Events |Describes events to be detected by the MG and what | 801 | |to do when an event is detected | |__________________|____________________________________________________| 802 |EventBuffer |Describes events to be detected by the MG when Event| 803 | |Buffering is active | |__________________|____________________________________________________| 804 |Signals |Describes signals and/or actions to be applied (e.g.| 805 | |Busy Tone) to the Terminations | |__________________|____________________________________________________| 806 |Audit |In Audit commands, identifies which information is | 807 | |desired | 808 |__________________|____________________________________________________| 809 |Packages |In AuditValue, returns a list of Packages realized | 810 | |by a Termination | |__________________|____________________________________________________| 811 |DigitMap |Instructions for handling DTMF tones at the MG | 812 |__________________|____________________________________________________| 813 |ServiceChange |In ServiceChange, what, why service change occurred,| 814 | |etc. | 815 |__________________|____________________________________________________| 816 |ObservedEvents |In Notify or AuditValue, report of events observed | 817 |__________________|____________________________________________________| 818 |Statistics |In Subtract and Audit, Report of Statistics kept on | 819 | |a Termination. | |__________________|____________________________________________________| 821 6.2.5. Root Termination 823 Occasionally, a command must refer to the entire gateway, rather than a 824 termination within it. A special TerminationID, "Root" is reserved for 825 this purpose. Packages may be defined on Root. Root thus may have pro- 826 perties and events (signals are not appropriate for root). Accord- 827 ingly, the root TerminationID may appear in: 829 * a Modify command - to change a property or set an event 831 * a Notify command - to report an event 833 * an AuditValue return - to examine the values of properties imple- 834 mented on root 836 * an AuditCapability - to determine what properties of root are 837 implemented 839 * a ServiceChange - to declare the gateway in or out of service Any 840 other use of the root TerminationID is an error. 842 Internet draft MEGACO Protocol January 27, 2000 844 7. COMMANDS 846 The protocol provides commands for manipulating the logical entities of 847 the protocol connection model, Contexts and Terminations. Commands pro- 848 vide control at the finest level of granularity supported by the proto- 849 col. For example, Commands exist to add Terminations to a Context, 850 modify Terminations, subtract Terminations from a Context, and audit 851 properties of Contexts or Terminations. Commands provide for complete 852 control of the properties of Contexts and Terminations. This includes 853 specifying which events a Termination is to report, which 854 signals/actions are to be applied to a Termination and specifying the 855 topology of a Context (who hears/sees whom). 857 Most commands are for the specific use of the Media Gateway Controller 858 as command initiator in controlling Media Gateways as command 859 responders. The exceptions are the Notify and ServiceChange commands: 860 Notify is sent from Media Gateway to Media Gateway Controller, and Ser- 861 viceChange may be sent by either entity. Below is an overview of the 862 commands; they are explained in more detail in section 7.2. 864 1. Add. The Add command adds a termination to a context. The Add com- 865 mand on the first Termination in a Context is used to create a Con- 866 text. 868 2. Modify. The Modify command modifies the properties, events and sig- 869 nals of a termination. 871 3. Subtract. The Subtract command disconnects a Termination from its 872 Context and returns statistics on the Termination's participation 873 in the Context. The Subtract command on the last Termination in a 874 Context deletes the Context. 876 4. Move. The Move command atomically moves a Termination to another 877 context. 879 5. AuditValue. The AuditValue command returns the current state of 880 properties, events, signals and statistics of Terminations. 882 6. AuditCapabilities. The AuditCapabilities command returns all the 883 possible values for Termination properties, events and signals 884 allowed by the Media Gateway. 886 7. Notify. The Notify command allows the Media Gateway to inform the 887 Media Gateway Controller of the occurrence of events in the Media 888 Gateway. 890 8. ServiceChange. The ServiceChange Command allows the Media Gateway 891 to notify the Media Gateway Controller that a Termination or group 893 Internet draft MEGACO Protocol January 27, 2000 895 of Terminations is about to be taken out of service or has just 896 been returned to service. ServiceChange is also used by the MG to 897 announce its availability to an MGC (registration), and to notify 898 the MGC of impending or completed restart of the MG. The MGC may 899 announce a handover to the MG by sending it a ServiceChange com- 900 mand. The MGC may also use ServiceChange to instruct the MG to 901 take a Termination or group of Terminations in or out of service. 903 These commands are detailed in sections 7.2.1 through 7.2.8 905 7.1. Descriptors 907 The parameters to a command are termed Descriptors. A Descriptor con- 908 sists of a name and a list of items. Some items may have values. Many 909 Commands share common Descriptors. This subsection enumerates these 910 Descriptors. Descriptors may be returned as output from a command. 911 Parameters and parameter usage specific to a given Command type are 912 described in the subsection that describes the Command. 914 7.1.1. Specifying Parameters 916 Command parameters are structured into a number of descriptors. In gen- 917 eral, the text format of descriptors is 918 DescriptorName={parm=value, parm=value....} 920 Parameters may be fully specified, over-specified or under-specified: 922 1. Fully specified parameters have a single, unambiguous value that 923 the command initiator is instructing the command responder to use 924 for the specified parameter. 926 2. Under-specified parameters, using the CHOOSE value, allow the com- 927 mand responder to choose any value it can support. 929 3. Over-specified parameters have a list of potential values. The 930 list order specifies the command initiator's order of preference of 931 selection. The command responder chooses one value from the 932 offered list and returns that value to the command initiator. 934 Unspecified mandatory parameters (i.e. mandatory parameters not speci- 935 fied in a descriptor) result in the command responder retaining the pre- 936 vious value for that parameter. Unspecified optional parameters result 937 in the command responder using the default value of the parameter. When- 938 ever a parameter is underspecified or overspecified, the descriptor con- 939 taining the value chosen by the responder is included as output from the 940 command. 942 Each command specifies the TerminationId the command operates on. This 944 Internet draft MEGACO Protocol January 27, 2000 946 TerminationId may be "wildcarded". When the TerminationId of a command 947 is wildcarded, the effect shall be as if the command was repeated with 948 each of the TerminationIds matched. 950 7.1.2. Modem Descriptor 952 The Modem descriptor specifies the modem type and parameters, if any, 953 required for use in e.g. H.324 and text conversation. The descriptor 954 includes the following modem types: V.18, V.22, V.22bis, V.32, V.32bis, 955 V.34, V.90, V.91, Synchronous ISDN, and allows for extensions. By 956 default, no modem descriptor is present in a Termination. 958 7.1.3. Multiplex Descriptor 960 In multimedia calls, a number of media streams are carried on a (possi- 961 bly different) number of bearers. The multiplex descriptor associates 962 the media and the bearers. The descriptor includes the multiplex type: 964 * H.221 966 * H.223, 968 * H.226, 970 * V.76, 972 * Possible Extensions 974 and a set of TerminationIDs representing the multiplexed inputs, in 975 order. For example: 977 Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22} 979 7.1.4. Media Descriptor 981 The Media Descriptor specifies the parameters for all the media streams. 982 These parameters are structured into two descriptors, a Termination 983 State Descriptor, which specifies the properties of a termination that 984 are not stream dependent, and one or more Stream Descriptors each of 985 which describes a single media stream. 987 A stream is identified by a StreamID. The StreamID is used to link the 988 streams in a Context that belong together. Multiple streams exiting a 989 termination shall be synchronized with each other. Within the Stream 990 Descriptor, there are up to three subsidiary descriptors, LocalControl, 991 Local, and Remote. The relationship between these descriptors is thus: 993 Internet draft MEGACO Protocol January 27, 2000 995 Media Descriptor 996 TerminationStateDescriptor 997 Stream Descriptor 998 LocalControl Descriptor 999 Local Descriptor 1000 Remote Descriptor 1002 StreamIDs are numbered from 1 upward. As a convenience a LocalControl, 1003 Local, or Remote descriptor may be included in the Media Descriptor 1004 without an enclosing Stream descriptor. In this case, the StreamID is 1005 assumed to be 1. 1007 7.1.5. Termination State Descriptor 1009 The Termination State Descriptor contains the ServiceStates property, 1010 the EventBuffer flag and properties of a termination (defined in Pack- 1011 ages) that are not stream specific. 1013 The ServiceStates property describes the overall state of the termina- 1014 tion (not stream-specific). A Termination can be in one of the follow- 1015 ing states: "test", "out of service", or "in service". The "test" state 1016 indicates that the termination is not used for normal traffic, but for 1017 testing. A Termination with state "test" cannot be seized for traffic. 1018 The state "out of service" indicates a fault in the termination and can- 1019 not be used for traffic. The state "in service" indicates that a termi- 1020 nation can be used or is being used for normal traffic. "in service" is 1021 the default state. 1023 Values assigned to Properties may be simple values 1024 (integer/string/enumeration) or may be underspecified, where more than 1025 one value is supplied and the MG may make a choice: 1027 * Alternative Values - multiple values in a list, one of which must 1028 be selected 1030 * Ranges - minimum and maximum values, any value between min and max 1031 must be selected, boundary values included 1033 * Greater Than/Less Than - value must be greater/less than specified 1034 value 1036 * CHOOSE Wildcard - the MG chooses from the allowed values for the 1037 property The EventBuffer flag specifies whether events are buffered 1038 following detection of an event in the Events Descriptor, or pro- 1039 cessed immediately. See section 7.1.9 for details. 1041 Internet draft MEGACO Protocol January 27, 2000 1043 7.1.6. Stream Descriptor 1045 A Stream descriptor specifies the parameters of a single bi-directional 1046 stream. These parameters are structured into three descriptors: one 1047 that contains termination properties specific to a stream and one each 1048 for local and remote flows. The Stream Descriptor includes a StreamID 1049 which identifies the stream. Streams are created by specifiying a new 1050 StreamID on one of the terminations in a Context. Streams are deleted by 1051 setting the Mode property in LocalControl to "delete" on one of the ter- 1052 minations in a Context. 1054 If a termination is moved from one context to another, the following 1055 applies: 1057 * if a streamID of an active stream in the moved termination matches 1058 a streamID in the context it was moved to, the associated stream 1059 remains active on that termination; 1061 * if a streamID of an active stream in the moved termination does not 1062 match any streamID in the context it was moved to, the stream SHALL 1063 be set to inactive; 1065 * if a stream is inactive on the moved termination, it SHALL remain 1066 inactive in the new context until its mode is changed explicitly; 1068 * the modes of streams on terminations already present in the new 1069 context are unaffected by the fact that a termination is moved into 1070 the context. 1072 7.1.7. LocalControl Descriptor 1074 The LocalControl Descriptor contains the Mode property, the Reserve pro- 1075 perty and properties of a termination (defined in Packages) that are 1076 stream specific, and are of interest between the MG and the MGC. Values 1077 of properties may be underspecified as in section 7.1.5 1079 The allowed values for the mode property are send-only, receive-only, 1080 send/receive, inactive, loop-back and delete. "Send" and "receive" are 1081 with respect to the exterior of the context, so that, for example, a 1082 stream set to mode=sendonly does not pass received media into the con- 1083 text. Signals and Events are not affected by mode. Mode set to delete 1084 is used to remove a stream from a termination. 1086 The boolean-valued Reserve property of a Termination indicates what the 1087 MG is expected to do when it receives a local and/or remote descriptor. 1089 If the value of Reserve is True, the MG SHALL reserve resources for all 1090 alternatives specified in the local and/or remote descriptors it 1092 Internet draft MEGACO Protocol January 27, 2000 1094 currently has resources available for. It SHALL respond with the alter- 1095 natives it reserves resources for. If it cannot not support any of the 1096 alternatives, it SHALL respond with a reply to the MGC that contains 1097 empty local and/or remote descriptors. 1099 If the value of Reserve is False, the MG SHALL choose one of the alter- 1100 natives specified in the local descriptor (if present) and one of the 1101 alternatives specified in the remote descriptor (if present). If the MG 1102 has not yet reserved resources to support the selected alternative, it 1103 SHALL reserve the resources. If, on the other hand, it already reserved 1104 resources for the Termination addressed (because of a prior exchange 1105 with Reserve equal to True), it SHALL release any excess resources it 1106 reserved previously. Finally, the MG shall send a reply to the MGC con- 1107 taining the alternatives for the local and/or remote descriptor that it 1108 selected. If the MG does not have sufficient resources to support any 1109 of the alternatives specified, is SHALL respond with error 510 (insuffi- 1110 cient resources). 1112 The default value of Reserve is False. 1114 A new setting of the LocalControl Descriptor completely replaces the 1115 previous setting of that descriptor in the MG. Thus to retain informa- 1116 tion from the previous setting the MGC must include that information in 1117 the new setting. If the MGC wishes to delete some information from the 1118 existing descriptor, it merely resends the descriptor (in a Modify com- 1119 mand) with the unwanted information stripped out 1121 7.1.8. Local and Remote Descriptors 1123 The MGC uses Local and Remote descriptors to reserve and commit MG 1124 resources for media decoding and encoding for the given Stream(s) and 1125 Termination to which they apply. The MG includes these descriptors in 1126 its response to indicate what it is actually prepared to support. The 1127 MG SHALL include additional properties and their values in its response 1128 if these properties are mandatory yet not present in the requests made 1129 by the MGC (e.g., by specifying detailed video encoding parameters where 1130 the MGC only specified the payload type). 1132 Local refers to the media received by the MG and Remote refers to the 1133 media sent by the MG. 1135 When text encoding the protocol, the descriptors consist of session 1136 descriptions as defined in SDP (RFC2327), except that the "s=", "t=" and 1137 "o=" lines are optional. When multiple session descriptions are provided 1138 in one descriptor, the "v=" lines are required as delimiters; otherwise 1139 they are optional. Implementations shall accept session descriptions 1140 that are fully conformant to RFC2327. When binary encoding the protocol 1141 the descriptor consists of groups of properties (tag-value pairs) as 1143 Internet draft MEGACO Protocol January 27, 2000 1145 specified in Annex C. Each such group may contain the parameters of a 1146 session description. 1148 Below, the semantics of the local and remote descriptors are specified 1149 in detail. The specification consists of two parts. The first part 1150 specifies the interpretation of the contents of the descriptor. The 1151 second part specifies the actions the MG must take upon receiving the 1152 local and remote descriptors. The actions to taken by the MG depend on 1153 the value of the Reserve property of the LocalControl descriptor. 1155 Either the local or the remote descriptor or both may be 1157 * unspecified (i.e., absent), 1159 * empty, 1161 * underspecified through use of CHOOSE in a property value, 1163 * fully specified, or 1165 * overspecified through presentation of multiple groups of proper- 1166 ties. 1168 Where the descriptors have been passed from the MGC to the MG, they are 1169 interpreted according to the rules given in section 7.1.1, with the fol- 1170 lowing additional comments for clarification: 1172 a) An unspecified Local or Remote descriptor is considered to be a 1173 missing mandatory parameter. It requires the MG to use whatever 1174 was last specified for that descriptor. It is possible that there 1175 was no previously-specified value, in which case the descriptor 1176 concerned is ignored in further processing of the command. 1178 b) An empty Local (Remote) descriptor in a message from the MGC signi- 1179 fies a request to release any resources reserved for the media flow 1180 received (sent). 1182 c) If multiple groups of properties are present in a Local or Remote 1183 descriptor, the order of preference is descending. 1185 d) Underspecified or overspecified properties within a group of pro- 1186 perties sent by the MGC are requests for the MG to choose a value 1187 which it can support for each of those properties. In case of an 1188 overspecified property, the list of values is in descending order 1189 of preference. 1191 Subject to the above rules, subsequent action depends on the value of 1192 the "Reserve" parameter in LocalControl. 1194 Internet draft MEGACO Protocol January 27, 2000 1196 If Reserve is true, the MG reserves the resources required to support 1197 any of the alternatives that it can currently support. 1199 NOTE - If a Local or Remote descriptor contains multiple groups of pro- 1200 perties, the MG is requested to reserve resources so that it can decode 1201 or encode one media stream according to any of the alternatives. For 1202 instance, if the Local descriptor contains two groups of properties, one 1203 specifying packetized G.711 A-law audio and the other G.723.1 audio, the 1204 MG reserves resources so that it can decode one audio stream encoded in 1205 G.711 A-law format or G.723.1 format. The MG should not reserve 1206 resources to decode two audio streams, one encoded in G.711 A-law and 1207 one in G.723.1. 1209 * If the MG has insufficient resources to support all alternatives 1210 requested by the MGC and the MGC requested resources in both Local 1211 and Remote, the MGC should reserve resources to support at least 1212 one alternative each within Local and Remote. 1214 * If the MG has insufficient resources to support at least one alter- 1215 native within a Local (Remote) descriptor received from the MGC, 1216 it shall return an empty Local (Remote) in response. 1218 * In its response to the MGC, the MG SHALL include local and remote 1219 descriptors for all groups of properties it reserved resources for. 1220 If the MG is incapable of supporting at least one of the alterna- 1221 tives within the Local (Remote) descriptor received from the MGC, 1222 it SHALL return an empty Local (Remote) descriptor. 1224 * If the Mode property of the TerminationState descriptor is RecvOnly 1225 or SendRecv, the MG must be prepared to receive media encoded 1226 according to any of the alternatives included in its response to 1227 the MGC. 1229 If Reserve is False then the MG SHOULD apply the following rules to 1230 resolve Local and Remote to a single alternative each: 1232 * If symmetric coding is not possible, the MG chooses the first 1233 alternative in Local for which it is able to support at least one 1234 alternative in Remote. 1236 * If the MG is unable to support at least one Local and one Remote 1237 alternative, it returns Error 510 (Insufficient Resources). 1239 * The MG returns its selected alternative in Local and Remote. 1241 A new setting of a Local or Remote Descriptor completely replaces the 1242 previous setting of that descriptor in the MG. Thus to retain informa- 1243 tion from the previous setting the MGC must include that information in 1245 Internet draft MEGACO Protocol January 27, 2000 1247 the new setting. If the MGC wishes to delete some information from the 1248 existing descriptor, it merely resends the descriptor (in a Modify com- 1249 mand) with the unwanted information stripped out. 1251 7.1.9. Events Descriptor 1253 The EventsDescriptor parameter contains a RequestIdentifier and a list 1254 of events that the Media Gateway is requested to detect and report. The 1255 RequestIdentifier is used to correlate the request with the notifica- 1256 tions that it may trigger. Requested events include, for example, fax 1257 tones, continuity tones, and on-hook and off-hook transitions. 1259 Each event in the descriptor contains the Event name, an optional 1260 streamID, an optional KeepActive flag, and optional parameters. The 1261 Event name consists of a Package Name (where the event is defined) and 1262 an EventID. The ALL wildcard may be used for the EventID, indicating 1263 that all events from the specified package have to be detected. The 1264 default streamIDis 0, indicating that the event to be detected is not 1265 related to a particular media stream. Events can have parameters. This 1266 allows a single event description to have some variation in meaning 1267 without creating large numbers of individual events. Further event 1268 parameters are defined in the package. 1270 The MG shall send a Notify command to the MGC when it detects an event 1271 in the Events Descriptor. If the EventBuffer flag is "on", following 1272 detection of such an event, normal handling of events is suspended, and 1273 any event found in the EventBuffer Descriptor which is subsequently 1274 detected is added to the end of a FIFO queue, along with the time that 1275 it was detected. A command containing an Events Descriptor which is 1276 received when the EventBuffer flag is on causes the following sequence 1277 to be executed: 1279 1. The first event in the FIFO queue is examined. If it is in the 1280 Events listed in the new events descriptor, the MG shall send a 1281 Notify command to the MGC and remove the event from the FIFO queue. 1282 The time stamp of the Notify shall be the time the event was actu- 1283 ally detected. 1285 2. If the event is not in the new Events Descriptor, it shall be dis- 1286 carded. 1288 3. If the queue is empty, the sequence shall be stopped, and normal 1289 event processing shall be resumed. If there are any events remain- 1290 ing in the queue, the sequence repeats. 1292 If the EventBuffer flag is off when the new Events Descriptor is 1293 received, the queue is flushed, and no events are added to it. The 1294 default state of EventBuffer is off. 1296 Internet draft MEGACO Protocol January 27, 2000 1298 Normally, detection of an event shall cause any active signals to stop. 1299 When KeepActive is specified in the event, the MG shall not interrupt 1300 any signals active on the Termination on which the event is detected. 1302 An event can include an Embedded Signals descriptor and/or an Embedded 1303 Events Descriptor which, if present, replaces the current Signals/Events 1304 descriptor when the event is detected. It is possible, for example, to 1305 specify that the dial-tone Signal be generated when an off-hook Event is 1306 detected, or that the dial-tone Signal be stopped when a digit is 1307 detected. A media gateway controller shall not send EventsDescriptors 1308 with an event both marked KeepActive and containing an embedded Sig- 1309 nalsDescriptor. 1311 Only one level of embedding is permitted. An embedded EventsDescriptor 1312 SHALL NOT contain another embedded EventsDescriptor. 1314 An Events Descriptor received by a media gateway replaces any previous 1315 Events Descriptor. Event notification in process shall complete, and 1316 events detected after the command containing the new EventsDescriptor 1317 executes, shall be processed according to the new EventsDescriptor. 1319 7.1.10. EventBuffer Descriptor 1321 The EventBuffer Descriptor contains a list of events, with their parame- 1322 ters if any, that the MG is requested to detect and buffer when no 1323 Events Descriptor is active (See 7.1.9). 1325 7.1.11. Signals Descriptor 1327 A SignalsDescriptor is a parameter that contains the set of signals that 1328 the Media Gateway is asked to apply to a Termination. A SignalsDescrip- 1329 tor contains a number of signals and/or sequential signal lists. A Sig- 1330 nalsDescriptor may contain zero signals and sequential signal lists. 1331 Support of sequential signal lists is optional. 1333 Signals are defined in packages. Signals shall be named with a Package 1334 name (in which the signal is defined) and a SignalID. No wildcard shall 1335 be used in the SignalID. Signals that occur in a SignalsDescriptor have 1336 an optional StreamID parameter (default is 0, to indicate that the sig- 1337 nal is not related to a particular media stream), an optional signal 1338 type (see below), an optional duration and possibly parameters defined 1339 in the package that defines the signal. This allows a single signal to 1340 have some variation in meaning, obviating the need to create large 1341 numbers of individual signals. Finally, there is an optional parameter 1342 "notifyCompletion" that allows a MGC to request being notified of com- 1343 pletion of the signal. The value of this parameter is a RequestIdentif- 1344 ier, allowing the MGC to correlate the Notify with the corresponding 1345 signal. 1347 Internet draft MEGACO Protocol January 27, 2000 1349 The duration is an integer value that is expressed in hundredths of a 1350 second. 1352 There are three types of signals: 1354 * on/off - the signal lasts until it is turned off, 1356 * timeout - the signal lasts until it is turned off or a specific 1357 period of time elapses, 1359 * brief - the signal duration is so short that it will stop on its 1360 own unless a new signal is applied that causes it to stop; no 1361 timeout value is needed. 1363 If the signal type is specified in a SignalsDescriptor, it overrides the 1364 default signal type (see Section 12.1.4). If duration is specified for 1365 an on/off signal, it SHALL be ignored. 1367 A sequential signal list consists of a signal list identifier, a 1368 sequence of signals to be played sequentially, and a signal type. Only 1369 the trailing element of the sequence of signals in a sequential signal 1370 list may be an on/off signal. If the trailing element of the sequence 1371 is an on/off signal, the signal type of the sequential signal list shall 1372 be on/off as well. If the sequence of signals in a sequential signal 1373 list contains signals of type timeout and the trailing element is not of 1374 type on/off, the type of the sequential signal list SHALL be set to 1375 timeout. The duration of a sequential signal list with type timeout is 1376 the sum of the durations of the signals it contains. If the sequence of 1377 signals in a sequential signal list contains only signals of type brief, 1378 the type of the sequential signal list SHALL be set to brief. A signal 1379 list is treated as a single signal of the specified type when played 1380 out. 1382 Multiple signals and sequential signal lists in the same SignalsDescrip- 1383 tor shall be played simultaneously. 1385 Signals are defined as proceeding from the termination towards the exte- 1386 rior of the Context unless otherwise specified in a package. When the 1387 same Signal is applied to multiple Terminations within one Transaction, 1388 the MG should consider using the same resource to generate these Sig- 1389 nals. 1391 Production of a Signal on a Termination is stopped by application of a 1392 new SignalsDescriptor, or detection of an Event on the Termination (see 1393 section 7.1.9). 1395 A new SignalsDescriptor replaces any existing SignalsDescriptor. Any 1396 signals applied to the Termination not in the replacement descriptor 1398 Internet draft MEGACO Protocol January 27, 2000 1400 shall be stopped, and new signals are applied. Signals present in both 1401 the existing and replacement descriptor, with the same parameters in 1402 both, shall be continued. If the replacement descriptor contains a 1403 sequential signal list with the same identifier as the existing descrip- 1404 tor, then 1406 * the signal type and sequence of signals in the sequential signal 1407 list in the replacement descriptor shall be ignored, and 1409 * the playing of the signals in the sequential signal list in the 1410 existing descriptor shall not be interrupted. 1412 If the MGC requested notification of completion for a signal, a Notify 1413 command SHALL be sent by the MG upon completion of that signal. A 1414 Notify triggered by completion of a signal SHALL NOT affect the state of 1415 the eventbuffer or any active events descriptor. 1417 7.1.12. Audit Descriptor 1419 Specifies what information is to be audited. The Audit Descriptor 1420 specifies the list of descriptors to be returned. Audit may be used in 1421 any command to force the return of a descriptor even if the descriptor 1422 in the command was not present, or had no underspecified parameters. 1423 Possible items in the Audit Descriptor are: 1425 ________________ 1426 | Modem | 1427 |_______________| 1428 | Mux | 1429 |_______________| 1430 | Events | 1431 |_______________| 1432 | Media | 1433 |_______________| 1434 | Signals | 1435 |_______________| 1436 | ObservedEvents| 1437 |_______________| 1438 | DigitMap | 1439 |_______________| 1440 | Statistics | 1441 |_______________| 1442 | Packages | 1443 |_______________| 1444 | EventBuffer | 1445 |_______________| 1447 Internet draft MEGACO Protocol January 27, 2000 1449 Audit may be empty, in which case, no descriptors are returned. This is 1450 useful in Subtract, to inhibit return of statistics, especially when 1451 using wildcard. 1453 7.1.13. ServiceChange Descriptor 1455 The ServiceChangeDescriptor contains the following parameters: 1457 * ServiceChangeMethod 1459 * ServiceChangeReason 1461 * ServiceChangeAddress 1463 * ServiceChangeDelay 1465 * Profile 1467 * Version 1469 * MGCIdToTry 1471 * TimeStamp 1473 See section 7.2.8 1475 7.1.14. DigitMap Descriptor 1477 A DigitMap is a dialing plan resident in the Media Gateway used for 1478 detecting and reporting digit events received on a Termination. The 1479 DigitMap Descriptor contains a DigitMap name and the DigitMap to be 1480 assigned. A digit map may be preloaded into the MG by management action 1481 and referenced by name in an EventsDescriptor, may be defined dynami- 1482 cally and subsequently referenced by name, or the actual digitmap itself 1483 may be specified in the EventsDescriptor. 1485 DigitMaps defined in a DigitMapDescriptor can occur in any of the stan- 1486 dard Termination manipulation Commands of the protocol. A DigitMap, 1487 once defined, can be used on all Terminations specified by the (possibly 1488 wildcarded) TerminationID in such a command. When a DigitMap is defined 1489 dynamically in a DigitMap Descriptor: 1491 * A new DigitMap is created by specifying a name that is not yet 1492 defined. The value shall be present. 1494 * A DigitMap value is updated by supplying a new value for a name 1495 that is already defined. Terminations presently using the digitmap 1496 shall continue to use the old definition; subsequent 1498 Internet draft MEGACO Protocol January 27, 2000 1500 EventsDescriptors specifying the name, including any EventsDescrip- 1501 tor in the command containing the DigitMap descriptor, shall use 1502 the new one. 1504 * A DigitMap is deleted by supplying an empty value for a name that 1505 is already defined. Terminations presently using the digitmap shall 1506 continue to use the old definition. 1508 The collection of digits according to a DigitMap may be protected by 1509 three timers, viz. a start timer (T), short timer (S), and long timer 1510 (L). 1512 1. The start timer (T) is used prior to any digits having been dialed. 1514 2. If the Media Gateway can determine that at least one more digit is 1515 needed for a digit string to match any of the allowed patterns in 1516 the digit map, then the interdigit timer value should be set to a 1517 long (L) duration (e.g.-16 seconds). 1519 3. If the DigitMap specifies that a variable number of additional 1520 digits may be needed then the short timer (S) is used. 1522 The timers are configurable parameters to a DigitMap. The Start timer 1523 is started at the beginning of every digit map use, but can be overrid- 1524 den. 1526 The formal syntax of the digit map is described by the DigitMap rule in 1527 the formal syntax description of the protocol (see Annex A and Annex B). 1528 A DigitMap, according to this syntax, is defined either by a string or 1529 by a list of strings. Each string in the list is an alternative number- 1530 ing scheme, specified either as a set of digits or timers, or as regular 1531 expression of digits and timers. Within a string, the digits "0" through 1532 "9" and letters "A" through a maximum value depending on the signalling 1533 system concerned, but never exceeding "K", correspond to specified 1534 events within a package which has been designated in the Events Descrip- 1535 tor on the termination to which the digit map is being applied. (The 1536 mapping between events and digit map symbols is defined in the documen- 1537 tation for packages associated with channel-associated signalling sys- 1538 tems such as DTMF, MF, or R2. Digits "0" through "9" MUST be mapped to 1539 the corresponding digit events within the signalling system concerned. 1540 Letters should be allocated in logical fashion, facilitating the use of 1541 range notation for alternative events.) The letter "x" is used as a 1542 wildcard, designating any event corresponding to symbols in the range 1543 "0"-"9". The string may also contain explicit ranges and, more gen- 1544 erally, explicit sets of symbols, designating alternative events any one 1545 of which satisfies that position of the digit map. 1547 In addition to these event symbols, the string may contain "S" and "L" 1549 Internet draft MEGACO Protocol January 27, 2000 1551 duration modifiers. An "L" designates a long event: placed in front of 1552 the symbol(s) designating the event(s) which satisfy a given digit posi- 1553 tion, it indicates that that position is satisfied only if the duration 1554 of the event exceeds the long-duration threshold. The value of this 1555 threshold is assumed to be provisioned in the MG. A MG that detects 1556 digits, letters or timers while a DigitMap is active SHALL: 1558 1. Add the event parameter to the end of an internal state variable 1559 referred to as the "current dial string". 1561 2. Apply the current dial string to the DigitMap, attempting a match 1562 to each regular expression in the DigitMap in lexical order. 1564 3. If the result is under-qualified (partially matches at least one 1565 entry in the DigitMap), do nothing further. 1567 4. If the result matches, or is over-qualified (i.e. no further digits 1568 could possibly produce a match), send the current dial string to 1569 the MGC in the digit string parameter of the completion event in 1570 the DTMF package (see section E.4.2). 1572 Note that unexpected timer expiries, for example, can cause over- 1573 qualified matches. The MG shall clear the current dial string when 1574 starting a new dial plan specified in an events descriptor or embedded 1575 events descriptor. 1577 As an example, consider the following dial plan: 1579 _______________________________________________________ 1580 | 0 | Local operator | 1581 | 00 | Long distance operator | 1582 | xxxx | Local extension number | 1583 | 8xxxxxxx | Local number | 1584 | #xxxxxxx | Off-site extension | 1585 | *xx | Star services | 1586 | 91xxxxxxxxxx | Long distance number | 1587 | 9011 + up to 15 digits | International number | 1588 |__________________________|___________________________| 1590 following digit map: 1592 (0S| 00S|[1-7]xLxx|8Lxxxxxxx|#xxxxxxx|*xx|9L1xxxxxxxxxx|9L011x.S) 1594 7.1.15. Statistics Descriptor 1596 The Statistics parameter provides information describing the status and 1597 usage of a Termination during its existence within a specific Context. 1599 Internet draft MEGACO Protocol January 27, 2000 1601 There is a set of standard statistics kept for each termination where 1602 appropriate (number of octets sent and received for example). The par- 1603 ticular statistical properties that are reported for a given Termination 1604 are determined by the Packages realized by the Termination. By default, 1605 statistics are reported when the Termination is Subtracted from the Con- 1606 text. This behavior can be overridden by including an empty Audit- 1607 Descriptor in the Subtract command. Statistics may also be returned 1608 from the AuditValue command, or any Add/Move/Modify command using the 1609 Audit descriptor. 1611 Statistics are cumulative; reporting Statistics does not reset them. 1612 Statistics are reset when a Termination is Subtracted from a Context. 1614 7.1.16. Packages Descriptor 1616 Used only with the AuditValue command, the PackageDescriptor returns a 1617 list of Packages realized by the Termination. 1619 7.1.17. ObservedEvents Descriptor 1621 ObservedEvents is supplied with the Notify command to inform the MGC of 1622 which event(s) were detected. Used with the AuditValue command, the 1623 ObservedEventsDescriptor returns events in the event buffer which have 1624 not been Notified. ObservedEvents contains the RequestIdentifier of the 1625 EventsDescriptor that triggered the notification, the event(s) detected 1626 and the detection time(s). If a Notify is sent as a result of a signal 1627 completion, the ObservedEventsDescriptor contains the name of the signal 1628 that completed and the time at which it completed. Detection times are 1629 reported with a precision of hundredths of a second. Time is expressed 1630 in UTC. 1632 7.1.18. Topology Descriptor 1634 A topology descriptor is used specify flow directions between termina- 1635 tions in a Context. Contrary to the descriptors in previous sections, 1636 the topology descriptor applies to a Context instead of a Termination. 1637 The default topology of a Context is that each termination's transmis- 1638 sion is received by all other terminations. The Topology Descriptor is 1639 optional to implement. 1641 The Topology Descriptor occurs before the commands in an action. It is 1642 possible to have an action containing only a Topology Descriptor, pro- 1643 vided that the context to which the action applies already exists. 1645 A topology descriptor consists of a sequence of triples of the form (T1, 1646 T2, association). T1 and T2 specify Terminations within the Context, 1647 possibly using the ALL or CHOOSE wildcard. The association specifies 1648 how media flows between these two Terminations as follows. 1650 Internet draft MEGACO Protocol January 27, 2000 1652 * (T1, T2, isolate) means that the Terminations matching T2 do not 1653 receive media from the Terminations matching T1, nor vice versa. 1655 * (T1, T2, oneway) means that the Terminations that match T2 receive 1656 media from the Terminations matching T1, but not vice versa. In 1657 this case use of the ALL wildcard such that there are Terminations 1658 that match both T1 and T2 is not allowed. 1660 * (T1, T2, bothway) means that the Terminations matching T2 receive 1661 media from the Terminations matching T1, and vice versa. In this 1662 case it is allowed to use wildcards such that there are Termina- 1663 tions that match both T1 and T2. However, if there is a Termina- 1664 tion that matches both, no loopback is introduced; loopbacks are 1665 created by setting the TerminationMode. 1667 CHOOSE wildcards may be used in T1 and T2 as well, under the following 1668 restrictions: 1670 * the action (see section 8) of which the topology descriptor is part 1671 contains an Add command in which a CHOOSE wildcard is used; 1673 * if a CHOOSE wildcard occurs in T1 or T2, then a partial name SHALL 1674 NOT be specified. 1676 The CHOOSE wildcard in a topology descriptor matches the TerminationID 1677 that the MG assigns in the first Add command that uses a CHOOSE wildcard 1678 in the same action. An existing Termination that matches T1 or T2 in 1679 the Context to which a Termination is added, is connected to the newly 1680 added Termination as specified by the topology descriptor. The default 1681 association when a termination is not mentioned in the Topology descrip- 1682 tor is bothway (if T3 is added to a context with T1 and T2 with topology 1683 (T3,T1,oneway) it will be connected bothway to T2). 1685 The figure below and the table following it show some examples of the 1686 effect of including topology descriptors in actions. 1688 Internet draft MEGACO Protocol January 27, 2000 1690 Context 1 Context 2 Context 3 1691 +------------------+ +------------------+ +------------------+ 1692 | +----+ | | +----+ | | +----+ | 1693 | | T2 | | | | T2 | | | | T2 | | 1694 | +----+ | | +----+ | | +----+ | 1695 | ^ ^ | | ^ | | ^ | 1696 | | | | | | | | | | 1697 | +--+ +--+ | | +---+ | | +--+ | 1698 | | | | | | | | | | 1699 | v v | | v | | | | 1700 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1701 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | 1702 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1703 +------------------+ +------------------+ +------------------+ 1704 1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway 1705 Context 1 Context 2 Context 3 1707 +------------------+ +------------------+ +------------------+ 1708 | +----+ | | +----+ | | +----+ | 1709 | | T2 | | | | T2 | | | | T2 | | 1710 | +----+ | | +----+ | | +----+ | 1711 | | | | ^ | | ^ ^ | 1712 | | | | | | | | | | 1713 | +--+ | | +---+ | | +--+ +--+ | 1714 | | | | | | | | | | 1715 | v | | v | | v v | 1716 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1717 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | 1718 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1719 +------------------+ +------------------+ +------------------+ 1720 1. T2, T3 oneway 2. T2, T3 bothway 3. T1, T2 bothway 1722 Figure 4: Example topologies 1724 Internet draft MEGACO Protocol January 27, 2000 1726 _______________________________________________________________________ 1727 |Topology | Description | 1728 |_________|____________________________________________________________| 1729 |1 |No topology descriptors. When no topology descriptors are | 1730 | |included, all terminations have a both way connection to all| 1731 | |other terminations. | |_________|____________________________________________________________| 1732 |2 |T1, T2, Isolated. Removes the connection between T1 and T2.| 1733 | |T3 has a both way connection with both T1 and T2. | 1734 |_________|____________________________________________________________| 1735 |3 |T3, T2, oneway. A oneway connection from T3 to T2 (i.e. T2 | 1736 | |receives media flow from T3). A bothway connection between | 1737 | |T1 and T3. | 1738 |_________|____________________________________________________________| 1739 |4 |T2, T3, oneway. A oneway connection between T2 to T3. | 1740 | |T1 and T3 remain bothway connected | 1741 |_________|____________________________________________________________| 1742 |5 |T2, T3 bothway. T2 is bothway connected to T3. | 1743 | |This results in the same as 2. | 1744 |_________|____________________________________________________________| 1745 |6 |T1, T2 bothway. (T2, T3 bothway and T1,T3 bothway may be | 1746 | |implied or explicit). terminations have a bothway | 1747 |_________|____________________________________________________________| 1749 A oneway connection must implemented in such a way that the other Termi- 1750 nations in the Context are not aware of the change in topology. 1752 7.2. Command Application Programming Interface 1754 Following is an Application Programming Interface (API) describing the 1755 Commands of the protocol. This API is shown to illustrate the Commands 1756 and their parameters and is not intended to specify implementation (e.g. 1757 via use of blocking function calls). It describes the input parameters 1758 in parentheses after the command name and the return values in front of 1759 the Command. This is only for descriptive purposes; the actual Command 1760 syntax and encoding are specified in later subsections. All parameters 1761 enclosed by square brackets ([. . . ]) are considered optional. 1763 7.2.1. Add 1765 The Add Command adds a Termination to a Context. 1767 TerminationID 1768 [,MediaDescriptor] 1769 [,ModemDescriptor] 1770 [,MuxDescriptor] 1772 Internet draft MEGACO Protocol January 27, 2000 1774 [,EventsDescriptor] 1775 [,SignalsDescriptor] 1776 [,DigitMapDescriptor] 1777 [,ObservedEventsDescriptor] 1778 [,EventBufferDescriptor] 1779 [,StatisticsDescriptor] 1780 [,PackagesDescriptor] 1781 Add( TerminationID 1782 [, MediaDescriptor] 1783 [, ModemDescriptor] 1784 [, MuxDescriptor] 1785 [, EventsDescriptor] 1786 [, SignalsDescriptor] 1787 [, DigitMapDescriptor] 1788 [, AuditDescriptor] 1789 ) 1791 The TerminationID specifies the termination to be added to the Context. 1792 The Termination is either created, or taken from the null Context. For 1793 an existing Termination, the TerminationID would be specific. For a 1794 Termination that does not yet exist, the TerminationID is specified as 1795 CHOOSE in the command. The new TerminationID will be returned. Wild- 1796 cards may be used in an Add, but such usage would be unusual. If the 1797 wildcard matches more than one TerminationID, all possible matches are 1798 attempted, with results reported for each one. The order of attempts 1799 when multiple TerminationIDs match is not specified. 1801 The optional MediaDescriptor describes all media streams. 1803 The optional ModemDescriptor and MuxDescriptor specify a modem and mul- 1804 tiplexer if applicable. For convenience, if a Multiplex Descriptor is 1805 present in an Add command and lists any Terminations that are not 1806 currently in the Context, such Terminations are added to the context as 1807 if individual Add commands listing the Terminations were invoked. If an 1808 error occurs on such an implied Add, error 471 - Implied Add for Multi- 1809 plex failure shall be returned and further processing of the command 1810 shall cease. 1812 The EventsDescriptor parameter is optional. If present, it provides the 1813 list of events that should be detected on the Termination. 1815 The SignalsDescriptor parameter is optional. If present, it provides 1816 the list of signals that should be applied to the Termination. 1818 The DigitMapDescriptor parameter is optional. If present, defines a 1819 DigitMap definition that may be used in an EventsDescriptor. 1821 Internet draft MEGACO Protocol January 27, 2000 1823 The AuditDescriptor is optional. If present, the command will return 1824 descriptors as specified in the AuditDescriptor. 1826 All descriptors that can be modified could be returned by MG if a param- 1827 eter was underspecified or overspecified. ObservedEvents, Statistics, 1828 and Packages, and the EventBuffer Descriptors are returned only if 1829 requested in the AuditDescriptor. Add SHALL NOT be used on a Termina- 1830 tion with a serviceState of "OutofService". 1832 7.2.2. Modify 1834 The Modify Command modifies the properties of a Termination. 1836 TerminationID 1837 [,MediaDescriptor] 1838 [,ModemDescriptor] 1839 [,MuxDescriptor] 1840 [,EventsDescriptor] 1841 [,SignalsDescriptor] 1842 [,DigitMapDescriptor] 1843 [,ObservedEventsDescriptor] 1844 [,EventBufferDescriptor] 1845 [,StatisticsDescriptor] 1846 [,PackagesDescriptor] 1847 Modify( TerminationID 1848 [, MediaDescriptor] 1849 [, ModemDescriptor] 1850 [, MuxDescriptor] 1851 [, EventsDescriptor] 1852 [, SignalsDescriptor] 1853 [, DigitMapDescriptor] 1854 [, AuditDescriptor] 1855 ) 1857 The TerminationID may be specific if a single Termination in the Context 1858 is to be modified. Use of wildcards in the TerminationID may be 1859 appropriate for some operations. If the wildcard matches more than one 1860 TerminationID, all possible matches are attempted, with results reported 1861 for each one. The order of attempts when multiple TerminationIDs match 1862 is not specified. The CHOOSE option is an error, as the Modify command 1863 may only be used on existing Terminations. 1865 The remaining parameters to Modify are the same as those to Add. Possi- 1866 ble return values are the same as those to Add. Modify SHALL NOT be 1867 used on a Termination with a serviceState of "OutofService". 1869 Internet draft MEGACO Protocol January 27, 2000 1871 7.2.3. Subtract 1873 The Subtract Command disconnects a Termination from its Context and 1874 returns statistics on the Termination's participation in the Context. 1876 TerminationID 1877 [,MediaDescriptor] 1878 [,ModemDescriptor] 1879 [,MuxDescriptor] 1880 [,EventsDescriptor] 1881 [,SignalsDescriptor] 1882 [,DigitMapDescriptor] 1883 [,ObservedEventsDescriptor] 1884 [,EventBufferDescriptor] 1885 [,StatisticsDescriptor] 1886 [,PackagesDescriptor] 1887 Subtract(TerminationID 1888 [, AuditDescriptor] 1889 ) 1891 TerminationID in the input parameters represents the Termination that is 1892 being subtracted. The TerminationID may be specific or may be a wild- 1893 card value indicating that all (or a set of related) Terminations in the 1894 Context of the Subtract Command are to be subtracted. If the wildcard 1895 matches more than one TerminationID, all possible matches are attempted, 1896 with results reported for each one. The order of attempts when multiple 1897 TerminationIDs match is not specified. The CHOOSE option is an error, as 1898 the Subtract command may only be used on existing Terminations. ALL may 1899 be used as the ContextID as well as the TerminationId in a Subtract, 1900 which would have the effect of deleting all contexts, deleting all 1901 ephemeral terminations, and returning all physical terminations to Null 1902 context. 1904 By default, the Statistics parameter is returned to report information 1905 collected on the Termination or Terminations specified in the Command. 1906 The information reported applies to the Termination's or 1907 Terminations'Termination's or Terminations' existence in the Context 1908 from which it or they are being subtracted. 1910 The AuditDescriptor is optional. If present, the command will return 1911 descriptors as specified in the AuditDescriptor. Possible return 1912 values are the same as those to Add. 1914 When a provisioned Termination is Subtracted from a context, its pro- 1915 perty values shall revert to: 1917 Internet draft MEGACO Protocol January 27, 2000 1919 * The default value, if specified for the property and not overridden 1920 by provisioning or modification within the null context 1922 * The provisioned value, if not overridden by modification in the 1923 null context 1925 * The last value set by a modification while the termination was in 1926 the null context. 1928 7.2.4. Move 1930 The Move Command moves a Termination to another Context from its current 1931 Context in one atomic operation. The Move command is the only command 1932 that refers to a Termination in a Context different from that to which 1933 the command is applied. The Move command shall not be used to move Ter- 1934 minations to or from the null Context. 1936 TerminationID 1937 [,MediaDescriptor] 1938 [,ModemDescriptor] 1939 [,MuxDescriptor] 1940 [,EventsDescriptor] 1941 [,SignalsDescriptor] 1942 [,DigitMapDescriptor] 1943 [,ObservedEventsDescriptor] 1944 [,EventBufferDescriptor] 1945 [,StatisticsDescriptor] 1946 [,PackagesDescriptor] 1947 Move( TerminationID 1948 [, MediaDescriptor] 1949 [, ModemDescriptor] 1950 [, MuxDescriptor] 1951 [, EventsDescriptor] 1952 [, SignalsDescriptor] 1953 [, DigitMapDescriptor] 1954 [, AuditDescriptor] 1955 ) 1957 The TerminationID specifies the Termination to be moved. It may be 1958 wildcarded. If the wildcard matches more than one TerminationID, all 1959 possible matches are attempted, with results reported for each one. The 1960 order of attempts when multiple TerminationIDs match is not specified. 1961 By convention, the Termination is subtracted from its previous Context. 1962 The Context to which the Termination is moved is indicated by the target 1963 ContextId in the Action. If the last remaining Termination is moved out 1964 of a Context, the Context is deleted. 1966 Internet draft MEGACO Protocol January 27, 2000 1968 The remaining descriptors are processed as in the Modify Command. The 1969 AuditDescriptor with the Statistics option, for example, would return 1970 statistics on the Termination just prior to the Move. Possible descrip- 1971 tors returned from Move are the same as for Add. Move SHALL NOT be used 1972 on a Termination with a serviceState of "OutofService". 1974 7.2.5. AuditValue 1976 The AuditValue Command returns the current values of properties, events, 1977 signals and statistics associated with Terminations. 1979 TerminationID 1980 [,MediaDescriptor] 1981 [,ModemDescriptor] 1982 [,MuxDescriptor] 1983 [,EventsDescriptor] 1984 [,SignalsDescriptor] 1985 [,DigitMapDescriptor] 1986 [,ObservedEventsDescriptor] 1987 [,EventBufferDescriptor] 1988 [,StatisticsDescriptor] 1989 [,PackagesDescriptor] 1990 AuditValue(TerminationID, 1991 AuditDescriptor 1992 ) 1994 TerminationID may be specific or wildcarded. If the wildcard matches 1995 more than one TerminationID, all possible matches are attempted, with 1996 results reported for each one. The order of attempts when multiple Ter- 1997 minationIDs match is not specified. If a wildcarded response is 1998 requested, only one command return is generated, with the contents con- 1999 taining the union of the values of all Terminations matching the wild- 2000 card. This convention may reduce the volume of data required to audit a 2001 group of Terminations. Use of CHOOSE is an error. 2003 The appropriate descriptors, with the current values for the Termina- 2004 tion, are returned from AuditValue. Values appearing in multiple 2005 instances of a descriptor are defined to be alternate values supported, 2006 with each parameter in a descriptor considered independent. 2008 ObservedEvents returns a list of events in the EventBuffer, Packages- 2009 Descriptor returns a list of packages realized by the Termination. 2010 DigitMapDescriptor returns the name or value of the current DigitMap for 2011 the Termination. DigitMap applied to the root Termination returns all 2012 named DigitMaps in the gateway. Statistics returns the current values 2013 of all statistics being kept on the Termination. Specifying an empty 2015 Internet draft MEGACO Protocol January 27, 2000 2017 Audit Descriptor results in only the TerminationID being returned. This 2018 may be useful to get a list of TerminationIDs when used with wildcard. 2020 AuditValue results depend on the Context, viz. specific, null, or 2021 unspecified. The TerminationID may be specific, or wildcarded. 2023 The following illustrates other information that can be obtained with 2024 the Audit Command: 2026 ________________________________________________________________________ 2027 |ContextID |TerminationID| Information Obtained | 2028 |Specific | wildcard |Audit of matching Terminations in a Context| 2029 |Specific | specific |Audit of a single Termination in a Context | 2030 |Null | Root |Audit of Media Gateway state and events | 2031 |Null | wildcard |Audit of all matching Terminations | 2032 |Null | specific |Audit of a single Termination outside of | 2033 | | |any Context | 2034 |All | wildcard |Audit of all matching Terminations and the | 2035 | | |Context to which they are associated | 2036 |All | Root | List of all ContextIds | 2037 |____________|_____________|___________________________________________| 2039 7.2.6. AuditCapabilities 2041 The AuditCapabilities Command returns the possible values of properties, 2042 events, signals and statistics associated with Terminations. 2044 TerminationID 2045 [,MediaDescriptor] 2046 [,ModemDescriptor] 2047 [,MuxDescriptor] 2048 [,EventsDescriptor] 2049 [,SignalsDescriptor] 2050 [,ObservedEventsDescriptor] 2051 [,EventBufferDescriptor] 2052 [,StatisticsDescriptor] 2053 AuditCapabilities(TerminationID, 2054 AuditDescriptor) 2056 The appropriate descriptors, with the possible values for the Termina- 2057 tion are returned from AuditCapabilities. Descriptors may be repeated 2058 where there are multiple possible values. values. If a wildcarded 2059 response is requested, only one command return is generated, with the 2060 contents containing the union of the values of all Terminations matching 2061 the wildcard. This convention may reduce the volume of data required to 2063 Internet draft MEGACO Protocol January 27, 2000 2065 audit a group of Terminations. 2067 Interpretation of what capabilities are requested for various values of 2068 ContextID and TerminationID is the same as in AuditValue. 2070 The EventsDescriptor returns the list of possible events on the Termina- 2071 tion together with the list of all possible values for the 2072 EventsDescriptor Parameters. The SignalsDescriptor returns the list of 2073 possible signals that could be applied to the Termination together with 2074 the list of all possible values for the Signals Parameters. Statis- 2075 ticsDescriptor returns the names of the statistics being kept on the 2076 termination. ObservedEventsDescriptor returns the names of active 2077 events on the termination. DigitMap and Packages are not legal in 2078 AuditCapability 2080 7.2.7. Notify 2082 The Notify Command allows the Media Gateway to notify the Media Gateway 2083 Controller of events occurring within the Media Gateway. 2085 Notify(TerminationID, 2086 ObservedEventsDescriptor) 2088 The TerminationID parameter specifies the Termination issuing the Notify 2089 Command. The TerminationID shall be a fully qualified name. 2091 The ObservedEventsDescriptor contains the RequestID and a list of events 2092 that the Media Gateway detected in the order that they were detected. 2093 Each event in the list is accompanied by parameters associated with the 2094 event and an indication of the time that the event was detected. Notify 2095 Commands shall occur only as the result of detection of an event speci- 2096 fied by an Events Descriptor which is active on the termination con- 2097 cerned, or as a result of completion of a signal for which the MGC 2098 requested notification of completion. 2100 The RequestID returns the RequestID parameter of the EventsDescriptor 2101 that triggered the Notify Command. It is used to correlate the notifi- 2102 cation with the request that triggered it. The events in the list must 2103 have been requested via the triggering EventsDescriptor, embedded events 2104 descriptor or the triggering SignalsDescriptor. 2106 A Notify triggered by completion of a signal, contains the corresponding 2107 signal name in the ObservedEventsDescriptor. 2109 7.2.8. ServiceChange 2111 The ServiceChange Command allows the Media Gateway to notify the Media 2113 Internet draft MEGACO Protocol January 27, 2000 2115 Gateway Controller that a Termination or group of Terminations is about 2116 to be taken out of service or has just been returned to service. The 2117 Media Gateway Controller may indicate that Termination(s) shall be taken 2118 out of or returned to service. The Media Gateway may notify the MGC 2119 that the capability of a Termination has changed. It also allows a MGC 2120 to hand over control of a MG to another MGC. 2122 [ServiceChangeDescriptor] 2123 ServiceChange(TerminationID, 2124 ServiceChangeDescriptor 2125 ) 2127 The TerminationID parameter specifies the Termination(s) that are taken 2128 out of or returned to service. Wildcarding of Termination names is per- 2129 mitted, with the exception that the CHOOSE mechanism shall not be used. 2130 Use of the "Root" TerminationID indicates a ServiceChange affecting the 2131 entire Media Gateway. 2133 The ServiceChangeDescriptor contains the following parameters as 2134 required: 2136 * ServiceChangeMethod 2138 * ServiceChangeReason 2140 * ServiceChangeDelay 2142 * ServiceChangeAddress 2144 * Profile 2146 * Version 2148 * MGCIdToTry 2150 * TimeStamp 2152 The ServiceChangeMethod parameter specifies the type of ServiceChange 2153 that will or has occurred: 2155 1) Graceful - indicates that the specified Terminations will be taken 2156 out of service after the specified ServiceChangeDelay; established 2157 connections are not yet affected, but the Media Gateway Controller 2158 should refrain from establishing new connections and should attempt 2159 to gracefully tear down existing connections. The MG should set 2160 termination serviceState to "test" until the expiry of Servi- 2161 ceChangeDelay or the removal of the termination from an active 2163 Internet draft MEGACO Protocol January 27, 2000 2165 context (whichever is first), then set it to "out of service". 2167 2) Forced - indicates that the specified Terminations were taken 2168 abruptly out of service and any established connections associated 2169 with them were lost. The MGC is responsible for cleaning up the 2170 context (if any) with which the failed termination is associated. 2171 At a minimum the termination shall be subtracted from the context. 2172 The termination serviceState should be "out of service". 2174 3) Restart - indicates that service will be restored on the specified 2175 Terminations after expiration of the ServiceChangeDelay. The ser- 2176 viceState should be set to "inService" upon expiry of Servi- 2177 ceChangeDelay. 2179 4) Disconnected - always applied with the Root TerminationID, indi- 2180 cates that the MG lost communication with the MGC, but it was sub- 2181 sequently restored. Since MG state may have changed, the MGC may 2182 wish to use the Audit command to resynchronize its state with the 2183 MG's. 2185 5) Handoff - sent from the MGC to the MG, this reason indicates that 2186 the MGC is going out of service and a new MGC association must be 2187 established. 2189 6) Failover - sent from MG to MGC to indicate the primary MG is out of 2190 service and a secondary MG is taking over, and sent from MG to 2191 (new) MGC in response to the MG having received a ServiceChange 2192 with ServiceChangeMethod equal to Handoff. 2194 The ServiceChangeReason parameter specifies the reason why the Servi- 2195 ceChange has or will occur. It consists of an alphanumeric token (IANA 2196 registered) and an explanatory string. 2198 The optional ServiceChangeAddress parameter specifies the address (e.g., 2199 IP port number for IP networks) to be used for subsequent communica- 2200 tions. It can be specified in the input parameter descriptor or the 2201 returned result descriptor. 2203 The optional ServiceChangeDelay parameter is expressed in seconds. If 2204 the delay is absent or set to zero, the delay value should be considered 2205 to be null. In the case of a "graceful" ServiceChangeMethod, a null 2206 delay indicates that the Media Gateway Controller should wait for the 2207 natural removal of existing connections and should not establish new 2208 connections. . For "graceful" only, null delay means the MG should set 2209 serviceState to "test" immediately, then wait indefinitely for the ter- 2210 mination to be removed from any active context before setting service- 2211 State to "out of service". For "restart", null means immediate return 2212 to service. 2214 Internet draft MEGACO Protocol January 27, 2000 2216 The optional Profile parameter specifies the Profile (if any) of the 2217 protocol supported. The Profile includes the version of the profile 2218 supported. 2220 The optional Version parameter contains the protocol version and is used 2221 if protocol version negotiation occurs (see section 11.3). 2223 The optional TimeStamp parameter specifies the actual time as kept by 2224 the sender. It can be used by the responder to determine how its notion 2225 of time differs from that of its correspondent. TimeStamp is sent with a 2226 precision of hundredths of a second, and is expressed in UTC. 2228 A ServiceChange Command specifying the "Root" for the TerminationID and 2229 ServiceChangeMethod equal to Restart is a registration command by which 2230 a Media Gateway announces its existence to the Media Gateway Controller. 2231 The Media Gateway is expected to be provisioned with the name of one 2232 primary and optionally some number of alternate Media Gateway Controll- 2233 ers. Acknowledgement of the ServiceChange Command completes the 2234 registration process. The MG may specify the transport ServiceChangeAd- 2235 dress to be used by the MGC for sending messages in the ServiceChangeAd- 2236 dress parameter in the input ServiceChangeDescriptor. The MGC shall use 2237 this Address, if specified, in its response to the ServiceChange command 2238 and any subsequent commands and responses. The MGC may specify the Ser- 2239 viceChangeAddress for the MG to use in the returned result Servi- 2240 ceDescriptor. The MG shall use this address for any subsequent communi- 2241 cation with the MGC. The TimeStamp parameter shall be sent with a 2242 registration command and its response. 2244 The Media Gateway Controller may return an MGCIdToTry parameter that 2245 describes the Media Gateway Controller that should preferably be con- 2246 tacted for further service by the Media Gateway. In this case the Media 2247 Gateway shall reissue the ServiceChange command to the new Media Gateway 2248 Controller. The Gateway specified in an MGCIdToTry, if provided, shall 2249 be contacted before any further alternate MGCs. On a HandOff message 2250 from MGC to MG, the MGCIdToTry is the new MGC that will take over from 2251 the current MGC. 2253 Summarizing use of properties in the ServiceChange Descriptor: 2255 * ServiceChangeMethod mandatory in all cases. 2257 * ServiceChangeReason mandatory in all cases. 2259 * ServiceChangeDelay mandatory if ServiceChangeMethod is "Graceful" 2260 or "Restart", otherwise not allowed. 2262 * ServiceChangeAddress mandatory when the terminationID is ROOT, oth- 2263 erwise not allowed. 2265 Internet draft MEGACO Protocol January 27, 2000 2267 * Profile required if terminationID is ROOT, optional otherwise. 2269 * Version as specified in section 11.3. 2271 * MGCIdToTry optional if the message comes from MGC and terminationID 2272 is ROOT, not allowed otherwise. 2274 * TimeStamp mandatory when terminationID is ROOT, optional otherwise. 2276 The return from ServiceChange has the same parameters as the input 2277 except that ServiceChangeMethod and ServiceChangeReason are optional. 2278 If provided they shall be the same as those specified in the command. 2280 The following ServiceChangeReasons are defined. This list may be 2281 extended by an IANA registration as outlined in section 13.3 2283 900 Service Restored 2284 901 MG Cold Boot 2285 902 MG Warm Boot 2286 903 MGC Directed Change 2287 904 Termination malfunctioning 2288 905 Termination taken out of service 2289 906 Loss of lower layer connectivity (e.g. downstream 2290 sync) 2291 907 Transmission Failure 2292 908 MG Impending Failure 2293 909 MGC Impending Failure 2294 910 Media Capability Failure 2295 911 Modem Capability Failure 2296 912 Mux Capability Failure 2297 913 Signal Capability Failure 2298 914 Event Capability Failure 2299 915 State Loss 2301 7.2.9. Manipulating and Auditing Context Attributes 2303 The commands of the protocol as discussed in the preceding sections 2304 apply to terminations. This section specifies how contexts are manipu- 2305 lated and audited. 2307 Commands are grouped into actions (see section 8). An action applies to 2308 one context. In addition to commands, it may contain context manipula- 2309 tion and auditing instructions. 2311 An action request sent to a MG may include a request to audit attributes 2312 of a context. An action may also include a request to change the attri- 2313 butes of a context. 2315 Internet draft MEGACO Protocol January 27, 2000 2317 The context properties that may be included in an action reply are used 2318 to return information to a MGC. This can be information requested by an 2319 audit of context attributes or details of the effect of manipulation of 2320 a context. 2322 If a MG receives an action which contains both a request to audit con- 2323 text attributes and a request to manipulate those attributes, the 2324 response SHALL include the values of the attributes after processing the 2325 manipulation request. 2327 7.2.10. Generic Command Syntax 2329 The protocol can be encoded in a binary format or in a text format. 2330 MGCs should support both encoding formats. MGs may support both for- 2331 mats. 2333 The protocol syntax for the binary format of the protocol is defined in 2334 Annex A. Annex C specifies the encoding of the Local and Remote 2335 descriptors for use with the binary format. 2337 A complete ABNF of the text encoding of the protocol per RFC2234 is 2338 given in Annex B. SDP, as modified herein is used as the encoding of 2339 the Local and Remote Descriptors for use with the text encoding. 2341 7.3. Command Error Codes 2343 Errors consist of an IANA registered error code and an explanatory 2344 string. Sending the explanatory string is optional. Implementations 2345 are encouraged to append diagnostic information to the end of the 2346 string. 2348 When a MG reports an error to a MGC, it does so in an error descriptor. 2349 An error descriptor consists of an error code and optionally the associ- 2350 ated explanatory string. 2352 The identified error codes are: 2354 400 - Bad Request 2355 401 - Protocol Error 2356 402 - Unauthorized 2357 403 - Syntax Error in Transaction 2358 404 - Syntax Error in TransactionReply 2359 405 - Syntax Error in TransactionPending 2360 406 - Version Not Supported 2361 410 - Incorrect identifier 2362 411 - The transaction refers to an unknown ContextId 2363 412 - No ContextIDs available 2364 421 - Unknown action or illegal combination of actions 2366 Internet draft MEGACO Protocol January 27, 2000 2368 422 - Syntax Error in Action 2369 430 - Unknown TerminationID 2370 431 - No TerminationID matched a wildcard 2371 432 - Out of TerminationIDs or No TerminationID available 2372 433 - TerminationID is already in a Context 2373 440 - Unsupported or unknown Package 2374 441 - Missing RemoteDescriptor 2375 442 - Syntax Error in Command 2376 443 - Unsupported or Unknown Command 2377 444 - Unsupported or Unknown Descriptor 2378 445 - Unsupported or Unknown Property 2379 446 - Unsupported or Unknown Parameter 2380 447 - Descriptor not legal in this command 2381 448 - Descriptor appears twice in a command 2382 450 - No such property in this package 2383 451 - No such event in this package 2384 452 - No such signal in this package 2385 453 - No such statistic in this package 2386 454 - No such parameter value in this package 2387 455 - Parameter illegal in this Descriptor 2388 456 - Parameter or Property appears twice in this Descriptor 2389 461 - TransactionIDs in Reply do not match Request 2390 462 - Commands in Transaction Reply do not match commands in request 2391 463 - TerminationID of Transaction Reply does not match request 2392 464 - Missing reply in Transaction Reply 2393 465 - TransactionID in Transaction Pending does not match any open request 2394 466 - Illegal Duplicate Transaction Request 2395 467 - Illegal Duplicate Transaction Reply 2396 471 - Implied Add for Multiplex failure 2398 500 - Internal Gateway Error 2399 501 - Not Implemented 2400 502 - Not ready. 2401 503 - Service Unavailable 2402 504 - Command Received from unauthorized entity 2403 505 - Command Received before Restart Response 2404 510 - Insufficient resources 2405 512 - Media Gateway unequipped to detect requested Event 2406 513 - Media Gateway unequipped to generate requested Signals 2407 514 - Media Gateway cannot send the specified announcement 2408 515 - Unsupported Media Type 2409 517 - Unsupported or invalid mode 2410 518 - Event buffer full 2411 519 - Out of space to store digit map 2412 520 - Media Gateway does not have a digit map 2413 521 - Termination is "ServiceChangeing" 2414 526 - Insufficient bandwidth 2415 529 - Internal hardware failure 2417 Internet draft MEGACO Protocol January 27, 2000 2419 530 - Temporary Network failure 2420 531 - Permanent Network failure 2421 581 - Does Not Exist 2423 8. TRANSACTIONS 2425 Commands between the Media Gateway Controller and the Media Gateway are 2426 grouped into Transactions, each of which is identified by a Transac- 2427 tionID. Transactions consist of one or more Actions. An Action con- 2428 sists of a series of Commands that are limited to operating within a 2429 single Context. Consequently each Action typically specifies a Contex- 2430 tID. However, there are two circumstances where a specific ContextID is 2431 not provided with an Action. One is the case of modification of a Ter- 2432 mination outside of a Context. The other is where the controller 2433 requests the gateway to create a new Context. Following is a graphic 2434 representation of the Transaction, Action and Command relationships. 2436 +----------------------------------------------------------+ 2437 | Transaction x | 2438 | +----------------------------------------------------+ | 2439 | | Action 1 | | 2440 | | +---------+ +---------+ +---------+ +---------+ | | 2441 | | | Command | | Command | | Command | | Command | | | 2442 | | | 1 | | 2 | | 3 | | 4 | | | 2443 | | +---------+ +---------+ +---------+ +---------+ | | 2444 | +----------------------------------------------------+ | 2445 | | 2446 | +----------------------------------------------------+ | 2447 | | Action 2 | | 2448 | | +---------+ | | 2449 | | | Command | | | 2450 | | | 1 | | | 2451 | | +---------+ | | 2452 | +----------------------------------------------------+ | 2453 | | 2454 | +----------------------------------------------------+ | 2455 | | Action 3 | | 2456 | | +---------+ +---------+ +---------+ | | 2457 | | | Command | | Command | | Command | | | 2458 | | | 1 | | 2 | | 3 | | | 2459 | | +---------+ +---------+ +---------+ | | 2460 | +----------------------------------------------------+ | 2461 +----------------------------------------------------------+ 2462 Figure 5 Transactions, Actions and Commands 2464 Transactions are presented as TransactionRequests. Corresponding 2466 Internet draft MEGACO Protocol January 27, 2000 2468 responses to a TransactionRequest are received in a single reply, possi- 2469 bly preceded by a number of TransactionPending messages (see section 2470 8.2.3). 2472 Transactions guarantee ordered Command processing. That is, Commands 2473 within a Transaction are executed sequentially. Ordering of Transactions 2474 is NOT guaranteed - transactions may be executed in any order, or simul- 2475 taneously. 2477 At the first failing Command in a Transaction, processing of the remain- 2478 ing Commands in that Transaction stops. If a command contains a wild- 2479 carded TerminationID, the command is attempted with each of the actual 2480 TerminationIDs matching the wildcard. A response within the Transac- 2481 tionReply is included for each matching TerminationID, even if one or 2482 more instances generated an error. If any TerminationID matching a 2483 wildcard results in an error when executed, any commands following the 2484 wildcarded command are not attempted. Commands may be marked as 2485 "Optional" which can override this behaviour - if a command marked as 2486 Optional results in an error, subsequent commands in the Transaction 2487 will be executed. 2489 A TransactionReply includes the return values for all of the Commands in 2490 the corresponding TransactionRequest. The TransactionReply includes the 2491 return values for the Commands that were executed successfully, and the 2492 Command and error descriptor for any Command that failed. Transaction- 2493 Pending is used to periodically notify the receiver that a Transaction 2494 has not completed yet, but is actively being processed. 2496 Applications SHOULD implement an application level timer per transac- 2497 tion. Expiration of the timer should cause a retransmission of the 2498 request. Receipt of a Reply should cancel the timer. Receipt of Pending 2499 should restart the timer. 2501 8.1. Common Parameters 2503 8.1.1. Transaction Identifiers 2505 Transactions are identified by a TransactionID, which is assigned by 2506 sender and is unique within the scope of the sender. 2508 8.1.2. Context Identifiers 2510 Contexts are identified by a ContextID, which is assigned by the Media 2511 Gateway and is unique within the scope of the Media Gateway. The Media 2512 Gateway Controller shall use the ContextID supplied by the Media Gateway 2513 in all subsequent Transactions relating to that Context. The protocol 2514 makes reference to a distinguished value that may be used by the Media 2516 Internet draft MEGACO Protocol January 27, 2000 2518 Gateway Controller when referring to a Termination that is currently not 2519 associated with a Context, namely the null ContextID. 2521 The CHOOSE wildcard is used to request that the Media Gateway create a 2522 new Context. The MGC shall not use partially specified ContextIDs con- 2523 taining the CHOOSE wildcard. The MGC may use the ALL wildcard to 2524 address all Contexts on the MG. 2526 8.2. Transaction Application Programming Interface 2528 Following is an Application Programming Interface (API) describing the 2529 Transactions of the protocol. This API is shown to illustrate the Tran- 2530 sactions and their parameters and is not intended to specify implementa- 2531 tion (e.g. via use of blocking function calls). It will describe the 2532 input parameters and return values expected to be used by the various 2533 Transactions of the protocol from a very high level. Transaction syntax 2534 and encodings are specified in later subsections. 2536 8.2.1. TransactionRequest 2538 The TransactionRequest is invoked by the sender. There is one Transac- 2539 tion per request invocation. A request contains one or more Actions, 2540 each of which specifies its target Context and one or more Commands per 2541 Context. 2543 TransactionRequest(TransactionId { 2544 ContextID {Command ... Command}, 2545 . . . 2546 ContextID {Command ... Command } }) 2548 The TransactionID parameter must specify a value for later correlation 2549 with the TransactionReply or TransactionPending response from the 2550 receiver. 2552 The ContextID parameter must specify a value to pertain to all Commands 2553 that follow up to either the next specification of a ContextID parameter 2554 or the end of the TransactionRequest, whichever comes first. 2556 The Command parameter represents one of the Commands mentioned in the 2557 "Command Details" subsection titled "Application Programming Interface". 2559 8.2.2. TransactionReply 2561 The TransactionReply is invoked by the receiver. There is one reply 2562 invocation per transaction. A reply contains one or more Actions, each 2563 of which must specify its target Context and one or more Responses per 2564 Context. 2566 Internet draft MEGACO Protocol January 27, 2000 2568 TransactionReply(TransactionID { 2569 ContextID { Response ... Response }, 2570 . . . 2571 ContextID { Response ... Response } }) 2573 The TransactionID parameter must be the same as that of the correspond- 2574 ing TransactionRequest. 2576 The ContextID parameter must specify a value to pertain to all Responses 2577 for the action. The ContextID may be specific or null. 2579 Each of the Response parameters represents a return value as mentioned 2580 in section 7.2, or an error descriptor if the command execution encoun- 2581 tered an error. Commands after the point of failure are not processed 2582 and, therefore, Responses are not issued for them. 2584 An exception to this occurs if a command has been marked as optional in 2585 the Transaction request. If the optional command generates an error, 2586 the transaction still continues to execute, so the Reply would, in this 2587 case, have Responses after an Error. 2589 If the receiver encounters an error in processing a ContextID, the 2590 requested Action response will consist of the context ID and a single 2591 error descriptor, 422 Syntax Error in Action. 2593 If the receiver encounters an error such that it cannot determine a 2594 legal Action, it will return a TransactionReply consisting of the Tran- 2595 sactionID and a single error descriptor, 422 Syntax Error in Action. If 2596 the end of an action cannot be reliably determined but one or more 2597 Actions can be parsed, it will process them and then send 422 Syntax 2598 Error in Action as the last action for the transaction.If the receiver 2599 encounters an error such that is cannot determine a legal Transaction, 2600 it will return a TransactionReply with a null TransactionID and a single 2601 error descriptor (403 Syntax Error in Transaction). 2603 If the end of a transaction can not be reliably determined and one or 2604 more Actions can be parsed, it will process them and then return 403 2605 Syntax Error in Transaction as the last action reply for the transac- 2606 tion. If no Actions can be parsed, it will return 403 Syntax Error in 2607 Transaction as the only reply 2609 If the terminationID cannot be reliably determined it will send 442 Syn- 2610 tax Error in Command as the action reply. 2612 If the end of a command cannot be reliably determined it will return 442 2613 Syntax Error in Transaction as the reply to the last action it can 2614 parse. 2616 Internet draft MEGACO Protocol January 27, 2000 2618 8.2.3. TransactionPending 2620 The receiver invokes the TransactionPending. A TransactionPending indi- 2621 cates that the Transaction is actively being processed, but has not been 2622 completed. It is used to prevent the sender from assuming the Transac- 2623 tionRequest was lost where the Transaction will take some time to com- 2624 plete. 2626 TransactionPending(TransactionID { } ) 2628 The TransactionID parameter must must be the same as that of the 2629 corresponding TransactionRequest. A property of root (normalMGExecu- 2630 tionTime) is settable by the MGC to indicate the interval within which 2631 the MGC expects a response to any transaction from the MG. Another pro- 2632 perty (normalMGCExecutionTime) is settable by the MGC to indicate the 2633 interval within which the MG should expects a response to any transac- 2634 tion from the MGC. Senders may receive more than one TransactionPending 2635 for a command. If a duplicate request is received when pending, the 2636 responder may send a duplicate pending immediately, or continue waiting 2637 for its timer to trigger another Transaction Pending. 2639 8.3. Messages 2641 Multiple Transactions can be concatenated into a Message. Messages have 2642 a header, which includes the identity of the sender. The Message Iden- 2643 tifier (MID) of a message is set to a provisioned name (e.g. domain 2644 address/domain name/device name) of the entity transmitting the message. 2645 Domain name is a suggested default. 2647 Every Message contains a Version Number identifying the version of the 2648 protocol the message conforms to. Versions are defined as in RFC2145, 2649 and consist of one or two digits. 2651 The transactions in a message are treated independently. There is no 2652 order implied, there is no application or protocol acknowledgement of a 2653 message. 2655 9. TRANSPORT 2657 The transport mechanism for the protocol should allow the reliable tran- 2658 sport of transactions between an MGC and MG. The transport shall remain 2659 independent of what particular commands are being sent and shall be 2660 applicable to all application states. There are several transports 2661 defined for the protocol, which are defined in normative Annexes to this 2662 document. Additional Transports may be defined as additional annexes in 2663 subsequent editions of this document, or in separate documents. For 2664 transport of the protocol over IP, MGCs shall implement both TCP and 2666 Internet draft MEGACO Protocol January 27, 2000 2668 UDP/ALF, an MG shall implement TCP or UDP/ALF or both. 2670 The MG is provisioned with a name or address (such as DNS name or IP 2671 address) of a primary and zero or more secondary MGCs (see section 2672 7.2.8) that is the address the MG uses to send messages to the MGC. 2673 The MGC receives the ServiceChange message from the MG and can determine 2674 the MGs address. Responses to commands are sent back to the source 2675 address of the commands. The initial ServiceChange message should be 2676 sent to the ServiceChangeAddress (in an IP network, port ???? if using 2677 TCP and port ???? if using UDP). The ServiceChange command contains a 2678 ServiceChangeAddress parameter. The MG specifies the address (e.g., 2679 TCP/UDP port number) it wishes the MGC to use for communication. The 2680 MGC replies with the ServiceChangeAddress set to the address it wishes 2681 the MG to use for further communications. 2683 9.1. Ordering of Commands 2685 This document does not mandate that the underlying transport protocol 2686 guarantees the sequencing of transactions sent to an entity. This pro- 2687 perty tends to maximize the timeliness of actions, but it has a few 2688 drawbacks. For example: 2690 * Notify commands may be delayed and arrive at the MGC after the 2691 transmission of a new command changing the EventsDescriptor 2693 * If a new command is transmitted before a previous one is ack- 2694 nowledged, there is no guarantee that prior command will be exe- 2695 cuted before the new one. 2697 Media Gateway Controllers that want to guarantee consistent operation of 2698 the Media Gateway may use the following rules: 2700 1. When a Media Gateway handles several Terminations, commands per- 2701 taining to the different Terminations may be sent in parallel, for 2702 example following a model where each Termination (or group of Ter- 2703 minations) is controlled by its own process or its own thread. 2705 2. In a given Context, there should normally be at most one outstand- 2706 ing command (Add or Modify or Move). However, a Subtract command 2707 may be issued at any time. In consequence, a Media Gateway may 2708 sometimes receive a Modify command that applies to a previously 2709 subtracted Termination. Such commands should be ignored, and an 2710 error code should be returned. 2712 3. On a given Termination, there should normally be at most one out- 2713 standing Notify command at any time. The RequestId parameter 2714 should be used to correlate Notify commands with the triggering 2715 notification request. 2717 Internet draft MEGACO Protocol January 27, 2000 2719 4. In some cases, an implicitly or explicitly wildcarded Subtract com- 2720 mand that applies to a group of Terminations may step in front of a 2721 pending Add command. The Media Gateway Controller should individu- 2722 ally delete all connections whose completion was pending at the 2723 time of the global Subtract command. Also, new Add commands for 2724 Terminations named by the wild-carding (or implied in a Multiplex 2725 descriptor) may not be sent until the wild-carded Subtract command 2726 is acknowledged. 2728 5. AuditValue and AuditCapability are not subject to any sequencing. 2730 6. ServiceChange shall always be the first command sent by a MG as 2731 defined by the restart procedure. Any other command or response 2732 must be delivered after this ServiceChange command. These rules do 2733 not affect the command responder, which should always respond to 2734 commands. 2736 9.2. Protection against Restart Avalanche 2738 In the event that a large number of Media Gateways are powered on simul- 2739 taneously and they were to all initiate a ServiceChange transaction, the 2740 Media Gateway Controller would very likely be swamped, leading to mes- 2741 sage losses and network congestion during the critical period of service 2742 restoration. In order to prevent such avalanches, the following behavior 2743 is suggested: 2745 1. When a Media Gateway is powered on, it should initiate a restart 2746 timer to a random value, uniformly distributed between 0 and a max- 2747 imum waiting delay (MWD). Care should be taken to avoid synchroni- 2748 city of the random number generation between multiple Media Gate- 2749 ways that would use the same algorithm. 2751 2. The Media Gateway should then wait for either the end of this timer 2752 or the detection of a local user activity, such as for example an 2753 off-hook transition on a residential Media Gateway. 2755 3. When the timer elapses, or when an activity is detected, the Media 2756 Gateway should initiate the restart procedure. 2758 The restart procedure simply requires the MG to guarantee that the first 2759 message that the Media Gateway Controller sees from this MG is a Servi- 2760 ceChange message informing the Media Gateway Controller about the res- 2761 tart 2763 The value of MWD is a configuration parameter that depends on the type 2764 of the Media Gateway. The following reasoning may be used to determine 2765 the value of this delay on residential gateways. 2767 Internet draft MEGACO Protocol January 27, 2000 2769 Media Gateway Controllers are typically dimensioned to handle the peak 2770 hour traffic load, during which, in average, 10% of the lines will be 2771 busy, placing calls whose average duration is typically 3 minutes. The 2772 processing of a call typically involves 5 to 6 Media Gateway Controller 2773 transactions between each Media Gateway and the Media Gateway Con- 2774 troller. This simple calculation shows that the Media Gateway Con- 2775 troller is expected to handle 5 to 6 transactions for each Termination, 2776 every 30 minutes on average, or, to put it otherwise, about one transac- 2777 tion per Termination every 5 to 6 minutes on average. This suggests 2778 that a reasonable value of MWD for a residential gateway would be 10 to 2779 12 minutes. In the absence of explicit configuration, residential gate- 2780 ways should adopt a value of 600 seconds for MWD. 2782 The same reasoning suggests that the value of MWD should be much shorter 2783 for trunking gateways or for business gateways, because they handle a 2784 large number of Terminations, and also because the usage rate of these 2785 Terminations is much higher than 10% during the peak busy hour, a typi- 2786 cal value being 60%. These Terminations, during the peak hour, are this 2787 expected to contribute about one transaction per minute to the Media 2788 Gateway Controller load. A reasonable algorithm is to make the value of 2789 MWD per "trunk" Termination six times shorter than the MWD per residen- 2790 tial gateway, and also inversely proportional to the number of Termina- 2791 tions that are being restarted. For example MWD should be set to 2.5 2792 seconds for a gateway that handles a T1 line, or to 60 milliseconds for 2793 a gateway that handles a T3 line. 2795 10. SECURITY CONSIDERATIONS 2797 This section covers security when using the protocol in an IP environ- 2798 ment. 2800 10.1. Protection of Protocol Connections 2802 A security mechanism is clearly needed to prevent unauthorized entities 2803 from using the protocol defined in this document for setting up unau- 2804 thorized calls or interfering with authorized calls. The security 2805 mechanism for the protocol when transported over IP networks is IPsec 2806 [RFC2401 to RFC2411]. 2808 The AH header [RFC2402] affords data origin authentication, connection- 2809 less integrity and optional anti-replay protection of messages passed 2810 between the MG and the MGC. The ESP header [RFC2406] provides confiden- 2811 tiality of messages, if desired. For instance, the ESP encryption ser- 2812 vice should be requested if the session descriptions are used to carry 2813 session keys, as defined in SDP. 2815 Implementations of the protocol defined in this document employing the 2816 ESP header SHALL comply with section 5 of [RFC2406], which defines a 2818 Internet draft MEGACO Protocol January 27, 2000 2820 minimum set of algorithms for integrity checking and encryption. Simi- 2821 larly, implementations employing the AH header SHALL comply with section 2822 5 of [RFC2402], which defines a minimum set of algorithms for integrity 2823 checking using manual keys. 2825 Implementations SHOULD use IKE [RFC2409] to permit more robust keying 2826 options. Implementations employing IKE SHOULD support authentication 2827 with RSA signatures and RSA public key encryption. 2829 10.2. Interim AH scheme 2831 Implementation of IPsec requires that the AH or ESP header be inserted 2832 immediately after the IP header. This cannot be easily done at the 2833 application level. Therefore, this presents a deployment problem for 2834 the protocol defined in this document where the underlying network 2835 implementation does not support IPsec. 2837 As an interim solution, an optional AH header is defined within the 2838 MEGACO protocol header. The header fields are exactly those of the SPI, 2839 SEQUENCE NUMBER and DATA fields as defined in [RFC2402]. The semantics 2840 of the header fields are the same as the "transport mode" of [RFC2402], 2841 except for the calculation of the Integrity Check value (ICV). In IPsec, 2842 the ICV is calculated over the entire IP packet including the IP header. 2843 This prevents spoofing of the IP addresses. To retain the same func- 2844 tionality, the ICV calculation should be performed across the entire 2845 transaction prepended by a synthesized IP header consisting of a 32 bit 2846 source IP address, a 32 bit destination address and an 16 bit UDP 2847 encoded as 10 hex digits. When the interim AH mechanism is employed when 2848 TCP is the transport Layer, the UDP Port above becomes the TCP port, and 2849 all other operations are the same. 2851 Implementations of the MEGACO protocol SHALL implement IPsec where the 2852 underlying operating system and the transport network supports IPsec. 2853 Implementations of the protocol using IPv4 SHALL implement the interim 2854 AH scheme. However, this interim scheme SHALL NOT be used when the 2855 underlying network layer supports IPsec. IPv6 implementations are 2856 assumed to support IPsec and SHALL NOT use the interim AH scheme. 2858 All implementations of the interim AH mechanism SHALL comply with sec- 2859 tion 5 of [RFC2402] which defines a minimum set of algorithms for 2860 integrity checking using manual keys. 2862 The interim AH interim scheme does not provide protection against eaves- 2863 dropping; thus forbidding third parties from monitoring the connections 2864 set up by a given termination. Also, it does not provide protection 2865 against replay attacks. These procedures do not necessarily protect 2866 against denial of service attacks by misbehaving MGs or misbehaving 2867 MGCs. However, they will provide an identification of these misbehaving 2869 Internet draft MEGACO Protocol January 27, 2000 2871 entities, which should then be deprived of their authorization through 2872 maintenance procedures. 2874 10.3. Protection of Media Connections 2876 The protocol allows the MGC to provide MGs with "session keys" that can 2877 be used to encrypt the audio messages, protecting against eavesdropping. 2879 A specific problem of packet networks is "uncontrolled barge-in". This 2880 attack can be performed by directing media packets to the IP address and 2881 UDP port used by a connection. If no protection is implemented, the 2882 packets must be decompressed and the signals must be played on the "line 2883 side". 2885 A basic protection against this attack is to only accept packets from 2886 known sources, checking for example that the IP source address and UDP 2887 source port match the values announced in the Remote Descriptor. This 2888 has two inconveniences: it slows down connection establishment and it 2889 can be fooled by source spoofing: 2891 * To enable the address-based protection, the MGC must obtain the 2892 remote session description of the egress MG and pass it to the 2893 ingress MG. This requires at least one network roundtrip, and 2894 leaves us with a dilemma: either allow the call to proceed without 2895 waiting for the round trip to complete, and risk for example, 2896 "clipping" a remote announcement, or wait for the full roundtrip 2897 and settle for slower call-set-up procedures. 2899 * Source spoofing is only effective if the attacker can obtain valid 2900 pairs of source destination addresses and ports, for example by 2901 listening to a fraction of the traffic. To fight source spoofing, 2902 one could try to control all access points to the network. But 2903 this is in practice very hard to achieve. 2905 An alternative to checking the source address is to encrypt and authen- 2906 ticate the packets, using a secret key that is conveyed during the call 2907 set-up procedure. This will not slow down the call set- up, and provides 2908 strong protection against address spoofing. 2910 11. MG-MGC CONTROL INTERFACE 2912 The control association between MG and MGC is initiated at MG cold 2913 start, and announced by a ServiceChange message, but can be changed by 2914 subsequent events, such as failures or manual service events. While the 2915 protocol does not have an explicit mechanism to support multiple MGCs 2916 controlling a physical MG, it has been designed to support the multiple 2917 logical MG (within a single physical MG) that can be associated with 2918 different MGCs. 2920 Internet draft MEGACO Protocol January 27, 2000 2922 11.1. Multiple Virtual MGs 2924 A physical Media Gateway may be partitioned into one or more Virtual 2925 MGs. A virtual MG consists of a set of statically partitioned physical 2926 Terminations and/or sets of ephemeral Terminations. A physical Termina- 2927 tion is controlled by one MGC. The model does not require that other 2928 resources be statically allocated, just Terminations. The mechanism for 2929 allocating Terminations to virtual MGs is a management method outside 2930 the scope of the protocol. Each of the virtual MGs appears to the MGC 2931 as a complete MG client. 2933 A physical MG may have only one network interface, which must be shared 2934 across virtual MGs. In such a case, the packet/cell side Termination is 2935 shared. It should be noted however, that in use, such interfaces 2936 require an ephemeral instance of the Termination to be created per flow, 2937 and thus sharing the Termination is straightforward. This mechanism 2938 does lead to a complication, namely that the MG must always know which 2939 of its controlling MGCs should be notified if an event occurs on the 2940 interface. 2942 In normal operation, the Virtual MG will be instructed by the MGC to 2943 create network flows (if it is the originating side), or to expect flow 2944 requests (if it is the terminating side), and no confusion will arise. 2945 However, if an unexpected event occurs, the Virtual MG must know what to 2946 do with respect to the physical resources it is controlling. 2948 If recovering from the event requires manipulation of a physical 2949 interface's state, only one MGC should do so. These issues are resolved 2950 by allowing any of the MGCs to create EventsDescriptors to be notified 2951 of such events, but only one MGC can have read/write access to the phy- 2952 sical interface properties; all other MGCs have read-only access. The 2953 management mechanism is used to designate which MGC has read/write capa- 2954 bility, and is designated the Master MGC. 2956 Each virtual MG has its own Root Termination. In most cases the values 2957 for the properties of the Root Termination are independently settable by 2958 each MGC. Where there can only be one value, the parameter is read-only 2959 to all but the Master MGC. 2961 ServiceChange may only be applied to a Termination or set of Termina- 2962 tions partitioned to the Virtual MG or created (in the case of ephemeral 2963 Terminations) by that Virtual MG. ServiceChange may only be applied to 2964 the Root by the Master MGC. 2966 11.2. Cold Start 2968 A MG is pre-provisioned by a management mechanism outside the scope of 2969 this protocol with a Primary and (optionally) an ordered list of 2971 Internet draft MEGACO Protocol January 27, 2000 2973 Secondary MGCs. Upon a cold start of the MG, it will issue a Servi- 2974 ceChange command with a "Restart" method, on the Root Termination to its 2975 primary MGC. If the MGC accepts the MG, it will send a Transaction 2976 Accept, with the MGCIdToTry set to itself. If the MG receives an MGCId- 2977 ToTry not equal to the MGC it contacted, it sends a ServiceChange to the 2978 MGC specified in the MGCIdToTry. It continues this process until it 2979 gets a controlling MGC to accept its registration, or it fails to get a 2980 reply. Upon failure to obtain a reply, either from the Primary MGC, or a 2981 designated successor, the MG tries its pre-provisioned Secondary MGCs, 2982 in order. If the MG is unable to establish a control relationship with 2983 any MGC, it shall wait a random amount of time as described in section 2984 9.2 and then start contacting its primary, and if necessary, its secon- 2985 dary MGCs again. 2987 It is possible that the reply to a ServiceChange with Restart will be 2988 lost, and a command will be received by the MG prior to the receipt of 2989 the ServiceChange response. The MG shall issue error 505 - Command 2990 Received before Restart Response. 2992 11.3. Negotiation of Protocol Version 2994 The first ServiceChange command from an MG shall contain the version 2995 number of the protocol supported by the MG in the ServiceChangeVersion 2996 parameter. Upon receiving such a message, if the MGC supports only a 2997 lower version, then the MGC shall send a ServiceChangeReply with the 2998 lower version and thereafter all the messages between MG and MGC shall 2999 conform to the lower version of the protocol. If the MG is unable to 3000 comply, it shall reject the association, with Error 406 Version Not Sup- 3001 ported. 3003 If the MGC supports a higher version than the MG but is able to support 3004 the lower version proposed by the MG, it shall send a ServiceChangeReply 3005 with the lower version and thereafter all the messages between MG and 3006 MGC shall conform to the lower version of the protocol. If the MGC is 3007 unable to comply, it shall reject the association, with Error 406 Ver- 3008 sion Not Supported. 3010 Protocol version negotiation may also occur at "handoff" and "failover" 3011 ServiceChanges. 3013 11.4. Failure of an MG 3015 If a MG fails, but is capable of sending a message to the MGC, it sends 3016 a ServiceChange with an appropriate method (graceful or forced) and 3017 specifies the Root TerminationID. When it returns to service, it sends 3018 a ServiceChange with a "Restart" method. 3020 Allowing the MGC to send duplicate messages to both MGs accommodates 3022 Internet draft MEGACO Protocol January 27, 2000 3024 pairs of MGs that are capable of redundant failover of one of the MGs. 3025 Only the Working MG shall accept or reject transactions. Upon failover, 3026 the Primary MG sends a ServiceChange command with a "Failover" method 3027 and a "MG Impending Failure" reason. The MGC then uses the primary MG 3028 as the active MG. When the error condition is repaired, the Working MG 3029 can send a "ServiceChange" with a "Restart" method. 3031 11.5. Failure of an MGC 3033 If the MG detects a failure of its controlling MGC, it attempts to con- 3034 tact the next MGC on its pre-provisioned list. It starts its attempts 3035 at the beginning (Primary MGC), unless that was the MGC that failed, in 3036 which case it starts at its first Secondary MGC. It sends a Servi- 3037 ceChange message with a "Failover" method and a " MGC Impending Failure" 3038 reason. 3040 In partial failure, or manual maintenance reasons, an MGC may wish to 3041 direct its controlled MGs to use a different MGC. To do so, it sends a 3042 ServiceChange method to the MG with a "HandOff" method, and its desig- 3043 nated replacement in MGCIdToTry. The MG should send a ServiceChange mes- 3044 sage with a "Failover" method and a "MGC directed change" reason to the 3045 designated MGC. If it fails to get a reply, or fails to see an Audit 3046 command subsequently, it should behave as if its MGC failed, and start 3047 contacting secondary MGCs. If the MG is unable to establish a control 3048 relationship with any MGC, it shall wait a random amount of time as 3049 described in section 9.2 and then start contacting its primary, and if 3050 necessary, its secondary MGCs again. 3052 No recommendation is made on how the MGCs involved in the Handoff main- 3053 tain state information; this is considered to be out of scope of this 3054 recommendation. The MGC and MG may take the following steps when Handoff 3055 occurs. When the MGC initiates a HandOff, the handover should be tran- 3056 sparent to Operations on the Media Gateway. Transactions can be exe- 3057 cuted in any order, and could be in progress when the ServiceChange is 3058 executed. Accordingly, commands in progress continue, transaction 3059 replies are sent to the new MGC (after a new control association is 3060 established), and the MG should expect outstanding transaction replies 3061 from the new MGC. No new messages shall be sent to the new MGC until 3062 the control association is established. Repeated transaction requests 3063 shall be directed to the new MGC. The MG shall maintain state on all 3064 terminations and contexts. 3066 It is possible that the MGC could be implemented in such a way that a 3067 failed MGC is replaced by a working MGC where the identity of the new 3068 MGC is the same as the failed one. In such a case, MGCIdToTry would be 3069 specified with the previous value and the MG shall behave as if the 3070 value was changed, and send a ServiceChange message, as above. 3072 Internet draft MEGACO Protocol January 27, 2000 3074 Pairs of MGCs that are capable of redundant failover can notify the con- 3075 trolled MGs of the failover by the above mechanism. 3077 12. PACKAGE DEFINITION 3079 The primary mechanism for extension is by means of Packages. Packages 3080 define additional Properties, Events, Signals and Statistics that may 3081 occur on Terminations. 3083 Packages defined by IETF will appear in separate RFCs. 3085 Packages relevant to H.323 systems are listed in an Annex to Recommenda- 3086 tion H.323. 3088 Packages defined by ITU-T will be described in Annexes to H.248. 3090 1) A public document or a standard forum document, which can be refer- 3091 enced as the document that describes the package following the 3092 guideline above, should be specified. 3094 2) The document shall specify the version of the Package that it 3095 describes. 3097 3) The document should be available on a public web server and should 3098 have a stable URL. The site should provide a mechanism to provide 3099 comments and appropriate responses should be returned. 3101 12.1. Guidelines for defining packages 3103 Packages define Properties, Events, Signals, and Statistics. 3105 Names of all such defined constructs shall consist of the PackageID 3106 (which uniquely identifies the package) and the ID of the item (which 3107 uniquely identifies the item in that package). In the text encoding the 3108 two shall be separated by a forward slash ("/") character. Example: 3109 togen/playtone is the text encoding to refer to the play tone signal in 3110 the tone generation package. 3112 A Package will contain the following sections: 3114 12.1.1. Package Overall description of the package, specifying: 3116 Package Name: only descriptive, 3118 PackageID: Is an identifier, its text encoding may not be a key- 3119 word in the base protocol Description: 3121 Version: A new version of a package can only add additional 3123 Internet draft MEGACO Protocol January 27, 2000 3125 Properties, Events, Signals, Statistics and new possible values for 3126 an existing parameter described in the original package. No dele- 3127 tions or modifications shall be allowed. A version is an integer in 3128 the range from 1 to 99. 3130 Extends (Optional): A package may extend an existing package. The 3131 version of the original package must be specified. When a package 3132 extends another package it shall only add additional Properties, 3133 Events, Signals, Statistics and new possible values for an existing 3134 parameter described in the original package. An extended package 3135 shall not redefine or overload a name defined in the original pack- 3136 age. Hence, if package B version 1 extends package A version 1, 3137 version 2 of B will not be able to extend the A version 2 if A ver- 3138 sion 2 defines a name already in B version 1. 3140 12.1.2. Properties 3142 Properties defined by the package, specifying: 3144 Property Name: only descriptive. 3145 PropertyID: Is an identifier 3146 Description: 3147 Type: One of: 3148 String: UTF-8 string 3149 Integer: 4 byte signed integer 3150 Double: 8 byte signed integer 3151 Character: Unicode UTF-8 encoding of a single letter. 3152 Could be more than one octet. 3153 Enumeration: One of a list of possible unique values 3154 (See 12.3) 3155 Sub-list: A list of several values from a list 3156 Boolean 3157 Possible Values: 3158 Defined in: Which descriptor the property is defined in. 3159 LocalControl is for stream dependent properties. 3160 TerminationState is for stream independent properties. 3161 Characteristics: Read / Write or both, and (optionally), global: 3162 Indicates whether a property is read-only, or read-write, 3163 and if it is global. If Global is omitted, the property 3164 is not global. If a property is declared as global, 3165 the value of the property is shared by all terminations 3166 realizing the package. 3168 12.1.3. Events 3170 Events defined by the package, specifying: 3172 Internet draft MEGACO Protocol January 27, 2000 3174 Event name: only descriptive. 3175 EventID: Is an identifier 3176 Description: 3177 EventsDescriptor Parameters: 3178 Parameters used by the MGC to configure the event, 3179 and found in the EventsDescriptor. See section 12.2 3180 ObservedEventsDescriptor Parameters: 3181 Parameters returned to the MGC in Notify requests 3182 and in replies to command requests from the MGC that 3183 audit ObservedEventsDescriptor, and found in the 3184 ObservedEventsDescriptor. See section 12.2 3186 12.1.4. Signals 3188 Signals defined by the package, specifying: 3189 Signal Name: only descriptive. 3190 SignalID: Is an identifier. SignalID is used in a 3191 SignalsDescriptor 3192 Description 3193 SignalType: One of: 3194 OO (On/Off) 3195 TO (TimeOut) 3196 BR (Brief) 3198 Note: SignalType may be defined such that it is dependent on the value 3199 of one or more parameters. Signals that would be played with SignalType 3200 BR should have a default duration. The package has to define the default 3201 duration and signalType. 3203 Duration: in hundredths of seconds 3204 Additional Parameters: See section 12.2 3206 12.1.5. Statistics 3208 Statistics defined by the package, specifying: 3209 Statistic name: only descriptive. 3210 StatisticID: Is an identifier 3211 StatisticID is used in a StatisticsDescriptor 3212 Description 3213 Units: unit of measure, e.g. milliseconds, packets 3215 12.1.6. Procedures 3217 Additional guidance on the use of the package. 3219 Internet draft MEGACO Protocol January 27, 2000 3221 12.2. Guidelines to defining Properties, Statistics and Parameters to 3222 Events and Signals. 3224 Parameter Name: only descriptive 3225 ParameterID: Is an identifier 3226 Type: One of: 3227 String: UTF-8 octet string 3228 Integer: 4 octet signed integer 3229 Double: 8 octet signed integer 3230 Character: Unicode UTF-8 encoding of a single letter. 3231 Could be more than one octet. 3232 Enumeration: One of a list of possible unique 3233 values (See 12.3) 3234 Sub-list: A list of several values from a list 3235 Boolean 3236 Possible values: 3237 Description: 3239 12.3. Lists 3241 Possible values for parameters include enumerations. Enumerations may 3242 be defined in a list. It is recommended that the list be IANA 3243 registered so that packages that extend the list can be defined without 3244 concern for conflicting names. 3246 12.4. Identifiers 3248 Identifiers in text encoding shall be strings of up to 64 characters, 3249 containing no spaces, starting with an alphanumeric character and con- 3250 sisting of alphanumeric characters and / or digits, and possibly includ- 3251 ing the special character underscore ("_"). Identifiers in binary 3252 encoding are 2 octets long. Both text and binary values shall be speci- 3253 fied for each identifier, including identifiers used as values in 3254 enumerated types. 3256 12.5. Package Registration 3258 A package can be registered with IANA for interoperability reasons. See 3259 section 13 for IANA considerations. 3261 13. IANA CONSIDERATIONS 3263 13.1. Packages 3265 The following considerations SHALL be met to register a package with 3266 IANA: 3268 Internet draft MEGACO Protocol January 27, 2000 3270 1. A unique string name, unique serial number and version number is 3271 registered for each package. The string name is used with text 3272 encoding. The serial number shall be used with binary encoding. 3273 Serial Numbers 60000-64565 are reserved for private use. Serial 3274 number 0 is reserved. 3276 2. A contact name, email and postal addresses for that contact shall 3277 be specified. The contact information shall be updated by the 3278 defining organization as necessary. 3280 3. A reference to a document that describes the package, which should 3281 be public: The document shall specify the version of the Package 3282 that it describes. If the document is public, it should be located 3283 on a public web server and should have a stable URL. The site 3284 should provide a mechanism to provide comments and appropriate 3285 responses should be returned. 3287 4. Packages registered by other than recognized standards bodies shall 3288 have a minimum package name length of 8 characters 3290 5. All other package names are first come-first served if all other 3291 conditions are met 3293 13.2. Error Codes 3295 The following considerations SHALL be met to register an error code with 3296 IANA: 3298 1. An error number and a one line (80 character maximum) string is 3299 registered for each error. 3301 2. A complete description of the conditions under which the error is 3302 detected shall be included in a publicly available document. The 3303 description shall be sufficiently clear to differentiate the error 3304 from all other existing error codes. 3306 3. The document should be available on a public web server and should 3307 have a stable URL. 3309 4. Error numbers registered by recognized standards bodies shall have 3310 3 or 4 character error numbers. 3312 5. Error numbers registered by all other organizations or individuals 3313 shall have 4 character error numbers. 3315 6. An error number shall not be redefined, nor modified except by the 3316 organization or individual that originally defined it, or their 3317 successors or assigns. 3319 Internet draft MEGACO Protocol January 27, 2000 3321 13.3. ServiceChange Reasons 3323 The following considerations SHALL be met to register service change 3324 reason with IANA: 3326 1. A one phrase, 80-character maximum, unique reason code is 3327 registered for each reason. 3329 2. A complete description of the conditions under which the reason is 3330 used is detected shall be included in a publicly available docu- 3331 ment. The description shall be sufficiently clear to differentiate 3332 the reason from all other existing reasons. 3334 3. The document should be available on a public web server and should 3335 have a stable URL. 3337 14. CONTACT INFORMATION 3339 IETF Editor 3340 Brian Rosen 3341 Marconi 3342 1000 FORE Drive 3343 Warrendale, PA 15086 3344 U.S.A. 3345 Phone: +1 724-742-6826 3346 Email: brosen@fore.com 3348 ITU Editor 3349 John Segers 3350 Lucent Technologies 3351 Room HE 306 3352 Dept. Forward Looking Work 3353 P.O. Box 18, 1270 AA Huizen 3354 Netherlands 3355 Phone: +31 35 687 4724 3356 Email: jsegers@lucent.com 3358 Additional IETF Authors 3359 Fernando Cuervo 3360 Nortel Networks 3361 P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7 3362 Canada 3363 Email: cuervo@nortelnetworks.com 3365 Bryan Hill 3366 Gotham Networks 3367 15 Discovery Way 3368 Acton, MA 01720 3370 Internet draft MEGACO Protocol January 27, 2000 3372 USA 3373 Phone: +1 978-263-6890 3374 Email: bhill@gothamnetworks.com 3376 Christian Huitema 3377 Telcordia Technologies 3378 MCC 1J236B 3379 445 South Street 3380 Morristown, NJ 07960 3381 U.S.A. 3382 Phone: +1 973-829-4266 3383 EMail: huitema@research.telcordia.com 3385 Nancy Greene 3386 Nortel Networks 3387 P.O. Box 3511 Stn C 3388 Ottawa, ON, K1Y 4H7 3389 Canada 3390 Phone: +1 514-271-7221 3391 Email: ngreene@nortelnetworks.com 3393 Abdallah Rayhan 3394 Nortel Networks 3395 P.O. Box 3511 Stn C 3396 Ottawa, ON, K1Y 4H7 3397 Canada 3398 Phone: +1 613-763-9611 3399 Email: arayhan@nortelnetworks.com 3401 ANNEX A BINARY ENCODING OF THE PROTOCOL (NORMATIVE) 3403 This Annex specifies the syntax of messages using the notation defined 3404 in ASN.1 [ITU-T Recommendation X.680 (1997): Information Technology - 3405 Abstract Syntax Notation One (ASN.1) - Specification of basic nota- 3406 tion.]. Messages shall be encoded for transmission by applying the basic 3407 encoding rules specified in [ITU-T Recommendation X.690(1994) Informa- 3408 tion Technology - ASN.1 Encoding Rules: Specification of Basic 3409 Encoding Rules (BER)]. 3411 A.1. Coding of wildcards 3413 The use of wildcards ALL and CHOOSE is allowed in the protocol. This 3414 allows a MGC to partially specify Termination IDs and let the MG choose 3415 from the values that conform to the partial specification. Termination 3416 IDs may encode a hierarchy of names. This hierarchy is provisioned. For 3418 Internet draft MEGACO Protocol January 27, 2000 3420 instance, a TerminationID may consist of a trunk group, a trunk within 3421 the group and a circuit. Wildcarding must be possible at all levels. 3422 The following paragraphs explain how this is achieved. 3424 The ASN.1 description uses octet strings of up to 8 octets in length for 3425 Termination IDs. This means that Termination IDs consist of at most 64 3426 bits. A fully specified Termination ID may be preceded by a sequence of 3427 wildcarding fields. A wildcarding field is octet in length. Bit 7 (the 3428 most significant bit) of this octet specifies what type of wildcarding 3429 is invoked: if the bit value equals 1, then the ALL wildcard is used; 3430 if the bit value if 0, then the CHOOSE wildcard is used. Bit 6 of the 3431 wildcarding field specifies whether the wildcarding pertains to one 3432 level in the hierarchical naming scheme (bit value 0) or to the level of 3433 the hierarchy specified in the wildcarding field plus all lower levels 3434 (bit value 1). Bits 0 through 5 of the wildcarding field specify the 3435 bit position in the Termination ID at which the starts. 3437 We illustrate this scheme with some examples. Assume that Termination 3438 IDs are three octets long and that each octet represents a level in a 3439 hierarchical naming scheme. A valid Termination ID is 3441 00000001 00011110 01010101. 3443 Addressing ALL names with prefix 00000001 00011110 is done as follows: 3445 wildcarding field: 10000111 3446 Termination ID: 00000001 00011110 xxxxxxxx. 3448 The values of the bits labeled "x" is irrelevant and shall be ignored by 3449 the receiver. 3451 Indicating to the receiver that is must choose a name with 00011110 as 3452 the second octet is done as follows: 3454 wildcarding fields: 00010111 followed by 00000111 3455 Termination ID: xxxxxxxx 00011110 xxxxxxxx. 3457 The first wildcard field indicates a CHOOSE wildcard for the level in 3458 the naming hierarchy starting at bit 23, the highest level in our 3459 assumed naming scheme. The second wildcard field indicates a CHOOSE 3460 wildcard for the level in the naming hierarchy starting at bit 7, the 3461 lowest level in our assumed naming scheme. 3463 Finally, a CHOOSE-wildcarded name with the highest level of the name 3464 equal to 00000001 is specified as follows: 3466 Internet draft MEGACO Protocol January 27, 2000 3468 wildcard field: 01001111 3469 Termination ID: 0000001 xxxxxxxx xxxxxxxx . 3471 Bit value 1 at bit position 6 of the first octet of the wildcard field 3472 indicates that the wildcarding pertains to the specified level in the 3473 naming hierarchy and all lower levels. 3475 Context IDs may also be wildcarded. In the case of Context IDs, how- 3476 ever, specifying partial names is not allowed. Context ID 0x0 SHALL be 3477 used to indicate the NULL Context, Context ID 0xFFFFFFFE SHALL be used 3478 to indicate a CHOOSE wildcard, and Context ID 0xFFFFFFFF SHALL be used 3479 to indicate an ALL wildcard. 3481 TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT Ter- 3482 mination. 3484 A.2. ASN.1 syntax specification 3486 This section contains the ASN.1 specification of the H.248 protocol syn- 3487 tax. 3489 NOTE - In case a transport mechanism is used that employs application 3490 level framing, the definition of Transaction below changes. Refer to 3491 the annex defining the transport mechanism for the definition that 3492 applies in that case. 3494 NOTE - The ASN.1 specification below contains a clause defining Termina- 3495 tionIDList as a sequence of TerminationIDs. The length of this sequence 3496 SHALL be one. The SEQUENCE OF construct is present only to allow future 3497 extensions. 3499 MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::= 3500 BEGIN 3502 MegacoMessage ::= SEQUENCE 3503 { 3504 authHeader AuthenticationHeader OPTIONAL, 3505 mess Message 3506 } 3508 AuthenticationHeader ::= SEQUENCE 3509 { 3510 secParmIndex SecurityParmIndex, 3511 seqNum SequenceNum, 3512 ad AuthData 3514 Internet draft MEGACO Protocol January 27, 2000 3516 } 3518 SecurityParmIndex ::= OCTET STRING(SIZE(4)) 3520 SequenceNum ::= OCTET STRING(SIZE(4)) 3522 AuthData ::= OCTET STRING (SIZE (16..32)) 3524 Message ::= SEQUENCE 3525 { 3526 version INTEGER(0..99), 3527 mId MId, -- Name/address of message originator 3528 messageBody CHOICE 3529 { 3530 messageError ErrorDescriptor, 3531 transactions SEQUENCE OF Transaction 3532 }, 3533 ... 3534 } 3536 MId ::= CHOICE 3537 { 3538 ip4Address IP4Address, 3539 ip6Address IP6Address, 3540 domainName DomainName, 3541 deviceName PathName, 3542 mtpAddress OCTET STRING(SIZE(5)), 3543 -- Addressing structure of mtpAddress: 3544 -- 15 0 3545 -- | PC | NI | 3546 -- 14 bits 2 bits 3547 ... 3548 } 3550 DomainName ::= SEQUENCE 3551 { 3552 name IA5String, 3553 -- The name starts with an alphanumeric digit followed by a 3554 -- sequence of alphanumeric digits, hyphens and dots. No two 3555 -- dots shall occur consecutively. 3556 portNumber INTEGER(0..65535) OPTIONAL 3557 } 3559 IP4Address ::= SEQUENCE 3560 { 3561 address OCTET STRING (SIZE(4)), 3562 portNumber INTEGER(0..65535) OPTIONAL 3563 } 3565 Internet draft MEGACO Protocol January 27, 2000 3567 IP6Address ::= SEQUENCE 3568 { 3569 address OCTET STRING (SIZE(16)), 3570 portNumber INTEGER(0..65535) OPTIONAL 3571 } 3573 PathName ::= IA5String(SIZE (1..64)) 3574 -- See section A.3 3576 Transaction ::= CHOICE 3577 { 3578 transactionRequest TransactionRequest, 3579 transactionPending TransactionPending, 3580 transactionReply TransactionReply, 3581 ... 3582 } 3584 TransactionId ::= INTEGER(0..4294967295) -- 32 bit unsigned integer 3586 TransactionRequest ::= SEQUENCE 3587 { 3588 transactionId TransactionId, 3589 actions SEQUENCE OF ActionRequest, 3590 ... 3591 } 3593 TransactionPending ::= SEQUENCE 3594 { 3595 transactionId TransactionId, 3596 ... 3597 } 3599 TransactionReply ::= SEQUENCE 3600 { 3601 transactionId TransactionId, 3602 transactionResult CHOICE 3603 { 3604 transactionError ErrorDescriptor, 3605 actionReplies SEQUENCE OF ActionReply 3606 }, 3607 ... 3608 } 3610 ErrorDescriptor ::= SEQUENCE 3611 { 3612 errorCode ErrorCode, 3613 errorText ErrorText OPTIONAL 3615 Internet draft MEGACO Protocol January 27, 2000 3617 } 3619 ErrorCode ::= INTEGER(0..65535) 3620 -- See section 13 for IANA considerations w.r.t. error codes 3622 ErrorText ::= IA5String 3624 ContextID ::= INTEGER(0..4294967295) 3626 -- Context NULL Value: 0 3627 -- Context CHOOSE Value: 429467294 (0xFFFFFFFE) 3628 -- Context ALL Value: 4294967295 (0xFFFFFFFF) 3630 ActionRequest ::= SEQUENCE 3631 { 3632 contextId ContextID, 3633 contextRequest ContextRequest OPTIONAL, 3634 contextAttrAuditReq ContextAttrAuditRequest OPTIONAL, 3635 commandRequests SEQUENCE OF CommandRequest 3636 } 3638 ActionReply ::= SEQUENCE 3639 { 3640 contextId ContextID, 3641 errorDescriptor ErrorDescriptor OPTIONAL, 3642 contextReply ContextRequest OPTIONAL, 3643 commandReply SEQUENCE OF CommandReply 3644 } 3646 ContextRequest ::= SEQUENCE 3647 { 3648 priority INTEGER(0..15) OPTIONAL, 3649 emergency BOOLEAN OPTIONAL, 3650 topologyReq SEQUENCE OF TopologyRequest OPTIONAL, 3651 ... 3652 } 3654 ContextAttrAuditRequest ::= SEQUENCE 3655 { 3656 topology NULL OPTIONAL, 3657 emergency NULL OPTIONAL, 3658 priority NULL OPTIONAL, 3659 ... 3660 } 3662 CommandRequest ::= SEQUENCE 3663 { 3665 Internet draft MEGACO Protocol January 27, 2000 3667 command Command, 3668 optional NULL OPTIONAL, 3669 wildcardReturn NULL OPTIONAL, 3670 ... 3671 } 3673 Command ::= CHOICE 3674 { 3675 addReq AmmRequest, 3676 moveReq AmmRequest, 3677 modReq AmmRequest, 3678 -- Add, Move, Modify requests have the same parameters 3679 subtractReq SubtractRequest, 3680 auditCapRequest AuditRequest, 3681 auditValueRequest AuditRequest, 3682 notifyReq NotifyRequest, 3683 serviceChangeReq ServiceChangeRequest, 3684 ... 3685 } 3687 CommandReply ::= CHOICE 3688 { 3689 addReply AmmsReply, 3690 moveReply AmmsReply, 3691 modReply AmmsReply, 3692 subtractReply AmmsReply, 3693 -- Add, Move, Modify, Subtract replies have the same parameters 3694 auditCapReply AuditReply, 3695 auditValueReply AuditReply, 3696 notifyReply NotifyReply, 3697 serviceChangeReply ServiceChangeReply, 3698 ... 3699 } 3701 TopologyRequest ::= SEQUENCE 3702 { 3703 terminationFrom TerminationID, 3704 terminationTo TerminationID, 3705 topologyDirection ENUMERATED 3706 { 3707 bothway(0), 3708 isolate(1), 3709 oneway(2) 3710 } 3711 } 3713 AmmRequest ::= SEQUENCE 3714 { 3716 Internet draft MEGACO Protocol January 27, 2000 3718 terminationID TerminationIDList, 3719 mediaDescriptor MediaDescriptor OPTIONAL, 3720 modemDescriptor ModemDescriptor OPTIONAL, 3721 muxDescriptor MuxDescriptor OPTIONAL, 3722 eventsDescriptor EventsDescriptor OPTIONAL, 3723 eventBufferDescriptor EventBufferDescriptor OPTIONAL, 3724 signalsDescriptor SignalsDescriptor OPTIONAL, 3725 digitMapDescriptor DigitMapDescriptor OPTIONAL, 3726 auditDescriptor AuditDescriptor OPTIONAL, 3727 ... 3728 } 3730 AmmsReply ::= SEQUENCE 3731 { 3732 terminationID TerminationIDList, 3733 terminationAudit TerminationAudit OPTIONAL 3734 } 3736 SubtractRequest ::= SEQUENCE 3737 { 3738 terminationID TerminationIDList, 3739 auditDescriptor AuditDescriptor OPTIONAL 3740 } 3742 AuditRequest ::= SEQUENCE 3743 { 3744 terminationID TerminationID, 3745 auditDescriptor AuditDescriptor OPTIONAL 3746 } 3748 AuditReply ::= SEQUENCE 3749 { 3750 terminationID TerminationID, 3751 auditResult AuditResult 3752 } 3754 AuditResult ::= CHOICE 3755 { 3756 contextAuditResult TerminationIDList, 3757 terminationAuditResult TerminationAudit 3758 } 3760 AuditDescriptor ::= SEQUENCE 3761 { 3762 auditToken BIT STRING 3763 { 3765 Internet draft MEGACO Protocol January 27, 2000 3767 muxToken(0), modemToken(1), mediaToken(2), 3768 eventsToken(3), signalsToken(4), 3769 digitMapToken(5), statsToken(6), 3770 observedEventsToken(7), 3771 packagesToken(8), eventBufferToken(9) 3772 } OPTIONAL, 3773 ... 3774 } 3776 TerminationAudit ::= SEQUENCE OF AuditReturnParameter 3778 AuditReturnParameter ::= CHOICE 3779 { 3780 errorDescriptor ErrorDescriptor, 3781 mediaDescriptor MediaDescriptor, 3782 modemDescriptor ModemDescriptor, 3783 muxDescriptor MuxDescriptor, 3784 eventsDescriptor EventsDescriptor, 3785 eventBufferDescriptor EventBufferDescriptor, 3786 signalsDescriptor SignalsDescriptor, 3787 digitMapDescriptor DigitMapDescriptor, 3788 observedEventsDescriptor ObservedEventsDescriptor, 3789 statisticsDescriptor StatisticsDescriptor, 3790 packagesDescriptor PackagesDescriptor, 3791 ... 3792 } 3794 NotifyRequest ::= SEQUENCE 3795 { 3796 terminationID TerminationIDList, 3797 observedEventsDescriptor ObservedEventsDescriptor, 3798 errorDescriptor ErrorDescriptor OPTIONAL 3799 } 3801 NotifyReply ::= SEQUENCE 3802 { 3803 terminationID TerminationIDList OPTIONAL, 3804 errorDescriptor ErrorDescriptor OPTIONAL 3805 } 3807 ObservedEventsDescriptor ::= SEQUENCE 3808 { 3809 requestId RequestID, 3810 observedEventLst SEQUENCE OF ObservedEvent 3811 } 3813 ObservedEvent ::= SEQUENCE 3814 { 3816 Internet draft MEGACO Protocol January 27, 2000 3818 eventName EventName, 3819 streamID StreamID OPTIONAL, 3820 eventParList SEQUENCE OF EventParameter, 3821 timeNotation TimeNotation OPTIONAL 3822 } 3824 EventName ::= PkgdName 3826 EventParameter ::= SEQUENCE 3827 { 3828 eventParameterName Name, 3829 value Value 3830 } 3832 ServiceChangeRequest ::= SEQUENCE 3833 { 3834 terminationID TerminationIDList, 3835 serviceChangeParms ServiceChangeParm 3836 } 3838 ServiceChangeReply ::= SEQUENCE 3839 { 3840 terminationID TerminationIDList, 3841 serviceChangeResult ServiceChangeResult 3842 } 3844 -- For ServiceChangeResult, no parameters are mandatory. Hence the 3845 -- distinction between ServiceChangeParm and ServiceChangeResParm. 3847 ServiceChangeResult ::= CHOICE 3848 { 3849 errorDescriptor ErrorDescriptor, 3850 serviceChangeResParms ServiceChangeResParm 3851 } 3853 WildcardField ::= OCTET STRING(SIZE(1)) 3855 TerminationID ::= SEQUENCE 3856 { 3857 wildcard SEQUENCE OF WildcardField, 3858 id OCTET STRING(SIZE(1..8)) 3859 } 3860 -- See Section A.1 for explanation of wildcarding mechanism. 3861 -- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination. 3863 TerminationIDList ::= SEQUENCE OF TerminationID 3865 MediaDescriptor ::= SEQUENCE 3867 Internet draft MEGACO Protocol January 27, 2000 3869 { 3871 termStateDescr TerminationStateDescriptor OPTIONAL, 3872 streams CHOICE 3873 { 3874 oneStream StreamParms, 3875 multiStream SEQUENCE OF StreamDescriptor 3876 }, 3877 ... 3878 } 3880 StreamDescriptor ::= SEQUENCE 3881 { 3882 streamID StreamID, 3883 streamParms StreamParms 3884 } 3886 StreamParms ::= SEQUENCE 3887 { 3888 localControlDescriptor LocalControlDescriptor OPTIONAL, 3889 localDescriptor LocalRemoteDescriptor OPTIONAL, 3890 remoteDescriptor LocalRemoteDescriptor OPTIONAL, 3891 ... 3892 } 3894 LocalControlDescriptor ::= SEQUENCE 3895 { 3896 streamMode StreamMode OPTIONAL, 3897 reserve BOOLEAN, 3898 propertyParms SEQUENCE OF PropertyParm, 3899 ... 3900 } 3902 StreamMode ::= ENUMERATED 3903 { 3904 sendOnly(0), 3905 recvOnly(1), 3906 sendRecv(2), 3907 inactive(3), 3908 loopBack(4), 3909 delete(5), 3910 ... 3911 } 3913 -- In PropertyParm, value is a SEQUENCE OF octet string. When sent 3914 -- by an MGC the interpretation is as follows: 3915 -- empty sequence means CHOOSE 3916 -- one element sequence specifies value 3918 Internet draft MEGACO Protocol January 27, 2000 3920 -- longer sequence means "choose one of the values" 3921 -- The relation field may only be selected if the value sequence 3922 -- has length 1. It indicates that the MG has to choose a value 3923 -- for the property. E.g., x > 3 (using the greaterThan 3924 -- value for relation) instructs the MG to choose any value larger 3925 -- than 3 for property x. 3926 -- The range field may only be selected if the value sequence 3927 -- has length 2. It indicates that the MG has to choose a value 3928 -- in the range between the first octet in the value sequence and 3929 -- the trailing octet in the value sequence, including the 3930 -- boundary values. 3931 -- When sent by the MG, only responses to an AuditCapability request 3932 -- may contain multiple values, a range, or a relation field. 3934 PropertyParm ::= SEQUENCE 3935 { 3936 name PkgdName, 3937 value SEQUENCE OF OCTET STRING, 3938 extraInfo CHOICE 3939 { 3940 relation Relation, 3941 range BOOLEAN 3942 } OPTIONAL 3944 } 3946 Name ::= OCTET STRING(SIZE(2)) 3948 PkgdName ::= OCTET STRING(SIZE(4)) 3949 -- represents Package Name (2 octets) plus Property Name (2 octets) 3950 -- To wildcard a package use 0xFFFF for first two octets, choose 3951 -- is not allowed. To reference native property tag specified in 3952 -- Annex C, use 0x0000 as first two octets. 3954 Relation ::= ENUMERATED 3955 { 3956 greaterThan(0), 3957 smallerThan(1), 3958 unequalTo(2), 3959 ... 3960 } 3962 LocalRemoteDescriptor ::= SEQUENCE 3963 { 3964 propGrps SEQUENCE OF PropertyGroup, 3965 ... 3966 } 3968 Internet draft MEGACO Protocol January 27, 2000 3970 PropertyGroup ::= SEQUENCE OF PropertyParm 3972 TerminationStateDescriptor ::= SEQUENCE 3973 { 3974 propertyParms SEQUENCE OF PropertyParm, 3975 eventBufferFlag BOOLEAN, 3976 serviceState ServiceState OPTIONAL, 3977 ... 3978 } 3980 ServiceState ::= ENUMERATED 3981 { 3982 test(0), 3983 outOfSvc(1), 3984 inSvc(2), 3985 ... 3986 } 3988 MuxDescriptor ::= SEQUENCE 3989 { 3990 muxType MuxType, 3991 termList SEQUENCE OF TerminationID, 3992 ... 3993 } 3995 MuxType ::= ENUMERATED 3996 { 3997 h221(0), 3998 h223(1), 3999 h226(2), 4000 v76(3), 4001 ... 4002 } 4004 StreamID ::= INTEGER(0..65535) -- 16 bit unsigned integer 4006 EventsDescriptor ::= SEQUENCE 4007 { 4008 requestID RequestID, 4009 eventList SEQUENCE OF RequestedEvent 4010 } 4012 RequestedEvent ::= SEQUENCE 4013 { 4014 pkgdName PkgdName, 4015 streamID StreamID OPTIONAL, 4016 eventAction RequestedActions OPTIONAL, 4017 evParList SEQUENCE OF EventParameter 4019 Internet draft MEGACO Protocol January 27, 2000 4021 } 4023 RequestedActions ::= SEQUENCE 4024 { 4025 keepActive BOOLEAN, 4026 eventDM EventDM OPTIONAL, 4027 secondEvent SecondEventsDescriptor OPTIONAL, 4028 signalsDescriptor SignalsDescriptor OPTIONAL, 4029 ... 4030 } 4032 EventDM ::= CHOICE 4033 { digitMapName DigitMapName, 4034 digitMapValue DigitMapValue 4035 } 4037 SecondEventsDescriptor ::= SEQUENCE 4038 { 4039 requestID RequestID, 4040 eventList SEQUENCE OF SecondRequestedEvent 4041 } 4043 SecondRequestedEvent ::= SEQUENCE 4044 { 4045 pkgdName PkgdName, 4046 streamID StreamID OPTIONAL, 4047 eventAction SecondRequestedActions OPTIONAL, 4048 evParList SEQUENCE OF EventParameter 4049 } 4051 SecondRequestedActions ::= SEQUENCE 4052 { 4053 keepActive BOOLEAN, 4054 eventDM EventDM OPTIONAL, 4055 signalsDescriptor SignalsDescriptor OPTIONAL, 4056 ... 4057 } 4059 EventBufferDescriptor ::= SEQUENCE OF ObservedEvent 4061 SignalsDescriptor ::= SEQUENCE OF SignalRequest 4063 SignalRequest ::=CHOICE 4064 { 4065 signal Signal, 4066 seqSigList SeqSigList 4067 } 4069 Internet draft MEGACO Protocol January 27, 2000 4071 SeqSigList ::= SEQUENCE 4072 { 4073 id INTEGER(0..65535), 4074 signalList SEQUENCE OF Signal 4075 } 4077 Signal ::= SEQUENCE 4078 { 4079 signalName SignalName, 4080 streamID StreamID OPTIONAL, 4081 sigType SignalType OPTIONAL, 4082 duration INTEGER (0..65535) OPTIONAL, 4083 notifyCompletion RequestID OPTIONAL, 4084 sigParList SEQUENCE OF SigParameter 4085 } 4087 SignalType ::= ENUMERATED 4088 { 4089 brief(0), 4090 onOff(1), 4091 timeOut(2), 4092 ... 4093 } 4095 SignalName ::= PkgdName 4097 SigParameter ::= SEQUENCE 4098 { 4099 sigParameterName Name, 4100 value Value 4101 } 4103 RequestID ::= INTEGER(0..4294967295) -- 32 bit unsigned integer 4105 ModemDescriptor ::= SEQUENCE 4106 { 4107 mtl SEQUENCE OF ModemType, 4108 mpl SEQUENCE OF PropertyParm 4110 } 4112 ModemType ::= ENUMERATED 4113 { 4114 v18(0), 4115 v22(1), 4116 v22bis(2), 4117 v32(3), 4118 v32bis(4), 4120 Internet draft MEGACO Protocol January 27, 2000 4122 v34(5), 4123 v90(6), 4124 v91(7), 4125 synchISDN(8), 4126 ... 4127 } 4129 DigitMapDescriptor ::= SEQUENCE 4130 { 4131 digitMapName DigitMapName, 4132 digitMapValue DigitMapValue 4133 } 4135 DigitMapName ::= Name 4137 DigitMapValue ::= SEQUENCE 4138 { 4139 startTimer INTEGER(0..99) OPTIONAL, 4140 shortTimer INTEGER(0..99) OPTIONAL, 4141 longTimer INTEGER(0..99) OPTIONAL, 4142 digitMapBody IA5String 4143 -- See Section A.3 for explanation of digit map syntax 4144 } 4146 ServiceChangeParm ::= SEQUENCE 4147 { 4148 serviceChangeMethod ServiceChangeMethod, 4149 serviceChangeAddress ServiceChangeAddress OPTIONAL, 4150 serviceChangeVersion INTEGER(0..99) OPTIONAL, 4151 serviceChangeProfile ServiceChangeProfile OPTIONAL, 4152 serviceChangeReason Value, 4153 serviceChangeDelay INTEGER(0..4294967295) OPTIONAL, 4154 -- 32 bit unsigned integer 4155 serviceChangeMgcId MId OPTIONAL, 4156 timeStamp TimeNotation OPTIONAL, 4157 } 4159 ServiceChangeAddress ::= CHOICE 4160 { 4161 portNumber INTEGER(0..65535), -- TCP/UDP port number 4162 ip4Address IP4Address, 4163 ip6Address IP6Address, 4164 domainName DomainName, 4165 deviceName PathName, 4166 mtpAddress OCTET STRING(SIZE(5)), 4167 ... 4168 } 4170 Internet draft MEGACO Protocol January 27, 2000 4172 ServiceChangeResParm ::= SEQUENCE 4173 { 4174 serviceChangeMgcId MId OPTIONAL, 4175 serviceChangeAddress ServiceChangeAddress OPTIONAL, 4176 serviceChangeVersion INTEGER(0..99) OPTIONAL, 4177 serviceChangeProfile ServiceChangeProfile OPTIONAL 4178 } 4180 ServiceChangeMethod ::= ENUMERATED 4181 { 4182 failover(0), 4183 forced(1), 4184 graceful(2), 4185 restart(3), 4186 disconnected(4), 4187 handOff(5), 4188 ... 4189 } 4191 ServiceChangeProfile ::= SEQUENCE 4192 { 4193 profileName Name, 4194 version INTEGER(0..99) 4195 } 4197 PackagesDescriptor ::= SEQUENCE OF PackagesItem 4199 PackagesItem ::= SEQUENCE 4200 { 4201 packageName Name, 4202 packageVersion INTEGER(0..99) 4203 } 4205 StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter 4207 StatisticsParameter ::= SEQUENCE 4208 { 4209 statName PkgdName, 4210 statValue Value 4211 } 4213 TimeNotation ::= SEQUENCE 4214 { 4215 date IA5String(SIZE(8)), -- yyyymmdd format 4216 time IA5String(SIZE(8)) -- hhmmssss format 4217 } 4219 Value ::= OCTET STRING 4221 Internet draft MEGACO Protocol January 27, 2000 4223 END 4225 A.3. Digit maps and path names 4227 >From a syntactic viewpoint, digit maps are strings with syntactic res- 4228 trictions imposed upon them. The syntax of valid digit maps is specified 4229 in ABNF [RFC 2119]. The syntax for digit maps presented in this section 4230 is for illustrative purposes only. The definition of digitMap in Annex B 4231 takes precedence in the case of differences between the two. 4233 digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP 4234 ")" LWSP) 4235 digitStringList = digitString *( LWSP "/" LWSP digitString ) 4236 digitString = 1*(digitStringElement) 4237 digitStringElement = digitPosition [DOT] 4238 digitPosition = digitMapLetter / digitMapRange 4239 digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) 4240 digitLetter = *((DIGIT "-" DIGIT) / ditigMapLetter) 4241 digitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / 4242 ; DTMF digits 4243 "S"/ "L" / ; timers (short, long) 4244 MFSig 4245 MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3" 4246 LWSP = *(WSP / COMMENT / EOL) 4247 WSP = SP / HTAB 4248 COMMENT = ";" *(SafeChar / RestChar / WSP) EOL 4249 EOL = (CR [LF]) / LF 4250 SP = %x20 4251 HTAB = %x09 4252 CR = &x0D 4253 LF = %x0A 4254 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" / 4255 "'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / " 4256 "(" / ")" / "%" / "." 4257 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" / 4258 "<" / ">" / "=" / %x22 4259 DIGIT = %x30-39 ; digits 0 through 9 4260 ALPHA = %x41-5A / %x61-7A ; A-Z, a-z 4262 A path name is also a string with syntactic restrictions imposed upon 4263 it. The ABNF production defining it is copied from Annex B. 4265 PathName = NAME *(["/"] ["*"] ["@"] (ALPHA / DIGIT)) ["*"] 4266 NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 4268 Internet draft MEGACO Protocol January 27, 2000 4270 ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE) 4272 B.1. Coding of wildcards 4274 In a text encoding of the protocol, while TerminationIDs are arbitrary, 4275 by judicious choice of names, the wildcard character, "*" may be made 4276 more useful. When the wildcard character is encountered, it will 4277 "match" all TerminationIDs having the same previous and following char- 4278 acters (if appropriate). For example, if there were TerminationIDs of 4279 R13/3/1, R13/3/2 and R13/3/3, the TerminationID R13/3/* would match all 4280 of them. There are some circumstances where ALL Terminations must be 4281 referred to. The TerminationID "*" suffices, and is referred to as ALL. 4282 The CHOOSE TerminationID "$" may be used to signal to the MG that it has 4283 to create an ephemeral Termination or select an idle physical Termina- 4284 tion. 4286 B.2. ABNF specification 4288 The protocol syntax is presented in ABNF according to RFC2234. The pro- 4289 tocol is not case sensitive. Identifiers are not case sensitive. 4291 megacoMessage = LWSP [authenticationHeader SEP ] message 4293 authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON 4294 SequenceNum COLON AuthData 4296 SecurityParmIndex = "0x" 8(HEXDIG) 4297 SequenceNum = "0x" 8(HEXDIG) 4298 AuthData = "0x" 32*64(HEXDIG) 4300 message = MegacopToken SLASH Version SEP mId SEP 4301 messageBody 4303 messageBody = ( errorDescriptor / transactionList ) 4305 transactionList = 1*( transactionRequest / transactionReply / 4306 transactionPending) 4308 transactionPending = PendingToken EQUAL TransactionID LBRKT RBRKT 4310 transactionRequest = TransToken EQUAL TransactionID LBRKT 4311 actionRequest *(COMMA actionRequest) RBRKT 4313 actionRequest = CtxToken EQUAL ContextID LBRKT (( 4314 contextRequest [COMMA commandRequestList]) 4315 / commandRequestList) RBRKT 4317 Internet draft MEGACO Protocol January 27, 2000 4319 contextRequest = ((contextAudit [COMMA contextProperties]) 4320 / contextProperties) 4322 contextProperties = contextProperty *(COMMA contextProperty) 4324 ; at-most-once 4325 contextProperty = (topologyDescriptor / priority / 4326 EmergencyToken) 4328 contextAudit = ContextAuditToken LBRKT 4329 contextAuditProperties *(COMMA 4330 contextAuditProperties) RBRKT 4332 ; at-most-once 4333 contextAuditProperties = ( TopologyToken / EmergencyToken / 4334 PriorityToken ) 4336 commandRequestList=["O-"] commandRequest *(COMMA ["O-"]commandRequest) 4338 commandRequest = ( ammRequest / subtractRequest / auditRequest / 4339 notifyRequest / serviceChangeRequest) 4341 transactionReply = ReplyToken EQUAL TransactionID LBRKT 4342 ( errorDescriptor / actionReplyList ) RBRKT 4344 actionReplyList = actionReply *(COMMA actionReply ) 4346 actionReply = CtxToken EQUAL ContextID LBRKT 4347 ( errorDescriptor / commandReply ) RBRKT 4349 commandReply = (( contextProperties [COMMA commandReplyList] ) / 4350 commandReplyList ) 4352 commandReplyList = commandReplys *(COMMA commandReplys ) 4354 commandReplys = (serviceChangeReply / auditReply / ammsReply / 4355 notifyReply ) 4357 ;Add Move and Modify have the same request parameters 4358 ammRequest = (AddToken / MoveToken / ModifyToken ) EQUAL 4359 TerminationID [LBRKT ammParameter *(COMMA 4360 ammParameter) RBRKT] 4362 ;at-most-once 4363 ammParameter = (mediaDescriptor / modemDescriptor / 4364 muxDescriptor / eventsDescriptor / 4365 signalsDescriptor / digitMapDescriptor / 4367 Internet draft MEGACO Protocol January 27, 2000 4369 eventBufferDescriptor / auditDescriptor) 4371 ammsReply = (AddToken / MoveToken / ModifyToken / 4372 SubtractToken ) EQUAL TerminationID [ LBRKT 4373 terminationAudit RBRKT ] 4375 subtractRequest = ["W-"] SubtractToken EQUAL TerminationID 4376 [ LBRKT auditDescriptor RBRKT] 4378 auditRequest = ["W-"] (AuditValueToken / AuditCapToken ) EQUAL 4379 TerminationID [ LBRKT auditDescriptor RBRKT ] 4381 auditReply = (AuditValueToken / AuditCapToken ) 4382 ( contextTerminationAudit / auditOther) 4384 auditOther = EQUAL TerminationID LBRKT 4385 terminationAudit RBRKT 4387 terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) 4389 contextTerminationAudit = EQUAL CtxToken ( terminationIDList / 4390 LBRKT errorDescriptor RBRKT ) 4391 ;at-most-once except errorDescriptor 4392 auditReturnParameter = (mediaDescriptor / modemDescriptor / 4393 muxDescriptor / eventsDescriptor / 4394 signalsDescriptor / digitMapDescriptor / 4395 observedEventsDescriptor / eventBufferDescriptor / 4396 statisticsDescriptor / packagesDescriptor / 4397 errorDescriptor ) 4399 auditDescriptor = AuditToken LBRKT [ auditItem 4400 *(COMMA auditItem) ] RBRKT 4402 notifyRequest = NotifyToken EQUAL TerminationID 4403 LBRKT ( observedEventsDescriptor / 4404 errorDescriptor ) RBRKT 4406 notifyReply = NotifyToken EQUAL TerminationID 4407 [ LBRKT errorDescriptor RBRKT ] 4409 serviceChangeRequest = ServiceChangeToken EQUAL TerminationID 4410 LBRKT serviceChangeDescriptor RBRKT 4412 serviceChangeReply = ServiceChangeToken EQUAL TerminationID 4413 [LBRKT (errorDescriptor / 4414 serviceChangeReplyDescriptor) RBRKT] 4416 errorDescriptor = ErrorToken EQUAL ErrorCode 4418 Internet draft MEGACO Protocol January 27, 2000 4420 LBRKT [quotedString] RBRKT 4422 ErrorCode = 1*3(DIGIT) ; could be extended 4424 TransactionID = UINT32 4426 mId = (( domainAddress / domainName ) 4427 [":" portNumber]) / mtpAddress / deviceName 4429 ; ABNF allows two or more consecutive "." although it is meaningless 4430 ; in a domain name. 4431 domainName = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" / 4432 ".") ">" 4433 deviceName = pathNAME 4435 ContextID = (UINT32 / "*" / "-" / "$") 4437 domainAddress = "[" (IPv4address / IPv6address) "]" 4438 ;RFC2373 contains the definition of IP6Addresses. 4439 IPv6address = hexpart [ ":" IPv4address ] 4440 IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex 4441 V4hex = 1*3(DIGIT) ; "0".."225" 4442 ; this production, while occurring in RFC2373, is not referenced 4443 ; IPv6prefix = hexpart SLASH 1*2DIGIT 4444 hexpart = hexseq "::" [ hexseq ] / "::" [ hexseq ] / 4445 hexseq 4446 hexseq = hex4 *( ":" hex4) 4447 hex4 = 1*4HEXDIG 4449 portNumber = UINT16 4451 ; An mtp address is five octets long 4452 mtpAddress = MTPToken LBRKT octetString RBRKT 4454 terminationIDList = LBRKT TerminationID *(COMMA TerminationID) 4455 RBRKT 4457 ; Total length of pathNAME must not exceed 64 chars. 4458 pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) 4459 ["@" pathDomainName ] 4461 ; ABNF allows two or more consecutive "." although it is meaningless 4462 ; in a path domain name. 4463 pathDomainName = (ALPHA / DIGIT / "*" ) 4464 *63(ALPHA / DIGIT / "-" / "*" / ".") 4466 TerminationID = "ROOT" / pathNAME / "$" / "*" 4468 Internet draft MEGACO Protocol January 27, 2000 4470 mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT 4472 ; at-most-once per item 4473 ; and either streamParm or streamDescriptor but not both 4474 mediaParm = (streamParm / streamDescriptor / 4475 terminationStateDescriptor) 4477 ; at-most-once 4478 streamParm = ( localDescriptor / remoteDescriptor / 4479 localControlDescriptor ) 4481 streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm 4482 *(COMMA streamParm) RBRKT 4484 localControlDescriptor = LocalControlToken LBRKT localParm 4485 *(COMMA localParm) RBRKT 4487 ; at-most-once per item 4488 localParm = ( streamMode / propertyParm / reservedMode) 4490 reservedMode = ReservedToken EQUAL ( "ON" / "OFF" ) 4492 streamMode = ModeToken EQUAL streamModes 4494 streamModes = (SendonlyToken / RecvonlyToken / SendrecvToken / 4495 InactiveToken / LoopbackToken / DeleteToken ) 4497 propertyParm = pkgdName parmValue 4498 parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) 4499 alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT / 4500 LSBRKT VALUE DOT DOT VALUE RSBRKT ) 4502 INEQUAL = LWSP (">" / "<" / "#" ) LWSP 4503 LSBRKT = LWSP "[" LWSP 4504 RSBRKT = LWSP "]" LWSP 4506 localDescriptor = LocalToken LBRKT octetString RBRKT 4508 remoteDescriptor = RemoteToken LBRKT octetString RBRKT 4510 eventBufferDescriptor= EventBufferToken LBRKT observedEvent 4511 *( COMMA observedEvent ) RBRKT 4513 eventBufferFlag = BufferToken EQUAL ("ON" / "OFF" ) 4515 terminationStateDescriptor = TerminationStateToken LBRKT 4516 terminationStateParm *( COMMA terminationStateParm ) RBRKT 4518 Internet draft MEGACO Protocol January 27, 2000 4520 ; at-most-once per item 4521 terminationStateParm=(propertyParm / serviceStates / eventBufferFlag ) 4523 serviceStates = ServiceStatesToken EQUAL ( TestToken / 4524 OutOfSvcToken / InSvcToken ) 4526 muxDescriptor = MuxToken EQUAL MuxType terminationIDList 4528 MuxType = ( H221Token / H223Token / H226Token / V75Token 4529 extensionParameter ) 4531 StreamID = UINT16 4532 pkgdName = (PackageName / "*") SLASH (ItemID / "*" ) 4533 PackageName = NAME 4534 ItemID = NAME 4536 eventsDescriptor = EventsToken EQUAL RequestID LBRKT 4537 requestedEvent *( COMMA requestedEvent ) RBRKT 4539 requestedEvent = pkgdName [ LBRKT eventParameter 4540 *( COMMA eventParameter ) RBRKT ] 4542 ; at-most-once each of embedOrKeepActive , eventDM or eventStream 4543 eventParameter = ( embedOrKeepActive / eventDM / eventStream 4544 / eventOther ) 4545 embedOrKeepActive = eventEmbedded / KeepActiveToken 4547 eventEmbedded = EmbedToken LBRKT embedFirst [COMMA embedFirst ] RBRKT 4548 ; at-most-once of each 4549 embedFirst = ( signalsDescriptor / secondEventEmbeddedDescriptor ) 4551 secondEventEmbeddedDescriptor= EventsToken EQUAL RequestID LBRKT 4552 secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT 4554 secondRequestedEvent = pkgdName [ LBRKT secondEventParameter 4555 *( COMMA secondEventParameter ) RBRKT ] 4557 ; at-most-once each of embedOrKeepActive , eventDM or eventStream 4558 secondEventParameter = ( SecondEmbedOrKeepActive / eventDM / 4559 eventStream / eventOther ) 4561 secondEmbedOrKeepActive = secondEventEmbedded / KeepActiveToken 4563 secondEventEmbedded = EmbedToken LBRKT signalsDescriptor RBRKT 4565 eventStream = StreamToken EQUAL StreamID 4567 eventOther = eventParameterName parmValue 4569 Internet draft MEGACO Protocol January 27, 2000 4571 eventParameterName = NAME 4573 eventDM = DigitMapToken ((EQUAL digitMapName ) / 4574 (LBRKT digitMapValue RBRKT )) 4576 signalsDescriptor = SignalsToken LBRKT [ signalParm 4577 *(COMMA signalParm)] RBRKT 4579 signalParm = signalList / signalRequest 4581 signalRequest = signalName [ LBRKT sigParameter 4582 *(COMMA sigParameter) RBRKT ] 4584 signalList = SignalListToken EQUAL signalListId LBRKT 4585 signalListParm *(COMMA signalListParm) RBRKT 4587 signalListId = UINT16 4589 ;exactly once signalType, at most once duration and every signal 4590 ;parameter 4591 signalListParm = signalRequest 4593 signalName = pkgdName 4594 ;at-most-once sigStream, at-most-once sigSignalType, 4595 ;at-most-once sigDuration, every signalParameterName at most once 4596 sigParameter = sigStream / sigSignalType / sigDuration / 4597 sigOther 4598 / notifyCompletion 4599 sigStream = StreamToken EQUAL StreamID 4600 sigOther = sigParameterName parmValue 4601 sigParameterName = NAME 4602 sigSignalType = SignalTypeToken EQUAL signalType 4603 signalType = (OnOffToken / TimeOutToken / BriefToken) 4604 sigDuration = DurationToken EQUAL UINT16 4605 notifyCompletion = NotifyCompletionToken EQUAL RequestID 4607 observedEventsDescriptor = ObservedEventsToken EQUAL RequestID 4608 LBRKT observedEvent *(COMMA observedEvent) RBRKT 4610 ;time per event, because it might be buffered 4611 observedEvent = [ TimeStamp LWSP COLON] LWSP 4612 pkgdName [ LBRKT observedEventParameter 4613 *(COMMA observedEventParameter) RBRKT ] 4615 ;at-most-once eventStream, every eventParameterName at most once 4616 observedEventParameter = eventStream / eventOther 4618 RequestID = UINT32 4620 Internet draft MEGACO Protocol January 27, 2000 4622 modemDescriptor = ModemToken (( EQUAL modemType) / 4623 (LSBRKT modemType *(COMMA modemType) RSBRKT)) 4624 [ LBRKT NAME parmValue 4625 *(COMMA NAME parmValue) RBRKT ] 4627 ; at-most-once 4628 modemType = (V32bisToken / V22bisToken / V18Token / 4629 V22Token / V32Token / V34Token / V90Token / 4630 V91Token / SynchISDNToken / extensionParameter) 4632 digitMapDescriptor = DigitMapToken EQUAL digitMapName 4633 ( LBRKT digitMapValue RBRKT ) 4634 digitMapName = NAME 4635 digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA] 4636 ["L" COLON Timer COMMA] digitMap 4637 Timer = 1*2DIGIT 4638 digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")" LWSP) 4639 digitStringList = digitString *( LWSP "|" LWSP digitString ) 4640 digitString = 1*(digitStringElement) 4641 digitStringElement = digitPosition [DOT] 4642 digitPosition = digitMapLetter / digitMapRange 4643 digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) 4644 digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter) 4645 digitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / 4646 MFSig / "S" / "L" 4648 MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3" 4650 ;at-most-once 4651 auditItem = ( MuxToken / ModemToken / MediaToken / 4652 SignalsToken / EventBufferToken / 4653 DigitMapToken / StatsToken / EventsToken / 4654 ObservedEventsToken / PackagesToken ) 4656 serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm 4657 *(COMMA serviceChangeParm) RBRKT 4659 serviceChangeParm = (serviceChangeMethod / serviceChangeReason / 4660 serviceChangeDelay / serviceChangeAddress / 4661 serviceChangeProfile / extension / TimeStamp / 4662 serviceChangeMgcId / serviceChangeVersion ) 4664 serviceChangeReplyDescriptor = ServicesToken LBRKT 4665 servChgReplyParm *(COMMA servChgReplyParm) RBRKT 4667 ;at-most-once. Version is REQUIRED on first ServiceChange response 4668 servChgReplyParm = (serviceChangeAddress / serviceChangeMgcId / 4669 serviceChangeProfile / serviceChangeVersion ) 4671 Internet draft MEGACO Protocol January 27, 2000 4673 serviceChangeMethod = MethodToken EQUAL (FailoverToken / 4674 ForcedToken / GracefulToken / RestartToken / 4675 DisconnectedToken / HandOffToken / 4676 extensionParameter) 4678 serviceChangeReason = ReasonToken EQUAL VALUE 4679 serviceChangeDelay = DelayToken EQUAL UINT32 4680 serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE 4681 serviceChangeMgcId = MgcIdToken EQUAL mId 4682 serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version 4683 serviceChangeVersion = VersionToken EQUAL Version 4684 extension = extensionParameter parmValue 4686 packagesDescriptor = PackagesToken LBRKT packagesItem 4687 *(COMMA packagesItem) RBRKT 4689 Version = 1*2(DIGIT) 4690 packagesItem = NAME "-" UINT16 4692 TimeStamp = Date "T" Time ; per ISO 8601:1988 4693 ; Date = yyyymmdd 4694 Date = 8(DIGIT) 4695 ; Time = hhmmssss 4696 Time = 8(DIGIT) 4697 statisticsDescriptor = StatsToken LBRKT statisticsParameter 4698 *(COMMA statisticsParameter ) RBRKT 4700 ;at-most-once per item 4701 statisticsParameter = pkgdName EQUAL VALUE 4703 topologyDescriptor = TopologyToken LBRKT terminationA COMMA 4704 terminationB COMMA topologyDirection RBRKT 4705 terminationA = TerminationID 4706 terminationB = TerminationID 4707 topologyDirection = BothwayToken / IsolateToken / OnewayToken 4709 priority = PriorityToken EQUAL UINT16 4711 extensionParameter = "X" ("-" / "+") 1*6(ALPHA / DIGIT) 4713 ; octetString is used to describe SDP defined in RFC2327. 4714 ; Caution should be taken if CRLF in RFC2327 is used. 4715 ; To be safe, use EOL in this ABNF. 4716 ; Whenever "}" appears in SDP, it is escaped by " 4717 octetString = *(nonEscapeChar) 4718 nonEscapeChar = ( "" / %x01-7C / %x7E-FF ) 4719 quotedString = DQUOTE 1*64(SafeChar / RestChar/ WSP) DQUOTE 4721 Internet draft MEGACO Protocol January 27, 2000 4723 UINT16 = 1*5(DIGIT) ; %x0-FFFF 4724 UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF 4726 NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 4727 VALUE = quotedString / 1*64(SafeChar) 4728 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / 4729 "!" / "_" / "/" / "'" / "?" / "@" / 4730 "^" / "`" / "~" / "*" / "$" / " 4731 "(" / ")" / "%" / "|" / "." 4733 EQUAL = LWSP %x3D LWSP ; "=" 4734 COLON = %x3A ; ":" 4735 LBRKT = LWSP %x7B LWSP ; "{" 4736 RBRKT = LWSP %x7D LWSP ; "}" 4737 COMMA = LWSP %x2C LWSP ; "," 4738 DOT = %x2E ; "." 4739 SLASH = %x2F ; "/" 4740 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 4741 DIGIT = %x30-39 ; 0-9 4742 DQUOTE = %x22 ; " (Double Quote) 4743 HEXDIG = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" ) 4744 SP = %x20 ; space 4745 HTAB = %x09 ; horizontal tab 4746 CR = %x0D ; Carriage return 4747 LF = %x0A ; linefeed 4748 LWSP = *( WSP / COMMENT / EOL ) 4749 EOL = (CR [LF] / LF ) 4750 WSP = SP / HTAB ; white space 4751 SEP = ( WSP / EOL / COMMENT) LWSP 4752 COMMENT = ";" *(SafeChar/ RestChar / WSP / %x22) EOL 4753 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" / 4754 "<" / ">" / "=" 4756 AddToken = ("Add" / "A") 4757 AuditToken = ("Audit" / "AT") 4758 AuditCapToken = ("AuditCapability" / "AC") 4759 AuditValueToken = ("AuditValue" / "AV") 4760 AuthToken = ("Authentication" / "AU") 4761 BothwayToken = ("Bothway" / "BW") 4762 BriefToken = ("Brief" / "BR") 4763 BufferToken = ("Buffer" / "BF") 4764 CtxToken = ("Context" / "C") 4765 ContextAuditToken = ("ContextAudit" / "CA") 4766 DigitMapToken = ("DigitMap" / "DM") 4767 DiscardToken = ("Discard" / "DS") 4768 DisconnectedToken = ("Disconnected" / "DC") 4769 DelayToken = ("Delay" / "DL") 4771 Internet draft MEGACO Protocol January 27, 2000 4773 DeleteToken = ("Delete" / "DE") 4774 DurationToken = ("Duration" / "DR") 4775 EmbedToken = ("Embed" / "EB") 4776 EmergencyToken = ("Emergency" / "EM") 4777 ErrorToken = ("Error" / "ER") 4778 EventBufferToken = ("EventBuffer" / "EB") 4779 EventsToken = ("Events" / "E") 4780 FailoverToken = ("Failover" / "FL") 4781 ForcedToken = ("Forced" / "FO") 4782 GracefulToken = ("Graceful" / "GR") 4783 H221Token = ("H221" ) 4784 H223Token = ("H223" ) 4785 H226Token = ("H226" ) 4786 HandOffToken = ("HandOff" / "HO") 4787 InactiveToken = ("Inactive" / "IN") 4788 IsolateToken = ("Isolate" / "IS") 4789 InSvcToken = ("InService" / "IV") 4790 KeepActiveToken = ("KeepActive" / "KA") 4791 LocalToken = ("Local" / "L") 4792 LocalControlToken = ("LocalControl" / "O") 4793 LoopbackToken = ("Loopback" / "LB") 4794 MediaToken = ("Media" / "M") 4795 MegacopToken = ("MEGACO" / "!") 4796 MethodToken = ("Method" / "MT") 4797 MgcIdToken = ("MgcIdToTry" / "MG") 4798 ModeToken = ("Mode" / "MO") 4799 ModifyToken = ("Modify" / "MF") 4800 ModemToken = ("Modem" / "MD") 4801 MoveToken = ("Move" / "MV") 4802 MTPToken = ("MTP") 4803 MuxToken = ("Mux" / "MX") 4804 NotifyToken = ("Notify" / "N") 4805 NotifyCompletionToken = ("NotifyCompletion" / "NC") 4806 ObservedEventsToken = ("ObservedEvents" / "OE") 4807 OnewayToken = ("Oneway" / "OW") 4808 OnOffToken = ("OnOff" / "OO") 4809 OutOfSvcToken = ("OutOfService" / "OS") 4810 PackagesToken = ("Packages" / "PG") 4811 PendingToken = ("Pending" / "PN") 4812 PriorityToken = ("Priority" / "PR") 4813 ProfileToken = ("Profile" / "PF") 4814 ReasonToken = ("Reason" / "RE") 4815 RecvonlyToken = ("ReceiveOnly" / "RC") 4816 ReplyToken = ("Reply" / "P") 4817 RestartToken = ("Restart" / "RS") 4818 RemoteToken = ("Remote" / "R") 4819 ReservedToken = ("Reserved" / "RV") 4820 SendonlyToken = ("SendOnly" / "SO") 4822 Internet draft MEGACO Protocol January 27, 2000 4824 SendrecvToken = ("SendReceive" / "SR") 4825 ServicesToken = ("Services" / "SV") 4826 ServiceStatesToken = ("ServiceStates" / "SI") 4827 ServiceChangeToken = ("ServiceChange" / "SC") 4828 ServiceChangeAddressToken = ("ServiceChangeAddress" / "AD") 4829 SignalListToken = ("SignalList" / "SL") 4830 SignalsToken = ("Signals" / "SG") 4831 SignalTypeToken = ("SignalType" / "SY") 4832 StatsToken = ("Statistics" / "SA") 4833 StreamToken = ("Stream" / "ST") 4834 SubtractToken = ("Subtract" / "S") 4835 SynchISDNToken = ("SynchISDN" / "SN") 4836 TerminationStateToken = ("TerminationState" / "TS") 4837 TestToken = ("Test" / "TE") 4838 TimeOutToken = ("TimeOut" / "TO") 4839 TopologyToken = ("Topology" / "TP") 4840 TransToken = ("Transaction" / "T") 4841 V18Token = ("V18") 4842 V22Token = ("V22") 4843 V22bisToken = ("V22b") 4844 V32Token = ("V32") 4845 V32bisToken = ("V32b") 4846 V34Token = ("V34") 4847 V76Token = ("V76") 4848 V90Token = ("V90") 4849 V91Token = ("V91") 4851 ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE) 4853 Parameters for Local descriptors and Remote descriptors are specified as 4854 tag-value pairs if binary encoding is used for the protocol. This annex 4855 contains the property names (PropertyID), the tags (Property Tag), type 4856 of the property (Type) and the values (Value).Values presented in the 4857 Value field when the field contains references shall be regarded as 4858 "information". The reference contains the normative values. If a value 4859 field does not contain a reference then the values in that field can be 4860 considered as "normative". 4862 Tags are given as hexadecimal numbers in this annex. When setting the 4863 value of a property, a MGC may underspecify the value according to one 4864 of the mechanisms specified in section 7.1.1. 4866 For type "enumeration" the value is represented by the value in brack- 4867 ets, e.g., Send(0), Receive(1). 4869 Internet draft MEGACO Protocol January 27, 2000 4871 C.1. General Media Attributes 4873 ________________________________________________________________________ 4874 |PropertyID | Tag | Type | Value | 4875 |Media |1001 |Enumeration|Audio(0), Video(1) ,Data(2), | 4876 |TransMode |1002 |Enumeration|Send(0), Receive(1), Send&Receive(2) | 4877 |NumChan |1003 |UINT | 0-255 | 4878 |SamplingRate |1004 |UINT | 0-2^32 | 4879 |Bitrate |1005 |Integer |(0..4294967295) Note-units of 100 bit | 4880 |Acodec |1006 | |. Audio Codec Type | 4881 |Samplepp |1007 |UINT |Maximum samples per packet:0-65535 | 4882 |Silencesupp |1008 |BOOLEAN |Silence Suppression | 4883 |Encrypttype |1009 |Octet str |Ref.: rec. H.245 | 4884 |Encryptkey |100A |Octet str |SIZE(0..65535) Encryption key | 4885 |Echocanc |100B |Enumeration|Echo Canceller:Off(0),G.165(1),G168(2)| 4886 |Gain |100C |UINT |Gain in db: 0-65535 | 4887 |Jitterbuff |100D |UINT |Jitter buffer size in ms: 0-65535 | 4888 |PropDelay |100E |UINT | Propagation Delay: 0..65535 | 4889 |RTPpayload |100F |integer |Payload type in RTP Profile | 4890 |_____________|_____|___________|______________________________________| 4892 C.2. Mux Properties 4894 _________________________________________________________________________ 4895 |PropertyID| Tag | Type | Value | 4896 |H.221 | 2001 | Octet string| H222LogicalChannelParameters | 4897 |H223 | 2002 | Octet string| H223LogicalChannelParameters | 4898 |V76 | 2003 | Octet String| V76LogicalChannelParameters | 4899 |H2250 | 2004 | Octet String| H2250LogicalChannelParameters| 4900 |__________|____________|______________|________________________________| 4902 C.3. General bearer properties 4904 _____________________________________________________________________ 4905 | PropertyID| Tag | Type | Value | 4906 | Mediatx | 3001 | Enumeration| Media Transport Type | 4907 | BIR | 3002 | 4 OCTET | Value depends on transport | 4908 | NSAP | 3003 | 20 OCTET | Ref: ITU X.213 Annex A | 4909 |___________|____________|_____________|_____________________________| 4911 C.4. General ATM properties 4913 Internet draft MEGACO Protocol January 27, 2000 4915 _________________________________________________________________ 4916 | PropertyID| Tag | Type | Value | 4917 | AESA | 4001| 20 OCTETS | ATM End System Address | 4918 | VPVC | 4002| 2x16b int | VPC-VCI | 4919 | SC | 4003| 4 bits | Service Category | 4920 | BCOB | 4004| 5b integer | Broadband Bearer Class | 4921 | BBTC | 4005| octet | Broadband Transfer Capability| 4922 | ATC | 4006| Enumeration| I.371 ATM Traffic Cap. | 4923 | STC | 4007| 2 bits | Susceptibility to clipping | 4924 | UPCC | 4008| 2 bits | User Plane Connection config | 4925 | PCR0 | 4009| 24b integer| Peak Cell Rate CLP=0 | 4926 | SCR0 | 400A| 24b integer| Sustainable Cell Rate CLP=0 | 4927 | MBS0 | 400B| 24b integer| Maximum Burst Size CLP=0 | 4928 | PCR1 | 400C| 24b integer| Peak Cell Rate CLP=0+1 | 4929 | SCR2 | 400D| 24b integer| Sustain. Cell Rate CLP=0+1 | 4930 | MBS3 | 400E| 24b integer| Maximum Burst Size CLP=0+1 | 4931 | BEI | 400F| Boolean | Best Effort Indicator | 4932 | TI | 4010| Boolean | Tagging | 4933 | FD | 4011| Boolean | Frame Discard | 4934 | FCDV | 4012| 24b integer| Forward P-P CDV | 4935 | BCDV | 4013| 24b integer| Backward P-P CDV | 4936 | FCLR0 | 4014| 8b integer | Fwd Cell Loss Ratio CLP=0 | 4937 | BCLR0 | 4015| 8b integer | Bkwd P-P CLR CLP=0 | 4938 | FCLR1 | 4016| 8b integer | Fwd Cell Loss Ratio CLP=0+1 | 4939 | BCLR1 | 4017| 8b integer | Bkwd P-P CLR CLP=0+1 | 4940 | FCDV | 4018| 24b integer| Fwd Cell Delay Variation | 4941 | BCDV | 4019| 24b integer| Bkwd Cell Delay Variation | 4942 | FACDV | 401A| 24b integer| Fwd Acceptable P-P-P CDV | 4943 | BACDV | 401B| 24b integer| Bkwd Acceptable P-P CDV | 4944 | FCCDV | 401C| 24b integer| Fwd Cumulative P-P CDV | 4945 | BCCDV | 401D| 24b integer| Bkwd Cumulative P-P CDV | 4946 | FCLR | 401E| 8b integer | Acceptable Fwd CLR | 4947 | BCLR | 401F| 8b integer | Acceptable Bkwd CLR | 4948 | EETD | 4020| 16b integer| End-to-end transit delay | 4949 | Mediatx | 4021| | AAL Type | 4950 | QosClass | 4022| Integer | 0-4 Qos Class | 4951 | AALtype | 4023| 1 OCTET | AAL Type Reference | 4952 |___________|______|_____________|_______________________________| 4954 C.5. Frame Relay 4956 ______________________________________________________________________ 4957 PropertyID Tag Type Value 4958 DLCI 5001 Unsigned Integer Data link connection id 4959 CID 5002 Unsigned Integer sub-channel id. 4960 SID 5003 Unsigned Integer silence insertion descriptor 4961 Payload 5004 Unsigned Integer Primary Payload Type 4963 Internet draft MEGACO Protocol January 27, 2000 4965 |___________|______|__________________|_______________________________| 4967 C.6. IP 4969 _____________________________________________________________________ 4970 | PropertyID| Tag | Type | Value | 4971 | IPv4 | 6001 | 32 BITS | Ipv4Address or Ipv6 address | 4972 | IPv6 | 6002 | 128 BITS | IPv6 Address | 4973 | Port | 6002 | 0-65535 | Port | 4974 | TCP | 6003 | Boolean | | 4975 | UDP | 6004 | Boolean | | 4976 |___________|____________|____________|______________________________| 4978 C.7. ATM AAL2 4980 _______________________________________________________________________________ 4981 |PropertyID| Tag | Type | Value | 4982 |AESA | 7001 | 20 OCTETS | AAL2 service endpoint address | 4983 |BIR | See C.3| 4 OCTETS | Served user generated reference | 4984 |ALC | 7002 | 12 OCTETS | AAL2 link | 4985 |SSCS | 7003 | 8..14 OCTETS | Service specific convergence sublayer | 4986 |SUT | 7004 | 1..254 octets| Served user transport param | 4987 |TCI | 7005 | BOOLEAN | Test connection | 4988 |Timer_CU | 7006 | 32b integer | Timer-CU | 4989 |MaxCPSSDU | 7007 | 8b integer | Max. Common Part Sublayer SDU | 4990 |SCLP | 7008 | Boolean | Set Cell Local PriorityLP bit | 4991 |EETR | 7009 | Boolean | End to End Timing Required | 4992 |__________|_________|_______________|________________________________________| 4994 C.8. ATM AAL1 4996 ______________________________________________________________________________ 4997 |PropertyID| Tag | Type | Value | 4998 |BIR | See Table C.3| 4 OCTETS |GIT (Generic Identifier Transport)| 4999 |AAL1ST | 8001 | 1 OCTET | AAL1 Subtype | 5000 |CBRR | 8002 | 1 OCTET | CBR Rate | 5001 |SCRI | 8003 | 1 OCTET | Src. Clock Freq. Recovery Method | 5002 |ECM | 8004 | 1 OCTET | Error Correction Method | 5003 |SDTB | 8005 | 16b integer | Structured Data Transfer Blksize | 5004 |PFCI | 8006 | 8b integer | Partially filled cells identifier| 5005 |EETR | See Table C.7| See Table C.7| | 5006 |__________|_______________|_______________|__________________________________| 5008 Internet draft MEGACO Protocol January 27, 2000 5010 C.9. Bearer Capabilities 5012 ________________________________________________________________________ 5013 |PropertyID | Tag | Type | Value | 5014 |TMR | 9001| 1 OCTET | Transmission Medium Requirement | 5015 |TMRSR | 9002| 1 OCTET | Trans. Medium Requirement Subrate| 5016 |Contcheck | 0003| BOOLEAN | Continuity Check | 5017 |ITC | 9004| 5 BITS | Information Transfer Capability | 5018 |TransMode | 9005| 2 BITS | Transfer Mode | 5019 |TransRate | 9006| 5 BITS | Transfer Rate | 5020 |MULT | 9007| 7 BITS | Rate Multiplier | 5021 |USI | 9008| 5 BITS | User Information Layer 1 Protocol| 5022 |Syncasync | 9009| BOOLEAN | Synchronous-Asynchronous | 5023 |Userrate | 900B| 5 BITS | User Rate Reference | 5024 |INTRATE | 900C| 2 BITS | Intermediate Rate | 5025 |Nictx | 900D| BOOLEAN | Tx Network Independent Clock | 5026 |Nicrx | 900E| BOOLEAN | Rx Network independent clock | 5027 |Flowconttx | 900F| BOOLEAN | Tx Flow Control | 5028 |Flowcontrx | 9010| BOOLEAN | Rx Flow control | 5029 |Rateadapthdr | 9011| BOOLEAN | Rate adapt header-no header | 5030 |Multiframe | 9012| BOOLEAN | Multiple frame estab. | 5031 |OPMODE | 9013| BOOLEAN | Mode of operation | 5032 |Llidnegot | 9014| BOOLEAN | Logical link identifier neg. | 5033 |Assign | 9015| BOOLEAN | Assignor-assignee | 5034 |Inbandneg | 9016| BOOLEAN | In-band or out-band negotiation | 5035 |Stopbits | 9017| 2 BITS | Number of stop bits | 5036 |Databits | 9018| 2 BIT | Number of data bits | 5037 |Parity | 9019| 3 BIT | Parity information | 5038 |Duplexmode | 901A| BOOLEAN | Mode duplex | 5039 |Modem | 901B| 6 BIT | Modem Type | 5040 |layer2prot | 901C| 5 BIT | User info layer 2 protocol | 5041 |layer3prot | 901D| 5 BIT | User info layer 3 protocol | 5042 |addlayer3prot| 901E| OCTET | Addl User Info L3 protocol | 5043 |DialledN | 901F| 10 OCTETS | Dialled Number | 5044 |DiallingN | 9020| 10 OCTETS | Dialling Number | 5045 |ECHOCI | 9021| Enumeration| Echo Control Information | 5046 |NCI | 9022| 1 OCTET | Nature of Connection Indicators | 5047 |_____________|______|_____________|___________________________________| 5049 C.10. AAL5 Properties 5051 ______________________________________________________________________ 5052 | PropertyID| Tag | Type | Value | 5053 | FMSDU | A001 | 32b integer| Forward Maximum CPCS-SDU Size | 5054 | BMSDU | A002 | 2b integer | Backwards Maximum CPCS-SDU Size | 5055 | SSCS | See C.7| See C.7 | See table C.7 | 5056 | SC | See C.4| See C.4 | See table C.4 | 5058 Internet draft MEGACO Protocol January 27, 2000 5060 |___________|_________|_____________|_________________________________| 5062 C.11. SDP Equivalents 5064 ______________________________________________________________ 5065 | PropertyID| Tag | Type | Value | 5066 | SDP_V | B001| STRING| Protocol Version | 5067 | SDP_O | B002| STRING| Owner-creator and session ID | 5068 | SDP_S | B003| STRING| Sesson name | 5069 | SDP_I | B004| STRING| Session identifier | 5070 | SDP_U | B005| STRING| URI of descriptor | 5071 | SDC_E | B006| STRING| email address | 5072 | SDP_P | B007| STRING| phone number | 5073 | SDP_C | B008| STRING| Connection information | 5074 | SDP_B | B009| STRING| Bandwidth Information | 5075 | SDP_Z | B00A| STRING| time zone adjustment | 5076 | SDP_K | B00B| STRING| Encryption Key | 5077 | SDP_A | B00C| STRING| Zero or more session attributes| 5078 | SDP_T | B00D| STRING| Active Session Time | 5079 | SDP_R | B00E| STRING| Zero or more repeat times | 5080 |___________|______|________|_________________________________| 5082 C.12. H.245 5084 ________________________________________________________________________ 5085 |OLC | C001| octet string| H.245 OpenLogicalChannel structure. | 5086 |OLCack| C002| octet string| H.245 OpenLogicalChannelAck structure.| 5087 |OLCcnf| C003| octet string| OpenLogicalChannelConfirm structure. | 5088 |OLCrej| C004| octet string| OpenLogicalChannelReject structure. | 5089 |CLC | C005| octet string| CloseLogicalChannel structure. | 5090 |CLCack| C006| octet string| CloseLogicalChannelAck structure. | 5091 |______|______|______________|_________________________________________| 5093 ANNEX D TRANSPORT OVER IP (NORMATIVE) 5095 D.1. Transport over IP/UDP using Application Level Framing 5097 Protocol messages defined in this document may be transmitted over UDP. 5098 When no port is specified for by the other side (see section 7.2.8), the 5099 commands should be sent to the default port. 5101 D.1.1. Providing At-Most-Once Functionality 5103 Messages, being carried over UDP, may be subject to losses. In the 5105 Internet draft MEGACO Protocol January 27, 2000 5107 absence of a timely response, commands are repeated. Most commands are 5108 not idempotent. The state of the MG would become unpredictable if, for 5109 example, Add commands were executed several times. The transmission 5110 procedures shall thus provide an "At- Most-Once" functionality. 5112 Peer protocol entities are expected to keep in memory a list of the 5113 responses that they sent to recent transactions and a list of the tran- 5114 sactions that are currently outstanding. The transaction identifiers of 5115 incoming messages are compared to the transaction identifiers of the 5116 recent responses from the same entity. If a match is found, the entity 5117 does not execute the transaction, but simply repeats the response. The 5118 remaining messages will be compared to the list of current transactions. 5119 If a match is found, indicating a duplicate transaction, the entity does 5120 not execute the transaction, which is simply ignored. 5122 The procedure uses a long timer value, noted LONG-TIMER in the follow- 5123 ing. The timer should be set larger than the maximum duration of a 5124 transaction, which should take into account the maximum number of 5125 repetitions, the maximum value of the repetition timer and the maximum 5126 propagation delay of a packet in the network. A suggested value is 30 5127 seconds. 5129 The copy of the responses may be destroyed either LONG-TIMER seconds 5130 after the response is issued, or when the entity receives a confirmation 5131 that the response has been received, through the "Response Acknowledge- 5132 ment parameter". For transactions that are acknowledged through this 5133 parameter, the entity shall keep a copy of the transaction-id for LONG- 5134 TIMER seconds after the response is issued, in order to detect and 5135 ignore duplicate copies of the transaction request that could be pro- 5136 duced by the network. 5138 D.1.2. Transaction identifiers and three-way handshake 5140 Transaction identifiers are 32 bit integer numbers. A Media Gateway 5141 Controller may decide to use a specific number space for each of the MGs 5142 that they manage, or to use the same number space for all MGs that 5143 belong to some arbitrary group. MGCs may decide to share the load of 5144 managing a large MG between several independent processes. These 5145 processes will share the same transaction number space. There are mul- 5146 tiple possible implementations of this sharing, such as having a cen- 5147 tralized allocation of transaction identifiers, or pre-allocating non- 5148 overlapping ranges of identifiers to different processes. The implemen- 5149 tations shall guarantee that unique transaction identifiers are allo- 5150 cated to all transactions that originate from a logical MGC (identical 5151 mId). MGs can simply detect duplicate transactions by looking at the 5152 transaction identifier and mId only. 5154 The Response Acknowledgement parameter can be found in any message. It 5156 Internet draft MEGACO Protocol January 27, 2000 5158 carries a set of "confirmed transaction-id ranges". Entities may choose 5159 to delete the copies of the responses to transactions whose id is 5160 included in "confirmed transaction-id ranges" received in the transac- 5161 tion response messages. They should silently discard further commands 5162 when the transaction-id falls within these ranges. 5164 The "confirmed transaction-id ranges" values shall not be used if more 5165 than LONG-TIMER seconds have elapsed since the MG issued its last 5166 response to that MGC, or when a MG resumes operation. In this situa- 5167 tion, transactions should be accepted and processed, without any test on 5168 the transaction-id. 5170 Messages that carry the "Response Acknowledgement" parameter may be 5171 transmitted in any order. The entity shall retain the "confirmed 5172 transaction-id ranges" received in for LONG- TIMER seconds. 5174 The ASN.1 of Annex A is modified as follows. The definition of Transac- 5175 tion of Annex A is replaced by 5177 Transaction ::= CHOICE 5178 { 5179 transactionRequest TransactionRequest, 5180 transactionPending TransactionPending, 5181 transactionReply TransactionReply, 5182 transactionResponseAck TransactionResponseAck 5183 } 5185 The definition of TransactionResponseAck reads 5187 TransactionResponseAck ::= SEQUENCE 5188 { 5189 firstAck TransactionId, 5190 lastAck TransactionId OPTIONAL 5191 } 5193 If only the firstAck is present in a response acknowledgement, only one 5194 transaction is acknowledged. If both firstAck and lastAck are present, 5195 then the range of transactions from firstAck to lastAck is acknowledged. 5197 The ABNF of Annex B is modified so that: 5199 transactionList = 1*(transactionRequest / transactionReply / 5200 transactionPending / transactionResponseAck) 5202 transactionResponseAck = ResponseAckToken LBRKT transactionAck 5204 Internet draft MEGACO Protocol January 27, 2000 5206 *(COMMA transactionAck) RBRKT 5207 transactionAck = transactionID / (transactionID "-" transactionID) 5208 ResponseAckToken = "TransactionResponseAck" | "K" 5210 D.1.3. Computing retransmission timers 5212 It is the responsibility of the requesting entity to provide suitable 5213 time outs for all outstanding transactions, and to retry transactions 5214 when time outs have been exceeded. Furthermore, when repeated transac- 5215 tions fail to be acknowledged, it is the responsibility of the request- 5216 ing entity to seek redundant services and/or clear existing or pending 5217 connections. 5219 The specification purposely avoids specifying any value for the 5220 retransmission timers. These values are typically network dependent. The 5221 retransmission timers should normally estimate the timer value by 5222 measuring the time spent between the sending of a command and the return 5223 of a response. One possibility is to use the algorithm implemented in 5224 TCP-IP, which uses two variables: 5226 * The average acknowledgement delay, AAD, estimated through an 5227 exponentially smoothed average of the observed delays. 5229 * The average deviation, ADEV, estimated through an exponentially 5230 smoothed average of the absolute value of the difference between 5231 the observed delay and the current average. 5233 The retransmission timer, in TCP, is set to the sum of the average delay 5234 plus N times the average deviation. The maximum value of the timer 5235 should however be bounded for the protocol defined in this document, in 5236 order to guarantee that no repeated packet would be received by the 5237 gateways after LONG-TIMER seconds. A suggested maximum value is 4 5238 seconds. After any retransmission, the entity should do the following: 5240 * It should double the estimated value of the average delay, AAD 5242 * It should compute a random value, uniformly distributed between 0.5 5243 AAD and AAD 5245 * It should set the retransmission timer to the sum of that random 5246 value and N times the average deviation. 5248 This procedure has two effects. Because it includes an exponentially 5249 increasing component, it will automatically slow down the stream of mes- 5250 sages in case of congestion. Because it includes a random component, it 5251 will break the potential synchronization between notifications triggered 5252 by the same external event. 5254 Internet draft MEGACO Protocol January 27, 2000 5256 D.1.4. Provisional responses 5258 Executing some transactions may require a long time. Long execution 5259 times may interact with the timer based retransmission procedure. This 5260 may result either in an inordinate number of retransmissions, or in 5261 timer values that become too long to be efficient. Entities that can 5262 predict that a transaction will require a long execution time may send a 5263 provisional response, "Transaction Pending". They should send this 5264 response if they receive a repetition of a transaction that is still 5265 being executed. 5267 Entities that receive a Transaction Pending shall switch to a different 5268 repetition timer for repeating requests. The root termination has a 5269 property (ProvisionalResponseTimerValue), which can be set to the 5270 requested maximum number of milliseconds between receipt of a command 5271 and transmission of the TransactionPending response. Upon receipt of a 5272 final response, an immediate confirmation shall be sent, and normal 5273 repetition timers shall be used thereafter. Receipt of a Transaction 5274 Pending after receipt of a reply shall be ignored. 5276 D.1.5. Repeating Requests, Responses and Acknowledgements 5278 The protocol is organized as a set of transactions, each of which is 5279 composed request and a response, commonly referred to as an acknowledge- 5280 ment. The protocol messages, being carried over UDP, may be subject to 5281 losses. In the absence of a timely response, transactions are repeated. 5282 Entities are expected to keep in memory a list of the responses that 5283 they sent to recent transactions, i.e. a list of all the responses they 5284 sent over the last LONG-TIMER seconds, and a list of the transactions 5285 that are currently being executed. 5287 The repetition mechanism is used to guard against three types of possi- 5288 ble errors: 5290 * transmission errors, when for example a packet is lost due to noise 5291 on a line or congestion in a queue; 5293 * component failure, when for example an interface to a entity 5294 becomes unavailable; 5296 * entity failure, when for example an entire entity become unavail- 5297 able. 5299 The entities should be able to derive from the past history an estimate 5300 of the packet loss rate due to transmission errors. In a properly con- 5301 figured system, this loss rate should be kept very low, typically less 5302 than 1%. If a Media Gateway Controller or a Media Gateway has to repeat 5303 a message more than a few times, it is very legitimate to assume that 5305 Internet draft MEGACO Protocol January 27, 2000 5307 something else than a transmission error is occurring. For example, 5308 given a loss rate of 1%, the probability that five consecutive transmis- 5309 sion attempts fail is 1 in 100 billion, an event that should occur less 5310 than once every 10 days for a Media Gateway Controller that processes 1 5311 000 transactions per second. (Indeed, the number of repetition that is 5312 considered excessive should be a function of the prevailing packet loss 5313 rate.) We should note that the "suspicion threshold", which we will call 5314 "Max1", is normally lower than the "disconnection threshold", which 5315 should be set to a larger value. 5317 A classic retransmission algorithm would simply count the number of suc- 5318 cessive repetitions, and conclude that the association is broken after 5319 retransmitting the packet an excessive number of times (typically 5320 between 7 and 11 times.) In order to account for the possibility of an 5321 undetected or in-progress "failover", we modify the classic algorithm so 5322 that if the Media Gateway receives a valid ServiceChange message 5323 announcing a failover, it will start transmitting outstanding commands 5324 to that new MGC. Responses to commands are still transmitted to the 5325 source address of the command. 5327 In order to automatically adapt to network load, this document specifies 5328 exponentially increasing timers. If the initial timer is set to 200 5329 milliseconds, the loss of a fifth retransmission will be detected after 5330 about 6 seconds. This is probably an acceptable waiting delay to detect 5331 a failover. The repetitions should continue after that delay not only in 5332 order to perhaps overcome a transient connectivity problem, but also in 5333 order to allow some more time for the execution of a failover - waiting 5334 a total delay of 30 seconds is probably acceptable. 5336 It is, however, important that the maximum delay of retransmissions be 5337 bounded. Prior to any retransmission, it is checked that the time 5338 elapsed since the sending of the initial datagram is no greater than T- 5339 MAX. If more than T-MAX time has elapsed, the MG concludes that the MGC 5340 has failed, and it begins its recovery process. When the MG establishes 5341 a new control association, it can retransmit to the new MGC. The value 5342 T-MAX is related to the LONG- TIMER value: the LONG-TIMER value is 5343 obtained by adding to T-MAX the maximum propagation delay in the net- 5344 work. 5346 D.2. using TCP 5348 Protocol messages as defined in this document may be transmitted over 5349 TCP. When no port is specified by the other side (see section 7.2.8), 5350 the commands should be sent to the default port. The defined protocol 5351 has messages as the unit of transfer, while TCP is a stream-oriented 5352 protocol. TPKT, according to RFC1006 SHALL be used to delineate mes- 5353 sages within the TCP stream. 5355 Internet draft MEGACO Protocol January 27, 2000 5357 In a transaction-oriented protocol, there are still ways for transaction 5358 requests or responses to be lost. As such, it is recommended that enti- 5359 ties using TCP transport implement application level timers for each 5360 request and each response, similar to those specified for application 5361 level framing over UDP. 5363 D.2.1. Providing the At-Most-Once functionality 5365 Messages, being carried over TCP, are not subject to transport losses, 5366 but loss of a transaction request or its reply may nonetheless be noted 5367 in real implementations. In the absence of a timely response, commands 5368 are repeated. Most commands are not idempotent. The state of the MG 5369 would become unpredictable if, for example, Add commands were executed 5370 several times. 5372 To guard against such losses, it is recommended that entities follow the 5373 procedures in section D.1.1 5375 D.2.2. Transaction identifiers and three way handshake 5377 For the same reasons, it is possible that transaction replies may be 5378 lost even with a reliable delivery protocol such as TCP. It is recom- 5379 mended that entities follow the procedures in section D.1.2 5381 D.2.3. Computing retransmission timers 5383 With reliable delivery, the incidence of loss of a transaction request 5384 or reply is expected to be very low. Therefore, only simple timer 5385 mechanisms are required. Exponential back-off algorithms should not be 5386 necessary, although they could be employed where, as in an MGC, the code 5387 to do so is already required, since MGCs must implement ALF/UDP as well 5388 as TCP. 5390 D.2.4. Provisional responses 5392 As with UDP, executing some transactions may require a long time. Enti- 5393 ties that can predict that a transaction will require a long execution 5394 time may send a provisional response, "Transaction Pending". They should 5395 send this response if they receive a repetition of a transaction that is 5396 still being executed. 5398 Entities that receive a Transaction Pending shall switch to a longer 5399 repetition timer for that transaction. 5401 Entities shall retain Transactions and replies until they are confirmed. 5402 The basic procedure of section D.1.4 should be followed, but simple 5403 timer values should be sufficient. 5405 Internet draft MEGACO Protocol January 27, 2000 5407 D.2.5. Ordering of commands 5409 TCP provides ordered delivery of transactions. No special procedures 5410 are required. It should be noted that ALF/UDP allows sending entity to 5411 modify its behavior under congestion, and in particular, could reorder 5412 transactions when congestion is encountered. TCP could not achieve the 5413 same results. 5415 ANNEX E BASIC PACKAGES 5417 This Annex contains definitions of some packages for use with MEGACO. 5419 E.1. Generic 5421 PackageID: g (0x000e) 5422 Version: 1 5423 Extends: None 5424 Description: 5425 Generic package for commonly encountered items 5427 E.1.1. Properties 5429 None 5431 E.1.2. Events 5433 Cause 5434 EventID: cause (0x0001) 5435 Generic error eventEvent Descriptor 5436 Parameters: 5437 General Cause 5438 ParameterID: Generalcause (0x0001) 5439 This parameter groups the failures into six groups, 5440 which the MGC may act upon. 5441 Possible values: Enumerated, 5442 "NR" Normal Release (0x0001) 5443 "UR" Unavailable Resources (0x0002) 5444 "FT" Failure, Temporary (0x0003) 5445 "FP" Failure, Permanent (0x0004) 5446 "IW" Interworking Error (0x0005) 5447 "UN" Unsupported (0x0006) 5448 Failure Cause 5449 ParameterID: Failurecause (0x0002) 5450 Possible Values: OCTET STRING 5451 Description: The Release Cause is the value generated 5452 by the Released equipment, i.e. a released network 5453 connection. The concerned value is defined in the 5455 Internet draft MEGACO Protocol January 27, 2000 5457 appropriate bearer control protocol. 5459 Internet draft MEGACO Protocol January 27, 2000 5461 E.1.3. Signals 5463 None 5465 E.1.4. Statistics 5467 None 5469 E.2. Base Root Package 5471 Base Root Package 5473 PackageID: root (0x000f) 5474 Version: 1 5475 Extends: None 5476 Description: 5477 This package defines Gateway wide properties. 5479 E.2.1. Properties 5481 MaxNrOfContexts 5482 PropertyID: maxNumberOfContexts (0x0001) 5483 The value of this property gives the maximum number of 5484 contexts that can exist at any time. The NULL context 5485 is not included in this number. 5486 Type: Double 5487 Possible values: 1 and up 5488 MaxTerminationsPerContext 5489 PropertyID: maxTerminationsPerContext (0x0002) 5490 The maximum number of allowed terminations in a context, 5491 see section 6.1 5492 Type: Integer 5493 Possible Values: any integer 5494 Defined In: TerminationState 5495 normalMGExecutionTime 5496 PropertyId: normalMGExecutionTime (0x0003) 5497 Settable by the MGC to indicate the interval within which 5498 the MGC expects a response to any transaction from 5499 the MG (exclusive of network delay) 5500 Type: Integer 5501 Possible Values: any integer, represents milliseconds 5502 normalMGCExecutionTime 5503 PropertyId: normalMGCExecutionTime (0x0004) 5504 Settable by the MGC to indicate the interval within which 5505 the MG should expects a response to any transaction 5506 from the MGC (exclusive of network delay) 5508 Internet draft MEGACO Protocol January 27, 2000 5510 Type: Integer 5511 Possible Values: any integer, represents milliseconds 5512 ProvisionalResponseTimerValue 5513 PropertyId: ProvisionalResponseTimerValue (0x0005) 5514 Indicates the time within which to expect a Pending 5515 Response if a Transaction cannot be completed. 5516 Initially set to normalMGExecutionTime or 5517 normalMGCExecutionTime as appropriate, plus network 5518 delay, but may be lowered. 5519 Pattern 5520 PropertyId: Pattern (0x0006) 5521 Name pattern of a set of terminations in the gateway. 5522 Used to discover the names of terminations that 5523 can be audited. Includes ephemeral terminations. 5524 MGs SHOULD use one pattern for each type of 5525 termination (same packages implemented), but no 5526 two Patterns can have the same value. 5527 Type: String 5528 Possible Value: 5529 A string of up to 64 characters using the following 5530 characters: 5531 a-z,A-Z,0-9, and "/" - the actual character 5532 in the name 5533 * - any set of characters 5534 ?a - any single character 5535 ?0 - any digit 5536 ?a - any alpha 5537 [n,n,..,n] - alternatives, one of the 5538 alternatives listed, n can be a substring 5539 of alphas or digits 5540 [n-n] - range, any number in the range, 5541 n can be a number or an alpha, for example 5542 [00-27] or [a-e] 5543 Note, mixing of alternatives or ranges is allowed, 5544 as in: [0,3-5,8] 5545 Characteristics: Read-only 5546 MaxPatterns 5547 PropertyId: MaxPatterns (0x0007) 5548 The number of patterns in the gateway 5549 Type: Integer 5550 Possible Value: any integer 5551 Characteristics: Read-only 5552 PatternNum 5553 PropertyId: PatternNum (0x0008) 5554 Which pattern to read, zero based. Set by the MGC to 5555 read a specific pattern in Pattern 5556 Type: Integer 5557 Possible Value: any integer less than MaxPatterns 5559 Internet draft MEGACO Protocol January 27, 2000 5561 E.2.2. Events 5563 None 5565 E.2.3. Signals 5567 None 5569 E.2.4. Statistics 5571 None 5573 E.2.5. Procedures 5575 None 5577 E.3. Tone Generator Package 5579 PackageID: tonegen (0x0001) 5580 Version: 1 5581 Extends: None 5582 Description: 5583 This package defines signals to generate audio tones. 5584 This package does not specify parameter values. It is 5585 intended to be extendable. Generally, tones are defined 5586 as an individual signal with a parameter, ind, 5587 representing "interdigit" time delay, and a tone id to 5588 be used with playtones. A tone id should be kept 5589 consistent with any tone generation for the same tone. 5590 MGs are expected to be provisioned with the characteristics 5591 of appropriate tones for the country in which the MG is located. 5593 E.3.1. Properties 5595 None 5597 E.3.2. Events 5599 None 5601 E.3.3. Signals 5603 Play tone 5605 SignalID: pt (0x0001) 5606 Plays audio tone over an audio channel 5607 Signal Type: Brief 5609 Internet draft MEGACO Protocol January 27, 2000 5611 Duration: Provisioned 5612 Additional Parameters: 5613 Tone id list 5614 ParameterID: tl (0x0001) 5615 Type: list of tone ids. 5616 List of tones to be played in sequence. 5617 The list SHALL contain one or more tone ids. 5618 Inter signal duration 5619 ParameterID: ind (0x0002) 5620 Type: integer. 5621 Timeout between two consecutive tones in milliseconds 5623 No tone ids are specified in this package. Packages that extend this 5624 package can add possible values for tone id as well as adding individual 5625 tone signals 5627 E.3.4. Statistics 5629 None 5631 E.3.5. Procedures 5633 None 5635 E.4. Tone Detection Package 5637 PackageID: tonedet (0x0002) 5638 Version: 1 5639 Extends: None 5640 This Package defines events for audio tone detection. 5641 Tones are selected by name (tone id). MGs are expected 5642 to be provisioned with the characteristics of appropriate 5643 tones for the country in which the MG is located. 5645 This package does not specify parameter values. It is intended to be 5646 extendable. 5648 E.4.1. Properties 5650 None 5652 E.4.2. Events 5654 Start tone detected 5655 EventID: std, 0x0001 5656 Detects the start of a tone. The characteristics of positive 5658 Internet draft MEGACO Protocol January 27, 2000 5660 tone detection is implementation dependent. 5661 EventsDescriptor parameters: 5662 Tone id list 5663 ParameterID: tl (0x0001) 5664 Type: list of tone ids 5665 Possible values: The only tone id defined in this 5666 package is "wild card" which is "*" in 5667 text encoding and 0x0000 in binary. 5668 Extensions to this package would add 5669 possible values for tone id. 5670 If tl is "wild card", any tone id is detected 5671 ObservedEventsDescriptor parameters: 5672 Tone id 5673 ParameterID: tid (0x0003) 5674 Type: Enumeration 5675 Possible values: "wildcard" as defined above is the 5676 only value defined in this package. Extensions 5677 to this package would add additional possible 5678 values for tone id 5679 End tone detected 5680 EventID: etd, 0x0002 5681 Detects the end of a tone. 5682 EventDescriptor parameters: 5683 Tone id list 5684 ParameterID: tl (0x0001) 5685 Type: enumeration or list of enumerated types 5686 Possible values: No possible values are specified 5687 in this package. Extensions to this package 5688 would add possible values for tone id 5689 ObservedEventsDescriptor parameters: 5690 Tone id 5691 ParameterID: tid (0x0003) 5692 Type: Enumeration 5693 Possible values: "wildcard" as defined above is the 5694 only value defined in this package. 5695 Extensions to this package would add possible 5696 values for tone id 5697 Duration 5698 ParameterId: dur (0x0002) 5699 Type: integer, in milliseconds 5700 This parameter contains the duration of the tone 5701 from first detection until it stopped. 5702 Long tone detected 5703 EventID: ltd, 0x0003 5704 Detects that a tone has been playing for at least a certain 5705 amount of time 5706 EventDescriptor parameters: 5707 Tone id list 5709 Internet draft MEGACO Protocol January 27, 2000 5711 ParameterID: tl (0x0001) 5712 Type: enumeration or list 5713 Possible values: "wildcard" as defined above is the 5714 only value defined in this package. Extensions 5715 to this package would add possible values for 5716 tone id 5717 Duration: 5718 ParameterID: dur (0x0002) 5719 Type: integer, duration to test against 5720 Possible values: any legal integer, expressed in 5721 milliseconds 5722 ObservedEventsDescriptor parameters: 5723 Tone id: 5724 ParameterID: tid (0x0003) 5725 Possible values: No possible values are specified 5726 in this package. Extensions to this package 5727 would add possible values for tone id 5729 E.4.3. Signals 5731 None 5733 E.4.4. Statistics 5735 None 5737 E.4.5. Procedures 5739 None 5741 E.5. Basic DTMF Generator Package 5743 PackageID: dg (0x0003) 5744 Version: 1 5745 Extends: tonegen version 1 5746 This package defines the basic DTMF tones as signals and 5747 extends the allowed values of parameter tl of playtone 5748 in tonegen. 5750 E.5.1. Properties 5752 None 5754 E.5.2. Events 5756 None 5758 Internet draft MEGACO Protocol January 27, 2000 5760 E.5.3. Signals 5762 dtmf character 0 5763 SignalID: d0 (0x0010) 5764 Generate DTMF 0 tone. The physical characteristic of DTMF 0 5765 is defined in the gateway. 5766 Signal Type: Brief 5767 Duration: Provisioned 5768 Additional Parameters: 5769 None 5770 Additional Values: 5771 d0 (0x0010) is defined as a toneid for playtone 5773 The other dtmf characters are specified in exactly the same way. For 5774 brevity's sake only a table with the signal names and the signal IDs is 5775 included. Note that each dtmf character is defined as both a signal and 5776 a toneid, thus extending the basic tone generation package. Also note 5777 that dtmf SignalIds are different from the names used in a digit map. 5779 ________________________________ 5780 | Signal Name | Signal ID | 5781 | dtmf character 1| d1 (0x0011)| 5782 | dtmf character 2| d2 (0x0012)| 5783 | dtmf character 3| d3 (0x0013)| 5784 | dtmf character 4| d4 (0x0014)| 5785 | dtmf character 5| d5 (0x0015)| 5786 | dtmf character 6| d6 (0x0016)| 5787 | dtmf character 7| d7 (0x0017)| 5788 | dtmf character 8| d8 (0x0018)| 5789 | dtmf character 9| d9 (0x0019)| 5790 | dtmf character *| d* (0x0020)| 5791 | dtmf character #| d# (0x0021)| 5792 | dtmf character A| da (0x001a)| 5793 | dtmf character B| db (0x001b)| 5794 | dtmf character C| dc (0x001c)| 5795 | dtmf character D| dd (0x001d)| 5796 |_________________|_____________| 5798 E.5.4. Statistics 5800 None 5802 E.5.5. Procedures 5804 None 5806 Internet draft MEGACO Protocol January 27, 2000 5808 E.6. DTMF detection Package 5810 PackageID: dd (0x0004) 5811 Version: 1 5812 Extends: tonedet version 1 5813 This package defines the basic DTMF tones detection. 5814 This Package extends the possible values of tone id 5815 in the "start tone detected" "end tone detected" 5816 and "long tone detected" events. 5818 Additional tone id values are all tone ids described in package dg 5819 (basic DTMF generator package). 5821 Implementers of this package shall support d0-d9,d* and d#. Support of 5822 dA-dD is optional. 5824 E.6.1. Properties 5826 None 5828 E.6.2. Events 5830 DTMF digits 5831 EventIds are defined with the same names as the SignalIds 5832 defined in the table found in section E.5.3 5833 DigitMap Completion Event 5834 EventID: ce, 0x0001 5835 Raised when the termination tone is detected on a digit map. 5836 EventsDescriptor parameters: none 5837 ObservedEventsDescriptor parameters: 5838 DigitString 5839 ParameterID: ds (0x0001) 5840 Type: list of tone ids 5841 Possible values: any of the DTMF or MF digits 5843 E.6.3. Signals 5845 None 5847 E.6.4. Statistics 5849 None 5851 E.6.5. Procedures 5853 None 5855 Internet draft MEGACO Protocol January 27, 2000 5857 E.7. Call Progress Tones Generator Package 5859 PackageID: cg, 0x0005 5860 Version: 1 5861 Extends: tonegen version 1 5862 This package defines the basic call progress tones as signals 5863 and extends the allowed values of the tl parameter of 5864 playtone in tonegen. 5866 E.7.1. Properties 5868 None 5870 E.7.2. Events 5872 None 5874 E.7.3. Signals 5876 Dial Tone 5877 SignaID: dt (0x0030) 5878 Generate dial tone. The physical characteristic of dial tone 5879 is available in the gateway. 5880 Signal Type: Timeout 5881 Duration: Provisioned 5882 Additional Parameters: 5883 None 5884 Additional Values 5885 dt (0x0030) is defined as a tone id for playtone 5887 The other tones of this package are defined in exactly the same way. For 5888 brevity's sake only a table with the signal names and the signal IDs is 5889 included. Note that each tone is defined as both a signal and a toneid, 5890 thus extending the basic tone generation package. 5891 l | l. 5892 Signal Name!Signal ID/tone id Ringing Tone!rt (0x0031) Busy Tone!bt 5893 (0x0032) Congestion Tone!ct (0x0033) Special Information 5894 Tone!sit(0x0034) Warning Tone!wt (0x0035) Payphone Recognition Tone!pt 5895 (0x0036) Call Waiting Tone!cw (0x0037) Caller Waiting Tone!cr (0x0038) 5897 E.7.4. Statistics 5899 None 5901 Internet draft MEGACO Protocol January 27, 2000 5903 E.7.5. Procedures 5905 NOTE - The required set of tone ids corresponds to those defined in 5906 Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)]. See 5907 E.180 for definition of the meanings of these tones. 5909 E.8. Call Progress Tones Detection Package 5911 PackageID: cd (0x0006) 5912 Version: 1 5913 Extends: tonedet version 1 5914 This package defines the basic call progress detection tones. 5915 This Package extends the possible values of tone id 5916 in the "start tone detected", "end tone detected" and 5917 "long tone detected" events. 5918 Additional values 5919 tone id values are defined for start tone detected, 5920 end tone detected and long tone detected with 5921 the same values as those in package cg (call 5922 progress tones generation package). 5924 The required set of tone ids corresponds to Recommendation E.180/Q.35 5925 [ITU-T Recommendation E.180/Q.35 (1998)]. See Recommendation E.180/Q.35 5926 for definition of the meanings of these tones. 5928 E.8.1. Properties 5930 none 5932 E.8.2. Events 5934 Events are defined as in the dtmf detection package (dd) for the tones 5935 listed in the table of section E.7.3 5937 E.8.3. Signals 5939 none 5941 E.8.4. Statistics 5943 none 5945 E.8.5. Procedures 5947 none 5949 Internet draft MEGACO Protocol January 27, 2000 5951 E.9. Analog Line Supervision Package 5953 PackageID: al, 0x0009 5954 Version: 1 5955 Extends: None 5956 This package defines events and signals for an analog line. 5958 E.9.1. Properties 5960 None 5962 E.9.2. Events 5964 onhook 5965 EventID: on (0x0004) 5966 Detects handset going on hook. 5967 EventDescriptor parameters 5968 None 5969 ObservedEventsDescriptor parameters 5970 None 5971 offhook 5972 EventID: of (0x0005) 5973 Detects handset going off hook. 5974 EventDescriptor parameters 5975 None 5976 ObservedEventsDescriptor parameters 5977 None 5978 flashhook 5979 EventID: fl, 0x0006 5980 Detects handset flash. A flash occurs when an onhook is 5981 followed by an offhook between a minimum and 5982 maximum duration. 5983 EventDescriptor parameters 5984 Minimum duration 5985 ParameterID: mindur (0x0004) 5986 Type: integer in milliseconds 5987 Default value is provisioned 5988 Maximum duration 5989 ParameterID: maxdur (0x0005) 5990 Type: integer in milliseconds 5991 Default value is provisioned 5992 ObservedEventsDescriptor parameters 5993 None 5995 E.9.3. Signals 5997 ring 5999 Internet draft MEGACO Protocol January 27, 2000 6001 SignalID: ri, 0x0002 6002 Applies ringing on the line 6003 Signal Type: TimeOut 6004 Duration: Provisioned 6005 Additional Parameters: 6006 Cadence 6007 ParameterID: cad (0x0006) 6008 Type: list of integers representing durations of 6009 alternating on and off segments, constituting 6010 a complete ringing cycle starting with an on. 6011 Units in milliseconds 6012 Default is fixed or provisioned. Restricted function 6013 MGs may ignore cadence values they are 6014 incapable of generating. 6015 Frequency 6016 ParameterID: freq (0x0007) 6017 Type: integer in Hz 6018 Default is fixed or provisioned. Restricted function 6019 MGs may ignore frequency values they are 6020 incapable of generating. 6022 E.9.4. Statistics 6024 None 6026 E.9.5. Procedures 6028 None 6030 E.10. Basic Continuity Package 6032 PackageID: ct (0x000a) 6033 Version: 1 6034 Extends: None 6035 This package defines events and signals for continuity test. 6037 E.10.1. Properties 6039 None 6041 E.10.2. Events 6043 Completion 6044 EventID: cmp, 0x0005 6045 Detects test completion. 6046 EventDescriptor parameters 6048 Internet draft MEGACO Protocol January 27, 2000 6050 None 6051 ObservedEventsDescriptor parameters 6052 Result 6053 ParameterID: res (0x0008) 6054 Type: Enumeration 6055 Possible values: success (0x0001), failure (0x0000) 6057 E.10.3. Signals 6059 Initiate 6060 SignalID: ini (0x0003) 6061 Initiates continuity test of a specified type 6062 Signal Type: OnOff 6063 Additional Parameters: 6064 Test type 6065 ParameterID: tt 6066 Type: enumeration of possible test types 6067 Possible Values: q724 6068 Default is provisioned 6069 Respond 6070 SignalID: rsp (0x0004) 6071 Responds to a continuity test of a specified type 6072 Signal Type: OnOff 6073 Additional Parameters: 6074 Test type 6075 ParameterID: tt 6076 Type: enumeration of possible test types 6077 Possible Values: q724 6078 Default is provisioned 6080 E.10.4. Statistics 6082 None 6084 E.10.5. Procedures 6086 When a MGC initiates or responds to a MG by sending the Initiate or 6087 Response signal to the MG, the MG shall perform the continuity test in 6088 accordance with section 7 (for 4-wire speech circuits) or section 8 (for 6089 2-wire speech circuits) of Recommendation Q.724. 6091 E.11. Network Package 6093 PackageID: nt (0x000b) 6094 Version: 1 6095 Extends: None 6097 Internet draft MEGACO Protocol January 27, 2000 6099 This package defines properties of network terminations 6100 independent of network type. 6102 E.11.1. Properties 6104 Maximum Jitter Buffer 6105 PropertyID: jit (0x0007) 6106 This property puts a maximum size on the jitter buffer. 6107 Type: integer in milliseconds 6108 Possible Values: This property is specified in milliseconds. 6109 Defined In: LocalControlDescriptor 6110 Characteristics: read/write 6112 E.11.2. Events 6114 network failure 6115 EventID: netfail, 0x0005 6116 The termination generates this event upon detection of a 6117 failure due to external or internal network reasons. 6118 EventDescriptor parameters 6119 none 6120 ObservedEventsDescriptor parameters 6121 cause 6122 ParameterID: cs (0x0001) 6123 Type: String 6124 Possible values: any text string 6125 This parameter may be included with the failure 6126 event to provide diagnostic information on the 6127 reason of failure. 6128 quality alert 6129 EventID: qualert, 0x0006 6130 This property allows the MG to indicate a loss of quality 6131 of the network connection. The MG may do this by 6132 measuring packet loss, interarrival jitter, propogation 6133 delay and then indicating this using a percentage of 6134 quality loss. 6135 EventDescriptor parameters 6136 Threshold 6137 ParameterId: th (0x0001) 6138 Type: integer 6139 Possible Values: threshold for percent of quality 6140 loss measured, calculated based on a 6141 provisioned method, that could take into 6142 consideration packet loss, jitter, and delay 6143 for example. Event is triggered when 6144 calculation exceeds the threshold. 6146 Internet draft MEGACO Protocol January 27, 2000 6148 ObservedEventsDescriptor parameters 6149 Threshold 6150 ParameterId: th (0x0001) 6151 Type: integer 6152 Possible Values: percent of quality loss measured, 6153 calculated based on a provisioned method, 6154 that could take into consideration packet loss, 6155 jitter, and delay for example. 6157 E.11.3. Signals 6159 none 6161 E.11.4. Statistics 6163 Duration 6164 StatisticsID: dur (0x0001) 6165 Description: Provides duration of time the termination has 6166 been in the context. 6167 Type: Double, in milliseconds 6168 Octets Sent 6169 StatisticID: os (0x0002) 6170 Type: double 6171 Possible Values: any 64 bit integer 6172 Octets Received 6173 StatisticID: or (0x0003) 6174 Type: double 6175 Possible Values: any 64 bit integer 6177 E.11.5. Procedures 6179 none 6181 E.12. RTP Package 6183 PackageID: rtp (0x000c) 6184 Version: 1 6185 Extends: Network Package version 1 6186 This package is used to support packet based multimedia 6187 data transfer by means of the Real-time Transport Protocol 6188 (RTP) [RFC 1889]. 6190 E.12.1. Properties 6192 None 6194 Internet draft MEGACO Protocol January 27, 2000 6196 E.12.2. Events 6198 Payload Transition 6199 EventID: pltrans, 0x0001 6200 This event detects and notifies when there is a transition 6201 of the RTP payload format from one format to another. 6202 EventDescriptor parameters 6203 none 6204 ObservedEventsDescriptor parameters 6205 ParameterName: rtppayload 6206 ParameterID: rtppltype, 0x01 6207 Type: list of enumerated types. 6208 Possible values: The encoding method shall be 6209 specified by using one or several valid 6210 encoding names, as defined in the RTP AV 6211 Profile or registered with IANA. 6213 E.12.3. Signals 6215 None 6217 E.12.4. Statistics 6219 Packets Sent 6220 StatisticID: ps (0x0004) 6221 Type: double 6222 Possible Values: any 64 bit integer 6223 Packets Received 6224 StatisticID: pr (0x0005) 6225 Type: double 6226 Possible Values: any 64 bit integer 6227 Packet Loss 6228 StatisticID: pl (0x0006) 6229 Describes the current rate of packet loss on an RTP stream, 6230 as defined in IETF RFC 1889. Packet loss is expressed as 6231 percentage value: number of packets lost in the interval 6232 between two reception reports, divided by the number of 6233 packets expected during that interval. 6234 Type: double 6235 Possible Values: a 32 bit whole number and a 32 bit fraction. 6236 Jitter 6237 StatisticID: jit (0x0007) 6238 Requests the current value of the interarrival jitter 6239 on an RTP stream as defined in IETF RFC 1889. 6240 Jitter measures the variation in interarrival time 6241 for RTP data packets. 6242 Delay 6244 Internet draft MEGACO Protocol January 27, 2000 6246 StatisticID:delay (0x0008) 6247 Requests the current value of packet propagation delay 6248 expressed in timestamp units. Same as average latency. 6250 E.12.5. Procedures 6252 none 6254 E.13. DS0 Package 6256 PackageID: ds0 (0x000d) 6257 Version: 1 6258 Extends: Network Package version 1 6259 This package is used to support DS0 terminations. 6261 E.13.1. Properties 6263 Echo Cancellation 6264 PropertyID: ec (0x0008) 6265 By default, the telephony gateways always perform 6266 echo cancellation. However, it is necessary, for some 6267 calls, to turn off these operations. 6268 Type: boolean 6269 Possible Values: 6270 "on" (when the echo cancellation is requested) and 6271 "off" (when it is turned off.) 6272 The default is "on". 6273 Defined In: LocalControlDescriptor 6274 Characteristics: read/write 6275 Gain Control 6276 PropertyID: gain (0x000a) 6277 Gain control, or usage of of signal level adaptation and 6278 noise level reduction is used to adapt the level of 6279 the signal. However, it is necessary, for example 6280 for modem calls, to turn off this function. 6281 Type: enumeration (integer) 6282 Possible Values: 6283 The gain control parameter may either be specified 6284 as "automatic" (0xffffffff), or as an explicit number 6285 of decibels of gain (any other integer value). 6286 The default is provisioned in the MG. 6287 Defined In: LocalControlDescriptor 6288 Characteristics: read/write 6290 Internet draft MEGACO Protocol January 27, 2000 6292 E.13.2. Events 6294 none 6296 E.13.3. Signals 6298 none 6300 E.13.4. Statistics 6302 None 6304 E.13.5. Procedures 6306 None 6308 APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) 6310 All Megaco implementors must read the normative part of this document 6311 carefully before implementing from it. No one should use the examples in 6312 this section as stand-alone explanations of how to create protocol mes- 6313 sages. 6315 The examples in this section use SDP for encoding of the Local and 6316 Remote stream descriptors. SDP is defined in RFC 2327. If there is any 6317 discrepancy between the SDP in the examples, and RFC 2327, the RFC 6318 should be consulted for correctness. Audio profiles used are those 6319 defined in RFC 1890, and others registered with IANA. For example, G.711 6320 A-law is called PCMA in the SDP, and is assigned profile 0. G.723 is 6321 profile 4, and H263 is profile 34. See also http://www.isi.edu/in- 6322 notes/iana/assignments/rtp-parameters 6324 A.1. Residential Gateway to Residential Gateway Call 6326 This example scenario illustrates the use of the elements of the proto- 6327 col to set up a Residential Gateway to Residential Gateway call over an 6328 IP-based network. For simplicity, this example assumes that both 6329 Residential Gateways involved in the call are controlled by the same 6330 Media Gateway Controller. 6332 20.1.1. Programming Residential GW Analog Line Terminations for Idle 6333 Behavior 6335 The following illustrates the API invocations from the Media Gateway 6336 Controller and Media Gateways to get the Terminations in this scenario 6337 programmed for idle behavior. Both the originating and terminating 6338 Media Gateways have idle AnalogLine Terminations programmed to look for 6339 call initiation events (i.e.-offhook) by using the Modify Command with 6341 Internet draft MEGACO Protocol January 27, 2000 6343 the appropriate parameters. The null Context is used to indicate that 6344 the Terminations are not yet involved in a Context. The ROOT termination 6345 is used to indicate the entire MG instead of a termination within the 6346 MG. 6348 In this example, MG1 has the IP address 124.124.124.222, MG2 is 6349 125.125.125.111, and the MGC is 123.123.123.4. The default Megaco port 6350 is 55555 for all three. 6352 1. An MG registers with an MGC using the ServiceChange command: 6354 MG1 to MGC: 6355 MEGACO/1 [124.124.124.222] 6356 Transaction = 9998 { 6357 Context = - { 6358 ServiceChange = ROOT {Services { 6359 Method=Restart, 6360 ServiceChangeAddress=55555, Profile=ResGW/1} 6361 } 6362 } 6363 } 6365 2. The MGC sends a reply: 6367 MGC to MG1: 6368 MEGACO/1 [123.123.123.4]:55555 6369 Reply = 9998 { 6370 Context = - {ServiceChange = ROOT { 6371 Services {ServiceChangeAddress=55555, Profile=ResGW/1} } } 6372 } 6374 3. The MGC programs a Termination in the NULL context. The termina- 6375 tionId is A4444, the streamId is 1, the requestId in the Events 6376 descriptor is 2222. The mId is the identifier of the sender of 6377 this message, in this case, it is the IP address and port 6378 [123.123.123.4]:55555. Mode for this stream is set to SendReceive. 6379 "al" is the analog line supervision package. 6381 MGC to MG1: 6382 MEGACO/1 [123.123.123.4]:55555 6383 Transaction = 9999 { 6384 Context = - { 6385 Modify = A4444 { 6386 Media { Stream = 1 { 6387 LocalControl { 6388 Mode = SendReceive, 6390 Internet draft MEGACO Protocol January 27, 2000 6392 ds0/gain=2, ; in dB, 6393 ds0/ec=G165 6394 }, 6395 Local { 6396 v=0 6397 c=IN IP4 $ 6398 m=audio $ RTP/AVP 0 6399 a=fmtp:PCMU VAD=X-NNVAD ; special voice activity 6400 ; detection algorithm 6401 } 6402 } 6403 }, 6404 Events = 2222 {al/of} 6405 } 6406 } 6407 } 6409 The dialplan script could have been loaded into the MG previously. Its 6410 function would be to wait for the OffHook, turn on dialtone and start 6411 collecting DTMF digits. However in this example, we use the digit map, 6412 which is put into place after the offhook is detected (step 5 below). 6414 Note that the embedded EventsDescriptor could have been used to combine 6415 steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. 6417 4. The MG1 accepts the Modify with this reply: 6419 MG1 to MGC: 6420 MEGACO/1 [124.124.124.222]:55555 6421 Reply = 9999 { 6422 Context = - {Modify = A4444} 6423 } 6425 5. A similar exchange happens between MG2 and the MGC, resulting in an 6426 idle Termination called A5555. 6428 A.1.2. Collecting Originator Digits and Initiating Termination 6430 The following builds upon the previously shown conditions. It illus- 6431 trates the transactions from the Media Gateway Controller and originat- 6432 ing Media Gateway (MG1) to get the originating Termination (A4444) 6433 through the stages of digit collection required to initiate a connection 6434 to the terminating Media Gateway (MG2). 6436 Internet draft MEGACO Protocol January 27, 2000 6438 6. MG1 detects an offhook event from User 1 and reports it to the 6439 Media Gateway Controller via the Notify Command. 6441 MG1 to MGC: 6442 MEGACO/1 [124.124.124.222]:55555 6443 Transaction = 10000 { 6444 Context = - { 6445 Notify = A4444 {ObservedEvents =2222 { 6446 19990729T22000000:al/of}} 6447 } 6448 } 6450 7. And the Notify is acknowledged. 6452 MGC to MG1: 6453 MEGACO/1 [123.123.123.4]:55555 6454 Reply = 10000 { 6455 Context = - {Notify = A4444} 6456 } 6458 8. The MGC Modifies the termination to play dial tone, and to look for 6459 digits now. There is also an embedded event to stop dialtone upon 6460 detection of the first digit. dd is the DTMF Detection package, and 6461 ce is the completion event. 6463 MGC to MG1: 6464 MEGACO/1 [123.123.123.4]:55555 6465 Transaction = 10001 { 6466 Context = - { 6467 Modify = A4444 { 6468 Events = 2223 { 6469 al/on, dd/ce {DigitMap=Dialplan0} 6470 }, 6471 Signals {cg/dt}, 6472 DigitMap= Dialplan0{ 6473 (0S| 00S|[1-7]xLxx|8Lxxxxxxx|#xxxxxxx|*xx|9L1xxxxxxxxxx|9L011x.S)} 6474 } 6475 } 6476 } 6478 9. And the Modify is acknowledged. 6480 Internet draft MEGACO Protocol January 27, 2000 6482 MG1 to MGC: 6483 MEGACO/1 [124.124.124.222]:55555 6484 Reply = 10001 { 6485 Context = - {Modify = A4444} 6486 } 6488 10. Next, digits are accumulated by MG1 as they are dialed by User 1. 6489 Dialtone is stopped upon detection of the first digit, using the 6490 embedded event in step 8. When an appropriate match is made of col- 6491 lected digits against the currently programmed Dialplan for A4444, 6492 another Notify is sent to the Media Gateway Controller. 6494 MG1 to MGC: 6495 MEGACO/1 [124.124.124.222]:55555 6496 Transaction = 10002 { 6497 Context = - { 6498 Notify = A4444 {ObservedEvents =2223 { 6499 19990729T22010001:dd/ce{tones="916135551212"}}} 6500 } 6501 } 6503 11. And the Notify is acknowledged. 6505 MGC to MG1: 6506 MEGACO/1 [123.123.123.4]:55555 6507 Reply = 10002 { 6508 Context = - {Notify = A4444} 6509 } 6511 12. The controller then analyses the digits and determines that a con- 6512 nection needs to be made from MG1 to MG2. Both the TDM termination 6513 A4444, and an RTP termination are added to a new context in MG1. 6514 Mode is ReceiveOnly since Remote descriptor values are not yet 6515 specified. Preferred codecs are in the MGC's preferred order of 6516 choice. 6518 MGC to MG1: 6519 MEGACO/1 [123.123.123.4]:55555 6520 Transaction = 10003 { 6521 Context = $ { 6522 Add = A4444, 6523 Add = $ { 6525 Internet draft MEGACO Protocol January 27, 2000 6527 Media { 6528 Stream = 1 { 6529 LocalControl { 6530 Mode = ReceiveOnly, 6532 nt/jit=40, ; in ms 6533 }, 6534 Local { 6535 v=0 6536 c=IN IP4 $ 6537 m=audio $ RTP/AVP 4 6538 a=ptime:30 6539 v=0 6540 c=IN IP4 $ 6541 m=audio $ RTP/AVP 0 6542 } 6543 } 6544 } 6545 } 6546 } 6547 } 6549 NOTE - The MGC states its preferred parameter values as a series of sdp 6550 blocks in Local. The MG fills in the Local Descriptor in the Reply. 6552 13. MG1 acknowledges the new Termination and fills in the Local IP 6553 address and UDP port. It also makes a choice for the codec based on 6554 the MGC preferences in Local. MG1 sets the RTP port to 2222. 6556 MEGACO/1 [124.124.124.222]:55555 6557 Reply = 10003 { 6558 Context = 2000 { 6559 Add = A4444, 6560 Add=A4445{ 6561 Media { 6562 Stream = 1 { 6563 Local { 6564 v=0 6565 c=IN IP4 124.124.124.222 6566 m=audio 2222 RTP/AVP 4 6567 a=ptime:30 6568 a=recvonly 6569 } ; RTP profile for G.723 is 4 6570 } 6571 } 6573 Internet draft MEGACO Protocol January 27, 2000 6575 } 6576 } 6577 } 6579 14. The MGC will now associate A5555 with a new Context on MG2, and 6580 establish an RTP Stream (i.e, A5556 will be assigned), SendReceive 6581 connection through to the originating user, User 1. The MGC also 6582 sets ring on A5555. 6584 MGC to MG2: 6585 MEGACO/1 [123.123.123.4]:55555 6586 Transaction = 50003 { 6587 Context = $ { 6588 Add = A5555 { Media { 6589 Stream = 1 { 6590 LocalControl {Mode = SendReceive} }}, 6591 Signals {al/ri} 6592 }, 6593 Add = $ {Media { 6594 Stream = 1 { 6595 LocalControl { 6596 Mode = SendReceive, 6597 nt/jit=40 ; in ms 6598 }, 6599 Local { 6600 v=0 6601 c=IN IP4 $ 6602 m=audio $ RTP/AVP 4 6603 a=ptime:30 6604 }, 6605 Remote { 6606 v=0 6607 c=IN IP4 124.124.124.222 6608 m=audio 2222 RTP/AVP 4 6609 a=ptime:30 6610 } ; RTP profile for G.723 is 4 6611 } 6612 } 6613 } 6614 } 6615 } 6617 17. This is acknowledged. The stream port number is different from the 6619 Internet draft MEGACO Protocol January 27, 2000 6621 control port number. In this case it is 1111 (in the SDP). 6623 MG2 to MGC: 6624 MEGACO/1 [124.124.124.222]:55555 6625 Reply = 50003 { 6626 Context = 5000 { 6627 Add = A5556{ 6628 Media { 6629 Stream = 1 { 6630 Local { 6631 v=0 6632 c=IN IP4 125.125.125.111 6633 m=audio 1111 RTP/AVP 4 6634 } 6635 } ; RTP profile for G723 is 4 6636 } 6637 } 6638 } 6639 } 6641 18. The above IPAddr and UDPport need to be given to MG1 now. 6643 MGC to MG1: 6644 MEGACO/1 [123.123.123.4]:55555 6645 Transaction = 10005 { 6646 Context = 2000 { 6647 Modify = A4444 { 6648 Signals {cg/rt} 6649 }, 6650 Modify = A4445 { 6651 Media { 6652 Stream = 1 { 6653 Remote { 6654 v=0 6655 c=IN IP4 125.125.125.111 6656 m=audio 1111 RTP/AVP 4 6657 } 6658 } ; RTP profile for G723 is 4 6659 } 6660 } 6661 } 6662 } 6664 MG1 to MGC: 6665 MEGACO/1 [124.124.124.222]:55555 6666 Reply = 10005 { 6668 Internet draft MEGACO Protocol January 27, 2000 6670 Context = 2000 {Modify = A4444, Modify = A4445} 6671 } 6673 19. The two gateways are now connected and User 1 hears the RingBack. 6674 The MG2 now waits until User2 picks up the receiver and then the 6675 two-way call is established. 6677 From MG2 to MGC: 6679 MEGACO/1 [125.125.125.111]:55555 6680 Transaction = 50005 { 6681 Context = 5000 { 6682 Notify = A5555 {ObservedEvents =1234 { 6683 19990729T22020002:al/of}} 6684 } 6685 } 6687 From MGC to MG2: 6689 MEGACO/1 [123.123.123.4]:55555 6690 Reply = 50005 { 6691 Context = - {Notify = A5555} 6692 } 6694 From MGC to MG2: 6696 MEGACO/1 [123.123.123.4]:55555 6697 Transaction = 50006 { 6698 Context = 5000 { 6699 Modify = A5555 { 6700 Events = 1235 {al/on}, 6701 Signals { } ; to turn off ringing 6702 } 6703 } 6704 } 6706 From MG2 to MGC: 6708 MEGACO/1 [125.125.125.111]:55555 6709 Reply = 50006 { 6710 Context = 5000 {Modify = A4445} 6711 } 6713 20. Change mode on MG1 to SendReceive, and stop the ringback. 6715 Internet draft MEGACO Protocol January 27, 2000 6717 MGC to MG1: 6718 MEGACO/1 [123.123.123.4]:55555 6719 Transaction = 10006 { 6720 Context = 2000 { 6721 Modify = A4445 { 6722 Media { 6723 Stream = 1 { 6724 LocalControl { 6725 Mode=SendReceive 6726 } 6727 } 6728 } 6729 }, 6730 Modify = A4444 { 6731 Signals { } 6732 } 6733 } 6734 } 6736 from MG1 to MGC: 6737 MEGACO/1 [124.124.124.222]:55555 6738 Reply = 10006 { 6739 Context = 2000 {Modify = A4445, Modify = A4444}} 6741 21. The MGC decides to Audit the RTP termination on MG2. 6743 MEGACO/1 [123.123.123.4]:55555 6744 Transaction = 50007 { 6745 Context = - {AuditValue = A5556{ 6746 Audit{Media, DigitMap, Events, Signals, Packages, Statistics }} 6747 } 6748 } 6750 22. The MG2 replies. An RTP termination has no events nor signals, so 6751 these are left out in the reply . 6753 MEGACO/1 [125.125.125.111]:55555 6754 Reply = 50007 { 6755 Context = - { 6756 AuditValue = A5556 { 6757 Media { 6758 Stream = 1 { 6759 LocalControl { Mode = SendReceive, 6760 nt/jit=40 }, 6762 Internet draft MEGACO Protocol January 27, 2000 6764 Local { 6765 v=0 6766 c=IN IP4 125.125.125.111 6767 m=audio 1111 RTP/AVP 4 6768 a=ptime:30 6769 }, 6770 Remote { 6771 v=0 6772 c=IN IP4 124.124.124.222 6773 m=audio 2222 RTP/AVP 4 6774 a=ptime:30 6775 } } }, 6776 Packages {nt-1, rtp-1}, 6777 Statistics { rtp/ps=1200, ; packets sent 6778 nt/os=62300, ; octets sent 6779 rtp/pr=700, ; packets received 6780 nt/or=45100, ; octets received 6781 rtp/pl=0.2, ; % packet loss 6782 rtp/jit=20, 6783 rtp/delay=40 } ; avg latency 6784 } 6785 } 6786 } 6788 23. When the MGC receives an onhook signal from one of the MGs, it 6789 brings down the call. In this example, the user at MG2 hangs up 6790 first. 6792 From MG2 to MGC: 6794 MEGACO/1 [125.125.125.111]:55555 6795 Transaction = 50008 { 6796 Context = 5000 { 6797 Notify = A5555 {ObservedEvents =1235 { 6798 19990729T24020002:al/on} 6799 } 6800 } 6801 } 6803 From MGC to MG2: 6805 MEGACO/1 [123.123.123.4]:55555 6806 Reply = 50008 { 6807 Context = - {Notify = A5555} 6808 } 6810 Internet draft MEGACO Protocol January 27, 2000 6812 24. The MGC now sends both MGs a Subtract to take down the call. Only 6813 the subtracts to MG2 are shown here. Each termination has its own 6814 set of statistics that it gathers. An MGC may not need to request 6815 both to be returned. A5555 is a physical termination, and A5556 is 6816 an RTP termination. 6818 From MGC to MG2: 6820 MEGACO/1 [123.123.123.4]:55555 6821 Transaction = 50009 { 6822 Context = 5000 { 6823 Subtract = A5555 {Audit{Statistics}}, 6824 Subtract = A5556 {Audit{Statistics}} 6825 } 6826 } 6828 From MG2 to MGC: 6830 MEGACO/1 [125.125.125.111]:55555 6831 Reply = 50009 { 6832 Context = 5000 { 6833 Subtract = A5555 { 6834 Statistics { 6835 nt/os=45123, ; Octets Sent 6836 nt/dur=40 ; in seconds 6837 } 6838 }, 6839 Subtract = A5556 { 6840 Statistics { 6841 rtp/ps=1245, ; packets sent 6842 nt/os=62345, ; octets sent 6843 rtp/pr=780, ; packets received 6844 nt/or=45123, ; octets received 6845 rtp/pl=10, ; % packets lost 6846 rtp/jit=27, 6847 rtp/delay=48 ; average latency 6848 } 6849 } 6850 } 6851 } 6853 25. The MGC now sets up both MG1 and MG2 to be ready to detect the next 6854 off-hook event. See step 1. Note that this could be the default 6855 state of a termination in the null context, and if this were the 6856 case, no message need be sent from the MGC to the MG. Once a termi- 6857 nation returns to the null context, it goes back to the default 6859 Internet draft MEGACO Protocol January 27, 2000 6861 termination values for that termination.