RFC 2885
Megaco Protocol version 0.8
RFC 2885: Megaco Protocol version 0.8 🎀
Bestie, this one is from the Network Working Group and it's a Standards Track doc, so it's the real deal 💅. It was written in August 2000 by a squad of six: F. Cuervo (Nortel Networks), N. Greene (Nortel Networks), C. Huitema (Microsoft Corporation), A. Rayhan (Nortel Networks), B. Rosen (Marconi), and J. Segers (Lucent Technologies). The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of this Memo 🌸
Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution is unlimited, so share it with everyone 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒
Abstract ✨
So this document is common text with Recommendation H.248, as redetermined in Geneva in February 2000 🌈 It must be read alongside the Megaco Errata, which is RFC 2886. A merged document that puts the Megaco protocol together with the Errata built in will be available shortly, so keep an eye out 👑
The protocol in here meets the requirements for a media gateway control protocol as laid out in RFC 2805. Iconic behavior, honestly 🔥
TABLE OF CONTENTS 🧚
1. SCOPE..........................................................6
2. REFERENCES.....................................................6
2.1 Normative references..........................................6
2.2 Informative references........................................8
3. DEFINITIONS....................................................9
4. ABBREVIATIONS.................................................10
5. CONVENTIONS...................................................11
6. CONNECTION MODEL..............................................11
6.1 Contexts.....................................................14
6.1.1 Context Attributes and Descriptors....................15
6.1.2 Creating, Deleting and Modifying Contexts.............15
6.2 Terminations.................................................15
6.2.1 Termination Dynamics..................................16
6.2.2 TerminationIDs........................................17
6.2.3 Packages..............................................17
6.2.4 Termination Properties and Descriptors................18
6.2.5 Root Termination......................................20
7. COMMANDS......................................................20
7.1 Descriptors..................................................21
7.1.1 Specifying Parameters.................................21
7.1.2 Modem Descriptor......................................22
7.1.3 Multiplex Descriptor..................................22
7.1.4 Media Descriptor......................................23
7.1.5 Termination State Descriptor..........................23
7.1.6 Stream Descriptor.....................................24
7.1.7 LocalControl Descriptor...............................24
7.1.8 Local and Remote Descriptors..........................25
7.1.9 Events Descriptor.....................................28
7.1.10 EventBuffer Descriptor...............................31
7.1.11 Signals Descriptor...................................31
7.1.12 Audit Descriptor.....................................32
7.1.13 ServiceChange Descriptor.............................33
7.1.14 DigitMap Descriptor..................................33
7.1.15 Statistics Descriptor................................38
7.1.16 Packages Descriptor..................................39
7.1.17 ObservedEvents Descriptor............................39
7.1.18 Topology Descriptor.................................39
7.2 Command Application Programming Interface....................42
7.2.1 Add...................................................43
7.2.2 Modify................................................44
7.2.3 Subtract..............................................45
7.2.4 Move..................................................46
7.2.5 AuditValue............................................47
7.2.6 AuditCapabilities.....................................48
7.2.7 Notify................................................49
7.2.8 ServiceChange.........................................50
7.2.9 Manipulating and Auditing Context Attributes..........54
7.2.10 Generic Command Syntax...............................54
7.3 Command Error Codes..........................................55
8. TRANSACTIONS..................................................56
8.1 Common Parameters............................................58
8.1.1 Transaction Identifiers...............................58
8.1.2 Context Identifiers...................................58
8.2 Transaction Application Programming Interface................58
8.2.1 TransactionRequest....................................59
8.2.2 TransactionReply......................................59
8.2.3 TransactionPending....................................60
8.3 Messages.....................................................61
9. TRANSPORT.....................................................61
9.1 Ordering of Commands.........................................62
9.2 Protection against Restart Avalanche.........................63
10. SECURITY CONSIDERATIONS......................................64
10.1 Protection of Protocol Connections..........................64
10.2 Interim AH scheme...........................................65
10.3 Protection of Media Connections.............................66
11. MG-MGC CONTROL INTERFACE....................................66
11.1 Multiple Virtual MGs........................................67
11.2 Cold Start..................................................68
11.3 Negotiation of Protocol Version.............................68
11.4 Failure of an MG............................................69
11.5 Failure of an MGC...........................................69
12. PACKAGE DEFINITION...........................................70
12.1 Guidelines for defining packages............................71
12.1.1 Package..............................................71
12.1.2 Properties...........................................72
12.1.3 Events...............................................72
12.1.4 Signals..............................................73
12.1.5 Statistics...........................................73
12.1.6 Procedures...........................................73
12.2 Guidelines to defining Properties, Statistics and Parameters
to Events and Signals.......................................73
12.3 Lists.......................................................74
12.4 Identifiers.................................................74
12.5 Package Registration........................................74
13. IANA CONSIDERATIONS.........................................74
13.1 Packages....................................................74
13.2 Error Codes.................................................75
13.3 ServiceChange Reasons.......................................76
ANNEX A: BINARY ENCODING OF THE PROTOCOL (NORMATIVE).............77
A.1 Coding of wildcards..........................................77
A.2 ASN.1 syntax specification...................................78
A.3 Digit maps and path names....................................94
ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE)................95
B.1 Coding of wildcards..........................................95
B.2 ABNF specification...........................................95
ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE)............107
C.1 General Media Attributes....................................107
C.2 Mux Properties..............................................108
C.3 General bearer properties...................................109
C.4 General ATM properties......................................109
C.5 Frame Relay.................................................112
C.6 IP..........................................................113
C.7 ATM AAL2....................................................113
C.8 ATM AAL1....................................................114
C.9 Bearer Capabilities.........................................116
C.10 AAL5 Properties............................................123
C.11 SDP Equivalents............................................124
C.12 H.245......................................................124
ANNEX D TRANSPORT OVER IP (NORMATIVE)...........................125
D.1 Transport over IP/UDP using Application Level Framing.......125
D.1.1 Providing At-Most-Once Functionality.................125
D.1.2 Transaction identifiers and three-way handshake......126
D.1.2.1 Transaction identifiers....................126
D.1.2.2 Three-way handshake........................126
D.1.3 Computing retransmission timers......................127
D.1.4 Provisional responses................................128
D.1.5 Repeating Requests, Responses and Acknowledgements...128
D.2 using TCP..................................................130
D.2.1 Providing the At-Most-Once functionality..........130
D.2.2 Transaction identifiers and three way handshake...130
D.2.3 Computing retransmission timers...................131
D.2.4 Provisional responses.............................131
D.2.5 Ordering of commands..............................131
ANNEX E BASIC PACKAGES..........................................131
E.1 Generic.....................................................131
E.1.1 Properties...........................................132
E.1.2 Events...............................................132
E.1.3 Signals..............................................133
E.1.4 Statistics...........................................133
E.2 Base Root Package...........................................133
E.2.1 Properties...........................................134
E.2.2 Events...............................................135
E.2.3 Signals..............................................135
E.2.4 Statistics...........................................135
E.2.5 Procedures...........................................135
E.3 Tone Generator Package......................................135
E.3.1 Properties...........................................135
E.3.2 Events...............................................136
E.3.3 Signals..............................................136
E.3.4 Statistics...........................................136
E.3.5 Procedures...........................................136
E.4 Tone Detection Package......................................137Part 1 of the TOC is all set, so the good stuff starts next, with the actual protocol sections 💜🫶
E.4.1 Properties...........................................137
E.4.2 Events...............................................137
E.4.3 Signals..............................................139
E.4.4 Statistics...........................................139
E.4.5 Procedures...........................................139
E.5 Basic DTMF Generator Package................................140
E.5.1 Properties...........................................140
E.5.2 Events...............................................140
E.5.3 Signals..............................................140
E.5.4 Statistics...........................................141
E.5.5 Procedures...........................................141
E.6 DTMF detection Package......................................141
E.6.1 Properties...........................................142
E.6.2 Events...............................................142
E.6.3 Signals..............................................143
E.6.4 Statistics...........................................143
E.6.5 Procedures...........................................143
E.7 Call Progress Tones Generator Package.......................143
E.7.1 Properties...........................................144
E.7.2 Events...............................................144
E.7.3 Signals..............................................144
E.7.4 Statistics...........................................145
E.7.5 Procedures...........................................145
E.8 Call Progress Tones Detection Package.......................145
E.8.1 Properties...........................................145
E.8.2 Events...............................................145
E.8.3 Signals..............................................145
E.8.4 Statistics...........................................145
E.8.5 Procedures...........................................146
E.9 Analog Line Supervision Package.............................146
E.9.1 Properties...........................................146
E.9.2 Events...............................................146
E.9.3 Signals..............................................147
E.9.4 Statistics...........................................148
E.9.5 Procedures...........................................148
E.10 Basic Continuity Package...................................148
E.10.1 Properties..........................................148
E.10.2 Events..............................................148
E.10.3 Signals.............................................149
E.10.4 Statistics..........................................150
E.10.5 Procedures..........................................150
E.11 Network Package............................................150
E.11.1 Properties..........................................150
E.11.2 Events..............................................151
E.11.3 Signals.............................................152
E.11.4 Statistics..........................................152
E.11.5 Procedures..........................................153
E.12 RTP Package...............................................153
E.12.1 Properties..........................................153
E.12.2 Events..............................................153
E.12.3 Signals.............................................153
E.12.4 Statistics..........................................153
E.12.5 Procedures..........................................154
E.13 TDM Circuit Package........................................154
E.13.1 Properties..........................................155
E.13.2 Events..............................................155
E.13.3 Signals.............................................155
E.13.4 Statistics..........................................156
E.13.5 Procedures..........................................156
APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE).....................157
A.1 Residential Gateway to Residential Gateway Call.............157
A.1.1 Programming Residential GW Analog Line Terminations for
Idle Behavior..............................................157
A.1.2 Collecting Originator Digits and Initiating Termination
...........................................................159
Authors' Addresses..............................................168
Full Copyright Statement........................................1701. SCOPE ✨
okay so this doc defines the protocol that talks between the pieces of a physically decomposed multimedia gateway 🎀 like, the bits can be spread across more than one physical device, and from a system point of view it acts exactly the same as a monolithic gateway like the one described in H.246. no functional difference, bestie 💅
it does NOT define how gateways, multipoint control units or IVRs work tho 🙈 instead it sets up a general framework that's good enough for all of those apps. packet network interfaces can be IP, ATM or possibly others 🌊 and it's giving compatibility with a whole bunch of SCN signalling systems: tone signalling, ISDN, ISUP, QSIG and GSM 💜 national variants of those get supported where they apply 🌍
the protocol definition in this doc is common text with ITU-T Recommendation H.248 🦋 and it meets the requirements written up in RFC 2805 💖
2. REFERENCES 📚
ngl this part is a LOT, but every single one of these is a reference the doc leans on, so here's the whole stash 🫶
2.1 Normative references 🔥
these are the must-read ones for the spec 💅
- ITU-T Recommendation H.225.0 (1998): "Call Signalling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems".
- ITU-T Recommendation H.235 (02/98): "Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals".
- ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia Communication".
- ITU-T Recommendation H.323 (1998): "Packet Based Multimedia Communication Systems".
- ITU-T Recommendation I.363.1 (08/96), "B-ISDN ATM Adaptation Layer specification: Type 1 AAL".
- ITU-T Recommendation I.363.2 (09/97), "B-ISDN ATM Adaptation Layer specification: Type 2 AAL".
- ITU-T Recommendation I.363.5 (08/96), "B-ISDN ATM Adaptation Layer specification: Type 5 AAL".
- ITU-T Recommendation I.366.1 (06/98), "Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2".
- ITU-T Recommendation I.366.2 (02/99), "AAL type 2 service specific convergence sublayer for trunking".
- ITU-T Recommendation I.371 (08/96), "Traffic control and congestion control in B-ISDN".
- ITU-T Recommendation Q.763 (09/97), "Signalling System No. 7 - ISDN user part formats and codes".
- ITU-T Recommendation Q.765, "Signalling System No. 7 - Application transport mechanism".
- ITU-T Recommendation Q.931 (05/98): "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification for Basic Call Control".
- ITU-T Recommendation Q.2630.1 (1999), "AAL Type 2 Signalling Protocol (Capability Set 1)".
- ITU-T Recommendation Q.2931 (10/95), "Broadband Integrated Services Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 2 (DSS 2) - User-Network Interface (UNI) - Layer 3 specification for basic call/connection control".
- ITU-T Recommendation Q.2941.1 (09/97), "Digital Subscriber Signalling System No. 2 - Generic Identifier Transport".
- ITU-T Recommendation Q.2961 (10/95), "Broadband integrated services digital network (B-ISDN) - Digital subscriber signalling system no.2 (DSS 2) - additional traffic parameters".
- ITU-T Recommendation Q.2961.2 (06/97), "Digital subscriber signalling system No. 2 - Additional traffic parameters: Support of ATM transfer capability in the broadband bearer capability information element."
- ITU-T Recommendation X.213 (11/1995), "Information technology - Open System Interconnection - Network service definition plus Amendment 1 (08/1997), Addition of the Internet protocol address format identifier".
- ITU-T Recommendation V.76 (08/96), "Generic multiplexer using V.42 LAPM-based procedures".
- ITU-T Recommendation X.680 (1997): "Information technology-Abstract Syntax Notation One (ASN.1): Specification of basic notation".
- ITU-T Recommendation H.246 (1998), "Interworking of H-series multimedia terminals with H-series multimedia terminals and voice/voiceband terminals on GSTN and ISDN".
- Rose, M. and D. Cass, "ISO Transport Service on top of the TCP, Version 3", RFC 1006, May 1987.
- Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
2.2 Informative references 🌸
these ones are just for extra context, bestie 🧚
- ITU-T Recommendation E.180/Q.35 (1998): "Technical characteristics of tones for the telephone service".
- CCITT Recommendation G.711 (1988), "Pulse Code Modulation (PCM) of voice frequencies".
- ITU-T Recommendation H.221 (05/99),"Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices".
- ITU-T Recommendation H.223 (1996), "Multiplexing protocol for low bit rate multimedia communication".
- ITU-T Recommendation Q.724 (1988): "Signalling procedures".
- Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- Postel, J., "Internet protocol", STD 5, RFC 791, September 1981.
- Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, RFC 793, September 1981.
- Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661, July 1994.
- Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
- Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
- Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
- Greene, N., Ramalho, M. and B. Rosen, "Media Gateway control protocol architecture and requirements", RFC 2805, April 1999.
3. DEFINITIONS ✨
okay bestie, let's get into the vocab 🎀 these are the terms the whole spec is built on, so no skipping!
- Access Gateway: a gateway that gives you a User to Network Interface (UNI), like ISDN 📞
- Descriptor: a syntax element in the protocol that bundles related properties together 🧃 For example, the MGC can set the properties of a media flow on the MG by putting the right descriptor in a command.
- Media Gateway (MG): the media gateway turns media from one kind of network into the format another network needs 🦋 An MG could terminate bearer channels from a circuit network (like DS0s) and media streams from a packet network (like RTP streams on an IP network). It might handle audio, video and T.120 alone or in any mix, and it'll be fully capable of full duplex media translations 💜 It can also play audio/video messages and do other IVR functions, or handle media conferencing.
- Media Gateway Controller (MGC): controls the part of the call state about connection control for media channels in an MG 👑
- Multipoint Control Unit (MCU): an entity that runs the setup and coordination of a multi-user conference, usually with audio, video and data processing 🌈
- Residential Gateway: a gateway that connects an analogue line to a packet network 🏠 It usually has one or two analogue lines and lives at the customer premises.
- SCN FAS Signalling Gateway: this function has the SCN Signalling Interface that terminates SS7, ISDN or other signalling links, where the call control channel and the bearer channels share the same physical span 🧩
- SCN NFAS Signalling Gateway: this function has the SCN Signalling Interface that terminates SS7 or other signalling links, where the call control channels are separated from the bearer channels 🍓
- Stream: bidirectional media or control flow that a media gateway sends or receives as part of a call or conference 🌸
- Trunk: a communication channel between two switching systems, like a DS0 on a T1 or E1 line 🔥
- Trunking Gateway: a gateway between an SCN network and a packet network that usually terminates a big pile of digital circuits 💅
4. ABBREVIATIONS 🧚
okay so this is your cheat sheet for every acronym in the doc 🫶 this recommendation defines the following terms:
ATM Asynchronous Transfer Mode
BRI Basic Rate Interface
CAS Channel Associated Signalling
DTMF Dual Tone Multi-Frequency
FAS Facility Associated Signalling
GW GateWay
IANA Internet Assigned Numbers Authority
IP Internet Protocol
ISUP ISDN User Part
MG Media Gateway
MGC Media Gateway Controller
NFAS Non-Facility Associated Signalling
PRI Primary Rate Interface
PSTN Public Switched Telephone Network
QoS Quality of Service
RTP Real-time Transport Protocol
SCN Switched Circuit Network
SG Signalling Gateway
SS7 Signalling System No. 75. CONVENTIONS 🎀
this section is the decoder ring for the wording 💖 in this recommendation, "shall" points to a mandatory requirement, while "should" is a suggested but optional feature or procedure. "may" is an optional course of action, and it doesn't say you have to pick it 🌷
6. CONNECTION MODEL 🦋
okay this part is the main character of the whole spec ✨ the connection model describes the logical entities, or objects, inside the Media Gateway that the Media Gateway Controller is allowed to control 👑 The two big abstractions are Terminations and Contexts.
A Termination sources and/or sinks one or more streams 💜 In a multimedia conference, one Termination can be multimedia and source or sink several media streams at once. The media stream parameters, plus modem and bearer parameters, all live inside the Termination.
A Context is an association between a collection of Terminations 🌈 There's also a special one called the null Context, which holds every Termination that isn't associated with any other Termination.
For instance, in a decomposed access gateway, all the idle lines are represented by Terminations in the null Context 🛋️
+------------------------------------------------------+
|Media Gateway |
| +-------------------------------------------------+ |
| |Context +-------------+ | |
| | | Termination | | |
| | |-------------| | |
| | +-------------+ +->| SCN Bearer |<---+->
| | | Termination | +-----+ | | Channel | | |
| | |-------------| | |---+ +-------------+ | |
<-+--->| RTP Stream |---| * | | |
| | | | | |---+ +-------------+ | |
| | +-------------+ +-----+ | | Termination | | |
| | | |-------------| | |
| | +->| SCN Bearer |<---+->
| | | Channel | | |
| | +-------------+ | |
| +-------------------------------------------------+ |
| |
| |
| +------------------------------+ |
| |Context | |
| +-------------+ | +-------------+ | |
| | Termination | | +-----+ | Termination | | |
| |-------------| | | | |-------------| | |
<-+->| SCN Bearer | | | * |------| SCN Bearer |<---+->
| | Channel | | | | | Channel | | |
| +-------------+ | +-----+ +-------------+ | |
| +------------------------------+ |
| |
| |
| +-------------------------------------------------+ |
| |Context | |
| | +-------------+ +-------------+ | |
| | | Termination | +-----+ | Termination | | |
| | |-------------| | | |-------------| | |
<-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
| | | Channel | | | | Channel | | |
| | +-------------+ +-----+ +-------------+ | |
| +-------------------------------------------------+ |
| ___________________________________________________ |
+------------------------------------------------------+
Figure 1: Example of H.248 Connection ModelFigure 1 is a picture of these concepts 🖼️ it gives a few examples and it's not meant to show every possible setup, so don't treat it like the full list. The asterisk box in each Context stands for the logical association of Terminations that the Context implies ⭐
Next up is a call-waiting scenario in a decomposed access gateway 📲 This one shows how a Termination gets moved between Contexts. Terminations T1 and T2 are in Context C1, on a two-way audio call. A second audio call is waiting for T1, coming from Termination T3, and T3 is all alone in Context C2. When T1 accepts the call from T3, T2 gets put on hold, and T1 moves into Context C2, as shown below 💀
+------------------------------------------------------+
|Media Gateway |
| +-------------------------------------------------+ |
| |Context C1 | |
| | +-------------+ +-------------+ | |
| | | Term. T2 | +-----+ | Term. T1 | | |
| | |-------------| | | |-------------| | |
<-+--->| RTP Stream |---| * |------| SCN Bearer |<---+->
| | | | | | | Channel | | |
| | +-------------+ +-----+ +-------------+ | |
| +-------------------------------------------------+ |
| |
| +-------------------------------------------------+ |
| |Context C2 | |
| | +-------------+ | |
| | +-----+ | Term. T3 | | |
| | | | |-------------| | |
| | | * |------| SCN Bearer |<---+->
| | | | | Channel | | |
| | +-----+ +-------------+ | |
| +-------------------------------------------------+ |
+------------------------------------------------------+
Figure 2: Example Call Waiting Scenario / Alerting Applied to T1 +------------------------------------------------------+
|Media Gateway |
| +-------------------------------------------------+ |
| |Context C1 | |
| | +-------------+ | |
| | | Term. T2 | +-----+ | |
| | |-------------| | | | |
<-+--->| RTP Stream |---| * | | |
| | | | | | | |
| | +-------------+ +-----+ | |
| +-------------------------------------------------+ |
| |
| +-------------------------------------------------+ |
| |Context C2 | |
| | +-------------+ +-------------+ | |
| | | Term. T1 | +-----+ | Term. T3 | | |
| | |-------------| | | |-------------| | |
<-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
| | | Channel | | | | Channel | | |
| | +-------------+ +-----+ +-------------+ | |
| +-------------------------------------------------+ |
+------------------------------------------------------+
Figure 3. Example Call Waiting Scenario / Answer by T16.1 Contexts ✨
okay so a Context is basically a group chat for Terminations 💬 It's an association between a bunch of Terminations, and it describes the topology (who hears/sees whom) plus the media mixing and/or switching parameters once there are more than two Terminations involved. bestie, that's giving main character energy 💅
there's also a special one called the null Context 🧚 It holds Terminations that aren't associated with any other Termination. Terminations chilling in the null Context can have their parameters examined or modified, and they may have events detected on them.
usually an Add command is what puts Terminations into Contexts ➕ If the MGC doesn't name an existing Context for the Termination to join, the MG creates a brand new one 🎀 A Termination can leave a Context with a Subtract command, or hop to another Context with a Move command. And here's the rule, no cap: a Termination SHALL exist in only one Context at a time 🙅♀️
the maximum number of Terminations in a Context is a MG property 🌸 Media gateways that only do point-to-point connectivity might allow at most two Terminations per Context. Gateways that support multipoint conferences might allow three or more Terminations per Context. iconic range honestly 🦋
6.1.1 Context Attributes and Descriptors
okay the attributes of Contexts are:
ContextID.- The topology (who hears/sees whom). The topology of a Context describes the flow of media between the Terminations within that Context. In contrast, the mode of a Termination (
send/receive/_) describes the flow of the media at the ingress/egress of the media gateway. not the same thing, so don't mix them up 🙈 - The priority. This is used for a Context to give the MG information about precedence handling for that Context. The MGC can also use the priority to control the traffic precedence in the MG autonomously and smoothly in certain situations (e.g. restart), when lots of Contexts need to be handled at the same time 🚦
- An indicator for an emergency call. This is also provided so the MG can do preference handling 🚨
6.1.2 Creating, Deleting and Modifying Contexts
the protocol can (implicitly) create Contexts and modify the parameter values of existing ones ✨ It has commands to add Terminations to Contexts, subtract them from Contexts, and move Terminations between Contexts 💖 Contexts get deleted implicitly when the last remaining Termination is subtracted or moved out. poof, gone 💨
6.2 Terminations 🦋
a Termination is a logical entity on a MG that sources and/or sinks media and/or control streams 💜 It's described by a bunch of characterizing Properties, which are grouped into Descriptors that get included in commands. Every Termination has a unique identity (a TerminationID), which the MG assigns when the Termination is created 🎀
Terminations representing physical entities have a semi-permanent existence 🧱 For example, a Termination representing a TDM channel might exist for as long as it's provisioned in the gateway.
Terminations representing ephemeral information flows, like RTP flows, usually only exist for as long as they're being used ⏳
ephemeral Terminations get created with an Add command and destroyed with a Subtract command 🫶 A physical Termination is different: when it's Added to or Subtracted from a Context, it's taken from or returned to the null Context, respectively.
Terminations can have signals applied to them 🔊 Signals are MG generated media streams, like tones and announcements, plus line signals such as hookswitch. Terminations can also be programmed to detect Events. When an Event happens, it can trigger notification messages to the MGC or action by the MG 🔔 Statistics may be accumulated on a Termination too 📊 They get reported to the MGC when requested (using the AuditValue command, see section 7.2.5), and also when the Termination is taken out of the call it's in.
multimedia gateways can process multiplexed media streams 🌈 For example, Recommendation H.221 describes a frame structure for multiple media streams multiplexed over a number of digital 64 kbit/s channels. the connection model handles this like so: for every bearer channel carrying part of the multiplexed streams, there's a Termination. The Terminations that source/sink the digital channels are connected to a separate Termination called the multiplexing Termination 🧩 That one describes the multiplex being used (e.g. how the H.221 frames are carried over the digital channels in use). The MuxDescriptor is used for this. If multiple media are carried, this Termination contains multiple StreamDescriptors. The media streams can be associated with streams sourced/sunk by other Terminations in the Context 💅
Terminations can also be created to represent multiplexed bearers, like an ATM AAL2 🌸 When a new multiplexed bearer is to be created, an ephemeral Termination is created in a Context established for that purpose. When that Termination is subtracted, the multiplexed bearer is destroyed. bye bye bearer 👋
6.2.1 Termination Dynamics
the protocol can create new Terminations and modify property values of existing ones ⚡ These modifications include adding or removing events and/or signals. The Termination properties, events and signals are described in the sections that follow 📖 An MGC can only release/modify terminations, and the resources those terminations represent, that it has previously seized via, e.g., the Add command. boundaries, bestie 🙅♀️
6.2.2 TerminationIDs
Terminations are referenced by a TerminationID, which is an arbitrary schema chosen by the MG 🍓
TerminationIDs of physical Terminations are provisioned in the Media Gateway 🛠️ They can be chosen to have structure. For instance, a TerminationID might consist of a trunk group and a trunk within that group.
there's a wildcarding mechanism that uses two types of wildcards with TerminationIDs 🃏 They're ALL and CHOOSE. ALL is used to address multiple Terminations at once, while CHOOSE tells a media gateway that it must select a Termination satisfying the partially specified TerminationID. So, for instance, an MGC can tell an MG to choose a circuit within a trunk group 🎯
when ALL is used in the TerminationID of a command, the effect is identical to repeating the command with each of the matching TerminationIDs 🔁 Each of those commands may generate a response, so the size of the entire response may be large 📚 If individual responses aren't required, a wildcard response may be requested. In that case, a single response is generated, which contains the UNION of all the individual responses that would otherwise have been generated, with duplicate values suppressed ✨ Wildcard responses may be especially useful in the Audit commands.
the encoding of the wildcarding mechanism is detailed in Annexes A and B 📎
6.2.3 Packages
different types of gateways can implement Terminations with wildly different characteristics 🌈 To handle that, the protocol lets Terminations have optional Properties, Events, Signals and Statistics implemented by MGs.
to get MG/MGC interoperability, those options are grouped into Packages, and a Termination realizes a set of them 🎁 More info on defining packages is in section 12. An MGC can audit a Termination to find out which Packages it realizes 🔍
Properties, Events, Signals and Statistics defined in Packages, plus their parameters, are referenced by identifiers (Ids) 🏷️ Identifiers are scoped. For each package, PropertyIds, EventIds, SignalIds, StatisticsIds and ParameterIds each have their own unique name spaces, so the same identifier can be used in each of them. Two PropertyIds in different packages can even share an identifier, etc. 💜
6.2.4 Termination Properties and Descriptors ✨
Okay bestie, Terminations have properties 💅, and every property gets its own unique PropertyIDs 🆔. Most of them come with default values. When a Termination gets created, its properties start at those defaults unless the controller specifically sets something different 🎀. Want to change the default for a physical Termination? Set it to the new value while the Termination is in the null Context. Then every time it goes back to the null Context, its properties reset to that new default 🔄.
There are a bunch of common properties for Terminations, plus properties that are specific to media streams 🌸. The common ones are also called the termination state properties 💜. For each media stream you get local properties, plus properties for the received and transmitted flows 🦋.
Properties that aren't in the base protocol get defined in Packages 📦. Those are referred to by a name made of the PackageName and a PropertyId 🏷️. Most of them have default values that are described in the Package description. A property can be read-only or read/write 👀. You can audit the possible values of a property, and you can audit its current values too. For read/write properties, the MGC can set the values 👑. A property can be declared as "Global", which means it has a single value that's shared by every termination that realizes the package 🌈. And related properties get grouped into descriptors, just to keep things tidy 🧚.
When a Termination is Added to a Context, you can set the value of its read/write properties by including the right descriptors as parameters to the Add command ✨. Properties that the command doesn't mention just keep their prior values 🙈. Same vibe with the Modify command: it can change a property's value on a Termination that's already in a Context, and any property it doesn't mention keeps its prior value 💅. Properties can also change value when a Termination gets moved from one Context to another through a Move command 🦋. And sometimes a command hands descriptors back as output 🎁.
Here's the full list of Descriptors and what they're for 📋. Heads up: not every descriptor is legal as input or output for every command 🙃.
Descriptor Name Description
Modem Identifies modem type and properties when
applicable.
Mux Describes multiplex type for multimedia
terminations (e.g. H.221, H.223, H.225.0)
and Terminations forming the input mux.
Media A list of media stream specifications (see
7.1.4).
TerminationState Properties of a Termination (which can be
defined in Packages) that are not stream
specific.
Stream A list of remote/local/localControl
descriptors for a single stream.
Local Contains properties that specify the media
flows that the MG receives from the remote
entity.
Remote Contains properties that specify the media
flows that the MG sends to the remote
entity.
LocalControl Contains properties (which can be defined
in packages) that are of interest between
the MG and the MGC.
Events Describes events to be detected by the MG
and what to do when an event is detected.
EventBuffer Describes events to be detected by the MG
when Event Buffering is active.
Signals Describes signals and/or actions to be
applied (e.g. Busy Tone) to the
Terminations.
Audit In Audit commands, identifies which
information is desired.
Packages In AuditValue, returns a list of Packages
realized by Termination.
DigitMap Instructions for handling DTMF tones at
the MG.
ServiceChange In ServiceChange, what, why service change
occurred, etc.
ObservedEvents In Notify or AuditValue, report of events
observed.
Statistics In Subtract and Audit, Report of
Statistics kept on a Termination.6.2.5 Root Termination 🌳
Sometimes a command needs to talk about the whole gateway instead of one termination inside it 🏰. That's what the special TerminationID Root is for 👑. Packages can be defined on Root, so it can have properties and events of its own. Signals, though, are not appropriate for root 🙅♀️. So the root TerminationID is allowed to show up in these places:
- a Modify command, to change a property or set an event 🛠️
- a Notify command, to report an event 📣
- an AuditValue return, to examine the values of properties implemented on root 🔍
- an AuditCapability, to find out which properties of root are implemented 📚
- a ServiceChange, to declare the gateway in or out of service 🚦
Using the root TerminationID anywhere else is an error 🚨.
7. COMMANDS 🎬
The protocol gives you commands for manipulating its logical entities, which are Contexts and Terminations 🧩. Commands give you control at the finest granularity the protocol supports 🔬. For example, there are commands to add Terminations to a Context, modify Terminations, subtract Terminations from a Context, and audit the properties of Contexts or Terminations 📝. Commands give you complete control over the properties of Contexts and Terminations 🎛️. That covers which events a Termination should report, which signals or actions get applied to a Termination, and the topology of a Context, meaning who hears or sees whom 👀.
Most commands are used by the Media Gateway Controller as the command initiator, controlling Media Gateways as command responders 🎮. The exceptions are the Notify and ServiceChange commands. Notify is sent from the Media Gateway to the Media Gateway Controller, and ServiceChange can be sent by either entity 🤝. Here's a quick overview of the commands. They get explained in more detail in section 7.2 💖.
- Add. The Add command adds a termination to a context. The Add command on the first Termination in a Context is used to create a Context ➕.
- Modify. The Modify command modifies the properties, events and signals of a termination 🔧.
- Subtract. The Subtract command disconnects a Termination from its Context and returns statistics on the Termination's participation in the Context 📊. The Subtract command on the last Termination in a Context deletes the Context 🗑️.
- Move. The Move command atomically moves a Termination to another context 🚚.
- AuditValue. The AuditValue command returns the current state of properties, events, signals and statistics of Terminations 🔎.
- AuditCapabilities. The AuditCapabilities command returns all the possible values for Termination properties, events and signals allowed by the Media Gateway 🗂️.
- Notify. The Notify command allows the Media Gateway to inform the Media Gateway Controller of the occurrence of events in the Media Gateway 🔔.
- ServiceChange. The ServiceChange Command allows the Media Gateway to notify the Media Gateway Controller that a Termination or group of Terminations is about to be taken out of service or has just been returned to service 🛑➡️✅. ServiceChange is also used by the MG to announce its availability to an MGC (registration), and to notify the MGC of impending or completed restart of the MG 🌅. The MGC may announce a handover to the MG by sending it a ServiceChange command 🤲. The MGC may also use ServiceChange to instruct the MG to take a Termination or group of Terminations in or out of service 🎚️.
These commands are detailed in sections 7.2.1 through 7.2.8 📖.
7.1 Descriptors 🧾
The parameters to a command are called Descriptors 💌. A Descriptor has a name and a list of items, and some items may have values 🎀. Lots of Commands share the same common Descriptors, so this subsection lists them all 🫶. Descriptors can be returned as output from a command too. Parameters that are specific to one Command type are described in the subsection for that Command 🔍.
7.1.1 Specifying Parameters 🪄
Command parameters are organized into a number of descriptors. In general, the text format of a descriptor looks like DescriptorName=<someID>{parm=value, parm=value_.} 📐.
Parameters can be fully specified, over-specified or under-specified 🎯:
- Fully specified parameters have a single, unambiguous value. The command initiator is telling the command responder to use exactly that value for the parameter 💯.
- Under-specified parameters use the CHOOSE value, which lets the command responder pick any value it can support 🎲.
- Over-specified parameters come with a list of potential values. The list order shows the command initiator's order of preference. The command responder picks one value from the offered list and sends that value back to the command initiator 🥇.
Unspecified mandatory parameters (that is, mandatory parameters that aren't specified in a descriptor) mean the command responder keeps the previous value for that parameter 🔒. Unspecified optional parameters mean the command responder uses the default value for that parameter 🌟. Whenever a parameter is underspecified or overspecified, the descriptor that holds the value the responder chose gets included as output from the command 📤.
Each command specifies the TerminationId it operates on 🎯. That TerminationId can be "wildcarded". When a command's TerminationId is wildcarded, the effect shall be as if the command had been repeated with each of the TerminationIds that matched 🃏.
7.1.2 Modem Descriptor 📞
The Modem descriptor specifies the modem type and any parameters needed for things like H.324 and text conversation 💬. It includes these modem types: V.18, V.22, V.22bis, V.32, V.32bis, V.34, V.90, V.91, Synchronous ISDN, and it leaves room for extensions 🔌. By default, there's no modem descriptor present in a Termination 🙅♀️.
7.1.3 Multiplex Descriptor 🎚️
In multimedia calls, a bunch of media streams get carried over a (possibly different) number of bearers 🚛. The multiplex descriptor is what ties the media and the bearers together 🔗. The descriptor includes the multiplex type 🧵:
- H.221
- H.223,
- H.226,
- V.76,
- Possible Extensions
It also includes a set of TerminationIDs that represent the multiplexed inputs, listed in order 🔢. For example:
Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}7.1.4 Media Descriptor ✨
okay so the Media Descriptor is where all the media stream parameters live 🎀 and they're split into two descriptors. First there's the Termination State Descriptor, which covers the termination properties that don't depend on a stream. Then there are one or more Stream Descriptors, and each one describes a single media stream 🦋
Every stream gets a StreamID. That's how you link the streams in a Context that belong together 🔗 Multiple streams exiting a termination shall be synchronized with each other 💜 Inside each Stream Descriptor there are up to three subsidiary descriptors: LocalControl, Local, and Remote. The whole family tree looks like this:
Media Descriptor
TerminationStateDescriptor
Stream Descriptor
LocalControl Descriptor
Local Descriptor
Remote DescriptorHere's a bonus, bestie 🧚 A LocalControl, Local, or Remote descriptor can also be included in the Media Descriptor without an enclosing Stream descriptor. When that happens, the StreamID is assumed to be 1 💅
7.1.5 Termination State Descriptor 🌸
The Termination State Descriptor holds the ServiceStates property, the EventBufferControl property, and the termination properties (defined in Packages) that aren't stream specific 💖
ServiceStates describes the overall state of the termination, and it's not stream-specific. A Termination can be in one of three states: "test", "out of service", or "in service". "test" means the termination is being tested 🧪 "out of service" means it can't be used for traffic 🚫 "in service" means it can be used, or is being used, for normal traffic ✨ and that's the default. Iconic, no notes 👑
Property values can be simple (integer, string, or enumeration), or they can be underspecified, where you supply more than one value and the MG gets to make a choice 🎀 The options are:
- Alternative Values: multiple values in a list, one of which must be selected
- Ranges: minimum and maximum values, any value between min and max must be selected, boundary values included
- Greater Than/Less Than: value must be greater/less than specified value
- CHOOSE Wildcard: the MG chooses from the allowed values for the property
The EventBufferControl property says whether events get buffered after an event in the Events Descriptor is detected, or whether they're processed immediately 🦋 For the details, see section 7.1.9 💅
7.1.6 Stream Descriptor 💜
A Stream descriptor specifies the parameters of a single bi-directional stream 🌈 It's split into three descriptors: one for termination properties that are specific to a stream, and one each for local and remote flows 🫶 The Stream Descriptor includes a StreamID that identifies the stream.
Streams get created by specifying a new StreamID on one of the terminations in a Context ✨ To delete a stream, you set empty Local and Remote descriptors for it, with ReserveGroup and ReserveValue in LocalControl set to "false", on all the terminations in the context that used to support that stream 😭
StreamIDs only have local significance between the MGC and the MG, and the MGC is the one who assigns them 🍓 Inside a context, the StreamID is how you tell which media flows are interconnected: streams with the same StreamID are connected 🔥
If a termination gets moved from one context to another, the effect on the context it lands in is the same as if a new termination were added with the same StreamIDs as the moved one 🦋
7.1.7 LocalControl Descriptor 🎀
The LocalControl Descriptor holds the Mode property, the ReserveGroup and ReserveValue properties, and the termination properties (defined in Packages) that are stream specific and matter between the MG and the MGC 💅 Values can be underspecified, same as in section 7.1.1 🌸
The allowed values for the mode property are send-only, receive-only, send/receive, inactive, and loop-back 🌈 "Send" and "receive" are from the perspective of the outside of the context. So, for example, a stream set to mode=sendonly won't pass received media into the context 🙈 Signals and Events aren't affected by mode at all 💖
The Reserve properties, ReserveValue and ReserveGroup, are booleans on a Termination. They tell the MG what to do when it gets a local and/or remote descriptor 🧚
Heads up, these are the rules that matter most!! 💀
If a Reserve property is True, the MG SHALL reserve resources for all the alternatives in the local and/or remote descriptors that it currently has resources for 💜 It SHALL respond with the alternatives it reserved resources for. If it cannot not support any of the alternatives, it SHALL respond with a reply to the MGC that contains empty local and/or remote descriptors 😭
If a Reserve property is False, the MG SHALL choose one of the alternatives in the local descriptor (if there is one) and one of the alternatives in the remote descriptor (if there is one) 🔥 If the MG hasn't reserved resources for the chosen alternative yet, it SHALL reserve them ✨ If, on the other hand, it already reserved resources for the Termination (because of an earlier exchange where ReserveValue and/or ReserveGroup was True), it SHALL release any excess resources it reserved before 🧹 Finally, the MG shall send a reply to the MGC with the alternatives it selected for the local and/or remote descriptor 🫶 If the MG doesn't have enough resources to support any of the alternatives, it is SHALL respond with error 510 (insufficient resources) 😬
The default value of ReserveValue and ReserveGroup is False 🌸
And one more thing, bestie: a new setting of the LocalControl Descriptor completely replaces the previous setting in the MG 💅 So if you want to keep info from the old setting, the MGC has to include that info in the new one 🦋 If the MGC wants to delete some info from the existing descriptor, it just resends the descriptor (in a Modify command) with the unwanted info stripped out 💜 Iconic, periodt 👑
7.1.8 Local and Remote Descriptors 🎀
okay bestie, so the MGC uses Local and Remote descriptors to reserve and commit MG resources for media decoding and encoding 🎧 for the given Stream(s) and Termination they apply to. the MG then sends them back in its response to show what it's actually ready to support 💅. and if the MGC didn't ask for a property that's mandatory, the MG SHALL include that property and its value in the response anyway 🫶. like if the MGC only said "payload type" but the MG needs detailed video encoding parameters, the MG has to fill those in too 😭✨
quick vocab check: Local is the media the MG receives, and Remote is the media the MG sends 🦋
when you text-encode the protocol, the descriptors are session descriptions from SDP (RFC2327) 📝. messages going from the MGC to the MG get a few extra perks on top of RFC2327 syntax:
- the "s=", "t=" and "o=" lines are optional 🙈
- CHOOSE is allowed in place of a single parameter value 🎲
- alternatives are allowed in place of a single parameter value 🍓
if one descriptor has multiple session descriptions, the "v=" lines are required as delimiters. otherwise they're optional in session descriptions sent to the MG 💜. implementations shall accept session descriptions that are fully conformant to RFC2327, so the strict version always gets a yes 🙌
when you binary-encode the protocol, the descriptor is a bunch of groups of properties (tag-value pairs) from Annex C 🧚. each group can hold the parameters of one session description 🌸
okay now the fun part: the semantics of local and remote descriptors get broken down in detail 🔍. there are two parts. part one is what the descriptor's contents mean. part two is what the MG has to do when it gets them 🛠️. what the MG does depends on the ReserveValue and ReserveGroup properties of the LocalControl descriptor 👑
either the Local or Remote descriptor (or both) can be:
- unspecified (aka absent) 👻
- empty 🫙
- underspecified, meaning CHOOSE is used in a property value 🤷♀️
- fully specified 💯
- overspecified, meaning multiple groups of properties and maybe multiple property values in one or more of those groups 🌈
when the descriptors come from the MGC to the MG, they follow the rules in section 7.1.1, plus these extra notes 💖
(a) an unspecified Local or Remote descriptor counts as a missing mandatory parameter 🚨. that makes the MG reuse whatever was last specified for that descriptor. if nothing was ever specified, the descriptor just gets ignored for the rest of the command 💀
(b) an empty Local (Remote) descriptor in a message from the MGC means "please release any resources reserved for the media flow received (sent)" 🧹💅
(c) if a Local or Remote descriptor has multiple groups of properties, or a group has multiple values, the order of preference is descending 📉✨ (top of the list is the favourite)
(d) underspecified or overspecified properties in a group sent by the MGC are requests for the MG to choose one or more values it can support for each of those properties 🎯. with an overspecified property, the list of values is in descending order of preference 🏆
after all that, what happens next depends on ReserveValue and ReserveGroup in LocalControl 🎀
if ReserveGroup is true, the MG reserves the resources needed to support any of the requested property group alternatives it can currently support 🧠. if ReserveValue is true, the MG reserves the resources needed to support any of the requested property value alternatives it can currently support 🧠💫
NOTE: if a Local or Remote descriptor has multiple groups of properties and ReserveGroup is true, the MG is being asked to reserve resources so it can decode or encode the media stream according to any of the alternatives. for example, say the Local descriptor has two groups, one for packetized G.711 A-law audio and one for G.723.1 audio. the MG reserves resources so it can decode one audio stream that's encoded in either G.711 A-law or G.723.1 😭. it does NOT have to reserve resources to decode two audio streams at the same time, one G.711 A-law and one G.723.1. ReserveValue works the same way, just with values instead of groups 🦋
if ReserveGroup is true OR ReserveValue is true, these rules kick in 🚦
- if the MG doesn't have enough resources to support all the alternatives the MGC asked for, and the MGC requested resources in both Local and Remote, the MG should reserve resources for at least one alternative in each of Local and Remote 🫶
- if the MG doesn't have enough resources to support at least one alternative within a Local (Remote) descriptor from the MGC, it shall return an empty Local (Remote) in response 🥺
- in its response, when the MGC included Local and Remote descriptors, the MG SHALL include Local and Remote descriptors for all the groups of properties and property values it reserved resources for 📦✨. if the MG can't support at least one alternative within the Local (Remote) descriptor it got from the MGC, it SHALL return an empty Local (Remote) descriptor 💔
- if the Mode property of the LocalControl descriptor is RecvOnly or SendRecv, the MG must be prepared to receive media encoded according to any of the alternatives in its response to the MGC 🎧💜
- if ReserveGroup is False AND ReserveValue is false, then the MG SHOULD follow these rules to boil Local and Remote down to a single alternative each 🎯:
- the MG picks the first alternative in Local that it can support with at least one alternative in Remote 🥇
- if the MG can't support at least one Local alternative and one Remote alternative, it returns Error 510 (Insufficient Resources) 😵
- the MG returns its selected alternative in each of Local and Remote 🌸
one more important thing: a new setting of a Local or Remote Descriptor completely replaces the previous setting of that descriptor in the MG 🧹💥. so if the MGC wants to keep any old info, it has to include that info again in the new setting 📝. and if the MGC wants to delete some info from the existing descriptor, it just resends the descriptor (in a Modify command) with the unwanted stuff stripped out ✂️🫧
7.1.9 Events Descriptor ✨
okay so the EventsDescriptor parameter is basically the bestie list 📝 It holds a RequestIdentifier plus all the events the Media Gateway is asked to detect and report. The RequestIdentifier is what links the request to any notifications it ends up triggering 🔗 Some requested events are things like fax tones, continuity test results, and on-hook and off-hook transitions 📞
Every event in the descriptor has an Event name, plus an optional streamID, an optional KeepActive flag, and optional parameters 💅 The Event name is a Package Name (the package where the event is defined) together with an EventID. The ALL wildcard can be used for the EventID, which means every event from that package has to be detected 🌈 The default streamID is 0, meaning the event isn't tied to any particular media stream. Events can also have parameters, so one event can mean a few slightly different things without you needing a whole pile of separate events 🦋 Any further event parameters are defined in the package.
The default move for the MG when it detects an event in the Events Descriptor is to send a Notify command to the MG 📨 Anything else is for further study 🔍
Now the EventBufferControl property is where it gets spicy 🌶️ If it's set to LockStep, then once an event gets detected, normal event handling is suspended 🛑 Any event detected after that which is in the EventBuffer Descriptor gets added to the end of the EventBuffer (a FIFO queue), along with the time it was detected ⏱️ The MG SHALL wait for a new EventsDescriptor to be loaded 🫶 A new EventsDescriptor can show up either by receiving a command with a new EventsDescriptor, or by activating an embedded EventsDescriptor.
If EventBufferControl is Off, the MG just keeps going based on the active EventsDescriptor 😌
If an embedded EventsDescriptor gets activated, the MG keeps handling events based on that newly activated EventsDescriptor 💖 (Note - for purposes of EventBuffer handling, activating an embedded EventsDescriptor is the same as receiving a new EventsDescriptor 🎀)
When the MG gets a command with a new EventsDescriptor, there might already be one or more events sitting in the EventBuffer 🧺 The value of EventBufferControl decides how the MG handles those buffered events 👑
Case 1
If EventBufferControl = LockStep and the MG receives a new EventsDescriptor, it checks the FIFO EventBuffer and does the following 🧚
- If the EventBuffer is empty, the MG waits to detect events based on the new EventsDescriptor 🌸
- If the EventBuffer is non-empty, the MG works through the FIFO queue starting with the first event 🔥
- a) If the event in the queue is one of the events listed in the new EventsDescriptor, the default action of the MG is to send a Notify command to the MGC and remove the event from the EventBuffer 💅 Anything else is for further study 🔍 The time stamp of the Notify shall be the time the event was actually detected ⏰ The MG then waits for a new EventsDescriptor 😤 While it's waiting, any events matching the EventsBufferDescriptor get placed in the EventBuffer, and the event processing repeats from step 1 🔁
- b) If the event is not in the new EventsDescriptor, the MG SHALL discard the event and repeat from step 1 🗑️
Case 2
If EventBufferControl equals Off and the MG receives a new EventsDescriptor, it processes new events with the new EventsDescriptor 🍓
If the MG receives a command telling it to set EventBufferControl to Off, all events in the EventBuffer SHALL be discarded 💀
The MG may report several events in a single Transaction, as long as that doesn't unnecessarily delay the reporting of individual events 🫧
For the procedures on transmitting the Notify command, check the appropriate annex for specific transport considerations 📚
The default value of EventBufferControl is Off 🙈
Note - Since the EventBufferControl property lives in the TerminationStateDescriptor, the MG might receive a command that changes EventBufferControl without including an EventsDescriptor 👀
Normally, detecting an event shall cause any active signals to stop 🛑 But when KeepActive is specified in the event, the MG shall not interrupt any signals active on the Termination where the event was detected 🦋
An event can include an Embedded Signals descriptor and/or an Embedded Events Descriptor, which (if present) replaces the current Signals/Events descriptor when the event is detected 🔄 For example, you could make the dial-tone Signal start when an off-hook Event is detected, or make the dial-tone Signal stop when a digit is detected 📞 A media gateway controller shall not send EventsDescriptors with an event that's marked KeepActive and also contains an embedded SignalsDescriptor 🙅♀️
Only one level of embedding is allowed 💜 An embedded EventsDescriptor SHALL NOT contain another embedded EventsDescriptor 🚫 An embedded EventsDescriptor may contain an embedded SignalsDescriptor ✨
An EventsDescriptor received by a media gateway replaces any previous Events Descriptor 🔁 Event notification that's already in progress shall complete, and events detected after the command containing the new EventsDescriptor executes shall be processed according to the new EventsDescriptor 🎀
7.1.10 EventBuffer Descriptor 🧃
The EventBuffer Descriptor holds a list of events (with their parameters, if any) that the MG is asked to detect and buffer when EventBufferControl equals LockStep (see 7.1.9) 🪄
7.1.11 Signals Descriptor 🎶
A SignalsDescriptor is the parameter that holds the set of signals the Media Gateway is asked to apply to a Termination 🔊 A SignalsDescriptor can contain a bunch of signals and/or sequential signal lists, and it may even contain zero signals and sequential signal lists 🫠 Support for sequential signal lists is optional 🌷
Signals are defined in packages 📦 They shall be named with a Package name (where the signal is defined) and a SignalID, and no wildcard shall be used in the SignalID 🙅♀️ Signals in a SignalsDescriptor have an optional StreamID parameter (the default is 0, meaning the signal isn't related to a particular media stream), an optional signal type (more on that below), an optional duration, and possibly parameters defined in the package that defines the signal 🎀 This lets one signal have some variation in meaning, so you don't have to make tons of separate signals 🦄 There's also the optional parameter "notifyCompletion", which lets an MGC say it wants to be notified when the signal finishes playing out 🔔 When the MGC enables the signal completion event (see section E.1.2) in an Events Descriptor, that event gets detected whenever a signal terminates and "notifyCompletion" is set to TRUE for that signal 💫 The signal completion event of section E.1.2 has a parameter that says how the signal ended: it played to completion, it was interrupted by an event, it was halted because a new SignalsDescriptor arrived, or the signal didn't complete for some other reason 📋
The duration is an integer value expressed in hundredths of a second ⏳
There are three types of signals 🌈
- on/off - the signal lasts until it is turned off 💡
- timeout - the signal lasts until it is turned off or a specific period of time elapses ⏲️
- brief - the signal duration is so short that it will stop on its own unless a new signal is applied that causes it to stop; no timeout value is needed ⚡
If the signal type is specified in a SignalsDescriptor, it overrides the default signal type (see Section 12.1.4) 🙌 If a duration is specified for an on/off signal, it SHALL be ignored 🙈
A sequential signal list is made up of a signal list identifier, a sequence of signals to be played sequentially, and a signal type 🎵
Only the trailing element of the sequence of signals in a sequential signal list may be an on/off signal 🎯 If the trailing element of the sequence is an on/off signal, the signal type of the sequential signal list shall be on/off as well 🔛 If the sequence of signals in a sequential signal list contains signals of type timeout and the trailing element is not of type on/off, the type of the sequential signal list SHALL be set to timeout ⏱️ The duration of a sequential signal list with type timeout is the sum of the durations of the signals it contains ➕ If the sequence of signals in a sequential signal list contains only signals of type brief, the type of the sequential signal list SHALL be set to brief ⚡ A signal list is treated as a single signal of the specified type when it's played out 🎭
Multiple signals and sequential signal lists in the same SignalsDescriptor shall be played simultaneously 🎶
Signals are defined as going from the termination towards the exterior of the Context, unless a package says otherwise 🧭 When the same Signal is applied to multiple Terminations within one Transaction, the MG should consider using the same resource to generate those Signals 🤔
Production of a Signal on a Termination is stopped by applying a new SignalsDescriptor, or by detecting an Event on the Termination (see section 7.1.9) 🛑
A new SignalsDescriptor replaces any existing SignalsDescriptor 🔄 Any signals applied to the Termination that aren't in the replacement descriptor shall be stopped, and new signals are applied, except as follows 🫶 Signals present in the replacement descriptor that contain the KeepActive flag shall be continued if they're currently playing and haven't already completed 💖 If a replacement signal descriptor contains a signal that isn't currently playing and contains the KeepActive flag, that signal SHALL be ignored 🙅♀️ If the replacement descriptor contains a sequential signal list with the same identifier as the existing descriptor, then:
- the signal type and sequence of signals in the sequential signal list in the replacement descriptor shall be ignored, and 🙈
- the playing of the signals in the sequential signal list in the existing descriptor shall not be interrupted 🎀
7.1.12 Audit Descriptor 🔍
The Audit Descriptor specifies what information is to be audited 🕵️♀️ It also specifies the list of descriptors to be returned 📜 Audit may be used in any command to force the return of a descriptor even if that descriptor wasn't present in the command, or had no underspecified parameters 💫 The possible items in the Audit Descriptor are:
ModemMuxEventsMediaSignalsObservedEventsDigitMapStatisticsPackagesEventBuffer
Audit may be empty, in which case no descriptors are returned 🫥 This is handy in Subtract, where it can stop statistics from being returned, especially when you're using a wildcard 🧊
7.1.13 ServiceChange Descriptor 🛎️
The ServiceChangeDescriptor contains the following parameters 🍬
ServiceChangeMethodServiceChangeReasonServiceChangeAddressServiceChangeDelayServiceChangeProfileServiceChangeVersionServiceChangeMGCIdTimeStamp
See section 7.2.8 👑
7.1.14 DigitMap Descriptor ✨
okay so a DigitMap is basically a dialing plan that lives inside the Media Gateway 📞, and its whole job is spotting digit events that come in on a Termination and reporting them 💅. The DigitMap Descriptor carries a DigitMap name plus the DigitMap being assigned to that name 🎀. There are three ways a digit map can show up: management can preload it into the MG and then you refer to it by name in an EventsDescriptor 🧚, you can define it dynamically and reference it by name later 🦋, or you can put the actual digitmap right into the EventsDescriptor 🌸. And the bestie-level detail 👑: a digit map completion event inside an Events Descriptor is allowed to refer by name to a DigitMap defined by a DigitMap Descriptor in the same command, regardless of the order the descriptors are sent in ✨.
DigitMaps defined in a DigitMapDescriptor can show up in any of the standard Termination manipulation Commands of the protocol 💖. Once defined, a digit map can be used on every Termination matched by that (possibly wildcarded) TerminationID 🌈. DigitMaps defined on the root Termination are global, so any Termination in the MG can use them, unless that Termination already has a DigitMap with the same name defined on it 🙈.
When you define a DigitMap dynamically, there are three moves:
- Create: pick a name that isn't defined yet. The value shall be present.
- Update: send a new value for a name that's already defined. Terminations currently using the digitmap shall keep using the old definition, but any EventsDescriptor that specifies the name afterwards, including one in the same command that contains the DigitMap descriptor, shall use the new one 🔄.
- Delete: send an empty value for a name that's already defined. Terminations currently using the digitmap shall keep using the old definition 🗑️.
Collecting digits with a DigitMap can be protected by three timers: a start timer (T), a short timer (S), and a long timer (L) ⏰.
- The start timer (T) is used before any digits have been dialed.
- If the Media Gateway can tell that at least one more digit is needed for a digit string to match any of the allowed patterns in the digit map, the interdigit timer value should be set to a long (L) duration (e.g. 16 seconds) 🐢.
- If the digit string has matched one of the patterns in a digit map, but more digits could still arrive that would match a different pattern, then the MG must apply the short timer (S) and wait for more digits instead of reporting the match right away 🙃.
The timers are configurable parameters of a DigitMap. The Start timer starts at the beginning of every digit map use, but it can be overridden 💜.
The formal syntax of the digit map is described by the DigitMap rule in the formal syntax description of the protocol (see Annex A and Annex B) 📜. According to that syntax, a DigitMap is defined either by a string or by a list of strings. Each string in the list is an alternative event sequence, written either as a sequence of digit map symbols or as a regular expression of digit map symbols. The digit map symbols are the digits 0 through 9 and the letters A through a maximum value that depends on the signalling system concerned, but never goes past K. They correspond to specified events within a package that was designated in the Events Descriptor on the termination the digit map is being applied to. (The mapping between events and digit map symbols is defined in the documentation for packages tied to channel-associated signalling systems like DTMF, MF, or R2. Digits 0 through 9 MUST be mapped to the corresponding digit events within the signalling system concerned. Letters should be allocated in a logical way, so range notation is easy to use for alternative events 🔤.)
The letter x is a wildcard that stands for any event matching the symbols 0 through 9 🃏. The string can also hold explicit ranges and, more generally, explicit sets of symbols, which are alternative events where any one of them satisfies that position in the digit map. Finally, the dot symbol . means zero or more repetitions of the event selector before it (an event, a range of events, a set of alternative events, or a wildcard) 🔁. Because of the third timing rule above, inter-event timing while matching the dot uses the short timer by default.
On top of the event symbols, the string can include the inter-event timing specifiers S and L, plus the Z duration modifier 🎛️. S and L tell the MG to use the short (S) timer or the long (L) timer for the events that follow, overriding the timing rules above. A timer specifier that follows a dot sets the inter-event timing for all events matching the dot as well as the events after it. If an explicit timing specifier is in effect in one alternative event sequence but none is given in any other candidate alternative, the timer value set by the explicit timing specifier must be used. If every sequence with explicit timing controls gets dropped from the candidate set, timing goes back to the default rules above. And if conflicting timing specifiers are in effect in different alternative sequences, the results are undefined 🙅.
A Z marks a long duration event 🐘. Placed in front of the symbol(s) for an event that satisfies a given digit position, it means that position is only satisfied if the event's duration goes past the long-duration threshold. The value of that threshold is assumed to be provisioned in the MG.
A digit map is active while the events descriptor that invoked it is active and it hasn't completed yet. A digit map completes when:
- a timer has expired, or
- an alternative event sequence has been matched and no other alternative event sequence in the digit map could still match through an additional event (an unambiguous match), or
- an event has been detected such that a match to a complete alternative event sequence of the digit map becomes impossible no matter what additional events arrive.
When it completes, a digit map completion event (as defined in the package that provides the events being mapped into the digit map) gets generated 🎉. At that point the digit map is deactivated. Any events in the package after that are processed by the currently active event processing mechanisms.
Before completion, successive events are processed with these rules:
- The "current dial string" is an internal variable that starts out empty. The set of candidate alternative event sequences includes all of the alternatives in the digit map 📝.
- At each step, a timer is set to wait for the next event. It's based either on the default timing rules above or on explicit timing from one or more alternative event sequences. If the timer expires and a member of the candidate set of alternatives is fully satisfied, a timeout completion with full match is reported. If the timer expires and part or none of every candidate alternative is satisfied, a timeout completion with partial match is reported ⏳.
- If an event is detected before the timer expires, it's mapped to a digit string symbol and provisionally added to the end of the current dial string. The duration of the event (long or not long) is noted if and only if it's relevant at the current symbol position, meaning at least one candidate alternative event sequence includes the
Zmodifier at that position in the sequence. - The current dial string is compared to the candidate alternative event sequences. If and only if a sequence expecting a long-duration event at this position is matched (the event had long duration and met the specification for this position), then any alternative event sequences that don't specify a long duration event at this position are discarded, and the current dial string is modified by inserting a
Zin front of the symbol for the latest event. Any sequence that expects a long-duration event at this position but doesn't match the observed event is discarded from the candidate set. If alternative event sequences that don't specify a long duration event in that position are still in the candidate set after these rules, the observed event duration is treated as irrelevant when assessing matches to them 🔍. - If exactly one candidate remains, a completion event is generated indicating an unambiguous match. If no candidates remain, the latest event is removed from the current dial string, and a completion event is generated indicating a full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or a partial match otherwise. The event removed from the current dial string is then reported by the currently active event processing mechanisms 🙌.
- If no completion event comes out of step 5 (because the candidate set still has more than one alternative event sequence), processing goes back to step 2 🔙.
A digit map gets activated whenever a new event descriptor is applied to the termination, or an embedded event descriptor is activated, and that event descriptor contains a digit map completion event that itself contains a digit map parameter 🚀. Each new activation of a digit map begins at step 1 of the procedure above, with a clear current dial string. Anything left in the current dial string from an earlier activation is lost. While the digit map is activated, detection is enabled for all events defined in the package containing the specified digit map completion event. Normal event behaviour keeps applying to each of those events as they're detected (for example, stopping signals, unless the digit completion event has the KeepActive flag enabled). The one exception: events in that package, other than the completion event itself, are not individually notified 🤫.
Note that if a package contains a digit map completion event, an event specification made of the package name with a wildcarded ItemID (Property Name) will activate a digit map if the event includes a digit map parameter. Whether or not a digit map gets activated, this form of event specification makes the individual events get reported to the MGC as they're detected 📣.
As an example, consider the following dial plan 🗺️:
0 Local operator
00 Long distance operator
xxxx Local extension number
(starts with 1-7)
8xxxxxxx Local number
#xxxxxxx Off-site extension
*xx Star services
91xxxxxxxxxx Long distance number
9011 + up to 15 digits International numberIf the DTMF detection package described in Annex E (section E.6) is used to collect the dialled digits, then the dialling plan shown above results in the following digit map:
(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)7.1.15 Statistics Descriptor ✨
Statistics is the parameter that tells you how a Termination is doing and how much it's been used while it's living inside a specific Context 📊. Every Termination that makes sense to track gets a standard set of stats, like how many octets it sent and received 📦. Which stats actually show up depends on the Packages that the Termination has realized 🎀. By default, the stats get reported when the Termination is Subtracted from the Context 🌸. If you want something different, you can include an empty AuditDescriptor in the Subtract command 💅. Stats can also come back from the AuditValue command, or from any Add/Move/Modify command that uses the Audit descriptor 🧚.
Here's the tea: stats are cumulative, so asking for them doesn't reset them 🙈. They only get reset when a Termination is Subtracted from a Context 💀.
7.1.16 Packages Descriptor 📦
Only the AuditValue command uses this one 💜. The PackageDescriptor gives back a list of the Packages that the Termination has realized 🦋.
7.1.17 ObservedEvents Descriptor 👀
ObservedEvents shows up with the Notify command so the MGC knows which event(s) got detected 🔔. When it's used with AuditValue, the ObservedEventsDescriptor hands back the events sitting in the event buffer that haven't been Notified yet 🫶. Each ObservedEvents has the RequestIdentifier of the EventsDescriptor that set off the notification, the event(s) that were detected, and the detection time(s) ⏰. Detection times are reported to the hundredth of a second, and they're always in UTC 🌍.
7.1.18 Topology Descriptor 🗺️
A topology descriptor is how you say which way media flows between Terminations in a Context 🌈. Unlike the descriptors we've looked at earlier, this one applies to a Context and not to a single Termination 👑. The default topology is that every termination's transmission gets received by all the other terminations 🔥. Implementing the Topology Descriptor is optional 🎀.
The Topology Descriptor comes before the commands in an action 💅. You can even have an action that's just a Topology Descriptor, as long as the context it's acting on already exists 🌸.
A topology descriptor is a sequence of triples that look like (T1, T2, association) 🧚. T1 and T2 name Terminations within the Context, and they can use the ALL or CHOOSE wildcard 🦋. The association tells you how media flows between those two, and there are three options 💖:
(T1, T2, isolate)means the Terminations matching T2 don't receive media from the Terminations matching T1, and the reverse is also true 🙅(T1, T2, oneway)means the Terminations that match T2 receive media from the Terminations matching T1, but not the other way around 🫶. In this case, you're not allowed to use the ALL wildcard in a way that makes some Terminations match both T1 and T2 🚫.(T1, T2, bothway)means the Terminations matching T2 receive media from the Terminations matching T1, and vice versa 💜. Wildcards are allowed here even if some Terminations match both, but then no loopback gets introduced ✨. Loopbacks come from setting the TerminationMode instead 🔁. CHOOSE wildcards can be used in T1 and T2 too, with these restrictions 🎀:- the action (see section 8) that holds the topology descriptor has an Add command that uses a CHOOSE wildcard 🧁
- if a CHOOSE wildcard shows up in T1 or T2, then a partial name SHALL NOT be specified 🙈
The CHOOSE wildcard in a topology descriptor matches the TerminationID that the MG assigns in the first Add command that uses a CHOOSE wildcard in the same action 🍓. When a Termination gets added to a Context, any existing Termination that matches T1 or T2 in that Context gets connected to the new one exactly the way the topology descriptor says 💫. If a Termination isn't mentioned in the Topology descriptor, its default association is bothway. So if T3 gets added to a context with T1 and T2, with the topology (T3,T1,oneway), it'll be connected bothway to T2 🌈.
The figure and table below show some examples of what topology descriptors do inside actions 👀. In these examples, the topology descriptors get applied in sequence 🧚.
Context 1 Context 2 Context 3
+------------------+ +------------------+ +------------------+
| +----+ | | +----+ | | +----+ |
| | T2 | | | | T2 | | | | T2 | |
| +----+ | | +----+ | | +----+ |
| ^ ^ | | ^ | | ^ |
| | | | | | | | | |
| +--+ +--+ | | +---+ | | +--+ |
| | | | | | | | | |
| v v | | v | | | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway
Context 1 Context 2 Context 3
+------------------+ +------------------+ +------------------+
| +----+ | | +----+ | | +----+ |
| | T2 | | | | T2 | | | | T2 | |
| +----+ | | +----+ | | +----+ |
| | | | ^ | | ^ ^ |
| | | | | | | | | |
| +--+ | | +---+ | | +--+ +--+ |
| | | | | | | | | |
| v | | v | | v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
4. T2, T3 oneway 5. T2, T3 bothway 6. T1, T2 bothway
Figure 4: A Sequence Of Example Topologies
Topology Description
1 No topology descriptors
When no topology descriptors are included, all
terminations have a both way connection to all
other terminations.
2 T1, T2, Isolate
Removes the connection between T1 and T2.
T3 has a both way connection with both T1 and
T2. T1 and T2 have bothway connection to T3.
3 T3, T2, oneway
A oneway connection from T3 to T2 (i.e. T2
receives media flow from T3). A bothway
connection between T1 and T3.
4 T2, T3, oneway
A oneway connection between T2 to T3.
T1 and T3 remain bothway connected
5 T2, T3 bothway
T2 is bothway connected to T3. This results in
the same as 2.
6 T1, T2 bothway (T2, T3 bothway
and T1,T3 bothway may be implied
or explicit).
All terminations have a bothway connection to
all other terminations.A oneway connection has to be built so that the other Terminations in the Context aren't aware the topology changed 🤫✨.
7.2. Command Application Programming Interface 🎀
Here's an Application Programming Interface (API) that lays out the Commands of the protocol 💖. It's there to show you the Commands and their parameters, not to dictate how anyone implements them (for example, with blocking function calls) 🙅. It lists the input parameters in parentheses after the command name, and the return values go in front of the Command 🧁. This is only for description; the real Command syntax and encoding get specified in the later subsections 📚. Anything in square brackets ([. . . ]) is optional 🫶.
7.2.1 Add ➕
The Add Command adds a Termination to a Context 🌸.
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Add( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)The TerminationID tells Add which Termination to put into the Context 🦋. That Termination either gets created or taken from the null Context 🧚. If the Termination already exists, the TerminationID is specific 💜. If it doesn't exist yet, you write the TerminationID as CHOOSE in the command, and the new TerminationID comes back in the reply 🎀. Wildcards can be used in an Add, but that'd be pretty unusual 🙈. If a wildcard matches more than one TerminationID, every possible match gets tried, and the results are reported for each one 📋. The order in which those attempts happen isn't specified 🤷♀️.
The MediaDescriptor is optional, and it describes all media streams 🌈.
The ModemDescriptor and MuxDescriptor are optional too, and they specify a modem and multiplexer when those apply 🔌. For convenience, if a Multiplex Descriptor shows up in an Add command and lists any Terminations that aren't in the Context yet, those Terminations get added to the Context as though separate Add commands for them had been invoked 🫶. If an implied Add fails, error 471 - Implied Add for Multiplex failure shall be returned, and further processing of the command shall cease 🚨.
The EventsDescriptor parameter is optional 💅. When it's there, it gives the list of events that should be detected on the Termination 👀.
The SignalsDescriptor parameter is optional 🔔. When it's there, it gives the list of signals that should be applied to the Termination ✨.
The DigitMapDescriptor parameter is optional 🔢. When it's there, it defines a DigitMap that an EventsDescriptor can use 🧚.
The AuditDescriptor is optional 🧁. When it's there, the command returns descriptors the way the AuditDescriptor asks for them 📥.
Any descriptor that can be modified might get returned by the MG if a parameter was underspecified or overspecified 😭. ObservedEvents, Statistics, Packages, and the EventBuffer Descriptors only come back if the AuditDescriptor requests them 🙈.
Add SHALL NOT be used on a Termination whose serviceState is "OutofService" 🛑💀.
7.2.2 Modify 🎀
okay so Modify is the command where you tweak a Termination that's already there, like giving it a fresh makeover 💅 It changes the properties of a Termination, and the whole thing looks like this:
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Modify( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)bestie, the TerminationID can be specific if you only want to touch one Termination in the Context ✨ Wildcards can be a good move for some operations 🦋 If the wildcard matches more than one TerminationID, every possible match gets attempted, and you get results reported for each one. The order of those attempts isn't specified, so don't count on it 🙈 CHOOSE is an error here, because Modify only works on Terminations that already exist. no cap, that's a hard no 💀
The rest of the parameters are the same as the ones for Add, and the possible return values are the same too 💖
7.2.3 Subtract 🧚
Subtract is the one that disconnects a Termination from its Context and hands back statistics on how it participated 🌸
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Subtract(TerminationID
[, AuditDescriptor]
)The TerminationID in the input is the Termination being subtracted 🎀 It can be specific, or it can be a wildcard meaning all (or a set of related) Terminations in the Context of the Subtract Command get subtracted. Same deal as before: if the wildcard matches more than one TerminationID, every match is attempted with results reported for each one, and the order isn't specified. CHOOSE is an error, since Subtract can only be used on existing Terminations 🙅♀️
Now the big one 😭 ALL can be used as the ContextID and also as the TerminationId in a Subtract. That would delete all contexts, delete all ephemeral terminations, and send all physical terminations back to the Null context. iconic, but also dramatic 💅
By default, the Statistics parameter comes back to report what was collected on the Termination or Terminations in the command. The info reported applies to their existence in the Context they're being subtracted from ✨
The AuditDescriptor is optional 🫶 If it's there, the command returns descriptors as the AuditDescriptor specifies. Possible return values are the same as the ones for Add.
Here's the part that matters for provisioned Terminations. When one gets Subtracted from a context, its property values shall revert to:
- the default value, if one is specified for the property and not overridden by provisioning,
- otherwise, the provisioned value.
7.2.4 Move 🦋
Move takes a Termination and shifts it to another Context from its current one, all in one atomic operation 🌈 It's the only command that refers to a Termination in a Context different from the one the command is applied to, so it's kind of a main character moment 👑
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Move( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)The TerminationID tells you which Termination gets moved, and it can be wildcarded 🍓 If the wildcard matches more than one TerminationID, all the possible matches are attempted, with results reported for each one. The order of attempts isn't specified. By convention, the Termination is subtracted from its previous Context. The Context it moves to is shown by the target ContextId in the Action. And if the last remaining Termination leaves a Context, that Context gets deleted 😭
The remaining descriptors are handled the same way as in the Modify Command. For example, the AuditDescriptor with the Statistics option would return statistics on the Termination just before the Move 🧁 Possible descriptors returned from Move are the same as for Add.
The Move command shall not be used to move Terminations to or from the null Context 🙅♀️ Also, SHALL NOT be used on a Termination with a serviceState of "OutofService". Be careful with that one, bestie 🚫
7.2.5 AuditValue 🔍
AuditValue is how you check the current values of properties, events, signals and statistics on Terminations 👀 It's giving detective energy 🕵️♀️
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
AuditValue(TerminationID,
AuditDescriptor
)TerminationID may be specific or wildcarded. If the wildcard matches more than one TerminationID, all possible matches are attempted, with results reported for each one. The order of attempts isn't specified. If a wildcarded response is requested, only one command return gets generated, and its contents contain the union of the values of all Terminations matching the wildcard. This is lowkey a great trick, since it can cut down on the amount of data needed to audit a group of Terminations 🫧 CHOOSE is an error here too.
The appropriate descriptors, with the current values for the Termination, come back from AuditValue. When values show up in multiple instances of a descriptor, they count as alternate values that are supported, and each parameter in a descriptor is considered independent 💜
Some things to know about what you get back:
- ObservedEvents returns a list of events in the EventBuffer.
- PackagesDescriptor returns a list of packages realized by the Termination.
- DigitMapDescriptor returns the name or value of the current DigitMap for the Termination.
- A DigitMap requested in an AuditValue command with TerminationID ALL returns all DigitMaps in the gateway.
- Statistics returns the current values of all statistics being kept on the Termination.
- Specifying an empty Audit Descriptor results in only the TerminationID being returned. This may be useful for getting a list of TerminationIDs when used with a wildcard 🧚
AuditValue results depend on the Context, which can be specific, null, or wildcarded. The TerminationID can be specific or wildcarded too. Here's the rundown of the other info you can get with the Audit Command, bestie 📋
ContextID TerminationID Information Obtained
Specific wildcard Audit of matching
Terminations in a Context
Specific specific Audit of a single
Termination in a Context
Null Root Audit of Media Gateway state
and events
Null wildcard Audit of all matching
Terminations in the Null
Context
Null specific Audit of a single
Termination outside of any
Context
All wildcard Audit of all matching
Terminations and the Context
to which they are associated
All Root List of all ContextIds7.2.6 AuditCapabilities 🌸
AuditCapabilities is the "what could this even do?" command 🤔 It returns the possible values of properties, events, signals and statistics on Terminations ✨
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
AuditCapabilities(TerminationID,
AuditDescriptor
)The appropriate descriptors, with the possible values for the Termination, come back from AuditCapabilities 🎀 Descriptors may be repeated where there are multiple possible values. If a wildcarded response is requested, only one command return gets generated, with the contents holding the union of the values of all Terminations matching the wildcard. Same trick as before: it can cut down the data needed to audit a group of Terminations 🫶
Interpretation of which capabilities are requested for different values of ContextID and TerminationID is the same as in AuditValue.
Here's what each descriptor gives you:
- The EventsDescriptor returns the list of possible events on the Termination, together with the list of all possible values for the EventsDescriptor Parameters.
- The SignalsDescriptor returns the list of possible signals that could be applied to the Termination, together with the list of all possible values for the Signals Parameters.
- StatisticsDescriptor returns the names of the statistics being kept on the termination.
- ObservedEventsDescriptor returns the names of active events on the termination.
DigitMap and Packages are not legal in AuditCapability 🚫 (no DigitMap or Packages for you, sweetie 💅)
7.2.7 Notify 🔔
Notify is how the Media Gateway lets the Media Gateway Controller know that events are happening inside the Media Gateway 📣
Notify(TerminationID,
ObservedEventsDescriptor,
[ErrorDescriptor]
)The TerminationID parameter says which Termination is issuing the Notify Command. The TerminationID shall be a fully qualified name 💖
The ObservedEventsDescriptor holds the RequestID and a list of events that the Media Gateway detected, in the order they were detected 🍓 Each event in the list comes with its own parameters and an indication of the time it was detected ⏰ Procedures for sending Notify commands with RequestID equal to 0 are for further study 🔮
Notify Commands with RequestID not equal to 0 shall occur only as the result of detection of an event specified by an Events Descriptor which is active on the termination concerned 🎯
The RequestID returns the RequestID parameter of the EventsDescriptor that triggered the Notify Command. It's used to correlate the notification with the request that set it off, which is so useful 🧩 The events in the list must have been requested via the triggering EventsDescriptor or embedded events descriptor, unless the RequestID is 0 (which is for further study) ✨
7.2.8 ServiceChange ✨
okay bestie, the ServiceChange Command is how the Media Gateway (MG) tells the Media Gateway Controller (MGC) that a Termination (or a whole group of them) is about to get taken out of service, or just came back 🔧 The MGC can also say that Termination(s) SHALL be taken out of or returned to service, and the MG can tell the MGC that a Termination's capability has changed 💅 It's also how an MGC hands control of an MG over to a different MGC 🦋
TerminationID,
[ServiceChangeDescriptor]
ServiceChange(TerminationID,
ServiceChangeDescriptor
)The TerminationID is whichever Termination(s) are going out of or coming back into service 🌸 Wildcarding Termination names is allowed, but the CHOOSE mechanism SHALL NOT be used 🙅♀️ If you use the "Root" TerminationID, that means the ServiceChange affects the entire Media Gateway, which is a whole main character moment 👑
The ServiceChangeDescriptor holds these parameters, as needed:
- ServiceChangeMethod
- ServiceChangeReason
- ServiceChangeDelay
- ServiceChangeAddress
- ServiceChangeProfile
- ServiceChangeVersion
- ServiceChangeMgcId
- TimeStamp
The ServiceChangeMethod says what kind of ServiceChange will happen or already happened ✨
- Graceful: the Terminations go out of service after the ServiceChangeDelay. Existing connections aren't affected yet, but the MGC SHOULD refrain from setting up new connections and SHOULD try to gently tear down the ones that already exist 🥹 The MG SHOULD set the termination serviceState to "out of service" when the ServiceChangeDelay runs out, or when the termination gets removed from an active context, whichever comes first.
- Forced: the Terminations were yanked out of service abruptly, so any connections on them are gone 💀 The MGC is responsible for cleaning up the context (if there is one) that the failed termination was in. At a minimum, the termination SHALL be subtracted from the context. The termination serviceState SHOULD be "out of service".
- Restart: service comes back on the specified Terminations once the ServiceChangeDelay is up 🌈 The serviceState SHOULD be set to "inService" when the ServiceChangeDelay expires.
- Disconnected: always paired with the Root TerminationID. It means the MG lost contact with the MGC, but the contact came back 📞 Since the MG's state might have changed in the meantime, the MGC MAY wish to use the Audit command to resync with the MG.
- Handoff: sent from the MGC to the MG, this means the MGC is leaving and a new MGC association MUST be established. Sent from the MG to the MGC, it means the MG is trying to set up a new association based on a Handoff it got from its previous MGC 🦋
- Failover: sent from the MG to the MGC to say the primary MG is out of service and a secondary MG is taking over 🔄
- Another value whose meaning both the MG and the MGC already understand ✨
The ServiceChangeReason says why the ServiceChange has happened or will happen 📝 It's made of an alphanumeric token (IANA registered) plus an explanatory string.
The optional ServiceChangeAddress is the address (like an IP port number for IP networks) to use for later communication 📮 It can go in the input parameter descriptor or the returned result descriptor. ServiceChangeAddress and ServiceChangeMgcId MUST NOT both be present in the ServiceChangeDescriptor or the ServiceChangeResultDescriptor 🙅♀️ The serviceChangeAddress is for the association currently being negotiated, while the ServiceChangeMgcId points the MG to an alternate address where it should try setting up a different association 🫶
The optional ServiceChangeDelay is measured in seconds ⏱️ If the delay is missing or zero, the delay value SHOULD be treated as null. For a "graceful" ServiceChangeMethod, a null delay means the Media Gateway Controller SHOULD wait for existing connections to naturally go away and SHOULD NOT set up new ones 🫠 Also only for "graceful": a null delay means the MG MUST NOT set serviceState to "out of service" until the termination is in the null context.
The optional ServiceChangeProfile tells you which Profile (if any) of the protocol is being used, including its version 📚
The optional ServiceChangeVersion carries the protocol version, and it's used when protocol version negotiation happens (see section 11.3) 🤓
The optional TimeStamp is the actual time according to the sender 🕰️ The responder can use it to figure out how far its clock is from its correspondent's. TimeStamp is sent with hundredths-of-a-second precision and is expressed in UTC 🌍
The optional Extension parameter MAY contain any value whose meaning the MG and MGC both understand 🧩
Here's the big one 🎀 A ServiceChange Command that uses the "Root" TerminationID with a ServiceChangeMethod of Restart is a registration command. It's how a Media Gateway announces it exists to the Media Gateway Controller 📣 The MG is supposed to be provisioned with the name of one primary MGC and optionally some alternate MGCs. Acknowledging the ServiceChange Command finishes the registration ✅ The MG MAY specify the transport ServiceChangeAddress that the MGC should use to send it messages, in the ServiceChangeAddress parameter of the input ServiceChangeDescriptor. The MG MAY also specify an address in the ServiceChangeAddress parameter of the ServiceChange request, and the MGC MAY do the same in the ServiceChange reply. Either way, the recipient MUST use that supplied address as the destination for all later transaction requests within the association. At the same time, as section 9 explains, transaction replies and pending indications MUST be sent to the address the original requests came from. This MUST be done even if it means extra messaging, because commands and responses cannot be packed together 📦 The TimeStamp parameter SHALL be sent with a registration command and its response.
The Media Gateway Controller MAY return a ServiceChangeMgcId, which is the MGC the MG should preferably contact for further service. In that case the Media Gateway SHALL reissue the ServiceChange command to the new Media Gateway Controller 🚨 A Gateway named in a ServiceChangeMgcId, if one is given, SHALL be contacted before any further alternate MGCs. On a HandOff message from the MGC to the MG, the ServiceChangeMgcId is the new MGC that will take over from the current one 👑
The return from ServiceChange is empty, except when the Root terminationID is used. In that case, it includes these parameters as needed:
- ServiceChangeAddress, if the responding MGC wants to set a new destination for messages from the MG for the rest of the association
- ServiceChangeMgcId, if the responding MGC doesn't want to keep up an association with the MG
- ServiceChangeProfile, if the responder wants to negotiate the profile used for the association
- ServiceChangeVersion, if the responder wants to negotiate the protocol version used for the association
These ServiceChangeReasons are defined. This list MAY be extended through an IANA registration, as outlined in section 13.3 📋
900 Service Restored
901 Cold Boot
902 Warm Boot
903 MGC Directed Change
904 Termination malfunctioning
905 Termination taken out of service
906 Loss of lower layer connectivity (e.g. downstream sync)
907 Transmission Failure
908 MG Impending Failure
909 MGC Impending Failure
910 Media Capability Failure
911 Modem Capability Failure
912 Mux Capability Failure
913 Signal Capability Failure
914 Event Capability Failure
915 State Loss7.2.9 Manipulating and Auditing Context Attributes 🌷
The commands we just covered all apply to terminations 🦋 This section explains how contexts get manipulated and audited, which is a whole different vibe ✨
Commands are grouped into actions (see section 8). An action applies to one context 🎯 Besides commands, an action MAY contain context manipulation and auditing instructions.
An action request sent to an MG MAY include a request to audit the attributes of a context 🔍 An action MAY also include a request to change the attributes of a context.
The context properties that MAY be included in an action reply are how info gets sent back to the MGC 💌 That can be the info an audit asked for, or details about what happened when a context got manipulated.
If an MG gets an action that has BOTH a request to audit context attributes AND a request to manipulate those attributes, the response SHALL include the values of the attributes after the manipulation request has been processed 🧠
7.2.10 Generic Command Syntax 💜
The protocol can be encoded in a binary format or a text format 💕 MGCs SHOULD support both encoding formats. MGs MAY support both formats.
The protocol syntax for the binary format is defined in Annex A. Annex C specifies how the Local and Remote descriptors are encoded for the binary format 🔢
A complete ABNF of the text encoding of the protocol, per RFC2234, is given in Annex B 📜 For the text encoding, SDP is used to encode the Local and Remote Descriptors, as modified in section 7.1.8 🫶
7.3 Command Error Codes ✨
okay so errors have a vibe too 💅 Every error is an IANA registered error code plus an explanatory string. Sending the string is optional, but implementations are encouraged to tack diagnostic info onto the end of it 🔍
When a MG reports an error to a MGC, it does so in an error descriptor 🎀 That descriptor holds an error code and, optionally, the explanatory string that goes with it.
Here's the full list of error codes you can get 👑
400 - Bad Request
401 - Protocol Error
402 - Unauthorized
403 - Syntax Error in Transaction
404 - Syntax Error in TransactionReply
405 - Syntax Error in TransactionPending
406 - Version Not Supported
410 - Incorrect identifier
411 - The transaction refers to an unknown ContextId
412 - No ContextIDs available
421 - Unknown action or illegal combination of actions
422 - Syntax Error in Action
430 - Unknown TerminationID
431 - No TerminationID matched a wildcard
432 - Out of TerminationIDs or No TerminationID available
433 - TerminationID is already in a Context
440 - Unsupported or unknown Package
441 - Missing RemoteDescriptor
442 - Syntax Error in Command
443 - Unsupported or Unknown Command
444 - Unsupported or Unknown Descriptor
445 - Unsupported or Unknown Property
446 - Unsupported or Unknown Parameter
447 - Descriptor not legal in this command
448 - Descriptor appears twice in a command
450 - No such property in this package
451 - No such event in this package
452 - No such signal in this package
453 - No such statistic in this package
454 - No such parameter value in this package
455 - Parameter illegal in this Descriptor
456 - Parameter or Property appears twice in this Descriptor
461 - TransactionIDs in Reply do not match Request
462 - Commands in Transaction Reply do not match commands in
request
463 - TerminationID of Transaction Reply does not match
request
464 - Missing reply in Transaction Reply
465 - TransactionID in Transaction Pending does not match any
open request
466 - Illegal Duplicate Transaction Request
467 - Illegal Duplicate Transaction Reply
471 - Implied Add for Multiplex failure
500 - Internal Gateway Error
501 - Not Implemented
502 - Not ready.
503 - Service Unavailable
504 - Command Received from unauthorized entity
505 - Command Received before Restart Response
510 - Insufficient resources
512 - Media Gateway unequipped to detect requested Event
513 - Media Gateway unequipped to generate requested Signals
514 - Media Gateway cannot send the specified announcement
515 - Unsupported Media Type
517 - Unsupported or invalid mode
518 - Event buffer full
519 - Out of space to store digit map
520 - Media Gateway does not have a digit map
521 - Termination is "ServiceChangeing"
526 - Insufficient bandwidth
529 - Internal hardware failure
530 - Temporary Network failure
531 - Permanent Network failure
581 - Does Not Exist8. TRANSACTIONS 🦋
okay this section is the big one bestie 🫶 Commands between the Media Gateway Controller and the Media Gateway get grouped into Transactions, and every Transaction has its own TransactionID 🆔 A Transaction is made of one or more Actions. An Action is a series of Commands that stay inside a single Context, so each Action usually names a ContextID 💜 There are two situations where an Action doesn't get a specific ContextID: modifying a Termination outside of a Context, and when the controller asks the gateway to create a brand new Context ✨ Here's a picture of how Transactions, Actions and Commands fit together 👇
+----------------------------------------------------------+
| Transaction x |
| +----------------------------------------------------+ |
| | Action 1 | |
| | +---------+ +---------+ +---------+ +---------+ | |
| | | Command | | Command | | Command | | Command | | |
| | | 1 | | 2 | | 3 | | 4 | | |
| | +---------+ +---------+ +---------+ +---------+ | |
| +----------------------------------------------------+ |
| |
| +----------------------------------------------------+ |
| | Action 2 | |
| | +---------+ | |
| | | Command | | |
| | | 1 | | |
| | +---------+ | |
| +----------------------------------------------------+ |
| |
| +----------------------------------------------------+ |
| | Action 3 | |
| | +---------+ +---------+ +---------+ | |
| | | Command | | Command | | Command | | |
| | | 1 | | 2 | | 3 | | |
| | +---------+ +---------+ +---------+ | |
| +----------------------------------------------------+ |
+----------------------------------------------------------+
Figure 5 Transactions, Actions and CommandsTransactions get sent as TransactionRequests 📨 The reply comes back as a single reply, and it might be preceded by a bunch of TransactionPending messages (check out section 8.2.3 for those) 🕰️
Now the ordering stuff 🔥 Transactions guarantee ordered Command processing, so Commands inside a Transaction run one after another, sequentially. But ordering of Transactions is NOT guaranteed, so they might run in any order, or all at once 🌀
If a Command fails, the rest of that Transaction's Commands stop right there 🛑 If a Command has a wildcarded TerminationID, the Command gets attempted with each actual TerminationID that matches the wildcard. You get a response in the TransactionReply for every matching TerminationID, even if some of them errored. But if any one matching TerminationID errors out, any Commands after the wildcarded one are not attempted 🙈 Commands can be marked as "Optional", and that overrides this behaviour. So if an Optional-marked Command errors, the later Commands in the Transaction still run 💖 The TransactionReply has results for all the Commands in the matching TransactionRequest. It includes return values for the Commands that succeeded, plus the Command and error descriptor for any that failed. And TransactionPending is how you let the receiver know a Transaction hasn't finished yet but is actively being worked on ⏳
Applications SHOULD implement an application level timer per transaction 🌸 When that timer expires, the request should get retransmitted. Getting a Reply cancels the timer, and getting Pending restarts it ⏱️
8.1 Common Parameters 🎀
8.1.1 Transaction Identifiers 🪪
Transactions are identified by a TransactionID. The sender assigns it, and it has to be unique within the scope of that sender 💜
8.1.2 Context Identifiers 🧚
Contexts are identified by a ContextID. The Media Gateway assigns it, and it has to be unique within the scope of that Media Gateway ✨ The Media Gateway Controller shall use the ContextID the Media Gateway supplied in all later Transactions about that Context. There's also a special value the MGC can use when it's talking about a Termination that isn't attached to a Context right now: the null ContextID 🌈
The CHOOSE wildcard is how you ask the Media Gateway to create a new Context 🪄 The MGC shall not use partially specified ContextIDs that contain the CHOOSE wildcard 🙅♀️
The MGC may use the ALL wildcard to address all Contexts on the MG 🌍
8.2 Transaction Application Programming Interface 💅
Here comes the API, which shows off the Transactions and their parameters 🎀 It's there to illustrate things, not to dictate how anyone has to implement it. For example, it's not saying anything about blocking function calls. It's a high-level look at the input parameters and return values the various Transactions are expected to use. The actual syntax and encodings show up in later subsections 🫶
8.2.1 TransactionRequest 📨
The sender invokes the TransactionRequest, and each request invocation is one Transaction 💖 A request has one or more Actions. Each Action names its target Context and has one or more Commands per Context 🔥
TransactionRequest(TransactionId {
ContextID {Command _ Command},
. . .
ContextID {Command _ Command } })The TransactionID parameter has to have a value so the receiver's TransactionReply or TransactionPending can be matched back to it later 🔗
The ContextID parameter needs a value that applies to all the Commands after it, up until the next ContextID parameter shows up or the TransactionRequest ends, whichever happens first 🎯
The Command parameter stands for one of the Commands from the "Command Details" subsection called "Application Programming Interface" 🧁
8.2.2 TransactionReply 💌
okay bestie, the TransactionReply is what the receiver sends back 💅 There's exactly one reply invocation per transaction 🦋 A reply holds one or more Actions, and each Action has to name its target Context and include one or more Responses per Context ✨
TransactionReply(TransactionID {
ContextID { Response _ Response },
. . .
ContextID { Response _ Response } })The TransactionID parameter must be the same as the one in the corresponding TransactionRequest 🔁 The ContextID parameter must specify a value that pertains to all Responses for the action, and it may be specific or null 🌸
Each Response is either a return value from section 7.2 or an error descriptor if the command hit an error 🙈 Commands after the point of failure are not processed, so no Responses get issued for them 💀
There's one exception. If a command was marked as optional in the Transaction request and it generates an error, the transaction still keeps running 🏃♀️ In that case, the Reply can have Responses after an Error, which is lowkey iconic 🌈
Now for the error-handling drama 😭
If the receiver runs into an error while processing a ContextID, the requested Action response will be the context ID plus a single error descriptor, 422 Syntax Error in Action 🎀
If the receiver hits an error so bad it can't figure out a legal Action, it sends back a TransactionReply with the TransactionID and one error descriptor, 422 Syntax Error in Action 💔 If the end of an action can't be reliably determined but one or more Actions can still be parsed, the receiver processes those and then sends 422 Syntax Error in Action as the last action for the transaction 🫶
If the receiver hits an error so bad it can't determine a legal Transaction, it returns a TransactionReply with a null TransactionID and a single error descriptor, 403 Syntax Error in Transaction 🥺
If the end of a transaction can't be reliably determined and one or more Actions can be parsed, the receiver processes them and then returns 403 Syntax Error in Transaction as the last action reply for the transaction 🧚 If no Actions can be parsed at all, it returns 403 Syntax Error in Transaction as the only reply ✨
If the terminationID can't be reliably determined, the receiver sends 442 Syntax Error in Command as the action reply 🙃
If the end of a command can't be reliably determined, the receiver returns 442 Syntax Error in Transaction as the reply to the last action it can parse 💅
8.2.3 TransactionPending ⏳
The receiver invokes the TransactionPending, and it basically says "I'm on it, the transaction is actively being processed but not finished yet" 💖 It exists so the sender doesn't assume the TransactionRequest got lost when the transaction is going to take a while 🫠
TransactionPending(TransactionID { } )The TransactionID parameter must be the same as the one in the corresponding TransactionRequest 🔁 Now the spicy timing stuff 👀 A property of root (normalMGExecutionTime) is settable by the MGC, and it indicates the interval within which the MGC expects a response to any transaction from the MG ⏱️ Another property (normalMGCExecutionTime) is also settable by the MGC, and it indicates the interval within which the MG should expects a response to any transaction from the MGC 🌸
Senders may receive more than one TransactionPending for a command, so don't panic if you get a few 🦋 If a duplicate request shows up while the responder is pending, the responder may send a duplicate pending right away, or it can keep waiting for its timer to trigger another Transaction Pending 🧁
8.3 Messages 📬
Multiple Transactions can be concatenated into a Message 💜 Messages have a header, and that header includes the identity of the sender 🪪 The Message Identifier (MID) of a message is set to a provisioned name (e.g. domain address/domain name/device name) of the entity transmitting the message ✨ Domain name is a suggested default, so it's the one people usually go with 💅
Every Message contains a Version Number that identifies the version of the protocol the message conforms to 🔖 Versions consist of one or two digits, beginning with version 1 for the present version of the protocol 🌈
The transactions in a message are treated independently 🫧 There's no order implied, and there's no application or protocol acknowledgement of a message 🙃 It's giving "every transaction is its own main character" 👑
9. TRANSPORT 🚚
The transport mechanism for the protocol should allow the reliable transport of transactions between an MGC and MG 💌 The transport shall remain independent of what particular commands are being sent, and it shall be applicable to all application states 🦋 Several transports are defined for the protocol, and they're defined in normative Annexes to this document 📜 Additional Transports may be defined as additional annexes in subsequent editions of this document, or in separate documents 🌸 For transport of the protocol over IP, MGCs shall implement both TCP and UDP/ALF, and an MG shall implement TCP or UDP/ALF or both 🔥
The MG is provisioned with a name or address (such as a DNS name or IP address) of a primary and zero or more secondary MGCs (see section 7.2.8) 🧚 That's the address the MG uses to send messages to the MGC 💖 If TCP or UDP is used as the protocol transport and the port to which the initial ServiceChange request is to be sent is not otherwise known, that request should be sent to the default port number for the protocol 🎀 That port number is 2944 for text-encoded operation or 2945 for binary-encoded operation, for either UDP or TCP 🍓 The MGC receives the message containing the ServiceChange request from the MG and can figure out the MG's address from it 👀 As described in section 7.2.8, either the MG or the MGC may supply an address in the ServiceChangeAddress parameter, and subsequent transaction requests must be addressed to that address 🗺️ Responses, though, including the response to the initial ServiceChange request, must always be sent back to the address that was the source of the corresponding request 🫶
9.1 Ordering of Commands 🔢
This document does not mandate that the underlying transport protocol guarantees the sequencing of transactions sent to an entity 🙈 This property tends to maximize the timeliness of actions, but it has a few drawbacks, like:
- Notify commands may be delayed and arrive at the MGC after the transmission of a new command changing the EventsDescriptor 😭
- If a new command is transmitted before a previous one is acknowledged, there is no guarantee that the prior command will be executed before the new one 💀
Media Gateway Controllers that want to guarantee consistent operation of the Media Gateway may use the following rules 💅 These rules are with respect to commands that are in different transactions 🧠 Commands that are in the same transaction are executed in order (see section 8) ✨
- When a Media Gateway handles several Terminations, commands pertaining to the different Terminations may be sent in parallel, for example following a model where each Termination (or group of Terminations) is controlled by its own process or its own thread 🧵
- On a Termination, there should normally be at most one outstanding command (Add or Modify or Move), unless the outstanding commands are in the same transaction 🌷 However, a Subtract command may be issued at any time 🫧 In consequence, a Media Gateway may sometimes receive a Modify command that applies to a previously subtracted Termination 😬 Such commands should be ignored, and an error code should be returned 🚫
- On a given Termination, there should normally be at most one outstanding Notify command at any time 🔔
- In some cases, an implicitly or explicitly wildcarded Subtract command that applies to a group of Terminations may step in front of a pending Add command 🌪️ The Media Gateway Controller should individually delete all Terminations for which an Add command was pending at the time of the global Subtract command 🗑️ Also, new Add commands for Terminations named by the wild-carding (or implied in a Multiplex descriptor) should not be sent until the wild-carded Subtract command is acknowledged 🙏
- AuditValue and AuditCapability are not subject to any sequencing 🥰
- ServiceChange shall always be the first command sent by a MG as defined by the restart procedure 🚀 Any other command or response must be delivered after this ServiceChange command 🏁
These rules do not affect the command responder, which should always respond to commands 💜
9.2. Protection against Restart Avalanche 🌊
Okay so picture this: a bunch of Media Gateways get powered on at the exact same moment, and they ALL try to send a ServiceChange transaction at once 😭. The Media Gateway Controller would very likely get totally swamped, which means messages get lost and the network gets congested right when everything is trying to come back up. Not it! To stop these avalanches, the following behavior is suggested:
- When a Media Gateway is powered on, it should start a restart timer set to a random value. That value is uniformly distributed between 0 and a maximum waiting delay (MWD). Make sure the random number generation doesn't line up across multiple Media Gateways that use the same algorithm 🎲.
- The Media Gateway should then wait for whichever comes first: the timer running out, or the detection of a local user activity, such as an off-hook transition on a residential Media Gateway 📞.
- When the timer elapses, or when an activity is detected, the Media Gateway should initiate the restart procedure.
The restart procedure is honestly simple. The MG just has to guarantee that the first message the Media Gateway Controller sees from this MG is a ServiceChange message informing the MGC about the restart 💖.
Note - The value of MWD is a configuration parameter that depends on the type of the Media Gateway. The following reasoning may be used to determine the value of this delay on residential gateways.
Okay, the math is giving main character energy 🧮. MGCs are usually sized to handle the peak hour traffic load, when on average 10% of the lines are busy, placing calls that typically last 3 minutes. Each call usually involves 5 to 6 MGC transactions between each Media Gateway and the MGC. So the MGC is expected to handle 5 to 6 transactions for each Termination every 30 minutes on average. Or, to put it another way, about one transaction per Termination every 5 to 6 minutes on average. This suggests that a reasonable value of MWD for a residential gateway would be 10 to 12 minutes. If there's no explicit configuration, residential gateways should adopt a value of 600 seconds for MWD 🎀.
The same logic says the MWD should be way shorter for trunking gateways or business gateways 🏢. They handle a huge number of Terminations, and the usage rate of those Terminations is much higher than 10% during the peak busy hour, with a typical value being 60%. During the peak hour, these Terminations are expected to contribute about one transaction per minute to the MGC load. A reasonable algorithm is to make the MWD per "trunk" Termination six times shorter than the MWD per residential gateway, and also inversely proportional to the number of Terminations being restarted. For example, MWD should be set to 2.5 seconds for a gateway that handles a T1 line, or to 60 milliseconds for a gateway that handles a T3 line 🦋.
10. SECURITY CONSIDERATIONS 🔒
This section covers security when using the protocol in an IP environment. Pay attention, bestie, this part is serious 🫶.
10.1. Protection of Protocol Connections
A security mechanism is clearly needed to stop unauthorized entities from using the protocol defined in this document to set up unauthorized calls or to interfere with authorized calls 🚨. When the protocol is transported over IP networks, the security mechanism is IPsec [RFC2401 to RFC2411].
The AH header [RFC2402] gives data origin authentication, connectionless integrity and optional anti-replay protection for messages passed between the MG and the MGC. The ESP header [RFC2406] provides confidentiality for messages, if that's wanted. For instance, the ESP encryption service should be requested if the session descriptions are used to carry session keys, as defined in SDP 🔐.
Implementations of the protocol defined in this document that use the ESP header SHALL comply with section 5 of [RFC2406], which defines a minimum set of algorithms for integrity checking and encryption. Similarly, implementations that use the AH header SHALL comply with section 5 of [RFC2402], which defines a minimum set of algorithms for integrity checking using manual keys.
Implementations SHOULD use IKE [RFC2409] to get more robust keying options. Implementations that use IKE SHOULD support authentication with RSA signatures and RSA public key encryption 🗝️.
10.2. Interim AH scheme
Implementing IPsec requires the AH or ESP header to be inserted immediately after the IP header. That can't be done easily at the application level 😩. So this creates a deployment problem for the protocol defined in this document when the underlying network implementation doesn't support IPsec.
As an interim solution, an optional AH header is defined within the H.248 protocol header 🩹. The header fields are exactly the SPI, SEQUENCE NUMBER and DATA fields defined in [RFC2402]. The semantics of the header fields are the same as the "transport mode" of [RFC2402], except for how the Integrity Check value (ICV) is calculated. In IPsec, the ICV is calculated over the entire IP packet, including the IP header. That's what stops IP address spoofing. To keep the same functionality, the ICV calculation should be performed across the entire transaction, prepended by a synthesized IP header made of a 32 bit source IP address, a 32 bit destination address and a 16 bit UDP port, encoded as 10 hex digits. When the interim AH mechanism is used with TCP as the transport layer, the UDP Port above becomes the TCP port, and everything else works the same ✨.
Implementations of the H.248 protocol SHALL implement IPsec where the underlying operating system and the transport network support IPsec. Implementations of the protocol using IPv4 SHALL implement the interim AH scheme. However, this interim scheme SHALL NOT be used when the underlying network layer supports IPsec. IPv6 implementations are assumed to support IPsec and SHALL NOT use the interim AH scheme 💅.
All implementations of the interim AH mechanism SHALL comply with section 5 of [RFC2402], which defines a minimum set of algorithms for integrity checking using manual keys.
Okay, real talk, the interim AH interim scheme does NOT protect against eavesdropping 👀. That means third parties could monitor the connections set up by a given termination. It also doesn't protect against replay attacks. These procedures don't necessarily protect against denial of service attacks from misbehaving MGs or misbehaving MGCs. However, they do identify these misbehaving entities, who should then be deprived of their authorization through maintenance procedures 🚫.
10.3. Protection of Media Connections
The protocol lets the MGC give MGs "session keys" that can be used to encrypt the audio messages, which protects against eavesdropping 🎧.
A specific problem with packet networks is "uncontrolled barge-in". This attack can be carried out by directing media packets at the IP address and UDP port used by a connection. If no protection is in place, the packets have to be decompressed and the signals get played on the "line side". Yikes 😱.
A basic protection against this attack is to only accept packets from known sources, for example by checking that the IP source address and UDP source port match the values announced in the Remote Descriptor. This comes with two inconveniences: it slows down connection establishment, and it can be fooled by source spoofing 🙃.
- To enable the address-based protection, the MGC has to get the remote session description of the egress MG and pass it to the ingress MG. This takes at least one network roundtrip, and leaves us with a dilemma. Either allow the call to proceed without waiting for the roundtrip to complete, and risk, for example, "clipping" a remote announcement, or wait for the full roundtrip and settle for slower call set-up procedures 🤯.
- Source spoofing only works if the attacker can get valid pairs of source and destination addresses and ports, for example by listening to a fraction of the traffic. To fight source spoofing, one could try to control all access points to the network. But in practice that's very hard to achieve 🫠.
An alternative to checking the source address is to encrypt and authenticate the packets, using a secret key that is conveyed during the call set-up procedure. This won't slow down call set-up, and it gives strong protection against address spoofing 🛡️.
11. MG-MGC CONTROL INTERFACE ✨
The control association between MG and MGC is initiated at MG cold start and announced by a ServiceChange message, but it can be changed by later events, such as failures or manual service events 🔄. The protocol doesn't have an explicit mechanism for multiple MGCs controlling one physical MG. It was designed, though, to support the multiple logical MGs (within a single physical MG) that can be associated with different MGCs 🌈.
11.1. Multiple Virtual MGs
A physical Media Gateway may be partitioned into one or more Virtual MGs. A Virtual MG consists of a set of statically partitioned physical Terminations and/or sets of ephemeral Terminations. A physical Termination is controlled by one MGC. The model doesn't require other resources to be statically allocated, just Terminations. How Terminations get allocated to Virtual MGs is a management method outside the scope of the protocol. Each Virtual MG looks to the MGC like a complete MG client 🧩.
A physical MG may have only one network interface, and it has to be shared across Virtual MGs. In that case the packet/cell side Termination is shared. It's worth noting that, in use, these interfaces need an ephemeral instance of the Termination to be created per flow, so sharing the Termination is pretty straightforward. This does add a complication, though: the MG must always know which of its controlling MGCs should be notified if an event happens on the interface 🤔.
In normal operation, the Virtual MG will be told by the MGC to create network flows (if it's the originating side) or to expect flow requests (if it's the terminating side), and no confusion will arise 💜. But if an unexpected event happens, the Virtual MG must know what to do with the physical resources it's controlling.
If recovering from the event requires changing a physical interface's state, only one MGC should do it. These issues are handled by letting any of the MGCs create EventsDescriptors to be notified of such events, while only one MGC gets read/write access to the physical interface properties. All other MGCs get read-only access. The management mechanism designates which MGC has read/write capability, and that MGC is called the Master MGC 👑.
Each Virtual MG has its own Root Termination. In most cases, each MGC can set the values for the properties of the Root Termination independently. Where there can only be one value, the parameter is read-only to everyone except the Master MGC 🔒.
ServiceChange may only be applied to a Termination or set of Terminations partitioned to the Virtual MG, or created (in the case of ephemeral Terminations) by that Virtual MG 🎀.
11.2 Cold Start ❄️
Okay bestie, so an MG gets pre-provisioned by a management mechanism that lives outside this protocol 🙅♀️ with a Primary MGC and, optionally, an ordered list of Secondary MGCs. When an MG cold starts, it sends a ServiceChange with a "Restart" method on the Root Termination to its Primary MGC. If the MGC accepts the MG, it sends back a Transaction Accept with ServiceChangeMgcId set to itself. If the MG gets a ServiceChangeMgcId that isn't the MGC it contacted, it sends a ServiceChange to the MGC named in ServiceChangeMgcId. It keeps doing this until a controlling MGC accepts its registration or it fails to get a reply 🔁. If there's no reply from the Primary MGC or from a designated successor, the MG tries its pre-provisioned Secondary MGCs, in order. If the MG can't comply and it has already set up a transport connection to the MGC, it SHOULD close that connection. Either way, it SHOULD reject all later requests from the MGC with Error 406 Version Not Supported.
It's possible the reply to a ServiceChange with Restart gets lost, and a command shows up at the MG before the ServiceChange response does 💀. In that case, the MG SHALL issue error 505 - Command Received before Restart Response.
11.3 Negotiation of Protocol Version 🤝
The first ServiceChange command from an MG SHALL contain the version number of the protocol that the MG supports, in the ServiceChangeVersion parameter. When the MGC gets that, if it only supports a lower version, it SHALL send a ServiceChangeReply with the lower version, and from then on every message between the MG and the MGC SHALL conform to the lower version. If the MG can't comply and it has already set up a transport connection to the MGC, it SHOULD close that connection. Either way, it SHOULD reject all later requests from the MGC with Error 406 Version Not supported.
If the MGC supports a higher version than the MG but can handle the lower version the MG proposed, it SHALL send a ServiceChangeReply with the lower version, and from then on all messages between the MG and the MGC SHALL conform to the lower version. If the MGC can't comply, it SHALL reject the association with Error 406 Version Not Supported.
Protocol version negotiation MAY also happen during "handoff" and "failover" ServiceChanges 🔄.
When extending the protocol with new versions, these rules SHOULD be followed:
- Existing protocol elements, i.e., procedures, parameters, descriptor, property, values, SHOULD NOT be changed unless a protocol error needs to be corrected or it becomes necessary to change the operation of the service that is being supported by the protocol.
- The semantics of a command, a parameter, descriptor, property, value SHOULD NOT be changed.
- Established rules for formatting and encoding messages and parameters SHOULD NOT be modified.
- When information elements are found to be obsolete they can be marked as not used. However, the identifier for that information element will be marked as reserved. In that way it can not be used in future versions.
11.4 Failure of an MG 💥
If an MG fails but can still send a message to the MGC, it sends a ServiceChange with an appropriate method (graceful or forced) and specifies the Root TerminationID. When it returns to service, it sends a ServiceChange with a "Restart" method 🩹.
Allowing the MGC to send duplicate messages to both MGs supports pairs of MGs that can do redundant failover of one of the MGs 👯. Only the Working MG SHALL accept or reject transactions. On failover, the Primary MG sends a ServiceChange command with a "Failover" method and a "MG Impending Failure" reason. The MGC then uses the primary MG as the active MG. Once the error condition is repaired, the Working MG can send a "ServiceChange" with a "Restart" method ✨.
11.5 Failure of an MGC 🚨
If the MG detects a failure of its controlling MGC, it tries to contact the next MGC on its pre-provisioned list. It starts at the beginning (the Primary MGC), unless that was the MGC that failed, in which case it starts at its first Secondary MGC. It sends a ServiceChange message with a "Failover" method and a " MGC Impending Failure" reason.
In partial failure, or for manual maintenance reasons, an MGC MAY want to direct its controlled MGs to use a different MGC 🎯. To do so, it sends a ServiceChange method to the MG with a "HandOff" method, and its designated replacement in ServiceChangeMgcId. The MG SHOULD send a ServiceChange message with a "Handoff" method and a "MGC directed change" reason to the designated MGC. If it fails to get a reply, or fails to see an Audit command afterward, it SHOULD behave as if its MGC failed, and start contacting Secondary MGCs. If the MG is unable to establish a control relationship with any MGC, it SHALL wait a random amount of time as described in section 9.2, and then start contacting its Primary and, if necessary, its Secondary MGCs again.
No recommendation is made on how the MGCs involved in the Handoff maintain state information. That's considered out of scope for this recommendation 🙃. The MGC and MG MAY take the following steps when a Handoff occurs. When the MGC initiates a HandOff, the handover SHOULD be transparent to Operations on the Media Gateway. Transactions can be executed in any order, and could be in progress when the ServiceChange is executed. So commands in progress continue, transaction replies are sent to the new MGC (after a new control association is established), and the MG SHOULD expect outstanding transaction replies from the new MGC. No new messages SHALL be sent to the new MGC until the control association is established. Repeated transaction requests SHALL be directed to the new MGC. The MG SHALL maintain state on all terminations and contexts.
It's possible that the MGC could be implemented so that a failed MGC gets replaced by a working MGC with the same identity as the failed one 🪞. In that case, ServiceChangeMgcId would be specified with the previous value, and the MG SHALL behave as if the value was changed, and send a ServiceChange message, as above.
Pairs of MGCs that are capable of redundant failover can notify the controlled MGs of the failover by the above mechanism 💜.
12. PACKAGE DEFINITION 📦
The primary mechanism for extension is by means of Packages 🧩. Packages define additional Properties, Events, Signals and Statistics that MAY occur on Terminations.
Packages defined by IETF will appear in separate RFCs.
Packages defined by ITU-T MAY appear in the relevant recommendations (e.g. as annexes).
- A public document or a standard forum document, which can be referenced as the document that describes the package following the guideline above, SHOULD be specified.
- The document SHALL specify the version of the Package that it describes.
- The document SHOULD be available on a public web server and SHOULD have a stable URL. The site SHOULD provide a mechanism to provide comments, and appropriate responses SHOULD be returned.
12.1 Guidelines for defining packages 🛠️
Packages define Properties, Events, Signals, and Statistics.
Packages MAY also define new error codes according to the guidelines given in section 13.2. This is a matter of documentary convenience: the package documentation is submitted to IANA in support of the error code registration. If a package is modified, it is unnecessary to provide IANA with a new document reference in support of the error code unless the description of the error code itself is modified.
Names of all such defined constructs SHALL consist of the PackageID (which uniquely identifies the package) and the ID of the item (which uniquely identifies the item in that package). In the text encoding the two SHALL be separated by a forward slash ("/") character. Example: togen/playtone is the text encoding to refer to the play tone signal in the tone generation package 🎵.
A Package will contain the following sections:
12.1.1 Package 📝
Overall description of the package, specifying:
- Package Name: only descriptive,
- PackageID: Is an identifier
- Description:
- Version: A new version of a package can only add additional Properties, Events, Signals, Statistics and new possible values for an existing parameter described in the original package. No deletions or modifications SHALL be allowed. A version is an integer in the range from 1 to 99.
- Extends (Optional): A package MAY extend an existing package. The version of the original package must be specified. When a package extends another package it SHALL only add additional Properties, Events, Signals, Statistics and new possible values for an existing parameter described in the original package. An extended package SHALL NOT redefine or overload a name defined in the original package. Hence, if package B version 1 extends package A version 1, version 2 of B will not be able to extend the A version 2 if A version 2 defines a name already in B version 1.
12.1.2 Properties 🎀
Properties defined by the package, specifying:
- Property Name: only descriptive.
- PropertyID: Is an identifier
- Description:
- Type: One of:
- String: UTF-8 string
- Integer: 4 byte signed integer
- Double: 8 byte signed integer
- Character: Unicode UTF-8 encoding of a single letter. Could be more than one octet.
- Enumeration: One of a list of possible unique values (See 12.3)
- Sub-list: A list of several values from a list
- Boolean
- Possible Values:
- Defined in: Which H.248 descriptor the property is defined in. LocalControl is for stream dependent properties. TerminationState is for stream independent properties.
- Characteristics: Read / Write or both, and (optionally), global: Indicates whether a property is read-only, or read-write, and if it is global. If Global is omitted, the property is not global. If a property is declared as global, the value of the property is shared by all terminations realizing the package.
12.1.3 Events 🎉
Events defined by the package, specifying:
- Event name: only descriptive.
- EventID: Is an identifier
- Description:
- EventsDescriptor Parameters: Parameters used by the MGC to configure the event, and found in the EventsDescriptor. See section 12.2.
- ObservedEventsDescriptor Parameters: Parameters returned to the MGC in Notify requests and in replies to command requests from the MGC that audit ObservedEventsDescriptor, and found in the ObservedEventsDescriptor. See section 12.2.
12.1.4 Signals ✨
Okay so signals are the things a package can do, bestie 💅 Every signal the package defines needs these details:
- Signal Name: only descriptive 🎀
- SignalID: an identifier, used in a SignalsDescriptor 🦋
- Description 💖
- SignalType: one of:
- OO (On/Off) 🌈
- TO (TimeOut) ⭐
- BR (Brief) 🍓
- Duration: in hundredths of seconds ⏱️
- Additional Parameters: See section 12.2 🧚
SignalType can be defined so that it depends on the value of one or more parameters. Signals that would be played with SignalType BR should have a default duration. The package has to define the default duration and signalType. 😭🫶
12.1.5 Statistics 📊
Statistics are the numbers a package keeps track of, and each one needs:
- Statistic name: only descriptive 🌸
- StatisticID: an identifier, used in a StatisticsDescriptor 💜
- Description ✨
- Units: the unit of measure, e.g. milliseconds, packets 🔥
12.1.6 Procedures 🎀
This is where you put extra guidance on how to actually use the package, so the vibe is "read this before you touch it" 👑
12.2. Guidelines to defining Properties, Statistics and Parameters to Events and Signals 🧁
Every parameter needs these bits filled in:
- Parameter Name: only descriptive 🦋
- ParameterID: an identifier 💖
- Type: one of:
- String: UTF-8 octet string 🌸
- Integer: 4 octet signed integer 🔥
- Double: 8 octet signed integer 💅
- Character: Unicode UTF-8 encoding of a single letter. Could be more than one octet. 🌈
- Enumeration: one of a list of possible unique values (See 12.3) ✨
- Sub-list: a list of several values from a list 🍓
- Boolean 🙈
- Possible values: 🧚
- Description: 💜
12.3. Lists 📝
Possible values for parameters can be enumerations, and enumerations can be defined in a list. It is recommended that the list be IANA registered, so that packages which extend the list can be defined without worrying about conflicting names. Main character energy 👑🎀
12.4. Identifiers 🆔
Identifiers in text encoding shall be strings of up to 64 characters, containing no spaces, starting with an alphanumeric character and consisting of alphanumeric characters and / or digits, and possibly including the special character underscore ("_"). 💅
Identifiers in binary encoding are 2 octets long. 🧚
Both text and binary values shall be specified for each identifier, including identifiers used as values in enumerated types. No skipping 😭✨
12.5. Package Registration 📮
A package can be registered with IANA for interoperability reasons, so it can play nicely with everyone else 🫶 For the IANA stuff, see section 13 🌈
13. IANA CONSIDERATIONS 🌸
13.1. Packages 📦
The following considerations SHALL be met to register a package with IANA. Non-negotiable, bestie 🔥
- A unique string name, unique serial number and version number is registered for each package. The string name is used with text encoding. The serial number shall be used with binary encoding. Serial Numbers 60000-64565 are reserved for private use. Serial number 0 is reserved. 🎀
- A contact name, email and postal addresses for that contact shall be specified. The contact information shall be updated by the defining organization as necessary. 💌
- A reference to a document that describes the package, which should be public:
- The document shall specify the version of the Package that it describes. 🧾
- If the document is public, it should be located on a public web server and should have a stable URL. The site should provide a mechanism to provide comments, and appropriate responses should be returned. 🦋
- Packages registered by other than recognized standards bodies shall have a minimum package name length of 8 characters. 🍓
- All other package names are first come, first served, if all other conditions are met. 💖
13.2. Error Codes 🚨
The following considerations SHALL be met to register an error code with IANA. Strict, but iconic 💅
- An error number and a one line (80 character maximum) string is registered for each error. 🌈
- A complete description of the conditions under which the error is detected shall be included in a publicly available document. The description shall be sufficiently clear to differentiate the error from all other existing error codes. 🔍
- The document should be available on a public web server and should have a stable URL. 🌸
- Error numbers registered by recognized standards bodies shall have 3 or 4 character error numbers. ✨
- Error numbers registered by all other organizations or individuals shall have 4 character error numbers. 🧚
- An error number shall not be redefined, nor modified except by the organization or individual that originally defined it, or their successors or assigns. Hands off, periodt 🙅♀️💜
13.3. ServiceChange Reasons 🔁
The following considerations SHALL be met to register a service change reason with IANA. 🎀
- A one phrase, 80-character maximum, unique reason code is registered for each reason. 🦋
- A complete description of the conditions under which the reason is used is detected shall be included in a publicly available document. The description shall be sufficiently clear to differentiate the reason from all other existing reasons. 💖
- The document should be available on a public web server and should have a stable URL. 🫶
ANNEX A: BINARY ENCODING OF THE PROTOCOL (NORMATIVE) 🧬
This Annex specifies the syntax of messages using the notation defined in ASN.1 [ITU-T Recommendation X.680 (1997): Information Technology - Abstract Syntax Notation One (ASN.1) - Specification of basic notation.]. Messages shall be encoded for transmission by applying the basic encoding rules specified in [ITU-T Recommendation X.690(1994) Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER)]. Standards nerd moment, but make it iconic 🤓💅
A.1. Coding of wildcards 🃏
Wildcards ALL and CHOOSE are allowed in the protocol. This lets an MGC partially specify Termination IDs and let the MG choose from the values that conform to the partial specification. Termination IDs may encode a hierarchy of names, and that hierarchy is provisioned. For instance, a TerminationID may consist of a trunk group, a trunk within the group and a circuit. Wildcarding must be possible at all levels. The following paragraphs explain how this is achieved 🌳✨
The ASN.1 description uses octet strings of up to 8 octets in length for Termination IDs. That means Termination IDs consist of at most 64 bits. A fully specified Termination ID may be preceded by a sequence of wildcarding fields. A wildcarding field is one octet in length. Bit 7 (the most significant bit) of this octet specifies what type of wildcarding is invoked: if the bit value equals 1, then the ALL wildcard is used; if the bit value is 0, then the CHOOSE wildcard is used. Bit 6 of the wildcarding field specifies whether the wildcarding pertains to one level in the hierarchical naming scheme (bit value 0) or to the level of the hierarchy specified in the wildcarding field plus all lower levels (bit value 1). Bits 0 through 5 of the wildcarding field specify the bit position in the Termination ID at which the starts. 🧩
We illustrate this scheme with some examples. In these examples, the most significant bit in a string of bits appears on the left hand side. Picture it like this 👀
Assume that Termination IDs are three octets long and that each octet represents a level in a hierarchical naming scheme. A valid Termination ID is:
00000001 00011110 01010101Addressing ALL names with prefix 00000001 00011110 is done as follows:
wildcarding field: 10000111
Termination ID: 00000001 00011110 xxxxxxxxThe values of the bits labeled "x" are irrelevant and shall be ignored by the receiver. Bits you don't care about get ignored, no drama 🙈
Indicating to the receiver that it must choose a name with 00011110 as the second octet is done as follows:
wildcarding fields: 00010111 followed by 00000111
Termination ID: xxxxxxxx 00011110 xxxxxxxxThe first wildcard field indicates a CHOOSE wildcard for the level in the naming hierarchy starting at bit 23, the highest level in our assumed naming scheme. The second wildcard field indicates a CHOOSE wildcard for the level in the naming hierarchy starting at bit 7, the lowest level in our assumed naming scheme. 🌟
Finally, a CHOOSE-wildcarded name with the highest level of the name equal to 00000001 is specified as follows:
wildcard field: 01001111
Termination ID: 0000001 xxxxxxxx xxxxxxxxBit value 1 at bit position 6 of the first octet of the wildcard field indicates that the wildcarding pertains to the specified level in the naming hierarchy and all lower levels. Level-skipping slay 💅🦋
Context IDs can be wildcarded too. With Context IDs, however, specifying partial names is not allowed. Context ID 0x0 SHALL be used to indicate the NULL Context, Context ID 0xFFFFFFFE SHALL be used to indicate a CHOOSE wildcard, and Context ID 0xFFFFFFFF SHALL be used to indicate an ALL wildcard. 🆔
TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT Termination. 🌍
A.2. ASN.1 syntax specification 🧾
This section contains the ASN.1 specification of the H.248 protocol syntax. Here's the full grammar, no cap 🧠
NOTE - In case a transport mechanism is used that employs application level framing, the definition of Transaction below changes. Refer to the annex defining the transport mechanism for the definition that applies in that case. ⚠️
NOTE - The ASN.1 specification below contains a clause defining TerminationIDList as a sequence of TerminationIDs. The length of this sequence SHALL be one. The SEQUENCE OF construct is present only to allow future extensions. 🔮
MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::= BEGIN
MegacoMessage ::= SEQUENCE
{
authHeader AuthenticationHeader OPTIONAL,
mess Message
}
AuthenticationHeader ::= SEQUENCE
{
secParmIndex SecurityParmIndex,
seqNum SequenceNum,
ad AuthData
}
SecurityParmIndex ::= OCTET STRING(SIZE(4))
SequenceNum ::= OCTET STRING(SIZE(4))
AuthData ::= OCTET STRING (SIZE (16..32))
Message ::= SEQUENCE
{
version INTEGER(0..99),
-- The version of the protocol defined here is equal to 1.
mId MId, -- Name/address of message originator
messageBody CHOICE
{
messageError ErrorDescriptor,
transactions SEQUENCE OF Transaction
},
...
}
MId ::= CHOICE
{
ip4Address IP4Address,
ip6Address IP6Address,
domainName DomainName,
deviceName PathName,
mtpAddress OCTET STRING(SIZE(2)),
-- Addressing structure of mtpAddress:
-- 15 0
-- | PC | NI |
-- 14 bits 2 bits
...
}
DomainName ::= SEQUENCE
{
name IA5String,
-- The name starts with an alphanumeric digit followed by a
-- sequence of alphanumeric digits, hyphens and dots. No two
-- dots shall occur consecutively.
portNumber INTEGER(0..65535) OPTIONAL
}
IP4Address ::= SEQUENCE
{
address OCTET STRING (SIZE(4)),
portNumber INTEGER(0..65535) OPTIONAL
}
IP6Address ::= SEQUENCE
{
address OCTET STRING (SIZE(16)),
portNumber INTEGER(0..65535) OPTIONAL
}
PathName ::= IA5String(SIZE (1..64))
-- See section A.3okay bestie, the grammar keeps going and it is ICONIC 💅✨ Every line below is copied exactly, because one stray space in ASN.1 and the whole thing breaks 💀
Transaction ::= CHOICE
{
transactionRequest TransactionRequest,
transactionPending TransactionPending,
transactionReply TransactionReply,
transactionResponseAck TransactionResponseAck,
-- use of response acks is dependent on underlying
transport
...
}
TransactionId ::= INTEGER(0..4294967295) -- 32 bit unsigned integer
TransactionRequest ::= SEQUENCE
{
transactionId TransactionId,
actions SEQUENCE OF ActionRequest,
...
}
TransactionPending ::= SEQUENCE
{
transactionId TransactionId,
...
}
TransactionReply ::= SEQUENCE
{
transactionId TransactionId,
transactionResult CHOICE
{
transactionError ErrorDescriptor,
actionReplies SEQUENCE OF ActionReply
},
...
}
TransactionResponseAck ::= SEQUENCE
{
firstAck TransactionId,
lastAck TransactionId OPTIONAL
}
ErrorDescriptor ::= SEQUENCE
{
errorCode ErrorCode,
errorText ErrorText OPTIONAL
}
ErrorCode ::= INTEGER(0..65535)
-- See section 13 for IANA considerations w.r.t. error codes
ErrorText ::= IA5String
ContextID ::= INTEGER(0..4294967295)
-- Context NULL Value: 0
-- Context CHOOSE Value: 429467294 (0xFFFFFFFE)
-- Context ALL Value: 4294967295 (0xFFFFFFFF)
ActionRequest ::= SEQUENCE
{
contextId ContextID,
contextRequest ContextRequest OPTIONAL,
contextAttrAuditReq ContextAttrAuditRequest OPTIONAL,
commandRequests SEQUENCE OF CommandRequest
}
ActionReply ::= SEQUENCE
{
contextId ContextID,
errorDescriptor ErrorDescriptor OPTIONAL,
contextReply ContextRequest OPTIONAL,
commandReply SEQUENCE OF CommandReply
}
ContextRequest ::= SEQUENCE
{
priority INTEGER(0..15) OPTIONAL,
emergency BOOLEAN OPTIONAL,
topologyReq SEQUENCE OF TopologyRequest OPTIONAL,
...
}
ContextAttrAuditRequest ::= SEQUENCE
{
topology NULL OPTIONAL,
emergency NULL OPTIONAL,
priority NULL OPTIONAL,
...
}
CommandRequest ::= SEQUENCE
{
command Command,
optional NULL OPTIONAL,
wildcardReturn NULL OPTIONAL,
...
}
Command ::= CHOICE
{
addReq AmmRequest,
moveReq AmmRequest,
modReq AmmRequest,
-- Add, Move, Modify requests have the same parameters
subtractReq SubtractRequest,
auditCapRequest AuditRequest,
auditValueRequest AuditRequest,
notifyReq NotifyRequest,
serviceChangeReq ServiceChangeRequest,
...
}
CommandReply ::= CHOICE
{
addReply AmmsReply,
moveReply AmmsReply,
modReply AmmsReply,
subtractReply AmmsReply,
-- Add, Move, Modify, Subtract replies have the same parameters
auditCapReply AuditReply,
auditValueReply AuditReply,
notifyReply NotifyReply,
serviceChangeReply ServiceChangeReply,
...
}
TopologyRequest ::= SEQUENCE
{
terminationFrom TerminationID,
terminationTo TerminationID,
topologyDirection ENUMERATED
{
bothway(0),
isolate(1),
oneway(2)
}
}
AmmRequest ::= SEQUENCE
{
terminationID TerminationIDList,
mediaDescriptor MediaDescriptor OPTIONAL,
modemDescriptor ModemDescriptor OPTIONAL,
muxDescriptor MuxDescriptor OPTIONAL,
eventsDescriptor EventsDescriptor OPTIONAL,
eventBufferDescriptor EventBufferDescriptor OPTIONAL,
signalsDescriptor SignalsDescriptor OPTIONAL,
digitMapDescriptor DigitMapDescriptor OPTIONAL,
auditDescriptor AuditDescriptor OPTIONAL,
...
}
AmmsReply ::= SEQUENCE
{
terminationID TerminationIDList,
terminationAudit TerminationAudit OPTIONAL
}
SubtractRequest ::= SEQUENCE
{
terminationID TerminationIDList,
auditDescriptor AuditDescriptor OPTIONAL,
...
}
AuditRequest ::= SEQUENCE
{
terminationID TerminationID,
auditDescriptor AuditDescriptor,
...
}
AuditReply ::= SEQUENCE
{
terminationID TerminationID,
auditResult AuditResult
}
AuditResult ::= CHOICE
{
contextAuditResult TerminationIDList,
terminationAuditResult TerminationAudit
}
AuditDescriptor ::= SEQUENCE
{
auditToken BIT STRING
{
muxToken(0), modemToken(1), mediaToken(2),
eventsToken(3), signalsToken(4),
digitMapToken(5), statsToken(6),
observedEventsToken(7),
packagesToken(8), eventBufferToken(9)
} OPTIONAL,
...
}
TerminationAudit ::= SEQUENCE OF AuditReturnParameter
AuditReturnParameter ::= CHOICE
{
errorDescriptor ErrorDescriptor,
mediaDescriptor MediaDescriptor,
modemDescriptor ModemDescriptor,
muxDescriptor MuxDescriptor,
eventsDescriptor EventsDescriptor,
eventBufferDescriptor EventBufferDescriptor,
signalsDescriptor SignalsDescriptor,
digitMapDescriptor DigitMapDescriptor,
observedEventsDescriptor ObservedEventsDescriptor,
statisticsDescriptor StatisticsDescriptor,
packagesDescriptor PackagesDescriptor,
...
}
NotifyRequest ::= SEQUENCE
{
terminationID TerminationIDList,
observedEventsDescriptor ObservedEventsDescriptor,
errorDescriptor ErrorDescriptor OPTIONAL,
...
}
NotifyReply ::= SEQUENCE
{
terminationID TerminationIDList OPTIONAL,
errorDescriptor ErrorDescriptor OPTIONAL,
...
}
ObservedEventsDescriptor ::= SEQUENCE
{
requestId RequestID,
observedEventLst SEQUENCE OF ObservedEvent
}
ObservedEvent ::= SEQUENCE
{
eventName EventName,
streamID StreamID OPTIONAL,
eventParList SEQUENCE OF EventParameter,
timeNotation TimeNotation OPTIONAL
}
EventName ::= PkgdName
EventParameter ::= SEQUENCE
{
eventParameterName Name,
value Value
}
ServiceChangeRequest ::= SEQUENCE
{
terminationID TerminationIDList,
serviceChangeParms ServiceChangeParm,
...
}
ServiceChangeReply ::= SEQUENCE
{
terminationID TerminationIDList,
serviceChangeResult ServiceChangeResult,
...
}
-- For ServiceChangeResult, no parameters are mandatory. Hence the
-- distinction between ServiceChangeParm and ServiceChangeResParm.
ServiceChangeResult ::= CHOICE
{
errorDescriptor ErrorDescriptor,
serviceChangeResParms ServiceChangeResParm
}
WildcardField ::= OCTET STRING(SIZE(1))
TerminationID ::= SEQUENCE
{
wildcard SEQUENCE OF WildcardField,
id OCTET STRING(SIZE(1..8))
}
-- See Section A.1 for explanation of wildcarding mechanism.
-- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination.
TerminationIDList ::= SEQUENCE OF TerminationID
MediaDescriptor ::= SEQUENCE
{
termStateDescr TerminationStateDescriptor OPTIONAL,
streams CHOICE
{
oneStream StreamParms,
multiStream SEQUENCE OF StreamDescriptor
},
...
}
StreamDescriptor ::= SEQUENCE
{
streamID StreamID,
streamParms StreamParms
}
StreamParms ::= SEQUENCE
{
localControlDescriptor LocalControlDescriptor OPTIONAL,
localDescriptor LocalRemoteDescriptor OPTIONAL,
remoteDescriptor LocalRemoteDescriptor OPTIONAL,
...
}
LocalControlDescriptor ::= SEQUENCE
{
streamMode StreamMode OPTIONAL,
reserveValue BOOLEAN,
reserveGroup BOOLEAN,
propertyParms SEQUENCE OF PropertyParm,
...
}
StreamMode ::= ENUMERATED
{
sendOnly(0),
recvOnly(1),
sendRecv(2),
inactive(3),
loopBack(4),
...
}
-- In PropertyParm, value is a SEQUENCE OF octet string. When sent
-- by an MGC the interpretation is as follows:
-- empty sequence means CHOOSE
-- one element sequence specifies value
-- longer sequence means "choose one of the values"
-- The relation field may only be selected if the value sequence
-- has length 1. It indicates that the MG has to choose a value
-- for the property. E.g., x > 3 (using the greaterThan
-- value for relation) instructs the MG to choose any value larger
-- than 3 for property x.
-- The range field may only be selected if the value sequence
-- has length 2. It indicates that the MG has to choose a value
-- in the range between the first octet in the value sequence and
-- the trailing octet in the value sequence, including the
-- boundary values.
-- When sent by the MG, only responses to an AuditCapability request
-- may contain multiple values, a range, or a relation field.
PropertyParm ::= SEQUENCE
{
name PkgdName,
value SEQUENCE OF OCTET STRING,
extraInfo CHOICE
{
relation Relation,
range BOOLEAN
} OPTIONAL
}
Name ::= OCTET STRING(SIZE(2))
PkgdName ::= OCTET STRING(SIZE(4))
-- represents Package Name (2 octets) plus Property Name (2 octets)
-- To wildcard a package use 0xFFFF for first two octets, choose
-- is not allowed. To reference native property tag specified in
-- Annex C, use 0x0000 as first two octets.
-- Wildcarding of Package Name is permitted only if Property Name is
-- also wildcarded.
Relation ::= ENUMERATED
{
greaterThan(0),
smallerThan(1),
unequalTo(2),
...
}
LocalRemoteDescriptor ::= SEQUENCE
{
propGrps SEQUENCE OF PropertyGroup,
...
}
PropertyGroup ::= SEQUENCE OF PropertyParm
TerminationStateDescriptor ::= SEQUENCE
{
propertyParms SEQUENCE OF PropertyParm,
eventBufferControl EventBufferControl OPTIONAL,
serviceState ServiceState OPTIONAL,
...
}
EventBufferControl ::= ENUMERATED
{
Off(0),
LockStep(1),
...
}that's the whole grammar block for this part 🦋 the types are all lined up now, and we're gonna keep building from here 🌸
ServiceState ::= ENUMERATED
{
test(0),
outOfSvc(1),
inSvc(2),
...
}
MuxDescriptor ::= SEQUENCE
{
muxType MuxType,
termList SEQUENCE OF TerminationID,
nonStandardData NonStandardData OPTIONAL,
...
}
MuxType ::= ENUMERATED
{
h221(0),
h223(1),
h226(2),
v76(3),
...
}
StreamID ::= INTEGER(0..65535) -- 16 bit unsigned integer
EventsDescriptor ::= SEQUENCE
{
requestID RequestID,
eventList SEQUENCE OF RequestedEvent
}
RequestedEvent ::= SEQUENCE
{
pkgdName PkgdName,
streamID StreamID OPTIONAL,
eventAction RequestedActions OPTIONAL,
evParList SEQUENCE OF EventParameter
}
RequestedActions ::= SEQUENCE
{
keepActive BOOLEAN,
eventDM EventDM OPTIONAL,
secondEvent SecondEventsDescriptor OPTIONAL,
signalsDescriptor SignalsDescriptor OPTIONAL,
...
}
EventDM ::= CHOICE
{ digitMapName DigitMapName,
digitMapValue DigitMapValue
}
SecondEventsDescriptor ::= SEQUENCE
{
requestID RequestID,
eventList SEQUENCE OF SecondRequestedEvent
}
SecondRequestedEvent ::= SEQUENCE
{
pkgdName PkgdName,
streamID StreamID OPTIONAL,
eventAction SecondRequestedActions OPTIONAL,
evParList SEQUENCE OF EventParameter
}
SecondRequestedActions ::= SEQUENCE
{
keepActive BOOLEAN,
eventDM EventDM OPTIONAL,
signalsDescriptor SignalsDescriptor OPTIONAL,
...
}
EventBufferDescriptor ::= SEQUENCE OF ObservedEvent
SignalsDescriptor ::= SEQUENCE OF SignalRequest
SignalRequest ::=CHOICE
{
signal Signal,
seqSigList SeqSigList
}
SeqSigList ::= SEQUENCE
{
id INTEGER(0..65535),
signalList SEQUENCE OF Signal
}
Signal ::= SEQUENCE
{
signalName SignalName,
streamID StreamID OPTIONAL,
sigType SignalType OPTIONAL,
duration INTEGER (0..65535) OPTIONAL,
notifyCompletion BOOLEAN OPTIONAL,
keepActive BOOLEAN OPTIONAL,
sigParList SEQUENCE OF SigParameter
}
SignalType ::= ENUMERATED
{
brief(0),
onOff(1),
timeOut(2),
...
}
SignalName ::= PkgdName
SigParameter ::= SEQUENCE
{
sigParameterName Name,
value Value
}
RequestID ::= INTEGER(0..4294967295) -- 32 bit unsigned integer
ModemDescriptor ::= SEQUENCE
{
mtl SEQUENCE OF ModemType,
mpl SEQUENCE OF PropertyParm,
nonStandardData NonStandardData OPTIONAL
}
ModemType ::= ENUMERATED
{
v18(0),
v22(1),
v22bis(2),
v32(3),
v32bis(4),
v34(5),
v90(6),
v91(7),
synchISDN(8),
...
}
DigitMapDescriptor ::= SEQUENCE
{
digitMapName DigitMapName,
digitMapValue DigitMapValue
}
DigitMapName ::= Name
DigitMapValue ::= SEQUENCE
{
startTimer INTEGER(0..99) OPTIONAL,
shortTimer INTEGER(0..99) OPTIONAL,
longTimer INTEGER(0..99) OPTIONAL,
digitMapBody IA5String
-- See Section A.3 for explanation of digit map syntax
}
ServiceChangeParm ::= SEQUENCE
{
serviceChangeMethod ServiceChangeMethod,
serviceChangeAddress ServiceChangeAddress OPTIONAL,
serviceChangeVersion INTEGER(0..99) OPTIONAL,
serviceChangeProfile ServiceChangeProfile OPTIONAL,
serviceChangeReason Value,
serviceChangeDelay INTEGER(0..4294967295) OPTIONAL,
-- 32 bit unsigned integer
serviceChangeMgcId MId OPTIONAL,
timeStamp TimeNotation OPTIONAL,
nonStandardData NonStandardData OPTIONAL,
}
ServiceChangeAddress ::= CHOICE
{
portNumber INTEGER(0..65535), -- TCP/UDP port number
ip4Address IP4Address,
ip6Address IP6Address,
domainName DomainName,
deviceName PathName,
mtpAddress OCTET STRING(SIZE(2)),
...
}
ServiceChangeResParm ::= SEQUENCE
{
serviceChangeMgcId MId OPTIONAL,
serviceChangeAddress ServiceChangeAddress OPTIONAL,
serviceChangeVersion INTEGER(0..99) OPTIONAL,
serviceChangeProfile ServiceChangeProfile OPTIONAL
}
ServiceChangeMethod ::= ENUMERATED
{
failover(0),
forced(1),
graceful(2),
restart(3),
disconnected(4),
handOff(5),
...
}
ServiceChangeProfile ::= SEQUENCE
{
profileName Name,
version INTEGER(0..99)
}
PackagesDescriptor ::= SEQUENCE OF PackagesItem
PackagesItem ::= SEQUENCE
{
packageName Name,
packageVersion INTEGER(0..99)
}
StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter
StatisticsParameter ::= SEQUENCE
{
statName PkgdName,
statValue Value
}
NonStandardData ::= SEQUENCE
{
nonStandardIdentifier NonStandardIdentifier,
data OCTET STRING
}
NonStandardIdentifier ::= CHOICE
{
object OBJECT IDENTIFIER,
h221NonStandard H221NonStandard,
experimental IA5STRING(SIZE(8)),
-- first two characters should be "X-" or "X+"
...
}
H221NonStandard ::= SEQUENCE
{ t35CountryCode INTEGER(0..255), -- country, as per T.35
t35Extension INTEGER(0..255), -- assigned nationally
manufacturerCode INTEGER(0..65535), -- assigned nationally
...
}
TimeNotation ::= SEQUENCE
{
date IA5String(SIZE(8)), -- yyyymmdd format
time IA5String(SIZE(8)) -- hhmmssss format
}
Value ::= OCTET STRING
ENDA.3 Digit maps and path names ✨
okay so bestie, from a syntax point of view, digit maps are just strings with some extra restrictions slapped on 💅. The syntax for valid digit maps is specified in ABNF [RFC 2234]. BUT the grammar in this section is only there for illustration 🙈, so if the definition of digitMap in Annex B doesn't match it, Annex B wins 👑.
digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")"
LWSP)
digitStringList = digitString *( LWSP "/" LWSP digitString )
digitString = 1*(digitStringElement)
digitStringElement = digitPosition [DOT]
digitPosition = digitMapLetter / digitMapRange
digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
digitLetter = *((DIGIT "-" DIGIT) /digitMapLetter)
digitMapLetter = DIGIT ;digits 0-9
/ %x41-4B / %x61-6B ;a-k and A-K
/ "L" / "S" ;Inter-event timers
;(long, short)
/ "Z" ;Long duration event
LWSP = *(WSP / COMMENT / EOL)
WSP = SP / HTAB
COMMENT = ";" *(SafeChar / RestChar / WSP) EOL
EOL = (CR [LF]) / LF
SP = %x20
HTAB = %x09
CR = %x0D
LF = %x0A
SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" /
"'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / "\" /
"(" / ")" / "%" / "."
RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
"<" / ">" / "=" / %x22
DIGIT = %x30-39 ; digits 0 through 9
ALPHA = %x41-5A / %x61-7A ; A-Z, a-zpath names are also strings with syntax rules of their own 🦋. We copied the ABNF production that defines them from Annex B, so here it is:
PathName = NAME *(["/"] ["*"] ["@"] (ALPHA / DIGIT)) ["*"]
NAME = ALPHA *63(ALPHA / DIGIT / "_" )ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE) 🎀
B.1 Coding of wildcards 🌸
okay so in a text encoding of the protocol, TerminationIDs can be pretty much anything 🫶, but if you pick your names wisely, the wildcard character "" becomes way more useful 🔥. When the wildcard shows up, it will "match" every TerminationID that has the same characters before and after it (where that makes sense). For example, if you have TerminationIDs R13/3/1, R13/3/2 and R13/3/3, then R13/3/ catches all three of them 💖.
Sometimes you really do need to talk about ALL Terminations, and that's when the TerminationID "*" does the job. It's called ALL, and it's giving main character energy ✨. Lastly, the CHOOSE TerminationID "$" can be used to signal to the MG that it has to create an ephemeral Termination or pick an idle physical Termination 🧚.
B.2 ABNF specification 🦋
the protocol syntax is written out in ABNF according to RFC2234, so here's the whole grammar, no cap 💅:
megacoMessage = LWSP [authenticationHeader SEP ] message
authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
SequenceNum COLON AuthData
SecurityParmIndex = "0x" 8(HEXDIG)
SequenceNum = "0x" 8(HEXDIG)
AuthData = "0x" 32*64(HEXDIG)
message = MegacopToken SLASH Version SEP mId SEP messageBody
; The version of the protocol defined here is equal to 1.
messageBody = ( errorDescriptor / transactionList )
transactionList = 1*( transactionRequest / transactionReply /
transactionPending / transactionResponseAck )
;Use of response acks is dependent on underlying transport
transactionPending = PendingToken EQUAL TransactionID LBRKT RBRKT
transactionResponseAck = ResponseAckToken LBRKT transactionAck
*(COMMA transactionAck) RBRKT
transactionAck = transactionID / (transactionID "-" transactionID)
transactionRequest = TransToken EQUAL TransactionID LBRKT
actionRequest *(COMMA actionRequest) RBRKT
actionRequest = CtxToken EQUAL ContextID LBRKT ((
contextRequest [COMMA commandRequestList])
/ commandRequestList) RBRKT
contextRequest = ((contextProperties [COMMA contextAudit])
/ contextAudit)
contextProperties = contextProperty *(COMMA contextProperty)
; at-most-once
contextProperty = (topologyDescriptor / priority / EmergencyToken)
contextAudit = ContextAuditToken LBRKT
contextAuditProperties *(COMMA
contextAuditProperties) RBRKT
; at-most-once
contextAuditProperties = ( TopologyToken / EmergencyToken /
PriorityToken )
commandRequestList= ["O-"] commandRequest *(COMMA ["O-"]
commandRequest)
commandRequest = ( ammRequest / subtractRequest / auditRequest
/ notifyRequest / serviceChangeRequest)
transactionReply = ReplyToken EQUAL TransactionID LBRKT
( errorDescriptor / actionReplyList ) RBRKT
actionReplyList = actionReply *(COMMA actionReply )
actionReply = CtxToken EQUAL ContextID LBRKT
( errorDescriptor / commandReply ) RBRKT
commandReply = (( contextProperties [COMMA commandReplyList] )
/ commandReplyList )Okay bestie, this part is all grammar 🎀 Every line is copied exactly as the spec has it, so the ABNF stays 100% accurate 💅
commandReplyList = commandReplys *(COMMA commandReplys )
commandReplys = (serviceChangeReply / auditReply / ammsReply
/ notifyReply )
;Add Move and Modify have the same request parameters
ammRequest = (AddToken / MoveToken / ModifyToken ) EQUAL
TerminationID [LBRKT ammParameter *(COMMA
ammParameter) RBRKT]
;at-most-once
ammParameter = (mediaDescriptor / modemDescriptor /
muxDescriptor / eventsDescriptor /
signalsDescriptor / digitMapDescriptor /
eventBufferDescriptor / auditDescriptor)
ammsReply = (AddToken / MoveToken / ModifyToken /
SubtractToken ) EQUAL TerminationID [ LBRKT
terminationAudit RBRKT ]
subtractRequest = ["W-"] SubtractToken EQUAL TerminationID
[ LBRKT auditDescriptor RBRKT]
auditRequest = ["W-"] (AuditValueToken / AuditCapToken )
EQUAL TerminationID LBRKT auditDescriptor RBRKT
auditReply = (AuditValueToken / AuditCapToken )
( contextTerminationAudit / auditOther)
auditOther = EQUAL TerminationID LBRKT
terminationAudit RBRKT
terminationAudit = auditReturnParameter *(COMMA
auditReturnParameter)
contextTerminationAudit = EQUAL CtxToken ( terminationIDList /
LBRKT errorDescriptor RBRKT )
;at-most-once except errorDescriptor
auditReturnParameter = (mediaDescriptor / modemDescriptor /
muxDescriptor / eventsDescriptor /
signalsDescriptor / digitMapDescriptor /
observedEventsDescriptor / eventBufferDescriptor /
statisticsDescriptor / packagesDescriptor /
errorDescriptor )
auditDescriptor = AuditToken LBRKT [ auditItem
*(COMMA auditItem) ] RBRKT
notifyRequest = NotifyToken EQUAL TerminationID
LBRKT ( observedEventsDescriptor
[ COMMA errorDescriptor ] ) RBRKT
notifyReply = NotifyToken EQUAL TerminationID
[ LBRKT errorDescriptor RBRKT ]
serviceChangeRequest = ServiceChangeToken EQUAL TerminationID
LBRKT serviceChangeDescriptor RBRKT
serviceChangeReply = ServiceChangeToken EQUAL TerminationID
[LBRKT (errorDescriptor /
serviceChangeReplyDescriptor) RBRKT]
errorDescriptor = ErrorToken EQUAL ErrorCode
LBRKT [quotedString] RBRKT
ErrorCode = 1*4(DIGIT) ; could be extended
TransactionID = UINT32
mId = (( domainAddress / domainName )
[":" portNumber]) / mtpAddress / deviceName
; ABNF allows two or more consecutive "." although it is meaningless
; in a domain name.
domainName = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" /
".") ">"
deviceName = pathNAME
ContextID = (UINT32 / "*" / "-" / "$")
domainAddress = "[" (IPv4address / IPv6address) "]"
;RFC2373 contains the definition of IP6Addresses.
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex
V4hex = 1*3(DIGIT) ; "0".."225"
; this production, while occurring in RFC2373, is not referenced
; IPv6prefix = hexpart SLASH 1*2DIGIT
hexpart = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
portNumber = UINT16
; An mtp address is two octets long
mtpAddress = MTPToken LBRKT octetString RBRKT
terminationIDList = LBRKT TerminationID *(COMMA TerminationID)
RBRKT
; Total length of pathNAME must not exceed 64 chars.
pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
["@" pathDomainName ]
; ABNF allows two or more consecutive "." although it is meaningless
; in a path domain name.
pathDomainName = (ALPHA / DIGIT / "*" )
*63(ALPHA / DIGIT / "-" / "*" / ".")
TerminationID = "ROOT" / pathNAME / "$" / "*"
mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm)
RBRKT
; at-most-once per item
; and either streamParm or streamDescriptor but not both
mediaParm = (streamParm / streamDescriptor /
terminationStateDescriptor)
; at-most-once
streamParm = ( localDescriptor / remoteDescriptor /
localControlDescriptor )
streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm
*(COMMA streamParm) RBRKT
localControlDescriptor = LocalControlToken LBRKT localParm
*(COMMA localParm) RBRKT
; at-most-once per item
localParm = ( streamMode / propertyParm /
reservedValueMode
/ reservedGroupMode )
reservedValueMode = ReservedValueToken EQUAL ( "ON" / "OFF" )
reservedGroupMode = ReservedGroupToken EQUAL ( "ON" / "OFF" )
streamMode = ModeToken EQUAL streamModes
streamModes = (SendonlyToken / RecvonlyToken /
SendrecvToken /
InactiveToken / LoopbackToken )
propertyParm = pkgdName parmValue
parmValue = (EQUAL alternativeValue/ INEQUAL VALUE)
alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT
/
LSBRKT VALUE DOT DOT VALUE RSBRKT )
INEQUAL = LWSP (">" / "<" / "#" ) LWSP
LSBRKT = LWSP "[" LWSP
RSBRKT = LWSP "]" LWSP
localDescriptor = LocalToken LBRKT octetString RBRKT
remoteDescriptor = RemoteToken LBRKT octetString RBRKT
eventBufferDescriptor= EventBufferToken LBRKT observedEvent
*( COMMA observedEvent ) RBRKT
eventBufferControl = BufferToken EQUAL ( "OFF" / LockStepToken )
terminationStateDescriptor = TerminationStateToken LBRKT
terminationStateParm *( COMMA terminationStateParm )
RBRKT
; at-most-once per item
terminationStateParm =(propertyParm / serviceStates /
eventBufferControl )
serviceStates = ServiceStatesToken EQUAL ( TestToken /
OutOfSvcToken / InSvcToken )
muxDescriptor = MuxToken EQUAL MuxType terminationIDList
MuxType = ( H221Token / H223Token / H226Token /
V76Token / extensionParameter )
StreamID = UINT16
pkgdName = (PackageName SLASH ItemID) ;specific item
/ (PackageName SLASH "*") ;all events in package
/ ("*" SLASH "*") ; all events supported by the MG
PackageName = NAME
ItemID = NAME
eventsDescriptor = EventsToken EQUAL RequestID LBRKT
requestedEvent *( COMMA requestedEvent ) RBRKT
requestedEvent = pkgdName [ LBRKT eventParameter
*( COMMA eventParameter ) RBRKT ]
; at-most-once each of KeepActiveToken , eventDM and eventStream
;at most one of either embedWithSig or embedNoSig but not both
;KeepActiveToken and embedWithSig must not both be present
eventParameter = ( embedWithSig / embedNoSig / KeepActiveToken
/eventDM / eventStream / eventOther )
embedWithSig = EmbedToken LBRKT signalsDescriptor
[COMMA embedFirst ] RBRKT
embedNoSig = EmbedToken LBRKT embedFirst RBRKT
; at-most-once of each
embedFirst = EventsToken EQUAL RequestID LBRKT
secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT
secondRequestedEvent = pkgdName [ LBRKT secondEventParameter
*( COMMA secondEventParameter ) RBRKT ]
; at-most-once each of embedSig , KeepActiveToken, eventDM or
; eventStream
; KeepActiveToken and embedSig must not both be present
secondEventParameter = ( EmbedSig / KeepActiveToken / eventDM /
eventStream / eventOther )
embedSig = EmbedToken LBRKT signalsDescriptor RBRKT
eventStream = StreamToken EQUAL StreamID
eventOther = eventParameterName parmValue
eventParameterName = NAME
eventDM = DigitMapToken ((EQUAL digitMapName ) /
(LBRKT digitMapValue RBRKT ))
signalsDescriptor = SignalsToken LBRKT [ signalParm
*(COMMA signalParm)] RBRKT
signalParm = signalList / signalRequest
signalRequest = signalName [ LBRKT sigParameter
*(COMMA sigParameter) RBRKT ]
signalList = SignalListToken EQUAL signalListId LBRKT
signalListParm *(COMMA signalListParm) RBRKT
signalListId = UINT16
;exactly once signalType, at most once duration and every signal
;parameter
signalListParm = signalRequest
signalName = pkgdName
;at-most-once sigStream, at-most-once sigSignalType,
;at-most-once sigDuration, every signalParameterName at most once
sigParameter = sigStream / sigSignalType / sigDuration / sigOther
/ notifyCompletion / KeepActiveToken
sigStream = StreamToken EQUAL StreamID
sigOther = sigParameterName parmValue
sigParameterName = NAME
sigSignalType = SignalTypeToken EQUAL signalType
signalType = (OnOffToken / TimeOutToken / BriefToken)
sigDuration = DurationToken EQUAL UINT16
notifyCompletion = NotifyCompletionToken EQUAL ("ON" / "OFF")
observedEventsDescriptor = ObservedEventsToken EQUAL RequestID
LBRKT observedEvent *(COMMA observedEvent) RBRKT
;time per event, because it might be buffered
observedEvent = [ TimeStamp LWSP COLON] LWSP
pkgdName [ LBRKT observedEventParameter
*(COMMA observedEventParameter) RBRKT ]
;at-most-once eventStream, every eventParameterName at most once
observedEventParameter = eventStream / eventOther
RequestID = UINT32
modemDescriptor = ModemToken (( EQUAL modemType) /
(LSBRKT modemType *(COMMA modemType) RSBRKT))
[ LBRKT NAME parmValue
*(COMMA NAME parmValue) RBRKT ]
; at-most-once
modemType = (V32bisToken / V22bisToken / V18Token /
V22Token / V32Token / V34Token / V90Token /
V91Token / SynchISDNToken / extensionParameter)
digitMapDescriptor = DigitMapToken EQUAL digitMapName
( LBRKT digitMapValue RBRKT )
digitMapName = NAME
digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA]
["L" COLON Timer COMMA] digitMap
Timer = 1*2DIGIT
digitMap =
digitString / LWSP "(" LWSP digitStringList LWSP ")" LWSP)That's the whole ABNF chunk for this part 💜 More of the spec is coming, so keep your eyes peeled 👀✨
digitStringList = digitString *( LWSP "|" LWSP digitString )
digitString = 1*(digitStringElement)
digitStringElement = digitPosition [DOT]
digitPosition = digitMapLetter / digitMapRange
digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter)
digitMapLetter = DIGIT ;Basic event symbols
/ %x41-4B / %x61-6B ; a-k, A-K
/ "L" / "S" ;Inter-event timers (long, short)
/ Z" ;Long duration modifier
;at-most-once
auditItem = ( MuxToken / ModemToken / MediaToken /
SignalsToken / EventBufferToken /
DigitMapToken / StatsToken / EventsToken /
ObservedEventsToken / PackagesToken )
serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
*(COMMA serviceChangeParm) RBRKT
serviceChangeParm = (serviceChangeMethod / serviceChangeReason /
serviceChangeDelay / serviceChangeAddress /
serviceChangeProfile / extension / TimeStamp /
serviceChangeMgcId / serviceChangeVersion )
serviceChangeReplyDescriptor = ServicesToken LBRKT
servChgReplyParm *(COMMA servChgReplyParm) RBRKT
;at-most-once. Version is REQUIRED on first ServiceChange response
servChgReplyParm = (serviceChangeAddress / serviceChangeMgcId /
serviceChangeProfile / serviceChangeVersion )
serviceChangeMethod = MethodToken EQUAL (FailoverToken /
ForcedToken / GracefulToken / RestartToken /
DisconnectedToken / HandOffToken /
extensionParameter)
serviceChangeReason = ReasonToken EQUAL VALUE
serviceChangeDelay = DelayToken EQUAL UINT32
serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
serviceChangeMgcId = MgcIdToken EQUAL mId
serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
serviceChangeVersion = VersionToken EQUAL Version
extension = extensionParameter parmValue
packagesDescriptor = PackagesToken LBRKT packagesItem
*(COMMA packagesItem) RBRKT
Version = 1*2(DIGIT)
packagesItem = NAME "-" UINT16
TimeStamp = Date "T" Time ; per ISO 8601:1988
; Date = yyyymmdd
Date = 8(DIGIT)
; Time = hhmmssss
Time = 8(DIGIT)
statisticsDescriptor = StatsToken LBRKT statisticsParameter
*(COMMA statisticsParameter ) RBRKT
;at-most-once per item
statisticsParameter = pkgdName EQUAL VALUE
topologyDescriptor = TopologyToken LBRKT terminationA COMMA
terminationB COMMA topologyDirection RBRKT
terminationA = TerminationID
terminationB = TerminationID
topologyDirection = BothwayToken / IsolateToken / OnewayToken
priority = PriorityToken EQUAL UINT16
extensionParameter = "X" ("-" / "+") 1*6(ALPHA / DIGIT)
; octetString is used to describe SDP defined in RFC2327.
; Caution should be taken if CRLF in RFC2327 is used.
; To be safe, use EOL in this ABNF.
; Whenever "}" appears in SDP, it is escaped by "\", e.g., "\}"
octetString = *(nonEscapeChar)
nonEscapeChar = ( "\}" / %x01-7C / %x7E-FF )
quotedString = DQUOTE 1*(SafeChar / RestChar/ WSP) DQUOTE
UINT16 = 1*5(DIGIT) ; %x0-FFFF
UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF
NAME = ALPHA *63(ALPHA / DIGIT / "_" )
VALUE = quotedString / 1*(SafeChar)
SafeChar = DIGIT / ALPHA / "+" / "-" / "&" /
"!" / "_" / "/" / "'" / "?" / "@" /
"^" / "`" / "~" / "*" / "$" / "\" /
"(" / ")" / "%" / "|" / "."
EQUAL = LWSP %x3D LWSP ; "="
COLON = %x3A ; ":"
LBRKT = LWSP %x7B LWSP ; "{"
RBRKT = LWSP %x7D LWSP ; "}"
COMMA = LWSP %x2C LWSP ; ","
DOT = %x2E ; "."
SLASH = %x2F ; "/"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
DQUOTE = %x22 ; " (Double Quote)
HEXDIG = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" )
SP = %x20 ; space
HTAB = %x09 ; horizontal tab
CR = %x0D ; Carriage return
LF = %x0A ; linefeed
LWSP = *( WSP / COMMENT / EOL )
EOL = (CR [LF] / LF )
WSP = SP / HTAB ; white space
SEP = ( WSP / EOL / COMMENT) LWSP
COMMENT = ";" *(SafeChar/ RestChar / WSP / %x22) EOL
RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#"
/
"<" / ">" / "="
AddToken = ("Add" / "A")
AuditToken = ("Audit" / "AT")
AuditCapToken = ("AuditCapability" / "AC")
AuditValueToken = ("AuditValue" / "AV")
AuthToken = ("Authentication" / "AU")
BothwayToken = ("Bothway" / "BW")
BriefToken = ("Brief" / "BR")
BufferToken = ("Buffer" / "BF")
CtxToken = ("Context" / "C")
ContextAuditToken = ("ContextAudit" / "CA")
DigitMapToken = ("DigitMap" / "DM")
DiscardToken = ("Discard" / "DS")
DisconnectedToken = ("Disconnected" / "DC")
DelayToken = ("Delay" / "DL")
DurationToken = ("Duration" / "DR")
EmbedToken = ("Embed" / "EB")
EmergencyToken = ("Emergency" / "EM")
ErrorToken = ("Error" / "ER")
EventBufferToken = ("EventBuffer" / "EB")
EventsToken = ("Events" / "E")
FailoverToken = ("Failover" / "FL")
ForcedToken = ("Forced" / "FO")
GracefulToken = ("Graceful" / "GR")
H221Token = ("H221" )
H223Token = ("H223" )
H226Token = ("H226" )
HandOffToken = ("HandOff" / "HO")
InactiveToken = ("Inactive" / "IN")
IsolateToken = ("Isolate" / "IS")
InSvcToken = ("InService" / "IV")
KeepActiveToken = ("KeepActive" / "KA")
LocalToken = ("Local" / "L")
LocalControlToken = ("LocalControl" / "O")
LockStepToken = ("LockStep" / "SP")
LoopbackToken = ("Loopback" / "LB")
MediaToken = ("Media" / "M")
MegacopToken = ("MEGACO" / "!")
MethodToken = ("Method" / "MT")
MgcIdToken = ("MgcIdToTry" / "MG")
ModeToken = ("Mode" / "MO")
ModifyToken = ("Modify" / "MF")
ModemToken = ("Modem" / "MD")
MoveToken = ("Move" / "MV")
MTPToken = ("MTP")
MuxToken = ("Mux" / "MX")
NotifyToken = ("Notify" / "N")
NotifyCompletionToken = ("NotifyCompletion" / "NC")
ObservedEventsToken = ("ObservedEvents" / "OE")
OnewayToken = ("Oneway" / "OW")
OnOffToken = ("OnOff" / "OO")
OutOfSvcToken = ("OutOfService" / "OS")
PackagesToken = ("Packages" / "PG")
PendingToken = ("Pending" / "PN")
PriorityToken = ("Priority" / "PR")
ProfileToken = ("Profile" / "PF")
ReasonToken = ("Reason" / "RE")
RecvonlyToken = ("ReceiveOnly" / "RC")
ReplyToken = ("Reply" / "P")
RestartToken = ("Restart" / "RS")
RemoteToken = ("Remote" / "R")
ReservedGroupToken = ("ReservedGroup" / "RG")
ReservedValueToken = ("ReservedValue" / "RV")
SendonlyToken = ("SendOnly" / "SO")
SendrecvToken = ("SendReceive" / "SR")
ServicesToken = ("Services" / "SV")
ServiceStatesToken = ("ServiceStates" / "SI")
ServiceChangeToken = ("ServiceChange" / "SC")
ServiceChangeAddressToken = ("ServiceChangeAddress" / "AD")
SignalListToken = ("SignalList" / "SL")
SignalsToken = ("Signals" / "SG")
SignalTypeToken = ("SignalType" / "SY")
StatsToken = ("Statistics" / "SA")
StreamToken = ("Stream" / "ST")
SubtractToken = ("Subtract" / "S")
SynchISDNToken = ("SynchISDN" / "SN")
TerminationStateToken = ("TerminationState" / "TS")
TestToken = ("Test" / "TE")
TimeOutToken = ("TimeOut" / "TO")
TopologyToken = ("Topology" / "TP")
TransToken = ("Transaction" / "T")
ResponseAckToken = ("TransactionResponseAck"/ "K")
V18Token = ("V18")
V22Token = ("V22")
V22bisToken = ("V22b")
V32Token = ("V32")
V32bisToken = ("V32b")
V34Token = ("V34")
V76Token = ("V76")
V90Token = ("V90")
V91Token = ("V91")ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE) 🎀
okay so 💖 parameters for Local descriptors and Remote descriptors get written as tag-value pairs if binary encoding is used for the protocol 🦋. This annex is basically the lookup list 📋: it has the property names (PropertyID), the tags (Property Tag), the type of each property (Type), and the values (Value).
Values in the Value field that contain references shall be regarded as "information" ✨. The reference holds the normative values. If a value field doesn't have a reference, then the values in that field can be considered as "normative" 💅.
Tags are given as hexadecimal numbers in this annex 🌸. When an MGC sets the value of a property, it may underspecify that value using one of the mechanisms in section 7.1.1 🫶.
For type "enumeration", the value is written as the value in brackets, like Send(0), Receive(1) 🍓.
C.1 General Media Attributes ✨
okay bestie, this is the media stream property table, and it's giving organized chaos 🎀 every row has a PropertyID tag, a property name, a type, and the allowed values. here's the lineup 💅
PropertyID Property Type Value
Tag
Media 1001 Enumeration Audio(0), Video(1),
Data(2),
Transmission mode 1002 Enumeration Send(0), Receive(1),
Send&Receive(2)
Number of Channels 1003 Unsigned 0-255
Integer
Sampling rate 1004 Unsigned 0-2^32
Integer
Bitrate 1005 Integer (0..4294967295)
Note - units of 100 bit/s
ACodec 1006 Octet String Audio Codec Type:
Reference: ITU-T Rec. Q.765 - Application transport mechanism.
Non-ITU codecs are defined with the appropriate standards
organisation under a defined Organizational Identifier.
Samplepp 1007 Unsigned Maximum samples or
Integer frames per packet: 0-
65535
Silencesupp 1008 BOOLEAN Silence Suppression:
True/false
Encrypttype 1009 Octet string Ref.: rec. H.245
Encryptkey 100A Octet string Encryption key
SIZE(0..65535)
Ref.: rec. H.235
Echocanc 100B Enumeration Echo Canceller:
Off(0), G.165(1),
G168(2)
Gain 100C Unsigned Gain in db: 0-65535
Integer
Jitterbuff 100D Unsigned Jitter buffer size in
Integer ms: 0-65535
PropDelay 100E Unsigned Propagation Delay:
Integer 0..65535
Maximum propagation delay in milliseconds for the bearer
connection between two media gateways. The maximum delay will be
dependent on the bearer technology.
RTPpayload 100F integer Payload type in RTP
Profile for Audio and
Video Conferences
with Minimal Control
Ref.: RFC 1890the Bitrate row is in units of 100 bit/s, so keep that in your head when you're reading the numbers 🧠 and PropDelay is the max propagation delay in milliseconds for the bearer connection between two media gateways. it also depends on the bearer technology, so it's not one-size-fits-all 🦋
C.2 Mux Properties 🌸
PropertyID Property Type Value
Tag
H.221 2001 Octet Ref.: rec. H.245,
string H222LogicalChannelParameters
H223 2002 Octet Ref.: rec. H.245,
string H223LogicalChannelParameters
V76 2003 Octet Ref.: rec. H.245,
String V76LogicalChannelParameters
H2250 2004 Octet Ref.: rec. H.245,
String H2250LogicalChannelParametersC.3 General bearer properties 🧚
PropertyID Property Type Value
Tag
Mediatx 3001 Enumeration Media Transport Type:
TDM Circuit(0), ATM(1),
FR(2), Ipv4(3), Ipv6(4),
_
BIR 3002 4 OCTET Value depends on
transport technology
NSAP 3003 1-20 OCTETS See NSAP
Reference: ITU X.213 Annex AC.4 General ATM properties 💜
ATM gets its own big cast of properties, so buckle up 🎢 the names are all over the place (some even repeat, like FCDV and BCDV, so read the PropertyID column, not just the name) 😭
PropertyID Property Type Value
Tag
AESA 4001 20 OCTETS ATM End System Address
VPVC 4002 2 x 16 bit VPC/VCI
integer
SC 4003 4 bits Service Category
Reference: ITU Recommendation Q.2931 (1995)
BCOB 4004 5 bit integer Broadband Bearer Class
Reference: ITU Recommendation Q.2961.2 (06/97)
BBTC 4005 octet Broadband Transfer
Capability
Reference: ITU Recommendation Q.2961 (10/95)
ATC 4006 Enumeration I.371 ATM Traffic
Capability
Reference: ITU Recommendation I.371:
DBR(0), SBR1(1), SBR2(2), SBR(3), ABT/IT(4), ABT/DT(5), ABR(6)
STC 4007 2 bits Susceptibility to
clipping
Reference: ITU Recommendation Q.2931 (1995)
00 Susceptible
01 Not-susceptible
UPCC 4008 2 bits User Plane Connection
configuration:
Reference: ITU Recommendation Q.2931 (1995)
00 Pt-to-pt,
01 Pt-to-mpt
PCR0 4009 24 bit Peak Cell Rate (For
integer CLP=0)
Reference: ITU Recommendation I.371
SCR0 400A 24 bit Sustainable Cell Rate
integer (For CLP=0)
Reference: ITU Recommendation I.371
MBS0 400B 24 bit Maximum Burst Size (For
integer CLP=0)
Reference: ITU Recommendation I.371
PCR1 400C 24 bit Peak Cell Rate (For
integer CLP=0+1)
Reference: ITU Recommendation I.371
SCR2 400D 24 bit Sustainable Cell Rate
integer (For CLP=0+1)
Reference: ITU Recommendation I.371
MBS3 400E 24 bit Maximum Burst Size (For
integer CLP=0+1)
Reference: ITU Recommendation I.371
BEI 400F Boolean Best Effort Indicator
TI 4010 Boolean Tagging
FD 4011 Boolean Frame Discard
FCDV 4012 24 bit Forward P-P CDV
integer
BCDV 4013 24 bit Backward P-P CDV
integer
FCLR0 4014 8 bit integer Forward Cell Loss Ratio
(For CLP=0)
BCLR0 4015 8 bit integer Backward P-P Cell Loss
Ratio (For CLP=0)
FCLR1 4016 8 bit integer Forward Cell Loss Ratio
BCLR1 4017 8 bit integer Backward P-P Cell Loss
Ratio (For CLP=0+1)
FCDV 4018 24 bit Forward Cell Delay
integer Variation
BCDV 4019 24 bit Backward Cell Delay
integer Variation
FACDV 401A 24 bit Forward Acceptable P-P-P
integer CDV
BACDV 401B 24 bit Backward Acceptable P-P
integer CDV
FCCDV 401C 24 bit Forward Cumulative P-P
integer CDV
BCCDV 401D 24 bit Backward Cumulative P-P
integer CDV
FCLR 401E 8 bit integer Acceptable Forward Cell
Loss Ratio
BCLR 401F 8 bit integer Acceptable Backward Cell
Loss Ratio
EETD 4020 16 bit End-to-end transit delay
integer
Mediatx (See 4021 AAL Type
General
Properties)
Reference: ITU Recommendation Q.2931 (1995)
QosClass 4022 Integer 0-4 Qos Class
Reference: ITU Recommendation Q.2931 (1995)
QoS Parameter Application:
Qos Class0 QoS ApplicationBest Effort
Parameter Unspecified
0 Unspecified Best EffortConstant Bit rate
Specified circuit emulation
1 Specified Constant Bit rate circuit
Specified emulationVariable bit rate
video and audio
2 Specified Variable bit rate video and
Specified audioConnection-oriented data
3 Specified Connection-oriented
Specified dataConnectionless data
4 Specified Connectionless data
AALtype 4023 1 OCTET AAL Type
Reference: ITU Recommendation Q.2931 (1995)
00000000 AAL for voice
00000001 AAL type 1
00000010 AAL type 2
00000011 AAL type 3/4
00000101 AAL type 5
00010000 user defined AALC.5 Frame Relay 🍓
PropertyID Property Type Value
Tag
DLCI 5001 Unsigned Integer Data link connection
id
CID 5002 Unsigned Integer sub-channel id.
SID/Noiselevel 5003 Unsigned Integer silence insertion
descriptor
Primary Payload 5004 Unsigned Integer Primary Payload Type
type
Covers FAX and codecsC.6 IP 🫶
the last table is all about IP. the IPv4 and IPv6 rows point at their own RFCs, so those are the references to go check if you want the full picture 👑
PropertyID Property Type Value
Tag
IPv4 6001 32 BITS Ipv4Address:
Ipv4Address
Reference: IETF RFC791
IPv6 6002 128 BITS IPv6 Address:
Reference: IETF RFC2460
Port 6003 unsigned integer 0-65535
Porttype 6004 enumerated TCP(0), UDP(1),
SCTP(2)C.7 ATM AAL2
okay the AAL2 tags are literally so iconic 💖 here's the whole lineup, bestie 🎀
PropertyID Property Type Value
Tag
AESA 7001 20 OCTETS AAL2 service endpoint
address
as defined in Reference: ITU Recommendation Q.2630.1
ESEA
NSEA
BIR See C.3 4 OCTETS Served user generated
reference
as defined in Reference: ITU Recommendation Q.2630.1
SUGR
ALC 7002 12 OCTETS AAL2 link
characteristics
as defined in Reference: ITU Recommendation Q.2630.1
max/average CPS-SDU bitrate,
max/average CPS-SDU size
SSCS 7003 I.366.2: Service
audio (8 OCTETS) specific
multirate (3 OCTETS) convergence
or I.366.1: sublayer
SAR-assured (14 OCTETS)/ information
unassured (7 OCTETS)
as defined in Reference: Q.2630.1 and used in I.366.1 and I.366.2
I.366.2: audio/multirate
I.366.1: SAR-assured/unassured
SUT 7004 1..254 octets Served user transport
parameter
as defined in Reference: ITU Recommendation Q.2630.1
TCI 7005 BOOLEAN Test connection
indicator
as defined in Reference: ITU Recommendation Q.2630.1
Timer_CU 7006 32 bit integer Timer-CU: Milliseconds
to hold partially
filled cell before
sending.
MaxCPSSDU 7007 8 bit integer Maximum Common Part
Sublayer Service Data
Unit
Ref.: rec. Q.2630.1
SCLP 7008 Boolean Set Cell Local
PriorityLP bit:
True if CLP bit is to
be set
EETR 7009 Boolean Timing Requirements
Reference: ITU Recommendation Q.2931 (1995)
End to End Timing Required:
In broadband bearer capability
CID 700A 8 bits subchannel id, 0-255
Ref.: rec. I.363.2 (09/97)C.8 ATM AAL1
next up is AAL1 and it's giving confident energy 🦋
PropertyID Property Type Value
Tag
BIR See GIT (Generic
Table Identifier Transport) 4 OCTETS
C.3
Ref.: Recommendation Q.2941.1 (09/97)
AAL1ST 8001 1 OCTET AAL1 Subtype:
Reference: ITU Recommendation Q.2931 (1995)
00000000 Null
00000001 voiceband signal transport on 64kbit/s
00000010 circuit transport
00000100 high-quality audio signal transport
00000101 video signal transport
CBRR 8002 1 OCTET CBR Rate
Reference: ITU Recommendation Q.2931 (1995)
00000001 64 kbit/s
00000100 1544 kbit/s
00000101 6312 kbit/s
00000110 32064 kbit/s
00000111 44736 kbit/s
00001000 97728 kbit/s
00010000 2048 kbit/s
00010001 8448 kbit/s
00010010 34368 kbit/s
00010011 139264 kbit/s
01000000 n x 64 kbit/s
01000001 n * 8 kbit/s
MULT See Multiplier, or n x
Table 64k/8k/300
C.9
Reference: ITU Recommendation Q.2931 (1995)
SCRI 8003 1 OCTECT Source Clock Frequency
Recovery Method
Reference: ITU Recommendation Q.2931 (1995)
00000000 NULL
00000001 SRTS
00000010 ACM
ECM 8004 1 OCTECT Error Correction
Method
Reference: ITU Recommendation Q.2931 (1995)
00000000 Null
00000001 FEC-LOSS
00000010 FEC-DELAY
SDTB 8005 16 bit integer Structured Data
Transfer Blocksize
Reference: ITU Recommendation I.363.1
Block size of SDT CBR service
PFCI 8006 8 bit integer Partially filled cells
indentifier
Reference: ITU Recommendation I.363.1
1-47
EETR See See Table C.7 See Table C.7
Table
C.7C.9 Bearer Capabilities
and now the big boss 👑 bearer capabilities, so many codes, I'm obsessed 🙈
PropertyID Property Type Value
Tag
TMR 9001 1 OCTET Transmission Medium
Requirement (Q.763)
Reference: ITU Recommendation Q.763(09/97)
Bit 8 7 6 5 4 3 2 1
00000000 - speech
00000001 - spare
00000010 - 64 kbit/s unrestricted
00000011 - 3.1 kHz audio
00000100 - reserved for alternate speech (service 2)/64 kbit/s
unrestricted (service 1)
00000101 - reserved for alternate 64 kbit/s unrestricted (service
1)/speech (service 2)
00000110 - 64 kbit/s preferred
00000111 - 2 x 64 kbit/s unrestricted
00001000 - 384 kbit/s unrestricted
00001001 - 1536 kbit/s unrestricted
00001010 - 1920 kbit/s unrestricted
00001011 through 00001111- spare
00010000 - 3 x 64 kbit/s unrestricted
00010001 - 4 x 64 kbit/s unrestricted
00010010 - 5 x 64 kbit/s unrestricted
00010011 spare
00010100 - 7 x 64 kbit/s unrestricted
00010101 - 8 x 64 kbit/s unrestricted
00010110 - 9 x 64 kbit/s unrestricted
00010111 - 10 x 64 kbit/s unrestricted
00011000 - 11 x 64 kbit/s unrestricted
00011001 - 12 x 64 kbit/s unrestricted
00011010 - 13 x 64 kbit/s unrestricted
00011011 - 14 x 64 kbit/s unrestricted
00011100 - 15 x 64 kbit/s unrestricted
00011101 - 16 x 64 kbit/s unrestricted
00011110 - 17 x 64 kbit/s unrestricted
00011111 - 18 x 64 kbit/s unrestricted
00100000 - 19 x 64 kbit/s unrestricted
00100001 - 20 x 64 kbit/s unrestricted
00100010 - 21 x 64 kbit/s unrestricted
00100011 - 22 x 64 kbit/s unrestricted
00100100 - 23x 64 kbit/s unrestricted
00100101 - spare
00100110 - 25 x 64 kbit/s unrestricted
00100111 - 26 x 64 kbit/s unrestricted
00101000 - 27 x 64 kbit/s unrestricted
00101001 - 28 x 64 kbit/s unrestricted
00101010 - 29 x 64 kbit/s unrestricted
00101011 through 11111111 Spare
TMRSR 9002 1 OCTET Transmission Medium
Requirement Subrate
0 - unspecified
1 - 8kbit/s
2 - 16kbit/s
3 - 32kbit/s
Contcheck 9003 BOOLEAN Continuity Check
Reference: ITU Recommendation Q.763(09/97)
0 - Not required on this circuit
1 - Required on this circuit
ITC 9004 5 BITS Information Transfer
Capability
Reference: ITU Recommendation Q.763(09/97)
Bits 5 4 3 2 1
00000 - Speech
01000 -Unrestricted digital information
01001- Restricted digital information
10000 3.1 kHz audio
10001 - Unrestricted digital information with tones/announcements
(Note 2)
11000 -Video
All other values are reserved.
TransMode 9005 2 BITS Transfer Mode
Reference: ITU Recommendation Q.931 (1998)
Bit 2 1
00 - Circuit mode
10 - Packet mode
TransRate 9006 5 BITS Transfer Rate
Reference: ITU Recommendation Q.931 (1998)
Bit 5 4 3 2 1
00000 - This code shall be used for packet mode calls
10000 - 64 kbit/s
10001 - 2 x 64 kbit/s
10011 -384 kbit/s
10101 -1536 kbit/s
10111 -1920 kbit/s
11000 - Multirate (64 kbit/s base rate)
MULT 9007 7 BITS Rate Multiplier
Reference: ITU Recommendation Q.931 (1998)
Any value from 2 to n (maximum number of B-channels)
USI 9008 5 BITS User Information Layer
1 Protocol
Reference: ITU Recommendation Q.931 (1998)
Bits 5 4 3 2 1
00001 - CCITT standardized rate adaption V.110 and X.30.
00010 - Recommendation G.711 u-law
00011 - Recommendation G.711 A-law
00100 - Recommendation G.721 32 kbit/s ADPCM and Recommendation
I.460.
00101 - Recommendations H.221 and H.242
00110 - Recommendations H.223 and H.245
00111 - Non-ITU-T standardized rate adaption.
01000 - ITU-T standardized rate adaption V.120.
01001 - CCITT standardized rate adaption X.31 HDLC flag stuffing.
All other values are reserved.
syncasync 9009 BOOLEAN Synchronous/
Asynchronous
Reference: ITU Recommendation Q.931 (1998)
0 - Synchronous data
1 - Asynchronous data
negotiation 900A BOOLEAN Negotiation
Reference: ITU Recommendation Q.931 (1998)
0 - In-band negotiation possible
1 - In-band negotiation not possible
Userrate 900B 5 BITS User Rate
Reference: ITU Recommendation Q.931 (1998)
Bits 5 4 3 2 1
00000 - Rate is indicated by E-bits specified in Recommendation
I.460 or may be negotiated in-band
00001 - 0.6 kbit/s Recommendations V.6 and X.1
00010 - 1.2 kbit/s Recommendation V.6
00011 - 2.4 kbit/s Recommendations V.6 and X.1
00100 - 3.6 kbit/s Recommendation V.6
00101 - 4.8 kbit/s Recommendations V.6 and X.1
00110 - 7.2 kbit/s RecommendationV.6
00111 - 8 kbit/s Recommendation I.460
01000 - 9.6 kbit/s Recommendations V.6 and X.1
01001 - 14.4 kbit/s Recommendation V.6
01010 - 16 kbit/s Recommendation I.460
01011 - 19.2 kbit/s Recommendation V.6
01100 - 32 kbit/s Recommendation I.460
01101 - 38.4 kbit/s Recommendation V.110
01110 - 48 kbit/s Recommendations V.6 and X.1
01111 - 56 kbit/s Recommendation V.6
10010 - 57.6 kbit/s Recommendation V.14 extended
10011 - 28.8 kbit/s Recommendation V.110
10100 - 24 kbit/s Recommendation V.110
10101 - 0.1345 kbit/s Recommendation X.1
10110 - 0.100 kbit/s Recommendation X.1
10111 - 0.075/1.2 kbit/s Recommendations V.6 and X.1
11000 - 1.2/0.075 kbit/s Recommendations V.6 and X.1
11001 - 0.050 kbit/s Recommendations V.6 and X.1
11010 - 0.075 kbit/s Recommendations V.6 and X.1
11011 - 0.110 kbit/s Recommendations V.6 and X.1
11100 - 0.150 kbit/s Recommendations V.6 and X.1
11101 - 0.200 kbit/s Recommendations V.6 and X.1
11110 - 0.300 kbit/s Recommendations V.6 and X.1
11111 - 12 kbit/s Recommendation V.6
All other values are reserved.
INTRATE 900C 2 BITS Intermediate Rate
Reference: ITU Recommendation Q.931 (1998)
Bit 2 1
00 - Not used
01 - 8 kbit/s
10 - 16 kbit/s
11 - 32 kbit/sokay so the bearer capability list keeps going and it's still giving main character energy 💅🎀
nictx 900D BOOLEAN Network Independent
Clock (NIC) on
transmission
Reference: ITU Recommendation Q.931 (1998)
0 - Not required to send data with network independent clock
1 - Required to send data with network independent clock
nicrx 900E BOOLEAN Network independent
clock (NIC) on
reception
Reference: ITU Recommendation Q.931 (1998)
0 - Cannot accept data with network independent clock (i.e.
sender does not support this optional procedure)
1 - Can accept data with network independent clock (i.e. sender
does support this optional procedure)
flowconttx 900F BOOLEAN Flow Control on
transmission (Tx)
Reference: ITU Recommendation Q.931 (1998)
0 - Not required to send data with flow control mechanism
1 - Required to send data with flow control mechanism
flowcontrx 9010 BOOLEAN Flow control on
reception (Rx)
Reference: ITU Recommendation Q.931 (1998)
0 - Cannot accept data with flow control mechanism (i.e. sender
does not support this optional procedure)
1 - Can accept data with flow control mechanism (i.e. sender does
support this optional procedure)
rateadapthdr 9011 BOOLEAN Rate adaption
header/no header
Reference: ITU Recommendation Q.931 (1998)
0 - Rate adaption header not included
1 - Rate adaption header included
multiframe 9012 BOOLEAN Multiple frame
establishment support
in data link
Reference: ITU Recommendation Q.931 (1998)
0 - Multiple frame establishment not supported. Only UI frames
allowed.
1 - Multiple frame establishment supported
OPMODE 9013 BOOLEAN Mode of operation
Reference: ITU Recommendation Q.931 (1998)
0 Bit transparent mode of operation
1 Protocol sensitive mode of operation
llidnegot 9014 BOOLEAN Logical link
identifier negotiation
Reference: ITU Recommendation Q.931 (1998)
0 Default, LLI = 256 only
1 Full protocol negotiation
assign 9015 BOOLEAN Assignor/assignee
Reference: ITU Recommendation Q.931 (1998)
0 Message originator is "Default assignee"
1 Message originator is "Assignor only"
inbandneg 9016 BOOLEAN In-band/out-band
negotiation
Reference: ITU Recommendation Q.931 (1998)
0- Negotiation is done with USER INFORMATION messages on a
temporary signalling connection
1- Negotiation is done in-band using logical link zero
stopbits 9017 2 BITS Number of stop bits
Reference: ITU Recommendation Q.931 (1998)
Bits 2 1
00 - Not used
01 - 1 bit
10 - 1.5 bits
11 - 2 bits
databits 9018 2 BIT Number of data bits
excluding parity Bit
if present
Reference: ITU Recommendation Q.931 (1998)
Bit 2 1
00 - Not used
01 - 5 bits
10 - 7 bits
11 - 8 bits
parity 9019 3 BIT Parity information
Reference: ITU Recommendation Q.931 (1998)
Bit 3 2 1
000 - Odd
010 - Even
011 -None
100 - Forced to 0
101 - Forced to 1
All other values are reserved.
duplexmode 901A BOOLEAN Mode duplex
Reference: ITU Recommendation Q.931 (1998)
0 - Half duplex
1 - Full duplex
modem 901B 6 BIT Modem Type
Reference: ITU Recommendation Q.931 (1998)
Bits 6 5 4 3 2 1
00000 through 000101 National Use
010001 - Recommendation V.21
010010 - Recommendation V.22
010011 - Recommendation V.22 bis
010100 - Recommendation V.23
010101 - Recommendation V.26
011001 - Recommendation V.26 bis
010111 -Recommendation V.26 ter
011000 - RecommendationV.27
011001 - Recommendation V.27 bis
011010 - Recommendation V.27 ter
011011 - Recommendation V.29
011101 - Recommendation V.32
011110 - Recommendation V.34
100000 through 101111 National Use
110000 through 111111 User Specified
layer2prot 901C 5 BIT User information layer
2 protocol
Reference: ITU Recommendation Q.931 (1998)
Bit 5 4 3 2 1
00010 - Recommendation Q.921/I.441 [3]
00110 - Recommendation X.25 [5], link layer
01100 - LAN logical link control (ISO/IEC 8802-2)
All other values are reserved.
layer3prot 901D 5 BIT User information layer
3 protocol
Reference: ITU Recommendation Q.931 (1998)
Bit 5 4 3 2 1
00010 - Recommendation Q.931/I.451
00110 - Recommendation X.25, packet layer
01011 - ISO/IEC TR 9577 (Protocol identification in the network
layer)
All other values are reserved.
addlayer3prot 901E OCTET Additional User
Information layer 3
protocol
Reference: ITU Recommendation Q.931 (1998)
Bits 4321 4321
1100 1100 - Internet Protocol (RFC 791) (ISO/IEC TR 9577)
1100 1111 - Point-to-point Protocol (RFC 1548)
DialledN 901F 30 OCTETS Dialled Number
DiallingN 9020 30 OCTETS Dialling Number
ECHOCI 9021 Enumeration Echo Control
Information
echo canceler off (0), incoming echo canceler on (1), outgoing
echo canceler on (2), incoming and outgoing echo canceler on (3)
NCI 9022 1 OCTET Nature of Connection
Indicators
Reference: ITU Recommendation Q.763
Bits 8 7 6 5 4 3 2 1
Bits 2 1 Satellite Indicator
0 0 no satellite circuit in the connection
0 1 one satellite circuit in the connection
1 0 two satellite circuits in the connection
1 1 spare
Bits 4 3 Continuity check indicator
0 0 continuity check not required
0 1 continuity check required on this circuit
1 0 continuity check performed on a previous circuit
1 1 spare
Bits 5 Echo control device indicator
0 outgoing echo control device not included
1 outgoing echo control device included
Bits 8 7 6 SpareANNEX D TRANSPORT OVER IP (NORMATIVE) 🌈
C.10 AAL5 Properties ⭐
Next up is the AAL5 crew, and the SSCS and SC rows just point back to earlier tables, which is so very organised of them 🙈
PropertyID Property Type Value
Tag
FMSDU A001 32 bit integer Forward Maximum CPCS-
SDU Size:
Reference: ITU Recommendation Q.2931 (1995)
Maximum CPCS-SDU size sent in the direction from the calling user
to the called user.
BMSDU A002 32 bit integer Backwards Maximum
CPCS-SDU Size
Reference: ITU Recommendation Q.2931 (1995)
Maximum CPCS-SDU size sent in the direction from the called user
to the calling user.
SSCS See See table C.7 See table C.7
table
C.7
Additional values:
VPI/VCI
SC See See Table C.4 See table C.4
Table
C.4C.11 SDP Equivalents 💜
Now the SDP lookalikes, one tag for each SDP line, all in a row 🦋
PropertyID Property Type Value
Tag
SDP_V B001 STRING Protocol Version
SDP_O B002 STRING Owner/creator and
session ID
SDP_S B003 STRING Sesson name
SDP_I B004 STRING Session identifier
SDP_U B005 STRING URI of descriptor
SDC_E B006 STRING email address
SDP_P B007 STRING phone number
SDP_C B008 STRING Connection information
SDP_B B009 STRING Bandwidth Information
SDP_Z B00A STRING time zone adjustment
SDP_K B00B STRING Encryption Key
SDP_A B00C STRING Zero or more session
attributes
SDP_T B00D STRING Active Session Time
SDP_R B00E STRING Zero or more repeat
times
Reference in all cases: IETF RFC2327, "Session Description
Protocol"C.12 H.245 🍓
The last stop on the property tour is H.245, and each of these tags carries one of its structures 🧚
PropertyID Property Type Value
Tag
OLC C001 octet string The value of H.245
OpenLogicalChannel
structure.
OLCack C002 octet string The value of H.245
OpenLogicalChannelAck
structure.
OLCcnf C003 octet string The value of H.245
OpenLogicalChannelConfirm
structure.
OLCrej C004 octet string The value of H.245
OpenLogicalChannelReject
structure.
CLC C005 octet string The value of H.245
CloseLogicalChannel
structure.
CLCack C006 octet string The value of H.245
CloseLogicalChannelAck
structure.
Reference in all cases: ITU-T Recommendation H.245D.1 Transport over IP/UDP using Application Level Framing 🦋
Okay so this is where the transport bit gets real. Protocol messages from this document can be sent over UDP, and if the peer hasn't given you a port (that's covered in section 7.2.8), commands should go to the default port. That's 2944 for text-encoded operation or 2945 for binary-encoded operation 💖 Responses must go back to the address and port the commands came from, except when the response is to a handoff or failover. In that case, the procedures of 11.5 apply, so read that part too, bestie 📖
Implementors using IP/UDP with ALF should be aware of the restrictions of the MTU on the maximum message size. 🙈
D.1.1 Providing At-Most-Once Functionality ✨
okay so messages get carried over UDP, which means they can just... get lost 😭 If there's no timely response, commands get repeated. The problem is most commands aren't idempotent, so the MG's state would go totally unpredictable if, say, Add commands ran several times. The transmission procedures shall thus provide an "At-Most-Once" functionality, so nothing runs twice 💅
Peer protocol entities are expected to keep in memory a list of the responses they sent to recent transactions, plus a list of the transactions that are currently outstanding. When an incoming message comes in, its transaction identifier gets compared to the transaction identifiers of the recent responses sent to the same MId. If it matches, the entity doesn't execute the transaction, it just repeats the response 🔁 If there's no match, the message gets compared to the outstanding list. If it matches something in there, that's a duplicate transaction, so again the entity doesn't execute it (see section 8.2.3 for procedures on sending TransactionPending) 🫶
The procedure uses a long timer value, noted LONG-TIMER in the following. The timer should be set larger than the maximum duration of a transaction, which should take into account the maximum number of repetitions, the maximum value of the repetition timer and the maximum propagation delay of a packet in the network. A suggested value is 30 seconds ⏰
The copy of the responses may be destroyed either LONG-TIMER seconds after the response is issued, or when the entity receives a confirmation that the response has been received, through the "Response Acknowledgement parameter". For transactions acknowledged through this parameter, the entity shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued. That's so it can detect and ignore duplicate copies of the transaction request that the network might've produced 🕵️♀️✨
D.1.2 Transaction identifiers and three-way handshake 🦋
D.1.2.1 Transaction identifiers
Okay, transaction identifiers are 32 bit integer numbers 🔢 A Media Gateway Controller may decide to use a specific number space for each of the MGs it manages, or use the same number space for all MGs that belong to some arbitrary group. MGCs may also decide to share the load of managing a large MG between several independent processes. Those processes will share the same transaction number space. There are multiple possible ways to do this sharing, like a centralized allocation of transaction identifiers, or pre-allocating non-overlapping ranges of identifiers to different processes. Whatever the implementation, it shall guarantee that unique transaction identifiers are allocated to all transactions that originate from a logical MGC (identical mId). MGs can detect duplicate transactions just by looking at the transaction identifier and mId, no extra work needed 🌸
D.1.2.2 Three-way handshake
The TransactionResponse Acknowledgement parameter can be found in any message 📬 It carries a set of "confirmed transaction-id ranges". Entities may choose to delete the copies of the responses to transactions whose id is included in those "confirmed transaction-id ranges" received in transaction response messages. They should silently discard further commands when the transaction-id falls within these ranges 🤫
The "confirmed transaction-id ranges" values shall not be used if more than LONG-TIMER seconds have elapsed since the MG issued its last response to that MGC, or when a MG resumes operation. In that situation, transactions should be accepted and processed without any test on the transaction-id. Fresh start, no drama 🌈
Messages that carry the Transaction Response Acknowledgement parameter may be transmitted in any order 🔀 The entity shall retain the "confirmed transaction-id ranges" received for LONG-TIMER seconds.
Here's how the binary encoding handles it: if only the firstAck is present in a response acknowledgement (see Annex A.2), then only one transaction is acknowledged. If both firstAck and lastAck are present, the range of transactions from firstAck to lastAck is acknowledged. In the text encoding, a horizontal dash is used to indicate a range of transactions being acknowledged (see Annex B.2) ➖💖
D.1.3 Computing retransmission timers ⏱️
It's the responsibility of the requesting entity to provide suitable time outs for all outstanding transactions, and to retry transactions when time outs have been exceeded. And when repeated transactions fail to be acknowledged, the requesting entity is responsible for seeking redundant services and/or clearing existing or pending connections 🙈
The specification purposely avoids specifying any value for the retransmission timers, because those values are typically network dependent 🌐 The retransmission timers should normally estimate the timer value by measuring the time spent between sending a command and getting back a response.
Note - One possibility is to use the algorithm implemented in TCP-IP, which uses two variables:
- The average acknowledgement delay, AAD, estimated through an exponentially smoothed average of the observed delays.
- The average deviation, ADEV, estimated through an exponentially smoothed average of the absolute value of the difference between the observed delay and the current average. In TCP, the retransmission timer is set to the sum of the average delay plus N times the average deviation. For this protocol, though, the maximum value of the timer should be bounded, so that no repeated packet gets received by the gateways after LONG-TIMER seconds. A suggested maximum value is 4 seconds.
After any retransmission, the entity should do the following:
- It should double the estimated value of the average delay, AAD.
- It should compute a random value, uniformly distributed between 0.5 AAD and AAD.
- It should set the retransmission timer to the sum of that random value and N times the average deviation.
This procedure has two effects 💫 Because it includes an exponentially increasing component, it automatically slows down the stream of messages when there's congestion. Because it includes a random component, it breaks the potential synchronization between notifications triggered by the same external event. Genius, honestly 👑
D.1.4 Provisional responses ⏳
Some transactions take a long time to execute 🐢 Long execution times can mess with the timer based retransmission procedure. That can result either in an inordinate number of retransmissions, or in timer values that get too long to be efficient. So entities that can predict a transaction will need a long execution time may send a provisional response, "Transaction Pending" 🧚
Entities that receive a Transaction Pending shall switch to a different repetition timer for repeating requests. The root termination has a property (ProvisionalResponseTimerValue), which can be set to the requested maximum number of milliseconds between receipt of a command and transmission of the TransactionPending response. When a final response comes in, an immediate confirmation shall be sent, and normal repetition timers shall be used from then on. A Transaction Pending received after a reply has already come in shall be ignored 🙅♀️
D.1.5 Repeating Requests, Responses and Acknowledgements 🔁
The protocol is organized as a set of transactions, each one made up of a request and a response, which is commonly referred to as an acknowledgement 🎀 Protocol messages get carried over UDP, so they may be subject to losses. If there's no timely response, transactions are repeated. Entities are expected to keep in memory a list of the responses they sent to recent transactions, i.e. a list of all the responses they sent over the last LONG-TIMER seconds, and a list of the transactions that are currently being executed.
The repetition mechanism guards against three types of possible errors:
- transmission errors, when for example a packet is lost due to noise on a line or congestion in a queue;
- component failure, when for example an interface to an entity becomes unavailable;
- entity failure, when for example an entire entity becomes unavailable.
Entities should be able to work out from past history an estimate of the packet loss rate due to transmission errors. In a properly configured system, this loss rate should be kept very low, typically less than 1% 📉 If a Media Gateway Controller or a Media Gateway has to repeat a message more than a few times, it's very legitimate to assume that something other than a transmission error is happening 🚨 For example, given a loss rate of 1%, the probability that five consecutive transmission attempts fail is 1 in 100 billion. That's an event that should occur less than once every 10 days for a Media Gateway Controller processing 1 000 transactions per second. (Indeed, the number of repetitions considered excessive should be a function of the prevailing packet loss rate.) We should note that the "suspicion threshold", which we will call "Max1", is normally lower than the "disconnection threshold", which should be set to a larger value 🧐
A classic retransmission algorithm would simply count the number of successive repetitions, and conclude the association is broken after retransmitting the packet an excessive number of times (typically between 7 and 11 times). To account for the possibility of an undetected or in-progress "failover", this document modifies the classic algorithm. If the Media Gateway receives a valid ServiceChange message announcing a failover, it will start transmitting outstanding commands to that new MGC. Responses to commands are still transmitted to the source address of the command 🎯
To automatically adapt to network load, this document specifies exponentially increasing timers. If the initial timer is set to 200 milliseconds, the loss of a fifth retransmission will be detected after about 6 seconds. That's probably an acceptable waiting delay to detect a failover 😌 The repetitions should continue after that delay, not only to perhaps overcome a transient connectivity problem, but also to allow more time for the execution of a failover. Waiting a total delay of 30 seconds is probably acceptable ⌛
It's important that the maximum delay of retransmissions be bounded. Before any retransmission, it's checked that the time elapsed since sending the initial datagram is no greater than T-MAX. If more than T-MAX time has elapsed, the MG concludes the MGC has failed, and begins its recovery process. When the MG establishes a new control association, it can retransmit to the new MGC. Alternatively, an MG may use a ServiceChange with ServiceChangeMethod equal to disconnected to inform the new MGC that the MG lost one or more transactions 💌 The value T-MAX is related to the LONG-TIMER value: the LONG-TIMER value is obtained by adding the maximum propagation delay in the network to T-MAX ✨
D.2 using TCP 🦋
okay so protocol messages from this doc can totally ride over TCP, bestie 🫶 If the other side doesn't tell you a port (see section 7.2.8), the commands should go to the default port. The protocol thinks in messages, but TCP is a stream, so TPKT, according to RFC1006 SHALL be used to mark where each message starts and ends in the stream ✨
even with a transaction-oriented protocol, requests or replies can still get lost 💀 so it's recommended that entities using TCP transport set up application level timers for each request and each response, kinda like the ones for application level framing over UDP 🌸
D.2.1 Providing the At-Most-Once functionality 💅
TCP means messages don't get lost in transit, but a lost request or reply can still happen in real life 😭 If there's no timely response, commands get repeated. Most commands are not idempotent, and that's the tea ☕ The state of the MG would go totally unpredictable if, for example, Add commands ran several times.
to guard against that, it is recommended that entities follow the procedures in section D.1.1 🔥
D.2.2 Transaction identifiers and three way handshake 🎀
same vibes as before: even with a reliable protocol like TCP, transaction replies can still vanish 🙈 so it is recommended that entities follow the procedures in section D.1.2.2 💖
D.2.3 Computing retransmission timers ⏱️
with reliable delivery, losing a transaction request or reply is expected to be super rare 🌈 so simple timers are enough, and exponential back-off algorithms should not be necessary. They could still be used where the code is already there, like in an MGC, since MGCs must implement ALF/UDP as well as TCP 🧚
D.2.4 Provisional responses 🍓
same as UDP, some transactions just take a long time ⏳ Entities that can predict a long execution time may send a provisional response, "Transaction Pending". They should send it if they get a repeat of a transaction that's still running ✨
entities that receive a Transaction Pending shall switch to a longer repetition timer for that transaction. No cap, that's the move 💜
entities shall retain transactions and replies until they're confirmed. The basic procedure from section D.1.4 should be followed, but simple timer values should be enough. There's no need to send an immediate confirmation when a final response shows up 🫶
D.2.5 Ordering of commands 👑
TCP gives you ordered delivery of transactions, so no special procedures are required 🦋 It's worth noting that ALF/UDP lets the sending entity change its behavior under congestion, and it could reorder transactions when congestion shows up. TCP just can't pull off that same trick 💀
ANNEX E BASIC PACKAGES ✨
this annex has definitions for some packages you can use with the Megaco protocol 🎀
E.1 Generic 💖
PackageID: g (0x000e)
Version: 1
Extends: None
Description: Generic package for commonly encountered items.E.1.1 Properties 🌸
None 🙈
E.1.2 Events 🦋
Cause
-----
EventID: cause (0x0001)
Generic error event
ObservedEvents Descriptor Parameters:
General Cause
-------------
ParameterID: Generalcause (0x0001)
Description: This parameter groups the failures into six
groups, which the MGC may act upon.
Possible values: Enumerated,
"NR" Normal Release (0x0001)
"UR" Unavailable Resources (0x0002)
"FT" Failure, Temporary (0x0003)
"FP" Failure, Permanent (0x0004)
"IW" Interworking Error (0x0005)
"UN" Unsupported (0x0006)
Failure Cause
-------------
ParameterID: Failurecause (0x0002)
Description: The Release Cause is the value generated by the
Released equipment, i.e. a released network connection.
The concerned value is defined in the appropriate bearer
control protocol.
Possible Values: OCTET STRING
Signal Completion
-----------------
EventID: sc (0x0002)
Indicates termination of one or more signals for which the
notifyCompletion parameter was set to "ON". For further procedural
description, see sections 7.1.11, 7.1.17, and 7.2.7.
ObservedEvents Descriptor parameters:
Signal Identity
---------------
ParameterID: SigID (0x0001)
This parameter identifies the signals which have terminated.
Type: list
Possible values: a list of signals and/or sequential signal
lists which have terminated. A signal outside of a sequential
signal list shall be identified using the pkgdName syntax
without wildcarding. An individual signal inside of a
sequential signal list shall be identified using the sequential
signal list syntax with the correct signal list identifier,
enclosing the name of the specific signal which terminated in
pkgdName syntax.
Termination Method
------------------
ParameterID: Meth (0x0002)
Indicates the means by which the signal terminated.
Type: enumeration
Possible values:
"TO" (0x0001) Duration expired
"EV" (0x0002) Interrupted by event
"SD" (0x0003) Halted by new Signals Descriptor
"NC" (0x0004) Not completed, other causeE.1.3 Signals ✨
None 💅
E.1.4 Statistics 🧚
None 🫶
E.2 Base Root Package 👑
Base Root Package
PackageID: root (0x000f)
Version: 1
Extends: None
Description: This package defines Gateway wide properties.E.2.1 Properties 🔥
MaxNrOfContexts
---------------
PropertyID: maxNumberOfContexts (0x0001)
The value of this property gives the maximum number of contexts that
can exist at any time. The NULL context is not included in this
number.
Type: Double
Possible values: 1 and up
MaxTerminationsPerContext
-------------------------
PropertyID: maxTerminationsPerContext (0x0002)
The maximum number of allowed terminations in a context, see section
6.1
Type: Integer
Possible Values: any integer
Defined In: TerminationState
normalMGExecutionTime
---------------------
PropertyId: normalMGExecutionTime (0x0003)
Settable by the MGC to indicate the interval within which the MGC
expects a response to any transaction from the MG (exclusive of
network delay)
Type: Integer
Possible Values: any integer, represents milliseconds
normalMGCExecutionTime
----------------------
PropertyId: normalMGCExecutionTime (0x0004)
Settable by the MGC to indicate the interval within which the MG
should expects a response to any transaction from the MGC (exclusive
of network delay)
Type: Integer
Possible Values: any integer, represents milliseconds
ProvisionalResponseTimerValue
-----------------------------
PropertyId: ProvisionalResponseTimerValue (0x0005)
Indicates the time within which to expect a Pending Response if a
Transaction cannot be completed. Initially set to
normalMGExecutionTime or normalMGCExecutionTime as appropriate, plus
network delay, but may be lowered.E.2.2 Events 🌈
None ✨
E.2.3 Signals 💜
None 🦋
E.2.4 Statistics 🍓
None 💖
E.2.5 Procedures 🎀
None 🫶
E.3 Tone Generator Package 🔊
PackageID: tonegen (0x0001)
Version: 1
Extends: None
Description:
This package defines signals to generate audio tones. This package
does not specify parameter values. It is intended to be extendable.
Generally, tones are defined as an individual signal with a
parameter, ind, representing "interdigit" time delay, and a tone id
to be used with playtones. A tone id should be kept consistent with
any tone generation for the same tone. MGs are expected to be
provisioned with the characteristics of appropriate tones for the
country in which the MG is located.E.3.1 Properties 🌸
None 💅
E.3.2 Events ✨
None 🧚
E.3.3 Signals 🔥
Play tone
---------
SignalID: pt (0x0001)
Plays audio tone over an audio channel
Signal Type: Brief
Duration: Provisioned
Additional Parameters:
Tone id list
------------
ParameterID: tl (0x0001)
Type: list of tone ids.
List of tones to be played in sequence. The list SHALL contain
one or more tone ids.
Inter signal duration
---------------------
ParameterID: ind (0x0002)
Type: integer.
Timeout between two consecutive tones in millisecondsno tone ids are specified in this package, so packages that extend it can add possible values for tone id and add their own individual tone signals 🎀
E.3.4 Statistics 🦋
None 🫶
E.3.5 Procedures 💖
None 💜
E.4 Tone Detection Package 🎧
PackageID: tonedet (0x0002)
Version: 1
Extends: Nonethis package defines events for audio tone detection 👂 Tones are picked by name (tone id), and MGs are expected to be provisioned with the characteristics of appropriate tones for the country where the MG is located 🌍 It doesn't specify parameter values and is meant to be extendable, so it's giving flexibility 💅
E.4.1 Properties 🌈
None ✨
E.4.2 Events ✨
okay bestie, let's get into the events 🎧
Start tone detected 🔥 EventID: std, 0x0001
This one catches the start of a tone. What positive tone detection actually looks like is implementation dependent, so that part is up to the implementer 🤷♀️
EventsDescriptor parameters:
- Tone id list 💖
ParameterID: tl (0x0001)- Type: list of tone ids
- Possible values: the only tone id defined in this package is "wild card", which is "*" in text encoding and 0x0000 in binary. Extensions to this package would add possible values for tone id. If tl is "wild card", any tone id is detected 🌈
ObservedEventsDescriptor parameters:
- Tone id 🎀
ParameterID: tid (0x0003)- Type: Enumeration
- Possible values: "wildcard" as defined above is the only value defined in this package. Extensions to this package would add additional possible values for tone id.
End tone detected 🦋 EventID: etd, 0x0002
This one catches the end of a tone 🛑
EventDescriptor parameters:
- Tone id list 🌸
ParameterID: tl (0x0001)- Type: enumeration or list of enumerated types
- Possible values: no possible values are specified in this package. Extensions to this package would add possible values for tone id.
ObservedEventsDescriptor parameters:
- Tone id 💜
ParameterID: tid (0x0003)- Type: Enumeration
- Possible values: "wildcard" as defined above is the only value defined in this package. Extensions to this package would add possible values for tone id
- Duration ⏱️
ParameterId: dur (0x0002)- Type: integer, in milliseconds
- This parameter contains the duration of the tone from first detection until it stopped. It's giving stopwatch energy 💅
Long tone detected 🧚 EventID: ltd, 0x0003
Detects that a tone has been playing for at least a certain amount of time. Main character energy, no cap 👑
EventDescriptor parameters:
- Tone id list 🍓
ParameterID: tl (0x0001)- Type: enumeration or list
- Possible values: "wildcard" as defined above is the only value defined in this package. Extensions to this package would add possible values for tone id
- Duration: ⏳
ParameterID: dur (0x0002)- Type: integer, duration to test against
- Possible values: any legal integer, expressed in milliseconds.
ObservedEventsDescriptor parameters:
- Tone id 🫶
ParameterID: tid (0x0003)- Possible values: no possible values are specified in this package. Extensions to this package would add possible values for tone id.
E.4.3 Signals
None
E.4.4 Statistics
None
E.4.5 Procedures
None
E.5 Basic DTMF Generator Package 📞
PackageID: dg (0x0003) Version: 1 Extends: tonegen version 1
This package defines the basic DTMF tones as signals and extends the allowed values of parameter tl of playtone in tonegen. Tones, but make them iconic 🎀
E.5.1 Properties
None
E.5.2 Events
None
E.5.3 Signals
dtmf character 0 💖 SignalID: d0 (0x0010)
Generate DTMF 0 tone. The physical characteristic of DTMF 0 is defined in the gateway.
Signal Type: Brief
Duration: Provisioned
Additional Parameters:
None
Additional Values ✨
d0 (0x0010) is defined as a toneid for playtone.
The other dtmf characters are specified in exactly the same way. A table with all signal names and signal IDs is included. Note that each dtmf character is defined as both a signal and a toneid, thus extending the basic tone generation package. Also note that dtmf SignalIds are different from the names used in a digit map. Not the same name, bestie, don't mix them up 🙈
Signal Name Signal ID/tone id
dtmf character 0 d0 (0x0010)
dtmf character 1 d1 (0x0011)
dtmf character 2 d2 (0x0012)
dtmf character 3 d3 (0x0013)
dtmf character 4 d4 (0x0014)
dtmf character 5 d5 (0x0015)
dtmf character 6 d6 (0x0016)
dtmf character 7 d7 (0x0017)
dtmf character 8 d8 (0x0018)
dtmf character 9 d9 (0x0019)
dtmf character * ds (0x0020)
dtmf character # do (0x0021)
dtmf character A da (0x001a)
dtmf character B db (0x001b)
dtmf character C dc (0x001c)
dtmf character D dd (0x001d)E.5.4 Statistics
None
E.5.5 Procedures
None
E.6 DTMF detection Package 🔍
PackageID: dd (0x0004) Version: 1 Extends: tonedet version 1
This package defines the basic DTMF tones detection. This Package extends the possible values of tone id in the "start tone detected" "end tone detected" and "long tone detected" events.
Additional tone id values are all tone ids described in package dg (basic DTMF generator package). So if you know dg, you already know this one 🫶
The following table maps DTMF events to digit map symbols as described in section 7.1.14.
DTMF Event Symbol
d0 "0"
d1 "1"
d2 "2"
d3 "3"
d4 "4"
d5 "5"
d6 "6"
d7 "7"
d8 "8"
d9 "9"
da "A" or "a"
db "B" or "b"
dc "C" or "c"
dd "D" or "d"
ds "E" or "e"
do "F" or "f"E.6.1 Properties
None
E.6.2 Events
DTMF digits 🎹
EventIds are defined with the same names as the SignalIds defined in the table found in section E.5.3.
DigitMap Completion Event 🌟 EventID: ce, 0x0001
Generated when a digit map completes as described in section 7.1.14.
EventsDescriptor parameters: digit map processing is activated only if a digit map parameter is present, specifying a digit map by name or by value. Other parameters such as a KeepActive flag or embedded Events or Signals Descriptors may be present.
ObservedEventsDescriptor parameters:
- DigitString 💅
ParameterID: ds (0x0001)- Type: string of digit map symbols (possibly empty) returned as a quotedString.
- Possible values: a sequence of the characters "0" through "9", "A" through "F", and the long duration modifier "L".
- Description: the portion of the current dial string as described in section 7.1.14 which matched part or all of an alternative event sequence specified in the digit map.
- Termination Method 🚦
ParameterID: Meth (0x0003)- Type: enumeration
- Possible values:
- "UM" (0x0001) Unambiguous match
- "PM" (0x0002) Partial match, completion by timer expiry or unmatched event
- "FM" (0x0003) Full match, completion by timer expiry or unmatched event
- Description: indicates the reason for generation of the event. See the procedures in section 7.1.14.
E.6.3 Signals
None
E.6.4 Statistics
None
E.6.5 Procedures
None
E.7 Call Progress Tones Generator Package 📡
PackageID: cg, 0x0005 Version: 1 Extends: tonegen version 1
This package defines the basic call progress tones as signals and extends the allowed values of the tl parameter of playtone in tonegen.
E.7.1 Properties
None
E.7.2 Events
None
E.7.3 Signals
Dial Tone ☎️ SignaID: dt (0x0030)
Generate dial tone. The physical characteristic of dial tone is available in the gateway.
Signal Type: Timeout
Duration: Provisioned
Additional Parameters: None
Additional Values 🎀
dt (0x0030) is defined as a tone id for playtone The other tones of this package are defined in exactly the same way. A table with all signal names and signal IDs is included. Note that each tone is defined as both a signal and a toneid, thus extending the basic tone generation package.
Signal Name Signal ID/tone id
Dial Tone dt (0x0030)
Ringing Tone rt (0x0031)
Busy Tone bt (0x0032)
Congestion Tone ct (0x0033)
Special Information Tone sit(0x0034)
Warning Tone wt (0x0035)
Payphone Recognition Tone pt (0x0036)
Call Waiting Tone cw (0x0037)
Caller Waiting Tone cr (0x0038)E.7.4 Statistics
None
E.7.5 Procedures
NOTE - The required set of tone ids corresponds to those defined in Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)]. See E.180 for definition of the meanings of these tones. Read the notes, it's giving responsible 📝
E.8 Call Progress Tones Detection Package 🎶
PackageID: cd (0x0006) Version: 1 Extends: tonedet version 1
This package defines the basic call progress detection tones. This Package extends the possible values of tone id in the "start tone detected", "end tone detected" and "long tone detected" events.
Additional values 🌷
tone id values are defined for start tone detected, end tone detected and long tone detected with the same values as those in package cg (call progress tones generation package).
The required set of tone ids corresponds to Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)]. See Recommendation E.180/Q.35 for definition of the meanings of these tones.
E.8.1 Properties
none
E.8.2 Events
Events are defined as in the call progress tones generator package (cg) for the tones listed in the table of section E.7.3
E.8.3 Signals
none
E.8.4 Statistics
none
E.8.5 Procedures
none
E.9 Analog Line Supervision Package 📱
PackageID: al, 0x0009 Version: 1 Extends: None
This package defines events and signals for an analog line. Phone lines, but make it vintage 📞✨
E.9.1 Properties
None
E.9.2 Events
onhook 📴 EventID: on (0x0004)
Detects handset going on hook. Whenever an events descriptor is activated that requests monitoring for an on-hook event and the line is already on-hook, then the MG shall immediately generate an on-hook event.
EventDescriptor parameters
None
ObservedEventsDescriptor parameters
None
offhook 📲 EventID: of (0x0005)
Detects handset going off hook. Whenever an events descriptor is activated that requests monitoring for an off-hook event and the line is already off-hook, then the MG shall immediately generate an off-hook event.
EventDescriptor parameters
None
ObservedEventsDescriptor parameters
None
flashhook ⚡ EventID: fl, 0x0006
Detects handset flash. A flash occurs when an onhook is followed by an offhook between a minimum and maximum duration.
EventDescriptor parameters
- Minimum duration 🌙
ParameterID: mindur (0x0004)- Type: integer in milliseconds
- Default value is provisioned
- Maximum duration 🌞
ParameterID: maxdur (0x0005)- Type: integer in milliseconds
- Default value is provisioned
ObservedEventsDescriptor parameters
None
E.9.3 Signals ✨
Okay bestie, signals time! 📞 Here's the one that makes the phone go brrr. 🔔
ring 🔔
This one applies ringing on the line, so it's basically the main event. 💖
ring
----
SignalID: ri, 0x0002
Signal Type: TimeOut
Duration: ProvisionedIt has two extra parameters, Cadence and Frequency, and both default to fixed or provisioned. 🎀
Cadence 🥁
Cadence
-------
ParameterID: cad (0x0006)
Type: list of integers representing durations of alternating on
and off segments, constituting a complete ringing cycle
starting with an on. Units in milliseconds.So it's a list of integers for the on and off segments that make up one full ringing cycle, and the cycle always starts with an on ⏱️. Restricted function MGs may ignore cadence values they can't generate, which is totally valid and not a glitch. 🙈
Frequency 🎶
Frequency
---------
ParameterID: freq (0x0007)
Type: integer in HzSame deal here: the default is fixed or provisioned, and restricted function MGs may ignore frequency values they can't generate. 💅
E.9.4 Statistics
None 🫶
E.9.5 Procedures
None 🫶
E.10 Basic Continuity Package 🧚
Continuity tests, bestie! This package defines the events and signals for them. A continuity test can use a loopback or a transceiver functionality. 🔁
PackageID: ct (0x000a)
Version: 1
Extends: NoneE.10.1 Properties
None
E.10.2 Events
Completion 🏁
This event detects when a continuity test is complete. 🎉
Completion
----------
EventID: cmp, 0x0005EventDescriptor parameters: None
ObservedEventsDescriptor parameters:
Result
------
ParameterID: res (0x0008)
Type: Enumeration
Possible values: success (0x0001), failure (0x0000)E.10.3 Signals
Continuity test 🔊
Continuity test
---------------
SignalID: ct (0x0003)
Signal Type: TimeOut
Default value is provisioned
Additional Parameters:
NoneThis one starts sending the continuity test tone on the termination it's applied to. ✨
Respond 📣
Respond
-------
SignalID: rsp (0x0004)
Signal Type: TimeOut
Default duration is provisioned
Additional Parameters:
None.This signal is how you respond to a continuity test. Check out section E.10.5 for the full tea. 🍓
E.10.4 Statistics
None
E.10.5 Procedures
Here's how the continuity test goes down. 🕵️♀️
When a MGC wants to start a continuity test, it sends a command to the MG that has:
- a signals descriptor with the ct signal, and
- an events descriptor containing the cmp event.
When the MG gets a command with the ct signal and the cmp event, it starts the continuity test tone on the specified termination. If the return tone shows up before the signal times out, the cmp event shall be generated with the result parameter set to success. In every other case, the cmp event shall be generated with the result parameter set to failure. 😭
When a MGC wants the MG to respond to a continuity test, it sends a command with a signals descriptor that has the rsp signal. Once the MG gets that, it waits to receive the continuity test tone. If the tone arrives before the rsp signal times out, the MG sends back the applicable return tone. If the rsp signal times out, the MG removes the detection and the return tone (if one was playing). 🌸
When a continuity test runs on a termination, no echo devices or codecs shall be active on that termination. No echo drama allowed. 🙅♀️
Doing voice path assurance as part of continuity testing is set up by bilateral agreement between network operators. 🤝
E.11 Network Package 🌐
This package defines properties of network terminations that don't depend on the network type. Network-agnostic energy, obsessed. ✨
PackageID: nt (0x000b)
Version: 1
Extends: NoneE.11.1 Properties
Maximum Jitter Buffer 🪣
This property puts a max size on the jitter buffer. 📏
Maximum Jitter Buffer
---------------------
PropertyID: jit (0x0007)
Type: integer in milliseconds
Possible Values: This property is specified in milliseconds.
Defined In: LocalControlDescriptor
Characteristics: read/writeE.11.2 Events
network failure 🚨
The termination generates this event when it detects a failure caused by external or internal network issues. Oof. 😩
network failure
---------------
EventID: netfail, 0x0005EventDescriptor parameters: None
ObservedEventsDescriptor parameters:
cause
-----
ParameterID: cs (0x0001)
Type: String
Possible values: any text stringcause can be included with the failure event to give diagnostic info about why it failed. Very helpful, very tea. ☕
quality alert 📉
This one lets the MG flag a loss of quality on the network connection. The MG may do this by measuring packet loss, interarrival jitter, and propagation delay, then reporting the result as a percentage of quality loss. Measuring vibes, literally. 📊
quality alert
-------------
EventID: qualert, 0x0006EventDescriptor parameters:
Threshold
---------
ParameterId: th (0x0001)
Type: integer
Possible Values: threshold for percent of quality loss
measured, calculated based on a provisioned method, that could
take into consideration packet loss, jitter, and delay for
example. Event is triggered when calculation exceeds the
threshold.The event triggers once the calculated quality loss goes over the threshold. 🚩
ObservedEventsDescriptor parameters:
Threshold
---------
ParameterId: th (0x0001)
Type: integer
Possible Values: percent of quality loss measured, calculated
based on a provisioned method, that could take into
consideration packet loss, jitter, and delay for example.E.11.3 Signals
none
E.11.4 Statistics
Duration ⏳
Tells you how long the termination has been in the context. ⌛
Duration
--------
StatisticsID: dur (0x0001)
Description: Provides duration of time the termination has been in
the context.
Type: Double, in millisecondsOctets Sent 📤
Octets Sent
-----------
StatisticID: os (0x0002)
Type: double
Possible Values: any 64 bit integerOctets Received 📥
Octets Received
---------------
StatisticID: or (0x0003)
Type: double
Possible Values: any 64 bit integerE.11.5 Procedures
none
E.12 RTP Package 🦋
This package supports packet-based multimedia data transfer using the Real-time Transport Protocol (RTP) [RFC 1889]. Packets, packets, packets! 📦
PackageID: rtp (0x000c)
Version: 1
Extends: Network Package version 1E.12.1 Properties
None
E.12.2 Events
Payload Transition 🔀
This event detects and reports when the RTP payload format switches from one format to another. Format glow-up. ✨
Payload Transition
EventID: pltrans, 0x0001EventDescriptor parameters: None
ObservedEventsDescriptor parameters:
rtppayload
----------
ParameterID: rtppltype, 0x01
Type: list of enumerated types.Possible values: the encoding method shall be specified using one or several valid encoding names, as defined in the RTP AV Profile or registered with IANA. 📝
E.12.3 Signals
None
E.12.4 Statistics
Packets Sent 📨
Packets Sent
------------
StatisticID: ps (0x0004)
Type: double
Possible Values: any 64 bit integerPackets Received 📬
Packets Received
----------------
StatisticID: pr (0x0005)
Type: double
Possible Values: any 64 bit integerPacket Loss 📉
Packet Loss
-----------
StatisticID: pl (0x0006)This describes the current rate of packet loss on an RTP stream, as defined in IETF RFC 1889. The loss is a percentage: the number of packets lost in the interval between two reception reports, divided by the number of packets expected in that interval. 🧮
Type: double
Possible Values: a 32 bit whole number and a 32 bit fraction.Jitter 🫨
Jitter
------
StatisticID: jit (0x0007)This requests the current interarrival jitter on an RTP stream, as defined in IETF RFC 1889. Jitter measures how much the interarrival time varies between RTP data packets. Wobbly vibes. 🌊
Delay ⏱️
Delay
-----
StatisticID:delay (0x0008)This requests the current packet propagation delay, expressed in timestamp units. It's the same as average latency. 🐢
E.12.5 Procedures
none
E.13 TDM Circuit Package 🔌
This package supports TDM circuit terminations. Old-school but make it iconic. 📻
PackageID: tdmc (0x000d)
Version: 1
Extends: Network Package version 1E.13.1 Properties
Echo Cancellation 🎧
By default, telephony gateways always do echo cancellation. Some calls need it turned off, though. 🙃
Echo Cancellation
-----------------
PropertyID: ec (0x0008)
Type: boolean
Possible Values:
"on" (when the echo cancellation is requested) and
"off" (when it is turned off.)
The default is "on".
Defined In: LocalControlDescriptor
Characteristics: read/writeGain Control 🎚️
Gain control is the signal level adaptation and noise level reduction that adjusts the level of the signal. Some calls, like modem calls, need this turned off. 📶
Gain Control
------------
PropertyID: gain (0x000a)
Type: enumeration (integer)
Possible Values:
The gain control parameter may either be specified as "automatic"
(0xffffffff), or as an explicit number of decibels of gain (any other
integer value). The default is provisioned in the MG.
Defined In: LocalControlDescriptor
Characteristics: read/writeE.13.2 Events
none
E.13.3 Signals
none
E.13.4 Statistics
None
E.13.5 Procedures
None
APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) 🎀
Every Megaco implementor must read the normative part of this document carefully before implementing from it. Nobody should treat the examples in this section as stand-alone explanations of how to build protocol messages. 📖
The examples here use SDP to encode the Local and Remote stream descriptors. SDP is defined in RFC 2327. If the SDP in the examples doesn't match RFC 2327, RFC 2327 should be checked for correctness. The audio profiles used are the ones defined in RFC 1890, plus others registered with IANA. For example, G.711 A-law is called PCMA in the SDP and is assigned profile 0. G.723 is profile 4, and H263 is profile 34. For more, see http://www.iana.org/numbers.htm#R 🔗
A.1 Residential Gateway to Residential Gateway Call 🏠
This example shows how the protocol's elements set up a Residential Gateway to Residential Gateway call over an IP-based network. To keep things simple, both Residential Gateways in the call are controlled by the same Media Gateway Controller. 💜
A.1.1 Programming Residential GW Analog Line Terminations for Idle Behavior
okay so this part is all about getting the Terminations ready to chill in idle mode 💤✨ Both the originating and terminating Media Gateways set up their idle AnalogLine Terminations to watch for call initiation events (aka offhook) using the Modify Command with the right parameters 📞. The null Context means the Terminations aren't in a Context yet 🫶. ROOT means the entire MG instead of one termination inside it 💅
In this example, MG1 has the IP address 124.124.124.222, MG2 is 125.125.125.111, and the MGC is 123.123.123.4. The default Megaco port is 55555 for all three 🎀
- An MG registers with an MGC using the ServiceChange command. MG1 is the one doing it, so here's its message to the MGC 🌸
MEGACO/1 [124.124.124.222]
Transaction = 9998 {
Context = - {
ServiceChange = ROOT {Services {
Method=Restart,
ServiceChangeAddress=55555, Profile=ResGW/1}
}
}
}- The MGC sends a reply 💖
MEGACO/1 [123.123.123.4]:55555
Reply = 9998 {
Context = - {ServiceChange = ROOT {
Services {ServiceChangeAddress=55555, Profile=ResGW/1} } }
}- The MGC programs a Termination in the NULL context 🧚 The terminationId is A4444, the streamId is 1, and the requestId in the Events descriptor is 2222. The mId is the identifier of the sender of this message. In this case that's the IP address and port [123.123.123.4]:55555. Mode for this stream is set to SendReceive. "al" is the analog line supervision package 🦋
MEGACO/1 [123.123.123.4]:55555
Transaction = 9999 {
Context = - {
Modify = A4444 {
Media { Stream = 1 {
LocalControl {
Mode = SendReceive,
ds0/gain=2, ; in dB,
ds0/ec=G165
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
; detection algorithm
}
}
},
Events = 2222 {al/of}
}
}
}The dialplan script could have been loaded into the MG beforehand 🍓 Its job would be to wait for the OffHook, turn on dialtone, and start collecting DTMF digits. In this example, though, we use the digit map instead, which gets put into place after the offhook is detected (step 5 below) 📞✨
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. Lowkey genius, right? 🙈
- The MG1 accepts the Modify with this reply 🫶
MEGACO/1 [124.124.124.222]:55555
Reply = 9999 {
Context = - {Modify = A4444}
}- A similar exchange happens between MG2 and the MGC, resulting in an idle Termination called A5555 💜
Okay that's the idle setup done, bestie! 🌈
A.1.2. Collecting Originator Digits and Initiating Termination ✨
okay so this next bit builds on everything we just set up 💅 It shows the messages between the Media Gateway Controller and the originating Media Gateway (MG1) as they get the originating Termination (A4444) through the digit collection it needs before it can start a connection to the terminating Media Gateway (MG2) 📞
- MG1 detects an offhook event from User 1 and reports it to the Media Gateway Controller with the Notify Command 📲
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Transaction = 10000 {
Context = - {
Notify = A4444 {ObservedEvents =2222 {
19990729T22000000:al/of}}
}
}- And the Notify gets acknowledged ✅
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Reply = 10000 {
Context = - {Notify = A4444}
}- The MGC Modifies the termination so it plays dial tone 🎶, looks for digits according to Dialplan0, and watches for the on-hook event now 👀
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10001 {
Context = - {
Modify = A4444 {
Events = 2223 {
al/on, dd/ce {DigitMap=Dialplan0}
},
Signals {cg/dt},
DigitMap= Dialplan0{
(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
}
}
}- And the Modify is acknowledged 🫶
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 10001 {
Context = - {Modify = A4444}
}- Next, MG1 accumulates digits as User 1 dials them 🔢 Dialtone stops as soon as the first digit is detected 🛑 When the collected digits match the currently programmed Dialplan for A4444, another Notify goes out to the Media Gateway Controller 🎯
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Transaction = 10002 {
Context = - {
Notify = A4444 {ObservedEvents =2223 {
19990729T22010001:dd/ce{ds="916135551212",Meth=FM}}}
}
}- And the Notify is acknowledged ✨
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Reply = 10002 {
Context = - {Notify = A4444}
}- The controller analyses the digits and works out that a connection needs to be made from MG1 to MG2 💫 Both the TDM termination A4444 and an RTP termination get added to a brand new context in MG1 🌸 The Mode is ReceiveOnly, since the Remote descriptor values aren't specified yet 🙈 The preferred codecs are listed in the MGC's preferred order of choice 🎀
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10003 {
Context = $ {
Add = A4444,
Add = $ {
Media {
Stream = 1 {
LocalControl {
Mode = ReceiveOnly,
nt/jit=40, ; in ms
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4
a=ptime:30
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
}
}
}
}
}
}NOTE - The MGC states its preferred parameter values as a series of sdp blocks in Local. The MG fills in the Local Descriptor in the Reply.
- MG1 acknowledges the new Termination and fills in the Local IP address and UDP port 🌐 It also picks a codec based on the MGC's preferences in Local 🎵 MG1 sets the RTP port to 2222 🦋
MEGACO/1 [124.124.124.222]:55555
Reply = 10003 {
Context = 2000 {
Add = A4444,
Add=A4445{
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 4
a=ptime:30
a=recvonly
} ; RTP profile for G.723 is 4
}
}
}
}
}- The MGC will now associate A5555 with a new Context on MG2 🧚 It also sets up an RTP Stream (so A5556 gets assigned), and a SendReceive connection through to the originating user, User 1 🔁 The MGC also turns on ring for A5555 🔔
MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Transaction = 50003 {
Context = $ {
Add = A5555 { Media {
Stream = 1 {
LocalControl {Mode = SendReceive} }},
Events=1234{al/of}
Signals {al/ri}
},
Add = $ {Media {
Stream = 1 {
LocalControl {
Mode = SendReceive,
nt/jit=40 ; in ms
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4
a=ptime:30
},
Remote {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 4
a=ptime:30
} ; RTP profile for G.723 is 4
}
}
}
}
}- And that gets acknowledged 🥰 The stream port number is different from the control port number 🌈 In this case it's 1111 (in the SDP) 💜
MG2 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 50003 {
Context = 5000 {
Add = A5555{}
Add = A5556{
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 125.125.125.111
m=audio 1111 RTP/AVP 4
}
}
} ; RTP profile for G723 is 4
}
}
}- The above IPAddr and UDPport now need to be given to MG1 📬
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10005 {
Context = 2000 {
Modify = A4444 {
Signals {cg/rt}
},
Modify = A4445 {
Media {
Stream = 1 {
Remote {
v=0
c=IN IP4 125.125.125.111
m=audio 1111 RTP/AVP 4
}
} ; RTP profile for G723 is 4
}
}
}
}MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 10005 {
Context = 2000 {Modify = A4444, Modify = A4445}
}- The two gateways are now connected 🤝 User 1 hears the RingBack 🎶 MG2 then waits until User 2 picks up the receiver, and only then is the two-way call established 📞💕
From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Transaction = 50005 {
Context = 5000 {
Notify = A5555 {ObservedEvents =1234 {
19990729T22020002:al/of}}
}
}From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Reply = 50005 {
Context = - {Notify = A5555}
}From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Transaction = 50006 {
Context = 5000 {
Modify = A5555 {
Events = 1235 {al/on},
Signals { } ; to turn off ringing
}
}
}From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Reply = 50006 {
Context = 5000 {Modify = A4445}
}- Time to change the mode on MG1 to SendReceive, and stop the ringback 🔊🛑
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10006 {
Context = 2000 {
Modify = A4445 {
Media {
Stream = 1 {
LocalControl {
Mode=SendReceive
}
}
}
},
Modify = A4444 {
Signals { }
}
}
}from MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 10006 {
Context = 2000 {Modify = A4445, Modify = A4444}}- The MGC decides to Audit the RTP termination on MG2 🔍
MEGACO/1 [123.123.123.4]:55555
Transaction = 50007 {
Context = - {AuditValue = A5556{
Audit{Media, DigitMap, Events, Signals, Packages, Statistics
}}
}
}- MG2 replies 💌 An RTP termination has no events or signals, so those get left out of the reply 🙅♀️
MEGACO/1 [125.125.125.111]:55555
Reply = 50007 {
Context = - {
AuditValue = A5556 {
Media {
Stream = 1 {
LocalControl { Mode = SendReceive,
nt/jit=40 },
Local {
v=0
c=IN IP4 125.125.125.111
m=audio 1111 RTP/AVP 4
a=ptime:30
},
Remote {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 4
a=ptime:30
} } },
Packages {nt-1, rtp-1},
Statistics { rtp/ps=1200, ; packets sent
nt/os=62300, ; octets sent
rtp/pr=700, ; packets received
nt/or=45100, ; octets received
rtp/pl=0.2, ; % packet loss
rtp/jit=20,
rtp/delay=40 } ; avg latency
}
}
}- When the MGC gets an onhook signal from one of the MGs, it brings the call down 📴 In this example, the user at MG2 hangs up first 👋
From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Transaction = 50008 {
Context = 5000 {
Notify = A5555 {ObservedEvents =1235 {
19990729T24020002:al/on}
}
}
}From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Reply = 50008 {
Context = - {Notify = A5555}
}- Now the MGC sends both MGs a Subtract to take the call down 🧹 Only the Subtracts to MG2 are shown here 👀 Each termination keeps its own set of statistics that it gathers 📊 An MGC may not need to request both to be returned 🤷♀️ A5555 is a physical termination, and A5556 is an RTP termination 💜
From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Transaction = 50009 {
Context = 5000 {
Subtract = A5555 {Audit{Statistics}},
Subtract = A5556 {Audit{Statistics}}
}
}From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Reply = 50009 {
Context = 5000 {
Subtract = A5555 {
Statistics {
nt/os=45123, ; Octets Sent
nt/dur=40 ; in seconds
}
},
Subtract = A5556 {
Statistics {
rtp/ps=1245, ; packets sent
nt/os=62345, ; octets sent
rtp/pr=780, ; packets received
nt/or=45123, ; octets received
rtp/pl=10, ; % packets lost
rtp/jit=27,
rtp/delay=48 ; average latency
}
}
}
}- The MGC now sets up both MG1 and MG2 so they're ready to detect the next off-hook event 🔄 See step 1 🫶 This could be the default state of a termination in the null context, and if that's the case, no message needs to be sent from the MGC to the MG 🌸 Once a termination returns to the null context, it goes back to the default termination values for that termination 💅
Authors' Addresses 🎀
Fernando Cuervo Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada E-mail: fcuervo@nortelnetworks.com
Nancy Greene Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada E-mail: ngreene@nortelnetworks.com
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA E-mail: huitema@microsoft.com
Abdallah Rayhan Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada E-mail: arayhan@nortelnetworks.com
Brian Rosen Marconi 1000 FORE Drive Warrendale, PA 15086 USA E-mail: brian.rosen@marconi.com
John Segers Lucent Technologies, Room HE 303 Dept. Forward Looking Work P.O. Box 18, 1270 AA Huizen The Netherlands E-mail: jsegers@lucent.com
Full Copyright Statement 💖
okay bestie, this is the legal bit, so I'm keeping every word exactly as written 📜 The Internet Society owns the copyright, and the rules for copying, sharing, and making derivative works are all in here. Read it carefully, it matters 🫶
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 💜 Ngl, that's the sweetest thank-you note, and it's giving "the people keeping the lights on for us" energy 🙌
That's the whole thing, bestie! 🎀✨ RFC 2885 is a wrap 👑 Go touch some grass, you earned it 🦋
📦 where this page comes from
- ietf: rfc2885 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms