idnits 2.17.1 draft-ietf-megaco-protocol-08.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 36 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 672: '...d. A Termination SHALL exist in only o...' RFC 2119 keyword, line 1173: '...property is True, the MG SHALL reserve...' RFC 2119 keyword, line 1176: '... SHALL respond with the alternatives...' RFC 2119 keyword, line 1177: '... of the alternatives, it SHALL respond...' RFC 2119 keyword, line 1181: '...erty is False, the MG SHALL choose one...' (113 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 926 has weird spacing: '...signals are n...' == Line 1126 has weird spacing: '...roperty speci...' == Line 1277 has weird spacing: '...sts for the M...' == Line 1311 has weird spacing: '...rnative withi...' == Line 1400 has weird spacing: '...ockStep and t...' == (17 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? '1' on line 20 looks like a reference -- Missing reference section? 'ErrorDescriptor' on line 2334 looks like a reference -- Missing reference section? 'ServiceChangeDescriptor' on line 2371 looks like a reference -- Missing reference section? 'RFC2402' on line 3116 looks like a reference -- Missing reference section? 'RFC2406' on line 3072 looks like a reference -- Missing reference section? 'RFC2409' on line 3078 looks like a reference -- Missing reference section? 'RFC 2234' on line 4474 looks like a reference -- Missing reference section? '3' on line 5836 looks like a reference -- Missing reference section? '5' on line 5837 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Media Gateway Control (Megaco) Working Group Fernando Cuervo 2 Internet Draft Nortel Networks 3 Document: draft-ietf-megaco-protocol-08.txt Nancy Greene 4 Category: Standards Track Nortel Networks 5 Christian Huitema 6 April 2000 Telcordia Technologies 7 Abdallah Rayhan 8 Nortel Networks 9 Brian Rosen 10 Marconi 11 John Segers 12 Lucent Technologies 14 Megaco Protocol 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [1]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- Drafts 27 as reference material or to cite them other than as "work in 28 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document is common text with draft Recommendation H.248 as 37 redetermined in Geneva, February 2000. It must be read in 38 conjunction with the Megaco Errata, draft-ietf-megaco-errata-00.txt. 39 A merged draft presenting the Megaco protocol with the Errata 40 incorporated is or will be available shortly as draft-ietf-megaco- 41 merged-00.txt. 43 The protocol presented in this document meets the requirements for a 44 media gateway control protocol as presented in RFC 2805. 46 Rosen et al Standards Track -- Expires Oct 2000 1 47 TABLE OF CONTENTS 49 1. SCOPE..........................................................7 51 2. REFERENCES.....................................................7 52 2.1 Normative references..........................................7 53 2.2 Informative references........................................9 55 3. DEFINITIONS...................................................10 57 4. ABBREVIATIONS.................................................11 59 5. CONVENTIONS...................................................11 61 6. CONNECTION MODEL..............................................11 62 6.1 Contexts.....................................................14 63 6.1.1 Context Attributes and Descriptors....................15 64 6.1.2 Creating, Deleting and Modifying Contexts.............15 65 6.2 Terminations.................................................15 66 6.2.1 Termination Dynamics..................................16 67 6.2.2 TerminationIDs........................................16 68 6.2.3 Packages..............................................17 69 6.2.4 Termination Properties and Descriptors................17 70 6.2.5 Root Termination......................................19 72 7. COMMANDS......................................................19 73 7.1 Descriptors..................................................21 74 7.1.1 Specifying Parameters.................................21 75 7.1.2 Modem Descriptor......................................21 76 7.1.3 Multiplex Descriptor..................................22 77 7.1.4 Media Descriptor......................................22 78 7.1.5 Termination State Descriptor..........................22 79 7.1.6 Stream Descriptor.....................................23 80 7.1.7 LocalControl Descriptor...............................23 81 7.1.8 Local and Remote Descriptors..........................24 82 7.1.9 Events Descriptor.....................................27 83 7.1.10 EventBuffer Descriptor...............................30 84 7.1.11 Signals Descriptor...................................30 85 7.1.12 Audit Descriptor.....................................31 86 7.1.13 ServiceChange Descriptor.............................32 87 7.1.14 DigitMap Descriptor..................................32 88 7.1.15 Statistics Descriptor................................36 89 7.1.16 Packages Descriptor..................................37 90 7.1.17 ObservedEvents Descriptor............................37 91 7.1.18 Topology Descriptor.................................37 92 7.2 Command Application Programming Interface....................40 93 7.2.1 Add...................................................40 94 7.2.2 Modify................................................41 95 7.2.3 Subtract..............................................42 96 7.2.4 Move..................................................43 97 7.2.5 AuditValue............................................44 99 Rosen et al Standards Track -- Expires Oct 2000 2 100 7.2.6 AuditCapabilities.....................................45 101 7.2.7 Notify................................................46 102 7.2.8 ServiceChange.........................................46 103 7.2.9 Manipulating and Auditing Context Attributes..........50 104 7.2.10 Generic Command Syntax...............................51 105 7.3 Command Error Codes..........................................51 107 8. TRANSACTIONS..................................................53 108 8.1 Common Parameters............................................54 109 8.1.1 Transaction Identifiers...............................54 110 8.1.2 Context Identifiers...................................54 111 8.2 Transaction Application Programming Interface................55 112 8.2.1 TransactionRequest....................................55 113 8.2.2 TransactionReply......................................55 114 8.2.3 TransactionPending....................................56 115 8.3 Messages.....................................................57 117 9. TRANSPORT.....................................................57 118 9.1 Ordering of Commands.........................................58 119 9.2 Protection against Restart Avalanche.........................59 121 10. SECURITY CONSIDERATIONS......................................60 122 10.1 Protection of Protocol Connections..........................60 123 10.2 Interim AH scheme...........................................60 124 10.3 Protection of Media Connections.............................61 126 11. MG-MGC CONTROL INTERFACE....................................62 127 11.1 Multiple Virtual MGs........................................62 128 11.2 Cold Start..................................................63 129 11.3 Negotiation of Protocol Version.............................64 130 11.4 Failure of an MG............................................64 131 11.5 Failure of an MGC...........................................65 133 12. PACKAGE DEFINITION...........................................66 134 12.1 Guidelines for defining packages............................66 135 12.1.1 Package..............................................67 136 12.1.2 Properties...........................................67 137 12.1.3 Events...............................................68 138 12.1.4 Signals..............................................68 139 12.1.5 Statistics...........................................68 140 12.1.6 Procedures...........................................68 141 12.2 Guidelines to defining Properties, Statistics and Parameters to 142 Events and Signals...............................................69 143 12.3 Lists.......................................................69 144 12.4 Identifiers.................................................69 145 12.5 Package Registration........................................69 147 13. IANA CONSIDERATIONS.........................................69 148 13.1 Packages....................................................69 149 13.2 Error Codes.................................................70 150 13.3 ServiceChange Reasons.......................................71 152 Rosen et al Standards Track -- Expires Oct 2000 3 153 ANNEX A: BINARY ENCODING OF THE PROTOCOL (NORMATIVE).............72 154 A.1 Coding of wildcards..........................................72 155 A.2 ASN.1 syntax specification...................................73 156 A.3 Digit maps and path names....................................88 158 ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE)................90 159 B.1 Coding of wildcards..........................................90 160 B.2 ABNF specification...........................................90 162 ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE)............102 163 C.1 General Media Attributes....................................102 164 C.2 Mux Properties..............................................103 165 C.3 General bearer properties...................................104 166 C.4 General ATM properties......................................104 167 C.5 Frame Relay.................................................107 168 C.6 IP..........................................................107 169 C.7 ATM AAL2....................................................... 170 C.8 ATM AAL1....................................................109 171 C.9 Bearer Capabilities.........................................110 172 C.10 AAL5 Properties............................................118 173 C.11 SDP Equivalents............................................119 174 C.12 H.245......................................................120 176 ANNEX D TRANSPORT OVER IP (NORMATIVE)...........................121 177 D.1 Transport over IP/UDP using Application Level Framing.......121 178 D.1.1 Providing At-Most-Once Functionality.................121 179 D.1.2 Transaction identifiers and three-way handshake......122 180 D.1.2.1 Transaction identifiers....................122 181 D.1.2.2 Three-way handshake........................122 182 D.1.3 Computing retransmission timers......................122 183 D.1.4 Provisional responses................................123 184 D.1.5 Repeating Requests, Responses and Acknowledgements...124 185 D.2 using TCP..................................................125 186 D.2.1 Providing the At-Most-Once functionality..........125 187 D.2.2 Transaction identifiers and three way handshake...126 188 D.2.3 Computing retransmission timers...................126 189 D.2.5 Ordering of commands..............................126 191 ANNEX E BASIC PACKAGES..........................................127 192 E.1 Generic.....................................................127 193 E.1.1 Properties...........................................127 194 E.1.2 Events...............................................127 195 E.1.3 Signals..............................................128 196 E.1.4 Statistics...........................................128 197 E.2 Base Root Package...........................................129 198 E.2.1 Properties...........................................129 199 E.2.2 Events...............................................130 200 E.2.3 Signals..............................................130 201 E.2.4 Statistics...........................................130 202 E.2.5 Procedures...........................................130 203 E.3 Tone Generator Package......................................130 204 E.3.1 Properties...........................................131 206 Rosen et al Standards Track -- Expires Oct 2000 4 207 E.3.2 Events...............................................131 208 E.3.3 Signals..............................................131 209 E.3.4 Statistics...........................................131 210 E.3.5 Procedures...........................................132 211 E.4 Tone Detection Package......................................132 212 E.4.1 Properties...........................................132 213 E.4.2 Events...............................................132 214 E.4.3 Signals..............................................134 215 E.4.4 Statistics...........................................134 216 E.4.5 Procedures...........................................134 217 E.5 Basic DTMF Generator Package................................134 218 E.5.1 Properties...........................................135 219 E.5.2 Events...............................................135 220 E.5.3 Signals..............................................135 221 E.5.4 Statistics...........................................136 222 E.5.5 Procedures...........................................136 223 E.6 DTMF detection Package......................................136 224 E.6.1 Properties...........................................137 225 E.6.2 Events...............................................137 226 E.6.3 Signals..............................................138 227 E.6.4 Statistics...........................................138 228 E.6.5 Procedures...........................................138 229 E.7 Call Progress Tones Generator Package.......................138 230 E.7.1 Properties...........................................138 231 E.7.2 Events...............................................139 232 E.7.3 Signals..............................................139 233 E.7.4 Statistics...........................................139 234 E.7.5 Procedures...........................................139 235 E.8 Call Progress Tones Detection Package.......................140 236 E.8.1 Properties...........................................140 237 E.8.2 Events...............................................140 238 E.8.3 Signals..............................................140 239 E.8.4 Statistics...........................................140 240 E.8.5 Procedures...........................................140 241 E.9 Analog Line Supervision Package.............................140 242 E.9.1 Properties...........................................141 243 E.9.2 Events...............................................141 244 E.9.3 Signals..............................................142 245 E.9.4 Statistics...........................................142 246 E.9.5 Procedures...........................................143 247 E.10 Basic Continuity Package...................................143 248 E.10.1 Properties..........................................143 249 E.10.2 Events..............................................143 250 E.10.3 Signals.............................................143 251 E.10.4 Statistics..........................................144 252 E.10.5 Procedures..........................................144 253 E.11 Network Package............................................145 254 E.11.1 Properties..........................................145 255 E.11.2 Events..............................................145 256 E.11.3 Signals.............................................146 257 E.11.4 Statistics..........................................146 258 E.11.5 Procedures..........................................147 260 Rosen et al Standards Track -- Expires Oct 2000 5 261 E.12 RTP Package...............................................147 262 E.12.1 Properties..........................................147 263 E.12.2 Events..............................................147 264 E.12.3 Signals.............................................148 265 E.12.4 Statistics..........................................148 266 E.12.5 Procedures..........................................149 267 E.13 TDM Circuit Package........................................149 268 E.13.1 Properties..........................................149 269 E.13.2 Events..............................................150 270 E.13.3 Signals.............................................150 271 E.13.4 Statistics..........................................150 272 E.13.5 Procedures..........................................150 274 APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE).....................151 276 A.1 Residential Gateway to Residential Gateway Call.............151 277 A.1.1 Programming Residential GW Analog Line Terminations for 278 Idle Behavior..............................................151 279 A.1.2 Collecting Originator Digits and Initiating Termination 280 ...........................................................153 282 Rosen et al Standards Track -- Expires Oct 2000 6 283 1. SCOPE 285 This document defines the protocol used between elements of a 286 physically decomposed multimedia gateway. There are no functional 287 differences from a system view between a decomposed gateway, with 288 distributed sub-components potentially on more than one physical 289 device, and a monolithic gateway such as described in H.246. This 290 recommendation does not define how gateways, multipoint control 291 units or integrated voice response units (IVRs) work. Instead it 292 creates a general framework that is suitable for these applications. 293 Packet network interfaces may include IP, ATM or possibly others. 294 The interfaces will support a variety of SCN signalling systems, 295 including tone signalling, ISDN, ISUP, QSIG, and GSM. National 296 variants of these signalling systems will be supported where 297 applicable. 299 The protocol definition in this document is common text with ITU-T 300 Recommendation H.248. It meets the requirements documented in RFC 301 2805. 303 2. REFERENCES 305 2.1 Normative references 307 ITU-T Recommendation H.225.0 (1998): "Call Signalling Protocols and 308 Media Stream Packetization for Packet Based Multimedia 309 Communications Systems". 311 ITU-T Recommendation H.235 (02/98): "Security and encryption for H- 312 Series (H.323 and other H.245-based) multimedia terminals". 314 ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia 315 Communication". 317 ITU-T Recommendation H.323 (1998): "Packet Based Multimedia 318 Communication Systems". 320 ITU-T Recommendation I.363.1 (08/96), "B-ISDN ATM Adaptation Layer 321 specification: Type 1 AAL". 323 ITU-T Recommendation I.363.2 (09/97), "B-ISDN ATM Adaptation Layer 324 specification: Type 2 AAL". 326 ITU-T Recommendation I.363.5 (08/96), "B-ISDN ATM Adaptation Layer 327 specification: Type 5 AAL". 329 ITU-T Recommendation I.366.1 (06/98), "Segmentation and Reassembly 330 Service Specific Convergence Sublayer for the AAL type 2". 332 ITU-T Recommendation I.366.2 (02/99), "AAL type 2 service specific 333 convergence sublayer for trunking". 335 Rosen et al Standards Track -- Expires Oct 2000 7 336 ITU-T Recommendation I.371 (08/96), "Traffic control and congestion 337 control in B-ISDN". 339 ITU-T Recommendation Q.763 (09/97), "Signalling System No. 7 - ISDN 340 user part formats and codes". 342 ITU-T Recommendation Q.765, "Signalling System No. 7 - Application 343 transport mechanism". 345 ITU-T Recommendation Q.931 (05/98): "Digital Subscriber Signalling 346 System No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 347 Specification for Basic Call Control". 349 ITU-T Recommendation Q.2630.1 (1999), "AAL Type 2 Signalling 350 Protocol (Capability Set 1)". 352 ITU-T Recommendation Q.2931 (10/95), "Broadband Integrated Services 353 Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 354 2 (DSS 2) - User-Network Interface (UNI) - Layer 3 specification for 355 basic call/connection control". 357 ITU-T Recommendation Q.2941.1 (09/97), "Digital Subscriber 358 Signalling System No. 2 - Generic Identifier Transport". 360 ITU-T Recommendation Q.2961 (10/95), "Broadband integrated services 361 digital network (B-ISDN) - Digital subscriber signalling system no.2 362 (DSS 2) - additional traffic parameters". 364 ITU-T Recommendation Q.2961.2 (06/97), "Digital subscriber 365 signalling system No. 2 - Additional traffic parameters: Support of 366 ATM transfer capability in the broadband bearer capability 367 information element." 369 ITU-T Recommendation X.213 (11/1995), "Information technology - Open 370 System Interconnection - Network service definition plus Amendment 1 371 (08/1997), Addition of the Internet protocol address format 372 identifier". 374 ITU-T Recommendation V.76 (08/96), "Generic multiplexer using V.42 375 LAPM-based procedures". 377 ITU-T Recommendation X.680 (1997): "Information technology-Abstract 378 Syntax Notation One (ASN.1): Specification of basic notation". 380 ITU-T Recommendation H.246 (1998), "Interworking of H-series 381 multimedia terminals with H-series multimedia terminals and 382 voice/voiceband terminals on GSTN and ISDN". 384 RFC 1006, "ISO Transport Service on top of the TCP, Version 3", 385 Marshall T. Rose, Dwight E. Cass, May 1987. 387 Rosen et al Standards Track -- Expires Oct 2000 8 388 RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", D. 389 Crocker, P. Overell, November 1997. 391 RFC 2327, "SDP: Session Description Protocol", M. Handley, V. 392 Jacobson, April 1998. 394 RFC 2402, "IP Authentication Header", S. Kent, R. Atkinson, November 395 1998. 397 RFC 2406, "IP Encapsulating Security Payload (ESP)", S. Kent, R. 398 Atkinson, November 1998. 400 2.2 Informative references 402 ITU-T Recommendation E.180/Q.35 (1998): "Technical characteristics 403 of tones for the telephone service". 405 CCITT Recommendation G.711 (1988), "Pulse Code Modulation (PCM) of 406 voice frequencies". 408 ITU-T Recommendation H.221 (05/99),"Frame structure for a 64 to 1920 409 kbit/s channel in audiovisual teleservices". 411 ITU-T Recommendation H.223 (1996), "Multiplexing protocol for low 412 bit rate multimedia communication". 414 ITU-T Recommendation Q.724 (1988): "Signalling procedures". 416 RFC 768, "User Datagram Protocol", J.Postel, August 1980. 418 RFC 791, "Internet protocol", J.Postel, September 1981. 420 RFC 793, "TRANSMISSION CONTROL PROTOCOL", J.Postel, September 1981. 422 RFC 1661, "The Point-to-Point Protocol", W. Simpson, July 1994. 424 RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", H. 425 Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996. 427 RFC 1890, "RTP Profile for Audio and Video Conferences with Minimal 428 Control", H. Schulzrinne, January 1996. 430 RFC 2401, "Security Architecture for the Internet Protocol", S. 431 Kent, R. Atkinson, November 1998. 433 RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", S. 434 Deering, R. Hinden, December 1998. 436 RFC 2543, "SIP: Session Initiation Protocol", M. Handley, H. 437 Schulzrinne, E. Schooler, J. Rosenberg, March 1999. 439 Rosen et al Standards Track -- Expires Oct 2000 9 440 RFC 2805, "Media Gateway control protocol architecture and 441 requirements", N. Greene, M. Ramalho, B. Rosen, April 1999. 443 3. DEFINITIONS 445 Access Gateway: A type of gateway that provides a User to Network 446 Interface (UNI) such as ISDN. 448 Descriptor: A syntactic element of the protocol that groups related 449 properties. For instance, the properties of a media flow on the MG 450 can be set by the MGC by including the appropriate descriptor in a 451 command. 453 Media Gateway (MG): The media gateway converts media provided in one 454 type of network to the format required in another type of network. 455 For example, a MG could terminate bearer channels from a switched 456 circuit network (e.g., DS0s) and media streams from a packet network 457 (e.g., RTP streams in an IP network). This gateway may be capable 458 of processing audio, video and T.120 alone or in any combination, 459 and will be capable of full duplex media translations. The MG may 460 also play audio/video messages and performs other IVR functions, or 461 may perform media conferencing. 463 Media Gateway Controller (MGC): Controls the parts of the call state 464 that pertain to connection control for media channels in a MG. 466 Multipoint Control Unit (MCU): An entity that controls the setup and 467 coordination of a multi-user conference that typically includes 468 processing of audio, video and data. 470 Residential Gateway: A gateway that interworks an analogue line to a 471 packet network. A residential gateway typically contains one or two 472 analogue lines and is located at the customer premises. 474 SCN FAS Signalling Gateway: This function contains the SCN 475 Signalling Interface that terminates SS7, ISDN or other signalling 476 links where the call control channel and bearer channels are 477 collocated in the same physical span. 479 SCN NFAS Signalling Gateway: This function contains the SCN 480 Signalling Interface that terminates SS7 or other signalling links 481 where the call control channels are separated from bearer channels. 483 Stream: Bidirectional media or control flow received/sent by a media 484 gateway as part of a call or conference. 486 Trunk: A communication channel between two switching systems such as 487 a DS0 on a T1 or E1 line. 489 Trunking Gateway: A gateway between SCN network and packet network 490 that typically terminates a large number of digital circuits. 492 Rosen et al Standards Track -- Expires Oct 2000 10 493 4. ABBREVIATIONS 495 This recommendation defines the following terms. 497 ATM Asynchronous Transfer Mode 498 BRI Basic Rate Interface 499 CAS Channel Associated Signalling 500 DTMF Dual Tone Multi-Frequency 501 FAS Facility Associated Signalling 502 GW GateWay 503 IANA Internet Assigned Numbers Authority 504 IP Internet Protocol 505 ISUP ISDN User Part 506 MG Media Gateway 507 MGC Media Gateway Controller 508 NFAS Non-Facility Associated Signalling 509 PRI Primary Rate Interface 510 PSTN Public Switched Telephone Network 511 QoS Quality of Service 512 RTP Real-time Transport Protocol 513 SCN Switched Circuit Network 514 SG Signalling Gateway 515 SS7 Signalling System No. 7 517 5. CONVENTIONS 519 In this recommendation, "shall" refers to a mandatory requirement, 520 while "should" refers to a suggested but optional feature or 521 procedure. The term "may" refers to an optional course of action 522 without expressing a preference. 524 6. CONNECTION MODEL 526 The connection model for the protocol describes the logical 527 entities, or objects, within the Media Gateway that can be 528 controlled by the Media Gateway Controller. The main abstractions 529 used in the connection model are Terminations and Contexts. 531 A Termination sources and/or sinks one or more streams. In a 532 multimedia conference, a Termination can be multimedia and sources 533 or sinks multiple media streams. The media stream parameters, as 534 well as modem, and bearer parameters are encapsulated within the 535 Termination. 537 A Context is an association between a collection of Terminations. 538 There is a special type of Context, the null Context, which contains 539 all Terminations that are not associated to any other Termination. 541 Rosen et al Standards Track -- Expires Oct 2000 11 542 For instance, in a decomposed access gateway, all idle lines are 543 represented by Terminations in the null Context. 545 +------------------------------------------------------+ 546 |Media Gateway | 547 | +-------------------------------------------------+ | 548 | |Context +-------------+ | | 549 | | | Termination | | | 550 | | |-------------| | | 551 | | +-------------+ +->| SCN Bearer |<---+-> 552 | | | Termination | +-----+ | | Channel | | | 553 | | |-------------| | |---+ +-------------+ | | 554 <-+--->| RTP Stream |---| * | | | 555 | | | | | |---+ +-------------+ | | 556 | | +-------------+ +-----+ | | Termination | | | 557 | | | |-------------| | | 558 | | +->| SCN Bearer |<---+-> 559 | | | Channel | | | 560 | | +-------------+ | | 561 | +-------------------------------------------------+ | 562 | | 563 | | 564 | +------------------------------+ | 565 | |Context | | 566 | +-------------+ | +-------------+ | | 567 | | Termination | | +-----+ | Termination | | | 568 | |-------------| | | | |-------------| | | 569 <-+->| SCN Bearer | | | * |------| SCN Bearer |<---+-> 570 | | Channel | | | | | Channel | | | 571 | +-------------+ | +-----+ +-------------+ | | 572 | +------------------------------+ | 573 | | 574 | | 575 | +-------------------------------------------------+ | 576 | |Context | | 577 | | +-------------+ +-------------+ | | 578 | | | Termination | +-----+ | Termination | | | 579 | | |-------------| | | |-------------| | | 580 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> 581 | | | Channel | | | | Channel | | | 582 | | +-------------+ +-----+ +-------------+ | | 583 | +-------------------------------------------------+ | 584 | ___________________________________________________ | 585 +------------------------------------------------------+ 587 Figure 1: Example of H.248 Connection Model 589 Figure 1 is a graphical depiction of these concepts. The diagram of 590 Figure 1 gives several examples and is not meant to be an all- 591 inclusive illustration. The asterisk box in each of the Contexts 592 represents the logical association of Terminations implied by the 593 Context. 595 Rosen et al Standards Track -- Expires Oct 2000 12 596 The example below shows an example of one way to accomplish a call- 597 waiting scenario in a decomposed access gateway, illustrating the 598 relocation of a Termination between Contexts. Terminations T1 and 599 T2 belong to Context C1 in a two-way audio call. A second audio 600 call is waiting for T1 from Termination T3. T3 is alone in Context 601 C2. T1 accepts the call from T3, placing T2 on hold. This action 602 results in T1 moving into Context C2, as shown below. 604 +------------------------------------------------------+ 605 |Media Gateway | 606 | +-------------------------------------------------+ | 607 | |Context C1 | | 608 | | +-------------+ +-------------+ | | 609 | | | Term. T2 | +-----+ | Term. T1 | | | 610 | | |-------------| | | |-------------| | | 611 <-+--->| RTP Stream |---| * |------| SCN Bearer |<---+-> 612 | | | | | | | Channel | | | 613 | | +-------------+ +-----+ +-------------+ | | 614 | +-------------------------------------------------+ | 615 | | 616 | +-------------------------------------------------+ | 617 | |Context C2 | | 618 | | +-------------+ | | 619 | | +-----+ | Term. T3 | | | 620 | | | | |-------------| | | 621 | | | * |------| SCN Bearer |<---+-> 622 | | | | | Channel | | | 623 | | +-----+ +-------------+ | | 624 | +-------------------------------------------------+ | 625 +------------------------------------------------------+ 627 Figure 2: Example Call Waiting Scenario / Alerting Applied to T1 629 Rosen et al Standards Track -- Expires Oct 2000 13 630 +------------------------------------------------------+ 631 |Media Gateway | 632 | +-------------------------------------------------+ | 633 | |Context C1 | | 634 | | +-------------+ | | 635 | | | Term. T2 | +-----+ | | 636 | | |-------------| | | | | 637 <-+--->| RTP Stream |---| * | | | 638 | | | | | | | | 639 | | +-------------+ +-----+ | | 640 | +-------------------------------------------------+ | 641 | | 642 | +-------------------------------------------------+ | 643 | |Context C2 | | 644 | | +-------------+ +-------------+ | | 645 | | | Term. T1 | +-----+ | Term. T3 | | | 646 | | |-------------| | | |-------------| | | 647 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> 648 | | | Channel | | | | Channel | | | 649 | | +-------------+ +-----+ +-------------+ | | 650 | +-------------------------------------------------+ | 651 +------------------------------------------------------+ 653 Figure 3. Example Call Waiting Scenario / Answer by T1 655 6.1 Contexts 657 A Context is an association between a number of Terminations. The 658 Context describes the topology (who hears/sees whom) and the media 659 mixing and/or switching parameters if more than two Terminations are 660 involved in the association. 662 There is a special Context called the null Context. It contains 663 Terminations that are not associated to any other Termination. 664 Terminations in the null Context can have their parameters examined 665 or modified, and may have events detected on them. 667 In general, an Add command is used to add Terminations to Contexts. 668 If the MGC does not specify an existing Context to which the 669 Termination is to be added, the MG creates a new Context. A 670 Termination may be removed from a Context with a Subtract command, 671 and a Termination may be moved from one Context to another with a 672 Move command. A Termination SHALL exist in only one Context at a 673 time. 675 The maximum number of Terminations in a Context is a MG property. 676 Media gateways that offer only point-to-point connectivity might 677 allow at most two Terminations per Context. Media gateways that 678 support multipoint conferences might allow three or more 679 terminations per Context. 681 Rosen et al Standards Track -- Expires Oct 2000 14 682 6.1.1 Context Attributes and Descriptors 684 The attributes of Contexts are: 686 . ContextID. 688 . The topology (who hears/sees whom). 689 The topology of a Context describes the flow of media between the 690 Terminations within a Context. In contrast, the mode of a 691 Termination (send/receive/_) describes the flow of the media at 692 the ingress/egress of the media gateway. 694 . The priority is used for a context in order to provide the MG with 695 information about a certain precedence handling for a context. The 696 MGC can also use the priority to control autonomously the traffic 697 precedence in the MG in a smooth way in certain situations (e.g. 698 restart), when a lot of contexts must be handled simultaneously. 700 . An indicator for an emergency call is also provided to allow a 701 preference handling in the MG. 703 6.1.2 Creating, Deleting and Modifying Contexts 705 The protocol can be used to (implicitly) create Contexts and modify 706 the parameter values of existing Contexts. The protocol has 707 commands to add Terminations to Contexts, subtract them from 708 Contexts, and to move Terminations between Contexts. Contexts are 709 deleted implicitly when the last remaining Termination is subtracted 710 or moved out. 712 6.2 Terminations 714 A Termination is a logical entity on a MG that sources and/or sinks 715 media and/or control streams. A Termination is described by a 716 number of characterizing Properties, which are grouped in a set of 717 Descriptors that are included in commands. Terminations have unique 718 identities (TerminationIDs), assigned by the MG at the time of their 719 creation. 721 Terminations representing physical entities have a semi-permanent 722 existence. For example, a Termination representing a TDM channel 723 might exist for as long as it is provisioned in the gateway. 724 Terminations representing ephemeral information flows, such as RTP 725 flows, would usually exist only for the duration of their use. 727 Ephemeral Terminations are created by means of an Add command. They 728 are destroyed by means of a Subtract command. In contrast, when a 729 physical Termination is Added to or Subtracted from a Context, it is 730 taken from or to the null Context, respectively. 732 Terminations may have signals applied to them. Signals are MG 733 generated media streams such as tones and announcements as well as 735 Rosen et al Standards Track -- Expires Oct 2000 15 736 line signals such as hookswitch. Terminations may be programmed to 737 detect Events, the occurrence of which can trigger notification 738 messages to the MGC, or action by the MG. Statistics may be 739 accumulated on a Termination. Statistics are reported to the MGC 740 upon request (by means of the AuditValue command, see section 7.2.5) 741 and when the Termination is taken out of the call it is in. 743 Multimedia gateways may process multiplexed media streams. For 744 example, Recommendation H.221 describes a frame structure for 745 multiple media streams multiplexed on a number of digital 64 kbit/s 746 channels. Such a case is handled in the connection model in the 747 following way. For every bearer channel that carries part of the 748 multiplexed streams, there is a Termination. The Terminations that 749 source/sink the digital channels are connected to a separate 750 Termination called the multiplexing Termination. This Termination 751 describes the multiplex used (e.g. how the H.221 frames are carried 752 over the digital channels used). The MuxDescriptor is used to this 753 end. If multiple media are carried, this Termination contains 754 multiple StreamDescriptors. The media streams can be associated with 755 streams sourced/sunk by other Terminations in the Context. 757 Terminations may be created which represent multiplexed bearers, 758 such as an ATM AAL2. When a new multiplexed bearer is to be 759 created, an ephemeral termination is created in a context 760 established for this purpose. When the termination is subtracted, 761 the multiplexed bearer is destroyed. 763 6.2.1 Termination Dynamics 765 The protocol can be used to create new Terminations and to modify 766 property values of existing Terminations. These modifications 767 include the possibility of adding or removing events and/or signals. 768 The Termination properties, and events and signals are described in 769 the ensuing sections. An MGC can only release/modify terminations 770 and the resources that the termination represents which it has 771 previously seized via, e.g., the Add command. 773 6.2.2 TerminationIDs 775 Terminations are referenced by a TerminationID, which is an 776 arbitrary schema chosen by the MG. 778 TerminationIDs of physical Terminations are provisioned in the Media 779 Gateway. The TerminationIDs may be chosen to have structure. For 780 instance, a TerminationID may consist of trunk group and a trunk 781 within the group. 783 A wildcarding mechanism using two types of wildcards can be used 784 with TerminationIDs. The two wildcards are ALL and CHOOSE. The 785 former is used to address multiple Terminations at once, while the 786 latter is used to indicate to a media gateway that it must select a 787 Termination satisfying the partially specified TerminationID. This 789 Rosen et al Standards Track -- Expires Oct 2000 16 790 allows, for instance, that a MGC instructs a MG to choose a circuit 791 within a trunk group. 793 When ALL is used in the TerminationID of a command, the effect is 794 identical to repeating the command with each of the matching 795 TerminationIDs. Since each of these commands may generate a 796 response, the size of the entire response may be large. If 797 individual responses are not required, a wildcard response may be 798 requested. In such a case, a single response is generated, which 799 contains the UNION of all of the individual responses which 800 otherwise would have been generated, with duplicate values 801 suppressed. Wildcard response may be particularly useful in the 802 Audit commands. 804 The encoding of the wildcarding mechanism is detailed in Annexes A 805 and B. 807 6.2.3 Packages 809 Different types of gateways may implement Terminations that have 810 widely differing characteristics. Variations in Terminations are 811 accommodated in the protocol by allowing Terminations to have 812 optional Properties, Events, Signals and Statistics implemented by 813 MGs. 815 In order to achieve MG/MGC interoperability, such options are 816 grouped into Packages, and a Termination realizes a set of such 817 Packages. More information on definition of packages can be found 818 in section 12. An MGC can audit a Termination to determine which 819 Packages it realizes. 821 Properties, Events, Signals and Statistics defined in Packages, as 822 well as parameters to them, are referenced by identifiers (Ids). 823 Identifiers are scoped. For each package, PropertyIds, EventIds, 824 SignalIds, StatisticsIds and ParameterIds have unique name spaces 825 and the same identifier may be used in each of them. Two 826 PropertyIds in different packages may also have the same identifier, 827 etc. 829 6.2.4 Termination Properties and Descriptors 831 Terminations have properties. The properties have unique 832 PropertyIDs. Most properties have default values. When a 833 Termination is created, properties get their default values, unless 834 the controller specifically sets a different value. The default 835 value of a property of a physical Termination can be changed by 836 setting it to a different value when the Termination is in the null 837 Context. Every time such a Termination returns to the null Context, 838 the values of its properties are reset to this default value. 840 There are a number of common properties for Terminations and 841 properties specific to media streams. The common properties are also 843 Rosen et al Standards Track -- Expires Oct 2000 17 844 called the termination state properties. For each media stream, 845 there are local properties and properties of the received and 846 transmitted flows. 848 Properties not included in the base protocol are defined in 849 Packages. These properties are referred to by a name consisting of 850 the PackageName and a PropertyId. Most properties have default 851 values described in the Package description. Properties may be read- 852 only or read/write. The possible values of a property may be 853 audited, as can their current values. For properties that are 854 read/write, the MGC can set their values. A property may be 855 declared as "Global" which has a single value shared by all 856 terminations realizing the package. Related properties are grouped 857 into descriptors for convenience. 859 When a Termination is Added to a Context, the value of its 860 read/write properties can be set by including the appropriate 861 descriptors as parameters to the Add command. Properties not 862 mentioned in the command retain their prior values. Similarly, a 863 property of a Termination in a Context may have its value changed by 864 the Modify command. Properties not mentioned in the Modify command 865 retain their prior values. Properties may also have their values 866 changed when a Termination is moved from one Context to another as a 867 result of a Move command. In some cases, descriptors are returned 868 as output from a command. 870 The following table lists all of the possible Descriptors and their 871 use. Not all descriptors are legal as input or output parameters to 872 every command. 874 Descriptor Name Description 876 Modem Identifies modem type and properties when 877 applicable. 878 Mux Describes multiplex type for multimedia 879 terminations (e.g. H.221, H.223, H.225.0) 880 and Terminations forming the input mux. 881 Media A list of media stream specifications (see 882 7.1.4). 883 TerminationState Properties of a Termination (which can be 884 defined in Packages) that are not stream 885 specific. 886 Stream A list of remote/local/localControl 887 descriptors for a single stream. 888 Local Contains properties that specify the media 889 flows that the MG receives from the remote 890 entity. 891 Remote Contains properties that specify the media 892 flows that the MG sends to the remote 893 entity. 895 Rosen et al Standards Track -- Expires Oct 2000 18 896 Descriptor Name Description 898 LocalControl Contains properties (which can be defined 899 in packages) that are of interest between 900 the MG and the MGC. 901 Events Describes events to be detected by the MG 902 and what to do when an event is detected. 903 EventBuffer Describes events to be detected by the MG 904 when Event Buffering is active. 905 Signals Describes signals and/or actions to be 906 applied (e.g. Busy Tone) to the 907 Terminations. 908 Audit In Audit commands, identifies which 909 information is desired. 910 Packages In AuditValue, returns a list of Packages 911 realized by Termination. 912 DigitMap Instructions for handling DTMF tones at 913 the MG. 914 ServiceChange In ServiceChange, what, why service change 915 occurred, etc. 916 ObservedEvents In Notify or AuditValue, report of events 917 observed. 918 Statistics In Subtract and Audit, Report of 919 Statistics kept on a Termination. 921 6.2.5 Root Termination 923 Occasionally, a command must refer to the entire gateway, rather 924 than a termination within it. A special TerminationID, "Root" is 925 reserved for this purpose. Packages may be defined on Root. Root 926 thus may have properties and events (signals are not appropriate 927 for root). Accordingly, the root TerminationID may appear in: 929 . a Modify command - to change a property or set an event 930 . a Notify command - to report an event 931 . an AuditValue return - to examine the values of properties 932 implemented on root 933 . an AuditCapability - to determine what properties of root are 934 implemented 935 . a ServiceChange - to declare the gateway in or out of service. 937 Any other use of the root TerminationID is an error. 939 7. COMMANDS 941 The protocol provides commands for manipulating the logical entities 942 of the protocol connection model, Contexts and Terminations. 943 Commands provide control at the finest level of granularity 944 supported by the protocol. For example, Commands exist to add 946 Rosen et al Standards Track -- Expires Oct 2000 19 947 Terminations to a Context, modify Terminations, subtract 948 Terminations from a Context, and audit properties of Contexts or 949 Terminations. Commands provide for complete control of the 950 properties of Contexts and Terminations. This includes specifying 951 which events a Termination is to report, which signals/actions are 952 to be applied to a Termination and specifying the topology of a 953 Context (who hears/sees whom). 955 Most commands are for the specific use of the Media Gateway 956 Controller as command initiator in controlling Media Gateways as 957 command responders. The exceptions are the Notify and ServiceChange 958 commands: Notify is sent from Media Gateway to Media Gateway 959 Controller, and ServiceChange may be sent by either entity. Below 960 is an overview of the commands; they are explained in more detail in 961 section 7.2. 963 1. Add. The Add command adds a termination to a context. The Add 964 command on the first Termination in a Context is used to create a 965 Context. 967 2. Modify. The Modify command modifies the properties, events and 968 signals of a termination. 970 3. Subtract. The Subtract command disconnects a Termination from its 971 Context and returns statistics on the Termination's participation 972 in the Context. The Subtract command on the last Termination in 973 a Context deletes the Context. 974 4. Move. The Move command atomically moves a Termination to another 975 context. 977 5. AuditValue. The AuditValue command returns the current state of 978 properties, events, signals and statistics of Terminations. 980 6. AuditCapabilities. The AuditCapabilities command returns all the 981 possible values for Termination properties, events and signals 982 allowed by the Media Gateway. 984 7. Notify. The Notify command allows the Media Gateway to inform the 985 Media Gateway Controller of the occurrence of events in the Media 986 Gateway. 988 8. ServiceChange. The ServiceChange Command allows the Media Gateway 989 to notify the Media Gateway Controller that a Termination or 990 group of Terminations is about to be taken out of service or has 991 just been returned to service. ServiceChange is also used by 992 the MG to announce its availability to an MGC (registration), and 993 to notify the MGC of impending or completed restart of the MG. 994 The MGC may announce a handover to the MG by sending it a 995 ServiceChange command. The MGC may also use ServiceChange to 996 instruct the MG to take a Termination or group of Terminations in 997 or out of service. 999 Rosen et al Standards Track -- Expires Oct 2000 20 1000 These commands are detailed in sections 7.2.1 through 7.2.8 1002 7.1 Descriptors 1004 The parameters to a command are termed Descriptors. A Descriptor 1005 consists of a name and a list of items. Some items may have values. 1006 Many Commands share common Descriptors. This subsection enumerates 1007 these Descriptors. Descriptors may be returned as output from a 1008 command. Parameters and parameter usage specific to a given Command 1009 type are described in the subsection that describes the Command. 1011 7.1.1 Specifying Parameters 1013 Command parameters are structured into a number of descriptors. In 1014 general, the text format of descriptors is 1015 DescriptorName={parm=value, parm=value_.}. 1017 Parameters may be fully specified, over-specified or under- 1018 specified: 1020 1. Fully specified parameters have a single, unambiguous value that 1021 the command initiator is instructing the command responder to use 1022 for the specified parameter. 1024 2. Under-specified parameters, using the CHOOSE value, allow the 1025 command responder to choose any value it can support. 1027 3. Over-specified parameters have a list of potential values. The 1028 list order specifies the command initiator's order of preference 1029 of selection. The command responder chooses one value from the 1030 offered list and returns that value to the command initiator. 1032 Unspecified mandatory parameters (i.e. mandatory parameters not 1033 specified in a descriptor) result in the command responder retaining 1034 the previous value for that parameter. Unspecified optional 1035 parameters result in the command responder using the default value 1036 of the parameter. Whenever a parameter is underspecified or 1037 overspecified, the descriptor containing the value chosen by the 1038 responder is included as output from the command. 1040 Each command specifies the TerminationId the command operates on. 1041 This TerminationId may be "wildcarded". When the TerminationId of a 1042 command is wildcarded, the effect shall be as if the command was 1043 repeated with each of the TerminationIds matched. 1045 7.1.2 Modem Descriptor 1047 The Modem descriptor specifies the modem type and parameters, if 1048 any, required for use in e.g. H.324 and text conversation. The 1049 descriptor includes the following modem types: V.18, V.22, V.22bis, 1050 V.32, V.32bis, V.34, V.90, V.91, Synchronous ISDN, and allows for 1052 Rosen et al Standards Track -- Expires Oct 2000 21 1053 extensions. By default, no modem descriptor is present in a 1054 Termination. 1056 7.1.3 Multiplex Descriptor 1058 In multimedia calls, a number of media streams are carried on a 1059 (possibly different) number of bearers. The multiplex descriptor 1060 associates the media and the bearers. The descriptor includes the 1061 multiplex type: 1062 . H.221 1063 . H.223, 1064 . H.226, 1065 . V.76, 1066 . Possible Extensions 1067 and a set of TerminationIDs representing the multiplexed inputs, in 1068 order. For example: 1069 Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22} 1071 7.1.4 Media Descriptor 1073 The Media Descriptor specifies the parameters for all the media 1074 streams. These parameters are structured into two descriptors, a 1075 Termination State Descriptor, which specifies the properties of a 1076 termination that are not stream dependent, and one or more Stream 1077 Descriptors each of which describes a single media stream. 1079 A stream is identified by a StreamID. The StreamID is used to link 1080 the streams in a Context that belong together. Multiple streams 1081 exiting a termination shall be synchronized with each other. Within 1082 the Stream Descriptor, there are up to three subsidiary descriptors, 1083 LocalControl, Local, and Remote. The relationship between these 1084 descriptors is thus: 1086 Media Descriptor 1087 TerminationStateDescriptor 1088 Stream Descriptor 1089 LocalControl Descriptor 1090 Local Descriptor 1091 Remote Descriptor 1093 As a convenience a LocalControl, Local, or Remote descriptor may be 1094 included in the Media Descriptor without an enclosing Stream 1095 descriptor. In this case, the StreamID is assumed to be 1. 1097 7.1.5 Termination State Descriptor 1099 The Termination State Descriptor contains the ServiceStates 1100 property, the EventBufferControl property and properties of a 1101 termination (defined in Packages) that are not stream specific. 1103 The ServiceStates property describes the overall state of the 1104 termination (not stream-specific). A Termination can be in one of 1106 Rosen et al Standards Track -- Expires Oct 2000 22 1107 the following states: "test", "out of service", or "in service". 1108 The "test" state indicates that the termination is being tested. The 1109 state "out of service" indicates that the termination cannot be used 1110 for traffic. The state "in service" indicates that a termination 1111 can be used or is being used for normal traffic. "in service" is 1112 the default state. 1114 Values assigned to Properties may be simple values 1115 (integer/string/enumeration) or may be underspecified, where more 1116 than one value is supplied and the MG may make a choice: 1117 . Alternative Values: multiple values in a list, one of which must 1118 be selected 1119 . Ranges: minimum and maximum values, any value between min and max 1120 must be selected, boundary values included 1121 . Greater Than/Less Than: value must be greater/less than specified 1122 value 1123 . CHOOSE Wildcard: the MG chooses from the allowed values for the 1124 property 1126 The EventBufferControl property specifies whether events are 1127 buffered following detection of an event in the Events Descriptor, 1128 or processed immediately. See section 7.1.9 for details. 1130 7.1.6 Stream Descriptor 1132 A Stream descriptor specifies the parameters of a single bi- 1133 directional stream. These parameters are structured into three 1134 descriptors: one that contains termination properties specific to a 1135 stream and one each for local and remote flows. The Stream 1136 Descriptor includes a StreamID which identifies the stream. Streams 1137 are created by specifying a new StreamID on one of the terminations 1138 in a Context. A stream is deleted by setting empty Local and Remote 1139 descriptors for the stream with ReserveGroup and ReserveValue in 1140 LocalControl set to "false" on all terminations in the context that 1141 previously supported that stream. 1143 StreamIDs are of local significance between MGC and MG and they are 1144 assigned by the MGC. Within a context, StreamID is a means by which 1145 to indicate which media flows are interconnected: streams with the 1146 same StreamID are connected. 1148 If a termination is moved from one context to another, the effect on 1149 the context to which the termination is moved is the same as in the 1150 case that a new termination were added with the same StreamIDs as 1151 the moved termination. 1153 7.1.7 LocalControl Descriptor 1155 The LocalControl Descriptor contains the Mode property, the 1156 ReserveGroup and ReserveValue properties and properties of a 1157 termination (defined in Packages) that are stream specific, and are 1159 Rosen et al Standards Track -- Expires Oct 2000 23 1160 of interest between the MG and the MGC. Values of properties may be 1161 underspecified as in section 7.1.1. 1163 The allowed values for the mode property are send-only, receive- 1164 only, send/receive, inactive and loop-back. "Send" and "receive" 1165 are with respect to the exterior of the context, so that, for 1166 example, a stream set to mode=sendonly does not pass received media 1167 into the context. Signals and Events are not affected by mode. 1169 The boolean-valued Reserve properties, ReserveValue and 1170 ReserveGroup, of a Termination indicate what the MG is expected to 1171 do when it receives a local and/or remote descriptor. 1173 If the value of a Reserve property is True, the MG SHALL reserve 1174 resources for all alternatives specified in the local and/or remote 1175 descriptors for which it currently has resources available. It 1176 SHALL respond with the alternatives for which it reserves resources. 1177 If it cannot not support any of the alternatives, it SHALL respond 1178 with a reply to the MGC that contains empty local and/or remote 1179 descriptors. 1181 If the value of a Reserve property is False, the MG SHALL choose one 1182 of the alternatives specified in the local descriptor (if present) 1183 and one of the alternatives specified in the remote descriptor (if 1184 present). If the MG has not yet reserved resources to support the 1185 selected alternative, it SHALL reserve the resources. If, on the 1186 other hand, it already reserved resources for the Termination 1187 addressed (because of a prior exchange with ReserveValue and/or 1188 ReserveGroup equal to True), it SHALL release any excess resources 1189 it reserved previously. Finally, the MG shall send a reply to the 1190 MGC containing the alternatives for the local and/or remote 1191 descriptor that it selected. If the MG does not have sufficient 1192 resources to support any of the alternatives specified, is SHALL 1193 respond with error 510 (insufficient resources). 1195 The default value of ReserveValue and ReserveGroup is False. 1197 A new setting of the LocalControl Descriptor completely replaces the 1198 previous setting of that descriptor in the MG. Thus to retain 1199 information from the previous setting the MGC must include that 1200 information in the new setting. If the MGC wishes to delete some 1201 information from the existing descriptor, it merely resends the 1202 descriptor (in a Modify command) with the unwanted information 1203 stripped out. 1205 7.1.8 Local and Remote Descriptors 1207 The MGC uses Local and Remote descriptors to reserve and commit MG 1208 resources for media decoding and encoding for the given Stream(s) 1209 and Termination to which they apply. The MG includes these 1210 descriptors in its response to indicate what it is actually prepared 1211 to support. The MG SHALL include additional properties and their 1213 Rosen et al Standards Track -- Expires Oct 2000 24 1214 values in its response if these properties are mandatory yet not 1215 present in the requests made by the MGC (e.g., by specifying 1216 detailed video encoding parameters where the MGC only specified the 1217 payload type). 1219 Local refers to the media received by the MG and Remote refers to 1220 the media sent by the MG. 1222 When text encoding the protocol, the descriptors consist of session 1223 descriptions as defined in SDP (RFC2327). In session descriptions 1224 sent from the MGC to the MG, the following exceptions to the syntax 1225 of RFC 2327 are allowed: 1226 . the "s=", "t=" and "o=" lines are optional, 1227 . the use of CHOOSE is allowed in place of a single parameter value, 1228 and 1229 . the use of alternatives is allowed in place of a single parameter 1230 value. 1232 When multiple session descriptions are provided in one descriptor, 1233 the "v=" lines are required as delimiters; otherwise they are 1234 optional in session descriptions sent to the MG. Implementations 1235 shall accept session descriptions that are fully conformant to 1236 RFC2327. When binary encoding the protocol the descriptor consists 1237 of groups of properties (tag-value pairs) as specified in Annex C. 1238 Each such group may contain the parameters of a session description. 1240 Below, the semantics of the local and remote descriptors are 1241 specified in detail. The specification consists of two parts. The 1242 first part specifies the interpretation of the contents of the 1243 descriptor. The second part specifies the actions the MG must take 1244 upon receiving the local and remote descriptors. The actions to be 1245 taken by the MG depend on the values of the ReserveValue and 1246 ReserveGroup properties of the LocalControl descriptor. 1248 Either the local or the remote descriptor or both may be 1249 . unspecified (i.e., absent), 1250 . empty, 1251 . underspecified through use of CHOOSE in a property value, 1252 . fully specified, or 1253 . overspecified through presentation of multiple groups of 1254 properties and possibly multiple property values in one or more of 1255 these groups. 1256 . 1257 Where the descriptors have been passed from the MGC to the MG, they 1258 are interpreted according to the rules given in section 7.1.1, with 1259 the following additional comments for clarification: 1261 (a) An unspecified Local or Remote descriptor is considered to be a 1262 missing mandatory parameter. It requires the MG to use whatever was 1263 last specified for that descriptor. It is possible that there was 1264 no previously-specified value, in which case the descriptor 1265 concerned is ignored in further processing of the command. 1267 Rosen et al Standards Track -- Expires Oct 2000 25 1268 (b) An empty Local (Remote) descriptor in a message from the MGC 1269 signifies a request to release any resources reserved for the media 1270 flow received (sent). 1272 (c) If multiple groups of properties are present in a Local or 1273 Remote descriptor or multiple values within a group, the order of 1274 preference is descending. 1276 (d) Underspecified or overspecified properties within a group of 1277 properties sent by the MGC are requests for the MG to choose one or 1278 more values which it can support for each of those properties. In 1279 case of an overspecified property, the list of values is in 1280 descending order of preference. 1282 Subject to the above rules, subsequent action depends on the values 1283 of the ReserveValue and ReserveGroup properties in LocalControl. 1285 If ReserveGroup is true, the MG reserves the resources required to 1286 support any of the requested property group alternatives that it can 1287 currently support. If ReserveValue is true, the MG reserves the 1288 resources required to support any of the requested property value 1289 alternatives that it can currently support. 1291 NOTE - If a Local or Remote descriptor contains multiple groups of 1292 properties, and ReserveGroup is true, then the MG is requested to 1293 reserve resources so that it can decode or encode the media stream 1294 according to any of the alternatives. For instance, if the Local 1295 descriptor contains two groups of properties, one specifying 1296 packetized G.711 A-law audio and the other G.723.1 audio, the MG 1297 reserves resources so that it can decode one audio stream encoded in 1298 either G.711 A-law format or G.723.1 format. The MG does not have 1299 to reserve resources to decode two audio streams simultaneously, one 1300 encoded in G.711 A-law and one in G.723.1. The intention for the 1301 use of ReserveValue is analogous. 1303 If ReserveGroup is true or ReserveValue is true, then the following 1304 rules apply. 1305 . If the MG has insufficient resources to support all alternatives 1306 requested by the MGC and the MGC requested resources in both Local 1307 and Remote, the MG should reserve resources to support at least 1308 one alternative each within Local and Remote. 1310 . If the MG has insufficient resources to support at least one 1311 alternative within a Local (Remote) descriptor received from the 1312 MGC, it shall return an empty Local (Remote) in response. 1314 . In its response to the MGC, when the MGC included Local and Remote 1315 descriptors, the MG SHALL include Local and Remote descriptors for 1316 all groups of properties and property values it reserved resources 1317 for. If the MG is incapable of supporting at least one of the 1318 alternatives within the Local (Remote) descriptor received from 1319 the MGC, it SHALL return an empty Local (Remote) descriptor. 1321 Rosen et al Standards Track -- Expires Oct 2000 26 1322 . If the Mode property of the LocalControl descriptor is RecvOnly or 1323 SendRecv, the MG must be prepared to receive media encoded 1324 according to any of the alternatives included in its response to 1325 the MGC. 1327 . If ReserveGroup is False and ReserveValue is false, then the MG 1328 SHOULD apply the following rules to resolve Local and Remote to a 1329 single alternative each: 1331 . The MG chooses the first alternative in Local for which it is able 1332 to support at least one alternative in Remote. 1334 . If the MG is unable to support at least one Local and one Remote 1335 alternative, it returns Error 510 (Insufficient Resources). 1337 . The MG returns its selected alternative in each of Local and 1338 Remote. 1340 A new setting of a Local or Remote Descriptor completely replaces 1341 the previous setting of that descriptor in the MG. Thus to retain 1342 information from the previous setting the MGC must include that 1343 information in the new setting. If the MGC wishes to delete some 1344 information from the existing descriptor, it merely resends the 1345 descriptor (in a Modify command) with the unwanted information 1346 stripped out. 1348 7.1.9 Events Descriptor 1350 The EventsDescriptor parameter contains a RequestIdentifier and a 1351 list of events that the Media Gateway is requested to detect and 1352 report. The RequestIdentifier is used to correlate the request with 1353 the notifications that it may trigger. Requested events include, 1354 for example, fax tones, continuity test results, and on-hook and 1355 off-hook transitions. 1357 Each event in the descriptor contains the Event name, an optional 1358 streamID, an optional KeepActive flag, and optional parameters. The 1359 Event name consists of a Package Name (where the event is defined) 1360 and an EventID. The ALL wildcard may be used for the EventID, 1361 indicating that all events from the specified package have to be 1362 detected. The default streamID is 0, indicating that the event to 1363 be detected is not related to a particular media stream. Events can 1364 have parameters. This allows a single event description to have 1365 some variation in meaning without creating large numbers of 1366 individual events. Further event parameters are defined in the 1367 package. 1369 The default action of the MG, when it detects an event in the Events 1370 Descriptor, is to send a Notify command to the MG. Any other action 1371 is for further study. 1373 Rosen et al Standards Track -- Expires Oct 2000 27 1374 If the value of the EventBufferControl property equals LockStep, 1375 following detection of such an event, normal handling of events is 1376 suspended. Any event which is subsequently detected and occurs in 1377 the EventBuffer Descriptor is added to the end of the EventBuffer (a 1378 FIFO queue), along with the time that it was detected. The MG 1379 SHALL wait for a new EventsDescriptor to be loaded. A new 1380 EventsDescriptor can be loaded either as the result of receiving a 1381 command with a new EventsDescriptor, or by activating an embedded 1382 EventsDescriptor. 1384 If EventBufferControl equals Off, the MG continues processing based 1385 on the active EventsDescriptor. 1387 In the case that an embedded EventsDescriptor being activated, the 1388 MG continues event processing based on the newly activated 1389 EventsDescriptor (Note - for purposes of EventBuffer handling, 1390 activation of an embedded EventsDescriptor is equivalent to receipt 1391 of a new EventsDescriptor). 1393 When the MG receives a command with a new EventsDescriptor, one or 1394 more events may have been buffered in the EventBuffer in the MG. The 1395 value of EventBufferControl then determines how the MG treats such 1396 buffered events. 1398 Case 1 1400 If EventBufferControl = LockStep and the MG receives a new 1401 EventsDescriptor it will check the FIFO EventBuffer and take the 1402 following actions: 1404 1. If the EventBuffer is empty, the MG waits for detection of events 1405 based on the new EventsDescriptor. 1407 2. If the EventBuffer is non-empty, the MG processes the FIFO queue 1408 starting with the first event: 1409 a) If the event in the queue is in the events listed in the new 1410 EventsDescriptor, the default action of the MG is to send a 1411 Notify command to the MGC and remove the event from the 1412 EventBuffer. Any other action is for further study. The time 1413 stamp of the Notify shall be the time the event was actually 1414 detected. The MG then waits for a new EventsDescriptor. While 1415 waiting for a new EventsDescriptor, any events matching the 1416 EventsBufferDescriptor will be placed in the EventBuffer and 1417 the event processing will repeat from step 1. 1419 b) If the event is not in the new EventsDescriptor, the MG 1420 SHALL discard the event and repeat from step 1. 1422 Rosen et al Standards Track -- Expires Oct 2000 28 1423 Case 2 1425 If EventBufferControl equals Off and the MG receives a new 1426 EventsDescriptor, it processes new events with the new 1427 EventsDescriptor. 1429 If the MG receives a command instructing it to set the value of 1430 EventBufferControl to Off, all events in the EventBuffer SHALL be 1431 discarded. 1433 The MG may report several events in a single Transaction as long as 1434 this does not unnecessarily delay the reporting of individual 1435 events. 1437 For procedures regarding transmitting the Notify command, refer to 1438 the appropriate annex for specific transport considerations. 1440 The default value of EventBufferControl is Off. 1442 Note - Since the EventBufferControl property is in the 1443 TerminationStateDescriptor, the MG might receive a command that 1444 changes the EventBufferControl property and does not include an 1445 EventsDescriptor. 1447 Normally, detection of an event shall cause any active signals to 1448 stop. When KeepActive is specified in the event, the MG shall not 1449 interrupt any signals active on the Termination on which the event 1450 is detected. 1452 An event can include an Embedded Signals descriptor and/or an 1453 Embedded Events Descriptor which, if present, replaces the current 1454 Signals/Events descriptor when the event is detected. It is 1455 possible, for example, to specify that the dial-tone Signal be 1456 generated when an off-hook Event is detected, or that the dial-tone 1457 Signal be stopped when a digit is detected. A media gateway 1458 controller shall not send EventsDescriptors with an event both 1459 marked KeepActive and containing an embedded SignalsDescriptor. 1461 Only one level of embedding is permitted. An embedded 1462 EventsDescriptor SHALL NOT contain another embedded 1463 EventsDescriptor; an embedded EventsDescriptor may contain an 1464 embedded SignalsDescriptor. 1466 An EventsDescriptor received by a media gateway replaces any 1467 previous Events Descriptor. Event notification in process shall 1468 complete, and events detected after the command containing the new 1469 EventsDescriptor executes, shall be processed according to the new 1470 EventsDescriptor. 1472 Rosen et al Standards Track -- Expires Oct 2000 29 1473 7.1.10 EventBuffer Descriptor 1475 The EventBuffer Descriptor contains a list of events, with their 1476 parameters if any, that the MG is requested to detect and buffer 1477 when EventBufferControl equals LockStep (see 7.1.9). 1479 7.1.11 Signals Descriptor 1481 A SignalsDescriptor is a parameter that contains the set of signals 1482 that the Media Gateway is asked to apply to a Termination. A 1483 SignalsDescriptor contains a number of signals and/or sequential 1484 signal lists. A SignalsDescriptor may contain zero signals and 1485 sequential signal lists. Support of sequential signal lists is 1486 optional. 1488 Signals are defined in packages. Signals shall be named with a 1489 Package name (in which the signal is defined) and a SignalID. No 1490 wildcard shall be used in the SignalID. Signals that occur in a 1491 SignalsDescriptor have an optional StreamID parameter (default is 0, 1492 to indicate that the signal is not related to a particular media 1493 stream), an optional signal type (see below), an optional duration 1494 and possibly parameters defined in the package that defines the 1495 signal. This allows a single signal to have some variation in 1496 meaning, obviating the need to create large numbers of individual 1497 signals. Finally, the optional parameter "notifyCompletion" allows 1498 a MGC to indicate that it wishes to be notified when the signal 1499 finishes playout. When the MGC enables the signal completion event 1500 (see section E.1.2) in an Events Descriptor, that event is detected 1501 whenever a signal terminates and "notifyCompletion" for that signal 1502 is set to TRUE. The signal completion event of section E.1.2 has a 1503 parameter that indicates how the signal terminated: it played to 1504 completion, it was interrupted by an event, it was halted because a 1505 new SignalsDescriptor arrived, or the signal did not complete for 1506 some other reason. 1508 The duration is an integer value that is expressed in hundredths of 1509 a second. 1511 There are three types of signals: 1512 . on/off - the signal lasts until it is turned off, 1513 . timeout - the signal lasts until it is turned off or a specific 1514 period of time elapses, 1515 . brief - the signal duration is so short that it will stop on its 1516 own unless a new signal is applied that causes it to stop; no 1517 timeout value is needed. 1519 If the signal type is specified in a SignalsDescriptor, it overrides 1520 the default signal type (see Section 12.1.4). If duration is 1521 specified for an on/off signal, it SHALL be ignored. 1523 A sequential signal list consists of a signal list identifier, a 1524 sequence of signals to be played sequentially, and a signal type. 1526 Rosen et al Standards Track -- Expires Oct 2000 30 1527 Only the trailing element of the sequence of signals in a sequential 1528 signal list may be an on/off signal. If the trailing element of the 1529 sequence is an on/off signal, the signal type of the sequential 1530 signal list shall be on/off as well. If the sequence of signals in 1531 a sequential signal list contains signals of type timeout and the 1532 trailing element is not of type on/off, the type of the sequential 1533 signal list SHALL be set to timeout. The duration of a sequential 1534 signal list with type timeout is the sum of the durations of the 1535 signals it contains. If the sequence of signals in a sequential 1536 signal list contains only signals of type brief, the type of the 1537 sequential signal list SHALL be set to brief. A signal list is 1538 treated as a single signal of the specified type when played out. 1540 Multiple signals and sequential signal lists in the same 1541 SignalsDescriptor shall be played simultaneously. 1543 Signals are defined as proceeding from the termination towards the 1544 exterior of the Context unless otherwise specified in a package. 1545 When the same Signal is applied to multiple Terminations within one 1546 Transaction, the MG should consider using the same resource to 1547 generate these Signals. 1549 Production of a Signal on a Termination is stopped by application of 1550 a new SignalsDescriptor, or detection of an Event on the Termination 1551 (see section 7.1.9). 1553 A new SignalsDescriptor replaces any existing SignalsDescriptor. 1554 Any signals applied to the Termination not in the replacement 1555 descriptor shall be stopped, and new signals are applied, except as 1556 follows. Signals present in the replacement descriptor and 1557 containing the KeepActive flagshall be continued if they are 1558 currently playing and have not already completed. If a replacement 1559 signal descriptor contains a signal that is not currently playing 1560 and contains the KeepActive flag, that signal SHALL be ignored. If 1561 the replacement descriptor contains a sequential signal list with 1562 the same identifier as the existing descriptor, then 1563 . the signal type and sequence of signals in the sequential signal 1564 list in the replacement descriptor shall be ignored, and 1566 . the playing of the signals in the sequential signal list in the 1567 existing descriptor shall not be interrupted. 1569 7.1.12 Audit Descriptor 1571 The Audit Descriptor specifies what information is to be audited. 1572 The Audit Descriptor specifies the list of descriptors to be 1573 returned. Audit may be used in any command to force the return of a 1574 descriptor even if the descriptor in the command was not present, or 1575 had no underspecified parameters. Possible items in the Audit 1576 Descriptor are: 1577 Modem 1578 Mux 1580 Rosen et al Standards Track -- Expires Oct 2000 31 1581 Events 1582 Media 1583 Signals 1584 ObservedEvents 1585 DigitMap 1586 Statistics 1587 Packages 1588 EventBuffer 1590 Audit may be empty, in which case, no descriptors are returned. 1591 This is useful in Subtract, to inhibit return of statistics, 1592 especially when using wildcard. 1594 7.1.13 ServiceChange Descriptor 1596 The ServiceChangeDescriptor contains the following parameters: 1597 . ServiceChangeMethod 1598 . ServiceChangeReason 1599 . ServiceChangeAddress 1600 . ServiceChangeDelay 1601 . ServiceChangeProfile 1602 . ServiceChangeVersion 1603 . ServiceChangeMGCId 1604 . TimeStamp 1605 See section 7.2.8. 1607 7.1.14 DigitMap Descriptor 1609 A DigitMap is a dialing plan resident in the Media Gateway used for 1610 detecting and reporting digit events received on a Termination. The 1611 DigitMap Descriptor contains a DigitMap name and the DigitMap to be 1612 assigned. A digit map may be preloaded into the MG by management 1613 action and referenced by name in an EventsDescriptor, may be defined 1614 dynamically and subsequently referenced by name, or the actual 1615 digitmap itself may be specified in the EventsDescriptor. It is 1616 permissible for a digit map completion event within an Events 1617 Descriptor to refer by name to a DigitMap which is defined by a 1618 DigitMap Descriptor within the same command, regardless of the 1619 transmitted order of the respective descriptors. 1621 DigitMaps defined in a DigitMapDescriptor can occur in any of the 1622 standard Termination manipulation Commands of the protocol. A 1623 DigitMap, once defined, can be used on all Terminations specified by 1624 the (possibly wildcarded) TerminationID in such a command. 1625 DigitMaps defined on the root Termination are global and can be used 1626 on every Termination in the MG, provided that a DigitMap with the 1627 same name has not been defined on the given Termination. When a 1628 DigitMap is defined dynamically in a DigitMap Descriptor: 1629 . A new DigitMap is created by specifying a name that is not yet 1630 defined. The value shall be present. 1632 Rosen et al Standards Track -- Expires Oct 2000 32 1633 . A DigitMap value is updated by supplying a new value for a name 1634 that is already defined. Terminations presently using the 1635 digitmap shall continue to use the old definition; subsequent 1636 EventsDescriptors specifying the name, including any 1637 EventsDescriptor in the command containing the DigitMap 1638 descriptor, shall use the new one. 1640 . A DigitMap is deleted by supplying an empty value for a name that 1641 is already defined. Terminations presently using the digitmap 1642 shall continue to use the old definition. 1644 The collection of digits according to a DigitMap may be protected by 1645 three timers, viz. a start timer (T), short timer (S), and long 1646 timer (L). 1647 1. The start timer (T) is used prior to any digits having been 1648 dialed. 1650 2. If the Media Gateway can determine that at least one more digit 1651 is needed for a digit string to match any of the allowed patterns 1652 in the digit map, then the interdigit timer value should be set 1653 to a long (L) duration (e.g. 16 seconds). 1655 3. If the digit string has matched one of the patterns in a digit 1656 map, but it is possible that more digits could be received which 1657 would cause a match with a different pattern, then instead of 1658 reporting the match immediately, the MG must apply the short 1659 timer (S) and wait for more digits. 1661 The timers are configurable parameters to a DigitMap. The Start 1662 timer is started at the beginning of every digit map use, but can be 1663 overridden. 1665 The formal syntax of the digit map is described by the DigitMap rule 1666 in the formal syntax description of the protocol (see Annex A and 1667 Annex B). A DigitMap, according to this syntax, is defined either by 1668 a string or by a list of strings. Each string in the list is an 1669 alternative event sequence, specified either as a sequence of digit 1670 map symbols or as a regular expression of digit map symbols. These 1671 digit map symbols, the digits "0" through "9" and letters "A" 1672 through a maximum value depending on the signalling system 1673 concerned, but never exceeding "K", correspond to specified events 1674 within a package which has been designated in the Events Descriptor 1675 on the termination to which the digit map is being applied. (The 1676 mapping between events and digit map symbols is defined in the 1677 documentation for packages associated with channel-associated 1678 signalling systems such as DTMF, MF, or R2. Digits "0" through "9" 1679 MUST be mapped to the corresponding digit events within the 1680 signalling system concerned. Letters should be allocated in logical 1681 fashion, facilitating the use of range notation for alternative 1682 events.) 1684 Rosen et al Standards Track -- Expires Oct 2000 33 1685 The letter "x" is used as a wildcard, designating any event 1686 corresponding to symbols in the range "0"-"9". The string may also 1687 contain explicit ranges and, more generally, explicit sets of 1688 symbols, designating alternative events any one of which satisfies 1689 that position of the digit map. Finally, the dot symbol "." stands 1690 for zero or more repetitions of the event selector (event, range of 1691 events, set of alternative events, or wildcard) that precedes it. 1692 As a consequence of the third timing rule above, inter-event timing 1693 while matching the dot symbol uses the short timer by default. 1695 In addition to these event symbols, the string may contain "S" and 1696 "L" inter-event timing specifiers and the "Z" duration modifier. 1697 "S" and "L" respectively indicate that the MG should use the short 1698 (S) timer or the long (L) timer for subsequent events, over-riding 1699 the timing rules described above. A timer specifier following a dot 1700 specifies inter-event timing for all events matching the dot as well 1701 as for subsequent events. If an explicit timing specifier is in 1702 effect in one alternative event sequence, but none is given in any 1703 other candidate alternative, the timer value set by the explicit 1704 timing specifier must be used. If all sequences with explicit 1705 timing controls are dropped from the candidate set, timing reverts 1706 to the default rules given above. Finally, if conflicting timing 1707 specifiers are in effect in different alternative sequences, the 1708 results are undefined. 1710 A "Z" designates a long duration event: placed in front of the 1711 symbol(s) designating the event(s) which satisfy a given digit 1712 position, it indicates that that position is satisfied only if the 1713 duration of the event exceeds the long-duration threshold. The 1714 value of this threshold is assumed to be provisioned in the MG. 1716 A digit map is active while the events descriptor which invoked it 1717 is active and it has not completed. A digit map completes when: 1718 . a timer has expired, or 1720 . an alternative event sequence has been matched and no other 1721 alternative event sequence in the digit map could be matched 1722 through detection of an additional event (unambiguous match), or 1724 . an event has been detected such that a match to a complete 1725 alternative event sequence of the digit map will be impossible no 1726 matter what additional events are received. 1728 Upon completion, a digit map completion event as defined in the 1729 package providing the events being mapped into the digit map shall 1730 be generated. At that point the digit map is deactivated. 1731 Subsequent events in the package are processed as per the currently 1732 active event processing mechanisms. 1734 Pending completion, successive events shall be processed according 1735 to the following rules: 1737 Rosen et al Standards Track -- Expires Oct 2000 34 1738 1. The "current dial string", an internal variable, is initially 1739 empty. The set of candidate alternative event sequences includes 1740 all of the alternatives specified in the digit map. 1742 2. At each step, a timer is set to wait for the next event, based 1743 either on the default timing rules given above or on explicit 1744 timing specified in one or more alternative event sequences. If 1745 the timer expires and a member of the candidate set of 1746 alternatives is fully satisfied, a timeout completion with full 1747 match is reported. If the timer expires and part or none of any 1748 candidate alternative is satisfied, a timeout completion with 1749 partial match is reported. 1751 3. If an event is detected before the timer expires, it is mapped to 1752 a digit string symbol and provisionally added to the end of the 1753 current dial string. The duration of the event (long or not 1754 long) is noted if and only if this is relevant in the current 1755 symbol position (because at least one of the candidate 1756 alternative event sequences includes the "Z" modifier at this 1757 position in the sequence). 1759 4. The current dial string is compared to the candidate alternative 1760 event sequences. If and only if a sequence expecting a long- 1761 duration event at this position is matched (i.e. the event had 1762 long duration and met the specification for this position), then 1763 any alternative event sequences not specifying a long duration 1764 event at this position are discarded, and the current dial string 1765 is modified by inserting a "Z" in front of the symbol 1766 representing the latest event. Any sequence expecting a long- 1767 duration event at this position but not matching the observed 1768 event is discarded from the candidate set. If alternative event 1769 sequences not specifying a long duration event in the given 1770 position remain in the candidate set after application of the 1771 above rules, the observed event duration is treated as irrelevant 1772 in assessing matches to them. 1774 5. If exactly one candidate remains, a completion event is generated 1775 indicating an unambiguous match. If no candidates remain, the 1776 latest event is removed from the current dial string and a 1777 completion event is generated indicating full match if one of the 1778 candidates from the previous step was fully satisfied before the 1779 latest event was detected, or partial match otherwise. The event 1780 removed from the current dial string will then be reported as per 1781 the currently active event processing mechanisms. 1783 6. If no completion event is reported out of step 5 (because the 1784 candidate set still contains more than one alternative event 1785 sequence), processing returns to step 2. 1787 A digit map is activated whenever a new event descriptor is applied 1788 to the termination or embedded event descriptor is activated, and 1789 that event descriptor contains a digit map completion event which 1791 Rosen et al Standards Track -- Expires Oct 2000 35 1792 itself contains a digit map parameter. Each new activation of a 1793 digit map begins at step 1 of the above procedure, with a clear 1794 current dial string. Any previous contents of the current dial 1795 string from an earlier activation are lost. While the digit map is 1796 activated, detection is enabled for all events defined in the 1797 package containing the specified digit map completion event. Normal 1798 event behaviour (e.g. stopping of signals unless the digit 1799 completion event has the KeepActive flag enabled) continues to apply 1800 for each such event detected, except that the events in the package 1801 containing the specified digit map completion event other than the 1802 completion event itself are not individually notified. 1804 Note that if a package contains a digit map completion event, then 1805 an event specification consisting of the package name with a 1806 wildcarded ItemID (Property Name) will activate a digit map if the 1807 event includes a digit map parameter. Regardless of whether a digit 1808 map is activated, this form of event specification will cause the 1809 individual events to be reported to the MGC as they are detected. 1811 As an example, consider the following dial plan: 1813 0 Local operator 1814 00 Long distance operator 1815 xxxx Local extension number 1816 (starts with 1-7) 1817 8xxxxxxx Local number 1818 #xxxxxxx Off-site extension 1819 *xx Star services 1820 91xxxxxxxxxx Long distance number 1821 9011 + up to 15 digits International number 1822 If the DTMF detection package described in Annex E (section E.6) is 1823 used to collect the dialled digits, then the dialling plan shown 1824 above results in the following digit map: 1826 (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.) 1828 7.1.15 Statistics Descriptor 1830 The Statistics parameter provides information describing the status 1831 and usage of a Termination during its existence within a specific 1832 Context. There is a set of standard statistics kept for each 1833 termination where appropriate (number of octets sent and received 1834 for example). The particular statistical properties that are 1835 reported for a given Termination are determined by the Packages 1836 realized by the Termination. By default, statistics are reported 1837 when the Termination is Subtracted from the Context. This behavior 1838 can be overridden by including an empty AuditDescriptor in the 1839 Subtract command. Statistics may also be returned from the 1840 AuditValue command, or any Add/Move/Modify command using the Audit 1841 descriptor. 1843 Rosen et al Standards Track -- Expires Oct 2000 36 1844 Statistics are cumulative; reporting Statistics does not reset them. 1845 Statistics are reset when a Termination is Subtracted from a 1846 Context. 1848 7.1.16 Packages Descriptor 1850 Used only with the AuditValue command, the PackageDescriptor returns 1851 a list of Packages realized by the Termination. 1853 7.1.17 ObservedEvents Descriptor 1855 ObservedEvents is supplied with the Notify command to inform the MGC 1856 of which event(s) were detected. Used with the AuditValue command, 1857 the ObservedEventsDescriptor returns events in the event buffer 1858 which have not been Notified. ObservedEvents contains the 1859 RequestIdentifier of the EventsDescriptor that triggered the 1860 notification, the event(s) detected and the detection time(s). 1861 Detection times are reported with a precision of hundredths of a 1862 second. Time is expressed in UTC. 1864 7.1.18 Topology Descriptor 1866 A topology descriptor is used to specify flow directions between 1867 terminations in a Context. Contrary to the descriptors in previous 1868 sections, the topology descriptor applies to a Context instead of a 1869 Termination. The default topology of a Context is that each 1870 termination's transmission is received by all other terminations. 1871 The Topology Descriptor is optional to implement. 1873 The Topology Descriptor occurs before the commands in an action. It 1874 is possible to have an action containing only a Topology Descriptor, 1875 provided that the context to which the action applies already 1876 exists. 1878 A topology descriptor consists of a sequence of triples of the form 1879 (T1, T2, association). T1 and T2 specify Terminations within the 1880 Context, possibly using the ALL or CHOOSE wildcard. The association 1881 specifies how media flows between these two Terminations as follows. 1882 . (T1, T2, isolate) means that the Terminations matching T2 do not 1883 receive media from the Terminations matching T1, nor vice versa. 1885 . (T1, T2, oneway) means that the Terminations that match T2 receive 1886 media from the Terminations matching T1, but not vice versa. In 1887 this case use of the ALL wildcard such that there are Terminations 1888 that match both T1 and T2 is not allowed. 1890 . (T1, T2, bothway) means that the Terminations matching T2 receive 1891 media from the Terminations matching T1, and vice versa. In this 1892 case it is allowed to use wildcards such that there are 1893 Terminations that match both T1 and T2. However, if there is a 1894 Termination that matches both, no loopback is introduced; 1895 loopbacks are created by setting the TerminationMode. 1897 Rosen et al Standards Track -- Expires Oct 2000 37 1898 CHOOSE wildcards may be used in T1 and T2 as well, under the 1899 following restrictions: 1900 . the action (see section 8) of which the topology descriptor is 1901 part contains an Add command in which a CHOOSE wildcard is used; 1903 . if a CHOOSE wildcard occurs in T1 or T2, then a partial name SHALL 1904 NOT be specified. 1906 The CHOOSE wildcard in a topology descriptor matches the 1907 TerminationID that the MG assigns in the first Add command that uses 1908 a CHOOSE wildcard in the same action. An existing Termination that 1909 matches T1 or T2 in the Context to which a Termination is added, is 1910 connected to the newly added Termination as specified by the 1911 topology descriptor. The default association when a termination is 1912 not mentioned in the Topology descriptor is bothway (if T3 is added 1913 to a context with T1 and T2 with topology (T3,T1,oneway) it will be 1914 connected bothway to T2). 1916 The figure below and the table following it show some examples of 1917 the effect of including topology descriptors in actions. In these 1918 examples it is assumed that the topology descriptors are applied in 1919 sequence. 1921 Context 1 Context 2 Context 3 1922 +------------------+ +------------------+ +------------------+ 1923 | +----+ | | +----+ | | +----+ | 1924 | | T2 | | | | T2 | | | | T2 | | 1925 | +----+ | | +----+ | | +----+ | 1926 | ^ ^ | | ^ | | ^ | 1927 | | | | | | | | | | 1928 | +--+ +--+ | | +---+ | | +--+ | 1929 | | | | | | | | | | 1930 | v v | | v | | | | 1931 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1932 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | 1933 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1934 +------------------+ +------------------+ +------------------+ 1935 1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway 1937 Rosen et al Standards Track -- Expires Oct 2000 38 1938 Context 1 Context 2 Context 3 1939 +------------------+ +------------------+ +------------------+ 1940 | +----+ | | +----+ | | +----+ | 1941 | | T2 | | | | T2 | | | | T2 | | 1942 | +----+ | | +----+ | | +----+ | 1943 | | | | ^ | | ^ ^ | 1944 | | | | | | | | | | 1945 | +--+ | | +---+ | | +--+ +--+ | 1946 | | | | | | | | | | 1947 | v | | v | | v v | 1948 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1949 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | 1950 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | 1951 +------------------+ +------------------+ +------------------+ 1952 4. T2, T3 oneway 5. T2, T3 bothway 6. T1, T2 bothway 1954 Figure 4: A Sequence Of Example Topologies 1956 Topology Description 1958 1 No topology descriptors 1959 When no topology descriptors are included, all 1960 terminations have a both way connection to all 1961 other terminations. 1963 2 T1, T2, Isolate 1964 Removes the connection between T1 and T2. 1965 T3 has a both way connection with both T1 and 1966 T2. T1 and T2 have bothway connection to T3. 1968 3 T3, T2, oneway 1969 A oneway connection from T3 to T2 (i.e. T2 1970 receives media flow from T3). A bothway 1971 connection between T1 and T3. 1973 4 T2, T3, oneway 1974 A oneway connection between T2 to T3. 1975 T1 and T3 remain bothway connected 1977 5 T2, T3 bothway 1978 T2 is bothway connected to T3. This results in 1979 the same as 2. 1981 6 T1, T2 bothway (T2, T3 bothway 1982 and T1,T3 bothway may be implied 1983 or explicit). 1984 All terminations have a bothway connection to 1985 all other terminations. 1986 A oneway connection must implemented in such a way that the other 1987 Terminations in the Context are not aware of the change in topology. 1989 Rosen et al Standards Track -- Expires Oct 2000 39 1990 7.2 Command Application Programming Interface 1992 Following is an Application Programming Interface (API) describing 1993 the Commands of the protocol. This API is shown to illustrate the 1994 Commands and their parameters and is not intended to specify 1995 implementation (e.g. via use of blocking function calls). It 1996 describes the input parameters in parentheses after the command name 1997 and the return values in front of the Command. This is only for 1998 descriptive purposes; the actual Command syntax and encoding are 1999 specified in later subsections. All parameters enclosed by square 2000 brackets ([. . . ]) are considered optional. 2002 7.2.1 Add 2004 The Add Command adds a Termination to a Context. 2006 TerminationID 2007 [,MediaDescriptor] 2008 [,ModemDescriptor] 2009 [,MuxDescriptor] 2010 [,EventsDescriptor] 2011 [,SignalsDescriptor] 2012 [,DigitMapDescriptor] 2013 [,ObservedEventsDescriptor] 2014 [,EventBufferDescriptor] 2015 [,StatisticsDescriptor] 2016 [,PackagesDescriptor] 2017 Add( TerminationID 2018 [, MediaDescriptor] 2019 [, ModemDescriptor] 2020 [, MuxDescriptor] 2021 [, EventsDescriptor] 2022 [, SignalsDescriptor] 2023 [, DigitMapDescriptor] 2024 [, AuditDescriptor] 2025 ) 2027 The TerminationID specifies the termination to be added to the 2028 Context. The Termination is either created, or taken from the null 2029 Context. For an existing Termination, the TerminationID would be 2030 specific. For a Termination that does not yet exist, the 2031 TerminationID is specified as CHOOSE in the command. The new 2032 TerminationID will be returned. Wildcards may be used in an Add, 2033 but such usage would be unusual. If the wildcard matches more than 2034 one TerminationID, all possible matches are attempted, with results 2035 reported for each one. The order of attempts when multiple 2036 TerminationIDs match is not specified. 2038 The optional MediaDescriptor describes all media streams. 2040 The optional ModemDescriptor and MuxDescriptor specify a modem and 2041 multiplexer if applicable. For convenience, if a Multiplex 2043 Rosen et al Standards Track -- Expires Oct 2000 40 2044 Descriptor is present in an Add command and lists any Terminations 2045 that are not currently in the Context, such Terminations are added 2046 to the context as if individual Add commands listing the 2047 Terminations were invoked. If an error occurs on such an implied 2048 Add, error 471 - Implied Add for Multiplex failure shall be returned 2049 and further processing of the command shall cease. 2051 The EventsDescriptor parameter is optional. If present, it provides 2052 the list of events that should be detected on the Termination. 2054 The SignalsDescriptor parameter is optional. If present, it 2055 provides the list of signals that should be applied to the 2056 Termination. 2058 The DigitMapDescriptor parameter is optional. If present, defines a 2059 DigitMap definition that may be used in an EventsDescriptor. 2061 The AuditDescriptor is optional. If present, the command will 2062 return descriptors as specified in the AuditDescriptor. 2064 All descriptors that can be modified could be returned by MG if a 2065 parameter was underspecified or overspecified. ObservedEvents, 2066 Statistics, and Packages, and the EventBuffer Descriptors are 2067 returned only if requested in the AuditDescriptor. Add SHALL NOT be 2068 used on a Termination with a serviceState of "OutofService". 2070 7.2.2 Modify 2072 The Modify Command modifies the properties of a Termination. 2074 TerminationID 2075 [,MediaDescriptor] 2076 [,ModemDescriptor] 2077 [,MuxDescriptor] 2078 [,EventsDescriptor] 2079 [,SignalsDescriptor] 2080 [,DigitMapDescriptor] 2081 [,ObservedEventsDescriptor] 2082 [,EventBufferDescriptor] 2083 [,StatisticsDescriptor] 2084 [,PackagesDescriptor] 2085 Modify( TerminationID 2086 [, MediaDescriptor] 2087 [, ModemDescriptor] 2088 [, MuxDescriptor] 2089 [, EventsDescriptor] 2090 [, SignalsDescriptor] 2091 [, DigitMapDescriptor] 2092 [, AuditDescriptor] 2093 ) 2095 Rosen et al Standards Track -- Expires Oct 2000 41 2096 The TerminationID may be specific if a single Termination in the 2097 Context is to be modified. Use of wildcards in the TerminationID 2098 may be appropriate for some operations. If the wildcard matches more 2099 than one TerminationID, all possible matches are attempted, with 2100 results reported for each one. The order of attempts when multiple 2101 TerminationIDs match is not specified. The CHOOSE option is an 2102 error, as the Modify command may only be used on existing 2103 Terminations. 2105 The remaining parameters to Modify are the same as those to Add. 2106 Possible return values are the same as those to Add. 2108 7.2.3 Subtract 2110 The Subtract Command disconnects a Termination from its Context and 2111 returns statistics on the Termination's participation in the 2112 Context. 2114 TerminationID 2115 [,MediaDescriptor] 2116 [,ModemDescriptor] 2117 [,MuxDescriptor] 2118 [,EventsDescriptor] 2119 [,SignalsDescriptor] 2120 [,DigitMapDescriptor] 2121 [,ObservedEventsDescriptor] 2122 [,EventBufferDescriptor] 2123 [,StatisticsDescriptor] 2124 [,PackagesDescriptor] 2125 Subtract(TerminationID 2126 [, AuditDescriptor] 2127 ) 2129 TerminationID in the input parameters represents the Termination 2130 that is being subtracted. The TerminationID may be specific or may 2131 be a wildcard value indicating that all (or a set of related) 2132 Terminations in the Context of the Subtract Command are to be 2133 subtracted. If the wildcard matches more than one TerminationID, all 2134 possible matches are attempted, with results reported for each one. 2135 The order of attempts when multiple TerminationIDs match is not 2136 specified. The CHOOSE option is an error, as the Subtract command 2137 may only be used on existing Terminations. ALL may be used as the 2138 ContextID as well as the TerminationId in a Subtract, which would 2139 have the effect of deleting all contexts, deleting all ephemeral 2140 terminations, and returning all physical terminations to Null 2141 context. 2143 By default, the Statistics parameter is returned to report 2144 information collected on the Termination or Terminations specified 2145 in the Command. The information reported applies to the 2146 Termination's or Terminations' existence in the Context from which 2147 it or they are being subtracted. 2149 Rosen et al Standards Track -- Expires Oct 2000 42 2150 The AuditDescriptor is optional. If present, the command will 2151 return descriptors as specified in the AuditDescriptor. Possible 2152 return values are the same as those to Add. 2154 When a provisioned Termination is Subtracted from a context, its 2155 property values shall revert to: 2156 . the default value, if specified for the property and not 2157 overridden by provisioning, 2158 . otherwise, the provisioned value. 2160 7.2.4 Move 2162 The Move Command moves a Termination to another Context from its 2163 current Context in one atomic operation. The Move command is the 2164 only command that refers to a Termination in a Context different 2165 from that to which the command is applied. The Move command shall 2166 not be used to move Terminations to or from the null Context. 2168 TerminationID 2169 [,MediaDescriptor] 2170 [,ModemDescriptor] 2171 [,MuxDescriptor] 2172 [,EventsDescriptor] 2173 [,SignalsDescriptor] 2174 [,DigitMapDescriptor] 2175 [,ObservedEventsDescriptor] 2176 [,EventBufferDescriptor] 2177 [,StatisticsDescriptor] 2178 [,PackagesDescriptor] 2179 Move( TerminationID 2180 [, MediaDescriptor] 2181 [, ModemDescriptor] 2182 [, MuxDescriptor] 2183 [, EventsDescriptor] 2184 [, SignalsDescriptor] 2185 [, DigitMapDescriptor] 2186 [, AuditDescriptor] 2187 ) 2189 The TerminationID specifies the Termination to be moved. It may be 2190 wildcarded. If the wildcard matches more than one TerminationID, 2191 all possible matches are attempted, with results reported for each 2192 one. The order of attempts when multiple TerminationIDs match is 2193 not specified. By convention, the Termination is subtracted from its 2194 previous Context. The Context to which the Termination is moved is 2195 indicated by the target ContextId in the Action. If the last 2196 remaining Termination is moved out of a Context, the Context is 2197 deleted. 2199 The remaining descriptors are processed as in the Modify Command. 2200 The AuditDescriptor with the Statistics option, for example, would 2202 Rosen et al Standards Track -- Expires Oct 2000 43 2203 return statistics on the Termination just prior to the Move. 2204 Possible descriptors returned from Move are the same as for Add. 2205 Move SHALL NOT be used on a Termination with a serviceState of 2206 "OutofService". 2208 7.2.5 AuditValue 2210 The AuditValue Command returns the current values of properties, 2211 events, signals and statistics associated with Terminations. 2213 TerminationID 2214 [,MediaDescriptor] 2215 [,ModemDescriptor] 2216 [,MuxDescriptor] 2217 [,EventsDescriptor] 2218 [,SignalsDescriptor] 2219 [,DigitMapDescriptor] 2220 [,ObservedEventsDescriptor] 2221 [,EventBufferDescriptor] 2222 [,StatisticsDescriptor] 2223 [,PackagesDescriptor] 2224 AuditValue(TerminationID, 2225 AuditDescriptor 2226 ) 2228 TerminationID may be specific or wildcarded. If the wildcard matches 2229 more than one TerminationID, all possible matches are attempted, 2230 with results reported for each one. The order of attempts when 2231 multiple TerminationIDs match is not specified. If a wildcarded 2232 response is requested, only one command return is generated, with 2233 the contents containing the union of the values of all Terminations 2234 matching the wildcard. This convention may reduce the volume of 2235 data required to audit a group of Terminations. Use of CHOOSE is an 2236 error. 2238 The appropriate descriptors, with the current values for the 2239 Termination, are returned from AuditValue. Values appearing in 2240 multiple instances of a descriptor are defined to be alternate 2241 values supported, with each parameter in a descriptor considered 2242 independent. 2244 ObservedEvents returns a list of events in the EventBuffer, 2245 PackagesDescriptor returns a list of packages realized by the 2246 Termination. DigitMapDescriptor returns the name or value of the 2247 current DigitMap for the Termination. DigitMap requested in an 2248 AuditValue command with TerminationID ALL returns all DigitMaps in 2249 the gateway. Statistics returns the current values of all 2250 statistics being kept on the Termination. Specifying an empty Audit 2251 Descriptor results in only the TerminationID being returned. This 2252 may be useful to get a list of TerminationIDs when used with 2253 wildcard. 2255 Rosen et al Standards Track -- Expires Oct 2000 44 2256 AuditValue results depend on the Context, viz. specific, null, or 2257 wildcarded. The TerminationID may be specific, or wildcarded. 2258 The following illustrates other information that can be obtained 2259 with the Audit Command: 2261 ContextID TerminationID Information Obtained 2263 Specific wildcard Audit of matching 2264 Terminations in a Context 2266 Specific specific Audit of a single 2267 Termination in a Context 2269 Null Root Audit of Media Gateway state 2270 and events 2272 Null wildcard Audit of all matching 2273 Terminations in the Null 2274 Context 2276 Null specific Audit of a single 2277 Termination outside of any 2278 Context 2280 All wildcard Audit of all matching 2281 Terminations and the Context 2282 to which they are associated 2284 All Root List of all ContextIds 2285 7.2.6 AuditCapabilities 2287 The AuditCapabilities Command returns the possible values of 2288 properties, events, signals and statistics associated with 2289 Terminations. 2291 TerminationID 2292 [,MediaDescriptor] 2293 [,ModemDescriptor] 2294 [,MuxDescriptor] 2295 [,EventsDescriptor] 2296 [,SignalsDescriptor] 2297 [,ObservedEventsDescriptor] 2298 [,EventBufferDescriptor] 2299 [,StatisticsDescriptor] 2300 AuditCapabilities(TerminationID, 2301 AuditDescriptor 2302 ) 2304 The appropriate descriptors, with the possible values for the 2305 Termination are returned from AuditCapabilities. Descriptors may be 2307 Rosen et al Standards Track -- Expires Oct 2000 45 2308 repeated where there are multiple possible values. If a wildcarded 2309 response is requested, only one command return is generated, with 2310 the contents containing the union of the values of all Terminations 2311 matching the wildcard. This convention may reduce the volume of 2312 data required to audit a group of Terminations. 2314 Interpretation of what capabilities are requested for various values 2315 of ContextID and TerminationID is the same as in AuditValue. 2317 The EventsDescriptor returns the list of possible events on the 2318 Termination together with the list of all possible values for the 2319 EventsDescriptor Parameters. The SignalsDescriptor returns the list 2320 of possible signals that could be applied to the Termination 2321 together with the list of all possible values for the Signals 2322 Parameters. StatisticsDescriptor returns the names of the 2323 statistics being kept on the termination. ObservedEventsDescriptor 2324 returns the names of active events on the termination. DigitMap and 2325 Packages are not legal in AuditCapability. 2327 7.2.7 Notify 2329 The Notify Command allows the Media Gateway to notify the Media 2330 Gateway Controller of events occurring within the Media Gateway. 2332 Notify(TerminationID, 2333 ObservedEventsDescriptor, 2334 [ErrorDescriptor] 2335 ) 2337 The TerminationID parameter specifies the Termination issuing the 2338 Notify Command. The TerminationID shall be a fully qualified name. 2340 The ObservedEventsDescriptor contains the RequestID and a list of 2341 events that the Media Gateway detected in the order that they were 2342 detected. Each event in the list is accompanied by parameters 2343 associated with the event and an indication of the time that the 2344 event was detected. Procedures for sending Notify commands with 2345 RequestID equal to 0 are for further study. 2347 Notify Commands with RequestID not equal to 0 shall occur only as 2348 the result of detection of an event specified by an Events 2349 Descriptor which is active on the termination concerned. 2351 The RequestID returns the RequestID parameter of the 2352 EventsDescriptor that triggered the Notify Command. It is used to 2353 correlate the notification with the request that triggered it. The 2354 events in the list must have been requested via the triggering 2355 EventsDescriptor or embedded events descriptor unless the RequestID 2356 is 0 (which is for further study). 2358 7.2.8 ServiceChange 2360 Rosen et al Standards Track -- Expires Oct 2000 46 2361 The ServiceChange Command allows the Media Gateway to notify the 2362 Media Gateway Controller that a Termination or group of Terminations 2363 is about to be taken out of service or has just been returned to 2364 service. The Media Gateway Controller may indicate that 2365 Termination(s) shall be taken out of or returned to service. The 2366 Media Gateway may notify the MGC that the capability of a 2367 Termination has changed. It also allows a MGC to hand over control 2368 of a MG to another MGC. 2370 TerminationID, 2371 [ServiceChangeDescriptor] 2372 ServiceChange(TerminationID, 2373 ServiceChangeDescriptor 2374 ) 2376 The TerminationID parameter specifies the Termination(s) that are 2377 taken out of or returned to service. Wildcarding of Termination 2378 names is permitted, with the exception that the CHOOSE mechanism 2379 shall not be used. Use of the "Root" TerminationID indicates a 2380 ServiceChange affecting the entire Media Gateway. 2382 The ServiceChangeDescriptor contains the following parameters as 2383 required: 2384 . ServiceChangeMethod 2385 . ServiceChangeReason 2386 . ServiceChangeDelay 2387 . ServiceChangeAddress 2388 . ServiceChangeProfile 2389 . ServiceChangeVersion 2390 . ServiceChangeMgcId 2391 . TimeStamp 2393 The ServiceChangeMethod parameter specifies the type of 2394 ServiceChange that will or has occurred: 2396 1) Graceful - indicates that the specified Terminations will be 2397 taken out of service after the specified ServiceChangeDelay; 2398 established connections are not yet affected, but the Media 2399 Gateway Controller should refrain from establishing new 2400 connections and should attempt to gracefully tear down existing 2401 connections. The MG should set termination serviceState at the 2402 expiry of ServiceChangeDelay or the removal of the termination 2403 from an active context (whichever is first), to "out of service". 2405 2) Forced - indicates that the specified Terminations were taken 2406 abruptly out of service and any established connections 2407 associated with them were lost. The MGC is responsible for 2408 cleaning up the context (if any) with which the failed 2409 termination is associated. At a minimum the termination shall be 2410 subtracted from the context. The termination serviceState should 2411 be "out of service". 2413 Rosen et al Standards Track -- Expires Oct 2000 47 2414 3) Restart - indicates that service will be restored on the 2415 specified Terminations after expiration of the 2416 ServiceChangeDelay. The serviceState should be set to 2417 "inService" upon expiry of ServiceChangeDelay. 2419 4) Disconnected - always applied with the Root TerminationID, 2420 indicates that the MG lost communication with the MGC, but it was 2421 subsequently restored. Since MG state may have changed, the MGC 2422 may wish to use the Audit command to resynchronize its state with 2423 the MG's. 2425 5) Handoff - sent from the MGC to the MG, this reason indicates that 2426 the MGC is going out of service and a new MGC association must be 2427 established. Sent from the MG to the MGC, this indicates that the 2428 MG is attempting to establish a new association in accordance 2429 with a Handoff received from the MGC with which it was previously 2430 associated. 2432 6) Failover - sent from MG to MGC to indicate the primary MG is out 2433 of service and a secondary MG is taking over. 2435 7) Another value whose meaning is mutually understood between the MG 2436 and the MGC. 2438 The ServiceChangeReason parameter specifies the reason why the 2439 ServiceChange has or will occur. It consists of an alphanumeric 2440 token (IANA registered) and an explanatory string. 2442 The optional ServiceChangeAddress parameter specifies the address 2443 (e.g., IP port number for IP networks) to be used for subsequent 2444 communications. It can be specified in the input parameter 2445 descriptor or the returned result descriptor. ServiceChangeAddress 2446 and ServiceChangeMgcId parameters must not both be present in the 2447 ServiceChangeDescriptor or the ServiceChangeResultDescriptor. The 2448 serviceChangeAddress provides an address to be used within the 2449 context of the association currently being negotiated, while the 2450 ServiceChangeMgcId provides an alternate address where the MG should 2451 seek to establish another association. 2453 The optional ServiceChangeDelay parameter is expressed in seconds. 2454 If the delay is absent or set to zero, the delay value should be 2455 considered to be null. In the case of a "graceful" 2456 ServiceChangeMethod, a null delay indicates that the Media Gateway 2457 Controller should wait for the natural removal of existing 2458 connections and should not establish new connections. . For 2459 "graceful" only, a null delay means the MG must not set serviceState 2460 "out of service" until the termination is in the null context. 2462 The optional ServiceChangeProfile parameter specifies the Profile 2463 (if any) of the protocol supported. The ServiceChangeProfile 2464 includes the version of the profile supported. 2466 Rosen et al Standards Track -- Expires Oct 2000 48 2467 The optional ServiceChangeVersion parameter contains the protocol 2468 version and is used if protocol version negotiation occurs (see 2469 section 11.3). 2471 The optional TimeStamp parameter specifies the actual time as kept 2472 by the sender. It can be used by the responder to determine how its 2473 notion of time differs from that of its correspondent. TimeStamp is 2474 sent with a precision of hundredths of a second, and is expressed in 2475 UTC. 2477 The optional Extension parameter may contain any value whose meaning 2478 is mutually understood by the MG and MGC. 2480 A ServiceChange Command specifying the "Root" for the TerminationID 2481 and ServiceChangeMethod equal to Restart is a registration command 2482 by which a Media Gateway announces its existence to the Media 2483 Gateway Controller. The Media Gateway is expected to be provisioned 2484 with the name of one primary and optionally some number of alternate 2485 Media Gateway Controllers. Acknowledgement of the ServiceChange 2486 Command completes the registration process. The MG may specify the 2487 transport ServiceChangeAddress to be used by the MGC for sending 2488 messages in the ServiceChangeAddress parameter in the input 2489 ServiceChangeDescriptor. The MG may specify an address in the 2490 ServiceChangeAddress parameter of the ServiceChange request, and the 2491 MGC may also do so in the ServiceChange reply. In either case, the 2492 recipient must use the supplied address as the destination for all 2493 subsequent transaction requests within the association. At the same 2494 time, as indicated in section 9, transaction replies and pending 2495 indications must be sent to the address from which the corresponding 2496 rquests originated. This must be done even if it implies extra 2497 messaging because commands and responses cannot be packed together. 2498 The TimeStamp parameter shall be sent with a registration command 2499 and its response. 2501 The Media Gateway Controller may return an ServiceChangeMgcId 2502 parameter that describes the Media Gateway Controller that should 2503 preferably be contacted for further service by the Media Gateway. 2504 In this case the Media Gateway shall reissue the ServiceChange 2505 command to the new Media Gateway Controller. The Gateway specified 2506 in an ServiceChangeMgcId, if provided, shall be contacted before any 2507 further alternate MGCs. On a HandOff message from MGC to MG, the 2508 ServiceChangeMgcId is the new MGC that will take over from the 2509 current MGC. 2511 The return from ServiceChange is empty except when the Root 2512 terminationID is used. In that case it includes the following 2513 parameters as required: 2514 . ServiceChangeAddress, if the responding MGC wishes to specify an 2515 new destination for messages from the MG for the remainder of the 2516 association; 2518 Rosen et al Standards Track -- Expires Oct 2000 49 2519 . ServiceChangeMgcId, if the responding MGC does not wish to sustain 2520 an association with the MG; 2522 . ServiceChangeProfile, if the responder wishes to negotiate the 2523 profile to be used for the association; 2525 . ServiceChangeVersion, if the responder wishes to negotiate the 2526 version of the protocol to be used for the association. 2528 The following ServiceChangeReasons are defined. This list may be 2529 extended by an IANA registration as outlined in section 13.3 2530 900 Service Restored 2531 901 Cold Boot 2532 902 Warm Boot 2533 903 MGC Directed Change 2534 904 Termination malfunctioning 2535 905 Termination taken out of service 2536 906 Loss of lower layer connectivity (e.g. downstream sync) 2537 907 Transmission Failure 2538 908 MG Impending Failure 2539 909 MGC Impending Failure 2540 910 Media Capability Failure 2541 911 Modem Capability Failure 2542 912 Mux Capability Failure 2543 913 Signal Capability Failure 2544 914 Event Capability Failure 2545 915 State Loss 2547 7.2.9 Manipulating and Auditing Context Attributes 2549 The commands of the protocol as discussed in the preceding sections 2550 apply to terminations. This section specifies how contexts are 2551 manipulated and audited. 2553 Commands are grouped into actions (see section 8). An action 2554 applies to one context. In addition to commands, an action may 2555 contain context manipulation and auditing instructions. 2557 An action request sent to a MG may include a request to audit 2558 attributes of a context. An action may also include a request to 2559 change the attributes of a context. 2561 The context properties that may be included in an action reply are 2562 used to return information to a MGC. This can be information 2563 requested by an audit of context attributes or details of the effect 2564 of manipulation of a context. 2566 If a MG receives an action which contains both a request to audit 2567 context attributes and a request to manipulate those attributes, the 2568 response SHALL include the values of the attributes after processing 2569 the manipulation request. 2571 Rosen et al Standards Track -- Expires Oct 2000 50 2572 7.2.10 Generic Command Syntax 2574 The protocol can be encoded in a binary format or in a text format. 2575 MGCs should support both encoding formats. MGs may support both 2576 formats. 2578 The protocol syntax for the binary format of the protocol is defined 2579 in Annex A. Annex C specifies the encoding of the Local and Remote 2580 descriptors for use with the binary format. 2582 A complete ABNF of the text encoding of the protocol per RFC2234 is 2583 given in Annex B. SDP is used as the encoding of the Local and 2584 Remote Descriptors for use with the text encoding as modified in 2585 section 7.1.8. 2587 7.3 Command Error Codes 2589 Errors consist of an IANA registered error code and an explanatory 2590 string. Sending the explanatory string is optional. 2591 Implementations are encouraged to append diagnostic information to 2592 the end of the string. 2594 When a MG reports an error to a MGC, it does so in an error 2595 descriptor. An error descriptor consists of an error code and 2596 optionally the associated explanatory string. 2598 The identified error codes are: 2599 400 - Bad Request 2600 401 - Protocol Error 2601 402 - Unauthorized 2602 403 - Syntax Error in Transaction 2603 404 - Syntax Error in TransactionReply 2604 405 - Syntax Error in TransactionPending 2605 406 - Version Not Supported 2606 410 - Incorrect identifier 2607 411 - The transaction refers to an unknown ContextId 2608 412 - No ContextIDs available 2610 421 - Unknown action or illegal combination of actions 2611 422 - Syntax Error in Action 2612 430 - Unknown TerminationID 2613 431 - No TerminationID matched a wildcard 2614 432 - Out of TerminationIDs or No TerminationID available 2615 433 - TerminationID is already in a Context 2616 440 - Unsupported or unknown Package 2617 441 - Missing RemoteDescriptor 2618 442 - Syntax Error in Command 2619 443 - Unsupported or Unknown Command 2620 444 - Unsupported or Unknown Descriptor 2621 445 - Unsupported or Unknown Property 2622 446 - Unsupported or Unknown Parameter 2623 447 - Descriptor not legal in this command 2625 Rosen et al Standards Track -- Expires Oct 2000 51 2626 448 - Descriptor appears twice in a command 2627 450 - No such property in this package 2628 451 - No such event in this package 2629 452 - No such signal in this package 2630 453 - No such statistic in this package 2631 454 - No such parameter value in this package 2632 455 - Parameter illegal in this Descriptor 2633 456 - Parameter or Property appears twice in this Descriptor 2634 461 - TransactionIDs in Reply do not match Request 2635 462 - Commands in Transaction Reply do not match commands in 2636 request 2637 463 - TerminationID of Transaction Reply does not match 2638 request 2639 464 - Missing reply in Transaction Reply 2640 465 - TransactionID in Transaction Pending does not match any 2641 open request 2642 466 - Illegal Duplicate Transaction Request 2643 467 - Illegal Duplicate Transaction Reply 2644 471 - Implied Add for Multiplex failure 2646 500 - Internal Gateway Error 2647 501 - Not Implemented 2648 502 - Not ready. 2649 503 - Service Unavailable 2650 504 - Command Received from unauthorized entity 2651 505 - Command Received before Restart Response 2652 510 - Insufficient resources 2653 512 - Media Gateway unequipped to detect requested Event 2654 513 - Media Gateway unequipped to generate requested Signals 2655 514 - Media Gateway cannot send the specified announcement 2656 515 - Unsupported Media Type 2657 517 - Unsupported or invalid mode 2658 518 - Event buffer full 2659 519 - Out of space to store digit map 2660 520 - Media Gateway does not have a digit map 2661 521 - Termination is "ServiceChangeing" 2662 526 - Insufficient bandwidth 2663 529 - Internal hardware failure 2664 530 - Temporary Network failure 2665 531 - Permanent Network failure 2666 581 - Does Not Exist 2668 Rosen et al Standards Track -- Expires Oct 2000 52 2669 8. TRANSACTIONS 2671 Commands between the Media Gateway Controller and the Media Gateway 2672 are grouped into Transactions, each of which is identified by a 2673 TransactionID. Transactions consist of one or more Actions. An 2674 Action consists of a series of Commands that are limited to 2675 operating within a single Context. Consequently each Action 2676 typically specifies a ContextID. However, there are two 2677 circumstances where a specific ContextID is not provided with an 2678 Action. One is the case of modification of a Termination outside of 2679 a Context. The other is where the controller requests the gateway 2680 to create a new Context. Following is a graphic representation of 2681 the Transaction, Action and Command relationships. 2683 +----------------------------------------------------------+ 2684 | Transaction x | 2685 | +----------------------------------------------------+ | 2686 | | Action 1 | | 2687 | | +---------+ +---------+ +---------+ +---------+ | | 2688 | | | Command | | Command | | Command | | Command | | | 2689 | | | 1 | | 2 | | 3 | | 4 | | | 2690 | | +---------+ +---------+ +---------+ +---------+ | | 2691 | +----------------------------------------------------+ | 2692 | | 2693 | +----------------------------------------------------+ | 2694 | | Action 2 | | 2695 | | +---------+ | | 2696 | | | Command | | | 2697 | | | 1 | | | 2698 | | +---------+ | | 2699 | +----------------------------------------------------+ | 2700 | | 2701 | +----------------------------------------------------+ | 2702 | | Action 3 | | 2703 | | +---------+ +---------+ +---------+ | | 2704 | | | Command | | Command | | Command | | | 2705 | | | 1 | | 2 | | 3 | | | 2706 | | +---------+ +---------+ +---------+ | | 2707 | +----------------------------------------------------+ | 2708 +----------------------------------------------------------+ 2710 Figure 5 Transactions, Actions and Commands 2712 Transactions are presented as TransactionRequests. Corresponding 2713 responses to a TransactionRequest are received in a single reply, 2714 possibly preceded by a number of TransactionPending messages (see 2715 section 8.2.3). 2717 Transactions guarantee ordered Command processing. That is, 2718 Commands within a Transaction are executed sequentially. Ordering of 2719 Transactions is NOT guaranteed - transactions may be executed in any 2720 order, or simultaneously. 2722 Rosen et al Standards Track -- Expires Oct 2000 53 2723 At the first failing Command in a Transaction, processing of the 2724 remaining Commands in that Transaction stops. If a command contains 2725 a wildcarded TerminationID, the command is attempted with each of 2726 the actual TerminationIDs matching the wildcard. A response within 2727 the TransactionReply is included for each matching TerminationID, 2728 even if one or more instances generated an error. If any 2729 TerminationID matching a wildcard results in an error when executed, 2730 any commands following the wildcarded command are not attempted. 2731 Commands may be marked as "Optional" which can override this 2732 behaviour - if a command marked as Optional results in an error, 2733 subsequent commands in the Transaction will be executed. 2734 A TransactionReply includes the results for all of the Commands in 2735 the corresponding TransactionRequest. The TransactionReply includes 2736 the return values for the Commands that were executed successfully, 2737 and the Command and error descriptor for any Command that failed. 2738 TransactionPending is used to periodically notify the receiver that 2739 a Transaction has not completed yet, but is actively being 2740 processed. 2742 Applications SHOULD implement an application level timer per 2743 transaction. Expiration of the timer should cause a retransmission 2744 of the request. Receipt of a Reply should cancel the timer. 2745 Receipt of Pending should restart the timer. 2747 8.1 Common Parameters 2749 8.1.1 Transaction Identifiers 2751 Transactions are identified by a TransactionID, which is assigned by 2752 sender and is unique within the scope of the sender. 2754 8.1.2 Context Identifiers 2756 Contexts are identified by a ContextID, which is assigned by the 2757 Media Gateway and is unique within the scope of the Media Gateway. 2758 The Media Gateway Controller shall use the ContextID supplied by the 2759 Media Gateway in all subsequent Transactions relating to that 2760 Context. The protocol makes reference to a distinguished value that 2761 may be used by the Media Gateway Controller when referring to a 2762 Termination that is currently not associated with a Context, namely 2763 the null ContextID. 2765 The CHOOSE wildcard is used to request that the Media Gateway create 2766 a new Context. The MGC shall not use partially specified ContextIDs 2767 containing the CHOOSE wildcard. 2769 The MGC may use the ALL wildcard to address all Contexts on the MG. 2771 Rosen et al Standards Track -- Expires Oct 2000 54 2772 8.2 Transaction Application Programming Interface 2774 Following is an Application Programming Interface (API) describing 2775 the Transactions of the protocol. This API is shown to illustrate 2776 the Transactions and their parameters and is not intended to specify 2777 implementation (e.g. via use of blocking function calls). It will 2778 describe the input parameters and return values expected to be used 2779 by the various Transactions of the protocol from a very high level. 2780 Transaction syntax and encodings are specified in later subsections. 2782 8.2.1 TransactionRequest 2784 The TransactionRequest is invoked by the sender. There is one 2785 Transaction per request invocation. A request contains one or more 2786 Actions, each of which specifies its target Context and one or more 2787 Commands per Context. 2789 TransactionRequest(TransactionId { 2790 ContextID {Command _ Command}, 2791 . . . 2792 ContextID {Command _ Command } }) 2794 The TransactionID parameter must specify a value for later 2795 correlation with the TransactionReply or TransactionPending response 2796 from the receiver. 2798 The ContextID parameter must specify a value to pertain to all 2799 Commands that follow up to either the next specification of a 2800 ContextID parameter or the end of the TransactionRequest, whichever 2801 comes first. 2803 The Command parameter represents one of the Commands mentioned in 2804 the "Command Details" subsection titled "Application Programming 2805 Interface". 2807 8.2.2 TransactionReply 2809 The TransactionReply is invoked by the receiver. There is one reply 2810 invocation per transaction. A reply contains one or more Actions, 2811 each of which must specify its target Context and one or more 2812 Responses per Context. 2814 TransactionReply(TransactionID { 2815 ContextID { Response _ Response }, 2816 . . . 2817 ContextID { Response _ Response } }) 2819 The TransactionID parameter must be the same as that of the 2820 corresponding TransactionRequest. 2822 The ContextID parameter must specify a value to pertain to all 2823 Responses for the action. The ContextID may be specific or null. 2825 Rosen et al Standards Track -- Expires Oct 2000 55 2826 Each of the Response parameters represents a return value as 2827 mentioned in section 7.2, or an error descriptor if the command 2828 execution encountered an error. Commands after the point of failure 2829 are not processed and, therefore, Responses are not issued for them. 2831 An exception to this occurs if a command has been marked as optional 2832 in the Transaction request. If the optional command generates an 2833 error, the transaction still continues to execute, so the Reply 2834 would, in this case, have Responses after an Error. 2836 If the receiver encounters an error in processing a ContextID, the 2837 requested Action response will consist of the context ID and a 2838 single error descriptor, 422 Syntax Error in Action. 2840 If the receiver encounters an error such that it cannot determine a 2841 legal Action, it will return a TransactionReply consisting of the 2842 TransactionID and a single error descriptor, 422 Syntax Error in 2843 Action. If the end of an action cannot be reliably determined but 2844 one or more Actions can be parsed, it will process them and then 2845 send 422 Syntax Error in Action as the last action for the 2846 transaction. If the receiver encounters an error such that is 2847 cannot determine a legal Transaction, it will return a 2848 TransactionReply with a null TransactionID and a single error 2849 descriptor (403 Syntax Error in Transaction). 2851 If the end of a transaction can not be reliably determined and one 2852 or more Actions can be parsed, it will process them and then return 2853 403 Syntax Error in Transaction as the last action reply for the 2854 transaction. If no Actions can be parsed, it will return 403 Syntax 2855 Error in Transaction as the only reply 2857 If the terminationID cannot be reliably determined it will send 442 2858 Syntax Error in Command as the action reply. 2860 If the end of a command cannot be reliably determined it will return 2861 442 Syntax Error in Transaction as the reply to the last action it 2862 can parse. 2864 8.2.3 TransactionPending 2866 The receiver invokes the TransactionPending. A TransactionPending 2867 indicates that the Transaction is actively being processed, but has 2868 not been completed. It is used to prevent the sender from assuming 2869 the TransactionRequest was lost where the Transaction will take some 2870 time to complete. 2872 TransactionPending(TransactionID { } ) 2874 The TransactionID parameter must be the same as that of the 2875 corresponding TransactionRequest. A property of root 2876 (normalMGExecutionTime) is settable by the MGC to indicate the 2878 Rosen et al Standards Track -- Expires Oct 2000 56 2879 interval within which the MGC expects a response to any transaction 2880 from the MG. Another property (normalMGCExecutionTime) is settable 2881 by the MGC to indicate the interval within which the MG should 2882 expects a response to any transaction from the MGC. Senders may 2883 receive more than one TransactionPending for a command. If a 2884 duplicate request is received when pending, the responder may send a 2885 duplicate pending immediately, or continue waiting for its timer to 2886 trigger another Transaction Pending. 2888 8.3 Messages 2890 Multiple Transactions can be concatenated into a Message. Messages 2891 have a header, which includes the identity of the sender. The 2892 Message Identifier (MID) of a message is set to a provisioned name 2893 (e.g. domain address/domain name/device name) of the entity 2894 transmitting the message. Domain name is a suggested default. 2896 Every Message contains a Version Number identifying the version of 2897 the protocol the message conforms to. Versions consist of one or 2898 two digits, beginning with version 1 for the present version of the 2899 protocol. 2901 The transactions in a message are treated independently. There is 2902 no order implied, there is no application or protocol 2903 acknowledgement of a message. 2905 9. TRANSPORT 2907 The transport mechanism for the protocol should allow the reliable 2908 transport of transactions between an MGC and MG. The transport shall 2909 remain independent of what particular commands are being sent and 2910 shall be applicable to all application states. There are several 2911 transports defined for the protocol, which are defined in normative 2912 Annexes to this document. Additional Transports may be defined as 2913 additional annexes in subsequent editions of this document, or in 2914 separate documents. For transport of the protocol over IP, MGCs 2915 shall implement both TCP and UDP/ALF, an MG shall implement TCP or 2916 UDP/ALF or both. 2918 The MG is provisioned with a name or address (such as DNS name or IP 2919 address) of a primary and zero or more secondary MGCs (see section 2920 7.2.8) that is the address the MG uses to send messages to the MGC. 2921 If TCP or UDP is used as the protocol transport and the port to 2922 which the initial ServiceChange request is to be sent is not 2923 otherwise known, that request should be sent to the default port 2924 number for the protocol. This port number is 2944 for text-encoded 2925 operation or 2945 for binary-encoded operation, for either UDP or 2926 TCP. The MGC receives the message containing the ServiceChange 2927 request from the MG and can determine the MG's address from it. As 2928 described in section 7.2.8, either the MG or the MGC may supply an 2929 address in the ServiceChangeAddress parameter to which subsequent 2931 Rosen et al Standards Track -- Expires Oct 2000 57 2932 transaction requests must be addressed, but responses (including the 2933 response to the initial ServiceChange request) must always be sent 2934 back to the address which was the source of the corresponding 2935 request. 2937 9.1 Ordering of Commands 2939 This document does not mandate that the underlying transport 2940 protocol guarantees the sequencing of transactions sent to an 2941 entity. This property tends to maximize the timeliness of actions, 2942 but it has a few drawbacks. For example: 2943 . Notify commands may be delayed and arrive at the MGC after the 2944 transmission of a new command changing the EventsDescriptor 2946 . If a new command is transmitted before a previous one is 2947 acknowledged, there is no guarantee that prior command will be 2948 executed before the new one. 2950 Media Gateway Controllers that want to guarantee consistent 2951 operation of the Media Gateway may use the following rules. These 2952 rules are with respect to commands that are in different 2953 transactions. Commands that are in the same transaction are 2954 executed in order (see section 8). 2956 1. When a Media Gateway handles several Terminations, commands 2957 pertaining to the different Terminations may be sent in parallel, 2958 for example following a model where each Termination (or group of 2959 Terminations) is controlled by its own process or its own thread. 2961 2. On a Termination, there should normally be at most one 2962 outstanding command (Add or Modify or Move), unless the 2963 outstanding commands are in the same transaction. However, a 2964 Subtract command may be issued at any time. In consequence, a 2965 Media Gateway may sometimes receive a Modify command that applies 2966 to a previously subtracted Termination. Such commands should be 2967 ignored, and an error code should be returned. 2969 3. On a given Termination, there should normally be at most one 2970 outstanding Notify command at any time. 2972 4. In some cases, an implicitly or explicitly wildcarded Subtract 2973 command that applies to a group of Terminations may step in front 2974 of a pending Add command. The Media Gateway Controller should 2975 individually delete all Terminations for which an Add command was 2976 pending at the time of the global Subtract command. Also, new 2977 Add commands for Terminations named by the wild-carding (or 2978 implied in a Multiplex descriptor) should not be sent until the 2979 wild-carded Subtract command is acknowledged. 2981 5. AuditValue and AuditCapability are not subject to any sequencing. 2983 Rosen et al Standards Track -- Expires Oct 2000 58 2984 6. ServiceChange shall always be the first command sent by a MG as 2985 defined by the restart procedure. Any other command or response 2986 must be delivered after this ServiceChange command. 2988 These rules do not affect the command responder, which should always 2989 respond to commands. 2991 9.2 Protection against Restart Avalanche 2993 In the event that a large number of Media Gateways are powered on 2994 simultaneously and they were to all initiate a ServiceChange 2995 transaction, the Media Gateway Controller would very likely be 2996 swamped, leading to message losses and network congestion during the 2997 critical period of service restoration. In order to prevent such 2998 avalanches, the following behavior is suggested: 3000 1. When a Media Gateway is powered on, it should initiate a restart 3001 timer to a random value, uniformly distributed between 0 and a 3002 maximum waiting delay (MWD). Care should be taken to avoid 3003 synchronicity of the random number generation between multiple 3004 Media Gateways that would use the same algorithm. 3006 2. The Media Gateway should then wait for either the end of this 3007 timer or the detection of a local user activity, such as for 3008 example an off-hook transition on a residential Media Gateway. 3010 3. When the timer elapses, or when an activity is detected, the 3011 Media Gateway should initiate the restart procedure. 3013 The restart procedure simply requires the MG to guarantee that the 3014 first message that the Media Gateway Controller sees from this MG is 3015 a ServiceChange message informing the Media Gateway Controller about 3016 the restart. 3018 Note - The value of MWD is a configuration parameter that depends 3019 on the type of the Media Gateway. The following reasoning may be 3020 used to determine the value of this delay on residential gateways. 3022 Media Gateway Controllers are typically dimensioned to handle the 3023 peak hour traffic load, during which, in average, 10% of the lines 3024 will be busy, placing calls whose average duration is typically 3 3025 minutes. The processing of a call typically involves 5 to 6 Media 3026 Gateway Controller transactions between each Media Gateway and the 3027 Media Gateway Controller. This simple calculation shows that the 3028 Media Gateway Controller is expected to handle 5 to 6 transactions 3029 for each Termination, every 30 minutes on average, or, to put it 3030 otherwise, about one transaction per Termination every 5 to 6 3031 minutes on average. This suggests that a reasonable value of MWD 3032 for a residential gateway would be 10 to 12 minutes. In the absence 3033 of explicit configuration, residential gateways should adopt a value 3034 of 600 seconds for MWD. 3036 Rosen et al Standards Track -- Expires Oct 2000 59 3037 The same reasoning suggests that the value of MWD should be much 3038 shorter for trunking gateways or for business gateways, because they 3039 handle a large number of Terminations, and also because the usage 3040 rate of these Terminations is much higher than 10% during the peak 3041 busy hour, a typical value being 60%. These Terminations, during 3042 the peak hour, are this expected to contribute about one transaction 3043 per minute to the Media Gateway Controller load. A reasonable 3044 algorithm is to make the value of MWD per "trunk" Termination six 3045 times shorter than the MWD per residential gateway, and also 3046 inversely proportional to the number of Terminations that are being 3047 restarted. For example MWD should be set to 2.5 seconds for a 3048 gateway that handles a T1 line, or to 60 milliseconds for a gateway 3049 that handles a T3 line. 3051 10. SECURITY CONSIDERATIONS 3053 This section covers security when using the protocol in an IP 3054 environment. 3056 10.1 Protection of Protocol Connections 3058 A security mechanism is clearly needed to prevent unauthorized 3059 entities from using the protocol defined in this document for 3060 setting up unauthorized calls or interfering with authorized calls. 3061 The security mechanism for the protocol when transported over IP 3062 networks is IPsec [RFC2401 to RFC2411]. 3064 The AH header [RFC2402] affords data origin authentication, 3065 connectionless integrity and optional anti-replay protection of 3066 messages passed between the MG and the MGC. The ESP header [RFC2406] 3067 provides confidentiality of messages, if desired. For instance, the 3068 ESP encryption service should be requested if the session 3069 descriptions are used to carry session keys, as defined in SDP. 3071 Implementations of the protocol defined in this document employing 3072 the ESP header SHALL comply with section 5 of [RFC2406], which 3073 defines a minimum set of algorithms for integrity checking and 3074 encryption. Similarly, implementations employing the AH header SHALL 3075 comply with section 5 of [RFC2402], which defines a minimum set of 3076 algorithms for integrity checking using manual keys. 3078 Implementations SHOULD use IKE [RFC2409] to permit more robust 3079 keying options. Implementations employing IKE SHOULD support 3080 authentication with RSA signatures and RSA public key encryption. 3082 10.2 Interim AH scheme 3084 Implementation of IPsec requires that the AH or ESP header be 3085 inserted immediately after the IP header. This cannot be easily done 3086 at the application level. Therefore, this presents a deployment 3088 Rosen et al Standards Track -- Expires Oct 2000 60 3089 problem for the protocol defined in this document where the 3090 underlying network implementation does not support IPsec. 3092 As an interim solution, an optional AH header is defined within the 3093 H.248 protocol header. The header fields are exactly those of the 3094 SPI, SEQUENCE NUMBER and DATA fields as defined in [RFC2402]. The 3095 semantics of the header fields are the same as the "transport mode" 3096 of [RFC2402], except for the calculation of the Integrity Check 3097 value (ICV). In IPsec, the ICV is calculated over the entire IP 3098 packet including the IP header. This prevents spoofing of the IP 3099 addresses. To retain the same functionality, the ICV calculation 3100 should be performed across the entire transaction prepended by a 3101 synthesized IP header consisting of a 32 bit source IP address, a 32 3102 bit destination address and an 16 bit UDP encoded as 10 hex digits. 3103 When the interim AH mechanism is employed when TCP is the transport 3104 Layer, the UDP Port above becomes the TCP port, and all other 3105 operations are the same. 3107 Implementations of the H.248 protocol SHALL implement IPsec where 3108 the underlying operating system and the transport network supports 3109 IPsec. Implementations of the protocol using IPv4 SHALL implement 3110 the interim AH scheme. However, this interim scheme SHALL NOT be 3111 used when the underlying network layer supports IPsec. IPv6 3112 implementations are assumed to support IPsec and SHALL NOT use the 3113 interim AH scheme. 3115 All implementations of the interim AH mechanism SHALL comply with 3116 section 5 of [RFC2402] which defines a minimum set of algorithms for 3117 integrity checking using manual keys. 3119 The interim AH interim scheme does not provide protection against 3120 eavesdropping; thus forbidding third parties from monitoring the 3121 connections set up by a given termination. Also, it does not provide 3122 protection against replay attacks. These procedures do not 3123 necessarily protect against denial of service attacks by misbehaving 3124 MGs or misbehaving MGCs. However, they will provide an 3125 identification of these misbehaving entities, which should then be 3126 deprived of their authorization through maintenance procedures. 3128 10.3 Protection of Media Connections 3130 The protocol allows the MGC to provide MGs with "session keys" that 3131 can be used to encrypt the audio messages, protecting against 3132 eavesdropping. 3134 A specific problem of packet networks is "uncontrolled barge-in". 3135 This attack can be performed by directing media packets to the IP 3136 address and UDP port used by a connection. If no protection is 3137 implemented, the packets must be decompressed and the signals must 3138 be played on the "line side". 3140 Rosen et al Standards Track -- Expires Oct 2000 61 3141 A basic protection against this attack is to only accept packets 3142 from known sources, checking for example that the IP source address 3143 and UDP source port match the values announced in the Remote 3144 Descriptor. This has two inconveniences: it slows down connection 3145 establishment and it can be fooled by source spoofing: 3147 . To enable the address-based protection, the MGC must obtain the 3148 remote session description of the egress MG and pass it to the 3149 ingress MG. This requires at least one network roundtrip, and 3150 leaves us with a dilemma: either allow the call to proceed without 3151 waiting for the round trip to complete, and risk for example, 3152 "clipping" a remote announcement, or wait for the full roundtrip 3153 and settle for slower call-set-up procedures. 3155 . Source spoofing is only effective if the attacker can obtain valid 3156 pairs of source destination addresses and ports, for example by 3157 listening to a fraction of the traffic. To fight source spoofing, 3158 one could try to control all access points to the network. But 3159 this is in practice very hard to achieve. 3161 An alternative to checking the source address is to encrypt and 3162 authenticate the packets, using a secret key that is conveyed during 3163 the call set-up procedure. This will not slow down the call set-up, 3164 and provides strong protection against address spoofing. 3166 11. MG-MGC CONTROL INTERFACE 3168 The control association between MG and MGC is initiated at MG cold 3169 start, and announced by a ServiceChange message, but can be changed 3170 by subsequent events, such as failures or manual service events. 3171 While the protocol does not have an explicit mechanism to support 3172 multiple MGCs controlling a physical MG, it has been designed to 3173 support the multiple logical MG (within a single physical MG) that 3174 can be associated with different MGCs. 3176 11.1 Multiple Virtual MGs 3178 A physical Media Gateway may be partitioned into one or more Virtual 3179 MGs. A virtual MG consists of a set of statically partitioned 3180 physical Terminations and/or sets of ephemeral Terminations. A 3181 physical Termination is controlled by one MGC. The model does not 3182 require that other resources be statically allocated, just 3183 Terminations. The mechanism for allocating Terminations to virtual 3184 MGs is a management method outside the scope of the protocol. Each 3185 of the virtual MGs appears to the MGC as a complete MG client. 3187 A physical MG may have only one network interface, which must be 3188 shared across virtual MGs. In such a case, the packet/cell side 3189 Termination is shared. It should be noted however, that in use, 3190 such interfaces require an ephemeral instance of the Termination to 3191 be created per flow, and thus sharing the Termination is 3193 Rosen et al Standards Track -- Expires Oct 2000 62 3194 straightforward. This mechanism does lead to a complication, namely 3195 that the MG must always know which of its controlling MGCs should be 3196 notified if an event occurs on the interface. 3198 In normal operation, the Virtual MG will be instructed by the MGC to 3199 create network flows (if it is the originating side), or to expect 3200 flow requests (if it is the terminating side), and no confusion will 3201 arise. However, if an unexpected event occurs, the Virtual MG must 3202 know what to do with respect to the physical resources it is 3203 controlling. 3205 If recovering from the event requires manipulation of a physical 3206 interface's state, only one MGC should do so. These issues are 3207 resolved by allowing any of the MGCs to create EventsDescriptors to 3208 be notified of such events, but only one MGC can have read/write 3209 access to the physical interface properties; all other MGCs have 3210 read-only access. The management mechanism is used to designate 3211 which MGC has read/write capability, and is designated the Master 3212 MGC. 3214 Each virtual MG has its own Root Termination. In most cases the 3215 values for the properties of the Root Termination are independently 3216 settable by each MGC. Where there can only be one value, the 3217 parameter is read-only to all but the Master MGC. 3219 ServiceChange may only be applied to a Termination or set of 3220 Terminations partitioned to the Virtual MG or created (in the case 3221 of ephemeral Terminations) by that Virtual MG. 3223 11.2 Cold Start 3225 A MG is pre-provisioned by a management mechanism outside the scope 3226 of this protocol with a Primary and (optionally) an ordered list of 3227 Secondary MGCs. Upon a cold start of the MG, it will issue a 3228 ServiceChange command with a "Restart" method, on the Root 3229 Termination to its primary MGC. If the MGC accepts the MG, it will 3230 send a Transaction Accept, with the ServiceChangeMgcId set to 3231 itself. If the MG receives an ServiceChangeMgcId not equal to the 3232 MGC it contacted, it sends a ServiceChange to the MGC specified in 3233 the ServiceChangeMgcId. It continues this process until it gets a 3234 controlling MGC to accept its registration, or it fails to get a 3235 reply. Upon failure to obtain a reply, either from the Primary MGC, 3236 or a designated successor, the MG tries its pre-provisioned 3237 Secondary MGCs, in order. If the MG is unable to comply and it has 3238 established a transport connection to the MGC, it should close that 3239 connection. In any event, it should reject all subsequent requests 3240 from the MGC with Error 406 Version Not Supported. 3242 It is possible that the reply to a ServiceChange with Restart will 3243 be lost, and a command will be received by the MG prior to the 3244 receipt of the ServiceChange response. The MG shall issue error 505 3245 - Command Received before Restart Response. 3247 Rosen et al Standards Track -- Expires Oct 2000 63 3248 11.3 Negotiation of Protocol Version 3250 The first ServiceChange command from an MG shall contain the version 3251 number of the protocol supported by the MG in the 3252 ServiceChangeVersion parameter. Upon receiving such a message, if 3253 the MGC supports only a lower version, then the MGC shall send a 3254 ServiceChangeReply with the lower version and thereafter all the 3255 messages between MG and MGC shall conform to the lower version of 3256 the protocol. If the MG is unable to comply and it has established 3257 a transport connection to the MGC, it should close that connection. 3258 In any event, it should reject all subsequent requests from the MGC 3259 with Error 406 Version Not supported. 3261 If the MGC supports a higher version than the MG but is able to 3262 support the lower version proposed by the MG, it shall send a 3263 ServiceChangeReply with the lower version and thereafter all the 3264 messages between MG and MGC shall conform to the lower version of 3265 the protocol. If the MGC is unable to comply, it shall reject the 3266 association, with Error 406 Version Not Supported. 3268 Protocol version negotiation may also occur at "handoff" and 3269 "failover" ServiceChanges. 3271 When extending the protocol with new versions, the following rules 3272 should be followed. 3274 1. Existing protocol elements, i.e., procedures, parameters, 3275 descriptor, property, values, should not be changed unless a 3276 protocol error needs to be corrected or it becomes necessary to 3277 change the operation of the service that is being supported by 3278 the protocol. 3280 2. The semantics of a command, a parameter, descriptor, property, 3281 value should not be changed. 3283 3. Established rules for formatting and encoding messages and 3284 parameters should not be modified. 3286 4. When information elements are found to be obsolete they can be 3287 marked as not used. However, the identifier for that information 3288 element will be marked as reserved. In that way it can not be 3289 used in future versions. 3291 11.4 Failure of an MG 3293 If a MG fails, but is capable of sending a message to the MGC, it 3294 sends a ServiceChange with an appropriate method (graceful or 3295 forced) and specifies the Root TerminationID. When it returns to 3296 service, it sends a ServiceChange with a "Restart" method. 3298 Rosen et al Standards Track -- Expires Oct 2000 64 3299 Allowing the MGC to send duplicate messages to both MGs accommodates 3300 pairs of MGs that are capable of redundant failover of one of the 3301 MGs. Only the Working MG shall accept or reject transactions. Upon 3302 failover, the Primary MG sends a ServiceChange command with a 3303 "Failover" method and a "MG Impending Failure" reason. The MGC then 3304 uses the primary MG as the active MG. When the error condition is 3305 repaired, the Working MG can send a "ServiceChange" with a "Restart" 3306 method. 3308 11.5 Failure of an MGC 3310 If the MG detects a failure of its controlling MGC, it attempts to 3311 contact the next MGC on its pre-provisioned list. It starts its 3312 attempts at the beginning (Primary MGC), unless that was the MGC 3313 that failed, in which case it starts at its first Secondary MGC. It 3314 sends a ServiceChange message with a "Failover" method and a " MGC 3315 Impending Failure" reason. 3317 In partial failure, or manual maintenance reasons, an MGC may wish 3318 to direct its controlled MGs to use a different MGC. To do so, it 3319 sends a ServiceChange method to the MG with a "HandOff" method, and 3320 its designated replacement in ServiceChangeMgcId. The MG should send 3321 a ServiceChange message with a "Handoff" method and a "MGC directed 3322 change" reason to the designated MGC. If it fails to get a reply, 3323 or fails to see an Audit command subsequently, it should behave as 3324 if its MGC failed, and start contacting secondary MGCs. If the MG 3325 is unable to establish a control relationship with any MGC, it shall 3326 wait a random amount of time as described in section 9.2 and then 3327 start contacting its primary, and if necessary, its secondary MGCs 3328 again. 3330 No recommendation is made on how the MGCs involved in the Handoff 3331 maintain state information; this is considered to be out of scope of 3332 this recommendation. The MGC and MG may take the following steps 3333 when Handoff occurs. When the MGC initiates a HandOff, the handover 3334 should be transparent to Operations on the Media Gateway. 3335 Transactions can be executed in any order, and could be in progress 3336 when the ServiceChange is executed. Accordingly, commands in 3337 progress continue, transaction replies are sent to the new MGC 3338 (after a new control association is established), and the MG should 3339 expect outstanding transaction replies from the new MGC. No new 3340 messages shall be sent to the new MGC until the control association 3341 is established. Repeated transaction requests shall be directed to 3342 the new MGC. The MG shall maintain state on all terminations and 3343 contexts. 3345 It is possible that the MGC could be implemented in such a way that 3346 a failed MGC is replaced by a working MGC where the identity of the 3347 new MGC is the same as the failed one. In such a case, 3348 ServiceChangeMgcId would be specified with the previous value and 3349 the MG shall behave as if the value was changed, and send a 3350 ServiceChange message, as above. 3352 Rosen et al Standards Track -- Expires Oct 2000 65 3353 Pairs of MGCs that are capable of redundant failover can notify the 3354 controlled MGs of the failover by the above mechanism. 3356 12. PACKAGE DEFINITION 3358 The primary mechanism for extension is by means of Packages. 3359 Packages define additional Properties, Events, Signals and 3360 Statistics that may occur on Terminations. 3362 Packages defined by IETF will appear in separate RFCs. 3364 Packages defined by ITU-T may appear in the relevant recommendations 3365 (e.g. as annexes). 3367 1. A public document or a standard forum document, which can be 3368 referenced as the document that describes the package following 3369 the guideline above, should be specified. 3371 2. The document shall specify the version of the Package that it 3372 describes. 3374 3. The document should be available on a public web server and 3375 should have a stable URL. The site should provide a mechanism to 3376 provide comments and appropriate responses should be returned. 3378 12.1 Guidelines for defining packages 3380 Packages define Properties, Events, Signals, and Statistics. 3382 Packages may also define new error codes according to the guidelines 3383 given in section 13.2. This is a matter of documentary convenience: 3384 the package documentation is submitted to IANA in support of the 3385 error code registration. If a package is modified, it is unnecessary 3386 to provide IANA with a new document reference in support of the 3387 error code unless the description of the error code itself is 3388 modified. 3390 Names of all such defined constructs shall consist of the PackageID 3391 (which uniquely identifies the package) and the ID of the item 3392 (which uniquely identifies the item in that package). In the text 3393 encoding the two shall be separated by a forward slash ("/") 3394 character. Example: togen/playtone is the text encoding to refer to 3395 the play tone signal in the tone generation package. 3397 A Package will contain the following sections: 3399 Rosen et al Standards Track -- Expires Oct 2000 66 3400 12.1.1 Package 3402 Overall description of the package, specifying: 3403 . Package Name: only descriptive, 3404 . PackageID: Is an identifier 3405 . Description: 3406 . Version: A new version of a package can only add additional 3407 Properties, Events, Signals, Statistics and new possible values 3408 for an existing parameter described in the original package. No 3409 deletions or modifications shall be allowed. A version is an 3410 integer in the range from 1 to 99. 3412 . Extends (Optional): A package may extend an existing package. The 3413 version of the original package must be specified. When a package 3414 extends another package it shall only add additional Properties, 3415 Events, Signals, Statistics and new possible values for an 3416 existing parameter described in the original package. An extended 3417 package shall not redefine or overload a name defined in the 3418 original package. Hence, if package B version 1 extends package A 3419 version 1, version 2 of B will not be able to extend the A version 3420 2 if A version 2 defines a name already in B version 1. 3422 12.1.2 Properties 3424 Properties defined by the package, specifying: 3425 . Property Name: only descriptive. 3426 . PropertyID: Is an identifier 3427 . Description: 3428 . Type: One of: 3429 String: UTF-8 string 3430 Integer: 4 byte signed integer 3431 Double: 8 byte signed integer 3432 Character: Unicode UTF-8 encoding of a single letter. 3433 Could be more than one octet. 3434 Enumeration: One of a list of possible unique values (See 12.3) 3435 Sub-list: A list of several values from a list 3436 Boolean 3438 . Possible Values: 3439 . Defined in: Which H.248 descriptor the property is defined in. 3440 LocalControl is for stream dependent properties. TerminationState 3441 is for stream independent properties. 3443 . Characteristics: Read / Write or both, and (optionally), global: 3444 Indicates whether a property is read-only, or read-write, and if 3445 it is global. If Global is omitted, the property is not global. 3446 If a property is declared as global, the value of the property is 3447 shared by all terminations realizing the package. 3449 Rosen et al Standards Track -- Expires Oct 2000 67 3450 12.1.3 Events 3452 Events defined by the package, specifying: 3453 . Event name: only descriptive. 3454 . EventID: Is an identifier 3455 . Description: 3456 . EventsDescriptor Parameters: Parameters used by the MGC to 3457 configure the event, and found in the EventsDescriptor. See 3458 section 12.2. 3460 . ObservedEventsDescriptor Parameters: Parameters returned to the 3461 MGC in Notify requests and in replies to command requests from 3462 the MGC that audit ObservedEventsDescriptor, and found in the 3463 ObservedEventsDescriptor. See section 12.2. 3465 12.1.4 Signals 3467 . Signals defined by the package, specifying: 3468 . Signal Name: only descriptive. 3469 . SignalID: Is an identifier. SignalID is used in a 3470 SignalsDescriptor 3471 . Description 3472 . SignalType: One of: 3473 - OO (On/Off) 3474 - TO (TimeOut) 3475 - BR (Brief) 3477 Note - SignalType may be defined such that it is dependent on 3478 the value of one or more parameters. Signals that would be 3479 played with SignalType BR should have a default duration. The 3480 package has to define the default duration and signalType. 3482 . Duration: in hundredths of seconds 3483 . Additional Parameters: See section 12.2 3485 12.1.5 Statistics 3487 Statistics defined by the package, specifying: 3488 . Statistic name: only descriptive. 3489 . StatisticID: Is an identifier. StatisticID is used in a 3490 StatisticsDescriptor. 3491 . Description 3492 . Units: unit of measure, e.g. milliseconds, packets. 3494 12.1.6 Procedures 3496 Additional guidance on the use of the package. 3498 Rosen et al Standards Track -- Expires Oct 2000 68 3499 12.2 Guidelines to defining Properties, Statistics and Parameters to 3500 Events and Signals. 3502 . Parameter Name: only descriptive 3503 . ParameterID: Is an identifier 3504 . Type: One of: 3505 String: UTF-8 octet string 3506 Integer: 4 octet signed integer 3507 Double: 8 octet signed integer 3508 Character: Unicode UTF-8 encoding of a single letter. Could be 3509 more than one octet. 3510 Enumeration: One of a list of possible unique values (See 12.3) 3511 Sub-list: A list of several values from a list 3512 Boolean 3514 . Possible values: 3515 . Description: 3517 12.3 Lists 3519 Possible values for parameters include enumerations. Enumerations 3520 may be defined in a list. It is recommended that the list be IANA 3521 registered so that packages that extend the list can be defined 3522 without concern for conflicting names. 3524 12.4 Identifiers 3526 Identifiers in text encoding shall be strings of up to 64 3527 characters, containing no spaces, starting with an alphanumeric 3528 character and consisting of alphanumeric characters and / or digits, 3529 and possibly including the special character underscore ("_"). 3531 Identifiers in binary encoding are 2 octets long. 3533 Both text and binary values shall be specified for each identifier, 3534 including identifiers used as values in enumerated types. 3536 12.5 Package Registration 3538 A package can be registered with IANA for interoperability reasons. 3539 See section 13 for IANA considerations. 3541 13. IANA CONSIDERATIONS 3543 13.1 Packages 3545 The following considerations SHALL be met to register a package with 3546 IANA: 3548 1. A unique string name, unique serial number and version number is 3549 registered for each package. The string name is used with text 3551 Rosen et al Standards Track -- Expires Oct 2000 69 3552 encoding. The serial number shall be used with binary encoding. 3553 Serial Numbers 60000-64565 are reserved for private use. Serial 3554 number 0 is reserved. 3556 2. A contact name, email and postal addresses for that contact shall 3557 be specified. The contact information shall be updated by the 3558 defining organization as necessary. 3560 3. A reference to a document that describes the package, which 3561 should be public: 3563 The document shall specify the version of the Package that it 3564 describes. 3566 If the document is public, it should be located on a public web 3567 server and should have a stable URL. The site should provide a 3568 mechanism to provide comments and appropriate responses should be 3569 returned. 3571 4. Packages registered by other than recognized standards bodies 3572 shall have a minimum package name length of 8 characters. 3574 5. All other package names are first come-first served if all other 3575 conditions are met 3577 13.2 Error Codes 3579 The following considerations SHALL be met to register an error code 3580 with IANA: 3582 1. An error number and a one line (80 character maximum) string is 3583 registered for each error. 3585 2. A complete description of the conditions under which the error is 3586 detected shall be included in a publicly available document. The 3587 description shall be sufficiently clear to differentiate the 3588 error from all other existing error codes. 3590 3. The document should be available on a public web server and 3591 should have a stable URL. 3593 4. Error numbers registered by recognized standards bodies shall 3594 have 3 or 4 character error numbers. 3596 5. Error numbers registered by all other organizations or 3597 individuals shall have 4 character error numbers. 3599 6. An error number shall not be redefined, nor modified except by 3600 the organization or individual that originally defined it, or 3601 their successors or assigns. 3603 Rosen et al Standards Track -- Expires Oct 2000 70 3604 13.3 ServiceChange Reasons 3606 The following considerations SHALL be met to register service change 3607 reason with IANA: 3609 1. A one phrase, 80-character maximum, unique reason code is 3610 registered for each reason. 3611 2. A complete description of the conditions under which the reason 3612 is used is detected shall be included in a publicly available 3613 document. The description shall be sufficiently clear to 3614 differentiate the reason from all other existing reasons. 3615 3. The document should be available on a public web server and 3616 should have a stable URL. 3618 Rosen et al Standards Track -- Expires Oct 2000 71 3619 ANNEX A: BINARY ENCODING OF THE PROTOCOL (NORMATIVE) 3621 This Annex specifies the syntax of messages using the notation 3622 defined in ASN.1 [ITU-T Recommendation X.680 (1997): Information 3623 Technology - Abstract Syntax Notation One (ASN.1) - Specification of 3624 basic notation.]. Messages shall be encoded for transmission by 3625 applying the basic encoding rules specified in [ITU-T Recommendation 3626 X.690(1994) Information Technology - ASN.1 Encoding Rules: 3627 Specification of Basic Encoding Rules (BER)]. 3629 A.1 Coding of wildcards 3631 The use of wildcards ALL and CHOOSE is allowed in the protocol. 3632 This allows a MGC to partially specify Termination IDs and let the 3633 MG choose from the values that conform to the partial specification. 3634 Termination IDs may encode a hierarchy of names. This hierarchy is 3635 provisioned. For instance, a TerminationID may consist of a trunk 3636 group, a trunk within the group and a circuit. Wildcarding must be 3637 possible at all levels. The following paragraphs explain how this 3638 is achieved. 3640 The ASN.1 description uses octet strings of up to 8 octets in length 3641 for Termination IDs. This means that Termination IDs consist of at 3642 most 64 bits. A fully specified Termination ID may be preceded by a 3643 sequence of wildcarding fields. A wildcarding field is octet in 3644 length. Bit 7 (the most significant bit) of this octet specifies 3645 what type of wildcarding is invoked: if the bit value equals 1, 3646 then the ALL wildcard is used; if the bit value if 0, then the 3647 CHOOSE wildcard is used. Bit 6 of the wildcarding field specifies 3648 whether the wildcarding pertains to one level in the hierarchical 3649 naming scheme (bit value 0) or to the level of the hierarchy 3650 specified in the wildcarding field plus all lower levels (bit value 3651 1). Bits 0 through 5 of the wildcarding field specify the bit 3652 position in the Termination ID at which the starts. 3654 We illustrate this scheme with some examples. In these examples, 3655 the most significant bit in a string of bits appears on the left 3656 hand side. 3658 Assume that Termination IDs are three octets long and that each 3659 octet represents a level in a hierarchical naming scheme. A valid 3660 Termination ID is 3661 00000001 00011110 01010101. 3663 Addressing ALL names with prefix 00000001 00011110 is done as 3664 follows: 3665 wildcarding field: 10000111 3666 Termination ID: 00000001 00011110 xxxxxxxx. 3668 The values of the bits labeled "x" is irrelevant and shall be 3669 ignored by the receiver. 3671 Rosen et al Standards Track -- Expires Oct 2000 72 3672 Indicating to the receiver that is must choose a name with 00011110 3673 as the second octet is done as follows: 3674 wildcarding fields: 00010111 followed by 00000111 3675 Termination ID: xxxxxxxx 00011110 xxxxxxxx. 3677 The first wildcard field indicates a CHOOSE wildcard for the level 3678 in the naming hierarchy starting at bit 23, the highest level in our 3679 assumed naming scheme. The second wildcard field indicates a CHOOSE 3680 wildcard for the level in the naming hierarchy starting at bit 7, 3681 the lowest level in our assumed naming scheme. 3683 Finally, a CHOOSE-wildcarded name with the highest level of the name 3684 equal to 00000001 is specified as follows: 3685 wildcard field: 01001111 3686 Termination ID: 0000001 xxxxxxxx xxxxxxxx . 3688 Bit value 1 at bit position 6 of the first octet of the wildcard 3689 field indicates that the wildcarding pertains to the specified level 3690 in the naming hierarchy and all lower levels. 3692 Context IDs may also be wildcarded. In the case of Context IDs, 3693 however, specifying partial names is not allowed. Context ID 0x0 3694 SHALL be used to indicate the NULL Context, Context ID 0xFFFFFFFE 3695 SHALL be used to indicate a CHOOSE wildcard, and Context ID 3696 0xFFFFFFFF SHALL be used to indicate an ALL wildcard. 3698 TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT 3699 Termination. 3701 A.2 ASN.1 syntax specification 3703 This section contains the ASN.1 specification of the H.248 protocol 3704 syntax. 3706 NOTE - In case a transport mechanism is used that employs 3707 application level framing, the definition of Transaction below 3708 changes. Refer to the annex defining the transport mechanism for 3709 the definition that applies in that case. 3711 NOTE - The ASN.1 specification below contains a clause defining 3712 TerminationIDList as a sequence of TerminationIDs. The length of 3713 this sequence SHALL be one. The SEQUENCE OF construct is present 3714 only to allow future extensions. 3716 MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::= 3717 BEGIN 3719 MegacoMessage ::= SEQUENCE 3720 { 3721 authHeader AuthenticationHeader OPTIONAL, 3722 mess Message 3723 } 3725 Rosen et al Standards Track -- Expires Oct 2000 73 3726 AuthenticationHeader ::= SEQUENCE 3727 { 3728 secParmIndex SecurityParmIndex, 3729 seqNum SequenceNum, 3730 ad AuthData 3731 } 3733 SecurityParmIndex ::= OCTET STRING(SIZE(4)) 3735 SequenceNum ::= OCTET STRING(SIZE(4)) 3737 AuthData ::= OCTET STRING (SIZE (16..32)) 3739 Message ::= SEQUENCE 3740 { 3741 version INTEGER(0..99), 3742 -- The version of the protocol defined here is equal to 1. 3743 mId MId, -- Name/address of message originator 3744 messageBody CHOICE 3745 { 3746 messageError ErrorDescriptor, 3747 transactions SEQUENCE OF Transaction 3748 }, 3749 ... 3750 } 3752 MId ::= CHOICE 3753 { 3754 ip4Address IP4Address, 3755 ip6Address IP6Address, 3756 domainName DomainName, 3757 deviceName PathName, 3758 mtpAddress OCTET STRING(SIZE(2)), 3759 -- Addressing structure of mtpAddress: 3760 -- 15 0 3761 -- | PC | NI | 3762 -- 14 bits 2 bits 3763 ... 3764 } 3766 DomainName ::= SEQUENCE 3767 { 3768 name IA5String, 3769 -- The name starts with an alphanumeric digit followed by a 3770 -- sequence of alphanumeric digits, hyphens and dots. No two 3771 -- dots shall occur consecutively. 3772 portNumber INTEGER(0..65535) OPTIONAL 3773 } 3775 Rosen et al Standards Track -- Expires Oct 2000 74 3776 IP4Address ::= SEQUENCE 3777 { 3778 address OCTET STRING (SIZE(4)), 3779 portNumber INTEGER(0..65535) OPTIONAL 3780 } 3782 IP6Address ::= SEQUENCE 3783 { 3784 address OCTET STRING (SIZE(16)), 3785 portNumber INTEGER(0..65535) OPTIONAL 3786 } 3788 PathName ::= IA5String(SIZE (1..64)) 3789 -- See section A.3 3791 Transaction ::= CHOICE 3792 { 3793 transactionRequest TransactionRequest, 3794 transactionPending TransactionPending, 3795 transactionReply TransactionReply, 3796 transactionResponseAck TransactionResponseAck, 3797 -- use of response acks is dependent on underlying 3798 transport 3799 ... 3800 } 3802 TransactionId ::= INTEGER(0..4294967295) -- 32 bit unsigned integer 3804 TransactionRequest ::= SEQUENCE 3805 { 3806 transactionId TransactionId, 3807 actions SEQUENCE OF ActionRequest, 3808 ... 3809 } 3811 TransactionPending ::= SEQUENCE 3812 { 3813 transactionId TransactionId, 3814 ... 3815 } 3817 TransactionReply ::= SEQUENCE 3818 { 3819 transactionId TransactionId, 3820 transactionResult CHOICE 3821 { 3822 transactionError ErrorDescriptor, 3823 actionReplies SEQUENCE OF ActionReply 3824 }, 3825 ... 3826 } 3828 Rosen et al Standards Track -- Expires Oct 2000 75 3829 TransactionResponseAck ::= SEQUENCE 3830 { 3831 firstAck TransactionId, 3832 lastAck TransactionId OPTIONAL 3833 } 3835 ErrorDescriptor ::= SEQUENCE 3836 { 3837 errorCode ErrorCode, 3838 errorText ErrorText OPTIONAL 3839 } 3841 ErrorCode ::= INTEGER(0..65535) 3842 -- See section 13 for IANA considerations w.r.t. error codes 3844 ErrorText ::= IA5String 3846 ContextID ::= INTEGER(0..4294967295) 3848 -- Context NULL Value: 0 3849 -- Context CHOOSE Value: 429467294 (0xFFFFFFFE) 3850 -- Context ALL Value: 4294967295 (0xFFFFFFFF) 3852 ActionRequest ::= SEQUENCE 3853 { 3854 contextId ContextID, 3855 contextRequest ContextRequest OPTIONAL, 3856 contextAttrAuditReq ContextAttrAuditRequest OPTIONAL, 3857 commandRequests SEQUENCE OF CommandRequest 3858 } 3860 ActionReply ::= SEQUENCE 3861 { 3862 contextId ContextID, 3863 errorDescriptor ErrorDescriptor OPTIONAL, 3864 contextReply ContextRequest OPTIONAL, 3865 commandReply SEQUENCE OF CommandReply 3866 } 3868 ContextRequest ::= SEQUENCE 3869 { 3870 priority INTEGER(0..15) OPTIONAL, 3871 emergency BOOLEAN OPTIONAL, 3872 topologyReq SEQUENCE OF TopologyRequest OPTIONAL, 3873 ... 3874 } 3876 Rosen et al Standards Track -- Expires Oct 2000 76 3877 ContextAttrAuditRequest ::= SEQUENCE 3878 { 3879 topology NULL OPTIONAL, 3880 emergency NULL OPTIONAL, 3881 priority NULL OPTIONAL, 3882 ... 3883 } 3885 CommandRequest ::= SEQUENCE 3886 { 3887 command Command, 3888 optional NULL OPTIONAL, 3889 wildcardReturn NULL OPTIONAL, 3890 ... 3891 } 3893 Command ::= CHOICE 3894 { 3895 addReq AmmRequest, 3896 moveReq AmmRequest, 3897 modReq AmmRequest, 3898 -- Add, Move, Modify requests have the same parameters 3899 subtractReq SubtractRequest, 3900 auditCapRequest AuditRequest, 3901 auditValueRequest AuditRequest, 3902 notifyReq NotifyRequest, 3903 serviceChangeReq ServiceChangeRequest, 3904 ... 3905 } 3907 CommandReply ::= CHOICE 3908 { 3909 addReply AmmsReply, 3910 moveReply AmmsReply, 3911 modReply AmmsReply, 3912 subtractReply AmmsReply, 3913 -- Add, Move, Modify, Subtract replies have the same parameters 3914 auditCapReply AuditReply, 3915 auditValueReply AuditReply, 3916 notifyReply NotifyReply, 3917 serviceChangeReply ServiceChangeReply, 3918 ... 3919 } 3921 TopologyRequest ::= SEQUENCE 3922 { 3923 terminationFrom TerminationID, 3924 terminationTo TerminationID, 3925 topologyDirection ENUMERATED 3926 { 3927 bothway(0), 3928 isolate(1), 3930 Rosen et al Standards Track -- Expires Oct 2000 77 3931 oneway(2) 3932 } 3933 } 3935 AmmRequest ::= SEQUENCE 3936 { 3937 terminationID TerminationIDList, 3938 mediaDescriptor MediaDescriptor OPTIONAL, 3939 modemDescriptor ModemDescriptor OPTIONAL, 3940 muxDescriptor MuxDescriptor OPTIONAL, 3941 eventsDescriptor EventsDescriptor OPTIONAL, 3942 eventBufferDescriptor EventBufferDescriptor OPTIONAL, 3943 signalsDescriptor SignalsDescriptor OPTIONAL, 3944 digitMapDescriptor DigitMapDescriptor OPTIONAL, 3945 auditDescriptor AuditDescriptor OPTIONAL, 3946 ... 3947 } 3949 AmmsReply ::= SEQUENCE 3950 { 3951 terminationID TerminationIDList, 3952 terminationAudit TerminationAudit OPTIONAL 3953 } 3955 SubtractRequest ::= SEQUENCE 3956 { 3957 terminationID TerminationIDList, 3958 auditDescriptor AuditDescriptor OPTIONAL, 3959 ... 3960 } 3962 AuditRequest ::= SEQUENCE 3963 { 3964 terminationID TerminationID, 3965 auditDescriptor AuditDescriptor, 3966 ... 3967 } 3969 AuditReply ::= SEQUENCE 3970 { 3971 terminationID TerminationID, 3972 auditResult AuditResult 3973 } 3975 AuditResult ::= CHOICE 3976 { 3977 contextAuditResult TerminationIDList, 3978 terminationAuditResult TerminationAudit 3979 } 3981 Rosen et al Standards Track -- Expires Oct 2000 78 3982 AuditDescriptor ::= SEQUENCE 3983 { 3984 auditToken BIT STRING 3985 { 3986 muxToken(0), modemToken(1), mediaToken(2), 3987 eventsToken(3), signalsToken(4), 3988 digitMapToken(5), statsToken(6), 3989 observedEventsToken(7), 3990 packagesToken(8), eventBufferToken(9) 3991 } OPTIONAL, 3992 ... 3993 } 3995 TerminationAudit ::= SEQUENCE OF AuditReturnParameter 3997 AuditReturnParameter ::= CHOICE 3998 { 3999 errorDescriptor ErrorDescriptor, 4000 mediaDescriptor MediaDescriptor, 4001 modemDescriptor ModemDescriptor, 4002 muxDescriptor MuxDescriptor, 4003 eventsDescriptor EventsDescriptor, 4004 eventBufferDescriptor EventBufferDescriptor, 4005 signalsDescriptor SignalsDescriptor, 4006 digitMapDescriptor DigitMapDescriptor, 4007 observedEventsDescriptor ObservedEventsDescriptor, 4008 statisticsDescriptor StatisticsDescriptor, 4009 packagesDescriptor PackagesDescriptor, 4010 ... 4011 } 4013 NotifyRequest ::= SEQUENCE 4014 { 4015 terminationID TerminationIDList, 4016 observedEventsDescriptor ObservedEventsDescriptor, 4017 errorDescriptor ErrorDescriptor OPTIONAL, 4018 ... 4019 } 4021 NotifyReply ::= SEQUENCE 4022 { 4023 terminationID TerminationIDList OPTIONAL, 4024 errorDescriptor ErrorDescriptor OPTIONAL, 4025 ... 4026 } 4028 ObservedEventsDescriptor ::= SEQUENCE 4029 { 4030 requestId RequestID, 4031 observedEventLst SEQUENCE OF ObservedEvent 4032 } 4034 Rosen et al Standards Track -- Expires Oct 2000 79 4035 ObservedEvent ::= SEQUENCE 4036 { 4037 eventName EventName, 4038 streamID StreamID OPTIONAL, 4039 eventParList SEQUENCE OF EventParameter, 4040 timeNotation TimeNotation OPTIONAL 4041 } 4043 EventName ::= PkgdName 4045 EventParameter ::= SEQUENCE 4046 { 4047 eventParameterName Name, 4048 value Value 4049 } 4051 ServiceChangeRequest ::= SEQUENCE 4052 { 4053 terminationID TerminationIDList, 4054 serviceChangeParms ServiceChangeParm, 4055 ... 4056 } 4058 ServiceChangeReply ::= SEQUENCE 4059 { 4060 terminationID TerminationIDList, 4061 serviceChangeResult ServiceChangeResult, 4062 ... 4063 } 4065 -- For ServiceChangeResult, no parameters are mandatory. Hence the 4066 -- distinction between ServiceChangeParm and ServiceChangeResParm. 4068 ServiceChangeResult ::= CHOICE 4069 { 4070 errorDescriptor ErrorDescriptor, 4071 serviceChangeResParms ServiceChangeResParm 4072 } 4074 WildcardField ::= OCTET STRING(SIZE(1)) 4076 TerminationID ::= SEQUENCE 4077 { 4078 wildcard SEQUENCE OF WildcardField, 4079 id OCTET STRING(SIZE(1..8)) 4080 } 4081 -- See Section A.1 for explanation of wildcarding mechanism. 4082 -- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination. 4084 TerminationIDList ::= SEQUENCE OF TerminationID 4086 Rosen et al Standards Track -- Expires Oct 2000 80 4087 MediaDescriptor ::= SEQUENCE 4088 { 4090 termStateDescr TerminationStateDescriptor OPTIONAL, 4091 streams CHOICE 4092 { 4093 oneStream StreamParms, 4094 multiStream SEQUENCE OF StreamDescriptor 4095 }, 4096 ... 4097 } 4099 StreamDescriptor ::= SEQUENCE 4100 { 4101 streamID StreamID, 4102 streamParms StreamParms 4103 } 4105 StreamParms ::= SEQUENCE 4106 { 4107 localControlDescriptor LocalControlDescriptor OPTIONAL, 4108 localDescriptor LocalRemoteDescriptor OPTIONAL, 4109 remoteDescriptor LocalRemoteDescriptor OPTIONAL, 4110 ... 4111 } 4113 LocalControlDescriptor ::= SEQUENCE 4114 { 4115 streamMode StreamMode OPTIONAL, 4116 reserveValue BOOLEAN, 4117 reserveGroup BOOLEAN, 4118 propertyParms SEQUENCE OF PropertyParm, 4119 ... 4120 } 4122 StreamMode ::= ENUMERATED 4123 { 4124 sendOnly(0), 4125 recvOnly(1), 4126 sendRecv(2), 4127 inactive(3), 4128 loopBack(4), 4129 ... 4130 } 4132 -- In PropertyParm, value is a SEQUENCE OF octet string. When sent 4133 -- by an MGC the interpretation is as follows: 4134 -- empty sequence means CHOOSE 4135 -- one element sequence specifies value 4136 -- longer sequence means "choose one of the values" 4138 Rosen et al Standards Track -- Expires Oct 2000 81 4139 -- The relation field may only be selected if the value sequence 4140 -- has length 1. It indicates that the MG has to choose a value 4141 -- for the property. E.g., x > 3 (using the greaterThan 4142 -- value for relation) instructs the MG to choose any value larger 4143 -- than 3 for property x. 4144 -- The range field may only be selected if the value sequence 4145 -- has length 2. It indicates that the MG has to choose a value 4146 -- in the range between the first octet in the value sequence and 4147 -- the trailing octet in the value sequence, including the 4148 -- boundary values. 4149 -- When sent by the MG, only responses to an AuditCapability request 4150 -- may contain multiple values, a range, or a relation field. 4152 PropertyParm ::= SEQUENCE 4153 { 4154 name PkgdName, 4155 value SEQUENCE OF OCTET STRING, 4156 extraInfo CHOICE 4157 { 4158 relation Relation, 4159 range BOOLEAN 4160 } OPTIONAL 4162 } 4164 Name ::= OCTET STRING(SIZE(2)) 4166 PkgdName ::= OCTET STRING(SIZE(4)) 4167 -- represents Package Name (2 octets) plus Property Name (2 octets) 4168 -- To wildcard a package use 0xFFFF for first two octets, choose 4169 -- is not allowed. To reference native property tag specified in 4170 -- Annex C, use 0x0000 as first two octets. 4171 -- Wildcarding of Package Name is permitted only if Property Name is 4172 -- also wildcarded. 4174 Relation ::= ENUMERATED 4175 { 4176 greaterThan(0), 4177 smallerThan(1), 4178 unequalTo(2), 4179 ... 4180 } 4182 LocalRemoteDescriptor ::= SEQUENCE 4183 { 4184 propGrps SEQUENCE OF PropertyGroup, 4185 ... 4186 } 4188 PropertyGroup ::= SEQUENCE OF PropertyParm 4190 Rosen et al Standards Track -- Expires Oct 2000 82 4191 TerminationStateDescriptor ::= SEQUENCE 4192 { 4193 propertyParms SEQUENCE OF PropertyParm, 4194 eventBufferControl EventBufferControl OPTIONAL, 4195 serviceState ServiceState OPTIONAL, 4196 ... 4197 } 4199 EventBufferControl ::= ENUMERATED 4200 { 4201 Off(0), 4202 LockStep(1), 4203 ... 4204 } 4206 ServiceState ::= ENUMERATED 4207 { 4208 test(0), 4209 outOfSvc(1), 4210 inSvc(2), 4211 ... 4212 } 4214 MuxDescriptor ::= SEQUENCE 4215 { 4216 muxType MuxType, 4217 termList SEQUENCE OF TerminationID, 4218 nonStandardData NonStandardData OPTIONAL, 4219 ... 4220 } 4222 MuxType ::= ENUMERATED 4223 { 4224 h221(0), 4225 h223(1), 4226 h226(2), 4227 v76(3), 4228 ... 4229 } 4231 StreamID ::= INTEGER(0..65535) -- 16 bit unsigned integer 4233 EventsDescriptor ::= SEQUENCE 4234 { 4235 requestID RequestID, 4236 eventList SEQUENCE OF RequestedEvent 4237 } 4239 Rosen et al Standards Track -- Expires Oct 2000 83 4240 RequestedEvent ::= SEQUENCE 4241 { 4242 pkgdName PkgdName, 4243 streamID StreamID OPTIONAL, 4244 eventAction RequestedActions OPTIONAL, 4245 evParList SEQUENCE OF EventParameter 4246 } 4248 RequestedActions ::= SEQUENCE 4249 { 4250 keepActive BOOLEAN, 4251 eventDM EventDM OPTIONAL, 4252 secondEvent SecondEventsDescriptor OPTIONAL, 4253 signalsDescriptor SignalsDescriptor OPTIONAL, 4254 ... 4255 } 4257 EventDM ::= CHOICE 4258 { digitMapName DigitMapName, 4259 digitMapValue DigitMapValue 4260 } 4262 SecondEventsDescriptor ::= SEQUENCE 4263 { 4264 requestID RequestID, 4265 eventList SEQUENCE OF SecondRequestedEvent 4266 } 4268 SecondRequestedEvent ::= SEQUENCE 4269 { 4270 pkgdName PkgdName, 4271 streamID StreamID OPTIONAL, 4272 eventAction SecondRequestedActions OPTIONAL, 4273 evParList SEQUENCE OF EventParameter 4274 } 4276 SecondRequestedActions ::= SEQUENCE 4277 { 4278 keepActive BOOLEAN, 4279 eventDM EventDM OPTIONAL, 4280 signalsDescriptor SignalsDescriptor OPTIONAL, 4281 ... 4282 } 4284 EventBufferDescriptor ::= SEQUENCE OF ObservedEvent 4286 SignalsDescriptor ::= SEQUENCE OF SignalRequest 4288 Rosen et al Standards Track -- Expires Oct 2000 84 4289 SignalRequest ::=CHOICE 4290 { 4291 signal Signal, 4292 seqSigList SeqSigList 4293 } 4295 SeqSigList ::= SEQUENCE 4296 { 4297 id INTEGER(0..65535), 4298 signalList SEQUENCE OF Signal 4299 } 4301 Signal ::= SEQUENCE 4302 { 4303 signalName SignalName, 4304 streamID StreamID OPTIONAL, 4305 sigType SignalType OPTIONAL, 4306 duration INTEGER (0..65535) OPTIONAL, 4307 notifyCompletion BOOLEAN OPTIONAL, 4308 keepActive BOOLEAN OPTIONAL, 4309 sigParList SEQUENCE OF SigParameter 4310 } 4312 SignalType ::= ENUMERATED 4313 { 4314 brief(0), 4315 onOff(1), 4316 timeOut(2), 4317 ... 4318 } 4320 SignalName ::= PkgdName 4322 SigParameter ::= SEQUENCE 4323 { 4324 sigParameterName Name, 4325 value Value 4326 } 4328 RequestID ::= INTEGER(0..4294967295) -- 32 bit unsigned integer 4330 ModemDescriptor ::= SEQUENCE 4331 { 4332 mtl SEQUENCE OF ModemType, 4333 mpl SEQUENCE OF PropertyParm, 4334 nonStandardData NonStandardData OPTIONAL 4335 } 4337 Rosen et al Standards Track -- Expires Oct 2000 85 4338 ModemType ::= ENUMERATED 4339 { 4340 v18(0), 4341 v22(1), 4342 v22bis(2), 4343 v32(3), 4344 v32bis(4), 4345 v34(5), 4346 v90(6), 4347 v91(7), 4348 synchISDN(8), 4349 ... 4350 } 4352 DigitMapDescriptor ::= SEQUENCE 4353 { 4354 digitMapName DigitMapName, 4355 digitMapValue DigitMapValue 4356 } 4358 DigitMapName ::= Name 4360 DigitMapValue ::= SEQUENCE 4361 { 4362 startTimer INTEGER(0..99) OPTIONAL, 4363 shortTimer INTEGER(0..99) OPTIONAL, 4364 longTimer INTEGER(0..99) OPTIONAL, 4365 digitMapBody IA5String 4366 -- See Section A.3 for explanation of digit map syntax 4367 } 4369 ServiceChangeParm ::= SEQUENCE 4370 { 4371 serviceChangeMethod ServiceChangeMethod, 4372 serviceChangeAddress ServiceChangeAddress OPTIONAL, 4373 serviceChangeVersion INTEGER(0..99) OPTIONAL, 4374 serviceChangeProfile ServiceChangeProfile OPTIONAL, 4375 serviceChangeReason Value, 4376 serviceChangeDelay INTEGER(0..4294967295) OPTIONAL, 4377 -- 32 bit unsigned integer 4378 serviceChangeMgcId MId OPTIONAL, 4379 timeStamp TimeNotation OPTIONAL, 4380 nonStandardData NonStandardData OPTIONAL, 4381 ... 4382 } 4384 Rosen et al Standards Track -- Expires Oct 2000 86 4385 ServiceChangeAddress ::= CHOICE 4386 { 4387 portNumber INTEGER(0..65535), -- TCP/UDP port number 4388 ip4Address IP4Address, 4389 ip6Address IP6Address, 4390 domainName DomainName, 4391 deviceName PathName, 4392 mtpAddress OCTET STRING(SIZE(2)), 4393 ... 4394 } 4396 ServiceChangeResParm ::= SEQUENCE 4397 { 4398 serviceChangeMgcId MId OPTIONAL, 4399 serviceChangeAddress ServiceChangeAddress OPTIONAL, 4400 serviceChangeVersion INTEGER(0..99) OPTIONAL, 4401 serviceChangeProfile ServiceChangeProfile OPTIONAL 4402 } 4404 ServiceChangeMethod ::= ENUMERATED 4405 { 4406 failover(0), 4407 forced(1), 4408 graceful(2), 4409 restart(3), 4410 disconnected(4), 4411 handOff(5), 4412 ... 4413 } 4415 ServiceChangeProfile ::= SEQUENCE 4416 { 4417 profileName Name, 4418 version INTEGER(0..99) 4419 } 4421 PackagesDescriptor ::= SEQUENCE OF PackagesItem 4423 PackagesItem ::= SEQUENCE 4424 { 4425 packageName Name, 4426 packageVersion INTEGER(0..99) 4427 } 4429 StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter 4431 StatisticsParameter ::= SEQUENCE 4432 { 4433 statName PkgdName, 4434 statValue Value 4435 } 4437 Rosen et al Standards Track -- Expires Oct 2000 87 4438 NonStandardData ::= SEQUENCE 4439 { 4440 nonStandardIdentifier NonStandardIdentifier, 4441 data OCTET STRING 4442 } 4444 NonStandardIdentifier ::= CHOICE 4445 { 4446 object OBJECT IDENTIFIER, 4447 h221NonStandard H221NonStandard, 4448 experimental IA5STRING(SIZE(8)), 4449 -- first two characters should be "X-" or "X+" 4450 ... 4451 } 4453 H221NonStandard ::= SEQUENCE 4454 { t35CountryCode INTEGER(0..255), -- country, as per T.35 4455 t35Extension INTEGER(0..255), -- assigned nationally 4456 manufacturerCode INTEGER(0..65535), -- assigned nationally 4457 ... 4458 } 4460 TimeNotation ::= SEQUENCE 4461 { 4462 date IA5String(SIZE(8)), -- yyyymmdd format 4463 time IA5String(SIZE(8)) -- hhmmssss format 4464 } 4466 Value ::= OCTET STRING 4468 END 4470 A.3 Digit maps and path names 4472 From a syntactic viewpoint, digit maps are strings with syntactic 4473 restrictions imposed upon them. The syntax of valid digit maps is 4474 specified in ABNF [RFC 2234]. The syntax for digit maps presented 4475 in this section is for illustrative purposes only. The definition of 4476 digitMap in Annex B takes precedence in the case of differences 4477 between the two. 4479 digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")" 4480 LWSP) 4481 digitStringList = digitString *( LWSP "/" LWSP digitString ) 4482 digitString = 1*(digitStringElement) 4483 digitStringElement = digitPosition [DOT] 4484 digitPosition = digitMapLetter / digitMapRange 4485 digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) 4486 digitLetter = *((DIGIT "-" DIGIT) /digitMapLetter) 4488 Rosen et al Standards Track -- Expires Oct 2000 88 4489 digitMapLetter = DIGIT ;digits 0-9 4490 / %x41-4B / %x61-6B ;a-k and A-K 4491 / "L" / "S" ;Inter-event timers 4492 ;(long, short) 4493 / "Z" ;Long duration event 4494 LWSP = *(WSP / COMMENT / EOL) 4495 WSP = SP / HTAB 4496 COMMENT = ";" *(SafeChar / RestChar / WSP) EOL 4497 EOL = (CR [LF]) / LF 4498 SP = %x20 4499 HTAB = %x09 4500 CR = %x0D 4501 LF = %x0A 4502 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" / 4503 "'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / "\" / 4504 "(" / ")" / "%" / "." 4505 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" / 4506 "<" / ">" / "=" / %x22 4507 DIGIT = %x30-39 ; digits 0 through 9 4508 ALPHA = %x41-5A / %x61-7A ; A-Z, a-z 4509 A path name is also a string with syntactic restrictions imposed 4510 upon it. The ABNF production defining it is copied from Annex B. 4512 PathName = NAME *(["/"] ["*"] ["@"] (ALPHA / DIGIT)) ["*"] 4513 NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 4515 Rosen et al Standards Track -- Expires Oct 2000 89 4516 ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE) 4518 B.1 Coding of wildcards 4520 In a text encoding of the protocol, while TerminationIDs are 4521 arbitrary, by judicious choice of names, the wildcard character, "*" 4522 may be made more useful. When the wildcard character is 4523 encountered, it will "match" all TerminationIDs having the same 4524 previous and following characters (if appropriate). For example, if 4525 there were TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the 4526 TerminationID R13/3/* would match all of them. There are some 4527 circumstances where ALL Terminations must be referred to. The 4528 TerminationID "*" suffices, and is referred to as ALL. The CHOOSE 4529 TerminationID "$" may be used to signal to the MG that it has to 4530 create an ephemeral Termination or select an idle physical 4531 Termination. 4533 B.2 ABNF specification 4535 The protocol syntax is presented in ABNF according to RFC2234. 4537 megacoMessage = LWSP [authenticationHeader SEP ] message 4539 authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON 4540 SequenceNum COLON AuthData 4542 SecurityParmIndex = "0x" 8(HEXDIG) 4543 SequenceNum = "0x" 8(HEXDIG) 4544 AuthData = "0x" 32*64(HEXDIG) 4546 message = MegacopToken SLASH Version SEP mId SEP messageBody 4547 ; The version of the protocol defined here is equal to 1. 4549 messageBody = ( errorDescriptor / transactionList ) 4551 transactionList = 1*( transactionRequest / transactionReply / 4552 transactionPending / transactionResponseAck ) 4553 ;Use of resopnse acks is dependent on underlying transport 4555 transactionPending = PendingToken EQUAL TransactionID LBRKT RBRKT 4557 transactionResponseAck = ResponseAckToken LBRKT transactionAck 4558 *(COMMA transactionAck) RBRKT 4559 transactionAck = transactionID / (transactionID "-" transactionID) 4561 transactionRequest = TransToken EQUAL TransactionID LBRKT 4562 actionRequest *(COMMA actionRequest) RBRKT 4564 actionRequest = CtxToken EQUAL ContextID LBRKT (( 4565 contextRequest [COMMA commandRequestList]) 4566 / commandRequestList) RBRKT 4568 Rosen et al Standards Track -- Expires Oct 2000 90 4569 contextRequest = ((contextProperties [COMMA contextAudit]) 4570 / contextAudit) 4572 contextProperties = contextProperty *(COMMA contextProperty) 4574 ; at-most-once 4575 contextProperty = (topologyDescriptor / priority / EmergencyToken) 4577 contextAudit = ContextAuditToken LBRKT 4578 contextAuditProperties *(COMMA 4579 contextAuditProperties) RBRKT 4581 ; at-most-once 4582 contextAuditProperties = ( TopologyToken / EmergencyToken / 4583 PriorityToken ) 4585 commandRequestList= ["O-"] commandRequest *(COMMA ["O-"] 4586 commandRequest) 4588 commandRequest = ( ammRequest / subtractRequest / auditRequest 4589 / notifyRequest / serviceChangeRequest) 4591 transactionReply = ReplyToken EQUAL TransactionID LBRKT 4592 ( errorDescriptor / actionReplyList ) RBRKT 4594 actionReplyList = actionReply *(COMMA actionReply ) 4596 actionReply = CtxToken EQUAL ContextID LBRKT 4597 ( errorDescriptor / commandReply ) RBRKT 4599 commandReply = (( contextProperties [COMMA commandReplyList] ) 4600 / commandReplyList ) 4602 commandReplyList = commandReplys *(COMMA commandReplys ) 4604 commandReplys = (serviceChangeReply / auditReply / ammsReply 4605 / notifyReply ) 4607 ;Add Move and Modify have the same request parameters 4608 ammRequest = (AddToken / MoveToken / ModifyToken ) EQUAL 4609 TerminationID [LBRKT ammParameter *(COMMA 4610 ammParameter) RBRKT] 4612 ;at-most-once 4613 ammParameter = (mediaDescriptor / modemDescriptor / 4614 muxDescriptor / eventsDescriptor / 4615 signalsDescriptor / digitMapDescriptor / 4616 eventBufferDescriptor / auditDescriptor) 4618 Rosen et al Standards Track -- Expires Oct 2000 91 4619 ammsReply = (AddToken / MoveToken / ModifyToken / 4620 SubtractToken ) EQUAL TerminationID [ LBRKT 4621 terminationAudit RBRKT ] 4623 subtractRequest = ["W-"] SubtractToken EQUAL TerminationID 4624 [ LBRKT auditDescriptor RBRKT] 4626 auditRequest = ["W-"] (AuditValueToken / AuditCapToken ) 4627 EQUAL TerminationID LBRKT auditDescriptor RBRKT 4629 auditReply = (AuditValueToken / AuditCapToken ) 4630 ( contextTerminationAudit / auditOther) 4632 auditOther = EQUAL TerminationID LBRKT 4633 terminationAudit RBRKT 4635 terminationAudit = auditReturnParameter *(COMMA 4636 auditReturnParameter) 4638 contextTerminationAudit = EQUAL CtxToken ( terminationIDList / 4639 LBRKT errorDescriptor RBRKT ) 4641 ;at-most-once except errorDescriptor 4642 auditReturnParameter = (mediaDescriptor / modemDescriptor / 4643 muxDescriptor / eventsDescriptor / 4644 signalsDescriptor / digitMapDescriptor / 4645 observedEventsDescriptor / eventBufferDescriptor / 4646 statisticsDescriptor / packagesDescriptor / 4647 errorDescriptor ) 4649 auditDescriptor = AuditToken LBRKT [ auditItem 4650 *(COMMA auditItem) ] RBRKT 4652 notifyRequest = NotifyToken EQUAL TerminationID 4653 LBRKT ( observedEventsDescriptor 4654 [ COMMA errorDescriptor ] ) RBRKT 4656 notifyReply = NotifyToken EQUAL TerminationID 4657 [ LBRKT errorDescriptor RBRKT ] 4659 serviceChangeRequest = ServiceChangeToken EQUAL TerminationID 4660 LBRKT serviceChangeDescriptor RBRKT 4662 serviceChangeReply = ServiceChangeToken EQUAL TerminationID 4663 [LBRKT (errorDescriptor / 4664 serviceChangeReplyDescriptor) RBRKT] 4666 errorDescriptor = ErrorToken EQUAL ErrorCode 4667 LBRKT [quotedString] RBRKT 4669 ErrorCode = 1*4(DIGIT) ; could be extended 4671 Rosen et al Standards Track -- Expires Oct 2000 92 4672 TransactionID = UINT32 4674 mId = (( domainAddress / domainName ) 4675 [":" portNumber]) / mtpAddress / deviceName 4677 ; ABNF allows two or more consecutive "." although it is meaningless 4678 ; in a domain name. 4679 domainName = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" / 4680 ".") ">" 4681 deviceName = pathNAME 4683 ContextID = (UINT32 / "*" / "-" / "$") 4685 domainAddress = "[" (IPv4address / IPv6address) "]" 4686 ;RFC2373 contains the definition of IP6Addresses. 4687 IPv6address = hexpart [ ":" IPv4address ] 4688 IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex 4689 V4hex = 1*3(DIGIT) ; "0".."225" 4690 ; this production, while occurring in RFC2373, is not referenced 4691 ; IPv6prefix = hexpart SLASH 1*2DIGIT 4692 hexpart = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq 4693 hexseq = hex4 *( ":" hex4) 4694 hex4 = 1*4HEXDIG 4696 portNumber = UINT16 4698 ; An mtp address is two octets long 4699 mtpAddress = MTPToken LBRKT octetString RBRKT 4701 terminationIDList = LBRKT TerminationID *(COMMA TerminationID) 4702 RBRKT 4704 ; Total length of pathNAME must not exceed 64 chars. 4705 pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) 4706 ["@" pathDomainName ] 4708 ; ABNF allows two or more consecutive "." although it is meaningless 4709 ; in a path domain name. 4710 pathDomainName = (ALPHA / DIGIT / "*" ) 4711 *63(ALPHA / DIGIT / "-" / "*" / ".") 4713 TerminationID = "ROOT" / pathNAME / "$" / "*" 4715 mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) 4716 RBRKT 4718 ; at-most-once per item 4719 ; and either streamParm or streamDescriptor but not both 4720 mediaParm = (streamParm / streamDescriptor / 4721 terminationStateDescriptor) 4723 Rosen et al Standards Track -- Expires Oct 2000 93 4724 ; at-most-once 4725 streamParm = ( localDescriptor / remoteDescriptor / 4726 localControlDescriptor ) 4728 streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm 4729 *(COMMA streamParm) RBRKT 4731 localControlDescriptor = LocalControlToken LBRKT localParm 4732 *(COMMA localParm) RBRKT 4734 ; at-most-once per item 4735 localParm = ( streamMode / propertyParm / 4736 reservedValueMode 4737 / reservedGroupMode ) 4739 reservedValueMode = ReservedValueToken EQUAL ( "ON" / "OFF" ) 4740 reservedGroupMode = ReservedGroupToken EQUAL ( "ON" / "OFF" ) 4742 streamMode = ModeToken EQUAL streamModes 4744 streamModes = (SendonlyToken / RecvonlyToken / 4745 SendrecvToken / 4746 InactiveToken / LoopbackToken ) 4748 propertyParm = pkgdName parmValue 4749 parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) 4750 alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT 4751 / 4752 LSBRKT VALUE DOT DOT VALUE RSBRKT ) 4754 INEQUAL = LWSP (">" / "<" / "#" ) LWSP 4755 LSBRKT = LWSP "[" LWSP 4756 RSBRKT = LWSP "]" LWSP 4758 localDescriptor = LocalToken LBRKT octetString RBRKT 4760 remoteDescriptor = RemoteToken LBRKT octetString RBRKT 4762 eventBufferDescriptor= EventBufferToken LBRKT observedEvent 4763 *( COMMA observedEvent ) RBRKT 4765 eventBufferControl = BufferToken EQUAL ( "OFF" / LockStepToken ) 4767 terminationStateDescriptor = TerminationStateToken LBRKT 4768 terminationStateParm *( COMMA terminationStateParm ) 4769 RBRKT 4771 ; at-most-once per item 4772 terminationStateParm =(propertyParm / serviceStates / 4773 eventBufferControl ) 4775 Rosen et al Standards Track -- Expires Oct 2000 94 4776 serviceStates = ServiceStatesToken EQUAL ( TestToken / 4777 OutOfSvcToken / InSvcToken ) 4779 muxDescriptor = MuxToken EQUAL MuxType terminationIDList 4781 MuxType = ( H221Token / H223Token / H226Token / 4782 V76Token / extensionParameter ) 4784 StreamID = UINT16 4785 pkgdName = (PackageName SLASH ItemID) ;specific item 4786 / (PackageName SLASH "*") ;all events in package 4787 / ("*" SLASH "*") ; all events supported by the MG 4788 PackageName = NAME 4789 ItemID = NAME 4791 eventsDescriptor = EventsToken EQUAL RequestID LBRKT 4792 requestedEvent *( COMMA requestedEvent ) RBRKT 4794 requestedEvent = pkgdName [ LBRKT eventParameter 4795 *( COMMA eventParameter ) RBRKT ] 4797 ; at-most-once each of KeepActiveToken , eventDM and eventStream 4798 ;at most one of either embedWithSig or embedNoSig but not both 4799 ;KeepActiveToken and embedWithSig must not both be present 4800 eventParameter = ( embedWithSig / embedNoSig / KeepActiveToken 4801 /eventDM / eventStream / eventOther ) 4803 embedWithSig = EmbedToken LBRKT signalsDescriptor 4804 [COMMA embedFirst ] RBRKT 4805 embedNoSig = EmbedToken LBRKT embedFirst RBRKT 4807 ; at-most-once of each 4808 embedFirst = EventsToken EQUAL RequestID LBRKT 4809 secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT 4811 secondRequestedEvent = pkgdName [ LBRKT secondEventParameter 4812 *( COMMA secondEventParameter ) RBRKT ] 4814 ; at-most-once each of embedSig , KeepActiveToken, eventDM or 4815 ; eventStream 4816 ; KeepActiveToken and embedSig must not both be present 4817 secondEventParameter = ( EmbedSig / KeepActiveToken / eventDM / 4818 eventStream / eventOther ) 4820 embedSig = EmbedToken LBRKT signalsDescriptor RBRKT 4822 eventStream = StreamToken EQUAL StreamID 4824 eventOther = eventParameterName parmValue 4826 eventParameterName = NAME 4828 Rosen et al Standards Track -- Expires Oct 2000 95 4829 eventDM = DigitMapToken ((EQUAL digitMapName ) / 4830 (LBRKT digitMapValue RBRKT )) 4832 signalsDescriptor = SignalsToken LBRKT [ signalParm 4833 *(COMMA signalParm)] RBRKT 4835 signalParm = signalList / signalRequest 4837 signalRequest = signalName [ LBRKT sigParameter 4838 *(COMMA sigParameter) RBRKT ] 4840 signalList = SignalListToken EQUAL signalListId LBRKT 4841 signalListParm *(COMMA signalListParm) RBRKT 4843 signalListId = UINT16 4845 ;exactly once signalType, at most once duration and every signal 4846 ;parameter 4847 signalListParm = signalRequest 4849 signalName = pkgdName 4850 ;at-most-once sigStream, at-most-once sigSignalType, 4851 ;at-most-once sigDuration, every signalParameterName at most once 4852 sigParameter = sigStream / sigSignalType / sigDuration / sigOther 4853 / notifyCompletion / KeepActiveToken 4854 sigStream = StreamToken EQUAL StreamID 4855 sigOther = sigParameterName parmValue 4856 sigParameterName = NAME 4857 sigSignalType = SignalTypeToken EQUAL signalType 4858 signalType = (OnOffToken / TimeOutToken / BriefToken) 4859 sigDuration = DurationToken EQUAL UINT16 4860 notifyCompletion = NotifyCompletionToken EQUAL ("ON" / "OFF") 4862 observedEventsDescriptor = ObservedEventsToken EQUAL RequestID 4863 LBRKT observedEvent *(COMMA observedEvent) RBRKT 4865 ;time per event, because it might be buffered 4866 observedEvent = [ TimeStamp LWSP COLON] LWSP 4867 pkgdName [ LBRKT observedEventParameter 4868 *(COMMA observedEventParameter) RBRKT ] 4870 ;at-most-once eventStream, every eventParameterName at most once 4871 observedEventParameter = eventStream / eventOther 4873 RequestID = UINT32 4875 modemDescriptor = ModemToken (( EQUAL modemType) / 4876 (LSBRKT modemType *(COMMA modemType) RSBRKT)) 4877 [ LBRKT NAME parmValue 4878 *(COMMA NAME parmValue) RBRKT ] 4880 Rosen et al Standards Track -- Expires Oct 2000 96 4881 ; at-most-once 4882 modemType = (V32bisToken / V22bisToken / V18Token / 4883 V22Token / V32Token / V34Token / V90Token / 4884 V91Token / SynchISDNToken / extensionParameter) 4886 digitMapDescriptor = DigitMapToken EQUAL digitMapName 4887 ( LBRKT digitMapValue RBRKT ) 4888 digitMapName = NAME 4889 digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA] 4890 ["L" COLON Timer COMMA] digitMap 4891 Timer = 1*2DIGIT 4892 digitMap = 4893 digitString / LWSP "(" LWSP digitStringList LWSP ")" LWSP) 4894 digitStringList = digitString *( LWSP "|" LWSP digitString ) 4895 digitString = 1*(digitStringElement) 4896 digitStringElement = digitPosition [DOT] 4897 digitPosition = digitMapLetter / digitMapRange 4898 digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) 4899 digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter) 4900 digitMapLetter = DIGIT ;Basic event symbols 4901 / %x41-4B / %x61-6B ; a-k, A-K 4902 / "L" / "S" ;Inter-event timers (long, short) 4903 / Z" ;Long duration modifier 4905 ;at-most-once 4906 auditItem = ( MuxToken / ModemToken / MediaToken / 4907 SignalsToken / EventBufferToken / 4908 DigitMapToken / StatsToken / EventsToken / 4909 ObservedEventsToken / PackagesToken ) 4911 serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm 4912 *(COMMA serviceChangeParm) RBRKT 4914 serviceChangeParm = (serviceChangeMethod / serviceChangeReason / 4915 serviceChangeDelay / serviceChangeAddress / 4916 serviceChangeProfile / extension / TimeStamp / 4917 serviceChangeMgcId / serviceChangeVersion ) 4919 serviceChangeReplyDescriptor = ServicesToken LBRKT 4920 servChgReplyParm *(COMMA servChgReplyParm) RBRKT 4922 ;at-most-once. Version is REQUIRED on first ServiceChange response 4923 servChgReplyParm = (serviceChangeAddress / serviceChangeMgcId / 4924 serviceChangeProfile / serviceChangeVersion ) 4925 serviceChangeMethod = MethodToken EQUAL (FailoverToken / 4926 ForcedToken / GracefulToken / RestartToken / 4927 DisconnectedToken / HandOffToken / 4928 extensionParameter) 4930 serviceChangeReason = ReasonToken EQUAL VALUE 4931 serviceChangeDelay = DelayToken EQUAL UINT32 4932 serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE 4934 Rosen et al Standards Track -- Expires Oct 2000 97 4935 serviceChangeMgcId = MgcIdToken EQUAL mId 4936 serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version 4937 serviceChangeVersion = VersionToken EQUAL Version 4938 extension = extensionParameter parmValue 4940 packagesDescriptor = PackagesToken LBRKT packagesItem 4941 *(COMMA packagesItem) RBRKT 4943 Version = 1*2(DIGIT) 4944 packagesItem = NAME "-" UINT16 4946 TimeStamp = Date "T" Time ; per ISO 8601:1988 4947 ; Date = yyyymmdd 4948 Date = 8(DIGIT) 4949 ; Time = hhmmssss 4950 Time = 8(DIGIT) 4951 statisticsDescriptor = StatsToken LBRKT statisticsParameter 4952 *(COMMA statisticsParameter ) RBRKT 4954 ;at-most-once per item 4955 statisticsParameter = pkgdName EQUAL VALUE 4957 topologyDescriptor = TopologyToken LBRKT terminationA COMMA 4958 terminationB COMMA topologyDirection RBRKT 4959 terminationA = TerminationID 4960 terminationB = TerminationID 4961 topologyDirection = BothwayToken / IsolateToken / OnewayToken 4963 priority = PriorityToken EQUAL UINT16 4965 extensionParameter = "X" ("-" / "+") 1*6(ALPHA / DIGIT) 4967 ; octetString is used to describe SDP defined in RFC2327. 4968 ; Caution should be taken if CRLF in RFC2327 is used. 4969 ; To be safe, use EOL in this ABNF. 4970 ; Whenever "}" appears in SDP, it is escaped by "\", e.g., "\}" 4971 octetString = *(nonEscapeChar) 4972 nonEscapeChar = ( "\}" / %x01-7C / %x7E-FF ) 4973 quotedString = DQUOTE 1*(SafeChar / RestChar/ WSP) DQUOTE 4975 UINT16 = 1*5(DIGIT) ; %x0-FFFF 4976 UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF 4978 NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 4979 VALUE = quotedString / 1*(SafeChar) 4980 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / 4981 "!" / "_" / "/" / "'" / "?" / "@" / 4982 "^" / "`" / "~" / "*" / "$" / "\" / 4983 "(" / ")" / "%" / "|" / "." 4985 EQUAL = LWSP %x3D LWSP ; "=" 4986 COLON = %x3A ; ":" 4988 Rosen et al Standards Track -- Expires Oct 2000 98 4989 LBRKT = LWSP %x7B LWSP ; "{" 4990 RBRKT = LWSP %x7D LWSP ; "}" 4991 COMMA = LWSP %x2C LWSP ; "," 4992 DOT = %x2E ; "." 4993 SLASH = %x2F ; "/" 4994 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 4995 DIGIT = %x30-39 ; 0-9 4996 DQUOTE = %x22 ; " (Double Quote) 4997 HEXDIG = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" ) 4998 SP = %x20 ; space 4999 HTAB = %x09 ; horizontal tab 5000 CR = %x0D ; Carriage return 5001 LF = %x0A ; linefeed 5002 LWSP = *( WSP / COMMENT / EOL ) 5003 EOL = (CR [LF] / LF ) 5004 WSP = SP / HTAB ; white space 5005 SEP = ( WSP / EOL / COMMENT) LWSP 5006 COMMENT = ";" *(SafeChar/ RestChar / WSP / %x22) EOL 5007 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" 5008 / 5009 "<" / ">" / "=" 5011 AddToken = ("Add" / "A") 5012 AuditToken = ("Audit" / "AT") 5013 AuditCapToken = ("AuditCapability" / "AC") 5014 AuditValueToken = ("AuditValue" / "AV") 5015 AuthToken = ("Authentication" / "AU") 5016 BothwayToken = ("Bothway" / "BW") 5017 BriefToken = ("Brief" / "BR") 5018 BufferToken = ("Buffer" / "BF") 5019 CtxToken = ("Context" / "C") 5020 ContextAuditToken = ("ContextAudit" / "CA") 5021 DigitMapToken = ("DigitMap" / "DM") 5022 DiscardToken = ("Discard" / "DS") 5023 DisconnectedToken = ("Disconnected" / "DC") 5024 DelayToken = ("Delay" / "DL") 5025 DurationToken = ("Duration" / "DR") 5026 EmbedToken = ("Embed" / "EB") 5027 EmergencyToken = ("Emergency" / "EM") 5028 ErrorToken = ("Error" / "ER") 5029 EventBufferToken = ("EventBuffer" / "EB") 5030 EventsToken = ("Events" / "E") 5031 FailoverToken = ("Failover" / "FL") 5032 ForcedToken = ("Forced" / "FO") 5033 GracefulToken = ("Graceful" / "GR") 5034 H221Token = ("H221" ) 5035 H223Token = ("H223" ) 5036 H226Token = ("H226" ) 5037 HandOffToken = ("HandOff" / "HO") 5038 InactiveToken = ("Inactive" / "IN") 5039 IsolateToken = ("Isolate" / "IS") 5041 Rosen et al Standards Track -- Expires Oct 2000 99 5042 InSvcToken = ("InService" / "IV") 5043 KeepActiveToken = ("KeepActive" / "KA") 5044 LocalToken = ("Local" / "L") 5045 LocalControlToken = ("LocalControl" / "O") 5046 LockStepToken = ("LockStep" / "SP") 5047 LoopbackToken = ("Loopback" / "LB") 5048 MediaToken = ("Media" / "M") 5049 MegacopToken = ("MEGACO" / "!") 5050 MethodToken = ("Method" / "MT") 5051 MgcIdToken = ("MgcIdToTry" / "MG") 5052 ModeToken = ("Mode" / "MO") 5053 ModifyToken = ("Modify" / "MF") 5054 ModemToken = ("Modem" / "MD") 5055 MoveToken = ("Move" / "MV") 5056 MTPToken = ("MTP") 5057 MuxToken = ("Mux" / "MX") 5058 NotifyToken = ("Notify" / "N") 5059 NotifyCompletionToken = ("NotifyCompletion" / "NC") 5060 ObservedEventsToken = ("ObservedEvents" / "OE") 5061 OnewayToken = ("Oneway" / "OW") 5062 OnOffToken = ("OnOff" / "OO") 5063 OutOfSvcToken = ("OutOfService" / "OS") 5064 PackagesToken = ("Packages" / "PG") 5065 PendingToken = ("Pending" / "PN") 5066 PriorityToken = ("Priority" / "PR") 5067 ProfileToken = ("Profile" / "PF") 5068 ReasonToken = ("Reason" / "RE") 5069 RecvonlyToken = ("ReceiveOnly" / "RC") 5070 ReplyToken = ("Reply" / "P") 5071 RestartToken = ("Restart" / "RS") 5072 RemoteToken = ("Remote" / "R") 5073 ReservedGroupToken = ("ReservedGroup" / "RG") 5074 ReservedValueToken = ("ReservedValue" / "RV") 5075 SendonlyToken = ("SendOnly" / "SO") 5076 SendrecvToken = ("SendReceive" / "SR") 5077 ServicesToken = ("Services" / "SV") 5078 ServiceStatesToken = ("ServiceStates" / "SI") 5079 ServiceChangeToken = ("ServiceChange" / "SC") 5080 ServiceChangeAddressToken = ("ServiceChangeAddress" / "AD") 5081 SignalListToken = ("SignalList" / "SL") 5082 SignalsToken = ("Signals" / "SG") 5083 SignalTypeToken = ("SignalType" / "SY") 5084 StatsToken = ("Statistics" / "SA") 5085 StreamToken = ("Stream" / "ST") 5086 SubtractToken = ("Subtract" / "S") 5087 SynchISDNToken = ("SynchISDN" / "SN") 5088 TerminationStateToken = ("TerminationState" / "TS") 5089 TestToken = ("Test" / "TE") 5090 TimeOutToken = ("TimeOut" / "TO") 5091 TopologyToken = ("Topology" / "TP") 5092 TransToken = ("Transaction" / "T") 5093 ResponseAckToken = ("TransactionResponseAck"/ "K") 5095 Rosen et al Standards Track -- Expires Oct 2000 100 5096 V18Token = ("V18") 5097 V22Token = ("V22") 5098 V22bisToken = ("V22b") 5099 V32Token = ("V32") 5100 V32bisToken = ("V32b") 5101 V34Token = ("V34") 5102 V76Token = ("V76") 5103 V90Token = ("V90") 5104 V91Token = ("V91") 5106 Rosen et al Standards Track -- Expires Oct 2000 101 5107 ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE) 5109 Parameters for Local descriptors and Remote descriptors are 5110 specified as tag-value pairs if binary encoding is used for the 5111 protocol. This annex contains the property names (PropertyID), the 5112 tags (Property Tag), type of the property (Type) and the values 5113 (Value).Values presented in the Value field when the field contains 5114 references shall be regarded as "information". The reference 5115 contains the normative values. If a value field does not contain a 5116 reference then the values in that field can be considered as 5117 "normative". 5119 Tags are given as hexadecimal numbers in this annex. When setting 5120 the value of a property, a MGC may underspecify the value according 5121 to one of the mechanisms specified in section 7.1.1. 5123 For type "enumeration" the value is represented by the value in 5124 brackets, e.g., Send(0), Receive(1). 5126 C.1 General Media Attributes 5128 PropertyID Property Type Value 5129 Tag 5131 Media 1001 Enumeration Audio(0), Video(1), 5132 Data(2), 5134 Transmission mode 1002 Enumeration Send(0), Receive(1), 5135 Send&Receive(2) 5137 Number of Channels 1003 Unsigned 0-255 5138 Integer 5139 Sampling rate 1004 Unsigned 0-2^32 5140 Integer 5141 Bitrate 1005 Integer (0..4294967295) 5142 Note - units of 100 bit/s 5144 ACodec 1006 Octet String Audio Codec Type: 5145 Reference: ITU-T Rec. Q.765 - Application transport mechanism. 5146 Non-ITU codecs are defined with the appropriate standards 5147 organisation under a defined Organizational Identitifier. 5149 Samplepp 1007 Unsigned Maximum samples or 5150 Integer frames per packet: 0- 5151 65535 5153 Silencesupp 1008 BOOLEAN Silence Suppression: 5154 True/false 5156 Encrypttype 1009 Octet string Ref.: rec. H.245 5158 Rosen et al Standards Track -- Expires Oct 2000 102 5159 Encryptkey 100A Octet string Encryption key 5160 SIZE(0..65535) 5161 Ref.: rec. H.235 5163 Echocanc 100B Enumeration Echo Canceller: 5164 Off(0), G.165(1), 5165 G168(2) 5167 Gain 100C Unsigned Gain in db: 0-65535 5168 Integer 5169 Jitterbuff 100D Unsigned Jitter buffer size in 5170 Integer ms: 0-65535 5172 PropDelay 100E Unsigned Propagation Delay: 5173 Integer 0..65535 5174 Maximum propagation delay in milliseconds for the bearer 5175 connection between two media gateways. The maximum delay will be 5176 dependent on the bearer technology. 5178 RTPpayload 100F integer Payload type in RTP 5179 Profile for Audio and 5180 Video Conferences 5181 with Minimal Control 5182 Ref.: RFC 1890 5184 C.2 Mux Properties 5186 PropertyID Property Type Value 5187 Tag 5189 H.221 2001 Octet Ref.: rec. H.245, 5190 string H222LogicalChannelParameters 5192 H223 2002 Octet Ref.: rec. H.245, 5193 string H223LogicalChannelParameters 5195 V76 2003 Octet Ref.: rec. H.245, 5196 String V76LogicalChannelParameters 5198 H2250 2004 Octet Ref.: rec. H.245, 5199 String H2250LogicalChannelParameters 5201 Rosen et al Standards Track -- Expires Oct 2000 103 5202 C.3 General bearer properties 5204 PropertyID Property Type Value 5205 Tag 5206 Mediatx 3001 Enumeration Media Transport Type: 5207 TDM Circuit(0), ATM(1), 5208 FR(2), Ipv4(3), Ipv6(4), 5209 _ 5211 BIR 3002 4 OCTET Value depends on 5212 transport technology 5214 NSAP 3003 1-20 OCTETS See NSAP 5215 Reference: ITU X.213 Annex A 5217 C.4 General ATM properties 5219 PropertyID Property Type Value 5220 Tag 5222 AESA 4001 20 OCTETS ATM End System Address 5224 VPVC 4002 2 x 16 bit VPC/VCI 5225 integer 5227 SC 4003 4 bits Service Category 5228 Reference: ITU Recommendation Q.2931 (1995) 5230 BCOB 4004 5 bit integer Broadband Bearer Class 5232 Reference: ITU Recommendation Q.2961.2 (06/97) 5234 BBTC 4005 octet Broadband Transfer 5235 Capability 5236 Reference: ITU Recommendation Q.2961 (10/95) 5238 ATC 4006 Enumeration I.371 ATM Traffic 5239 Capability 5240 Reference: ITU Recommendation I.371: 5241 DBR(0), SBR1(1), SBR2(2), SBR(3), ABT/IT(4), ABT/DT(5), ABR(6) 5243 STC 4007 2 bits Susceptibility to 5244 clipping 5245 Reference: ITU Recommendation Q.2931 (1995) 5246 00 Susceptible 5247 01 Not-susceptible 5249 Rosen et al Standards Track -- Expires Oct 2000 104 5250 UPCC 4008 2 bits User Plane Connection 5251 configuration: 5252 Reference: ITU Recommendation Q.2931 (1995) 5253 00 Pt-to-pt, 5254 01 Pt-to-mpt 5256 PCR0 4009 24 bit Peak Cell Rate (For 5257 integer CLP=0) 5258 Reference: ITU Recommendation I.371 5260 SCR0 400A 24 bit Sustainable Cell Rate 5261 integer (For CLP=0) 5262 Reference: ITU Recommendation I.371 5264 MBS0 400B 24 bit Maximum Burst Size (For 5265 integer CLP=0) 5266 Reference: ITU Recommendation I.371 5268 PCR1 400C 24 bit Peak Cell Rate (For 5269 integer CLP=0+1) 5270 Reference: ITU Recommendation I.371 5272 SCR2 400D 24 bit Sustainable Cell Rate 5273 integer (For CLP=0+1) 5274 Reference: ITU Recommendation I.371 5276 MBS3 400E 24 bit Maximum Burst Size (For 5277 integer CLP=0+1) 5279 Reference: ITU Recommendation I.371 5281 BEI 400F Boolean Best Effort Indicator 5283 TI 4010 Boolean Tagging 5285 FD 4011 Boolean Frame Discard 5287 FCDV 4012 24 bit Forward P-P CDV 5288 integer 5290 BCDV 4013 24 bit Backward P-P CDV 5291 integer 5293 FCLR0 4014 8 bit integer Forward Cell Loss Ratio 5294 (For CLP=0) 5296 BCLR0 4015 8 bit integer Backward P-P Cell Loss 5297 Ratio (For CLP=0) 5299 FCLR1 4016 8 bit integer Forward Cell Loss Ratio 5300 (For CLP=0+1) 5301 Rosen et al Standards Track -- Expires Oct 2000 105 5302 BCLR1 4017 8 bit integer Backward P-P Cell Loss 5303 Ratio (For CLP=0+1) 5305 FCDV 4018 24 bit Forward Cell Delay 5306 integer Variation 5308 BCDV 4019 24 bit Backward Cell Delay 5309 integer Variation 5311 FACDV 401A 24 bit Forward Acceptable P-P-P 5312 integer CDV 5314 BACDV 401B 24 bit Backward Acceptable P-P 5315 integer CDV 5317 FCCDV 401C 24 bit Forward Cumulative P-P 5318 integer CDV 5320 BCCDV 401D 24 bit Backward Cumulative P-P 5321 integer CDV 5323 FCLR 401E 8 bit integer Acceptable Forward Cell 5324 Loss Ratio 5326 BCLR 401F 8 bit integer Acceptable Backward Cell 5327 Loss Ratio 5329 EETD 4020 16 bit End-to-end transit delay 5330 integer 5332 Mediatx (See 4021 AAL Type 5333 General 5334 Properties) 5335 Reference: ITU Recommendation Q.2931 (1995) 5337 QosClass 4022 Integer 0-4 Qos Class 5338 Reference: ITU Recommendation Q.2931 (1995) 5339 QoS Parameter Application: 5340 Qos Class0 QoS ApplicationBest Effort 5341 Parameter Unspecified 5343 0 Unspecified Best EffortConstant Bit rate 5344 Specified circuit emulation 5345 1 Specified Constant Bit rate circuit 5346 Specified emulationVariable bit rate 5347 video and audio 5348 2 Specified Variable bit rate video and 5349 Specified audioConnection-oriented data 5350 3 Specified Connection-oriented 5351 Specified dataConnectionless data 5353 Rosen et al Standards Track -- Expires Oct 2000 106 5354 4 Specified Connectionless data 5356 AALtype 4023 1 OCTET AAL Type 5357 Reference: ITU Recommendation Q.2931 (1995) 5358 00000000 AAL for voice 5359 00000001 AAL type 1 5360 00000010 AAL type 2 5361 00000011 AAL type 3/4 5362 00000101 AAL type 5 5363 00010000 user defined AAL 5365 C.5 Frame Relay 5367 PropertyID Property Type Value 5368 Tag 5370 DLCI 5001 Unsigned Integer Data link connection 5371 id 5373 CID 5002 Unsigned Integer sub-channel id. 5375 SID/Noiselevel 5003 Unsigned Integer silence insertion 5376 descriptor 5378 Primary Payload 5004 Unsigned Integer Primary Payload Type 5379 type 5380 Covers FAX and codecs 5382 C.6 IP 5384 PropertyID Property Type Value 5385 Tag 5387 IPv4 6001 32 BITS Ipv4Address: 5388 Ipv4Address 5389 Reference: IETF RFC791 5391 IPv6 6002 128 BITS IPv6 Address: 5392 Reference: IETF RFC2460 5394 Port 6003 unsigned integer 0-65535 5396 Porttype 6004 enumerated TCP(0), UDP(1), 5397 SCTP(2) 5399 Rosen et al Standards Track -- Expires Oct 2000 107 5400 C.7 ATM AAL2 5402 PropertyID Property Type Value 5403 Tag 5405 AESA 7001 20 OCTETS AAL2 service endpoint 5406 address 5407 as defined in Reference: ITU Recommendation Q.2630.1 5408 ESEA 5409 NSEA 5411 BIR See C.3 4 OCTETS Served user generated 5412 reference 5413 as defined in Reference: ITU Recommendation Q.2630.1 5414 SUGR 5416 ALC 7002 12 OCTETS AAL2 link 5417 characteristics 5418 as defined in Reference: ITU Recommendation Q.2630.1 5419 max/average CPS-SDU bitrate, 5420 max/average CPS-SDU size 5422 SSCS 7003 I.366.2: Service 5423 audio (8 OCTETS) specific 5424 multirate (3 OCTETS) convergence 5425 or I.366.1: sublayer 5426 SAR-assured (14 OCTETS)/ information 5427 unassured (7 OCTETS) 5428 as defined in Reference: Q.2630.1 and used in I.366.1 and I.366.2 5429 I.366.2: audio/multirate 5430 I.366.1: SAR-assured/unassured 5432 SUT 7004 1..254 octets Served user transport 5433 parameter 5434 as defined in Reference: ITU Recommendation Q.2630.1 5436 TCI 7005 BOOLEAN Test connection 5437 indicator 5439 as defined in Reference: ITU Recommendation Q.2630.1 5441 Timer_CU 7006 32 bit integer Timer-CU: Milliseconds 5442 to hold partially 5443 filled cell before 5444 sending. 5446 MaxCPSSDU 7007 8 bit integer Maximum Common Part 5447 Sublayer Service Data 5448 Unit 5449 Ref.: rec. Q.2630.1 5451 Rosen et al Standards Track -- Expires Oct 2000 108 5452 SCLP 7008 Boolean Set Cell Local 5453 PriorityLP bit: 5454 True if CLP bit is to 5455 be set 5457 EETR 7009 Boolean Timing Requirements 5458 Reference: ITU Recommendation Q.2931 (1995) 5459 End to End Timing Required: 5460 In broadband bearer capability 5462 CID 700A 8 bits subchannel id, 0-255 5463 Ref.: rec. I.363.2 (09/97) 5465 C.8 ATM AAL1 5467 PropertyID Property Type Value 5468 Tag 5470 BIR See GIT (Generic 5471 Table Identifier Transport) 4 OCTETS 5472 C.3 5473 Ref.: Recommendation Q.2941.1 (09/97) 5475 AAL1ST 8001 1 OCTET AAL1 Subtype: 5477 Reference: ITU Recommendation Q.2931 (1995) 5478 00000000 Null 5479 00000001 voiceband signal transport on 64kbit/s 5480 00000010 circuit transport 5481 00000100 high-quality audio signal transport 5482 00000101 video signal transport 5484 CBRR 8002 1 OCTET CBR Rate 5485 Reference: ITU Recommendation Q.2931 (1995) 5486 00000001 64 kbit/s 5487 00000100 1544 kbit/s 5488 00000101 6312 kbit/s 5489 00000110 32064 kbit/s 5490 00000111 44736 kbit/s 5491 00001000 97728 kbit/s 5492 00010000 2048 kbit/s 5493 00010001 8448 kbit/s 5494 00010010 34368 kbit/s 5495 00010011 139264 kbit/s 5496 01000000 n x 64 kbit/s 5497 01000001 n * 8 kbit/s 5499 MULT See Multiplier, or n x 5500 Table 64k/8k/300 5501 C.9 5503 Rosen et al Standards Track -- Expires Oct 2000 109 5504 Reference: ITU Recommendation Q.2931 (1995) 5506 SCRI 8003 1 OCTECT Source Clock Frequency 5507 Recovery Method 5508 Reference: ITU Recommendation Q.2931 (1995) 5509 00000000 NULL 5510 00000001 SRTS 5511 00000010 ACM 5513 ECM 8004 1 OCTECT Error Correction 5514 Method 5515 Reference: ITU Recommendation Q.2931 (1995) 5516 00000000 Null 5517 00000001 FEC-LOSS 5518 00000010 FEC-DELAY 5520 SDTB 8005 16 bit integer Structured Data 5521 Transfer Blocksize 5522 Reference: ITU Recommendation I.363.1 5523 Block size of SDT CBR service 5525 PFCI 8006 8 bit integer Partially filled cells 5526 indentifier 5527 Reference: ITU Recommendation I.363.1 5528 1-47 5530 EETR See See Table C.7 See Table C.7 5531 Table 5532 C.7 5534 C.9 Bearer Capabilities 5536 PropertyID Property Type Value 5537 Tag 5539 TMR 9001 1 OCTET Transmission Medium 5540 Requirement (Q.763) 5542 Rosen et al Standards Track -- Expires Oct 2000 110 5543 Reference: ITU Recommendation Q.763(09/97) 5544 Bit 8 7 6 5 4 3 2 1 5545 00000000 - speech 5546 00000001 - spare 5547 00000010 - 64 kbit/s unrestricted 5548 00000011 - 3.1 kHz audio 5549 00000100 - reserved for alternate speech (service 2)/64 kbit/s 5550 unrestricted (service 1) 5551 00000101 - reserved for alternate 64 kbit/s unrestricted (service 5552 1)/speech (service 2) 5553 00000110 - 64 kbit/s preferred 5554 00000111 - 2 x 64 kbit/s unrestricted 5555 00001000 - 384 kbit/s unrestricted 5556 00001001 - 1536 kbit/s unrestricted 5557 00001010 - 1920 kbit/s unrestricted 5558 00001011 through 00001111- spare 5559 00010000 - 3 x 64 kbit/s unrestricted 5560 00010001 - 4 x 64 kbit/s unrestricted 5561 00010010 - 5 x 64 kbit/s unrestricted 5562 00010011 spare 5563 00010100 - 7 x 64 kbit/s unrestricted 5564 00010101 - 8 x 64 kbit/s unrestricted 5565 00010110 - 9 x 64 kbit/s unrestricted 5566 00010111 - 10 x 64 kbit/s unrestricted 5567 00011000 - 11 x 64 kbit/s unrestricted 5568 00011001 - 12 x 64 kbit/s unrestricted 5569 00011010 - 13 x 64 kbit/s unrestricted 5570 00011011 - 14 x 64 kbit/s unrestricted 5571 00011100 - 15 x 64 kbit/s unrestricted 5572 00011101 - 16 x 64 kbit/s unrestricted 5573 00011110 - 17 x 64 kbit/s unrestricted 5574 00011111 - 18 x 64 kbit/s unrestricted 5575 00100000 - 19 x 64 kbit/s unrestricted 5576 00100001 - 20 x 64 kbit/s unrestricted 5577 00100010 - 21 x 64 kbit/s unrestricted 5578 00100011 - 22 x 64 kbit/s unrestricted 5579 00100100 - 23x 64 kbit/s unrestricted 5580 00100101 - spare 5581 00100110 - 25 x 64 kbit/s unrestricted 5582 00100111 - 26 x 64 kbit/s unrestricted 5583 00101000 - 27 x 64 kbit/s unrestricted 5584 00101001 - 28 x 64 kbit/s unrestricted 5585 00101010 - 29 x 64 kbit/s unrestricted 5586 00101011 through 11111111 Spare 5588 TMRSR 9002 1 OCTET Transmission Medium 5589 Requirement Subrate 5591 Rosen et al Standards Track -- Expires Oct 2000 111 5592 0 - unspecified 5593 1 - 8kbit/s 5594 2 - 16kbit/s 5595 3 - 32kbit/s 5597 Contcheck 9003 BOOLEAN Continuity Check 5598 Reference: ITU Recommendation Q.763(09/97) 5599 0 - Not required on this circuit 5600 1 - Required on this circuit 5602 ITC 9004 5 BITS Information Transfer 5603 Capability 5604 Reference: ITU Recommendation Q.763(09/97) 5605 Bits 5 4 3 2 1 5606 00000 - Speech 5607 01000 -Unrestricted digital information 5608 01001- Restricted digital information 5609 10000 3.1 kHz audio 5610 10001 - Unrestricted digital information with tones/announcements 5611 (Note 2) 5612 11000 -Video 5613 All other values are reserved. 5615 TransMode 9005 2 BITS Transfer Mode 5616 Reference: ITU Recommendation Q.931 (1998) 5617 Bit 2 1 5618 00 - Circuit mode 5619 10 - Packet mode 5621 TransRate 9006 5 BITS Transfer Rate 5622 Reference: ITU Recommendation Q.931 (1998) 5623 Bit 5 4 3 2 1 5624 00000 - This code shall be used for packet mode calls 5625 10000 - 64 kbit/s 5626 10001 - 2 x 64 kbit/s 5627 10011 -384 kbit/s 5628 10101 -1536 kbit/s 5629 10111 -1920 kbit/s 5630 11000 - Multirate (64 kbit/s base rate) 5632 MULT 9007 7 BITS Rate Multiplier 5633 Reference: ITU Recommendation Q.931 (1998) 5634 Any value from 2 to n (maximum number of B-channels) 5636 Rosen et al Standards Track -- Expires Oct 2000 112 5637 USI 9008 5 BITS User Information Layer 5638 1 Protocol 5639 Reference: ITU Recommendation Q.931 (1998) 5640 Bits 5 4 3 2 1 5641 00001 - CCITT standardized rate adaption V.110 and X.30. 5642 00010 - Recommendation G.711 u-law 5643 00011 - Recommendation G.711 A-law 5644 00100 - Recommendation G.721 32 kbit/s ADPCM and Recommendation 5645 I.460. 5646 00101 - Recommendations H.221 and H.242 5647 00110 - Recommendations H.223 and H.245 5648 00111 - Non-ITU-T standardized rate adaption. 5649 01000 - ITU-T standardized rate adaption V.120. 5650 01001 - CCITT standardized rate adaption X.31 HDLC flag stuffing. 5651 All other values are reserved. 5653 syncasync 9009 BOOLEAN Synchronous/ 5654 Asynchronous 5655 Reference: ITU Recommendation Q.931 (1998) 5656 0 - Synchronous data 5657 1 - Asynchronous data 5659 negotiation 900A BOOLEAN Negotiation 5660 Reference: ITU Recommendation Q.931 (1998) 5661 0 - In-band negotiation possible 5662 1 - In-band negotiation not possible 5664 Rosen et al Standards Track -- Expires Oct 2000 113 5665 Userrate 900B 5 BITS User Rate 5666 Reference: ITU Recommendation Q.931 (1998) 5667 Bits 5 4 3 2 1 5668 00000 - Rate is indicated by E-bits specified in Recommendation 5669 I.460 or may be negotiated in-band 5670 00001 - 0.6 kbit/s Recommendations V.6 and X.1 5671 00010 - 1.2 kbit/s Recommendation V.6 5672 00011 - 2.4 kbit/s Recommendations V.6 and X.1 5673 00100 - 3.6 kbit/s Recommendation V.6 5674 00101 - 4.8 kbit/s Recommendations V.6 and X.1 5675 00110 - 7.2 kbit/s RecommendationV.6 5676 00111 - 8 kbit/s Recommendation I.460 5677 01000 - 9.6 kbit/s Recommendations V.6 and X.1 5678 01001 - 14.4 kbit/s Recommendation V.6 5679 01010 - 16 kbit/s Recommendation I.460 5680 01011 - 19.2 kbit/s Recommendation V.6 5681 01100 - 32 kbit/s Recommendation I.460 5682 01101 - 38.4 kbit/s Recommendation V.110 5683 01110 - 48 kbit/s Recommendations V.6 and X.1 5684 01111 - 56 kbit/s Recommendation V.6 5685 10010 - 57.6 kbit/s Recommendation V.14 extended 5686 10011 - 28.8 kbit/s Recommendation V.110 5687 10100 - 24 kbit/s Recommendation V.110 5688 10101 - 0.1345 kbit/s Recommendation X.1 5689 10110 - 0.100 kbit/s Recommendation X.1 5690 10111 - 0.075/1.2 kbit/s Recommendations V.6 and X.1 5691 11000 - 1.2/0.075 kbit/s Recommendations V.6 and X.1 5692 11001 - 0.050 kbit/s Recommendations V.6 and X.1 5693 11010 - 0.075 kbit/s Recommendations V.6 and X.1 5694 11011 - 0.110 kbit/s Recommendations V.6 and X.1 5695 11100 - 0.150 kbit/s Recommendations V.6 and X.1 5696 11101 - 0.200 kbit/s Recommendations V.6 and X.1 5697 11110 - 0.300 kbit/s Recommendations V.6 and X.1 5698 11111 - 12 kbit/s Recommendation V.6 5699 All other values are reserved. 5701 INTRATE 900C 2 BITS Intermediate Rate 5702 Reference: ITU Recommendation Q.931 (1998) 5703 Bit 2 1 5704 00 - Not used 5705 01 - 8 kbit/s 5706 10 - 16 kbit/s 5707 11 - 32 kbit/s 5709 nictx 900D BOOLEAN Network Independent 5710 Clock (NIC) on 5711 transmission 5712 Reference: ITU Recommendation Q.931 (1998) 5713 0 - Not required to send data with network independent clock 5714 1 - Required to send data with network independent clock 5716 Rosen et al Standards Track -- Expires Oct 2000 114 5717 nicrx 900E BOOLEAN Network independent 5718 clock (NIC) on 5719 reception 5720 Reference: ITU Recommendation Q.931 (1998) 5721 0 - Cannot accept data with network independent clock (i.e. 5722 sender does not support this optional procedure) 5723 1 - Can accept data with network independent clock (i.e. sender 5724 does support this optional procedure) 5726 flowconttx 900F BOOLEAN Flow Control on 5727 transmission (Tx) 5728 Reference: ITU Recommendation Q.931 (1998) 5729 0 - Not required to send data with flow control mechanism 5730 1 - Required to send data with flow control mechanism 5732 flowcontrx 9010 BOOLEAN Flow control on 5733 reception (Rx) 5734 Reference: ITU Recommendation Q.931 (1998) 5735 0 - Cannot accept data with flow control mechanism (i.e. sender 5736 does not support this optional procedure) 5737 1 - Can accept data with flow control mechanism (i.e. sender does 5738 support this optional procedure) 5740 rateadapthdr 9011 BOOLEAN Rate adaption 5741 header/no header 5742 Reference: ITU Recommendation Q.931 (1998) 5743 0 - Rate adaption header not included 5744 1 - Rate adaption header included 5746 multiframe 9012 BOOLEAN Multiple frame 5747 establishment support 5748 in data link 5749 Reference: ITU Recommendation Q.931 (1998) 5750 0 - Multiple frame establishment not supported. Only UI frames 5751 allowed. 5752 1 - Multiple frame establishment supported 5754 OPMODE 9013 BOOLEAN Mode of operation 5755 Reference: ITU Recommendation Q.931 (1998) 5756 0 Bit transparent mode of operation 5757 1 Protocol sensitive mode of operation 5759 llidnegot 9014 BOOLEAN Logical link 5760 identifier negotiation 5761 Reference: ITU Recommendation Q.931 (1998) 5762 0 Default, LLI = 256 only 5763 1 Full protocol negotiation 5765 Rosen et al Standards Track -- Expires Oct 2000 115 5766 assign 9015 BOOLEAN Assignor/assignee 5767 Reference: ITU Recommendation Q.931 (1998) 5768 0 Message originator is "Default assignee" 5769 1 Message originator is "Assignor only" 5771 inbandneg 9016 BOOLEAN In-band/out-band 5772 negotiation 5773 Reference: ITU Recommendation Q.931 (1998) 5774 0- Negotiation is done with USER INFORMATION messages on a 5775 temporary signalling connection 5776 1- Negotiation is done in-band using logical link zero 5778 stopbits 9017 2 BITS Number of stop bits 5779 Reference: ITU Recommendation Q.931 (1998) 5780 Bits 2 1 5781 00 - Not used 5782 01 - 1 bit 5783 10 - 1.5 bits 5784 11 - 2 bits 5786 databits 9018 2 BIT Number of data bits 5787 excluding parity Bit 5788 if present 5789 Reference: ITU Recommendation Q.931 (1998) 5790 Bit 2 1 5791 00 - Not used 5792 01 - 5 bits 5793 10 - 7 bits 5794 11 - 8 bits 5796 parity 9019 3 BIT Parity information 5797 Reference: ITU Recommendation Q.931 (1998) 5798 Bit 3 2 1 5799 000 - Odd 5800 010 - Even 5801 011 -None 5802 100 - Forced to 0 5803 101 - Forced to 1 5804 All other values are reserved. 5806 duplexmode 901A BOOLEAN Mode duplex 5807 Reference: ITU Recommendation Q.931 (1998) 5808 0 - Half duplex 5809 1 - Full duplex 5811 Rosen et al Standards Track -- Expires Oct 2000 116 5812 modem 901B 6 BIT Modem Type 5813 Reference: ITU Recommendation Q.931 (1998) 5814 Bits 6 5 4 3 2 1 5815 00000 through 000101 National Use 5816 010001 - Recommendation V.21 5817 010010 - Recommendation V.22 5818 010011 - Recommendation V.22 bis 5819 010100 - Recommendation V.23 5820 010101 - Recommendation V.26 5821 011001 - Recommendation V.26 bis 5822 010111 -Recommendation V.26 ter 5823 011000 - RecommendationV.27 5824 011001 - Recommendation V.27 bis 5825 011010 - Recommendation V.27 ter 5826 011011 - Recommendation V.29 5827 011101 - Recommendation V.32 5828 011110 - Recommendation V.34 5829 100000 through 101111 National Use 5830 110000 through 111111 User Specified 5832 layer2prot 901C 5 BIT User information layer 5833 2 protocol 5834 Reference: ITU Recommendation Q.931 (1998) 5835 Bit 5 4 3 2 1 5836 00010 - Recommendation Q.921/I.441 [3] 5837 00110 - Recommendation X.25 [5], link layer 5838 01100 - LAN logical link control (ISO/IEC 8802-2) 5839 All other values are reserved. 5841 layer3prot 901D 5 BIT User information layer 5842 3 protocol 5843 Reference: ITU Recommendation Q.931 (1998) 5844 Bit 5 4 3 2 1 5845 00010 - Recommendation Q.931/I.451 5846 00110 - Recommendation X.25, packet layer 5847 01011 - ISO/IEC TR 9577 (Protocol identification in the network 5848 layer) 5849 All other values are reserved. 5851 addlayer3prot 901E OCTET Additional User 5852 Information layer 3 5853 protocol 5854 Reference: ITU Recommendation Q.931 (1998) 5856 Bits 4321 4321 5857 1100 1100 - Internet Protocol (RFC 791) (ISO/IEC TR 9577) 5858 1100 1111 - Point-to-point Protocol (RFC 1548) 5860 DialledN 901F 30 OCTETS Dialled Number 5861 DiallingN 9020 30 OCTETS Dialling Number 5863 Rosen et al Standards Track -- Expires Oct 2000 117 5864 ECHOCI 9021 Enumeration Echo Control 5865 Information 5866 echo canceler off (0), incoming echo canceler on (1), outgoing 5867 echo canceler on (2), incoming and outgoing echo canceler on (3) 5869 NCI 9022 1 OCTET Nature of Connection 5870 Indicators 5871 Reference: ITU Recommendation Q.763 5873 Bits 8 7 6 5 4 3 2 1 5874 Bits 2 1 Satellite Indicator 5875 0 0 no satellite circuit in the connection 5876 0 1 one satellite circuit in the connection 5877 1 0 two satellite circuits in the connection 5878 1 1 spare 5880 Bits 4 3 Continuity check indicator 5881 0 0 continuity check not required 5882 0 1 continuity check required on this circuit 5883 1 0 continuity check performed on a previous circuit 5884 1 1 spare 5886 Bits 5 Echo control device indicator 5887 0 outgoing echo control device not included 5888 1 outgoing echo control device included 5890 Bits 8 7 6 Spare 5892 C.10 AAL5 Properties 5894 PropertyID Property Type Value 5895 Tag 5897 FMSDU A001 32 bit integer Forward Maximum CPCS- 5898 SDU Size: 5899 Reference: ITU Recommendation Q.2931 (1995) 5900 Maximum CPCS-SDU size sent in the direction from the calling user 5901 to the called user. 5903 BMSDU A002 32 bit integer Backwards Maximum 5904 CPCS-SDU Size 5905 Reference: ITU Recommendation Q.2931 (1995) 5906 Maximum CPCS-SDU size sent in the direction from the called user 5907 to the calling user. 5909 Rosen et al Standards Track -- Expires Oct 2000 118 5910 SSCS See See table C.7 See table C.7 5911 table 5912 C.7 5913 Additional values: 5914 VPI/VCI 5916 SC See See Table C.4 See table C.4 5917 Table 5918 C.4 5920 C.11 SDP Equivalents 5922 PropertyID Property Type Value 5923 Tag 5925 SDP_V B001 STRING Protocol Version 5927 SDP_O B002 STRING Owner/creator and 5928 session ID 5930 SDP_S B003 STRING Sesson name 5932 SDP_I B004 STRING Session identifier 5934 SDP_U B005 STRING URI of descriptor 5936 SDC_E B006 STRING email address 5938 SDP_P B007 STRING phone number 5940 SDP_C B008 STRING Connection information 5942 SDP_B B009 STRING Bandwidth Information 5944 SDP_Z B00A STRING time zone adjustment 5946 SDP_K B00B STRING Encryption Key 5948 SDP_A B00C STRING Zero or more session 5949 attributes 5951 SDP_T B00D STRING Active Session Time 5953 SDP_R B00E STRING Zero or more repeat 5954 times 5956 Reference in all cases: IETF RFC2327, "Session Description 5957 Protocol" 5959 Rosen et al Standards Track -- Expires Oct 2000 119 5960 C.12 H.245 5962 PropertyID Property Type Value 5963 Tag 5964 OLC C001 octet string The value of H.245 5965 OpenLogicalChannel 5966 structure. 5967 OLCack C002 octet string The value of H.245 5968 OpenLogicalChannelAck 5969 structure. 5970 OLCcnf C003 octet string The value of H.245 5971 OpenLogicalChannelConfirm 5972 structure. 5973 OLCrej C004 octet string The value of H.245 5974 OpenLogicalChannelReject 5975 structure. 5976 CLC C005 octet string The value of H.245 5977 CloseLogicalChannel 5978 structure. 5979 CLCack C006 octet string The value of H.245 5980 CloseLogicalChannelAck 5981 structure. 5982 Reference in all cases: ITU-T Recommendation H.245 5984 Rosen et al Standards Track -- Expires Oct 2000 120 5985 ANNEX D TRANSPORT OVER IP (NORMATIVE) 5987 D.1 Transport over IP/UDP using Application Level Framing 5989 Protocol messages defined in this document may be transmitted over 5990 UDP. When no port is provided by the peer (see section 7.2.8), 5991 commands should be sent to the default port number, 2944 for text- 5992 encoded operation or 2945 for binary-encoded operation. Responses 5993 must be sent to the address and port from which the corresponding 5994 commands were sent except if the response is to a handoff or 5995 failover, in which case the procedures of 11.5 apply. 5997 Implementors using IP/UDP with ALF should be aware of the 5998 restrictions of the MTU on the maximum message size. 6000 D.1.1 Providing At-Most-Once Functionality 6002 Messages, being carried over UDP, may be subject to losses. In the 6003 absence of a timely response, commands are repeated. Most commands 6004 are not idempotent. The state of the MG would become unpredictable 6005 if, for example, Add commands were executed several times. The 6006 transmission procedures shall thus provide an "At- Most-Once" 6007 functionality. 6009 Peer protocol entities are expected to keep in memory a list of the 6010 responses that they sent to recent transactions and a list of the 6011 transactions that are currently outstanding. The transaction 6012 identifier of each incoming message is compared to the transaction 6013 identifiers of the recent responses sent to the same MId. If a match 6014 is found, the entity does not execute the transaction, but simply 6015 repeats the response. If no match is found, the message will be 6016 compared to the list of currently outstanding transactions. If a 6017 match is found in that list, indicating a duplicate transaction, the 6018 entity does not execute the transaction (see section 8.2.3 for 6019 procedures on sending TransactionPending). 6021 The procedure uses a long timer value, noted LONG-TIMER in the 6022 following. The timer should be set larger than the maximum duration 6023 of a transaction, which should take into account the maximum number 6024 of repetitions, the maximum value of the repetition timer and the 6025 maximum propagation delay of a packet in the network. A suggested 6026 value is 30 seconds. 6028 The copy of the responses may be destroyed either LONG-TIMER seconds 6029 after the response is issued, or when the entity receives a 6030 confirmation that the response has been received, through the 6031 "Response Acknowledgement parameter". For transactions that are 6032 acknowledged through this parameter, the entity shall keep a copy of 6033 the transaction-id for LONG-TIMER seconds after the response is 6034 issued, in order to detect and ignore duplicate copies of the 6035 transaction request that could be produced by the network. 6037 Rosen et al Standards Track -- Expires Oct 2000 121 6038 D.1.2 Transaction identifiers and three-way handshake 6040 D.1.2.1 Transaction identifiers 6042 Transaction identifiers are 32 bit integer numbers. A Media Gateway 6043 Controller may decide to use a specific number space for each of the 6044 MGs that they manage, or to use the same number space for all MGs 6045 that belong to some arbitrary group. MGCs may decide to share the 6046 load of managing a large MG between several independent processes. 6047 These processes will share the same transaction number space. There 6048 are multiple possible implementations of this sharing, such as 6049 having a centralized allocation of transaction identifiers, or pre- 6050 allocating non-overlapping ranges of identifiers to different 6051 processes. The implementations shall guarantee that unique 6052 transaction identifiers are allocated to all transactions that 6053 originate from a logical MGC (identical mId). MGs can simply detect 6054 duplicate transactions by looking at the transaction identifier and 6055 mId only. 6057 D.1.2.2 Three-way handshake 6059 The TransactionResponse Acknowledgement parameter can be found in 6060 any message. It carries a set of "confirmed transaction-id ranges". 6061 Entities may choose to delete the copies of the responses to 6062 transactions whose id is included in "confirmed transaction-id 6063 ranges" received in the transaction response messages. They should 6064 silently discard further commands when the transaction-id falls 6065 within these ranges. 6067 The "confirmed transaction-id ranges" values shall not be used if 6068 more than LONG-TIMER seconds have elapsed since the MG issued its 6069 last response to that MGC, or when a MG resumes operation. In this 6070 situation, transactions should be accepted and processed, without 6071 any test on the transaction-id. 6073 Messages that carry the "Transaction Response Acknowledgement" 6074 parameter may be transmitted in any order. The entity shall retain 6075 the "confirmed transaction-id ranges" receivedfor LONG-TIMER 6076 seconds. 6078 In the binary encoding, if only the firstAck is present in a 6079 response acknowledgement (see Annex A.2), only one transaction is 6080 acknowledged. If both firstAck and lastAck are present, then the 6081 range of transactions from firstAck to lastAck is acknowledged. In 6082 the text encoding, a horizontal dash is used to indicate a range of 6083 transactions being acknowledged (see Annex B.2). 6085 D.1.3 Computing retransmission timers 6087 It is the responsibility of the requesting entity to provide 6088 suitable time outs for all outstanding transactions, and to retry 6089 transactions when time outs have been exceeded. Furthermore, when 6091 Rosen et al Standards Track -- Expires Oct 2000 122 6092 repeated transactions fail to be acknowledged, it is the 6093 responsibility of the requesting entity to seek redundant services 6094 and/or clear existing or pending connections. 6096 The specification purposely avoids specifying any value for the 6097 retransmission timers. These values are typically network dependent. 6098 The retransmission timers should normally estimate the timer value 6099 by measuring the time spent between the sending of a command and the 6100 return of a response. 6102 Note - One possibility is to use the algorithm implemented in TCP- 6103 IP, which uses two variables: 6105 . The average acknowledgement delay, AAD, estimated through an 6106 exponentially smoothed average of the observed delays. 6108 . The average deviation, ADEV, estimated through an exponentially 6109 smoothed average of the absolute value of the difference between 6110 the observed delay and the current average. The retransmission 6111 timer, in TCP, is set to the sum of the average delay plus N times 6112 the average deviation. The maximum value of the timer should 6113 however be bounded for the protocol defined in this document, in 6114 order to guarantee that no repeated packet would be received by 6115 the gateways after LONG-TIMER seconds. A suggested maximum value 6116 is 4 seconds. 6118 After any retransmission, the entity should do the following: 6120 . It should double the estimated value of the average delay, AAD 6122 . It should compute a random value, uniformly distributed between 6123 0.5 AAD and AAD 6125 . It should set the retransmission timer to the sum of that random 6126 value and N times the average deviation. 6128 This procedure has two effects. Because it includes an exponentially 6129 increasing component, it will automatically slow down the stream of 6130 messages in case of congestion. Because it includes a random 6131 component, it will break the potential synchronization between 6132 notifications triggered by the same external event. 6134 D.1.4 Provisional responses 6136 Executing some transactions may require a long time. Long execution 6137 times may interact with the timer based retransmission procedure. 6138 This may result either in an inordinate number of retransmissions, 6139 or in timer values that become too long to be efficient. Entities 6140 that can predict that a transaction will require a long execution 6141 time may send a provisional response, "Transaction Pending". 6143 Rosen et al Standards Track -- Expires Oct 2000 123 6144 Entities that receive a Transaction Pending shall switch to a 6145 different repetition timer for repeating requests. The root 6146 termination has a property (ProvisionalResponseTimerValue), which 6147 can be set to the requested maximum number of milliseconds between 6148 receipt of a command and transmission of the TransactionPending 6149 response. Upon receipt of a final response, an immediate 6150 confirmation shall be sent, and normal repetition timers shall be 6151 used thereafter. Receipt of a Transaction Pending after receipt of 6152 a reply shall be ignored. 6154 D.1.5 Repeating Requests, Responses and Acknowledgements 6156 The protocol is organized as a set of transactions, each of which is 6157 composed request and a response, commonly referred to as an 6158 acknowledgement. The protocol messages, being carried over UDP, may 6159 be subject to losses. In the absence of a timely response, 6160 transactions are repeated. Entities are expected to keep in memory a 6161 list of the responses that they sent to recent transactions, i.e. a 6162 list of all the responses they sent over the last LONG-TIMER 6163 seconds, and a list of the transactions that are currently being 6164 executed. 6166 The repetition mechanism is used to guard against three types of 6167 possible errors: 6168 . transmission errors, when for example a packet is lost due to 6169 noise on a line or congestion in a queue; 6170 . component failure, when for example an interface to a entity 6171 becomes unavailable; 6172 . entity failure, when for example an entire entity become 6173 unavailable. 6175 The entities should be able to derive from the past history an 6176 estimate of the packet loss rate due to transmission errors. In a 6177 properly configured system, this loss rate should be kept very low, 6178 typically less than 1%. If a Media Gateway Controller or a Media 6179 Gateway has to repeat a message more than a few times, it is very 6180 legitimate to assume that something else than a transmission error 6181 is occurring. For example, given a loss rate of 1%, the probability 6182 that five consecutive transmission attempts fail is 1 in 100 6183 billion, an event that should occur less than once every 10 days for 6184 a Media Gateway Controller that processes 1 000 transactions per 6185 second. (Indeed, the number of repetition that is considered 6186 excessive should be a function of the prevailing packet loss rate.) 6187 We should note that the "suspicion threshold", which we will call 6188 "Max1", is normally lower than the "disconnection threshold", which 6189 should be set to a larger value. 6191 A classic retransmission algorithm would simply count the number of 6192 successive repetitions, and conclude that the association is broken 6193 after retransmitting the packet an excessive number of times 6194 (typically between 7 and 11 times.) In order to account for the 6195 possibility of an undetected or in-progress "failover", we modify 6197 Rosen et al Standards Track -- Expires Oct 2000 124 6198 the classic algorithm so that if the Media Gateway receives a valid 6199 ServiceChange message announcing a failover, it will start 6200 transmitting outstanding commands to that new MGC. Responses to 6201 commands are still transmitted to the source address of the command. 6203 In order to automatically adapt to network load, this document 6204 specifies exponentially increasing timers. If the initial timer is 6205 set to 200 milliseconds, the loss of a fifth retransmission will be 6206 detected after about 6 seconds. This is probably an acceptable 6207 waiting delay to detect a failover. The repetitions should 6208 continue after that delay not only in order to perhaps overcome a 6209 transient connectivity problem, but also in order to allow some more 6210 time for the execution of a failover - waiting a total delay of 30 6211 seconds is probably acceptable. 6213 It is, however, important that the maximum delay of retransmissions 6214 be bounded. Prior to any retransmission, it is checked that the 6215 time elapsed since the sending of the initial datagram is no greater 6216 than T-MAX. If more than T-MAX time has elapsed, the MG concludes 6217 that the MGC has failed, and it begins its recovery process. When 6218 the MG establishes a new control association, it can retransmit to 6219 the new MGC. Alternatively, a MG may use a ServiceChange with 6220 ServiceChangeMethod equal to disconnected to inform the new MGC that 6221 the MG lost one or more transactions. The value T-MAX is related to 6222 the LONG-TIMER value: the LONG-TIMER value is obtained by adding to 6223 T-MAX the maximum propagation delay in the network. 6225 D.2 using TCP 6227 Protocol messages as defined in this document may be transmitted 6228 over TCP. When no port is specified by the other side (see section 6229 7.2.8), the commands should be sent to the default port. The defined 6230 protocol has messages as the unit of transfer, while TCP is a 6231 stream-oriented protocol. TPKT, according to RFC1006 SHALL be used 6232 to delineate messages within the TCP stream. 6234 In a transaction-oriented protocol, there are still ways for 6235 transaction requests or responses to be lost. As such, it is 6236 recommended that entities using TCP transport implement application 6237 level timers for each request and each response, similar to those 6238 specified for application level framing over UDP. 6240 D.2.1 Providing the At-Most-Once functionality 6242 Messages, being carried over TCP, are not subject to transport 6243 losses, but loss of a transaction request or its reply may 6244 nonetheless be noted in real implementations. In the absence of a 6245 timely response, commands are repeated. Most commands are not 6246 idempotent. The state of the MG would become unpredictable if, for 6247 example, Add commands were executed several times. 6249 Rosen et al Standards Track -- Expires Oct 2000 125 6250 To guard against such losses, it is recommended that entities follow 6251 the procedures in section D.1.1 6253 D.2.2 Transaction identifiers and three way handshake 6255 For the same reasons, it is possible that transaction replies may be 6256 lost even with a reliable delivery protocol such as TCP. It is 6257 recommended that entities follow the procedures in section D.1.2.2. 6259 D.2.3 Computing retransmission timers 6261 With reliable delivery, the incidence of loss of a transaction 6262 request or reply is expected to be very low. Therefore, only simple 6263 timer mechanisms are required. Exponential back-off algorithms 6264 should not be necessary, although they could be employed where, as 6265 in an MGC, the code to do so is already required, since MGCs must 6266 implement ALF/UDP as well as TCP. 6268 D.2.4 Provisional responses 6270 As with UDP, executing some transactions may require a long time. 6271 Entities that can predict that a transaction will require a long 6272 execution time may send a provisional response, "Transaction 6273 Pending". They should send this response if they receive a 6274 repetition of a transaction that is still being executed. 6276 Entities that receive a Transaction Pending shall switch to a longer 6277 repetition timer for that transaction. 6279 Entities shall retain Transactions and replies until they are 6280 confirmed. The basic procedure of section D.1.4 should be followed, 6281 but simple timer values should be sufficient. There is no need to 6282 send an immediate confirmation upon receipt of a final response. 6284 D.2.5 Ordering of commands 6286 TCP provides ordered delivery of transactions. No special 6287 procedures are required. It should be noted that ALF/UDP allows 6288 sending entity to modify its behavior under congestion, and in 6289 particular, could reorder transactions when congestion is 6290 encountered. TCP could not achieve the same results. 6292 Rosen et al Standards Track -- Expires Oct 2000 126 6293 ANNEX E BASIC PACKAGES 6295 This Annex contains definitions of some packages for use with the 6296 Megaco protocol. 6298 E.1 Generic 6300 PackageID: g (0x000e) 6301 Version: 1 6302 Extends: None 6304 Description: Generic package for commonly encountered items. 6306 E.1.1 Properties 6308 None 6310 E.1.2 Events 6312 Cause 6313 ----- 6314 EventID: cause (0x0001) 6316 Generic error event 6318 ObservedEvents Descriptor Parameters: 6320 General Cause 6321 ------------- 6322 ParameterID: Generalcause (0x0001) 6324 Description: This parameter groups the failures into six 6325 groups, which the MGC may act upon. 6327 Possible values: Enumerated, 6328 "NR" Normal Release (0x0001) 6329 "UR" Unavailable Resources (0x0002) 6330 "FT" Failure, Temporary (0x0003) 6331 "FP" Failure, Permanent (0x0004) 6332 "IW" Interworking Error (0x0005) 6333 "UN" Unsupported (0x0006) 6335 Failure Cause 6336 ------------- 6337 ParameterID: Failurecause (0x0002) 6339 Description: The Release Cause is the value generated by the 6340 Released equipment, i.e. a released network connection. 6341 The concerned value is defined in the appropriate bearer 6342 control protocol. 6344 Possible Values: OCTET STRING 6346 Rosen et al Standards Track -- Expires Oct 2000 127 6347 Signal Completion 6348 ----------------- 6349 EventID: sc (0x0002) 6351 Indicates termination of one or more signals for which the 6352 notifyCompletion parameter was set to "ON". For further procedural 6353 description, see sections 7.1.11, 7.1.17, and 7.2.7. 6355 ObservedEvents Descriptor parameters: 6357 Signal Identity 6358 --------------- 6359 ParameterID: SigID (0x0001) 6361 This parameter identifies the signals which have terminated. 6363 Type: list 6365 Possible values: a list of signals and/or sequential signal 6366 lists which have terminated. A signal outside of a sequential 6367 signal list shall be identified using the pkgdName syntax 6368 without wildcarding. An individual signal inside of a 6369 sequential signal list shall be identified using the sequential 6370 signal list syntax with the correct signal list identifier, 6371 enclosing the name of the specific signal which terminated in 6372 pkgdName syntax. 6374 Termination Method 6375 ------------------ 6376 ParameterID: Meth (0x0002) 6378 Indicates the means by which the signal terminated. 6380 Type: enumeration 6382 Possible values: 6383 "TO" (0x0001) Duration expired 6384 "EV" (0x0002) Interrupted by event 6385 "SD" (0x0003) Halted by new Signals Descriptor 6386 "NC" (0x0004) Not completed, other cause 6388 E.1.3 Signals 6390 None 6392 E.1.4 Statistics 6394 None 6396 Rosen et al Standards Track -- Expires Oct 2000 128 6397 E.2 Base Root Package 6399 Base Root Package 6400 PackageID: root (0x000f) 6401 Version: 1 6402 Extends: None 6404 Description: This package defines Gateway wide properties. 6406 E.2.1 Properties 6408 MaxNrOfContexts 6409 --------------- 6410 PropertyID: maxNumberOfContexts (0x0001) 6412 The value of this property gives the maximum number of contexts that 6413 can exist at any time. The NULL context is not included in this 6414 number. 6416 Type: Double 6418 Possible values: 1 and up 6420 MaxTerminationsPerContext 6421 ------------------------- 6422 PropertyID: maxTerminationsPerContext (0x0002) 6424 The maximum number of allowed terminations in a context, see section 6425 6.1 6427 Type: Integer 6429 Possible Values: any integer 6431 Defined In: TerminationState 6433 normalMGExecutionTime 6434 --------------------- 6435 PropertyId: normalMGExecutionTime (0x0003) 6437 Settable by the MGC to indicate the interval within which the MGC 6438 expects a response to any transaction from the MG (exclusive of 6439 network delay) 6441 Type: Integer 6443 Possible Values: any integer, represents milliseconds 6445 Rosen et al Standards Track -- Expires Oct 2000 129 6446 normalMGCExecutionTime 6447 ---------------------- 6448 PropertyId: normalMGCExecutionTime (0x0004) 6450 Settable by the MGC to indicate the interval within which the MG 6451 should expects a response to any transaction from the MGC (exclusive 6452 of network delay) 6454 Type: Integer 6456 Possible Values: any integer, represents milliseconds 6458 ProvisionalResponseTimerValue 6459 ----------------------------- 6460 PropertyId: ProvisionalResponseTimerValue (0x0005) 6462 Indicates the time within which to expect a Pending Response if a 6463 Transaction cannot be completed. Initially set to 6464 normalMGExecutionTime or normalMGCExecutionTime as appropriate, plus 6465 network delay, but may be lowered. 6467 E.2.2 Events 6469 None 6471 E.2.3 Signals 6473 None 6475 E.2.4 Statistics 6477 None 6479 E.2.5 Procedures 6481 None 6483 E.3 Tone Generator Package 6485 PackageID: tonegen (0x0001) 6486 Version: 1 6487 Extends: None 6489 Description: 6490 This package defines signals to generate audio tones. This package 6491 does not specify parameter values. It is intended to be extendable. 6492 Generally, tones are defined as an individual signal with a 6493 parameter, ind, representing "interdigit" time delay, and a tone id 6494 to be used with playtones. A tone id should be kept consistent with 6495 any tone generation for the same tone. MGs are expected to be 6497 Rosen et al Standards Track -- Expires Oct 2000 130 6498 provisioned with the characteristics of appropriate tones for the 6499 country in which the MG is located. 6501 E.3.1 Properties 6503 None 6505 E.3.2 Events 6507 None 6509 E.3.3 Signals 6511 Play tone 6512 --------- 6513 SignalID: pt (0x0001) 6515 Plays audio tone over an audio channel 6517 Signal Type: Brief 6519 Duration: Provisioned 6521 Additional Parameters: 6523 Tone id list 6524 ------------ 6525 ParameterID: tl (0x0001) 6527 Type: list of tone ids. 6529 List of tones to be played in sequence. The list SHALL contain 6530 one or more tone ids. 6532 Inter signal duration 6533 --------------------- 6534 ParameterID: ind (0x0002) 6536 Type: integer. 6538 Timeout between two consecutive tones in milliseconds 6540 No tone ids are specified in this package. Packages that extend this 6541 package can add possible values for tone id as well as adding 6542 individual tone signals. 6544 E.3.4 Statistics 6546 None 6548 Rosen et al Standards Track -- Expires Oct 2000 131 6549 E.3.5 Procedures 6551 None 6553 E.4 Tone Detection Package 6555 PackageID: tonedet (0x0002) 6556 Version: 1 6557 Extends: None 6559 This Package defines events for audio tone detection. Tones are 6560 selected by name (tone id). MGs are expected to be provisioned with 6561 the characteristics of appropriate tones for the country in which 6562 the MG is located. 6564 This package does not specify parameter values. It is intended to be 6565 extendable. 6567 E.4.1 Properties 6569 None 6571 E.4.2 Events 6573 Start tone detected 6574 ------------------- 6575 EventID: std, 0x0001 6577 Detects the start of a tone. The characteristics of positive tone 6578 detection is implementation dependent. 6580 EventsDescriptor parameters: 6582 Tone id list 6583 ------------ 6584 ParameterID: tl (0x0001) 6586 Type: list of tone ids 6588 Possible values: The only tone id defined in this package is 6589 "wild card" which is "*" in text encoding and 0x0000 in binary. 6590 Extensions to this package would add possible values for tone 6591 id. If tl is "wild card", any tone id is detected. 6593 ObservedEventsDescriptor parameters: 6595 Tone id 6596 -------- 6597 ParameterID: tid (0x0003) 6599 Type: Enumeration 6601 Rosen et al Standards Track -- Expires Oct 2000 132 6602 Possible values: "wildcard" as defined above is the only value 6603 defined in this package. Extensions to this package would add 6604 additional possible values for tone id. 6606 End tone detected 6607 ----------------- 6608 EventID: etd, 0x0002 6610 Detects the end of a tone. 6612 EventDescriptor parameters: 6614 Tone id list 6615 ------------ 6616 ParameterID: tl (0x0001) 6618 Type: enumeration or list of enumerated types 6620 Possible values: No possible values are specified in this 6621 package. Extensions to this package would add possible values 6622 for tone id. 6624 ObservedEventsDescriptor parameters: 6626 Tone id 6627 ------- 6628 ParameterID: tid (0x0003) 6630 Type: Enumeration 6632 Possible values: "wildcard" as defined above is the only value 6633 defined in this package. Extensions to this package would add 6634 possible values for tone id 6636 Duration 6637 -------- 6638 ParameterId: dur (0x0002) 6640 Type: integer, in milliseconds 6642 This parameter contains the duration of the tone from first 6643 detection until it stopped. 6645 Long tone detected 6646 ------------------ 6647 EventID: ltd, 0x0003 6649 Detects that a tone has been playing for at least a certain amount 6650 of time 6652 Rosen et al Standards Track -- Expires Oct 2000 133 6653 EventDescriptor parameters: 6655 Tone id list 6656 ------------ 6657 ParameterID: tl (0x0001) 6659 Type: enumeration or list 6661 Possible values: "wildcard" as defined above is the only value 6662 defined in this package. Extensions to this package would add 6663 possible values for tone id 6665 Duration: 6666 --------- 6667 ParameterID: dur (0x0002) 6669 Type: integer, duration to test against 6671 Possible values: any legal integer, expressed in milliseconds. 6673 ObservedEventsDescriptor parameters: 6675 Tone id 6676 ------- 6677 ParameterID: tid (0x0003) 6679 Possible values: No possible values are specified in this 6680 package. Extensions to this package would add possible values 6681 for tone id. 6683 E.4.3 Signals 6685 None 6687 E.4.4 Statistics 6689 None 6691 E.4.5 Procedures 6693 None 6695 E.5 Basic DTMF Generator Package 6697 PackageID: dg (0x0003) 6698 Version: 1 6699 Extends: tonegen version 1 6701 This package defines the basic DTMF tones as signals and extends the 6702 allowed values of parameter tl of playtone in tonegen. 6704 Rosen et al Standards Track -- Expires Oct 2000 134 6705 E.5.1 Properties 6707 None 6709 E.5.2 Events 6711 None 6713 E.5.3 Signals 6715 dtmf character 0 6716 ---------------- 6717 SignalID: d0 (0x0010) 6719 Generate DTMF 0 tone. The physical characteristic of DTMF 0 is 6720 defined in the gateway. 6722 Signal Type: Brief 6724 Duration: Provisioned 6726 Additional Parameters: 6728 None 6730 Additional Values: 6731 ----------------- 6733 d0 (0x0010) is defined as a toneid for playtone. 6735 The other dtmf characters are specified in exactly the same way. A 6736 table with all signal names and signal IDs is included. Note that 6737 each dtmf character is defined as both a signal and a toneid, thus 6738 extending the basic tone generation package. Also note that dtmf 6739 SignalIds are different from the names used in a digit map. 6741 Rosen et al Standards Track -- Expires Oct 2000 135 6742 Signal Name Signal ID/tone id 6744 dtmf character 0 d0 (0x0010) 6745 dtmf character 1 d1 (0x0011) 6746 dtmf character 2 d2 (0x0012) 6747 dtmf character 3 d3 (0x0013) 6748 dtmf character 4 d4 (0x0014) 6749 dtmf character 5 d5 (0x0015) 6750 dtmf character 6 d6 (0x0016) 6751 dtmf character 7 d7 (0x0017) 6752 dtmf character 8 d8 (0x0018) 6753 dtmf character 9 d9 (0x0019) 6754 dtmf character * ds (0x0020) 6756 dtmf character # do (0x0021) 6757 dtmf character A da (0x001a) 6758 dtmf character B db (0x001b) 6759 dtmf character C dc (0x001c) 6760 dtmf character D dd (0x001d) 6761 E.5.4 Statistics 6763 None 6765 E.5.5 Procedures 6767 None 6769 E.6 DTMF detection Package 6771 PackageID: dd (0x0004) 6772 Version: 1 6773 Extends: tonedet version 1 6775 This package defines the basic DTMF tones detection. This Package 6776 extends the possible values of tone id in the "start tone detected" 6777 "end tone detected" and "long tone detected" events. 6779 Additional tone id values are all tone ids described in package dg 6780 (basic DTMF generator package). 6782 The following table maps DTMF events to digit map symbols as 6783 described in section 7.1.14. 6785 Rosen et al Standards Track -- Expires Oct 2000 136 6786 DTMF Event Symbol 6788 d0 "0" 6789 d1 "1" 6790 d2 "2" 6791 d3 "3" 6792 d4 "4" 6793 d5 "5" 6794 d6 "6" 6795 d7 "7" 6796 d8 "8" 6797 d9 "9" 6798 da "A" or "a" 6800 db "B" or "b" 6801 dc "C" or "c" 6802 dd "D" or "d" 6803 ds "E" or "e" 6804 do "F" or "f" 6805 E.6.1 Properties 6807 None 6809 E.6.2 Events 6811 DTMF digits 6812 ----------- 6814 EventIds are defined with the same names as the SignalIds defined in 6815 the table found in section E.5.3. 6817 DigitMap Completion Event 6818 ------------------------- 6819 EventID: ce, 0x0001 6821 Generated when a digit map completes as described in section 7.1.14. 6823 EventsDescriptor parameters: digit map processing is activated only 6824 if a digit map parameter is present, specifying a digit map by name 6825 or by value. Other parameters such as a KeepActive flag or embedded 6826 Events or Signals Descriptors may be present. 6828 ObservedEventsDescriptor parameters: 6830 DigitString 6831 ----------- 6832 ParameterID: ds (0x0001) 6834 Type: string of digit map symbols (possibly empty) returned as 6835 a quotedString. 6837 Rosen et al Standards Track -- Expires Oct 2000 137 6838 Possible values: a sequence of the characters "0" through "9", 6839 "A" through "F", and the long duration modifier "L". 6841 Description: the portion of the current dial string as 6842 described in section 7.1.14 which matched part or all of an 6843 alternative event sequence specified in the digit map. 6845 Termination Method 6846 ------------------ 6847 ParameterID: Meth (0x0003) 6849 Type: enumeration 6851 Possible values: 6852 "UM" (0x0001) Unambiguous match 6853 "PM" (0x0002) Partial match, completion by timer 6854 expiry or unmatched event 6855 "FM" (0x0003) Full match, completion by timer expiry 6856 or unmatched event 6858 Description: indicates the reason for generation of the event. 6859 See the procedures in section 7.1.14. 6861 E.6.3 Signals 6863 None 6865 E.6.4 Statistics 6867 None 6869 E.6.5 Procedures 6871 None 6873 E.7 Call Progress Tones Generator Package 6875 PackageID: cg, 0x0005 6876 Version: 1 6877 Extends: tonegen version 1 6879 This package defines the basic call progress tones as signals and 6880 extends the allowed values of the tl parameter of playtone in 6881 tonegen . 6883 E.7.1 Properties 6885 None 6887 Rosen et al Standards Track -- Expires Oct 2000 138 6888 E.7.2 Events 6890 None 6892 E.7.3 Signals 6894 Dial Tone 6895 --------- 6896 SignaID: dt (0x0030) 6898 Generate dial tone. The physical characteristic of dial tone is 6899 available in the gateway. 6901 Signal Type: Timeout 6903 Duration: Provisioned 6905 Additional Parameters: 6906 None 6908 Additional Values 6909 ----------------- 6910 dt (0x0030) is defined as a tone id for playtone 6911 The other tones of this package are defined in exactly the same way. 6912 A table with all signal names and signal IDs is included. Note 6913 that each tone is defined as both a signal and a toneid, thus 6914 extending the basic tone generation package. 6916 Signal Name Signal ID/tone id 6918 Dial Tone dt (0x0030) 6919 Ringing Tone rt (0x0031) 6920 Busy Tone bt (0x0032) 6921 Congestion Tone ct (0x0033) 6922 Special Information Tone sit(0x0034) 6923 Warning Tone wt (0x0035) 6924 Payphone Recognition Tone pt (0x0036) 6925 Call Waiting Tone cw (0x0037) 6926 Caller Waiting Tone cr (0x0038) 6927 E.7.4 Statistics 6929 None 6931 E.7.5 Procedures 6933 NOTE - The required set of tone ids corresponds to those defined in 6934 Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)]. 6935 See E.180 for definition of the meanings of these tones. 6937 Rosen et al Standards Track -- Expires Oct 2000 139 6938 E.8 Call Progress Tones Detection Package 6940 PackageID: cd (0x0006) 6941 Version: 1 6942 Extends: tonedet version 1 6944 This package defines the basic call progress detection tones. This 6945 Package extends the possible values of tone id in the "start tone 6946 detected", "end tone detected" and "long tone detected" events. 6948 Additional values 6949 ----------------- 6951 tone id values are defined for start tone detected, end tone 6952 detected and long tone detected with the same values as those in 6953 package cg (call progress tones generation package). 6955 The required set of tone ids corresponds to Recommendation 6956 E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)]. See 6957 Recommendation E.180/Q.35 for definition of the meanings of these 6958 tones. 6960 E.8.1 Properties 6962 none 6964 E.8.2 Events 6966 Events are defined as in the call progress tones generator package 6967 (cg) for the tones listed in the table of section E.7.3 6969 E.8.3 Signals 6971 none 6973 E.8.4 Statistics 6975 none 6977 E.8.5 Procedures 6979 none 6981 E.9 Analog Line Supervision Package 6983 PackageID: al, 0x0009 6984 Version: 1 6985 Extends: None 6987 This package defines events and signals for an analog line. 6989 Rosen et al Standards Track -- Expires Oct 2000 140 6990 E.9.1 Properties 6992 None 6994 E.9.2 Events 6996 onhook 6997 ------ 6998 EventID: on (0x0004) 7000 Detects handset going on hook. Whenever an events descriptor is 7001 activated that requests monitoring for an on-hook event and the line 7002 is already on-hook, then the MG shall immediately generate an on- 7003 hook event. 7005 EventDescriptor parameters 7007 None 7009 ObservedEventsDescriptor parameters 7011 None 7013 offhook 7014 ------- 7015 EventID: of (0x0005) 7017 Detects handset going off hook. Whenever an events descriptor is 7018 activated that requests monitoring for an off-hook event and the 7019 line is already off-hook, then the MG shall immediately generate an 7020 off-hook event. 7022 EventDescriptor parameters 7024 None 7026 ObservedEventsDescriptor parameters 7028 None 7030 flashhook 7031 --------- 7032 EventID: fl, 0x0006 7034 Detects handset flash. A flash occurs when an onhook is followed by 7035 an offhook between a minimum and maximum duration. 7037 EventDescriptor parameters 7039 Minimum duration 7040 ---------------- 7041 ParameterID: mindur (0x0004) 7043 Rosen et al Standards Track -- Expires Oct 2000 141 7044 Type: integer in milliseconds 7046 Default value is provisioned 7048 Maximum duration 7049 ---------------- 7050 ParameterID: maxdur (0x0005) 7052 Type: integer in milliseconds 7054 Default value is provisioned 7056 ObservedEventsDescriptor parameters 7058 None 7060 E.9.3 Signals 7062 ring 7063 ---- 7064 SignalID: ri, 0x0002 7066 Applies ringing on the line 7068 Signal Type: TimeOut 7070 Duration: Provisioned 7072 Additional Parameters: 7074 Cadence 7075 ------- 7076 ParameterID: cad (0x0006) 7078 Type: list of integers representing durations of alternating on 7079 and off segments, constituting a complete ringing cycle 7080 starting with an on. Units in milliseconds. 7082 Default is fixed or provisioned. Restricted function MGs may 7083 ignore cadence values they are incapable of generating. 7085 Frequency 7086 --------- 7087 ParameterID: freq (0x0007) 7089 Type: integer in Hz 7091 Default is fixed or provisioned. Restricted function MGs may 7092 ignore frequency values they are incapable of generating. 7094 E.9.4 Statistics 7096 Rosen et al Standards Track -- Expires Oct 2000 142 7097 None 7099 E.9.5 Procedures 7101 None 7103 E.10 Basic Continuity Package 7105 PackageID: ct (0x000a) 7106 Version: 1 7107 Extends: None 7109 This package defines events and signals for continuity test. The 7110 continuity test includes provision of either a loopback or 7111 transceiver functionality. 7113 E.10.1 Properties 7115 None 7117 E.10.2 Events 7119 Completion 7120 ---------- 7121 EventID: cmp, 0x0005 7123 This event detects test completion of continuity test. 7125 EventDescriptor parameters 7127 None 7129 ObservedEventsDescriptor parameters 7131 Result 7132 ------ 7133 ParameterID: res (0x0008) 7135 Type: Enumeration 7137 Possible values: success (0x0001), failure (0x0000) 7139 E.10.3 Signals 7141 Continuity test 7142 --------------- 7143 SignalID: ct (0x0003) 7145 Initiates sending of continuity test tone on the termination to 7146 which it is applied. 7148 Rosen et al Standards Track -- Expires Oct 2000 143 7149 Signal Type: TimeOut 7151 Default value is provisioned 7153 Additional Parameters: 7155 None 7157 Respond 7158 ------- 7159 SignalID: rsp (0x0004) 7161 The signal is used to respond to a continuity test . See section 7162 E.10.5 for further explanation. 7164 Signal Type: TimeOut 7166 Default duration is provisioned 7168 Additional Parameters: 7170 None. 7172 E.10.4 Statistics 7174 None 7176 E.10.5 Procedures 7178 When a MGC wants to initiate a continuity test, it sends a command 7179 to the MG containing 7180 . a signals descriptor with the ct signal, and 7181 . an events descriptor containing the cmp event. 7183 Upon reception of a command containing the ct signal and cmp event, 7184 the MG initiates the continuity test tone for the specified 7185 termination. If the return tone is detected before the signal times 7186 out, the cmp event shall be generated with the value of the result 7187 parameter equal to success. In all other cases, the cmp event shall 7188 be generated with the value of the result parameter equal to 7189 failure. 7191 When a MGC wants the MG to respond to a continuity test, it sends a 7192 command to the MG containing a signals descriptor with the rsp 7193 signal. Upon reception of a command with the rsp signal, the MG 7194 awaits reception of the continuity test tone. When the tone is 7195 received before the rsp signal times out, the MG returns the 7196 applicable return tone. If the rsp signal times out, the MG removes 7197 the detection and the return tone (if that was playing). 7199 Rosen et al Standards Track -- Expires Oct 2000 144 7200 When a continuity test is performed on a termination, no echo 7201 devices or codecs shall be active on that termination. 7203 Performing voice path assurance as part of continuity testing is 7204 provisioned by bilateral agreement between network operators. 7206 E.11 Network Package 7208 PackageID: nt (0x000b) 7209 Version: 1 7210 Extends: None 7212 This package defines properties of network terminations independent 7213 of network type. 7215 E.11.1 Properties 7217 Maximum Jitter Buffer 7218 --------------------- 7219 PropertyID: jit (0x0007) 7221 This property puts a maximum size on the jitter buffer. 7223 Type: integer in milliseconds 7225 Possible Values: This property is specified in milliseconds. 7227 Defined In: LocalControlDescriptor 7229 Characteristics: read/write 7231 E.11.2 Events 7233 network failure 7234 --------------- 7235 EventID: netfail, 0x0005 7237 The termination generates this event upon detection of a failure due 7238 to external or internal network reasons. 7240 EventDescriptor parameters 7242 None 7244 ObservedEventsDescriptor parameters 7246 cause 7247 ----- 7248 ParameterID: cs (0x0001) 7250 Type: String 7252 Rosen et al Standards Track -- Expires Oct 2000 145 7253 Possible values: any text string 7255 This parameter may be included with the failure event to provide 7256 diagnostic information on the reason of failure. 7258 quality alert 7259 ------------- 7260 EventID: qualert, 0x0006 7262 This property allows the MG to indicate a loss of quality of the 7263 network connection. The MG may do this by measuring packet loss, 7264 interarrival jitter, propogation delay and then indicating this 7265 using a percentage of quality loss. 7267 EventDescriptor parameters 7269 Threshold 7270 --------- 7271 ParameterId: th (0x0001) 7273 Type: integer 7275 Possible Values: threshold for percent of quality loss 7276 measured, calculated based on a provisioned method, that could 7277 take into consideration packet loss, jitter, and delay for 7278 example. Event is triggered when calculation exceeds the 7279 threshold. 7281 ObservedEventsDescriptor parameters 7283 Threshold 7284 --------- 7285 ParameterId: th (0x0001) 7287 Type: integer 7289 Possible Values: percent of quality loss measured, calculated 7290 based on a provisioned method, that could take into 7291 consideration packet loss, jitter, and delay for example. 7293 E.11.3 Signals 7295 none 7297 E.11.4 Statistics 7299 Duration 7300 -------- 7301 StatisticsID: dur (0x0001) 7303 Rosen et al Standards Track -- Expires Oct 2000 146 7304 Description: Provides duration of time the termination has been in 7305 the context. 7307 Type: Double, in milliseconds 7309 Octets Sent 7310 ----------- 7311 StatisticID: os (0x0002) 7313 Type: double 7315 Possible Values: any 64 bit integer 7317 Octets Received 7318 --------------- 7319 StatisticID: or (0x0003) 7321 Type: double 7323 Possible Values: any 64 bit integer 7325 E.11.5 Procedures 7327 none 7329 E.12 RTP Package 7331 PackageID: rtp (0x000c) 7332 Version: 1 7333 Extends: Network Package version 1 7335 This package is used to support packet based multimedia data 7336 transfer by means of the Real-time Transport Protocol (RTP) [RFC 7337 1889]. 7339 E.12.1 Properties 7341 None 7343 E.12.2 Events 7345 Payload Transition 7346 EventID: pltrans, 0x0001 7347 This event detects and notifies when there is a transition of the 7348 RTP payload format from one format to another. 7350 EventDescriptor parameters 7352 None 7354 ObservedEventsDescriptor parameters 7356 Rosen et al Standards Track -- Expires Oct 2000 147 7357 rtppayload 7358 ---------- 7359 ParameterID: rtppltype, 0x01 7361 Type: list of enumerated types. 7363 Possible values: The encoding method shall be specified by 7364 using one or several valid encoding names, as defined in the 7365 RTP AV Profile or registered with IANA. 7367 E.12.3 Signals 7369 None 7371 E.12.4 Statistics 7373 Packets Sent 7374 ------------ 7375 StatisticID: ps (0x0004) 7377 Type: double 7379 Possible Values: any 64 bit integer 7381 Packets Received 7382 ---------------- 7383 StatisticID: pr (0x0005) 7385 Type: double 7387 Possible Values: any 64 bit integer 7389 Packet Loss 7390 ----------- 7391 StatisticID: pl (0x0006) 7393 Describes the current rate of packet loss on an RTP stream, as 7394 defined in IETF RFC 1889. Packet loss is expressed as percentage 7395 value: number of packets lost in the interval between two reception 7396 reports, divided by the number of packets expected during that 7397 interval. 7399 Type: double 7401 Possible Values: a 32 bit whole number and a 32 bit fraction. 7403 Jitter 7404 ------ 7405 StatisticID: jit (0x0007) 7407 Rosen et al Standards Track -- Expires Oct 2000 148 7408 Requests the current value of the interarrival jitter on an RTP 7409 stream as defined in IETF RFC 1889. Jitter measures the variation in 7410 interarrival time for RTP data packets. 7412 Delay 7413 ----- 7414 StatisticID:delay (0x0008) 7416 Requests the current value of packet propagation delay expressed in 7417 timestamp units. Same as average latency. 7419 E.12.5 Procedures 7421 none 7423 E.13 TDM Circuit Package 7425 PackageID: tdmc (0x000d) 7426 Version: 1 7427 Extends: Network Package version 1 7429 This package is used to support TDM circuit terminations. 7431 E.13.1 Properties 7433 Echo Cancellation 7434 ----------------- 7435 PropertyID: ec (0x0008) 7437 By default, the telephony gateways always perform echo cancellation. 7438 However, it is necessary, for some calls, to turn off these 7439 operations. 7441 Type: boolean 7443 Possible Values: 7444 "on" (when the echo cancellation is requested) and 7445 "off" (when it is turned off.) 7446 The default is "on". 7448 Defined In: LocalControlDescriptor 7450 Characteristics: read/write 7452 Gain Control 7453 ------------ 7454 PropertyID: gain (0x000a) 7456 Gain control, or usage of of signal level adaptation and noise level 7457 reduction is used to adapt the level of the signal. However, it is 7458 necessary, for example for modem calls, to turn off this function. 7460 Rosen et al Standards Track -- Expires Oct 2000 149 7461 Type: enumeration (integer) 7463 Possible Values: 7464 The gain control parameter may either be specified as "automatic" 7465 (0xffffffff), or as an explicit number of decibels of gain (any 7466 other integer value). The default is provisioned in the MG. 7468 Defined In: LocalControlDescriptor 7470 Characteristics: read/write 7472 E.13.2 Events 7474 none 7476 E.13.3 Signals 7478 none 7480 E.13.4 Statistics 7482 None 7484 E.13.5 Procedures 7486 None 7488 Rosen et al Standards Track -- Expires Oct 2000 150 7489 APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) 7491 All Megaco implementors must read the normative part of this 7492 document carefully before implementing from it. No one should use 7493 the examples in this section as stand-alone explanations of how to 7494 create protocol messages. 7496 The examples in this section use SDP for encoding of the Local and 7497 Remote stream descriptors. SDP is defined in RFC 2327. If there is 7498 any discrepancy between the SDP in the examples, and RFC 2327, the 7499 RFC should be consulted for correctness. Audio profiles used are 7500 those defined in RFC 1890, and others registered with IANA. For 7501 example, G.711 A-law is called PCMA in the SDP, and is assigned 7502 profile 0. G.723 is profile 4, and H263 is profile 34. See also 7504 http://www.isi.edu/in-notes/iana/assignments/rtp-parameters 7506 A.1 Residential Gateway to Residential Gateway Call 7508 This example scenario illustrates the use of the elements of the 7509 protocol to set up a Residential Gateway to Residential Gateway call 7510 over an IP-based network. For simplicity, this example assumes that 7511 both Residential Gateways involved in the call are controlled by the 7512 same Media Gateway Controller. 7514 A.1.1 Programming Residential GW Analog Line Terminations for Idle 7515 Behavior 7517 The following illustrates the API invocations from the Media Gateway 7518 Controller and Media Gateways to get the Terminations in this 7519 scenario programmed for idle behavior. Both the originating and 7520 terminating Media Gateways have idle AnalogLine Terminations 7521 programmed to look for call initiation events (i.e.-offhook) by 7522 using the Modify Command with the appropriate parameters. The null 7523 Context is used to indicate that the Terminations are not yet 7524 involved in a Context. The ROOT termination is used to indicate the 7525 entire MG instead of a termination within the MG. 7527 In this example, MG1 has the IP address 124.124.124.222, MG2 is 7528 125.125.125.111, and the MGC is 123.123.123.4. The default Megaco 7529 port is 55555 for all three. 7531 1. An MG registers with an MGC using the ServiceChange command: 7533 MG1 to MGC: 7534 MEGACO/1 [124.124.124.222] 7535 Transaction = 9998 { 7536 Context = - { 7537 ServiceChange = ROOT {Services { 7538 Method=Restart, 7539 ServiceChangeAddress=55555, Profile=ResGW/1} 7540 } 7542 Rosen et al Standards Track -- Expires Oct 2000 151 7543 } 7544 } 7546 2. The MGC sends a reply: 7548 MGC to MG1: 7549 MEGACO/1 [123.123.123.4]:55555 7550 Reply = 9998 { 7551 Context = - {ServiceChange = ROOT { 7552 Services {ServiceChangeAddress=55555, Profile=ResGW/1} } } 7553 } 7555 3. The MGC programs a Termination in the NULL context. The 7556 terminationId is A4444, the streamId is 1, the requestId in the 7557 Events descriptor is 2222. The mId is the identifier of the sender 7558 of this message, in this case, it is the IP address and port 7559 [123.123.123.4]:55555. Mode for this stream is set to SendReceive. 7560 "al" is the analog line supervision package. 7562 MGC to MG1: 7563 MEGACO/1 [123.123.123.4]:55555 7564 Transaction = 9999 { 7565 Context = - { 7566 Modify = A4444 { 7567 Media { Stream = 1 { 7568 LocalControl { 7569 Mode = SendReceive, 7570 ds0/gain=2, ; in dB, 7571 ds0/ec=G165 7572 }, 7573 Local { 7574 v=0 7575 c=IN IP4 $ 7576 m=audio $ RTP/AVP 0 7577 a=fmtp:PCMU VAD=X-NNVAD ; special voice activity 7578 ; detection algorithm 7579 } 7580 } 7581 }, 7582 Events = 2222 {al/of} 7583 } 7584 } 7585 } 7587 The dialplan script could have been loaded into the MG previously. 7588 Its function would be to wait for the OffHook, turn on dialtone and 7589 start collecting DTMF digits. However in this example, we use the 7590 digit map, which is put into place after the offhook is detected 7591 (step 5 below). 7593 Note that the embedded EventsDescriptor could have been used to 7594 combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. 7596 Rosen et al Standards Track -- Expires Oct 2000 152 7597 4. The MG1 accepts the Modify with this reply: 7599 MG1 to MGC: 7600 MEGACO/1 [124.124.124.222]:55555 7601 Reply = 9999 { 7602 Context = - {Modify = A4444} 7603 } 7605 5. A similar exchange happens between MG2 and the MGC, resulting in 7606 an idle Termination called A5555. 7608 A.1.2 Collecting Originator Digits and Initiating Termination 7610 The following builds upon the previously shown conditions. It 7611 illustrates the transactions from the Media Gateway Controller and 7612 originating Media Gateway (MG1) to get the originating Termination 7613 (A4444) through the stages of digit collection required to initiate 7614 a connection to the terminating Media Gateway (MG2). 7616 6. MG1 detects an offhook event from User 1 and reports it to the 7617 Media Gateway Controller via the Notify Command. 7619 MG1 to MGC: 7620 MEGACO/1 [124.124.124.222]:55555 7621 Transaction = 10000 { 7622 Context = - { 7623 Notify = A4444 {ObservedEvents =2222 { 7624 19990729T22000000:al/of}} 7625 } 7626 } 7628 7. And the Notify is acknowledged. 7630 MGC to MG1: 7631 MEGACO/1 [123.123.123.4]:55555 7632 Reply = 10000 { 7633 Context = - {Notify = A4444} 7634 } 7636 8. The MGC Modifies the termination to play dial tone, to look for 7637 digits according to Dialplan0 and to look for the on-hook event now. 7638 MGC to MG1: 7640 MEGACO/1 [123.123.123.4]:55555 7641 Transaction = 10001 { 7642 Context = - { 7643 Modify = A4444 { 7644 Events = 2223 { 7645 al/on, dd/ce {DigitMap=Dialplan0} 7646 }, 7647 Signals {cg/dt}, 7649 Rosen et al Standards Track -- Expires Oct 2000 153 7650 DigitMap= Dialplan0{ 7651 (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)} 7652 } 7653 } 7654 } 7656 9. And the Modify is acknowledged. 7658 MG1 to MGC: 7659 MEGACO/1 [124.124.124.222]:55555 7660 Reply = 10001 { 7661 Context = - {Modify = A4444} 7662 } 7664 10. Next, digits are accumulated by MG1 as they are dialed by User 7665 1. Dialtone is stopped upon detection of the first digit. When an 7666 appropriate match is made of collected digits against the currently 7667 programmed Dialplan for A4444, another Notify is sent to the Media 7668 Gateway Controller. 7670 MG1 to MGC: 7671 MEGACO/1 [124.124.124.222]:55555 7672 Transaction = 10002 { 7673 Context = - { 7674 Notify = A4444 {ObservedEvents =2223 { 7675 19990729T22010001:dd/ce{ds="916135551212",Meth=FM}}} 7676 } 7677 } 7679 11. And the Notify is acknowledged. 7681 MGC to MG1: 7682 MEGACO/1 [123.123.123.4]:55555 7683 Reply = 10002 { 7684 Context = - {Notify = A4444} 7685 } 7687 12. The controller then analyses the digits and determines that a 7688 connection needs to be made from MG1 to MG2. Both the TDM 7689 termination A4444, and an RTP termination are added to a new context 7690 in MG1. Mode is ReceiveOnly since Remote descriptor values are not 7691 yet specified. Preferred codecs are in the MGC's preferred order of 7692 choice. 7694 MGC to MG1: 7695 MEGACO/1 [123.123.123.4]:55555 7696 Transaction = 10003 { 7697 Context = $ { 7698 Add = A4444, 7699 Add = $ { 7700 Media { 7701 Stream = 1 { 7703 Rosen et al Standards Track -- Expires Oct 2000 154 7704 LocalControl { 7705 Mode = ReceiveOnly, 7707 nt/jit=40, ; in ms 7708 }, 7709 Local { 7710 v=0 7711 c=IN IP4 $ 7712 m=audio $ RTP/AVP 4 7713 a=ptime:30 7714 v=0 7715 c=IN IP4 $ 7716 m=audio $ RTP/AVP 0 7717 } 7718 } 7719 } 7720 } 7721 } 7722 } 7724 NOTE - The MGC states its preferred parameter values as a series of 7725 sdp blocks in Local. The MG fills in the Local Descriptor in the 7726 Reply. 7728 13. MG1 acknowledges the new Termination and fills in the Local IP 7729 address and UDP port. It also makes a choice for the codec based on 7730 the MGC preferences in Local. MG1 sets the RTP port to 2222. 7731 MEGACO/1 [124.124.124.222]:55555 7732 Reply = 10003 { 7733 Context = 2000 { 7734 Add = A4444, 7735 Add=A4445{ 7736 Media { 7737 Stream = 1 { 7738 Local { 7739 v=0 7740 c=IN IP4 124.124.124.222 7741 m=audio 2222 RTP/AVP 4 7742 a=ptime:30 7743 a=recvonly 7744 } ; RTP profile for G.723 is 4 7745 } 7746 } 7747 } 7748 } 7749 } 7751 14. The MGC will now associate A5555 with a new Context on MG2, and 7752 establish an RTP Stream (i.e, A5556 will be assigned), SendReceive 7753 connection through to the originating user, User 1. The MGC also 7754 sets ring on A5555. 7756 Rosen et al Standards Track -- Expires Oct 2000 155 7757 MGC to MG2: 7758 MEGACO/1 [123.123.123.4]:55555 7759 Transaction = 50003 { 7760 Context = $ { 7761 Add = A5555 { Media { 7762 Stream = 1 { 7763 LocalControl {Mode = SendReceive} }}, 7764 Events=1234{al/of} 7765 Signals {al/ri} 7766 }, 7767 Add = $ {Media { 7768 Stream = 1 { 7769 LocalControl { 7770 Mode = SendReceive, 7771 nt/jit=40 ; in ms 7772 }, 7773 Local { 7774 v=0 7775 c=IN IP4 $ 7776 m=audio $ RTP/AVP 4 7777 a=ptime:30 7778 }, 7779 Remote { 7780 v=0 7781 c=IN IP4 124.124.124.222 7782 m=audio 2222 RTP/AVP 4 7783 a=ptime:30 7784 } ; RTP profile for G.723 is 4 7785 } 7786 } 7787 } 7788 } 7789 } 7791 15. This is acknowledged. The stream port number is different from 7792 the control port number. In this case it is 1111 (in the SDP). 7794 MG2 to MGC: 7795 MEGACO/1 [124.124.124.222]:55555 7796 Reply = 50003 { 7797 Context = 5000 { 7798 Add = A5555{} 7799 Add = A5556{ 7800 Media { 7801 Stream = 1 { 7802 Local { 7803 v=0 7804 c=IN IP4 125.125.125.111 7805 m=audio 1111 RTP/AVP 4 7806 } 7807 } ; RTP profile for G723 is 4 7808 } 7810 Rosen et al Standards Track -- Expires Oct 2000 156 7811 } 7812 } 7813 } 7815 16. The above IPAddr and UDPport need to be given to MG1 now. 7817 MGC to MG1: 7818 MEGACO/1 [123.123.123.4]:55555 7819 Transaction = 10005 { 7820 Context = 2000 { 7821 Modify = A4444 { 7822 Signals {cg/rt} 7823 }, 7824 Modify = A4445 { 7825 Media { 7826 Stream = 1 { 7827 Remote { 7828 v=0 7829 c=IN IP4 125.125.125.111 7830 m=audio 1111 RTP/AVP 4 7831 } 7832 } ; RTP profile for G723 is 4 7833 } 7834 } 7835 } 7836 } 7838 MG1 to MGC: 7839 MEGACO/1 [124.124.124.222]:55555 7840 Reply = 10005 { 7841 Context = 2000 {Modify = A4444, Modify = A4445} 7842 } 7844 17. The two gateways are now connected and User 1 hears the 7845 RingBack. The MG2 now waits until User2 picks up the receiver and 7846 then the two-way call is established. 7848 From MG2 to MGC: 7850 MEGACO/1 [125.125.125.111]:55555 7851 Transaction = 50005 { 7852 Context = 5000 { 7853 Notify = A5555 {ObservedEvents =1234 { 7854 19990729T22020002:al/of}} 7855 } 7856 } 7858 From MGC to MG2: 7860 MEGACO/1 [123.123.123.4]:55555 7861 Reply = 50005 { 7862 Context = - {Notify = A5555} 7864 Rosen et al Standards Track -- Expires Oct 2000 157 7865 } 7867 From MGC to MG2: 7869 MEGACO/1 [123.123.123.4]:55555 7870 Transaction = 50006 { 7871 Context = 5000 { 7872 Modify = A5555 { 7873 Events = 1235 {al/on}, 7874 Signals { } ; to turn off ringing 7875 } 7876 } 7877 } 7879 From MG2 to MGC: 7881 MEGACO/1 [125.125.125.111]:55555 7882 Reply = 50006 { 7883 Context = 5000 {Modify = A4445} 7884 } 7886 18. Change mode on MG1 to SendReceive, and stop the ringback. 7888 MGC to MG1: 7889 MEGACO/1 [123.123.123.4]:55555 7890 Transaction = 10006 { 7891 Context = 2000 { 7892 Modify = A4445 { 7893 Media { 7894 Stream = 1 { 7895 LocalControl { 7896 Mode=SendReceive 7897 } 7898 } 7899 } 7900 }, 7901 Modify = A4444 { 7902 Signals { } 7903 } 7904 } 7905 } 7907 from MG1 to MGC: 7908 MEGACO/1 [124.124.124.222]:55555 7909 Reply = 10006 { 7910 Context = 2000 {Modify = A4445, Modify = A4444}} 7912 19. The MGC decides to Audit the RTP termination on MG2. 7914 MEGACO/1 [123.123.123.4]:55555 7915 Transaction = 50007 { 7916 Context = - {AuditValue = A5556{ 7918 Rosen et al Standards Track -- Expires Oct 2000 158 7919 Audit{Media, DigitMap, Events, Signals, Packages, Statistics 7920 }} 7921 } 7922 } 7924 20. The MG2 replies. An RTP termination has no events nor signals, 7925 so these are left out in the reply . 7927 MEGACO/1 [125.125.125.111]:55555 7928 Reply = 50007 { 7929 Context = - { 7930 AuditValue = A5556 { 7931 Media { 7932 Stream = 1 { 7933 LocalControl { Mode = SendReceive, 7934 nt/jit=40 }, 7935 Local { 7936 v=0 7937 c=IN IP4 125.125.125.111 7938 m=audio 1111 RTP/AVP 4 7939 a=ptime:30 7940 }, 7941 Remote { 7942 v=0 7943 c=IN IP4 124.124.124.222 7944 m=audio 2222 RTP/AVP 4 7945 a=ptime:30 7946 } } }, 7947 Packages {nt-1, rtp-1}, 7948 Statistics { rtp/ps=1200, ; packets sent 7949 nt/os=62300, ; octets sent 7950 rtp/pr=700, ; packets received 7951 nt/or=45100, ; octets received 7952 rtp/pl=0.2, ; % packet loss 7953 rtp/jit=20, 7954 rtp/delay=40 } ; avg latency 7955 } 7956 } 7957 } 7959 21. When the MGC receives an onhook signal from one of the MGs, it 7960 brings down the call. In this example, the user at MG2 hangs up 7961 first. 7963 From MG2 to MGC: 7965 MEGACO/1 [125.125.125.111]:55555 7966 Transaction = 50008 { 7967 Context = 5000 { 7968 Notify = A5555 {ObservedEvents =1235 { 7969 19990729T24020002:al/on} 7970 } 7972 Rosen et al Standards Track -- Expires Oct 2000 159 7973 } 7974 } 7976 From MGC to MG2: 7978 MEGACO/1 [123.123.123.4]:55555 7979 Reply = 50008 { 7980 Context = - {Notify = A5555} 7981 } 7983 22. The MGC now sends both MGs a Subtract to take down the call. 7984 Only the subtracts to MG2 are shown here. Each termination has its 7985 own set of statistics that it gathers. An MGC may not need to 7986 request both to be returned. A5555 is a physical termination, and 7987 A5556 is an RTP termination. 7989 From MGC to MG2: 7991 MEGACO/1 [123.123.123.4]:55555 7992 Transaction = 50009 { 7993 Context = 5000 { 7994 Subtract = A5555 {Audit{Statistics}}, 7995 Subtract = A5556 {Audit{Statistics}} 7996 } 7997 } 7999 From MG2 to MGC: 8001 MEGACO/1 [125.125.125.111]:55555 8002 Reply = 50009 { 8003 Context = 5000 { 8004 Subtract = A5555 { 8005 Statistics { 8006 nt/os=45123, ; Octets Sent 8007 nt/dur=40 ; in seconds 8008 } 8009 }, 8010 Subtract = A5556 { 8011 Statistics { 8012 rtp/ps=1245, ; packets sent 8013 nt/os=62345, ; octets sent 8014 rtp/pr=780, ; packets received 8015 nt/or=45123, ; octets received 8016 rtp/pl=10, ; % packets lost 8017 rtp/jit=27, 8018 rtp/delay=48 ; average latency 8019 } 8020 } 8021 } 8022 } 8024 Rosen et al Standards Track -- Expires Oct 2000 160 8025 23. The MGC now sets up both MG1 and MG2 to be ready to detect the 8026 next off-hook event. See step 1. Note that this could be the default 8027 state of a termination in the null context, and if this were the 8028 case, no message need be sent from the MGC to the MG. Once a 8029 termination returns to the null context, it goes back to the default 8030 termination values for that termination. 8032 Rosen et al Standards Track -- Expires Oct 2000 161