RFC 3525
Gateway Control Protocol Version 1
RFC 3525: Gateway Control Protocol Version 1 🎀
okay bestie, RFC 3525 is the Gateway Control Protocol Version 1 🦋 It was published in June 2003 as a Standards Track document. It was written by C. Groves and M. Pantaleo (LM Ericsson), T. Anderson (Consultant), and T. Taylor (Nortel Networks), and all four are listed as Editors. It's from the Network Working Group, and it obsoletes RFC 3015 💅 The header doesn't have an Updates line, so it doesn't update anything listed there.
Status of this Memo 💖
this is an Internet standards track protocol for the Internet community, and the authors are asking for discussion and suggestions for improvements 🫶 If you want to know where it stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited ✨
Copyright Notice 🌸
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract 🔥
okay so this doc defines the protocol that talks between the two halves of a physically split-up multimedia gateway 🧚 those halves are a Media Gateway and a Media Gateway Controller. 🍓 It's giving "the controller tells the gateway what to do" energy 👑
The protocol here meets the requirements for a media gateway control protocol that were laid out in RFC 2805. Obsessed. 😭
This document replaces RFC 3015. It came out of ongoing teamwork between the IETF Megaco Working Group and ITU-T Study Group 16 🌈 It keeps the original text of RFC 3015, but with fixes and clarifications that were talked through on the Megaco E-mail list and then folded into the Study Group 16 Implementor's Guide for Recommendation H.248. ✨ This version went through ITU-T Last Call as Recommendation H.248 Amendment 1. Then, because of ITU-T renumbering, the ITU-T published it as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Iconic renaming arc 💅
Users of this spec are advised to check the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for more corrections and clarifications 🙈
Conventions used in this document 🎀
the key words are the ones in the BCP 14 list: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're to be read the way RFC 2119 [RFC2119] describes them. Those capitalized words are the official ones, so keep an eye out for them 👀
Table of Contents 📚
1 Scope.........................................................5
1.1 Changes From RFC 3015.....................................5
1.2 Differences From ITU-T Recommendation H.248.1 (03/2002)...5
2 References....................................................6
2.1 Normative references......................................6
2.2 Informative references....................................9
3 Definitions..................................................10
4 Abbreviations................................................11
5 Conventions..................................................12
6 Connection model.............................................13
6.1 Contexts.................................................16
6.2 Terminations.............................................17
6.2.1 Termination dynamics.................................21
6.2.2 TerminationIDs.......................................21
6.2.3 Packages.............................................22
6.2.4 Termination properties and descriptors...............23
6.2.5 Root Termination.....................................25
7 Commands.....................................................26
7.1 Descriptors..............................................27
7.1.1 Specifying parameters................................27
7.1.2 Modem descriptor.....................................28
7.1.3 Multiplex descriptor.................................28
7.1.4 Media descriptor.....................................29
7.1.5 TerminationState descriptor..........................29
7.1.6 Stream descriptor....................................30
7.1.7 LocalControl descriptor..............................31
7.1.8 Local and Remote descriptors.........................32
7.1.9 Events descriptor....................................35
7.1.10 EventBuffer descriptor..............................38
7.1.11 Signals descriptor..................................38
7.1.12 Audit descriptor....................................40
7.1.13 ServiceChange descriptor............................41
7.1.14 DigitMap descriptor.................................41
7.1.15 Statistics descriptor...............................46
7.1.16 Packages descriptor.................................47
7.1.17 ObservedEvents descriptor...........................47
7.1.18 Topology descriptor.................................47
7.1.19 Error Descriptor....................................50
7.2 Command Application Programming Interface................50
7.2.1 Add..................................................51
7.2.2 Modify...............................................52
7.2.3 Subtract.............................................53
7.2.4 Move.................................................55
7.2.5 AuditValue...........................................56
7.2.6 AuditCapabilities....................................59
7.2.7 Notify...............................................60
7.2.8 ServiceChange........................................61
7.2.9 Manipulating and Auditing Context Attributes.........65
7.2.10 Generic Command Syntax..............................66
7.3 Command Error Codes......................................66
8 Transactions.................................................66
8.1 Common parameters........................................68
8.1.1 Transaction Identifiers..............................68
8.1.2 Context Identifiers..................................68
8.2 Transaction Application Programming Interface............69
8.2.1 TransactionRequest...................................69
8.2.2 TransactionReply.....................................69
8.2.3 TransactionPending...................................71
8.3 Messages.................................................72
9 Transport....................................................72
9.1 Ordering of Commands.....................................73
9.2 Protection against Restart Avalanche.....................74
10 Security Considerations.....................................75
10.1 Protection of Protocol Connections......................75
10.2 Interim AH scheme.......................................76
10.3 Protection of Media Connections.........................77
11 MG-MGC Control Interface....................................78
11.1 Multiple Virtual MGs....................................78
11.2 Cold start..............................................79
11.3 Negotiation of protocol version.........................79
11.4 Failure of a MG.........................................80
11.5 Failure of an MGC.......................................81
12 Package definition..........................................82
12.1 Guidelines for defining packages........................82
12.1.1 Package.............................................83
12.1.2 Properties..........................................84
12.1.3 Events..............................................85
12.1.4 Signals.............................................85
12.1.5 Statistics..........................................86
12.1.6 Procedures..........................................86
12.2 Guidelines to defining Parameters to Events and Signals.86
12.3 Lists...................................................87
12.4 Identifiers.............................................87
12.5 Package registration....................................88
13 IANA Considerations.........................................88
13.1 Packages................................................88
13.2 Error codes.............................................89
13.3 ServiceChange reasons...................................89
ANNEX A Binary encoding of the protocol.......................90
A.1 Coding of wildcards......................................90
A.2 ASN.1 syntax specification...............................92
A.3 Digit maps and path names...............................111
ANNEX B Text encoding of the protocol.........................113
B.1 Coding of wildcards.....................................113
B.2 ABNF specification......................................113
B.3 Hexadecimal octet coding................................127
B.4 Hexadecimal octet sequence..............................127
ANNEX C Tags for media stream properties......................128
C.1 General media attributes................................128
C.2 Mux properties..........................................130
C.3 General bearer properties...............................130
C.4 General ATM properties..................................130
C.5 Frame Relay.............................................134
C.6 IP......................................................134
C.7 ATM AAL2................................................134
C.8 ATM AAL1................................................136
C.9 Bearer capabilities.....................................137
C.10 AAL5 properties........................................147
C.11 SDP equivalents........................................148
C.12 H.245..................................................149
ANNEX D Transport over IP.....................................150
D.1 Transport over IP/UDP using Application Level Framing ..150
D.1.1 Providing At-Most-Once functionality................150
D.1.2 Transaction identifiers and three-way handshake.....151
D.1.3 Computing retransmission timers.....................152
D.1.4 Provisional responses...............................153
D.1.5 Repeating Requests, Responses and Acknowledgements..153
D.2 Using TCP...............................................155
D.2.1 Providing the At-Most-Once functionality............155
D.2.2 Transaction identifiers and three-way handshake.....155
D.2.3 Computing retransmission timers.....................156
D.2.4 Provisional responses...............................156
D.2.5 Ordering of commands................................156
ANNEX E Basic packages.......................................157
E.1 Generic.................................................157
E.2 Base Root Package.......................................159
E.3 Tone Generator Package..................................161
E.4 Tone Detection Package..................................163
E.5 Basic DTMF Generator Package............................166
E.6 DTMF detection Package..................................167
E.7 Call Progress Tones Generator Package...................169
E.8 Call Progress Tones Detection Package...................171
E.9 Analog Line Supervision Package.........................172
E.10 Basic Continuity Package...............................175
E.11 Network Package........................................178
E.12 RTP Package............................................180
E.13 TDM Circuit Package....................................182
APPENDIX I EXAMPLE CALL FLOWS (INFORMATIVE)...................184
A.1 Residential Gateway to Residential Gateway Call.........184
A.1.1 Programming Residential GW Analog Line Terminations
for Idle Behavior...................................184
A.1.2 Collecting Originator Digits and Initiating
Termination.........................................186
APPENDIX II Changes From RFC 3015............................195
Intellectual Property Rights..................................210
Acknowledgments...............................................211
Authors' Addresses............................................212
Full Copyright Statement......................................2131. Scope 🌸
okay so this doc is basically a twin of the published ITU-T Recommendation H.248.1 (03/2002), just with the bits noted below changed 💅 it defines the protocols that talk between the elements of a physically decomposed multimedia gateway, which means the pieces are split up and can live on more than one physical device 🧚 and from a system view there are no functional differences between that and a monolithic gateway like the one described in ITU-T Recommendation H.246 ✨ this doc does not define how gateways, multipoint control units or interactive voice response units (IVRs) work, bestie. instead it gives you a general framework that works for all of those apps 🎀
packet network interfaces can be IP, ATM or possibly other stuff 🦋 and they'll support a whole bunch of Switched Circuit Network (SCN) signalling systems, like tone signalling, ISDN, ISUP, QSIG and GSM 💜 national variants of those signalling systems get supported too, wherever they apply 🌈
1.1. Changes From RFC 3015 🍓
the differences between this document and RFC 3015 are written up in Appendix II, so go check there if you want the tea ☕💀
1.2. Differences From ITU-T Recommendation H.248.1 (03/2002) 🎀
okay so this doc is not a copy-paste of the ITU-T one 💅 here's everything that's different:
- IETF front matter replaces the ITU-T material 📄
- The ITU-T summary is super H.323-specific, so it got cut 🙈
- The IETF conventions are now stated as governing this document. As discussed in section 5 below, this gives slightly greater strength to "should" requirements 💪
- The Scope section (just above) got a light edit to fit its IETF context ✨
- Normative references to RFCs 2026 and 2119 were added 📚
- Figures 4, 5, and 6 now show the centre of the context so it's way clearer 🦋 and there's a brand new Figure 6a showing an important extra example 🤩
- A paragraph in section 7.1.18 was added back in 🌸 it was approved in the Implementor's Guide but got lost by accident in the ITU-T approved version 😭
- Corrections to the informative examples in Appendix I are included. They also show up in H.248.1 version 2, but they didn't make it into H.248.1 (03/2002) 🍓
- There's a new Appendix II listing all the changes from RFC 3015 🧚
- There's an Acknowledgements section that lists the authors of RFC 3015 plus a ton of other people who helped build the Megaco/H.248.x protocol 🫶
- The Intellectual Property declaration got moved to its usual spot in an IETF document, and there's now a reference to declarations on the IETF web site 🔥
2. References ✨
okay so these are the references. the ITU-T Recommendations and other references below contain provisions that, through reference in this text, count as provisions of this RFC 👑 at the time of publication, the editions listed were valid. all of them can be revised, so everyone using this RFC is strongly encouraged to check whether the most recent edition of the Recommendations and other references is worth applying 💅 a list of the currently valid ITU-T Recommendations gets published regularly too.
2.1. Normative references 💜
- ITU-T Recommendation H.225.0 (1999), Call signalling protocols and media stream packetization for packet-based multimedia communication systems.
- ITU-T Recommendation H.235 (1998), 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.246 (1998), Interworking of H-series multimedia terminals with H-series multimedia terminals and voice/voiceband terminals on GSTN and ISDN.
- ITU-T Recommendation H.248.8 (2002), H.248 Error Codes and Service Change Reasons.
- ITU-T Recommendation H.323 (1999), Packet-based multimedia communication systems.
- ITU-T Recommendation I.363.1 (1996), B-ISDN ATM adaptation layer (AAL) specification: Type 1 AAL.
- ITU-T Recommendation I.363.2 (1997), B-ISDN ATM adaptation layer (AAL) specification: Type 2 AAL.
- ITU-T Recommendation I.363.5 (1996), B-ISDN ATM adaptation layer (AAL) specification: Type 5 AAL.
- ITU-T Recommendation I.366.1 (1998), Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2.
- ITU-T Recommendation I.366.2 (1999), AAL type 2 service specific convergence sublayer for trunking.
- ITU-T Recommendation I.371 (2000), Traffic control and congestion control in B-ISDN.
- ITU-T Recommendation Q.763 (1999), Signalling System No. 7 - ISDN user part formats and codes.
- ITU-T Recommendation Q.765.5 (2001), Application transport mechanism - Bearer independent call control (BICC).
- ITU-T Recommendation Q.931 (1998), 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 (1995), Digital Subscriber Signalling System No. 2 (DSS2) - User-Network Interface (UNI) - Layer 3 specification for basic call/connection control.
- ITU-T Recommendation Q.2941.1 (1997), Digital Subscriber Signalling System No. 2 - Generic identifier transport.
- ITU-T Recommendation Q.2961.1 (1995), Additional signalling capabilities to support traffic parameters for the tagging option and the sustainable call rate parameter set.
- ITU-T Recommendation Q.2961.2 (1997), Additional traffic parameters: Support of ATM transfer capability in the broadband bearer capability information element.
- ITU-T Recommendation Q.2965.1 (1999), Digital subscriber signalling system No. 2 - Support of Quality of Service classes.
- ITU-T Recommendation Q.2965.2 (1999), Digital subscriber signalling system No. 2 - Signalling of individual Quality of Service parameters.
- ITU-T Recommendation V.76 (1996), Generic multiplexer using V.42 LAPM-based procedures.
- ITU-T Recommendation X.213 (1995), Information technology - Open Systems Interconnection - Network service definition plus Amendment 1 (1997), Addition of the Internet protocol address format identifier.
- ITU-T Recommendation X.680 (1997), Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
- ITU-T Recommendation X.690 (1997), Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
- ATM Forum (1996), ATM User-Network Interface (UNI) Signalling Specification - Version 4.0.
[RFC 1006] Rose, M. and D. Cass, "ISO Transport Service on top of the TCP, Version 3", STD 35, RFC 1006, May 1987.
[RFC 2026] Brander, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC 2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC 2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC 2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
2.2. Informative references 🌈
- 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 (1999), 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 H.226 (1998), Channel aggregation protocol for multilink operation on circuit-switched networks
- ITU-T Recommendation Q.724 (1998), Signalling procedures.
- ITU-T Recommendation Q.764 (1999), Signalling system No. 7 - ISDN user part signalling procedures.
- ITU-T Recommendation Q.1902.4 (2001), Bearer independent call control protocol - Basic call procedures.
[RFC 768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC 1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC 1890] Schulzrinne, H. and G. Fokus, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC 2805] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, April 2000.
3. Definitions 🧚
okay the terms below are the ones this document defines, so the definitions are the official vibes 🔥
Access gateway: A type of gateway that provides a User-Network Interface (UNI) such as ISDN. 🛜
Descriptor: A syntactic element of the protocol that groups related properties. For instance, the properties of a media flow on the MG can be set by the MGC by including the appropriate descriptor in a command. 🎛️
Media Gateway (MG): The media gateway converts media provided in one type of network to the format required in another type of network. For example, a MG could terminate bearer channels from a switched circuit network (e.g., DS0s) and media streams from a packet network (e.g., RTP streams in an IP network). This gateway may be capable of processing audio, video and T.120 alone or in any combination, and will be capable of full duplex media translations. The MG may also play audio/video messages and perform other IVR functions, or may perform media conferencing. 🎬
Media Gateway Controller (MGC): Controls the parts of the call state that pertain to connection control for media channels in a MG. 🧠
Multipoint Control Unit (MCU): An entity that controls the setup and coordination of a multi-user conference that typically includes processing of audio, video and data. 🎤
Residential gateway: A gateway that interworks an analogue line to a packet network. A residential gateway typically contains one or two analogue lines and is located at the customer premises. 🏠
SCN FAS signalling gateway: This function contains the SCN Signalling Interface that terminates SS7, ISDN or other signalling links where the call control channel and bearer channels are collocated in the same physical span. 📡
SCN NFAS signalling gateway: This function contains the SCN Signalling Interface that terminates SS7 or other signalling links where the call control channels are separated from bearer channels. 🛰️
Stream: Bidirectional media or control flow received/sent by a media gateway as part of a call or conference. 🌊
Trunk: A communication channel between two switching systems such as a DS0 on a T1 or E1 line. 🚇
Trunking gateway: A gateway between SCN network and packet network that typically terminates a large number of digital circuits. 🏢
4. Abbreviations 💅
okay so this section is basically the glossary bestie, and it's a LOT of acronyms 😭 i'm keeping the list exactly as it is because the rest of the doc leans on these, no cap:
ALF Application Layer Framing
ATM Asynchronous Transfer Mode
CAS Channel Associated Signalling
DTMF Dual Tone Multi-Frequency
FAS Facility Associated Signalling
GSM Global System for Mobile communications
GW GateWay
IANA Internet Assigned Numbers Authority (superseded by Internet
Corporation for Assigned Names and Numbers - ICANN)
IP Internet Protocol
ISUP ISDN User Part
IVR Interactive Voice Response
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 🎀
okay so the H.248.1 Recommendation has its own vibe for requirement words 🥺 over there, "SHALL" means something mandatory, and "SHOULD" is the suggested-but-optional kind of thing. "MAY" just means you're allowed to do it, with no preference attached 🦋
BUT here's the tea: this document overrides all of that with the RFC 2119 conventions from the top of the doc. RFC 2119 also has a more precise idea of "should" than the ITU-T does, so we go with that one ✨
6. Connection model 🧚
the connection model is basically the cast list for the Media Gateway 💜 it describes the logical entities, or objects, inside the MG that the Media Gateway Controller can control. the two big abstractions are Terminations and Contexts, and honestly they're the main characters here 👑
so a Termination sources and/or sinks one or more streams. in a multimedia conference, a Termination can be multimedia and handle multiple media streams at once, which is so iconic. the media stream parameters, plus the modem and bearer parameters, all live inside the Termination 💅
a Context is an association between a collection of Terminations. there's also a super special one called the null Context, which holds every Termination that isn't associated with any other Termination. for example, in a decomposed access gateway, all the idle lines are Terminations sitting in the null Context 🙈
here's a diagram of these concepts. Figure 1 gives a few examples and is not meant to be an all-inclusive illustration. the asterisk box in each Context stands for the logical association of Terminations that the Context implies ✨
+------------------------------------------------------+
|Media Gateway |
| +-------------------------------------------------+ |
| |Context +-------------+ | |
| | | Termination | | |
| | |-------------| | |
| | +-------------+ +->| SCN Bearer |<---+->
| | | Termination | +-----+ | | Channel | | |
| | |-------------| | |---+ +-------------+ | |
<-+--->| RTP Stream |---| * | | |
| | | | | |---+ +-------------+ | |
| | +-------------+ +-----+ | | Termination | | |
| | | |-------------| | |
| | +->| SCN Bearer |<---+->
| | | Channel | | |
| | +-------------+ | |
| +-------------------------------------------------+ |
| |
| |
| +------------------------------+ |
| (NULL Context) |Context | |
| +-------------+ | +-------------+ | |
| | Termination | | +-----+ | Termination | | |
| |-------------| | | | |-------------| | |
| | SCN Bearer | | | * |------| SCN Bearer |<---+->
| | Channel | | | | | Channel | | |
| +-------------+ | +-----+ +-------------+ | |
| +------------------------------+ |
| |
| |
| +-------------------------------------------------+ |
| |Context | |
| | +-------------+ +-------------+ | |
| | | Termination | +-----+ | Termination | | |
| | |-------------| | | |-------------| | |
<-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
| | | Channel | | | | Channel | | |
| | +-------------+ +-----+ +-------------+ | |
| +-------------------------------------------------+ |
| ___________________________________________________ |
+------------------------------------------------------+Figure 1: Examples of Megaco/H.248 Connection Model
next up, Figure 2 shows one way to handle a call-waiting scenario in a decomposed access gateway. it shows how a Termination gets relocated between Contexts, which is such a plot twist 😭 Terminations T1 and T2 are in Context C1 on a two-way audio call. then a second audio call comes in for T1 from Termination T3, and T3 is all alone in Context C2. T1 accepts the call from T3 and puts T2 on hold. that makes T1 move into Context C2, as Figure 3 shows 🌈
+------------------------------------------------------+
|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 T1
6.1. Contexts 🌸
a Context is an association between a number of Terminations. it describes the topology (who hears/sees whom), plus the media mixing and/or switching parameters once more than two Terminations are involved 🫶
the null Context is a special one that holds Terminations not associated with any other Termination. Terminations in the null Context can have their parameters examined or modified, and they can have events detected on them 👀
generally, an Add command is how you put Terminations into Contexts. if the MGC doesn't name an existing Context for the Termination, the MG creates a new one 🪄 a Termination can leave a Context with a Subtract command, and it can move from one Context to another with a Move command. a Termination SHALL exist in only one Context at a time, no exceptions, periodt 💀
the max number of Terminations in a Context is an MG property. media gateways that only do point-to-point might allow at most two Terminations per Context, while ones that support multipoint conferences might allow three or more 🍓
6.1.1. Context attributes and descriptors 💖
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 it. the mode of a Termination (send/receive/...) is different, since it describes the flow of media at the ingress/egress of the media gateway. two different vibes, both important 🦋
- The priority is used for a Context to give the MG info about precedence handling for that Context. the MGC can also use the priority to smoothly control the traffic precedence in the MG on its own in certain situations (e.g., restart), when a lot of Contexts need handling at once. Priority 0 is the lowest priority and a priority of 15 is the highest priority 📈
- An indicator for an emergency call is also provided, so the MG can give it preference handling 🚨
6.1.2 Creating, deleting and modifying Contexts ✨
okay so the protocol can (implicitly) create Contexts and tweak the parameter values of Contexts that already exist 💅 It has commands to add Terminations to a Context, subtract them, and move Terminations between Contexts 🔄 And the Context gets deleted automatically once its last Termination is subtracted or moved out. Bye bye, empty Context 👋
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 ride along inside commands. Every Termination gets a unique identity (a TerminationID), and the MG is the one who assigns it when the Termination is created 🫶
Physical entities get semi-permanent Terminations. A Termination for a TDM channel might hang around for as long as it's provisioned in the gateway 🌸 Ephemeral information flows, like RTP flows, usually only exist for as long as they're being used. Temporary vibes only 🧚
Ephemeral Terminations get created with an Add command and destroyed with a Subtract command 💜 Physical Terminations are different: when one is Added to or Subtracted from a Context, it's taken from or sent to the null Context 🙈
Terminations can have signals applied to them (see 7.1.11) ✨ They can also be set up to detect Events. When an Event happens, it can trigger a notification to the MGC or an action by the MG 🔥 Statistics can be collected on a Termination too. They get reported to the MGC when asked for (with the AuditValue command, see 7.2.5), and also when the Termination gets taken out of the call it's in 📊
Now the multiplexing stuff, which is giving real main character energy 👑 Multimedia gateways can process multiplexed media streams. Recommendation H.221 is the example here, a frame structure for several media streams multiplexed over a bunch of digital 64 kbit/s channels 🌈 The connection model handles it like this. Every bearer channel carrying part of the multiplexed streams gets a physical or ephemeral "bearer Termination" 🍓 The bearer Terminations that source/sink those digital channels then connect to one separate Termination, called the "multiplexing Termination". That multiplexing Termination is an ephemeral Termination representing a frame-oriented session. Its MultiplexDescriptor says which multiplex is being used (for example, H.221 for an H.320 session) and the order the contained digital channels get assembled into a frame 🧩
Multiplexing Terminations can be cascades too (like an H.226 multiplex of digital channels feeding into an H.223 multiplex supporting an H.324 session) 😭
The individual media streams in the session are described by StreamDescriptors on the multiplexing Termination 💖 Those streams can be associated with streams sourced/sunk by Terminations in the Context other than the bearer Terminations that support the multiplexing Termination. Each bearer Termination supports only a single data stream. Those data streams don't show up explicitly as streams on the multiplexing Termination, and they're hidden from the rest of the Context 🙈
Figures 4, 5, 6, and 6a show typical uses of the multiplexing Termination and the Multiplex Descriptor. Look at these diagrams, they're so iconic 🖼️
+-----------------------------------+
| Context +-------+ |
+----+ | | |
Circuit 1 -|--| TC1|---------+ Tmux | |
| +----+ (Str 1) | | Audio +-----+
| | | +-----*-----+ |-----
| +----+ | H.22x | Stream 1 | |
Circuit 2 -|--| TC2|---------+ multi-| | TR1 |
| +----+ (Str 1) | plex | |(RTP)|
| | | | Video | |
| +----+ | +-----*-----+ |-----
Circuit 3 -|--| TC3|---------+ | Stream 2 | |
/ +----+ (Str 1) | | +-----+
/ | +-------+ |
/ +-----------------\-----------------+
Audio, video, and control \
signals are carried in frames Tmux is an ephemeral with two
spanning the circuits. explicit Stream Descriptors
and a Multiplex Descriptor.
Figure 4: Multiplexed Termination Scenario - Circuit to Packet
(Asterisks * denote the centre of the context) Context
+--------------------------------------+
| +-------+ +-------+ |
+----+ | | | | +----+
Circuit 1 ----| TC1|---+ Tmux1 | Audio | Tmux2 +---| TC4|---
+----+ | +---*----+ | +----+
| | | Str 1 | | |
+----+ | H.22x | | H.22x | +----+
Circuit 2 ----| TC2|---+ multi-| | multi-+---| TC5|---
+----+ | plex | | plex | +----+
| | | Video | | |
+----+ | +---*----+ | +----+
Circuit 3 ----| TC3|---+ | Str 2 | +---| TC6|---
+----+ | | | | +----+
| +-------+ +-------+ |
+-----------------\-----/--------------+
\ /
Tmux1 and Tmux2 are ephemerals each with two
explicit Stream Descriptors and a Multiplex Descriptor.
Figure 5: Multiplexed Termination Scenario - Circuit to Circuit
(Asterisks * denote the centre of the context) +-----------------------------------+
| Context +-------+ |
+----+ | | |
Circuit 1 -|--| TC1|---------+ Tmux | |
| +----+ (Str 1) | | Audio +-----+
| | | +-----*-----+ TR1 |-----
| +----+ | H.22x | Stream 1 |(RTP)|
Circuit 2 -|--| TC2|---------+ multi-| +-----+
| +----+ (Str 1) | plex | |
| | | | Video +-----+
| +----+ | +-----*-----+ TR2 |-----
Circuit 3 -|--| TC3|---------+ | Stream 2 |(RTP)|
/ +----+ (Str 1) | | +-----+
/ | +-------+ |
/ +-----------------\-----------------+
Audio, video, and control \ Tmux is an ephemeral with two
signals are carried in frames explicit Stream Descriptors and
spanning the circuits. and a Multiplex Descriptor.
Figure 6: Multiplexed Termination Scenario - Single to Multiple
Terminations
(Asterisks * denote the centre of the context) Context
+---------------------------------------------+
| +-------+ +-------+ |
Cct 1 +----+ | | | | Audio +-----+
----| TC1|---+ Tmux1 | | Tmux2 +-----*-----| TR1 |-----
+----+ | | | | Stream 1 |(RTP)|
| | | Data | | +-----+
Cct 2 +----+ | H.226 +-------+ H.223 | |
----| TC2|---+ multi-|(Str 1)| multi-| Control +-----+
+----+ | plex | | plex +-----*-----+ Tctl|-----
| | | | | Stream 3 +-----+
Cct 3 +----+ | | | | |
----| TC3|---+ | | | +-----+
+----+ | | | +-----*-----+ TR2 |-----
| +-------+ | | Video |(RTP)|
| +-------+ Stream 2 +-----+
| |
+---------------------------------------------+
Tmux1 has a Multiplex Descriptor and a single data stream.
Tmux2 has a Multiplex Descriptor with a single bearer and
three explicit Stream Descriptors.
Figure 6a: Multiplexed Termination Scenario - Cascaded Multiplexes
(Asterisks * denote the centre of the context)
Note: this figure does not appear in Rec. H.248.1Terminations can also be created to represent multiplexed bearers, like an ATM AAL Type 2 bearer 🌊 When a new multiplexed bearer needs to be created, an ephemeral Termination gets created in a Context that's set up for that purpose. When that Termination is subtracted, the multiplexed bearer is destroyed 💀
6.2.1 Termination dynamics 🔧
The protocol can create new Terminations and modify the property values of existing ones 💅 Those modifications can include adding or removing Events and/or signals. The Termination properties, Events and signals get described in the subclauses that follow. An MGC can only release or modify Terminations (and the resources they represent) that it has previously seized, for example through the Add command 🔐
6.2.2 TerminationIDs 🆔
Terminations are referenced by a TerminationID, which is an arbitrary schema chosen by the MG 🌈
TerminationIDs of physical Terminations get provisioned in the Media Gateway. They can be given structure too. For instance, a TerminationID might be made of a trunk group and a trunk within that group 🍓
There's a wildcarding mechanism using two types of wildcards that can be used with TerminationIDs 🃏 The two wildcards are ALL and CHOOSE. ALL is for addressing multiple Terminations at once, while CHOOSE tells a media gateway that it has to select a Termination matching the partially specified TerminationID. So, for example, an MGC can tell an MG to pick 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. ALL does not address the ROOT termination 🙅♀️ Each of those commands may generate a response, so the whole response can get really big 😭 If individual responses aren't needed, a wildcard response can be requested instead. Then only one response is generated, containing the UNION of all the individual responses that would otherwise have been generated, with duplicate values suppressed. Say Termination Ta has properties p1=a, p2=b and Termination Tb has properties p2=c, p3=d. A UNION response would then consist of a wildcarded TerminationId and the sequence of properties p1=a, p2=b,c and p3=d ✨ Wildcard responses are especially handy in the Audit commands 🫧
The encoding of the wildcarding mechanism is detailed in Annexes A and B 📖
6.2.3 Packages 🎀
Okay bestie, not every gateway is the same 💅 Some Terminations have totally different vibes, so the protocol lets Terminations have optional Properties, Events, Signals and Statistics that the MG implements (or doesn't) 🦋
To keep MG/MGC interop from getting messy, all those options get bundled into Packages 📦 A Termination usually realizes a whole set of them. You can read more about how packages get defined in clause 12 ✨ And an MGC can audit a Termination to see which Packages it realizes 👀
Properties, Events, Signals and Statistics defined in Packages, plus their parameters, get referenced by identifiers (Ids) 🏷️ These identifiers are scoped, so each package has its own separate name spaces for PropertyIds, EventIds, SignalIds, StatisticsIds and ParameterIds. The same identifier can show up in more than one of them, and two PropertyIds in different packages can share an identifier too. No drama 🙌
To support a particular package, the MG must support all properties, signals, events and statistics defined in that package. It must also support all Signal and Event parameters. The MG may support only a subset of the values listed in a package for a particular Property or Parameter 💜
Now the extension part, which is kinda iconic 🧚 When a package gets extended, the properties, events, signals and statistics from the base package can be referred to using either the extended package name or the base package name. For example, if Package A defines event e1 and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but publishing the base package as an allowed interface is optional. If it does publish A, then A gets reported on the Package Descriptor in AuditValue alongside B, and the event A/e1 is available on a termination. If the MG doesn't publish A, then only B/e1 is available. And if it's published through AuditValue, A/e1 and B/e1 are the same event 🤯
For improved interoperability and backward compatibility, an MG MAY publish all Packages supported by its Terminations, including the base Packages that extended Packages are derived from. The one exception is when the base packages are expressly "Designed to be extended only" 🚫
6.2.4 Termination properties and descriptors 💖
Terminations have properties, and each property has a unique PropertyIDs 🌸 Most properties have default values. Those defaults are either explicitly defined in this protocol specification, in a package (see clause 12), or set by provisioning.
If it's not provisioned otherwise, the properties in all descriptors except TerminationState and LocalControl default to empty/"no value" when a Termination is first created or returned to the null Context. The default contents of those two exceptions are described in 7.1.5 and 7.1.7 📋
Provisioning a property value in the MG overrides any default value, whether it came from this protocol specification or from a package. So if the MGC needs full control over a Termination's property values, it should supply explicit values when ADDing the Termination to a Context. Or, for a physical Termination, the MGC can figure out any provisioned property values by auditing the Termination while it's in the NULL Context 🔍
There are common properties for Terminations and properties specific to media streams. The common ones are also called the Termination state properties ✨ For each media stream, there are local properties plus properties of the received and transmitted flows 🌊
Properties that aren't in the base protocol are defined in Packages. They're referred to by a name made of the PackageName and a PropertyId. Most have default values described in the Package description. Properties can be read-only or read/write. The possible values of a property can be audited, and so can its current values. For read/write properties, the MGC can set the values. A property can be declared as "Global", which means it has a single value shared by all Terminations realizing the package 🌈 Related properties get grouped into descriptors, just for convenience 🫶
When a Termination gets added to a Context, you can set its read/write property values by including the right descriptors as parameters to the Add command. Similarly, a property of a Termination in a Context can have its value changed by the Modify command 💅
Properties can also change value when a Termination is moved from one Context to another as the result of a Move command. And in some cases, descriptors come back as output from a command 🎀
Generally, if a Descriptor is completely omitted from one of the commands above, the properties in that Descriptor keep their prior values for the Termination(s) the Command acts on. BUT if some read/write properties are left out of a Descriptor (so it's only partially specified), those properties get reset to their default values for the Termination(s) the Command acts on, unless the package specifies other behavior. See clause 7.1 for the details on each Descriptor 😭
The table below lists all the possible descriptors and what they're for. Not every descriptor is legal as an input or output parameter for every command, so keep that in mind 🍓
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 (see 7.1.11) applied to
Terminations.
Audit In Audit commands, identifies which information is
desired.
Packages In AuditValue, returns a list of Packages realized
by Termination.
DigitMap Defines patterns against which sequences of a
specified set of events are to be matched so they
can be reported as a group rather than singly.
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.
Topology Specifies flow directions between Terminations in a
Context.
Error Contains an error code and optionally error text;
it may occur in command replies and in Notify
requests.6.2.5 Root Termination 🌟
Sometimes a command needs to talk about the entire gateway instead of one Termination inside it 👑 That's what the special TerminationID "Root" is reserved for ✨ Packages can be defined on Root, so Root can have properties, events and statistics. Signals aren't appropriate for Root, though 🙅♀️
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 and statistics 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 🚦
Any other use of the root TerminationID is an error, no exceptions 🙅♀️ In those cases, 410 - Incorrect identifier shall be returned. Error code 410 is the one you want to memorize, periodt 💀
7. Commands ✨
okay bestie, this is the part where the protocol gets to actually do stuff 💅 Commands are how you touch the logical entities from the connection model, which are Contexts and Terminations. They give you the finest-grained control the protocol has 🔍 You can add Terminations to a Context, modify them, subtract them, and audit their properties. You get full control over Context and Termination properties 👑 That includes picking which events a Termination reports, which signals or actions get applied to it, and the topology of a Context (aka who hears and sees whom 🫣).
Most commands are the Media Gateway Controller initiating and the Media Gateways responding 🎀 The exceptions are Notify, which goes from the Media Gateway to the Media Gateway Controller, and ServiceChange, which either entity MAY send 🙌 Here's the lineup. We'll go deeper in 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 a 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 7.2.1 through 7.2.8. 💖
7.1. Descriptors 🧩
The parameters to a command are called Descriptors. A descriptor is a name plus a list of items, and some items MAY have values. Lots of commands share the same descriptors, so this subclause lists them all in one place 📝 Descriptors MAY also be returned as output from a command. When a descriptor's contents come back, an empty descriptor shows up as just its name with no list after it. Parameters that only matter for one specific command are explained in the subclause for that command.
7.1.1. Specifying parameters 🎯
Command parameters are grouped into descriptors. The general text format looks like DescriptorName=<someID>{parm=value, parm=value, ...}.
Parameters MAY be fully specified, overspecified or underspecified:
- Fully specified parameters have one clear, unambiguous value. The command initiator is telling the command responder exactly what to use for that parameter 🎯
- Underspecified parameters use the
CHOOSEvalue, which lets the command responder pick any value it can support 🎲 - Overspecified parameters come with a list of potential values. The order of the list is the command initiator's order of preference. The command responder picks one value from the list and sends that value back to the command initiator 🥇
If a required descriptor other than the Audit descriptor is totally absent from a command, then whatever values were previously set in that descriptor for that Termination, if any, are kept 🫶 In commands other than Subtract, a missing Audit descriptor counts the same as an empty Audit descriptor. How the MG handles unspecified parameters inside a descriptor depends on that descriptor, and the later subclauses spell it out. Whenever a parameter is underspecified or overspecified, the descriptor holding the value the responder chose SHALL NOT be left out. It comes back as output from the command 👀
Oops, I need to fix that last bit, because the original is about inclusion, not prohibition. Here it is properly: whenever a parameter is underspecified or overspecified, the descriptor containing the value the responder chose is included as output from the command 💅
Each command names the TerminationId it operates on. That TerminationId MAY be "wildcarded". When a command's TerminationId is wildcarded, the effect SHALL be as if the command had been repeated once for each TerminationId that matched 🌈
7.1.2. Modem descriptor 📞
The Modem descriptor specifies the modem type and any parameters it needs for things like H.324 and text conversation. It covers these modem types: V.18, V.22, V.22 bis, V.32, V.32 bis, V.34, V.90, V.91, Synchronous ISDN, and it leaves room for extensions 🎀 By default, a Termination has no Modem descriptor.
7.1.3. Multiplex descriptor 🧵
In multimedia calls, a bunch of media streams ride on a (possibly different) number of bearers. The multiplex descriptor is what ties the media to the bearers 🪢 It includes the multiplex type:
- H.221;
- H.223;
- H.226;
- V.76;
- possible extensions,
plus a set of TerminationIDs for the multiplexed bearers, kept in order. Here's an example:
Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}7.1.4. Media descriptor 🎬
The Media descriptor sets the parameters for all the media streams. It's split into two parts: a TerminationState descriptor, which covers the Termination properties that aren't stream-specific, and one or more Stream descriptors, where each one describes a single media stream 🍓
Each stream gets a StreamID, and the StreamID is what links together the streams in a Context that belong as a set. Multiple streams exiting a Termination SHALL be synchronized with each other ⏱️ Inside a Stream descriptor there are up to three sub-descriptors: LocalControl, Local, and Remote. Here's how they nest:
Media descriptor
TerminationState Descriptor
Stream descriptor
LocalControl descriptor
Local descriptor
Remote descriptorFor convenience, LocalControl, Local, or Remote descriptors MAY be placed in the Media descriptor without wrapping them in a Stream descriptor. When that happens, the StreamID is assumed to be 1 🧚
7.1.5. TerminationState descriptor 🚦
The TerminationState 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 these states: "test", "out of service", or "in service". "test" means the Termination is being tested. "out of service" means the Termination can't be used for traffic. "in service" means the Termination can be used, or is being used, for normal traffic. "in service" is the default state ✅
Property values can be simple values (integer, string, or enumeration), or they can be underspecified. Underspecified means you supply more than one value and the MG MAY make the choice itself 🎲 Here are the options:
- 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 right away. See 7.1.9 for the details 🧠
7.1.6. Stream descriptor 🌊
A Stream descriptor sets the parameters for one bidirectional stream. Those parameters are split into three descriptors: one with Termination properties that are specific to a stream, and then one each for the local and remote flows 💜 The Stream descriptor carries 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 every Termination in the Context that used to support that stream 🗑️
StreamIDs only mean something locally, between the MGC and the MG, and the MGC is the one that assigns them. Inside a Context, the StreamID is how you tell which media flows are connected to each other: streams with the same StreamID are connected 🔗
If a Termination gets moved from one Context to another, the receiving Context ends up in the same state it would be in if a brand-new Termination had been added with the same StreamIDs as the moved one 🦋
7.1.7 LocalControl descriptor ✨
okay so the LocalControl descriptor is the bit that holds the Mode property, the ReserveGroup and ReserveValue properties, and any Termination properties (from Packages) that are stream-specific and matter between the MG and the MGC. Property values can be underspecified the same way they were back in 7.1.1 🎀
The allowed mode values are send-only, receive-only, send/receive, inactive and loop-back 🦋 "Send" and "receive" are measured from the outside of the Context, so a stream set to mode=sendOnly won't pass received media into the Context. The default is Inactive. Signals and Events aren't affected by mode at all, so don't go looking for that drama 💅
The two boolean Reserve properties, ReserveValue and ReserveGroup, tell the MG what to do when it gets a Local and/or Remote descriptor 👑
If a Reserve property is True, the MG SHALL reserve resources for every alternative in the Local and/or Remote descriptors that it currently has resources for. It SHALL respond with the alternatives it actually reserved. If it can't support any of the alternatives, it SHALL reply to the MGC with empty Local and/or Remote descriptors 💀 And if media starts flowing while more than one alternative is reserved, media packets may be sent or received on any of them and must be processed, though only one alternative can be active at any given time ✨
If a Reserve property is False, the MG SHALL choose one alternative from the Local descriptor (if there is one) and one from the Remote descriptor (if there is one). If it hasn't reserved resources for the chosen alternative yet, it SHALL reserve them. But if it already reserved resources for that Termination because of an earlier exchange with ReserveValue and/or ReserveGroup set to True, it SHALL release any excess resources it reserved before 🧹 After that, the MG shall send a reply to the MGC containing the alternatives it selected for the Local and/or Remote descriptor. And if the MG doesn't have enough resources for any of the alternatives, it SHALL respond with error 510 (insufficient resources) 😭
The default for both ReserveValue and ReserveGroup is False. More detail on how the two Reserve properties get used is in 7.1.8 🌈
A new LocalControl descriptor completely replaces the previous one in the MG, so it's not a merge situation 🙈 If the MGC wants to keep any old info, it has to include that info in the new setting again. And if it wants to delete something, it just resends the descriptor (in a Modify command) with the unwanted stuff stripped out 🍓
7.1.8 Local and Remote descriptors 💜
okay this one is the big deal. The MGC uses Local and Remote descriptors to reserve and commit MG resources for media decoding and encoding, for the Stream(s) and Termination they apply to ✨ The MG puts these descriptors in its response to show what it's actually ready to support. The MG SHALL add extra properties and their values to its response if they're mandatory but weren't in the MGC's request. For example, if the MGC only gave a payload type, the MG has to spell out the detailed video encoding parameters 🎬
Local means the media the MG receives, and Remote means the media the MG sends 🦋
When the protocol is text encoded, the descriptors are session descriptions as defined in SDP (RFC 2327). For session descriptions going from the MGC to the MG, these exceptions to the RFC 2327 syntax are allowed:
- the
s=,t=ando=lines are optional; - CHOOSE can be used in place of a single parameter value; and
- alternatives can be used in place of a single parameter value.
A Stream Descriptor covers one bi-directional media stream, so a single session description MUST NOT include more than one media description (m= line) 🙅♀️ A Stream Descriptor can still have extra session descriptions as alternatives. Each media stream for a termination has to live in its own distinct Stream Descriptor. When you put multiple session descriptions in one descriptor, the v= lines are required as delimiters. Otherwise, they're optional in session descriptions sent to the MG. Implementations shall accept session descriptions that fully conform to RFC 2327 💖 When the protocol is binary encoded, the descriptor is made of groups of properties (tag-value pairs) as specified in Annex C, and each group can hold the parameters of a session description.
Now the semantics of Local and Remote get spelled out in detail, in two parts. Part one covers what the contents of the descriptor mean. Part two covers what the MG must do after getting the Local and Remote descriptors. What the MG does depends on the ReserveValue and ReserveGroup values in LocalControl 🔥
Either the Local or the Remote descriptor (or both) can be:
- unspecified (i.e., absent);
- empty;
- underspecified through use of CHOOSE in a property value;
- fully specified; or
- overspecified through presentation of multiple groups of properties and possibly multiple property values in one or more of these groups.
When the descriptors come from the MGC to the MG, they get interpreted using the rules in 7.1.1, plus these extra notes:
- a) An unspecified Local or Remote descriptor counts as a missing mandatory parameter. The MG then has to use whatever was last specified for that descriptor. If nothing was ever specified, that's possible too, and in that case the descriptor is ignored in the rest of the command's processing 🙃
- 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 multiple values within a group, the order of preference is descending ✨
- d) Underspecified or overspecified properties within a group that the MGC sends are requests for the MG to pick one or more values it can support for each property. For an overspecified property, the list of values is in descending order of preference 💅
After all that, what happens next depends on the values of 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 asked to reserve resources so it can decode or encode the media stream using any of the alternatives. For instance, say the Local descriptor has two groups of properties, one for packetized G.711 A-law audio and the other for G.723.1 audio. The MG reserves resources so it can decode one audio stream encoded in either G.711 A-law format or G.723.1 format. It does NOT have to reserve resources to decode two audio streams at once, one in G.711 A-law and one in G.723.1 🧚 The intention for ReserveValue works the same way.
If ReserveGroup is True or ReserveValue is True, these rules apply too:
- If the MG doesn't have enough resources to support all the alternatives the MGC asked for, and the MGC asked for resources in both Local and Remote, the MG should reserve resources to support 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 to the MGC, when the MGC included Local and Remote descriptors, the MG SHALL include Local and Remote descriptors for every group of properties and property values it reserved resources for. If the MG can't support at least one alternative within the Local (Remote) descriptor from the MGC, it SHALL return an empty Local (Remote) descriptor 🙈
- If the Mode property of the LocalControl descriptor is
RecvOnly,SendRecv, orLoopBack, the MG must be ready to receive media encoded according to any of the alternatives in its response to the MGC 🦋
If ReserveGroup is False and ReserveValue is False, the MG SHOULD apply these rules to narrow Local and Remote down to a single alternative each:
- The MG picks the first alternative in Local for which it can support 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 ✨
Just like LocalControl, a new setting of a Local or Remote descriptor completely replaces the previous one in the MG. If the MGC wants to keep old info, it has to put that info into the new setting. And if it wants to delete something, it resends the descriptor (in a Modify command) with the unwanted information stripped out 🍓
7.1.9 Events descriptor 🔔
The EventsDescriptor parameter has a RequestIdentifier and a list of events the Media Gateway is asked to detect and report 📣 The RequestIdentifier is what ties the request to the notifications it might set off. Requested events include things like fax tones, continuity test results, and on-hook and off-hook transitions 📞 The RequestIdentifier is left out if the EventsDescriptor is empty (meaning no events are specified).
Each event in the descriptor has an Event name, an optional streamID, an optional KeepActive flag, and optional parameters. The Event name is made of a Package Name (where the event is defined) and an EventID. You can use the ALL wildcard for the EventID, which means every event from that package has to be detected 👑 The default streamID is 0, which means the event isn't tied to any particular media stream. Events can have parameters, so one event description can vary in meaning without needing a huge pile of separate events 🌈 More event parameters are defined in the package itself.
If a digit map completion event is present or implied in the EventsDescriptor, the EventDM parameter carries either the name or the value of the associated digit map. Check out 7.1.14 for more details 🧠
Okay so picking up right where the events stuff left off 💅 When an event gets processed against an active Events Descriptor and it's found in there ("recognized"), the MG's default move is to send a Notify command to the MGC 📣 Notification can get deferred if the event gets absorbed into the current dial string of an active digit map (see 7.1.14) 🎀 Anything else the MG does is for further study, so that's still an open question 🤷♀️ Event recognition can also make currently active signals stop, or swap out the current Events and/or Signals descriptor, which we'll get to at the end of this bit ✨ Unless another Events Descriptor replaces it, the Events Descriptor stays active after an event gets recognized, no cap 🔒
If EventBufferControl equals LockStep, then once an event like that is detected, normal event handling gets paused 🫶 Any event that's detected after that and shows up in the EventBuffer 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 be loaded either because a command came in with a new EventsDescriptor, or by activating an embedded EventsDescriptor ✨
If EventBufferControl equals Off, the MG just keeps going based on the active EventsDescriptor 💖
In the case of an embedded EventsDescriptor being activated, the MG keeps doing event processing based on the newly activated EventsDescriptor 🌸
NOTE 1 - For purposes of EventBuffer handling, activation of an embedded EventsDescriptor is equivalent to receipt of a new EventsDescriptor.
When the MG gets a command with a new EventsDescriptor, there might be one or more events already sitting in the EventBuffer in the MG 👀 The value of EventBufferControl then decides how the MG handles those buffered events 🎀
Case 1
If EventBufferControl equals LockStep and the MG receives a new EventsDescriptor, it will check the FIFO EventBuffer and take the following actions:
- If the EventBuffer is empty, the MG waits for detection of events based on the new
EventsDescriptor. - If the EventBuffer is non-empty, the MG processes the FIFO queue starting with the first event:
- a) If the event in the queue is in the events listed in the new
EventsDescriptor, the MG acts on the event and removes the event from the EventBuffer. The time stamp of the Notify shall be the time the event was actually detected. The MG then waits for a new EventsDescriptor. While waiting for a new EventsDescriptor, any events detected that appear in theEventsBufferDescriptorwill be placed in the EventBuffer. When a new EventsDescriptor is received, the event processing will repeat from step 1. - b) If the event is not in the new EventsDescriptor, the MG SHALL discard the event and repeat from step 1.
- a) If the event in the queue is in the events listed in the new
Case 2
If EventBufferControl equals Off and the MG receives a new EventsDescriptor, it processes new events with the new EventsDescriptor 🌈
If the MG gets 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 procedures on transmitting the Notify command, check the appropriate annex or Recommendation of the H.248 sub-series for specific transport considerations 📚
The default value of EventBufferControl is Off 🍓
NOTE 2 - Since the EventBufferControl property is in the TerminationStateDescriptor, the MG might receive a command that changes the EventBufferControl property and does not include an EventsDescriptor.
Normally, recognition of an event shall cause any active signals to stop. When KeepActive is specified in the event, the MG shall not interrupt any signals active on the Termination on which the event is 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 recognized 🪄 It's possible, for example, to specify that the dial-tone Signal be generated when an off-hook Event is recognized, or that the dial-tone Signal be stopped when a digit is recognized 📞 A media gateway controller shall not send EventsDescriptors with an event both marked KeepActive and containing an embedded SignalsDescriptor 🚫
Only one level of embedding is permitted. 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 in process shall complete, and events detected after the command containing the new EventsDescriptor executes shall be processed according to the new EventsDescriptor 🔁
An empty Events Descriptor disables all event recognition and reporting. An empty EventBuffer Descriptor clears the EventBuffer and disables all event accumulation in LockStep mode: the only events reported will be those occurring while an Events Descriptor is active 🧹 If an empty Events Descriptor is activated while the Termination is operating in LockStep mode, the events buffer is immediately cleared 💨
7.1.10. EventBuffer descriptor 🧺
The EventBuffer descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep (see 7.1.9) 📋
7.1.11. Signals descriptor 🔊
Signals are MG generated media such as tones and announcements, as well as bearer-related signals such as hookswitch 📞 More complex signals may include a sequence of such simple signals interspersed with, and conditioned upon, the receipt and analysis of media or bearer-related signals 🧠 Examples include echoing of received data, as in the Continuity Test package 🔁 Signals may also request preparation of media content for future signals 🎶
A SignalsDescriptor is a parameter that contains the set of signals that the Media Gateway is asked to apply to a Termination 🎀 A SignalsDescriptor contains a number of signals and/or sequential signal lists 📑 A SignalsDescriptor may contain zero signals and sequential signal lists. Support of sequential signal lists is optional 🫧
Signals are defined in packages. Signals shall be named with a Package name (in which the signal is defined) and a SignalID. No wildcard shall be used in the SignalID 🃏 Signals that occur in a SignalsDescriptor have an optional StreamID parameter (default is 0, to indicate that the signal is not related to a particular media stream), an optional signal type (see below), an optional duration, and possibly parameters defined in the package that defines the signal 🧩 This allows a single signal to have some variation in meaning, which means no need to create large numbers of individual signals 🙌
Finally, the optional parameter notifyCompletion lets an MGC say that it wants to be notified when the signal finishes playout 🔔 The possible cases are that the signal timed out (or otherwise completed on its own), that it was interrupted by an event, that it was halted when a Signals descriptor was replaced, or that it stopped or never started for other reasons 🏁 If the notifyCompletion parameter is not included in a Signals descriptor, notification is generated only if the signal stopped or was never started for other reasons. For reporting to occur, the signal completion event (see E.1.2) must be enabled in the currently active Events descriptor 📣
The duration is an integer value that is 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 will stop on its own unless a new Signals descriptor is applied that causes it to stop; no timeout value is needed.
If a signal of default type other than TO has its type overridden to type TO in the Signals descriptor, the duration parameter must be present ⚠️
If the signal type is specified in a SignalsDescriptor, it overrides the default signal type (see 12.1.4). If duration is specified for an on/off signal, it SHALL be ignored 🙈
A sequential signal list consists of a signal list identifier and a sequence of signals to be played sequentially. Only the trailing element of the sequence of signals in a sequential signal list may be an on/off signal. The duration of a sequential signal list is the sum of the durations of the signals it contains 🧵
Multiple signals and sequential signal lists in the same SignalsDescriptor shall be played simultaneously 🎹
Signals are defined as proceeding from the Termination towards the exterior of the Context unless otherwise specified in a package 🧭
When the same Signal is applied to multiple Terminations within one Transaction, the MG should consider using the same resource to generate these Signals 🤔
Production of a Signal on a Termination is stopped by application of a new SignalsDescriptor, or detection of an Event on the Termination (see 7.1.9) 🛑
A new SignalsDescriptor replaces any existing SignalsDescriptor. Any signals applied to the Termination that are not in the replacement descriptor shall be stopped, and new signals are applied, except as follows. Signals present in the replacement descriptor and containing the KeepActive flag shall be continued if they are currently playing and have not already completed 🫶 If a replacement signal descriptor contains a signal that is not 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 specifies the list of descriptors to be returned. Audit may be used in any command to force the return of any descriptor containing the current values of its properties, events, signals and statistics, even if that descriptor was not present in the command or had no underspecified parameters 💫 Possible items in the Audit descriptor are:
ModemMuxEventsMediaSignalsObservedEventsDigitMapStatisticsPackagesEventBuffer
Audit may be empty, in which case no descriptors are returned. This is useful in Subtract, to inhibit return of statistics, especially when using wildcard 🧼
7.1.13. ServiceChange descriptor 🔧
The ServiceChangeDescriptor contains the following parameters:
ServiceChangeMethodServiceChangeReasonServiceChangeAddressServiceChangeDelayServiceChangeProfileServiceChangeVersionServiceChangeMGCIdTimeStampExtension
See 7.2.8 🌷
7.1.14. DigitMap descriptor 📱
7.1.14.1 DigitMap definition, creation, modification and deletion
okay so a DigitMap is basically a dialing plan that lives inside the Media Gateway 📞, and its whole job is to spot and report digit events coming in on a Termination 🎀. The DigitMap descriptor carries a DigitMap name plus the DigitMap being assigned. There are three ways a digit map can show up: management can preload it into the MG and then you reference it by name in an EventsDescriptor 🧚, you can define it dynamically and reference it by name later, or you can just put the actual digit map right inside the EventsDescriptor 💅. Here's the bestie-level tea 🫶: a digit map completion event inside an Events descriptor is totally allowed to point at a DigitMap defined by a DigitMap descriptor in the same command, no matter which order those descriptors were sent in.
DigitMaps defined in a DigitMapDescriptor can show up in any of the standard Termination manipulation Commands of the protocol 🔥. Once it's defined, a DigitMap works on every Termination picked out by the (possibly wildcarded) TerminationID in that command ✨. DigitMaps defined on the root Termination are global 🌍. They can be used on every Termination in the MG, but only if that particular Termination hasn't got its own DigitMap with the same name 💜. When you define one dynamically in a DigitMap descriptor, here's how it goes:
- Making a new one: pick a name that isn't defined yet. The value shall be present.
- Updating: give a new value for a name that's already defined. Terminations already using it keep the old definition 🙈, but any EventsDescriptor that references the name afterwards, including one in the same command as the DigitMap descriptor, uses the new one.
- Deleting: send an empty value for a name that's already defined. Terminations already using it keep the old definition 💀.
7.1.14.2 DigitMap Timers
Digit collection with a DigitMap can be guarded by three timers 🕰️: the start timer (T), the short timer (S), and the long timer (L) ⏱️.
- The start timer (T) runs before any digits have been dialed. If it's overridden with the value zero (
T=0), the start timer gets disabled 🙅, which means the MG will wait indefinitely for digits ♾️. - If the Media Gateway can tell that at least one more digit is needed for a digit string to match any allowed pattern in the digit map, the interdigit timer should be set to a long (L) duration (e.g., 16 seconds) 🐢.
- If the digit string has already matched one of the patterns, but more digits could still turn it into a match with a different pattern, then the MG must apply the short timer (S) and wait for more digits instead of reporting the match straight away 👀.
The timers are configurable parameters of a DigitMap 🎀. Default values of these timers should be provisioned on the MG, but they can be overridden by values specified within the DigitMap.
7.1.14.3 DigitMap Syntax
The formal syntax lives in the DigitMap rule in the formal syntax description of the protocol (see Annex A and Annex B) 📜. A DigitMap, according to this syntax, 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 symbols are the digits "0" through "9" and the letters "A" through a maximum value depending on the signalling system concerned, but never exceeding "K". They correspond to specified events inside a package that was designated in the Events descriptor on the Termination the digit map is being applied to 🦋. (The mapping between events and symbols is defined in the docs 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 that range notation is easy to use 🧠.)
The letter "x" is a wildcard, meaning any event in the range "0"-"9" 🃏. The string can also hold explicit ranges and, more generally, explicit sets of symbols. These are alternative events where any single one satisfies that position in the digit map 🎯. The dot symbol "." means zero or more repetitions of whatever event selector (event, range of events, set of alternative events, or wildcard) comes right before it 🔁. Because of the third timing rule above, inter-event timing while matching a terminal dot symbol uses the short timer by default ⏳.
On top of the event symbols, the string may contain "S" and "L" inter-event timing specifiers and the "Z" duration modifier ✨. "S" and "L" say the MG should use the short (S) timer or the long (L) timer for subsequent events, overriding the timing rules above 💅. 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 that explicit timing specifier must be used 🎀. If all sequences with explicit timing controls get dropped from the candidate set, timing goes back to the default rules 🔄. And if conflicting timing specifiers are in effect in different alternative sequences, the long timer shall be used 🐢.
A "Z" designates a long duration event ⏰. Placed in front of the symbol(s) for the event(s) that satisfy a given digit position, it means that position only counts if the duration of the event exceeds the long-duration threshold. That threshold is assumed to be provisioned in the MG 🧚.
7.1.14.4 DigitMap Completion Event
A digit map is active while the Events descriptor that invoked it is active and it hasn't completed 🌸. 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 be matched through detection of an additional event (unambiguous match); or
- an event has been detected such that a match to a complete alternative event sequence of the digit map will be impossible no matter what additional events are received.
Upon completion, a digit map completion event, as defined in the package providing the events being mapped into the digit map, shall be generated 💖. At that point the digit map is deactivated 🛑. Subsequent events in the package are processed as per the currently active event processing mechanisms ✨.
7.1.14.5 DigitMap Procedures
Pending completion, successive events shall be processed according to these rules 🧩:
- The "current dial string", an internal variable, is initially empty 🫙. The set of candidate alternative event sequences includes all of the alternatives specified 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 specified in 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 any 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 in the current symbol position (because at least one of the candidate alternative event sequences includes the "Z" modifier at this 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 (i.e., the event had long duration and met the specification for this position), then any alternative event sequences not specifying a long duration event at this position are discarded. The current dial string is then modified by inserting a "Z" in front of the symbol representing the latest event ✂️. Any sequence expecting a long-duration event at this position but not matching the observed event is discarded from the candidate set 🗑️. If alternative event sequences not specifying a long duration event in the given position remain in the candidate set after applying the above rules, the observed event duration is treated as irrelevant in assessing matches to them 🤷♀️.
- If exactly one candidate remains and it has been fully matched, a completion event is generated indicating an unambiguous match 🏆. If no candidates remain, the latest event is removed from the current dial string. A completion event is then generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise 🙃. The event removed from the current dial string will then be reported as per the currently active event processing mechanisms 📨.
- If no completion event is reported out of step 5, processing returns to step 2 🔁.
7.1.14.6 DigitMap Activation
A digit map is 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 🚀. The digit map completion event contains an eventDM field in its requested actions field. Each new activation of a digit map begins at step 1 of the above procedure, with a clear current dial string 🧹. Any previous contents of the current dial string from an earlier activation are lost 👋.
A digit map completion event that does not contain aneventDMfield in its requested actions field is considered an error ❌. Upon receipt of such an event in an EventsDescriptor, an MG shall respond with an error response, includingError 457 - Missing parameter in signal or event.
7.1.14.7 Interaction Of DigitMap and Event Processing
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 (e.g., stopping of signals unless the digit completion event has the KeepActive flag enabled) continues to apply to each such event detected, except that 🎀:
- the events in the package containing the specified digit map completion event, other than the completion event itself, are not individually notified and have no side-effects unless separately enabled; and
- an event that triggers a partial match completion event is not recognized and therefore has no side effects until it's reprocessed following the recognition of the digit map completion event 🔄.
7.1.14.8 Wildcards 💖
okay so, if a package has a digit map completion event, then an event spec with a wildcarded ItemID (Property Name) will activate a digit map 🦋. the event spec has to include an eventDM field, following section 7.1.14.6, so it's not optional 🙈. and if the package also has the digit events themselves, this form of event spec makes each individual event get reported to the MGC as it's detected ✨
7.1.14.9 Example 🧚
let's look at a dial plan 📞 here's the whole vibe:
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 from E.6 is used to collect the dialed digits, then that dial plan turns into this digit map 💅
(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)7.1.15 Statistics descriptor 📊
the Statistics descriptor is basically the usage report for a Termination while it lives inside a specific Context 🌸 every Termination keeps a standard set of stats where it makes sense (like the number of octets sent and received, for example). which stats actually get reported depends on the Packages that the Termination realizes ✨
by default, stats get reported when the Termination is Subtracted from the Context. you can override that by putting 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.
stats are cumulative, so reporting them doesn't reset them 💜. they only get reset when a Termination is Subtracted from a Context 🫶
7.1.16 Packages descriptor 🎀
only used with the AuditValue command, the PackageDescriptor returns a list of the Packages the Termination realizes 🍓
7.1.17 ObservedEvents descriptor 👀
ObservedEvents is supplied with the Notify command so the MGC knows which event(s) got detected 🔥 when it's used with AuditValue, the ObservedEventsDescriptor returns the events sitting in the event buffer that haven't been Notified yet.
ObservedEvents carries the RequestIdentifier of the EventsDescriptor that triggered the notification, the event(s) that were detected, optionally the detection time(s), and any parameters of the observed event 🌈 detection times are reported with a precision of hundredths of a second ⏱️
7.1.18 Topology descriptor 🦋
okay this one is so fun 🤩 a Topology descriptor says which way media flows between Terminations in a Context. the tea is that it applies to a Context, not a single Termination, unlike the descriptors before it 💅 by default, every Termination's transmission gets received by all the other Terminations.
the Topology descriptor is optional to implement. if an MG doesn't support it but gets a command containing one, it returns Error 444 Unsupported or unknown descriptor, and can optionally include a string with the name of the unsupported Descriptor ("Topology") in the error text of the error descriptor 😭
the Topology descriptor comes before the commands in an action. you can even have an action with only a Topology descriptor, as long as the Context it applies to already exists ✨
a Topology descriptor is a sequence of triples shaped like (T1, T2, association). T1 and T2 pick out Terminations in the Context, and they can use the ALL or CHOOSE wildcard. the association tells you how media moves between the two:
(T1, T2, isolate)means the Terminations matching T2 don't receive media from the Terminations matching T1, and the other way around either 🚫(T1, T2, oneway)means the Terminations matching T2 receive media from the Terminations matching T1, but not the reverse. in this case, using the ALL wildcard so that some Termination matches both T1 and T2 is not allowed 🙅♀️(T1, T2, bothway)means the Terminations matching T2 receive media from the Terminations matching T1, and vice versa. here it's allowed to use wildcards so that some Termination matches both. but if one does match both, no loopback gets introduced 🔁
CHOOSE wildcards can be used in T1 and T2 too, with these restrictions 🧐
- the action (see clause 8) that the topology descriptor is part of contains 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 🎯 any existing Termination in the Context that matches T1 or T2 gets connected to the newly added Termination, just like the Topology descriptor says.
if a termination isn't mentioned in a Topology Descriptor, whatever topology it had stays the same 💜 but if a new termination gets added to a context, its association with the other terminations defaults to bothway, unless a Topology Descriptor changes that. for example, if T3 gets added to a context with T1 and T2, and the topology is (T3, T1, oneway), then T3 ends up connected bothway to T2 🌷
Figure 7 and the table after it show some examples of what topology descriptors do inside actions. these examples assume the topology descriptors get applied in sequence ✨
+------------------+ +------------------+ +------------------+
| +----+ | | +----+ | | +----+ |
| | T2 | | | | T2 | | | | T2 | |
| +----+ | | +----+ | | +----+ |
| ^ ^ | | ^ | | ^ |
| | | | | | | | | |
| +--+ +--+ | | +---+ | | +--+ |
| | | | | | | | | |
| v v | | v | | | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
1. No Topology Desc. 2. T1, T2, Isolate 3. T3, T2, Oneway
+------------------+ +------------------+ +------------------+
| +----+ | | +----+ | | +----+ |
| | 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
Note: the direction of the arrow indicates the direction of flow.
Figure 7: Example topologies Topology Description
1 No topology descriptors When no topology descriptors are
included, all Terminations have a
bothway connection to all other
Terminations.
2 T1, T2 Isolate Removes the connection between T1 and
T2. T3 has a bothway 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 All Terminations have a bothway
bothway and T1, T3 connection to all other Terminations.
bothway may be implied or
explicit).a oneway connection must be implemented so that the other Terminations in the Context aren't aware of the change in topology 🫣
7.1.19 Error Descriptor 🚨
if a responder runs into an error while it's processing a transaction request, it must include an error descriptor in its response 💥 a Notify request can include one too.
an error descriptor is an IANA-registered error code, optionally with some error text. H.248.8 has the list of valid error codes and what they mean 📚
an error descriptor should be placed at the "deepest level" that makes semantic sense for the error and is still possible given any parsing problems with the original request 🔍 an error descriptor can talk about a syntactical construct that's different from where it appears. for example, Error descriptor 422 - Syntax Error in Action can sit inside a command even though it's describing the bigger thing, the action, and not the specific command it's in 🙃
7.2 Command Application Programming Interface 🎀
here comes the API that describes the protocol's Commands 💻 it's there to show the Commands and their parameters, not to dictate how anything gets implemented (like whether calls block, for example). the input parameters go in parentheses after the command name, and the return values go in front of the Command ✨ this is just for description. the real Command syntax and encoding come in later subclauses 🌸 the order of parameters to commands isn't fixed, and descriptors can show up as parameters in any order. the descriptors SHALL be processed in the order they appear 🫶
any reply to a command may contain an error descriptor, though the API doesn't specifically show that 🙈
all parameters wrapped in square brackets ([. . .]) are optional 🦋
7.2.1 Add 💖
okay so Add is the command that adds a Termination to a Context 🦋 The Termination either gets created, or it gets pulled from the null Context 🧚
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Add( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, EventBufferDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)The TerminationID is the Termination you want added to the Context 🎀 If you use a CHOOSE wildcard in there, the TerminationID that gets picked is the one that comes back to you ✨ Wildcards can be used in an Add, but ngl that would be pretty unusual 🙈 If a wildcard matches more than one TerminationID, every possible match gets attempted, and you get results for each one 💅 The order of those attempts isn't specified, so don't count on any particular order 🌈
The MediaDescriptor is optional, and it describes all the media streams 🎶
The ModemDescriptor and MuxDescriptor are optional too, and they're where you specify a modem and a multiplexer if they 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 too, as if you'd sent separate Add commands for them 🫶 If something goes wrong with one of those implied Adds, error 471 - Implied Add for Multiplex failure shall be returned, and the rest of the command shall cease processing 😭
The EventsDescriptor is optional 🔔 When it's there, it gives the list of events that should be detected on the Termination ✨
The EventBufferDescriptor is optional as well 🧺 When it's there, it gives the list of events the MG is asked to detect and buffer, but only when EventBufferControl equals LockStep 💜
The SignalsDescriptor is optional 🚨 When it's there, it gives the list of signals that should be applied to the Termination 🌸
The DigitMapDescriptor is optional too 🔢 When it's there, it defines a DigitMap definition that can be used in an EventsDescriptor 🍓
The AuditDescriptor is optional 🔍 If you include it, the command returns whatever descriptors it asks for ⭐
Every descriptor that can be modified might come back from the MG if a parameter was underspecified or overspecified 🙃 ObservedEvents, Statistics, Packages, and the EventBuffer descriptors only come back if you request them in the AuditDescriptor 📋
Add SHALL NOT be used on a Termination with a serviceState of "OutofService". Not on an out-of-service Termination, bestie 🚫💀
7.2.2 Modify 🛠️
Modify is the command that changes the properties of a Termination 💅
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Modify( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, EventBufferDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)The TerminationID can be specific if you're only modifying one Termination in the Context 🎯 Wildcards in the TerminationID might be appropriate for some operations 🌟 If a wildcard matches more than one TerminationID, all possible matches get attempted, and results come back for each one 🦋 The order of attempts isn't specified when several TerminationIDs match 🌀 Using CHOOSE is an error, because Modify can only be used on Terminations that already exist 🙅♀️
For convenience, if a Multiplex Descriptor is in a Modify command, then:
- if the new Multiplex Descriptor lists any Terminations that aren't in the Context yet, those Terminations get added to the Context, as if you'd sent separate commands listing them ✨
- if any Terminations that were listed earlier in the Multiplex Descriptor aren't in the new one anymore, they get subtracted from the Context, as if you'd sent separate Subtract commands listing them 👋
The remaining parameters to Modify are the same as the ones for Add 🎀 Modify's possible return values are the same as Add's too 💖
7.2.3 Subtract 🧹
Subtract is the command that disconnects a Termination from its Context and returns statistics about how that Termination participated in the Context 📊
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Subtract(TerminationID
[, AuditDescriptor]
)TerminationID in the input parameters is the Termination being subtracted 💫 The TerminationID can be specific, or it can be a wildcard that means all (or a set of related) Terminations in the Context of the Subtract command get subtracted 🧺 If the wildcard matches more than one TerminationID, all possible matches get attempted, with results reported for each one 🌈 The order of attempts when multiple TerminationIDs match isn't specified 🤷♀️
Using CHOOSE in the TerminationID is an error, since Subtract can only be used on Terminations that already exist 🚫
ALL can be used as the ContextID as well as the TerminationId in a Subtract 💥 That has the effect of deleting all Contexts, deleting all ephemeral Terminations, and returning all physical Terminations to the Null Context 🌍 Subtracting a Termination from the Null Context is not allowed 🙅♀️
For convenience, if a multiplexing Termination is the object of a Subtract command, then any bearer Terminations listed in its Multiplex Descriptor get subtracted from the Context too, as if you'd sent separate Subtract commands listing them 🫧
By default, the Statistics parameter comes back to report information collected on the Termination or Terminations named in the Command 📈 The information reported applies to how long the Termination (or Terminations) existed in the Context it's being subtracted from 🕰️
The AuditDescriptor is optional 🔎 If you include it, the command returns only the descriptors it specifies, and that list is allowed to be empty 🫥 If you leave it out, the Statistics descriptor comes back by default 💜 Possible return values are the same as Add's 💖
When a provisioned Termination is Subtracted from a Context, its property values shall revert to:
- the default value, if one is specified for the property and it isn't overridden by provisioning;
- otherwise, the provisioned value.
7.2.4 Move 🦋
Move is the command that moves a Termination to another Context from its current Context, all in one atomic operation ⚛️ Move is the only command that refers to a Termination in a Context that's different from the one the command is applied to 🌉 Move shall not be used to move Terminations to or from the null Context 🙅♀️
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Move( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, EventBufferDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)The TerminationID specifies the Termination to be moved 🎯 It can be wildcarded, but CHOOSE shall not be used in the TerminationID 🙈 If a wildcard matches more than one TerminationID, all possible matches get attempted, with results reported for each one 💅 The order of attempts when multiple TerminationIDs match isn't specified 🤷♀️ The Context the Termination moves to is indicated by the target ContextId in the Action 🎀 If the last remaining Termination gets moved out of a Context, that Context gets deleted 💀
The Move command doesn't change the properties of the Termination it operates on, except for those properties that are explicitly modified by descriptors included in the Move command 🧩 The AuditDescriptor with the Statistics option, for example, would return statistics on the Termination just before the Move 📊 Possible descriptors returned from Move are the same as the ones for Add 💖
For convenience, if a multiplexing Termination is the object of a Move command, then any bearer Terminations listed in its Multiplex Descriptor also get moved, as if you'd sent separate Move commands listing them 🫶
Move SHALL NOT be used on a Termination with a serviceState of "OutofService". Same energy as Add, no moving the out-of-service ones 🚫😭
7.2.5 AuditValue ✨
okay bestie, AuditValue is the command that returns the current values of properties, events, signals and statistics on Terminations 👀🎀 it's giving "show me what you're doing right now" energy 💅
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
AuditValue(TerminationID,
AuditDescriptor
)TerminationID can be specific or wildcarded 🌸 if the wildcard matches more than one TerminationID, all the possible matches get attempted, and results come back for each one. the order of attempts when multiple TerminationIDs match is not specified, so don't build your whole life around it 🙈 if you ask for a wildcarded response, you only get ONE command return, and its contents are the union of the values of all the matching Terminations. this is lowkey a huge vibe because it cuts down on the volume of data you need to audit a whole group of Terminations 🫶 and using CHOOSE is an error 🙅♀️
the right descriptors come back with the current values for the Termination. if a value shows up in multiple instances of a descriptor, that means they're alternate values supported 🦋 and each parameter in a descriptor is considered independent, so they don't affect each other ✨
ObservedEvents returns a list of events in the EventBuffer 🍓 and if you audit the ObservedEventsDescriptor while a DigitMap is active, the ObservedEvents descriptor also includes a digit map completion event. that event shows the current dial string, but it does NOT show a Termination method 🧚
EventBuffer returns the set of events and their associated parameter values that are currently enabled in the EventBufferDescriptor 💜 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, iconic 👑 Statistics returns the current values of all statistics being kept on the Termination 📊
if you send an empty Audit descriptor, you only get the TerminationID back 🌈 that's actually useful for getting a list of TerminationIDs when you're using a wildcard. Annexes A and B give you a special syntax for presenting that kind of list in condensed form, so the AuditValue command tag doesn't have to be repeated for every single TerminationID 💖
AuditValue results depend on the Context, which can be specific, null, or wildcarded. (fyi, ContextID ALL does NOT include the null Context 🙈) the TerminationID can be specific or wildcarded too 🦋
here are some examples of what comes back when the context and/or the termination is wildcarded and a wildcarded response has been requested ✨
say the gateway has 4 terminations: t1/1, t1/2, t2/1 and t2/2. say terminations t1/* have implemented packages aaa and bbb, and terminations t2/* have implemented packages ccc and ddd. say Context 1 has t1/1 and t2/1 in it, and Context 2 has t1/2 and t2/2 in it 💅
the command:
Context=1{AuditValue=t1/1{Audit{Packages}}}returns:
Context=1{AuditValue=t1/1{Packages{aaa,bbb}}}the command:
Context=*{AuditValue=t2/*{Audit{Packages}}}returns:
Context=1{AuditValue=t2/1{Packages{ccc,ddd}}},
Context=2{AuditValue=t2/2{Packages{ccc,ddd}}}the command:
Context=*{W-AuditValue=t1/*{Audit{Packages}}}returns:
Context=*{W-AuditValue=t1/*{Packages{aaa,bbb}}}Note: a wildcard response can also be used for other commands, like Subtract 👀
here's the other info you can get with AuditValue 🎀
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 ContextIds (the ContextID list
should be returned by using multiple action
replies, each containing a ContextID from
the list)
All Specific (Non-null) ContextID in which the
Termination currently exists7.2.6 AuditCapabilities 🦋
AuditCapabilities is the sibling command 🧚 it returns the possible values of properties, events, signals and statistics on Terminations, so it's more like "what COULD you do?" instead of "what are you doing?" 💜
TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
AuditCapabilities(TerminationID,
AuditDescriptor
)the right descriptors come back with the possible values for the Termination 🌸 descriptors can be repeated where there are multiple possible values. same deal as before: if you ask for a wildcarded response, you get ONE command return, with the union of the values of all matching Terminations, which keeps the data volume down 🫶
the way you interpret which capabilities are requested for different ContextID and TerminationID values is the same as in AuditValue ✨
the EventsDescriptor returns the list of possible events on the Termination, along with the list of all possible values for the EventsDescriptor Parameters 🔥 EventBufferDescriptor returns the same info as EventsDescriptor 💅 the SignalsDescriptor returns the list of possible signals that could be applied to the Termination, plus 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 🍓 and DigitMap and Packages are NOT legal in AuditCapability 🙅♀️
here's what else you can get with the AuditCapabilties Command 🎀
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 MG 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 Same as for AuditValue
All Specific Same as for AuditValue7.2.7 Notify 📣
Notify is how the Media Gateway tells the Media Gateway Controller that something happened inside the Media Gateway 🔥 it's the gateway literally raising its hand like "bestie, look at this" 🙋♀️
TerminationID
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 the Media Gateway detected, in the order they were detected ✨ each event in the list comes with its associated parameters, and optionally an indication of the time the event 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 only occur as the result of detecting an event specified by an Events descriptor that's active on the Termination concerned 🦋
the RequestID returns the RequestID parameter of the EventsDescriptor that triggered the Notify Command 🎀 it's how you match the notification back to the request that set it off, iykyk 💅 the events in the list must have been requested via the triggering EventsDescriptor or an embedded events descriptor, unless the RequestID is 0 (which, again, is for further study 🙈)
the ErrorDescriptor may be sent in the Notify Command as a result of Error 518 - Event buffer full 🚨 respect the buffer, periodt 💜
7.2.8 ServiceChange ✨
okay so ServiceChange is the command where the Media Gateway pings its Media Gateway Controller bestie to say 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. The MG MAY tell the MGC that a Termination's capability has changed. And it's how an MGC hands over control of an MG to a different MGC 💅
TerminationID,
[ServiceChangeDescriptor]
ServiceChange ( TerminationID,
ServiceChangeDescriptor
)The TerminationID parameter says which Termination(s) get taken out of or returned to service 🎀 Wildcarding Termination names is allowed, but the CHOOSE mechanism SHALL NOT be used. Using the "Root" TerminationID means the ServiceChange is about the entire Media Gateway 👑
The ServiceChangeDescriptor holds these parameters, as required:
- ServiceChangeMethod
- ServiceChangeReason
- ServiceChangeDelay
- ServiceChangeAddress
- ServiceChangeProfile
- ServiceChangeVersion
- ServiceChangeMgcId
- TimeStamp
The ServiceChangeMethod tells you what kind of ServiceChange will happen (or already did) 🌈
- Graceful - the Terminations will be taken out of service after the ServiceChangeDelay. Established connections aren't affected yet, but the MGC SHOULD refrain from setting up new connections and SHOULD attempt to gently tear down the existing ones on the affected Termination(s). The MG SHOULD set the Termination serviceState to
"out of service"when the ServiceChangeDelay expires 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 may be lost 😭 For non-Root terminations, 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". For the root termination, the MGC can assume all connections on the MG are lost, so it can treat all the terminations as subtracted. - Restart - service is coming back on the specified Terminations once the ServiceChangeDelay runs out. The serviceState SHOULD be set to
"inService"when the ServiceChangeDelay expires. - Disconnected - always used with the Root TerminationID. It means the MG lost contact with the MGC but got reconnected to that same MGC (maybe after trying other MGCs on a pre-provisioned list). Since the MG's state may have changed, the MGC may wish to use the Audit command to resync its state with the MG's 🙈
- Handoff - sent from the MGC to the MG, this means the MGC is going out of service and a new MGC association has to be set up. 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 the MGC it was previously associated with 🦋
- Failover - sent from the MG to the MGC to say the primary MG is out of service and a secondary MG is taking over. This method is also sent from the MG to the MGC when the MG notices the MGC has failed 💔
- Another value - whose meaning both the MG and the MGC understand.
The ServiceChangeReason says why the ServiceChange has happened (or will). It's made of an alphanumeric token (IANA registered) and, optionally, an explanatory string 📝
The optional ServiceChangeAddress is the address (like an IP port number for IP networks) to use for later communications. It can show up in the input parameter descriptor or the returned result descriptor. ServiceChangeAddress and ServiceChangeMgcId MUST NOT both be present in the ServiceChangeDescriptor or the ServiceChangeResultDescriptor. ServiceChangeAddress gives an address to use within the Context of the association being negotiated right now, while ServiceChangeMgcId gives an alternate address where the MG should try to set up another association. Note that the use of ServiceChangeAddress is not encouraged 🙃 MGCs and MGs MUST be able to cope with ServiceChangeAddress being either a full address or just a port number when TCP transports are used.
The optional ServiceChangeDelay is measured in seconds 🍓 If the delay is absent or set to zero, the delay value SHOULD be considered null. For a "graceful" ServiceChangeMethod, a null delay means the MGC SHOULD wait for the existing connections to naturally go away and SHOULD NOT set up new connections. For "graceful" only, 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 says which Profile (if any) of the protocol is supported. It includes the version of that Profile.
The optional ServiceChangeVersion holds the protocol version and gets used if protocol version negotiation happens (see 11.3) ✨
The optional TimeStamp is the actual time as kept by the sender. It's not necessarily absolute time (like your local time zone). It just sets an arbitrary starting point that all future timestamps the sender transmits during this association SHALL be compared against. The responder can use it to figure out how far its clock is from its correspondent's. TimeStamp is sent with a precision of hundredths of a second ⏰
The optional Extension parameter MAY contain any value whose meaning is mutually understood by the MG and MGC 🧚
Okay, the registration moment is so important 🌸 A ServiceChange Command that specifies "Root" for the TerminationID and a ServiceChangeMethod of Restart is a registration command. It's how a Media Gateway announces its existence to the Media Gateway Controller. The MG MAY also send a registration command by specifying "Root" for the TerminationID and a ServiceChangeMethod of Failover when the MG detects MGC failures. The MG is expected to be provisioned with the name of one primary Media Gateway Controller and optionally some number of alternate ones. Acknowledging the ServiceChange Command finishes the registration process, except when the MGC has returned an alternative ServiceChangeMgcId, as described in the following paragraph. The MG MAY specify the transport ServiceChangeAddress that the MGC should use for sending messages, in the ServiceChangeAddress parameter of the input ServiceChangeDescriptor. The MG MAY specify an address in the ServiceChangeAddress parameter of the ServiceChange request, and the MGC MAY also do so in the ServiceChange reply. Either way, the recipient MUST use the supplied address as the destination for all later transaction requests within the association. At the same time, as indicated in clause 9, transaction replies and pending indications MUST be sent to the address the corresponding 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 parameter that describes the Media Gateway Controller that 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. The MGC specified in a ServiceChangeMgcId, if one is given, SHALL be contacted before any further alternate MGCs. On a HandOff message from MGC to MG, the ServiceChangeMgcId is the new MGC that will take over from the current MGC.
The return from ServiceChange is empty, except when the Root terminationID is used. In that case, it includes these parameters, as required:
- ServiceChangeAddress, if the responding MGC wants to specify a new destination for messages from the MG for the rest of the association;
- ServiceChangeMgcId, if the responding MGC does not want to keep 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 version of the protocol used for the association.
The following ServiceChangeReasons are defined. This list MAY be extended through an IANA registration, as outlined in 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 ✨
okay so everything we just covered in the commands 🦋 applies to Terminations. this bit is about how Contexts get manipulated and audited, aka how you poke at a Context's attributes 💅
Commands are grouped into actions (see clause 8) 🌸. An action applies to one Context. On top of commands, an action can also carry Context manipulation and auditing instructions 🎀.
An action request sent to a MG may include a request to audit 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 used to return information to a MGC 🫶. That can be the stuff an audit of Context attributes asked for, or the details of what happened when a Context got manipulated 👑.
If a MG receives an action which contains both a request to audit context attributes and a request to manipulate those attributes, the response SHALL include the values of the attributes after processing the manipulation request. ✨ this is the main character moment: audit AND manipulate in the same action and the reply shows you the post-manipulation values 😭
7.2.10 Generic Command Syntax
okay 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 the encoding of the Local and Remote descriptors for use with the binary format 💜.
a complete ABNF of the text encoding of the protocol per RFC 2234 is given in Annex B 📜. SDP is used as the encoding of the Local and Remote descriptors for use with the text encoding as modified in 7.1.8 💅.
7.3 Command Error Codes
errors come as an IANA registered error code plus an explanatory string 🚨. Sending the explanatory string is optional 🙈. Implementations are encouraged to append diagnostic information to the end of the string 🔥.
When a MG reports an error to a MGC, it does so in an error descriptor 💀. An error descriptor consists of an error code and optionally the associated explanatory string 🎀.
H.248.8 contains the error codes supported by Recommendations in the H.248 sub-series 📚.
8. Transactions 🦋
Commands between the Media Gateway Controller and the Media Gateway are grouped into Transactions, each of which is identified by a TransactionID 🫶. Transactions consist of one or more Actions. An Action consists of a non-empty series of Commands, Context property modifications, or Context property audits that are limited to operating within a single Context 💖. Consequently, each Action typically specifies a ContextID 🌸. However, there are two circumstances where a specific ContextID is not provided with an Action. One is the case of modification of a Termination outside of a Context. The other is where the controller requests the gateway to create a new Context 🧚. Figure 8 is a graphic representation of the Transaction, Action and Command relationships 🖼️.
+----------------------------------------------------------+
| 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 8: Transactions, Actions and Commands 📊
Transactions are presented as TransactionRequests. Corresponding responses to a TransactionRequest are received in a single reply, possibly preceded by a number of TransactionPending messages (see 8.2.3) 💌.
Transactions guarantee ordered Command processing 🔒. That is, Commands within a Transaction are executed sequentially 🎯. Ordering of Transactions is NOT guaranteed - transactions may be executed in any order, or simultaneously 🌀.
At the first failing Command in a Transaction, processing of the remaining Commands in that Transaction stops 🛑. If a command contains a wildcarded TerminationID, the command is attempted with each of the actual TerminationIDs matching the wildcard 🃏. A response within the TransactionReply is included for each matching TerminationID, even if one or more instances generated an error 💅. If any TerminationID matching a wildcard results in an error when executed, any commands following the wildcarded command are not attempted 😤.
Commands may be marked as "Optional" which can override this behaviour - if a command marked as Optional results in an error, subsequent commands in the Transaction will be executed 🪄. If a command fails, the MG shall as far as possible restore the state that existed prior to the attempted execution of the command before continuing with command processing 🔄.
A TransactionReply includes the results for all of the Commands in the corresponding TransactionRequest 📬. The TransactionReply includes the return values for the Commands that were executed successfully, and the Command and error descriptor for any Command that failed 💔.
TransactionPending is used to periodically notify the receiver that a Transaction has not completed yet, but is actively being processed ⏳.
Applications SHOULD implement an application level timer per transaction ⏰. Expiration of the timer should cause a retransmission of the request. Receipt of a Reply should cancel the timer. Receipt of Pending should restart the timer 🔁.
8.1 Common parameters
8.1.1 Transaction Identifiers
Transactions are identified by a TransactionID, which is assigned by sender and is unique within the scope of the sender 🪪. A response containing an error descriptor to indicate that the TransactionID is missing in a request shall use TransactionID 0 in the corresponding TransactionReply 🙈.
8.1.2 Context Identifiers
Contexts are identified by a ContextID, which is assigned by the Media Gateway and is unique within the scope of the Media Gateway 🏷️. The Media Gateway Controller shall use the ContextID supplied by the Media Gateway in all subsequent Transactions relating to that Context 🫶. The protocol makes reference to a distinguished value that may be used by the Media Gateway Controller when referring to a Termination that is currently not associated with a Context, namely the null ContextID 🌙.
The CHOOSE wildcard is used to request that the Media Gateway create a new Context 🎲.
The MGC may use the ALL wildcard to address all Contexts on the MG 🌍. The null Context is not included when the ALL wildcard is used 🚫.
The MGC shall not use partially specified ContextIDs containing the CHOOSE or ALL wildcards 🙅.
8.2 Transaction Application Programming Interface
Following is an Application Programming Interface (API) describing the Transactions of the protocol 🧩. This API is shown to illustrate the Transactions and their parameters and is not intended to specify implementation (e.g., via use of blocking function calls). It will describe the input parameters and return values expected to be used by the various Transactions of the protocol from a very high level. Transaction syntax and encodings are specified in later subclauses 🎀.
8.2.1 TransactionRequest
The TransactionRequest is invoked by the sender. There is one Transaction per request invocation. A request contains one or more Actions, each of which specifies its target Context and one or more Commands per Context 📮.
TransactionRequest(TransactionId {
ContextID {Command ... Command},
. . .
ContextID {Command ... Command } })The TransactionID parameter must specify a value for later correlation with the TransactionReply or TransactionPending response from the receiver 🔑. The ContextID parameter must specify a value to pertain to all Commands that follow up to either the next specification of a ContextID parameter or the end of the TransactionRequest, whichever comes first 🧵. The Command parameter represents one of the Commands mentioned in 7.2 (Command Application Programming Interface) 💫.
8.2.2 TransactionReply ✨
Okay bestie, the TransactionReply is invoked by the receiver 💌 and there's exactly one reply per transaction. Each reply has one or more Actions, and every Action MUST specify its target Context plus one or more Responses per Context. The responder sends it once it has processed the TransactionRequest 🎀
So when is a TransactionRequest considered processed? 🤔
- when all actions in that TransactionRequest have been processed; or
- when an error is encountered in processing that TransactionRequest, except when the error is in an optional command.
A command is processed once all of its descriptors are processed 🧚
A SignalsDescriptor counts as processed once it's been established that the descriptor is syntactically valid, the requested signals are supported, and they've been queued to be applied 💜
An EventsDescriptor or EventBufferDescriptor is processed once it's been established that the descriptor is syntactically valid, the requested events can be observed, any embedded signals can be generated, any embedded events can be detected, and the MG has been brought into a state where the events will be detected 👑
TransactionReply(TransactionID {
ContextID { Response ... Response },
. . .
ContextID { Response ... Response } })The TransactionID parameter MUST be the same as that of the corresponding TransactionRequest 🦋
The ContextID parameter MUST specify a value that pertains to all Responses for the action. The ContextID MAY be specific, all or null 🌸
Each of the Response parameters represents a return value as mentioned in 7.2, or an error descriptor if the command execution hit an error. Commands after the point of failure are NOT processed, so no Responses get issued for them 💀
Heads up: if a command was marked as optional in the Transaction request and it generates an error, the transaction still keeps going. In that case the Reply would have Responses after an Error. Iconic plot twist 😭
Section 7.1.19 Error Descriptor specifies how error descriptors get generated. The bits below talk through a few specific cases 🍓
If the receiver hits an error while processing a ContextID, the requested Action response will consist of the Context ID and a single error descriptor, 422 - Syntax Error in Action ✨
If the receiver hits an error so bad that it can't determine a legal Action, it returns a TransactionReply made of the TransactionID and a single error descriptor, 422 - Syntax Error in Action. If the end of an action can't be reliably determined but one or more commands can be parsed, it processes them and then sends 422 - Syntax Error in Action as the last action for the transaction 🙈 If the receiver hits an error so bad that it can't determine a legal Transaction, it returns a TransactionReply with a null TransactionID and a single error descriptor (403 - Syntax Error in TransactionRequest) 💅
If the end of a transaction can't be reliably determined and one or more Actions can be parsed, it processes them and then returns 403 - Syntax Error in Transaction as the last action reply for the transaction. If no Actions can be parsed, it returns 403 - Syntax Error in TransactionRequest as the only reply 🫶
If the terminationID can't be reliably determined, it sends 442 - Syntax Error in Command as the action reply 🌈
If the end of a command can't be reliably determined, it returns 442 - Syntax Error in Command as the reply to the last action it can parse 😭
8.2.3 TransactionPending 🦋
The receiver invokes the TransactionPending. A TransactionPending says the Transaction is actively being processed but isn't completed 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 that of the corresponding TransactionRequest. There's a property of root (normalMGExecutionTime) that the MGC can set to tell the MG the interval within which the MGC expects a response to any transaction from the MG. Another property (normalMGCExecutionTime) is settable by the MGC to show the interval within which the MG SHOULD expect a response to any transaction from the MGC 💖 Senders may receive more than one TransactionPending for a command. If a duplicate request arrives while the responder is pending, the responder MAY send a duplicate pending immediately, or keep waiting for its timer to trigger another TransactionPending 🌸
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 🧚 An H.248.1 entity (MG/MGC) MUST consistently use the same MID in all messages it originates for the duration of the control association with the peer (MGC/MG) 👑
Every Message contains a Version Number that says which version of the protocol it follows. Versions are one or two digits long, starting at 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. A message is basically just a transport mechanism 🦋 For example, message X containing transaction requests A, B, and C may get answered with message Y containing replies to A and C, plus message Z containing the reply to B. Likewise, message L containing request D and message M containing request E may get answered with message N containing replies to both D and E 🌈
9. Transport 🚚✨
okay bestie, transport time! 🦋 The transport mechanism should allow the reliable transport of transactions between a MGC and MG. It has to stay totally independent of which commands are being sent, and it has to be applicable to all application states 💅 There are several transports defined for the protocol. They live in the Annexes to this RFC and in other Recommendations of the H.248 sub-series. More transports can be defined later as additional Recommendations of the H.248 sub-series 🌸
For transport over IP, MGCs shall implement both TCP and UDP/ALF, and a MG shall implement TCP or UDP/ALF or both. 🫶
The MG gets provisioned with a name or address (like a DNS name or IP address) for a primary MGC and zero or more secondary MGCs (see 7.2.8). That's the address the MG uses to send messages to the MGC 📮 If TCP or UDP is the protocol transport and the port for the initial ServiceChange request isn't otherwise known, that request should be sent to the default port number for the protocol. That port is 2944 for text-encoded operation or 2945 for binary-encoded operation, for either UDP or TCP 🎀 The MGC gets the message with the ServiceChange request from the MG and can work out the MG's address from it 🔍
As described in 7.2.8, either the MG or the MGC may supply an address in the ServiceChangeAddress parameter. That's where subsequent transaction requests must be addressed. 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 🧚 For example, in IP networks, that's the source address in the IP header and the source port number in the TCP/UDP/SCTP header. Iconic routing behaviour, honestly 💜
9.1. Ordering of Commands
okay so this part is lowkey important 🧐 This RFC does not require the underlying transport protocol to guarantee the sequencing of transactions sent to an entity. That property tends to maximise the timeliness of actions, but it does come with 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 can use the following rules 📋 These rules are about commands that are in different transactions. Commands in the same transaction are executed in order (see clause 8), so no drama there ✨
- When a Media Gateway handles several Terminations, commands for the different Terminations may be sent in parallel. Think of 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 (
AddorModifyorMove), unless the outstanding commands are in the same transaction. However, aSubtractcommand may be issued at any time. So a Media Gateway may sometimes receive aModifycommand that applies to a previously subtracted Termination. Such commands should be ignored, and an error code should be returned 🙈 - For transports that do not guarantee in-sequence delivery of messages (i.e., UDP), there should normally be on a given Termination at most one outstanding
Notifycommand at any time. - In some cases, an implicitly or explicitly wildcarded
Subtractcommand that applies to a group of Terminations may step in front of a pendingAddcommand. The Media Gateway Controller should individually delete all Terminations for which anAddcommand was pending at the time of the globalSubtractcommand. Also, newAddcommands for Terminations named by the wildcarding (or implied in a Multiplex descriptor) should not be sent until the wildcardedSubtractcommand is acknowledged 🫠 AuditValueandAuditCapabilityare not subject to any sequencing. Chill vibes only 🌈ServiceChangeshall always be the first command sent by a MG as defined by the restart procedure. Any other command or response must be delivered after thisServiceChangecommand. Main character rule, no exceptions 👑
These rules do not affect the command responder, which should always respond to commands. Responders are always ready to reply, no matter what 💖
9.2. Protection against Restart Avalanche
ngl this is giving "don't all show up at the party at the same time" energy 🥳 If a huge number of Media Gateways get powered on at once and they all start a ServiceChange transaction, the Media Gateway Controller would very likely get swamped. That means message losses and network congestion right when service is coming back, which is the worst possible time 😭 To prevent these avalanches, the following behaviour is suggested:
- When a Media Gateway is powered on, it should start a restart timer set to a random value, uniformly distributed between 0 and a maximum waiting delay (MWD). Care should be taken to avoid synchronicity of the random number generation between multiple Media Gateways that would use the same algorithm 🎲
- The Media Gateway should then wait for either the end of this timer 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 basically just requires the MG to guarantee that the first message the Media Gateway Controller sees from it is a ServiceChange message telling the MGC about the restart. Simple, but so important 🫶
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.
Media Gateway Controllers are typically dimensioned to handle the peak hour traffic load, when on average 10% of the lines will be busy, placing calls whose average duration is typically 3 minutes 📊 Processing a call typically involves 5 to 6 Media Gateway Controller transactions between each Media Gateway and the Media Gateway Controller. So this simple maths shows that the Media Gateway Controller is expected to handle 5 to 6 transactions for each Termination every 30 minutes on average. Or, to put it otherwise, 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. Without explicit configuration, residential gateways should adopt a value of 600 seconds for MWD ⏰
The same reasoning suggests that the value of MWD should be much shorter for trunking gateways or business gateways. They handle a large 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 Media Gateway Controller load. A reasonable algorithm is to make the value of 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 clause covers security when using the protocol in an IP environment. Buckle up, this part is serious bestie 🙈
10.1. Protection of Protocol Connections
A security mechanism is clearly needed to stop unauthorized entities from using the protocol defined in this RFC to set up unauthorized calls or to interfere with authorized calls 🚫 The security mechanism for the protocol when it's transported over IP networks is IPsec [RFC 2401 to RFC 2411]. Protect the vibes 🛡️
The AH header [RFC 2402] affords data origin authentication, connectionless integrity and optional anti-replay protection of messages passed between the MG and the MGC. The ESP header [RFC 2406] provides confidentiality of messages, if desired. 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 RFC employing the ESP header SHALL comply with section 5 of [RFC 2406], which defines a minimum set of algorithms for integrity checking and encryption. Similarly, implementations employing the AH header SHALL comply with section 5 of [RFC 2402], which defines a minimum set of algorithms for integrity checking using manual keys 🧾
Implementations SHOULD use IKE [RFC 2409] to permit more robust keying options. Implementations employing IKE SHOULD support authentication with RSA signatures and RSA public key encryption 🔐✨
10.2. Interim AH scheme
Implementation of IPsec requires that the AH or ESP header be inserted immediately after the IP header. This can't really be done easily at the application level 😩 So this creates a deployment problem for the protocol defined in this RFC where the underlying network implementation doesn't support IPsec.
As an interim solution, an optional AH header is defined within the H.248.1 protocol header. The header fields are exactly those of the SPI, SEQUENCE NUMBER and DATA fields as defined in [RFC 2402]. The semantics of the header fields are the same as the "transport mode" of [RFC 2402], except for the calculation of the Integrity Check Value (ICV) 🧩 In IPsec, the ICV is calculated over the entire IP packet, including the IP header. That's what prevents spoofing of the IP addresses. To keep the same functionality, the ICV calculation should be performed across all the transactions (concatenated) in the message, prepended by a synthesized IP header. That header consists of a 32-bit source IP address, a 32-bit destination address and a 16-bit UDP destination port encoded as 20 hex digits. When the interim AH mechanism is employed with TCP as the transport Layer, the UDP Port above becomes the TCP port, and all other operations are the same 🌸
Implementations of the H.248.1 protocol SHALL implement IPsec where the underlying operating system and the transport network supports 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 RFC 2402, which defines a minimum set of algorithms for integrity checking using manual keys 🧾
The interim AH interim scheme does not provide protection against eavesdropping, which means it doesn't stop third parties from monitoring the connections set up by a given Termination 👀 It also doesn't provide protection against replay attacks. These procedures do not necessarily protect against denial of service attacks by misbehaving MGs or misbehaving MGCs. However, they will provide an identification of these misbehaving entities, which should then be deprived of their authorization through maintenance procedures 🚨
10.3. Protection of Media Connections ✨
okay so the protocol lets the MGC hand MGs little "session keys" 🔑 so they can encrypt the audio messages, which keeps eavesdroppers 👀 out of the call. bestie, we need that.
the problem with packet networks is "uncontrolled barge-in" 😭 an attacker just sends media packets to the IP address and UDP port a connection is using, and if nothing protects it, those packets MUST be decompressed and the signals MUST be played on the "line side". that's chaotic.
the basic defense is to only accept packets from sources we already know, like checking that the IP source address and UDP source port match the values announced in the Remote descriptor 🎀 lowkey good, but it has two problems:
- to turn on address-based protection, the MGC MUST get the remote session description of the egress MG and pass it to the ingress MG. that takes at least one network round trip, so you're stuck in a dilemma 💀 either let the call go ahead without waiting and risk something like "clipping" a remote announcement, or wait the full round trip and accept slower call set-up.
- source spoofing only works if the attacker can get valid pairs of source destination addresses and ports, like by listening to some of the traffic 🙈 to stop that, you could try controlling every access point to the network, but that's honestly very hard to pull off in practice.
the alternative is to encrypt and authenticate the packets with a secret key that gets shared during call set-up 🫶 this doesn't slow down call set-up, and it gives strong protection against address spoofing. iconic, really.
11. MG-MGC Control Interface 🦋
the control association between an MG and an MGC starts at MG cold start and gets announced by a ServiceChange message 🌸 but it can change later because of things like failures or manual service events. the protocol doesn't have an explicit way for multiple MGCs to control one physical MG, BUT it was built to support multiple logical MGs inside a single physical MG, and those can be tied to different MGCs. so it's giving flexibility 💅
11.1. Multiple Virtual MGs 🧚
a physical Media Gateway can be split into one or more Virtual MGs. a virtual MG is made up 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 assigned to virtual MGs is a management method that sits outside the scope of the protocol. each virtual MG looks like a complete MG client to the MGC, which is so iconic 👑
a physical MG MAY have only one network interface, and that interface MUST be shared across virtual MGs. when that happens, the packet/cell side Termination is shared. it's worth noting that these interfaces need an ephemeral instance of the Termination for each flow, so sharing the Termination is actually pretty straightforward. the tricky bit is that the MG MUST always know which of its controlling MGCs SHOULD be notified when an event happens on the interface 😭
in normal operation, the Virtual MG gets 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), so no confusion comes up. but if something unexpected happens, the Virtual MG MUST know what to do with the physical resources it's controlling 💖
if recovering from the event means changing a physical interface's state, only one MGC SHOULD do that. the way this gets handled is that any of the MGCs can create EventsDescriptors to get notified about these events, but only one MGC can have read/write access to the physical interface properties, and every other MGC gets read-only access 🍓 the management mechanism picks which MGC gets read/write capability, and that one is called the Master MGC 👑
each virtual MG has its own Root Termination. most of the time, the values for the Root Termination's properties can be set independently by each MGC. where there can only be one value, the parameter is read-only for everyone except the Master MGC.
ServiceChange MAY ONLY be applied to a Termination or set of Terminations that's partitioned to the Virtual MG, or that was created (for ephemeral Terminations) by that Virtual MG. boundaries, bestie 🫶
11.2. Cold start 🌈
an MG is pre-provisioned by a management mechanism outside the scope of this protocol with a primary MGC and (optionally) an ordered list of secondary MGCs. when the MG cold starts, it issues a ServiceChange command with a "Restart" method on the Root Termination to its primary MGC. if the MGC accepts the MG, it sends back a Transaction Reply that does NOT include a ServiceChangeMgcId parameter. if the MGC doesn't accept the MG's registration, it sends a Transaction Reply that gives the address of an alternate MGC to contact, by including a ServiceChangeMgcId parameter ✨
if the MG gets a Transaction Reply that includes a ServiceChangeMgcId parameter, it sends a ServiceChange to the MGC named in ServiceChangeMgcId. it keeps doing this until it gets a controlling MGC to accept its registration, or until it fails to get a reply. if it can't get a 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 set up a control relationship with any MGC, it SHALL wait a random amount of time as described in 9.2 and then start contacting its primary and, if needed, its secondary MGCs again 😩
it's possible the reply to a ServiceChange with Restart gets lost, and then a command shows up at the MG before the ServiceChange response arrives. in that case, the MG SHALL issue Error 505 - Command Received before a ServiceChange Reply has been received 🙈
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 message and only supports a lower version, the MGC SHALL send a ServiceChangeReply with the lower version, and from then on, all the messages between the MG and MGC SHALL conform to the lower version of the protocol. 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 support the lower version the MG proposed, it SHALL send a ServiceChangeReply with the lower version, and from then on, all the messages between the MG and MGC SHALL conform to the lower version of the protocol. 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 (that's procedures, parameters, descriptors, properties, and values) SHOULD NOT be changed, unless a protocol error needs fixing or it becomes necessary to change how the service the protocol supports actually operates.
- the semantics of a command, a parameter, a descriptor, a property, or a value SHOULD NOT be changed.
- established rules for formatting and encoding messages and parameters SHOULD NOT be modified.
- when information elements turn out to be obsolete, they can be marked as not used. however, the identifier for that information element WILL be marked as reserved, so it can't be used in future versions. that's the lore, iykyk 🧚
11.4. Failure of a 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 comes back into service, it sends a ServiceChange with a "Restart" method 🌸
letting the MGC send duplicate messages to both MGs supports pairs of MGs that can do redundant failover of one of them. ONLY the Working MG SHALL accept or reject transactions. upon failover, the primary MG sends a ServiceChange command with a "Failover" method and a "MG Impending Failure" reason. the MGC then uses the secondary MG as the active MG. once the error condition is repaired, the Working MG can send a "ServiceChange" with a "Restart" method 💜
Note: Redundant failover MGs require a reliable transport, because the protocol provides no means for a secondary MG running ALF to acknowledge messages sent from the MGC. ⚠️ bestie, this one is not optional 😭
11.5. Failure of an MGC 💔✨
okay bestie, so what happens when the MG notices its controlling MGC has gone down? 😭 It goes to the next MGC on its pre-provisioned list 💅. It starts at the beginning with the primary MGC, unless that's the one that just failed, in which case it starts at its first secondary MGC. Then it sends a ServiceChange message with a Failover method and a MGC Impending Failure reason 🦋. If the MG can't establish a control relationship with any MGC, it waits a random amount of time as described in section 9.2 🎲 and then tries its primary MGC again, and its secondary MGCs if needed. When it contacts the MGC it was previously controlled by, it sends the ServiceChange message with a Disconnected method 🫶.
Now for the handoff glow-up 🔄. In partial failure, or for manual maintenance, an MGC might want its controlled MGs to move over to a different MGC. To do that, it sends a ServiceChange to the MG with a HandOff method, and puts its chosen replacement in ServiceChangeMgcId. If HandOff is supported, the MG shall send a ServiceChange message with a Handoff method and an MGC directed change reason to the designated MGC 👑. If it doesn't get a reply from that designated MGC, the MG shall act like its MGC failed and start contacting secondary MGCs, as described in the previous paragraph. And if the MG still can't establish a control relationship with any MGC, it shall wait a random amount of time as described in 9.2, then start contacting its primary, and if necessary its secondary, MGCs again ⏳.
This part is giving "out of scope" energy 🙈. No recommendation is made on how the MGCs involved in the Handoff keep their state information, because that's not what this RFC covers. Still, the MGC and MG may take these steps when a Handoff happens. When the MGC starts a HandOff, the handover should be transparent to Operations on the Media Gateway ✨. Transactions can run in any order, and they could still be in progress when the ServiceChange happens. So commands in progress keep going, and replies to all commands from the original MGC must be sent to the transport address they came from 📬. If the service relationship with the sending MGC has ended, the replies should be discarded 🗑️. The MG might get 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. And the MG shall maintain state on all Terminations and Contexts 🧠.
Okay, plot twist 🌀. It's possible for an MGC to be built so that a failed MGC gets replaced by a working one 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, then send a ServiceChange message as above 🎭.
Last but not least, pairs of MGCs that can do redundant failover can tell their controlled MGs about the failover using the mechanism above 💜.
12. Package definition 📦🎀
The main way to extend the protocol is through Packages 🌈. Packages define extra Properties, Events, Signals and Statistics that may show up on Terminations.
Packages defined by IETF will live in their own separate RFCs 📜. Packages defined by ITU-T may appear in the relevant Recommendations, for example as Recommendations in the H.248 sub-series 🧚.
The package has to be documented properly too, so there are a few rules for that 🧾:
- A public document or a standard forum document should be specified. It can be referenced as the document that describes the package, following the guideline above.
- 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 way to leave 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, following the guidelines in 13.2. This is mostly a matter of documentary convenience 📚: the package documentation gets submitted to IANA to support the error code registration. If a package is modified, you don't need to give IANA a new document reference for the error code unless the error code's own description changes 🙌.
Names of all these 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. For example, togen/playtone is the text encoding for the play tone signal in the tone generation package 🎶.
A Package will contain the following sections:
12.1.1. Package 🎁
Here's the 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
1to99🔢.
- 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
- Designed to be extended only (Optional):
- This indicates that the package has been expressly designed to be extended by others, not to be directly referenced. For example, the package may not have any function on its own or be nonsensical on its own. The MG SHOULD NOT publish this PackageID when reporting packages 🙈.
- Extends (Optional): existing package Descriptor
- 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 an identifier defined in the original package, or in packages it may have extended (multiple levels of extension). So, if package B version 1 extends package A version 1, version 2 of B won't be able to extend A version 2 if A version 2 defines a name that's already in B version 1 😬.
12.1.2. Properties 🎨
Here are the Properties defined by the package, specifying:
- Property Name: only descriptive
- PropertyID: is an identifier
- Description:
- Type: One of:
BooleanString: UTF-8 stringOctet String: A number of octets. See Annex A and Annex B.3 for encodingInteger: 4 byte signed integerDouble: 8 byte signed integerCharacter: unicode UTF-8 encoding of a single letter. Could be more than one octetEnumeration: one of a list of possible unique values (see 12.3)Sub-list: a list of several values from a list. The type of sub-list SHALL also be specified. The type shall be chosen from the types specified in this section (with the exception of sub-list). For example,Type: sub-list of enumeration. The encoding of sub-lists is specified in Annexes A and B.3 💅
- Possible values:
- A package MUST specify either a specific set of values or a description of how values are determined. A package MUST also specify a default value or the default behaviour when the value is omitted from its descriptor. For example, a package may specify that procedures related to the property are suspended when its value is omitted. A default value (but not procedures) may be specified as provisionable 🔧.
- Defined in:
- Which H.248.1 descriptor the property is defined in.
LocalControlis for stream dependent properties.TerminationStateis for stream independent properties. These are expected to be the most common cases, but it's possible for properties to be defined in other descriptors.
- Which H.248.1 descriptor the property is defined in.
- Characteristics: Read/Write or both, and (optionally), global:
- Indicates whether a property is read-only or read-write, and whether it is global. If Global is omitted, the property is not global. If a property is declared as global, its value is shared by all Terminations realizing the package 🤝.
12.1.3. Events ⚡
Here are the 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 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 12.2 👀.
12.1.4. Signals 📣
Here are the Signals defined by the package, specifying:
- Signal Name: only descriptive
- SignalID: is an identifier. SignalID is used in a SignalsDescriptor
- Description
- SignalType: one of:
OO (On/Off)TO (TimeOut)BR (Brief)
NOTE - SignalType may be defined such that it is dependent on the value of one or more parameters. The package MUST specify a default signal type. If the default type is TO, the package MUST specify a default duration, which may be provisioned. A default duration is meaningless for BR 🙃.
- Duration: in hundredths of seconds ⏱️
- Additional Parameters: see 12.2
12.1.5. Statistics 📊
Here are the Statistics defined by the package, specifying:
- Statistic name: only descriptive
- StatisticID: is an identifier
- StatisticID is used in a StatisticsDescriptor
- Description:
- Units: unit of measure, e.g., milliseconds, packets 📏
12.1.6. Procedures 🛠️
Additional guidance on the use of the package 🧠.
12.2 Guidelines to defining Parameters to Events and Signals 🎀
Okay so, parameters to Events and Signals have a few rules, and they're honestly kind of cute once you see them. Let's go through them. 💅
Parameter Name: only descriptive
ParameterID: is an identifier. The textual ParameterID of parameters to Events and Signals shall not start with "EPA" and "SPA", respectively. The textual ParameterID shall also not be "ST", "Stream", "SY", "SignalType", "DR", "Duration", "NC", "NotifyCompletion", "KA", "Keepactive", "EB", "Embed", "DM" or "DigitMap". 🙈
Type: One of:
- Boolean
- String: UTF-8 octet string
- Octet String: A number of octets. See Annex A and Annex B.3 for encoding
- 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 (not supported for statistics). The type of sub-list SHALL also be specified. The type shall be chosen from the types specified in this section (with the exception of sub-list). For example, Type: sub-list of enumeration. The encoding of sub-lists is specified in Annexes A and B.3.
Possible values: A package MUST specify either a specific set of values or a description of how values are determined. A package MUST also specify a default value or the default behavior when the value is omitted from its descriptor. For example, a package may specify that procedures related to the parameter are suspended when it value is omitted. A default value (but not procedures) may be specified as provisionable. 🔥
Description:
12.3 Lists 📝
Possible values for parameters include enumerations. Enumerations may be defined in a list. It is recommended that the list be IANA registered so that packages that extend the list can be defined without concern for conflicting names. Honestly that's just good sense, no cap. 🌸
12.4 Identifiers 🧚
Identifiers in text encoding shall be strings of up to 64 characters, containing no spaces, starting with an alphabetic 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. ✨
12.5 Package registration 🦋
A package can be registered with IANA for interoperability reasons. See clause 13 for IANA Considerations.
13 IANA Considerations 👑
13.1 Packages 💖
The following considerations SHALL be met to register a package with IANA:
- 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
0x8000to0xFFFFare reserved for private use. Serial number0is 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:
- 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.
13.3 ServiceChange reasons 🍓
The following considerations SHALL be met to register 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 🦋
This annex specifies the syntax of messages using the notation defined in Recommendation X.680; 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 Recommendation X.690, Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules.
A.1 Coding of wildcards 💅
The use of wildcards ALL and CHOOSE is allowed in the protocol. This allows a MGC to partially specify Termination IDs and to let the MG choose from the values that conform to the partial specification. Termination IDs may encode a hierarchy of names. This 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. This means that 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 if 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 wildcarding 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.
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 01010101.Addressing ALL names with prefix 00000001 00011110 is done as follows:
wildcarding field: 10000111
Termination ID: 00000001 00011110 xxxxxxxx.The values of the bits labeled "x" is irrelevant and shall be ignored by the receiver.
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 xxxxxxxx.The 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 xxxxxxxx .Bit 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.
Context IDs may also be wildcarded. In the case of 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 subclause contains the ASN.1 specification of the H.248.1 protocol syntax.
NOTE 1 - In case a transport mechanism is used that employs application level framing, the definition of Transaction below changes. Refer to the annex or to the Recommendation of the H.248 sub-series defining the transport mechanism for the definition that applies in that case.
NOTE 2 - The ASN.1 specification below contains a clause defining TerminationIDList as a sequence of TerminationIDs. The length of this sequence SHALL be one, except possibly when used in contextAuditResult.
NOTE 3 - This syntax specification does not enforce all restrictions on element inclusions and values. Some additional restrictions are stated in comments and other restrictions appear in the text of this RFC. These additional restrictions are part of the protocol even though not enforced by this specification.
NOTE 4 - The ASN.1 module in this Annex uses octet string types to encode values for property parameter, signal parameter and event parameter values and statistics. The actual types of these values vary and are specified in Annex C or the relevant package definition.
A value is first BER-encoded based on its type using the table below. The result of this BER-encoding is then encoded as an ASN.1 octet string, "double wrapping" the value. The format specified in Annex C or the package relates to BER encoding according to the following table:
Type Specified in Package ASN.1 BER Type
String IA5String or UTF8String (Note 4)
Integer (4 Octet) INTEGER
Double (8 octet signed int) INTEGER (Note 3)
Character (UTF-8, Note 1) IA5String
Enumeration ENUMERATED
Boolean BOOLEAN
Unsigned Integer (Note 2) INTEGER (Note 3)
Octet (String) OCTET STRING- Note 1: Can be more than one byte
- Note 2: Unsigned integer is referenced in Annex C
- Note 3: The BER encoding of INTEGER does not imply the use of 4 bytes.
- Note 4: String should be encoded as IA5String when the contents are all ASCII characters, but as UTF8String if it contains any Non-ASCII characters.
See ITU-T Rec. X.690, 8.7, for the definition of the encoding of an octet string value.
Here's the start of the ASN.1 module, so grab your snacks:
MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=
BEGIN
MegacoMessage ::= SEQUENCE
{
authHeader AuthenticationHeader OPTIONAL,
mess Message
}Okay bestie, we're picking up right where the ASN.1 left off 💅✨ Here's the next chunk of grammar, the message structures for the Gateway Control Protocol, and it's giving very organised 🎀
AuthenticationHeader ::= SEQUENCE
{
secParmIndex SecurityParmIndex,
seqNum SequenceNum,
ad AuthData
}
SecurityParmIndex ::= OCTET STRING(SIZE(4))
SequenceNum ::= OCTET STRING(SIZE(4))
AuthData ::= OCTET STRING (SIZE (12..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..4)),
-- Addressing structure of mtpAddress:
-- 25 - 15 0
-- | PC | NI |
-- 24 - 14 bits 2 bits
-- Note: 14 bits are defined for international use.
-- Two national options exist where the point code is 16 or 24
-- bits.
-- To octet align the mtpAddress, the MSBs shall be encoded as 0s.
...
}
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 A.3
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,
immAckRequired NULL OPTIONAL,
transactionResult CHOICE
{
transactionError ErrorDescriptor,
actionReplies SEQUENCE OF ActionReply
},
...
}
TransactionResponseAck ::= SEQUENCE OF TransactionAck
TransactionAck ::= SEQUENCE
{
firstAck TransactionId,
lastAck TransactionId OPTIONAL
}
ErrorDescriptor ::= SEQUENCE
{
errorCode ErrorCode,
errorText ErrorText OPTIONAL
}
ErrorCode ::= INTEGER(0..65535)
-- See clause 13 for IANA Considerations with respect to error codes
ErrorText ::= IA5String
ContextID ::= INTEGER(0..4294967295)
-- Context NULL Value: 0
-- Context CHOOSE Value: 4294967294 (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,
descriptors SEQUENCE OF AmmDescriptor,
-- At most one descriptor of each type (see AmmDescriptor)
-- allowed in the sequence.
...
}
AmmDescriptor ::= CHOICE
{
mediaDescriptor MediaDescriptor,
modemDescriptor ModemDescriptor,
muxDescriptor MuxDescriptor,
eventsDescriptor EventsDescriptor,
eventBufferDescriptor EventBufferDescriptor,
signalsDescriptor SignalsDescriptor,
digitMapDescriptor DigitMapDescriptor,
auditDescriptor AuditDescriptor,
...
}
AmmsReply ::= SEQUENCE
{
terminationID TerminationIDList,
terminationAudit TerminationAudit OPTIONAL,
...
}
SubtractRequest ::= SEQUENCE
{
terminationID TerminationIDList,
auditDescriptor AuditDescriptor OPTIONAL,
...
}
AuditRequest ::= SEQUENCE
{
terminationID TerminationID,
auditDescriptor AuditDescriptor,
...
}
AuditReply ::= CHOICE
{
contextAuditResult TerminationIDList,
error ErrorDescriptor,
auditResult AuditResult,
...
}
AuditResult ::= SEQUENCE
{
terminationID TerminationID,
terminationAuditResult TerminationAudit
}
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,
emptyDescriptors AuditDescriptor,
...
}
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,
...
}
NotifyRequest ::= SEQUENCE
{
terminationID TerminationIDList,
observedEventsDescriptor ObservedEventsDescriptor,
errorDescriptor ErrorDescriptor OPTIONAL,
...
}
NotifyReply ::= SEQUENCE
{
terminationID TerminationIDList,
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,
-- For use of extraInfo see the comment related to PropertyParm
extraInfo CHOICE
{
relation Relation,
range BOOLEAN,
sublist BOOLEAN
} OPTIONAL,
...
}
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 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
} OPTIONAL,
...
}
StreamDescriptor ::= SEQUENCE
{
streamID StreamID,
streamParms StreamParms
}
StreamParms ::= SEQUENCE
{
localControlDescriptor LocalControlDescriptor OPTIONAL,
localDescriptor LocalRemoteDescriptor OPTIONAL,
remoteDescriptor LocalRemoteDescriptor OPTIONAL,
...
}
LocalControlDescriptor ::= SEQUENCE
{
streamMode StreamMode OPTIONAL,
reserveValue BOOLEAN OPTIONAL,
reserveGroup BOOLEAN OPTIONAL,
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
-- If the sublist field is not selected, a longer sequence means
-- "choose one of the values" (i.e., value1 OR value2 OR ...)
-- If the sublist field is selected,
-- a sequence with more than one element encodes the value of a
-- list-valued property (i.e., value1 AND value2 AND ...).
-- 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,
sublist BOOLEAN
} OPTIONAL,
...
}
Name ::= OCTET STRING(SIZE(2))
PkgdName ::= OCTET STRING(SIZE(4))
-- represents Package Name (2 octets) plus Property, Event,
-- Signal Names or Statistics ID. (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.
-- To wildcard a Property, Event, Signal, or Statistics ID, use
-- 0xFFFF for last two octets, choose is not allowed.
-- Wildcarding of Package Name is permitted only if Property,
-- Event, Signal, or Statistics ID are
-- 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),
...
}
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 OPTIONAL,
-- RequestID must be present if eventList
-- is non empty
eventList SEQUENCE OF RequestedEvent,
...
}
RequestedEvent ::= SEQUENCE
{
pkgdName PkgdName,
streamID StreamID OPTIONAL,
eventAction RequestedActions OPTIONAL,
evParList SEQUENCE OF EventParameter,
...
}
RequestedActions ::= SEQUENCE
{
keepActive BOOLEAN OPTIONAL,
eventDM EventDM OPTIONAL,
secondEvent SecondEventsDescriptor OPTIONAL,
signalsDescriptor SignalsDescriptor OPTIONAL,
...
}
EventDM ::= CHOICE
{ digitMapName DigitMapName,
digitMapValue DigitMapValue
}
SecondEventsDescriptor ::= SEQUENCE
{
requestID RequestID OPTIONAL,
eventList SEQUENCE OF SecondRequestedEvent,
...
}
SecondRequestedEvent ::= SEQUENCE
{
pkgdName PkgdName,
streamID StreamID OPTIONAL,
eventAction SecondRequestedActions OPTIONAL,
evParList SEQUENCE OF EventParameter,
...
}
SecondRequestedActions ::= SEQUENCE
{
keepActive BOOLEAN OPTIONAL,
eventDM EventDM OPTIONAL,
signalsDescriptor SignalsDescriptor OPTIONAL,
...
}
EventBufferDescriptor ::= SEQUENCE OF EventSpec
EventSpec ::= SEQUENCE
{
eventName EventName,
streamID StreamID OPTIONAL,
eventParList SEQUENCE OF EventParameter,
...
}
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 NotifyCompletion OPTIONAL,
keepActive BOOLEAN OPTIONAL,
sigParList SEQUENCE OF SigParameter,
...
}
SignalType ::= ENUMERATED
{
brief(0),
onOff(1),
timeOut(2),
...
}
SignalName ::= PkgdName
NotifyCompletion ::= BIT STRING
{
onTimeOut(0), onInterruptByEvent(1),
onInterruptByNewSignalDescr(2), otherReason(3)
}
SigParameter ::= SEQUENCE
{
sigParameterName Name,
value Value,
-- For use of extraInfo see the comment related to PropertyParm
extraInfo CHOICE
{
relation Relation,
range BOOLEAN,
sublist BOOLEAN
} OPTIONAL,
...
}
-- For an AuditCapReply with all events, the RequestID SHALL be ALL.
-- ALL is represented by 0xffffffff.
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 OPTIONAL,
digitMapValue DigitMapValue OPTIONAL
}
DigitMapName ::= Name
DigitMapValue ::= SEQUENCE
{
startTimer INTEGER(0..99) OPTIONAL,
shortTimer INTEGER(0..99) OPTIONAL,
longTimer INTEGER(0..99) OPTIONAL,
digitMapBody IA5String,
-- Units are seconds for start, short and long timers, and
-- hundreds of milliseconds for duration timer. Thus start,
-- short, and long range from 1 to 99 seconds and duration
-- from 100 ms to 9.9 s
-- See 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,
-- A serviceChangeReason consists of a numeric reason code
-- and an optional text description.
-- The serviceChangeReason SHALL be a string consisting of
-- a decimal reason code, optionally followed by a single
-- space character and a textual description string.
-- This string is first BER-encoded as an IA5String.
-- The result of this BER-encoding is then encoded as
-- an ASN.1 OCTET STRING type, "double wrapping" the
-- value as was done for package elements.
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..4)),
...
}
ServiceChangeResParm ::= SEQUENCE
{
serviceChangeMgcId MId OPTIONAL,
serviceChangeAddress ServiceChangeAddress OPTIONAL,
serviceChangeVersion INTEGER(0..99) OPTIONAL,
serviceChangeProfile ServiceChangeProfile OPTIONAL,
timestamp TimeNotation OPTIONAL,
...
}
ServiceChangeMethod ::= ENUMERATED
{
failover(0),
forced(1),
graceful(2),
restart(3),
disconnected(4),
handOff(5),
...
}
ServiceChangeProfile ::= SEQUENCE
{
profileName IA5String(SIZE (1..67))
-- 64 characters for name, 1 for "/", 2 for version to match ABNF
}
PackagesDescriptor ::= SEQUENCE OF PackagesItem
PackagesItem ::= SEQUENCE
{
packageName Name,
packageVersion INTEGER(0..99),
...
}
StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter
StatisticsParameter ::= SEQUENCE
{
statName PkgdName,
statValue Value OPTIONAL
}
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
{ t35CountryCode1 INTEGER(0..255),
t35CountryCode2 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
-- per ISO 8601:1988
}
Value ::= SEQUENCE OF OCTET STRING
ENDA.3 Digit maps and path names 🧚
okay so here's the vibe 💅 digit maps are basically strings, but with some syntax rules stapled on top 🎀 the rules for what counts as a valid digit map live in ABNF [RFC 2234], which is the grammar language they use 🤓 the syntax you're about to see in this subclause is just there to help you visualise things 🦋 it's not the final word, bestie! if the digitMap definition in Annex B looks different, Annex B wins 👑
Annex B always takes precedence over the illustrative syntax below if the two disagree. 🫶
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
DOT = %x2E ; "."
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-zA path name is also a string, just with extra syntax rules stacked on top 💅. The ABNF production that defines it gets copied over from Annex B, so you can see exactly what's allowed 🎀.
; 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 / "-"
NAME = ALPHA *63(ALPHA / DIGIT / "_" )ANNEX B - Text encoding of the protocol 📜
B.1. Coding of wildcards
Okay so in a text encoding of the protocol, TerminationIDs can be basically anything 🌸. But if you pick your names smartly, the wildcard character * becomes way more useful 🧚. When the MG runs into the wildcard, it will "match" every TerminationID that has the same characters before and after it (if that makes sense for the situation) 💖. For example, if you had TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, then the TerminationID R13/3/* would match all three of them 🦋. Sometimes ALL Terminations must be referred to, and that's what the TerminationID * is for, and it's called ALL 👑. Then there's the CHOOSE TerminationID $, which tells the MG that it has to either create an ephemeral Termination or pick an idle physical Termination ✨.
B.2. ABNF specification
The protocol syntax is written in ABNF, following RFC 2234 📝.
Note 1 - This syntax specification does not enforce every restriction on element inclusions and values 🙈. Some extra restrictions are spelled out in comments, and others live in the text of this RFC. Those extra restrictions are still part of the protocol, even though this syntax doesn't enforce them 🔥.
Note 2 - The syntax depends on context 🫶. For example, "Add" can be the AddToken or a NAME, and it all depends on where it shows up 💀.
Everything in the ABNF and the text encoding is case insensitive, and that includes TerminationIDs, digitmap Ids and so on 🌈. SDP is the one that's case sensitive, as per RFC 2327 💜.
; NOTE -- The ABNF in this section uses the VALUE construct (or lists
; of VALUE constructs) to encode various package element values
; (properties, signal parameters, etc.). The types of these values
; vary and are specified the relevant package definition. Several
; such types are described in section 12.2.
;
; The ABNF specification for VALUE allows a quotedString form or a
; collection of SafeChars. The encoding of package element values
; into ABNF VALUES is specified below. If a type's encoding allows
; characters other than SafeChars, the quotedString form MUST be used
; for all values of that type, even for specific values that consist
; only of SafeChars.
;
; String: A string MUST use the quotedString form of VALUE and can
; contain anything allowable in the quotedString form.
;
; Integer, Double, and Unsigned Integer: Decimal values can be
; encoded using characters 0-9. Hexadecimal values must be prefixed
; with '0x' and can use characters 0-9,a-f,A-F. An octal format is
; not supported. Negative integers start with '-' and MUST be
; Decimal. The SafeChar form of VALUE MUST be used.
;
; Character: A UTF-8 encoding of a single letter surrounded by
; double quotes.
;
; Enumeration: An enumeration MUST use the SafeChar form of VALUE
; and can contain anything allowable in the SafeChar form.
;
; Boolean: Boolean values are encoded as "on" and "off" and are
; case insensitive. The SafeChar form of VALUE MUST be used.
;
; Future types: Any defined types MUST fit within
; the ABNF specification of VALUE. Specifically, if a type's
; encoding allows characters other than SafeChars, the quotedString
; form MUST be used for all values of that type, even for specific
; values that consist only of SafeChars.
;
; Note that there is no way to use the double quote character within
; a value.
;
; Note that SDP disallows whitespace at the beginning of a line,
; Megaco ABNF allows whitespace before the beginning of the SDP in
; the Local/Remote descriptor. Parsers should accept whitespace
; between the LBRKT following the Local/Remote token and the
; beginning of the SDP.
megacoMessage = LWSP [authenticationHeader SEP ] message
authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
SequenceNum COLON AuthData
SecurityParmIndex = "0x" 8(HEXDIG)
SequenceNum = "0x" 8(HEXDIG)
AuthData = "0x" 24*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 )
; "O-" indicates an optional command
; "W-" indicates a wildcarded response to a command
commandRequestList = ["O-"] ["W-"] commandRequest
*(COMMA ["O-"] ["W-"]commandRequest)
commandRequest = ( ammRequest / subtractRequest / auditRequest /
notifyRequest / serviceChangeRequest)
transactionReply = ReplyToken EQUAL TransactionID LBRKT
[ ImmAckRequiredToken COMMA]
( errorDescriptor / actionReplyList ) RBRKT
actionReplyList = actionReply *(COMMA actionReply )
actionReply = CtxToken EQUAL ContextID LBRKT
( errorDescriptor / commandReply ) /
(commandReply COMMA errorDescriptor) ) RBRKT
commandReply = (( contextProperties [COMMA commandReplyList] ) /
commandReplyList )
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 = SubtractToken EQUAL TerminationID
[ LBRKT auditDescriptor RBRKT]
auditRequest = (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 )
auditReturnParameter = (mediaDescriptor / modemDescriptor /
muxDescriptor / eventsDescriptor /
signalsDescriptor / digitMapDescriptor /
observedEventsDescriptor / eventBufferDescriptor /
statisticsDescriptor / packagesDescriptor /
errorDescriptor / auditItem)
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
;The values 0x0, 0xFFFFFFFE and 0xFFFFFFFF are reserved.
ContextID = (UINT32 / "*" / "-" / "$")The grammar keeps going, so let's keep the vibes up 💖
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".."255"
; 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
; Addressing structure of mtpAddress:
; 25 - 15 0
; | PC | NI |
; 24 - 14 bits 2 bits
; Note: 14 bits are defined for international use.
; Two national options exist where the point code is 16 or 24 bits.
; To octet align the mtpAddress the MSBs shall be encoded as 0s.
; An octet shall be represented by 2 hex digits.
mtpAddress = MTPToken LBRKT 4*8 (HEXDIG) 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-one terminationStateDescriptor
; and either streamParm(s) or streamDescriptor(s) but not both
mediaParm = (streamParm / streamDescriptor /
terminationStateDescriptor)
; at-most-once per item
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 except for propertyParm
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
; sublist (i.e., A AND B AND ...)
/ LBRKT VALUE *(COMMA VALUE) RBRKT
; alternatives (i.e., A OR B OR ...)
/ LSBRKT VALUE COLON VALUE RSBRKT )
; range
INEQUAL = LWSP (">" / "<" / "#" ) LWSP
LSBRKT = LWSP "[" LWSP
RSBRKT = LWSP "]" LWSP
; Note - The octet zero is not among the permitted characters in
; octet string. As the current definition is limited to SDP, and a
; zero octet would not be a legal character in SDP, this is not a
; concern.
localDescriptor = LocalToken LBRKT octetString RBRKT
remoteDescriptor = RemoteToken LBRKT octetString RBRKT
eventBufferDescriptor= EventBufferToken [ LBRKT eventSpec
*( COMMA eventSpec) RBRKT ]
eventSpec = pkgdName [ LBRKT eventSpecParameter
*(COMMA eventSpecParameter) RBRKT ]
eventSpecParameter = (eventStream / eventOther)
eventBufferControl = BufferToken EQUAL ( "OFF" / LockStepToken )
terminationStateDescriptor = TerminationStateToken LBRKT
terminationStateParm *( COMMA terminationStateParm ) RBRKT
; at-most-once per item except for propertyParm
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 items in package
/ ("*" SLASH "*") ; all items 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 (LBRKT
notificationReason *(COMMA notificationReason) RBRKT)
notificationReason = ( TimeOutToken / InterruptByEventToken
/ InterruptByNewSignalsDescrToken
/ OtherReasonToken )
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
; For an AuditCapReply with all events, the RequestID should be ALL.
RequestID = ( UINT32 / "*" )
modemDescriptor = ModemToken (( EQUAL modemType) /
(LSBRKT modemType *(COMMA modemType) RSBRKT))
[ LBRKT propertyParm *(COMMA propertyParm) RBRKT ]
; at-most-once except for extensionParameter
modemType = (V32bisToken / V22bisToken / V18Token /
V22Token / V32Token / V34Token / V90Token /
V91Token / SynchISDNToken / extensionParameter)
digitMapDescriptor = DigitMapToken EQUAL
( ( LBRKT digitMapValue RBRKT ) /
(digitMapName [ LBRKT digitMapValue RBRKT ]) )
digitMapName = NAME
digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA]
["L" COLON Timer COMMA] digitMap
Timer = 1*2DIGIT
; Units are seconds for T, S, and L timers, and hundreds of
; milliseconds for Z timer. Thus T, S, and L range from 1 to 99
; seconds and Z from 100 ms to 9.9 s
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 ;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, and DigitMapToken and PackagesToken are not allowed
;in AuditCapabilities command
auditItem = ( MuxToken / ModemToken / MediaToken /
SignalsToken / EventBufferToken /
DigitMapToken / StatsToken / EventsToken /
ObservedEventsToken / PackagesToken )
serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
*(COMMA serviceChangeParm) RBRKT
; each parameter at-most-once
; at most one of either serviceChangeAddress or serviceChangeMgcId
; but not both
; serviceChangeMethod and serviceChangeReason are REQUIRED
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
; at most one of either serviceChangeAddress or serviceChangeMgcId
; but not both
servChgReplyParm = (serviceChangeAddress / serviceChangeMgcId /
serviceChangeProfile / serviceChangeVersion /
TimeStamp)
serviceChangeMethod = MethodToken EQUAL (FailoverToken /
ForcedToken / GracefulToken / RestartToken /
DisconnectedToken / HandOffToken /
extensionParameter)
; A serviceChangeReason consists of a numeric reason code
; and an optional text description.
; A serviceChangeReason MUST be encoded using the quotedString
; form of VALUE.
; The quotedString SHALL contain a decimal reason code,
; optionally followed by a single space character and a
; textual description string.
serviceChangeReason = ReasonToken EQUAL VALUE
serviceChangeDelay = DelayToken EQUAL UINT32
serviceChangeAddress = ServiceChangeAddressToken EQUAL ( mId /
portNumber )
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 topologyTriple
*(COMMA topologyTriple) RBRKT
topologyTriple = terminationA COMMA
terminationB COMMA topologyDirection
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 )
; Note - The double-quote character is not allowed in quotedString.
quotedString = DQUOTE *(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 = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
"<" / ">" / "="
; New Tokens added to sigParameter must take the format of SPA*
; * may be of any form i.e., SPAM
; New Tokens added to eventParameter must take the form of EPA*
; * may be of any form i.e., EPAD
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")
DisconnectedToken = ("Disconnected" / "DC")
DelayToken = ("Delay" / "DL")
DurationToken = ("Duration" / "DR")
EmbedToken = ("Embed" / "EM")
EmergencyToken = ("Emergency" / "EG")
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")
ImmAckRequiredToken = ("ImmAckRequired" / "IA")
InactiveToken = ("Inactive" / "IN")
IsolateToken = ("Isolate" / "IS")
InSvcToken = ("InService" / "IV")
InterruptByEventToken = ("IntByEvent" / "IBE")
InterruptByNewSignalsDescrToken
= ("IntBySigDescr" / "IBS")
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")
OtherReasonToken = ("OtherReason" / "OR")
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")
VersionToken = ("Version" / "V")B.3. Hexadecimal octet coding 🍓
Okay so hexadecimal octet coding is basically how you turn a string of octets into a string of hex digits, with two digits for every octet 💅 This is the encoding you should use whenever you're encoding octet strings in the text version of the protocol. For each octet, the 8-bit sequence becomes two hex digits. Bit 0 is the first one transmitted and bit 7 is the last (the order matters, bestie 🙈). Bits 7-4 become the first hex digit, with bit 7 as the MSB and bit 4 as the LSB. Bits 3-0 become the second hex digit, with bit 3 as the MSB and bit 0 as the LSB. Here are some examples:
Octet bit pattern Hexadecimal coding
00011011 D8
11100100 27
10000011 10100010 11001000 00001001 C1451390B.4. Hexadecimal octet sequence 🧚
A hexadecimal octet sequence is an even number of hex digits, ended by a <CR> character. It's giving tidy and predictable 🫶
ANNEX C - Tags for media stream properties 🎀
Okay bestie, this is where the annex gets into the nitty-gritty 🎀✨ When binary encoding is used, the parameters for Local, Remote and LocalControl descriptors are tag-value pairs 💖. This annex lists each one's PropertyID, its Property tag, its Type and its Value.
When a Value field points to a reference, those values are just "information" 🧚. The reference is where the real normative values live. If a Value field has no reference, then whatever is in that field counts as "normative" 💅.
Tags are written as hexadecimal numbers in this annex 🌸. When an MGC sets a property's value, it can underspecify that value using one of the mechanisms in 7.1.1 🫶.
Supporting these properties is optional, and that goes for this whole annex and every one of its sub-sections 🦋. For example, an implementation might only do three properties from C.3 and only five from C.8, and that's totally fine 💜.
For a type of "enumeration", the value is the number in brackets, like Send(0) or Receive(1) 🍓. Annex C properties typed "N bits" or "M Octets" should be handled as octet strings when the protocol is encoded 🙈. Properties typed "N bit integer" shall be handled as integers 👑. And "String" shall be handled as an IA5String when the protocol is encoded 💀.
When a type is smaller than one octet, the value shall be stored in the low-order bits of an octet string of size 1 ⭐.
C.1 General media attributes
PropertyID Property Type Value
tag
Media 1001 Enumeration Audio(0), Video(1), Data(2)
Transmission 1002 Enumeration Send(0), Receive(1),
mode Send&Receive(2)
Number of 1003 Unsigned 0-255
Channels integer
Sampling 1004 Unsigned 0-2^32
rate integer
Bitrate 1005 Integer (0..4294967295)NOTE - Units of
100 bit/s.
ACodec 1006 Octet string Audio Codec Type:
Ref.: ITU-T Q.765
Non-ITU-T codecs are defined
with the appropriate standards
organization under a defined
Organizational Identifier.
Samplepp 1007 Unsigned Maximum samples or frames per
integer packet: 0..65535
Silencesupp 1008 Boolean Silence Suppression: True/False
Encrypttype 1009 Octet string Ref.: ITU-T H.245
Encryptkey 100A Octet string Encryption key
size Ref.: ITU-T H.235
(0..65535)
Echocanc 100B Not Used. See H.248.1 E.13 for
an example of possible Echo
Control properties.
Gain 100C Unsigned Gain in dB: 0..65535
integer
Jitterbuff 100D Unsigned Jitter buffer size in ms:
integer 0..65535
PropDelay 100E Unsigned Propagation Delay: 0..65535
integer 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 1890C.2 Mux properties
PropertyID Property tag Type Value
H222 2001 Octet string H222LogicalChannelParameters
Ref.: ITU-T H.245
H223 2002 Octet string H223LogicalChannelParameters
Ref.: ITU-T H.245
V76 2003 Octet string V76LogicalChannelParameters
Ref.: ITU-T H.245
H2250 2004 Octet string H2250LogicalChannelParameters
Ref.: ITU-T H.245C.3 General bearer properties
PropertyID Property Type Value
tag
Mediatx 3001 Enumeration Media Transport TypeTDM
Circuit(0), ATM(1), FR(2),
Ipv4(3), Ipv6(4), ...
BIR 3002 4 octets Value depends on transport
technology
NSAP 3003 1-20 octets See NSAP.
Ref.: Annex A/X.213C.4 General ATM properties
PropertyID Property Type Value
tag
AESA 4001 20 octets ATM End System Address
VPVC 4002 4 octets: VPCI VPCI/VCI
in first two
least Ref.: ITU-T Q.2931
significant
octets, VCI in
second two
octets
SC 4003 Enumeration Service Category: CBR(0),
nrt-VBR1(1), nrt VBR2(2),
nrt-VBR3(3), rt-VBR1(4),
rt VBR2(5), rt-VBR3(6),
UBR1(7), UBR2(8), ABR(9).
Ref.: ATM Forum UNI 4.0
BCOB 4004 5-bit integer Broadband Bearer Class
Ref.: ITU-T Q.2961.2
BBTC 4005 7-bit integer Broadband Transfer Capability
Ref.: ITU-T Q.2961.1
ATC 4006 Enumeration I.371 ATM Traffic
CapabilityDBR(0), SBR1(1),
SBR2(2), SBR3(3), ABT/IT(4),
ABT/DT(5), ABR(6)
Ref.: ITU-T I.371
STC 4007 2 bits Susceptibility to clipping:
Bits
2 1
---
0 0 not susceptible to
clipping
0 1 susceptible to
clipping
Ref.: ITU-T Q.2931
UPCC 4008 2 bits User Plane Connection
configuration:
Bits
2 1
---
0 0 point-to-point
0 1 point-to-multipoint
Ref.: ITU-T Q.2931
PCR0 4009 24-bit integer Peak Cell Rate (For CLP = 0)
Ref.: ITU-T Q.2931
SCR0 400A 24-bit integer Sustainable Cell Rate (For
CLP = 0)
Ref.: ITU-T Q.2961.1
MBS0 400B 24-bit integer Maximum Burst Size (For CLP =
0)
Ref.: ITU-T Q.2961.1
PCR1 400C 24-bit integer Peak Cell Rate (For CLP = 0 +
1)
Ref.: ITU-T Q.2931
SCR1 400D 24-bit integer Sustainable Cell Rate (For
CLP = 0 + 1)
Ref.: ITU-T Q.2961.1
MBS1 400E 24-bit integer Maximum Burst Size (For CLP =
0 + 1)
Ref.: ITU-T Q.2961.1
BEI 400F Boolean Best Effort Indicator
Value 1 indicates that BEI is
to be included in the ATM
signaling; value 0 indicates
that BEI is not to be
included in the ATM
signaling.
Ref.: ATM Forum UNI 4.0
TI 4010 Boolean Tagging Indicator
Value 0 indicates that
tagging is not allowed; value
1 indicates that tagging is
requested.
Ref.: ITU-T Q.2961.1
FD 4011 Boolean Frame Discard
Value 0 indicates that no
frame discard is allowed;
value 1 indicates that frame
discard is allowed.
Ref.: ATM Forum UNI 4.0
A2PCDV 4012 24-bit integer Acceptable 2-point CDV
Ref.: ITU-T Q.2965.2
C2PCDV 4013 24-bit integer Cumulative 2-point CDV
Ref.: ITU-T Q.2965.2
APPCDV 4014 24-bit integer Acceptable P-P CDV
Ref.: ATM Forum UNI 4.0
CPPCDV 4015 24-bit integer Cumulative P-P CDV
Ref.: ATM Forum UNI 4.0
ACLR 4016 8-bit integer Acceptable Cell Loss Ratio
Ref.: ITU-T Q.2965.2, ATM
Forum UNI 4.0
MEETD 4017 16-bit integer Maximum End-to-end transit
delay
Ref.: ITU-T Q.2965.2, ATM
Forum UNI 4.0
CEETD 4018 16-bit integer Cumulative End-to-end transit
delay
Ref.: ITU-T Q.2965.2, ATM
Forum UNI 4.0
QosClass 4019 Integer 0-5 QoS Class
QoS Class Meaning
0 Default QoS
associated
with the ATC
as defined
in ITU-T
Q.2961.2
1 Stringent
2 Tolerant
3 Bi-level
4 Unbounded 5 Stringent
Bi-level
Ref.: ITU-T Q.2965.1
AALtype 401A 1 octet AAL Type
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 AAL for
voice
0 0 0 0 0 0 0 1 AAL type 1
0 0 0 0 0 0 1 0 AAL type 2
0 0 0 0 0 0 1 1 AAL type
3/4
0 0 0 0 0 1 0 1 AAL type 5
0 0 0 1 0 0 0 0 user-
defined AAL
Ref.: ITU-T Q.2931C.5. Frame Relay ✨
okay so this one's the Frame Relay table, and it's giving clean and organized 🎀
PropertyID Property Type Value
tag
DLCI 5001 Unsigned Data link connection
integer id
CID 5002 Unsigned sub-channel id
integer
SID/Noiselevel 5003 Unsigned silence insertion
integer descriptor
Primary Payload 5004 Unsigned Primary Payload Type
type integer Covers FAX and codecsC.6. IP 🦋
the IP table is next and bestie, it's the main character of this whole annex 😭
PropertyID Property tag Type Value
IPv4 6001 32 bits Ipv4Address Ipv4Address
Ref.: IETF RFC 791
IPv6 6002 128 bits IPv6 Address
Ref.: IETF RFC 2460
Port 6003 Unsigned integer 0..65535
Porttype 6004 Enumerated TCP(0), UDP(1), SCTP(2)C.7. ATM AAL2 🌸
ATM AAL2 has a bunch of properties, and the ones with a Recommendation reference are basically pointing you to the source doc for the details 🙈
PropertyID Property Type Value
tag
AESA 7001 20 octets AAL2 service endpoint
address as defined in
the referenced
Recommendation.
ESEANSEA
Ref.: ITU-T Q.2630.1
BIR See C.3 4 octets Served user generated
reference as defined in
the referenced
Recommendation.
SUGR
Ref.: ITU-T Q.2630.1
ALC 7002 12 octets AAL2 link
characteristics as
defined in the
referenced
Recommendation.
Maximum/Average CPS-SDU
bit rate;
Maximum/Average CPS-SDU
size
Ref.: ITU-T Q.2630.1
SSCS 7003 I.366.2: Audio (8 Service specific
octets); Multirate (3 convergence sublayer
octets), or I.366.1: information as defined
SAR-assured (14 in:
octets);SAR-unassured - ITU-T Q.2630.1,and
(7 octets). used in:
- ITU-T I.366.2:
Audio/Multirate;
- ITU-T I.366.1: SAR-
assured/unassured.
Ref.: ITU-T Q.2630.1,
I.366.1 and I.366.2
SUT 7004 1..254 octets Served user transport
parameter as defined in
the referenced
Recommendation.
Ref.: ITU-T Q.2630.1
TCI 7005 Boolean Test connection
indicator as defined in
the referenced
Recommendation.
Ref.: ITU-T 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.: ITU-T Q.2630.1
CID 7008 8 bits subchannel id: 0-255
Ref.: ITU-T I.363.2C.8. ATM AAL1 🧚
last ATM one, AAL1, and it's got its own little cast of subtypes, rates, and clock methods. slay 💖
PropertyID Property Type Value
tag
BIR See table 4-29 octets GIT (Generic Identifier
in C.3 Transport)
Ref.: ITU-T Q.2941.1
AAL1ST 8001 1 octet AAL1 Subtype
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 null
0 0 0 0 0 0 0 1 voiceband
signal transport on 64 kbit/s
0 0 0 0 0 0 1 0 circuit
transport
0 0 0 0 0 1 0 0 high-quality
audio signal transport
0 0 0 0 0 1 0 1 video signal
transport
Ref.: ITU-T Q.2931
CBRR 8002 1 octet CBR Rate
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 1 64 kbit/s
0 0 0 0 0 1 0 0 1544 kbit/s
0 0 0 0 0 1 0 1 6312 kbit/s
0 0 0 0 0 1 1 0 32 064 kbit/s
0 0 0 0 0 1 1 1 44 736 kbit/s
0 0 0 0 1 0 0 0 97 728 kbit/s
0 0 0 1 0 0 0 0 2048 kbit/s
0 0 0 1 0 0 0 1 8448 kbit/s
0 0 0 1 0 0 1 0 34 368 kbit/s
0 0 0 1 0 0 1 1 139 264 kbit/s
0 1 0 0 0 0 0 0 n x 64 kbit/s
0 1 0 0 0 0 0 1 n x 8 kbit/s
Ref.: ITU-T Q.2931
MULT See table Multiplier, or n x 64k/8k/300
in C.9 Ref.: ITU-T Q.2931
SCRI 8003 1 octet Source Clock Frequency Recovery
Method
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 null
0 0 0 0 0 0 0 1 SRTS
0 0 0 0 0 0 1 0 ACM
Ref.: ITU-T Q.2931
ECM 8004 1 octet Error Correction Method
Bits
8 7 6 5 4 3 2 1
---------------
0 0 0 0 0 0 0 0 null
0 0 0 0 0 0 0 1 FEC - Loss
0 0 0 0 0 0 1 0 FEC - Delay
Ref.: ITU-T Q.2931
SDTB 8005 16-bit Structured Data Transfer
integer Blocksize
Block size of SDT CBR service
Ref.: ITU-T I.363.1
PFCI 8006 8-bit Partially filled cells identifier
integer 1-47
Ref.: ITU-T I.363.1C.9. Bearer capabilities 💜
quick heads up before this table: any entry that references Q.931 is talking about the bearer capability information element of Q.931, NOT the low layer information element. don't mix them up bestie 🙈
PropertyID Tag Type Value
TMR 9001 1 octet Transmission Medium
Requirement (Q.763)
Bits
87654321
--------
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
The assigned codepoints
listed below are all for
unrestricted service.
00000111 2 x 64 kbit/s
00001000 384 kbit/s
00001001 1536 kbit/s
00001010 1920 kbit/s
00001011
through
00001111 spare
00010000
through
00101010:
3 x 64 kbit/s through
29 x 64 kbit/s
except
00010011 spare
00100101 spare
00101011
through
11111111 spare
Ref.: ITU-T Q.763okay so we're still in the media stream property tags 🎀 and these ones are giving BIG information-transfer energy 💅 each tag has a name, a code, a size, and a little table of what every value means 🦋
TMRSR 9002 1 octet Transmission Medium
Requirement Subrate
0 unspecified
1 8 kbit/s
2 16 kbit/s
3 32 kbit/s
Contcheck 9003 Boolean Continuity Check
0 continuity check not
required on this circuit
1 continuity check
required on this circuit
Ref.: ITU-T Q.763
ITC 9004 5 bits Information Transfer
Capability
Bits
5 4 3 2 1
---------
0 0 0 0 0 Speech
0 1 0 0 0 Unrestricted
digital information
0 1 0 0 1 Restricted
digital information
1 0 0 0 0 3.1 kHz audio
1 0 0 0 1 Unrestricted
digital information with
tones/announcements
1 1 0 0 0 Video
All other values are
reserved.
Ref.: ITU-T Q.763
TransMode 9005 2 bits Transfer Mode
Bits
2 1
---
0 0 Circuit mode
1 0 Packet mode
Ref.: ITU-T Q.931
TransRate 9006 5 bits Transfer Rate
Bits
5 4 3 2 1
---------
0 0 0 0 0 This code shall
be used for packet mode calls
1 0 0 0 0 64 kbit/s
1 0 0 0 1 2 x 64 kbit/s
1 0 0 1 1 384 kbit/s
1 0 1 0 1 1536 kbit/s
1 0 1 1 1 1920 kbit/s
1 1 0 0 0 Multirate (64
kbit/s base rate)
Ref.: ITU-T Q.931
MULT 9007 7 bits Rate Multiplier
Any value from 2 to n
(maximum number of B-
channels)
Ref.: ITU-T Q.931
layer1prot 9008 5 bits User Information Layer 1
Protocol
Bits
5 4 3 2 1
---------
0 0 0 0 1 ITU-T
standardized rate adaption
V.110 and X.30.
0 0 0 1 0 Recommendation
G.711 m-law
0 0 0 1 1 Recommendation
G.711 A-law
0 0 1 0 0 Recommendation
G.721 32 kbit/s ADPCM and
Recommendation I.460
0 0 1 0 1 Recommendations
H.221 and H.242
0 0 1 1 0 Recommendations
H.223 and H.245
0 0 1 1 1 Non-ITU-T
standardized rate adaption.
0 1 0 0 0 ITU-T
standardized rate adaption
V.120.
0 1 0 0 1 ITU-T
standardized rate adaption
X.31 HDLC flag stuffing
All other values are
reserved.
Ref.: ITU Recommendation
Q.931
syncasync 9009 Boolean Synchronous/Asynchronous
0 Synchronous data
1 Asynchronous data
Ref.: ITU-T Q.931
negotiation 900A Boolean Negotiation
0 In-band negotiation
possible
1 In-band negotiation not
possible
Ref.: ITU-T Q.931
Userrate 900B 5 bits User Rate
Bits
5 4 3 2 1
---------
0 0 0 0 0 Rate is
indicated by E-bits specified
in Recommendation I.460 or
may be negotiated in-band
0 0 0 0 1 0.6 kbit/s
Recommendations V.6 and X.1
0 0 0 1 0 1.2 kbit/s
Recommendation V.6
0 0 0 1 1 2.4 kbit/s
Recommendations V.6 and X.1
0 0 1 0 0 3.6 kbit/s
Recommendation V.6
0 0 1 0 1 4.8 kbit/s
Recommendations V.6 and X.1
0 0 1 1 0 7.2 kbit/s
Recommendation V.6
0 0 1 1 1 8 kbit/s
Recommendation I.460
0 1 0 0 0 9.6 kbit/s
Recommendations V.6 and X.1
0 1 0 0 1 14.4 kbit/s
Recommendation V.6
0 1 0 1 0 16 kbit/s
Recommendation I.460
0 1 0 1 1 19.2 kbit/s
Recommendation V.6
0 1 1 0 0 32 kbit/s
Recommendation I.460
0 1 1 0 1 38.4 kbit/s
Recommendation V.110
0 1 1 1 0 48 kbit/s
Recommendations V.6 and X.1
0 1 1 1 1 56 kbit/s
Recommendation V.6
1 0 0 1 0 57.6 kbit/s
Recommendation V.14 extended
1 0 0 1 1 28.8 kbit/s
Recommendation V.110
1 0 1 0 0 24 kbit/s
Recommendation V.110
1 0 1 0 1 0.1345 kbit/s
Recommendation X.1
1 0 1 1 0 0.100 kbit/s
Recommendation X.1
1 0 1 1 1 0.075/1.2
kbit/s Recommendations V.6
and X.1
1 1 0 0 0 1.2/0.075
kbit/s Recommendations V.6
and X.1
1 1 0 0 1 0.050 kbit/s
Recommendations V.6 and X.1
1 1 0 1 0 0.075 kbit/s
Recommendations V.6 and X.1
1 1 0 1 1 0.110 kbit/s
Recommendations V.6 and X.1
1 1 1 0 0 0.150 kbit/s
Recommendations V.6 and X.1
1 1 1 0 1 0.200 kbit/s
Recommendations V.6 and X.1
1 1 1 1 0 0.300 kbit/s
Recommendations V.6 and X.1
1 1 1 1 1 12 kbit/s
Recommendation V.6
All other values are
reserved.
Ref.: ITU-T Q.931
INTRATE 900C 2 bits Intermediate Rate
Bits
2 1
---
0 0 Not used
0 1 8 kbit/s
1 0 16 kbit/s
1 1 32 kbit/s
Ref.: ITU-T Q.931
nictx 900D Boolean Network Independent Clock
(NIC) on transmission
0 Not required to send
data with network independent
clock
1 Required to send data
with network independent
clock
Ref.: ITU-T Q.931
nicrx 900E Boolean Network independent clock
(NIC) on reception
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)
Ref.: ITU-T Q.931
flowconttx 900F Boolean Flow Control on transmission
(Tx)
0 Not required to send
data with flow control
mechanism
1 Required to send data
with flow control mechanism
Ref.: ITU-T Q.931
flowcontrx 9010 Boolean Flow control on reception
(Rx)
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)
Ref.: ITU-T Q.931okay that's the whole tag list 🧚 every single one has its own little value table, and the ones with bits show the bit order right in the table so you can read it directly 🫶
okay bestie, the Q.931 properties keep going, and every one is a tag with a type and a set of values 🎀 the table is a little long but totally worth the scroll 💅
rateadapthdr 9011 Boolean Rate adaption header/no
header
0 Rate adaption header
not included
1 Rate adaption header
included
Ref.: ITU-T Q.931
multiframe 9012 Boolean Multiple frame establishment
support in data link
0 Multiple frame
establishment not supported.
Only UI frames allowed
1 Multiple frame
establishment supported
Ref.: ITU-T Q.931
OPMODE 9013 Boolean Mode of operation
0 Bit transparent mode of
operation
1 Protocol sensitive mode
of operation
Ref.: ITU-T Q.931
llidnegot 9014 Boolean Logical link identifier
negotiation
0 Default, LLI = 256 only
1 Full protocol
negotiation
Ref.: ITU-T Q.931
assign 9015 Boolean Assignor/assignee
0 Message originator is
"default assignee"
1 Message originator is
"assignor only"
Ref.: ITU-T Q.931
inbandneg 9016 Boolean In-band/out-band negotiation
0 Negotiation is done
with USER INFORMATION
messages on a temporary
signalling connection
1 Negotiation is done in-
band using logical link zero
Ref.: ITU-T Q.931
stopbits 9017 2 bits Number of stop bits
Bits
2 1
---
0 0 Not used
0 1 1 bit
1 0 1.5 bits
1 1 2 bits
Ref.: ITU-T Q.931
databits 9018 2 bits Number of data bits excluding
parity bit if present
Bits
2 1
---
0 0 Not used
0 1 5 bits
1 0 7 bits
1 1 8 bits
Ref.: ITU-T Q.931
parity 9019 3 bits Parity information
Bits
3 2 1
------
0 0 0 Odd
0 1 0 Even
0 1 1 None
1 0 0 Forced to 0
1 0 1 Forced to 1
All other values are
reserved.
Ref.: ITU-T Q.931
duplexmode 901A Boolean Mode duplex
0 Half duplex
1 Full duplex
Ref.: ITU-T Q.931
modem 901B 6 bits Modem Type
Bits
6 5 4 3 2 1
-----------
0 0 0 0 0 0 through
0 0 0 1 0 1 National use
0 1 0 0 0 1 Rec. V.21
0 1 0 0 1 0 Rec. V.22
0 1 0 0 1 1 Rec. V.22 bis
0 1 0 1 0 0 Rec. V.23
0 1 0 1 0 1 Rec. V.26
0 1 1 0 0 1 Rec. V.26 bis
0 1 0 1 1 1 Rec. V.26 ter
0 1 1 0 0 0 Rec. V.27
0 1 1 0 0 1 Rec. V.27 bis
0 1 1 0 1 0 Rec. V.27 ter
0 1 1 0 1 1 Rec. V.29
0 1 1 1 0 1 Rec. V.32
0 1 1 1 1 0 Rec. V.34
1 0 0 0 0 0 through
1 0 1 1 1 1 National use
1 1 0 0 0 0 through
1 1 1 1 1 1 User specified
Ref.: ITU-T Q.931
layer2prot 901C 5 bits User information layer 2
protocol
Bits
5 4 3 2 1
---------
0 0 0 1 0 Rec. Q.921/I.441
0 0 1 1 0 Rec. X.25, link
layer
0 1 1 0 0 LAN logical link
control (ISO/IEC 8802 2)
All other values are
reserved.
Ref.: ITU-T Q.931
layer3prot 901D 5 bits User information layer 3
protocol
Bits
5 4 3 2 1
---------
0 0 0 1 0 ITU-T Q.931
0 0 1 1 0 ITU-T X.25,
packet layer
0 1 0 1 1 ISO/IEC TR 9577
(Protocol identification in
the network layer)
All other values are
reserved.
Ref.: ITU-T Q.931
addlayer3prot 901E Octet Additional User Information
layer 3 protocol
Bits Bits
4 3 2 1 4 3 2 1
------- -------
1 1 0 0 1 1 0 0
Internet Protocol (RFC 791)
(ISO/IEC TR 9577)
1 1 0 0 1 1 1 1
Point-to-point Protocol (RFC
1661)
Ref.: ITU-T Q.931
DialledN 901F 30 Dialled Number
octets
DiallingN 9020 30 Dialling Number
octets
ECHOCI 9021 Not Used. See H.248.1 E.13
for an example of possible
Echo Control properties.
NCI 9022 1 octet Nature of Connection
Indicators
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
Bit
5 Echo control device
- indicator
0 outgoing echo control
device not included
1 outgoing echo control
device included
Bits
8 7 6 Spare
Ref.: ITU-T Q.763
USI 9023 Octet User Service Information
string Ref.: ITU-T Q.763 Clause 3.57C.10. AAL5 properties ✨
Last stop on this tour: the AAL5 properties! 🦋 There are three of them, and each one comes with a property tag, a type, and a value. The two size properties count CPCS-SDU sizes in opposite directions, so the calling and called users each get their own number 🫶
PropertyID Property Type Value
tag
FMSDU A001 32-bit Forward Maximum CPCS-SDU Size:
integer Maximum CPCS-SDU size sent in the
direction from the calling user to
the called user.
Ref.: ITU-T Q.2931
BMSDU A002 32-bit Backwards Maximum CPCS-SDU Size:
integer Maximum CPCS-SDU size sent in the
direction from the called user to
the calling user.
Ref.: ITU-T Q.2931
SSCS See table See table See table in C.7
in C.7 in C.7 Additional values:
VPI/VCIthe properties are all accounted for, bestie 🌈✨
C.11. SDP equivalents 💌
okay so this table is basically the SDP starter pack 🦋 every row maps a property to its SDP tag, and they all point back to RFC 2327 ✨
PropertyID Property Type Value
tag
SDP_V B001 String Protocol Version
Ref.: RFC 2327
SDP_O B002 String Owner/creator and session ID
Ref.: RFC 2327
SDP_S B003 String Session name
Ref.: RFC 2327
SDP_I B004 String Session identifier
Ref.: RFC 2327
SDP_U B005 String URI of descriptor
Ref.: RFC 2327
SDC_E B006 String email address
Ref.: RFC 2327
SDP_P B007 String phone number
Ref.: RFC 2327
SDP_C B008 String Connection information
Ref.: RFC 2327
SDP_B B009 String Bandwidth Information
Ref.: RFC 2327
SDP_Z B00A String Time zone adjustment
Ref.: RFC 2327
SDP_K B00B String Encryption Key
Ref.: RFC 2327
SDP_A B00C String Zero or more session attributes
Ref.: RFC 2327
SDP_T B00D String Active Session Time
Ref.: RFC 2327
SDP_R B00E String Zero or more repeat times
Reference: RFC 2327
SDP_M B00F String Media type, port, transport and format
Ref.: RFC 2327C.12. H.245 🎀
this one is the H.245 crew 🧚 each of these is a property whose value is the matching H.245 structure, and they're all referenced to ITU-T H.245 💜
PropertyID Property Type Value
tag
OLC C001 Octet The value of H.245
OpenLogicalChannel structure.
string Ref.: ITU-T H.245
OLCack C002 Octet The value of H.245
string OpenLogicalChannelAck structure.
Ref.: ITU-T H.245
OLCcnf C003 Octet The value of H.245
string OpenLogicalChannelConfirm structure.
Ref.: ITU-T H.245
OLCrej C004 Octet The value of H.245
string OpenLogicalChannelReject structure.
Ref.: ITU-T H.245
CLC C005 Octet The value of H.245
string CloseLogicalChannel structure.
Ref.: ITU-T H.245
CLCack C006 Octet The value of H.245
string CloseLogicalChannelAck structure.
Ref.: ITU-T H.245ANNEX D - Transport over IP 🦋
D.1. Transport over IP/UDP using Application Level Framing (ALF) 🌸
okay this is where we talk about sending the messages over UDP 📡 the protocol messages can ride over UDP, and if the peer doesn't give you a port (see 7.2.8), commands should go to the default port. that's 2944 for text-encoded operation and 2945 for binary-encoded operation 🎀 and responses must go back to the same address and port the commands came from, no detours 💅
ALF is a set of techniques that lets an application, not the stack, change how messages get sent to the other side ✨ a typical ALF move is letting the app reorder messages that are already queued up 🙈 there's no formal spec for ALF, but the procedures in Annex D.1 give a minimum suggested set of ALF behaviours 🫶
implementors using IP/UDP with ALF should be aware of the restrictions of the MTU on the maximum message size. bestie, watch your message size 👀
D.1.1. Providing At-Most-Once functionality 🔁
so UDP can lose stuff 💀 if there's no timely response, the commands get repeated. the problem is that most commands aren't idempotent, so if an Add gets run a bunch of times, the MG state goes totally unpredictable 😭 which is why the transmission procedures shall provide an "At-Most-Once" functionality 🔒
here's how the peers keep it together 🧠 they keep a list of the responses they sent to recent transactions, plus a list of transactions that are still outstanding. when a message comes in, its transaction identifier gets compared to the recent responses sent to the same MId. if there's a match, 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 there, it's a duplicate transaction, so the entity doesn't execute it either (see D.1.4 for procedures on sending TransactionPending) 🍓
the procedure uses a long timer called LONG-TIMER. it should be set larger than the maximum duration of a transaction, and that duration should account for 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 gets a confirmation that the response was received, through the "Response Acknowledgement parameter" ✨ for transactions acknowledged through that parameter, the entity shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued, so it can detect and ignore duplicate copies of the transaction request that the network might produce 🫧
D.1.2. Transaction identifiers and three-way handshake 🤝
D.1.2.1. Transaction identifiers 🔢
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 in some arbitrary group 🌈 MGCs can also share the load of managing a large MG between several independent processes, and those processes share the same transaction number space 🧚 there are multiple ways to do this sharing, like a centralized allocation of transaction identifiers, or pre-allocating non-overlapping ranges of identifiers to different processes 💅
the implementations shall guarantee that unique transaction identifiers are allocated to all transactions that originate from a logical MGC (identical mId) ✨ and MGs can detect duplicate transactions just by looking at the transaction identifier and mId, which is honestly so clean 😌
D.1.2.2. Three-way handshake 🤝
the TransactionResponse Acknowledgement parameter can show up in any message 🎀 it carries a set of "confirmed transaction-id ranges" 📦 entities may delete their copies of responses to transactions whose id is inside those ranges, and they should silently discard further commands whose transaction-id falls within them 🫶
the "confirmed transaction-id ranges" values shall not be used if more than LONG-TIMER seconds have passed since the MG issued its last response to that MGC, or when an MG resumes operation 🕰️ in that situation, transactions should be accepted and processed without any test on the transaction-id 🦋
messages carrying the "Transaction Response Acknowledgement" parameter may be sent in any order 🌀 and the entity shall retain the "confirmed transaction-id ranges" it received for LONG-TIMER seconds 💾
in the binary encoding, if only the firstAck is present in a response acknowledgement (see A.2), only one transaction is acknowledged 🔢 if both firstAck and lastAck are present, every transaction from firstAck to lastAck is acknowledged 🌸 in the text encoding, a horizontal dash marks a range of transactions being acknowledged (see B.2) ➖
D.1.3. Computing retransmission timers ⏱️
it's the requesting entity's job to set suitable timeouts for all outstanding transactions, and to retry them when timeouts are exceeded 🫶 and if repeated transactions never get acknowledged, the requesting entity is responsible for seeking redundant services and/or clearing existing or pending connections 🙈
the specification purposely avoids giving any value for the retransmission timers, since those values are typically network dependent 🌐 the timers should normally estimate their value by measuring the time between sending a command and getting the response back ⏲️ and implementations SHALL ensure that the retransmission timing algorithm does an exponentially increasing backoff of the retransmission timeout for each retransmission or repetition after the first one 📈
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. The retransmission timer, in TCP, is set to the sum of the average delay plus N times the average deviation. The maximum value of the timer should however be bounded for the protocol defined in this RFC, in order to guarantee that no repeated packet would be 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, and they're both iconic 👑 because it includes an exponentially increasing component, it automatically slows down the stream of messages when there's congestion 🚦 and because it includes a random component, it breaks the potential synchronization between notifications triggered by the same external event 🎲
D.1.4. Provisional responses 🧁
some transactions take a long time to execute 🐢 long execution times can mess with the timer-based retransmission procedure, either causing an inordinate number of retransmissions or timer values that get too long to be efficient 😵 so entities that can predict a long execution time may send a provisional response, "Transaction Pending" ✨ they SHOULD send this response if they receive a repetition of a transaction that's still being executed 🔥
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 after provisional responses, an immediate confirmation shall be sent, and normal repetition timers are used from then on 🫶 an entity that sends a provisional response SHALL include the immAckRequired field in the ensuing final response, indicating that an immediate confirmation is expected 💌 and a Transaction Pending received after a reply shall be ignored 🙅♀️
D.1.5 Repeating Requests, Responses and Acknowledgements ✨
okay so the protocol is basically a bunch of transactions 🦋, and each one is a request plus a response (aka an acknowledgement, which is a whole vibe 💅). Since all of this rides on UDP, messages may get lost 😭. If you don't get a timely response, you repeat the transaction. Entities are expected to keep in memory a list of the responses they sent to recent transactions, meaning every response sent over the last LONG-TIMER seconds, plus a list of the transactions that are currently being executed 📝.
The repetition mechanism is there to guard against three kinds of errors 🛡️:
- transmission errors, like when a packet gets lost to noise on a line or congestion in a queue;
- component failure, like when an interface to an entity becomes unavailable;
- entity failure, like when an entire entity becomes unavailable.
The entities should be able to work out an estimate of the packet loss rate due to transmission errors from their past history 📊. 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 is very legit to assume that something other than a transmission error is happening 🙈. For example, with 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 1000 transactions per second. (Honestly, the number of repetitions considered excessive should be a function of the prevailing packet loss rate.) Also, 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 just 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). But to account for the possibility of an undetected or in progress "failover" 👑, we modify 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 RFC 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 maybe overcome a transient connectivity problem, but also to give some more time for the execution of a failover (waiting a total delay of 30 seconds is probably acceptable) 🍓.
It is, however, important that the maximum delay of retransmissions be bounded. This part is non-negotiable bestie 🚨.
Prior to any retransmission, it is 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 that the MGC has failed, and it begins its recovery process as described in section 11.5. If the MG retries to connect to the current MGC, it shall use a ServiceChange with ServiceChangeMethod set to Disconnected, so that the new MGC will be aware 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 to T MAX the maximum propagation delay in the network 🦋.
D.2 Using TCP 🎀
Protocol messages as defined in this RFC may be transmitted over TCP 💖. When no port is specified by the other side (see 7.2.8), the commands should be sent to the default port. The defined protocol treats messages as the unit of transfer, but TCP is a stream-oriented protocol, so there's a mismatch 🙃. TPKT, according to RFC 1006, SHALL be used to delineate messages within the TCP stream.
Even in a transaction-oriented protocol, transaction requests or responses can still get lost 😤. So it is recommended that entities using TCP transport implement application level timers for each request and each response, similar to those specified for application level framing over UDP ⏱️.
D.2.1 Providing the At-Most-Once functionality 🔒
Messages are carried over TCP, so they aren't subject to transport losses. Still, losing a transaction request or its reply may be noticed in real implementations 👀. If you don't get a timely response, commands are repeated. But most commands are not idempotent, which is a big deal 😬. The state of the MG would become unpredictable if, for example, Add commands were executed several times 💀.
To guard against such losses, it is recommended that entities follow the procedures in D.1.1 🫶.
D.2.2 Transaction identifiers and three-way handshake 🤝
For the same reasons, transaction replies may still be lost even with a reliable delivery protocol like TCP. It is recommended that entities follow the procedures in D.1.2.2 ✨.
D.2.3 Computing retransmission timers ⏳
With reliable delivery, the incidence of loss of a transaction request or reply is expected to be very low 🌈. So only simple timer mechanisms are required. Exponential back-off algorithms should not be necessary, although they could be employed where, as in an MGC, the code to do so is already required, since MGCs must implement ALF/UDP as well as TCP 💅.
D.2.4 Provisional responses 📣
As with UDP, some transactions may take a long time to execute. Entities that can predict that a transaction will require a long execution time may send a provisional response, "Transaction Pending" 🌸. They should send this response if they receive a repetition of a transaction that is still being executed.
Entities that receive a Transaction Pending shall switch to a longer repetition timer for that transaction 🕰️.
Entities shall retain Transactions and replies until they are confirmed. The basic procedure of D.1.4 should be followed, but simple timer values should be sufficient. There is no need to send an immediate confirmation upon receipt of a final response 🙌.
D.2.5 Ordering of commands 📦
TCP provides ordered delivery of transactions, so no special procedures are required 💖. It should be noted that ALF/UDP allows the sending entity to modify its behaviour under congestion. In particular, it could reorder transactions when congestion is encountered, and TCP could not achieve the same results 🦋.
ANNEX E - Basic packages ✨
This annex contains definitions of some packages for use with Recommendation H.248.1 🎀.
E.1 Generic 💜
PackageID: g (0x0001)
Version: 1
Extends: None
Description:
Generic package for commonly encountered items.E.1.1 Properties
None.
E.1.2 Events
The Generic package has an event called Cause 🔥, which is a generic error event:
Cause
EventID: cause (0x0001)
Generic error event
EventsDescriptor parameters: None
ObservedEvents Descriptor Parameters:
General Cause
ParameterID: Generalcause (0x0001)
This parameter groups the failures into six groups, which
the MGC may act upon.
Type: enumeration
Possible values:
"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)
Possible values: OCTET STRING
Description: The Failure 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.There's also the Signal Completion event 🏁, which indicates the termination of a signal for which the notifyCompletion parameter was set to enable reporting of a completion event. For further procedural description, see 7.1.1, 7.1.17 and 7.2.7 📖.
Signal Completion
EventID: sc (0x0002)
EventsDescriptor parameters: None
ObservedEvents Descriptor parameters:
Signal Identity
ParameterID: SigID (0x0001)
This parameter identifies the signal which has terminated.
For a signal that is contained in a signal list, the signal
list identity parameter should also be returned indicating
the appropriate list.
Type: Binary: octet (string), Text: string
Possible values: a signal which has terminated. A signal
shall be identified using the pkgdName syntax without
wildcarding.
Termination Method
ParameterID: Meth (0x0002)
Indicates the means by which the signal terminated.
Type: enumeration
Possible values:
"TO" (0x0001) Signal timed out or otherwise completed on
its own
"EV" (0x0002) Interrupted by event
"SD" (0x0003) Halted by new Signals descriptor
"NC" (0x0004) Not completed, other cause
Signal List ID
ParameterID: SLID (0x0003)
Indicates to which signal list a signal belongs. The
SignalList ID is only returned in cases where the signal
resides in a signal list.
Type: integer
Possible values: any integerE.1.3 Signals
None.
E.1.4 Statistics
None.
E.2 Base Root Package 🌍
PackageID: root (0x0002)
Version: 1
Extends: None
Description:
This package defines Gateway wide properties.E.2.1 Properties ✨
Okay bestie, let's get into the properties for this package! 💖 Each one gets its own little card so you can see what it does, what type it is, and whether you can touch it.
MaxNrOfContexts 🌸
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.
PropertyID: maxNumberOfContexts (0x0001)
Type: double
Possible values: 1 and up
Defined in: TerminationState
Characteristics: read onlyMaxTerminationsPerContext 🦋
This one is the maximum number of allowed terminations in a context. Go check out 6.1 if you want the full story! 👀
PropertyID: maxTerminationsPerContext (0x0002)
Type: integer
Possible values: any integer
Defined in: TerminationState
Characteristics: read onlynormalMGExecutionTime 🧚
This one is settable by the MGC. It tells the MG how long the MGC expects to wait for a response to any transaction from the MG, not counting network delay. 💅
PropertyId: normalMGExecutionTime (0x0003)
Type: integer
Possible values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / writenormalMGCExecutionTime 🎀
Also settable by the MGC! This is the mirror image of the one above. It indicates the interval within which the MG is expected to respond to any transaction from the MGC, again not counting network delay. Same energy, opposite direction. 🔁
PropertyId: normalMGCExecutionTime (0x0004)
Type: integer
Possible values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / writeMGProvisionalResponseTimerValue ⏰
This is the time the MGC should be expecting a Pending Response from the MG if a Transaction can't be completed. It starts out as normalMGExecutionTime plus network delay, but it's allowed to be lowered. 🫶
PropertyId: MGProvisionalResponseTimerValue (0x0005)
Type: Integer
Possible Values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / writeMGCProvisionalResponseTimerValue ⏳
Same vibe, flipped roles. This is the time the MG should be expecting a Pending Response from the MGC if a Transaction can't be completed. It starts at normalMGCExecutionTime plus network delay and may also be lowered. 🌈
PropertyId: MGCProvisionalResponseTimerValue (0x0006)
Type: Integer
Possible Values: any integer, represents milliseconds
Defined in: TerminationState
Characteristics: read / writeE.2.2 Events
Nothing here! None. 🫧
E.2.3 Signals
Also None. 🫧
E.2.4 Statistics
Still None. 🫧 Slay the emptiness. 💅
E.2.5 Procedures
None. 🫧 Nothing to see, moving on! ✨
E.3 Tone Generator Package 🎶
This package is all about generating audio tones. It's giving "build your own ringtone" energy. 🎵 The package itself doesn't set any parameter values, and it's meant to be extended later on. Basically, tones are defined as individual signals that take a parameter called ind, which is the interdigit time delay, plus a tone id you use with playtone. Keep your tone id consistent across any tone generation for the same tone, okay? 💜 MGs are expected to be provisioned with the characteristics of the right tones for whatever country they're located in. 🌍
PackageID: tonegen (0x0003)
Version: 1
Extends: NoneHeads up, this package is designed to be extended only. Don't try to use it on its own and expect magic! 🙈
E.3.1 Properties
None. 🫧
E.3.2 Events
None. 🫧
E.3.3 Signals
Here's the star of the show: the Play tone signal. 🔥
Play tone 🔊
SignalID: pt (0x0001)
Signal Type: Brief
Duration: ProvisionedThis signal plays an audio tone over an audio channel. Its duration is provisioned, which means it's set up ahead of time. 🍓
It also comes with two additional parameters:
Tone id list 🎼
ParameterID: tl (0x0001)
Type: list of tone idsThis is the list of tones to be played in sequence. The list SHALL contain one or more tone ids. No skipping allowed, bestie! 🙅♀️
Inter signal duration ⏱️
ParameterID: ind (0x0002)
Type: integerThis is the timeout between two consecutive tones, measured in milliseconds. 💖
No tone ids are specified in this package. Packages that extend it can add possible values for tone id, as well as adding individual tone signals. Expansion pack vibes! 🌟
E.3.4 Statistics
None. 🫧
E.3.5 Procedures
None. 🫧
E.4 Tone Detection Package 👂
This package is for detecting audio tones. Tones get picked out by name, which is their tone id. ✨ Just like the tone generator, MGs are expected to be provisioned with the characteristics of the right tones for their country. 🌏
PackageID: tonedet (0x0004)
Version: 1
Extends: NoneThis package doesn't specify parameter values either. It's intended to be extendable, so it's built to grow. 🌱
E.4.1 Properties
None. 🫧
E.4.2 Events
Start tone detected 🎧
EventID: std, 0x0001This event detects the start of a tone. How positive tone detection works is up to the implementation. 🤷♀️
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, 0x0002This event detects 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 millisecondsThis parameter contains how long the tone lasted, from first detection until it stopped. 💜
Long tone detected 🎵
EventID: ltd, 0x0003This event detects that a tone has been playing for at least a certain amount of time. Long vibes only! 🌙
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 millisecondsObservedEventsDescriptor parameters:
Tone id
ParameterID: tid (0x0003)
Type: Enumeration
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 📞
This package defines the basic DTMF tones as signals, and it extends the allowed values of the tl parameter of playtone from the tone generator package. Iconic crossover moment! 👑
PackageID: dg (0x0005)
Version: 1
Extends: tonegen version 1E.5.1 Properties
None. 🫧
E.5.2 Events
None. 🫧
E.5.3 Signals
Each DTMF character gets its own signal. Here's the first one. 🌸
DTMF character 0 0️⃣
SignalID: d0 (0x0010)
Signal Type: Brief
Duration: ProvisionedThis generates the DTMF 0 tone. The physical characteristics of DTMF 0 are defined in the gateway. 🏠
Additional parameters:
None. 🫧
Additional values:
d0 (0x0010) is defined as a tone id for playtoneThe other DTMF characters are specified in exactly the same way. Each DTMF character is defined as both a signal and a tone id, which is how this package extends basic tone generation. 🎀 Also, heads up: DTMF SignalIds are different from the names used in a digit map. Don't mix them up! 🙈
Here's the full lineup:
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 🔔
This package defines basic DTMF tone detection. It extends the possible values of the tone id in the "start tone detected", "end tone detected" and "long tone detected" events. 🧚
The extra tone id values are all the tone ids described in package dg, the basic DTMF generator package. 💅
PackageID: dd (0x0006)
Version: 1
Extends: tonedet version 1Here's how DTMF events map onto digit map symbols, as described in 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 🔢
The EventIds here use the same names as the SignalIds in the table from E.5.3. Matching names, no confusion! 🫶
DigitMap Completion Event 🏁
EventID: ce, 0x0004This event is generated when a digit map completes, as described in 7.1.14. ✅
EventsDescriptor parameters: None. 🫧
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 "Z".This is the portion of the current dial string, as described in 7.1.14, that 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 eventThis tells you why the event was generated. Check out the procedures in 7.1.14 for the full picture. 🔍
E.6.3 Signals
None. 🫧
E.6.4 Statistics
None. 🫧
E.6.5 Procedures 💅
okay so digit map processing only turns on if an events descriptor is activated that has a digit map completion event (see Section E.6.2) AND that event has the eventDM field in its requested actions (see Section 7.1.9) 🔥 KeepActive or embedded signals descriptor events can hang out in the same events descriptor too, they just don't change whether digit map processing gets activated 🫶
E.7 Call Progress Tones Generator Package 🎀
PackageID: cg, 0x0007
Version: 1
Extends: tonegen version 1bestie this package is giving basic call progress tones 🔊 it defines them as signals AND it 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 📞
SignalID: 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 in this package are defined in exactly the same way, slay 💅 and there's a full table of every signal name and ID right below. each tone gets defined as BOTH a signal AND a tone id, which is how it extends 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 prt (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. See Recommendation E.180/Q.35 for definition of the meanings of these tones. 🍓
E.8 Call Progress Tones Detection Package 🦋
PackageID: cd (0x0008)
Version: 1
Extends: tonedet version 1this one is the detection side of the call progress tones 👀 it defines the basic call progress detection tones, and it extends the possible values of tone id in the "start tone detected", "end tone detected" and "long tone detected" events 💜
Additional values
toneID values are defined for start tone detected, end tone detected and long tone detected, using the same values as the ones in package cg (the call progress tones generation package) 🧚
the required set of tone ids corresponds to Recommendation E.180/Q.35, so check that for what each tone actually means 🌸
E.8.1 Properties
None. 🫧
E.8.2 Events
events are defined the same way as in the call progress tones generator package (cg) for the tones listed in the table of 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: Nonethis package defines the events and signals for an analog line, aka the old-school phone handset stuff 🧡
E.9.1 Properties
None. 🫧
E.9.2 Events
onhook 📴
EventID: on (0x0004)detects the handset going on hook. whenever an events descriptor gets activated that asks for monitoring of an on-hook event AND the line is already on-hook, then the MG shall behave according to the setting of the "strict" parameter 😭
EventDescriptor parameters:
Strict Transition
ParameterID: strict (0x0001)
Type: enumeration
Possible values: "exact" (0x00), "state" (0x01), "failWrong" (0x02)"exact"means only an actual hook state transition to on-hook gets recognized 🎯"state"means the event gets recognized if the hook state transition is detected OR if the hook state is already on-hook 💅"failWrong"means that if the hook state is already on-hook, the command fails and an error gets reported 💀
ObservedEventsDescriptor parameters:
Initial State
ParameterID: init (0x0002)
Type: Boolean
Possible values:"True"means the event was reported because the line was already on-hook when the events descriptor containing this event was activated 🙈"False"means the event represents an actual state transition to on-hook 🔥
offhook 📱
EventID: of (0x0005)detects the handset going off hook. same energy as onhook: whenever an events descriptor is activated that asks for monitoring of an off-hook event AND the line is already off-hook, the MG shall behave according to the "strict" parameter 🌈
EventDescriptor parameters:
Strict Transition
ParameterID: strict (0x0001)
Type: enumeration
Possible values: "exact" (0x00), "state" (0x01), "failWrong" (0x02)"exact"means only an actual hook state transition to off-hook gets recognized 🎯"state"means the event gets recognized if the hook state transition is detected OR if the hook state is already off-hook 💖"failWrong"means that if the hook state is already off-hook, the command fails and an error gets reported 💀
ObservedEventsDescriptor parameters
Initial State
ParameterID: init (0x0002)
Type: Boolean
Possible values:"True"means the event was reported because the line was already off-hook when the events descriptor containing this event was activated 🫶"False"means the event represents an actual state transition to off-hook ✨
flashhook ⚡
EventID: fl, 0x0006detects a handset flash. a flash happens when an onhook is followed by an offhook between a minimum and maximum duration, ngl that's such a specific vibe 🍓
EventDescriptor parameters:
Minimum duration
ParameterID: mindur (0x0004)
Type: integer in millisecondsDefault value is provisioned.
Maximum duration
ParameterID: maxdur (0x0005)
Type: integer in millisecondsDefault value is provisioned.
ObservedEventsDescriptor parameters: None.
E.9.3 Signals
ring 🔔
SignalID: ri, 0x0002applies ringing on the line 📣
Signal Type: TimeOut Duration: Provisioned
Additional parameters:
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 millisecondsDefault is fixed or provisioned. Restricted function MGs may ignore cadence values they are incapable of generating.
Frequency
ParameterID: freq (0x0007)
Type: integer in HzDefault is fixed or provisioned. Restricted function MGs may ignore frequency values they are incapable of generating.
E.9.4 Statistics
None. 🫧
E.9.5 Procedures
okay this is the drama bit 😤 if the MGC sets an EventsDescriptor with a hook state transition event (on-hook or off-hook) and the "strict" (0x0001) parameter is set to "failWrong", AND the hook state is already what the transition implies, then the execution of the command containing that EventsDescriptor fails. the MG SHALL include error code 540 "Unexpected initial hook state" in its response. no cap, that's a hard rule 🚫
E.9.6 Error code
this package defines a new error code, and it's just the one 🎀
540 - Unexpected initial hook statethe procedure for using this code is in E.9.5 💅
E.10 Basic Continuity Package 🔁
PackageID: ct (0x000a)
Version: 1
Extends: Nonethis package defines events and signals for continuity test 🧪 the continuity test includes providing either a loopback OR transceiver functionality 🌟
E.10.1 Properties
None. 🫧
E.10.2 Events
Completion ✅
EventID: cmp, 0x0005this event detects the test completion of a continuity test 🎉
EventDescriptor parameters: None.
ObservedEventsDescriptor parameters
Result
ParameterID: res (0x0008)
Type: enumeration
Possible values: success (0x0001), failure (0x0000)E.10.3 Signals
Continuity test 🔊
SignalID: ct (0x0003)initiates sending of the continuity test tone on the termination it gets applied to 🎵
Signal Type: TimeOut Default value: Provisioned Additional parameters: None.
Respond 📡
SignalID: rsp (0x0004)this signal is used to respond to a continuity test. see E.10.5 for more explanation 💜
Signal Type: On/Off Default duration: Provisioned Additional parameters: None.
E.10.4 Statistics
None. 🫧
E.10.5 Procedures
when a MGC wants to start a continuity test, it sends a command to the MG containing:
- a signals descriptor with the ct signal; and
- an events descriptor containing the cmp event.
when the command with the ct signal and cmp event shows up, the MG starts the continuity test tone for the specified Termination 🎶 if the return tone is detected and any other required conditions are satisfied before the signal times out, the cmp event shall be generated with the value of the result parameter equal to success. in all other cases, the cmp event shall be generated with the value of the result parameter equal to failure 💀
when a MGC wants the MG to respond to a continuity test, it sends a command containing a signals descriptor with the rsp signal. once the MG gets a command with the rsp signal, it either applies a loopback or (for 2-wire circuits) waits to receive a continuity test tone. in the loopback case, any incoming information shall be reflected back as outgoing information 🔁 in the 2-wire case, any time the appropriate test tone comes in, the appropriate response tone should be sent. the MGC decides when to remove the rsp signal 🫶
when a continuity test is performed on a Termination, no echo devices or codecs shall be active on that Termination 🙅♀️
performing voice path assurance as part of continuity testing is provisioned by bilateral agreement between network operators 🤝
(Informative Note) Example tones and test procedure details are given in Q.724 sections 7 and 8, Q.764 section 2.1.8 and Q.1902.4. 🍓
E.11 Network Package ✨
okay bestie, the Network Package is all about properties of network terminations that don't care what kind of network they're on 🌐💅
PackageID: nt (0x000b)Version: 1Extends: None
This package defines properties of network terminations independent of network type.
E.11.1 Properties 🎀
Maximum Jitter Buffer 🫧
PropertyID: jit (0x0007)
This property puts a maximum size on the jitter buffer.
- Type: integer in milliseconds
- Possible values: This property is specified in milliseconds.
- Defined in: LocalControlDescriptor
- Characteristics: read/write
E.11.2 Events 🚨
network failure 💥
EventID: netfail, 0x0005
The termination generates this event when it detects a failure caused by external or internal network reasons. It's giving "something broke and I'm telling you about it" 😭
- EventDescriptor parameters: None.
- ObservedEventsDescriptor parameters:
- cause
ParameterID: cs (0x0001)- Type: string
- Possible values: any text string. This parameter may be included with the failure event to provide diagnostic information on the reason of failure. ✨
- cause
quality alert 📉
EventID: qualert, 0x0006
This property allows the MG to indicate a loss of quality of the network connection. The MG may do this by measuring packet loss, interarrival jitter, and propagation delay, and then indicating the result as a percentage of quality loss. Main character energy, measuring the vibes of your connection 🦋
- EventDescriptor parameters:
- Threshold
ParameterId: th (0x0001)- Type: integer
- Possible values: 0 to 99
- Description: 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. The event is triggered when the calculation exceeds the threshold. 👑
- Threshold
- ObservedEventsDescriptor parameters:
- Threshold
ParameterId: th (0x0001)- Type: integer
- Possible values: 0 to 99
- Description: percent of quality loss measured, calculated based on a provisioned method, that could take into consideration packet loss, jitter, and delay for example.
- Threshold
E.11.3 Signals 🤍
None.
E.11.4 Statistics 📊
Duration ⏱️
StatisticsID: dur (0x0001)
Description: provides the duration of time the termination has been in the Context. 🕰️
- Type: double, in milliseconds
Octets Sent 📤
StatisticID: os (0x0002)- Type: double
- Possible values: any 64-bit integer
Octets Received 📥
StatisticID: or (0x0003)- Type: double
- Possible values: any 64-bit integer
E.11.5 Procedures 🧚
None.
E.12 RTP Package 🦋
okay so the RTP Package is for packet-based multimedia data transfer using the Real-time Transport Protocol, and it's honestly so iconic 😭🎶
PackageID: rtp (0x000c)Version: 1Extends: Network Package version 1
This package is used to support packet-based multimedia data transfer by means of the Real-time Transport Protocol (RTP) [RFC 1889].
E.12.1 Properties 🫧
None.
E.12.2 Events 💫
Payload Transition 🔀
EventID: pltrans, 0x0001
This event detects and notifies when there is a transition of the RTP payload format from one format to another. Format glow-up, bestie ✨
- EventDescriptor parameters: None.
- ObservedEventsDescriptor parameters:
ParameterName: rtppayloadParameterID: rtppltype, 0x01- Type: list of enumerated types.
- Possible values: The encoding method shall be specified by 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 📤
StatisticID: ps (0x0004)- Type: double
- Possible values: any 64-bit integer
Packets Received 📥
StatisticID: pr (0x0005)- Type: double
- Possible values: any 64-bit integer
Packet Loss 📉
StatisticID: pl (0x0006)
Describes the current rate of packet loss on an RTP stream, as defined in IETF RFC 1889. Packet loss is expressed as a percentage value: the number of packets lost in the interval between two reception reports, divided by the number of packets expected during that interval. Ngl this is the stat I check first 💀
- Type: double
- Possible values: a 32-bit whole number and a 32-bit fraction.
Jitter 🌊
StatisticID: jit (0x0007)
Requests the current value of the interarrival jitter on an RTP stream, as defined in IETF RFC 1889. Jitter measures the variation in interarrival time for RTP data packets.
Delay 🕐
StatisticID:delay (0x0008)
Requests the current value of packet propagation delay, expressed in timestamp units. Same as average latency.
E.12.5 Procedures 🧚
None.
E.13 TDM Circuit Package 🌸
PackageID: tdmc (0x000d)Version: 1Extends: Network Package version 1
This package may be used by any termination that supports gain and echo control. It was originally intended for use on TDM circuits, but it may be used more widely. Glow-up era 🌷
New versions or extensions of this package should take non-TDM use into account. 🫶
E.13.1 Properties 🎀
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 provisioned.
- Defined in: LocalControlDescriptor
- Characteristics: read/write
Gain Control 🔊
PropertyID: gain (0x000a)
Gain control, or the use of signal level adaptation and noise level reduction, is used to adapt the level of the signal. However, it is necessary to turn this function off for things like modem calls. 📞
- Type: 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/write
E.13.2 Events 🤍
None.
E.13.3 Signals 🤍
None.
E.13.4 Statistics 📊
None.
E.13.5 Procedures 🧚
None.
APPENDIX I EXAMPLE CALL FLOWS (INFORMATIVE) 📞✨
All H.248.1 implementors must read the normative part of this RFC carefully before implementing from it. The examples in this appendix should not be used as stand-alone explanations of how to create protocol messages. Read the actual spec first, bestie 🙈
The examples in this appendix use SDP for encoding of the Local and Remote stream descriptors. SDP is defined in RFC 2327. If there is any discrepancy between the SDP in the examples and RFC 2327, RFC 2327 should be consulted for correctness. Audio profiles used are those defined in IETF RFC 1890, and others registered with IANA. For example, G.711 A-law is called PCMA in SDP and is assigned profile 0. G.723.1 is called G723 and is profile 4, and H.263 is called H263 and is profile 34. See also http://www.iana.org/assignments/rtp-parameters.
A.1 Residential Gateway to Residential Gateway Call 🏠📞
This example scenario illustrates the use of the elements of the protocol to set up a Residential Gateway to Residential Gateway call over an IP-based network. For simplicity, this example assumes that both Residential Gateways involved in the call are controlled by the same Media Gateway Controller. Two gateways, one controller, zero drama 💅
A.1.1 Programming Residential GW Analog Line Terminations for Idle Behavior 💤
The following illustrates the API invocations from the Media Gateway Controller and Media Gateways to get the Terminations in this scenario programmed for idle behavior. Both the originating and terminating Media Gateways have idle AnalogLine Terminations programmed to look for call initiation events (i.e., -offhook) by using the Modify Command with the appropriate parameters. The null Context is used to indicate that the Terminations are not yet involved in a Context. The ROOT termination is used to indicate the entire MG instead of a termination within the MG. 🧃
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. 🎀
Step 1: An MG registers with an MGC using the ServiceChange command. Here's MG1 to MGC:
MEGACO/1 [124.124.124.222] Transaction = 9998 {
Context = - {
ServiceChange = ROOT {Services {
Method=Restart,
ServiceChangeAddress=55555, Profile=ResGW/1}
}
} }Step 2: The MGC sends a reply. Here's MGC to MG1:
MEGACO/1 [123.123.123.4]:55555 Reply = 9998 {
Context = - {ServiceChange = ROOT {
Services {ServiceChangeAddress=55555, Profile=ResGW/1} } } }Step 3: 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, it is 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. Local and Remote are assumed to be provisioned. Here's MGC to MG1:
MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 {
Context = - {
Modify = A4444 {
Media { Stream = 1 {
LocalControl {
Mode = SendReceive,
tdmc/gain=2, ; in dB,
tdmc/ec=on
},
}
},
Events = 2222 {al/of(strict=state)}
}
} }The dialplan script could have been loaded into the MG previously. Its function would be to wait for the OffHook, turn on dialtone, and start collecting DTMF digits. However, in this example, we use the digit map, which is 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. Galaxy brain move 🧠✨
Step 4: MG1 accepts the Modify with this reply. Here's MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 9999 {
Context = - {Modify = A4444} }Step 5: A similar exchange happens between MG2 and the MGC, resulting in an idle Termination called A5555. 🦋
A.1.2 Collecting Originator Digits and Initiating Termination 📞✨
Okay so this one picks up right where the last bit left off 💅 It walks through the chat between the Media Gateway Controller and the originating Media Gateway (MG1) as they get the originating Termination (A4444) through digit collection, so MG1 can start a connection to the terminating Media Gateway (MG2) 🦋
6. Okay, MG1 spots an offhook event from User 1 and tells the Media Gateway Controller about it with the Notify Command 📞
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555 Transaction = 10000 {
Context = - {
Notify = A4444 {ObservedEvents =2222 {
19990729T22000000:al/of(init=false)}}
} }7. And the Notify gets acknowledged 🫶
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555 Reply = 10000 {
Context = - {Notify = A4444} }8. Next the MGC modifies the termination so it plays dial tone, looks for digits using Dialplan0, and watches for the on-hook event now too 🔥
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555 Transaction = 10001 {
Context = - {
Modify = A4444 {
Events = 2223 {
al/on(strict=state), dd/ce {DigitMap=Dialplan0}
},
Signals {cg/dt},
DigitMap= Dialplan0{ (0| 00|[1-
7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
}
} }9. And the Modify is acknowledged 💖
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555 Reply = 10001 {
Context = - {Modify = A4444} }10. Now the digits get collected by MG1 as User 1 dials them 🌸 The dial tone stops as soon as the first digit is detected. Once the collected digits match the Dialplan that's currently programmed for A4444, MG1 sends another Notify 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=UM}}}
} }11. And the Notify gets acknowledged ✨
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555 Reply = 10002 {
Context = - {Notify = A4444} }12. The controller looks at the digits and figures out that a connection has to be made from MG1 to MG2 🧚 Both the TDM termination A4444 and an RTP termination get added to a new context in MG1. The Mode is ReceiveOnly because 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.
13. 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 🌈
MG1 -> MGC:
MEGACO/1 [124.124.124.222]:55555 Reply = 10003 {
Context = 2000 {
Add = A4444,
Add=A4445{
Media {
Stream = 1 {
Local { v=0 o=- 2890844526 2890842807 IN IP4
124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
RTP/AVP 4 a=ptime:30 a=recvonly
} ; RTP profile for G.723.1 is 4
}
}
}
} }14. Now the MGC associates A5555 with a new Context on MG2 and sets up an RTP Stream (so A5556 gets assigned), a SendReceive connection through to the originating user, User 1 💖 The MGC also sets ring on 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(strict=state)},
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.1 is 4
}
}
}
} }15. This 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 [125.125.125.111]:55555 Reply = 50003 {
Context = 5000 {
Add = A5555,
Add = A5556{
Media {
Stream = 1 {
Local { v=0 o=- 7736844526 7736842807 IN IP4
125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
RTP/AVP 4 }
} ; RTP profile for G723.1 is 4
}
}
} }16. The IPAddr and UDPport from above need to be handed over to MG1 now 🎀
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 o=- 7736844526 7736842807 IN IP4
125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
RTP/AVP 4
}
} ; RTP profile for G723.1 is 4
}
}
} }MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555 Reply = 10005 {
Context = 2000 {Modify = A4444, Modify = A4445} }17. The two gateways are now connected and User 1 hears the RingBack 🔔🦋 MG2 waits until User2 picks up the receiver, and then the two-way call is established 🥹
From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555 Transaction = 50005 {
Context = 5000 {
Notify = A5555 {ObservedEvents =1234 {
19990729T22020002:al/of(init=false)}}
} }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(strict=state)},
Signals { } ; to turn off ringing
}
} }From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
Context = 5000 {Modify = A4445} }18. Time to switch MG1's mode 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}}19. The MGC decides to Audit the RTP termination on MG2 🔍
MGC -> MG2:
MEGACO/1 [123.123.123.4]:55555 Transaction = 50007 {
Context = - {AuditValue = A5556{
Audit{Media, DigitMap, Events, Signals, Packages, Statistics }}
} }20. MG2 replies 💅
MG2 -> MGC:
MEGACO/1 [125.125.125.111]:55555 Reply = 50007 {
Context = - { AuditValue = A5556 {
Media {
TerminationState { ServiceStates = InService,
Buffer = OFF },
Stream = 1 {
LocalControl { Mode = SendReceive,
nt/jit=40 },
Local { v=0 o=- 7736844526 7736842807 IN IP4
125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
RTP/AVP 4 a=ptime:30
},
Remote { v=0 o=- 2890844526 2890842807 IN IP4
124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
RTP/AVP 4 a=ptime:30
} } },
Events,
Signals,
DigitMap,
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
}
} }21. When the MGC gets an onhook signal from one of the MGs, it hangs up the call 📵 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(init=false)}
}
} }From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555 Reply = 50008 {
Context = - {Notify = A5555} }22. The MGC now sends both MGs a Subtract to take the call down 💀 Only the Subtracts to MG2 are shown here. Each termination gathers its own set of statistics. An MGC may not need to ask for 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
}
}
} }23. Last step: the MGC 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. If that's the case, no message need 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 🍓
APPENDIX II Changes From RFC 3015 🌸💅
In the following table, "source" indicates when the change was first approved. It has the following values:
IG1100: H.248 Implementor's Guide approved in November, 2000 (as TD Plen-39, Christian Groves, editor).
IG0601: H.248 Implementor's Guide approved in June, 2001 (as TD Plen-15, Christian Groves, editor).
IGDUB: Draft H.248 Implementor's Guide approved at the Q.3 Rapporteur's meeting held near Dublin, October 2001 (as TD-28, Terry Anderson, editor).
GEN0202: added at the Geneva meeting, February 2002, which consented to H.248 v1 Amendment 1 (as TD Plen-36r1, Marcello Pantaleo, editor).
ITUPOST: added in post-Geneva editing by the ITU-T.
Okay bestie, so Tom Taylor (the Megaco Chair) did some post-approval editing to get this doc ready for submission, and he's the reason a bunch of these changes are tagged TTPOST. 💅✨ Here's the full change table, untouched, so you can see exactly who changed what and where.
Section Source Change
1 ITUPOST Reference changed from H.248 to H.248.1.
2.1 ITUPOST Reference added for error codes, changed from
H.248 Annex L to H.248.8 (2002).
2.1 IG1100 Corrected Q.765 reference to Q.765.5.
2.1 GEN0202 Added reference to X.690.
2.2 GEN0202 Added reference to H.226.
2.2 IGDUB Added informative references to Q.724, Q.764,
and Q.1902.4.
4 IG0601 Added expansion of ALF.
5 TTPOST Gave priority to IETF conventions (added at
start of document).
6.1.1 IG0601 Added text regarding use of wildcards for
context identifiers. (This information
already appeared in section 8.1.2. The IG
change subsequently disappeared.)
6.1.1 IG1100 Added ranking of priority values.
6.2 IGDUB Deleted definition of signals.
6.2 GEN0202 Expanded text and diagrams describing
multiplexing terminations.
6.2 TTPOST Added asterisks to multiplexing diagrams to
indicate centre of context. Added Figure 6a
showing cascading of multiplexes.
6.2.2 IG0601 Added text indicating that ALL does not
include ROOT.
6.2.3 IG1100 Added text clarifying what must be supported
to claim support of a package.
6.2.3 IG1100 Added text indicating what packages a peer can
indicate support for, when some of them are
extensions of others.
6.2.4 IG0601 Added text on ability of provisioning to
override default values, and need for MGC to
audit to learn the provisioned defaults.
6.2.4 IG0601 Added text indicating effect of omitting
specific properties from Descriptors in
commands modifying a termination.
Contradicted original text saying that omitted
properties retain their prior values (still
true for entirely-omitted Descriptors).
6.2.4 GEN0202 Modified above text to restrict it to
read/write properties, allow for default
behaviour in place of default values if so
specified in the property definition.
6.2.4 IGDUB Trimmed definition of signals Descriptor in
table and inserted cross-reference to section
7.1.11.
6.2.4 IG1100 Added Topology and Error Descriptors to table.
6.2.5 IGDUB Specified error code to return if ROOT used
inappropriately.
7.1.1 IG1100 Added qualification to explanation of effect
of missing Audit Descriptor, excepting
Subtract.
7.1.3 GEN0202 Changed "inputs" to "bearers" to be consistent
with terminology in 6.2.
7.1.4 IG0601 Small change to make clear that more than one
of Local, Remote, and LocalControl can be
included in the default streamId.
7.1.7 IG0601 Default value for Mode specified to be
Inactive.
7.1.7 GEN0202 Added text requiring processing of media in
any of the reserved formats, where more than
one has been reserved in a given stream.
7.1.8 IGDUB Added restriction to at most one m= line per
session description.
7.1.9 IG0601 Text added to omit request identifier if the
EventsDescriptor is empty. Further text added
at end to indicate the effects of an empty
EventsDescriptor and an empty
EventBufferDescriptor.
7.1.9 IG0601 Fixed typo for destination of a Notify.
7.1.9 IG1100 Added note to say event remains active after
it has been notified, so long as it is still
present in the active Events Descriptor.
7.1.11 IGDUB Added definition of signals.
7.1.11 GEN0202 Modified definition to include example of more
complex signal, and added role of signal in
media preparation for future signals.
7.1.11 IGDUB The timeout completion reason was broadened to
include other circumstances where the signal
completed on its own. Text added to indicate
that if default signal type changed to TO,
duration parameter must be provided.
7.1.11 GEN0202 Removed reference to BR signal being "so
short" it will stop on its own. Added text
indicating that if the type of a signal is
changed to TO, the Duration parameter must be
supplied.
7.1.11 IG1100 Deleted text discussing type of Signals List.
7.1.12 GEN0202 Improved wording of introductory paragraph and
added text making content of returned
Descriptor clear.
7.1.14.2 GEN0202 Added text indicating that when the start
timer is set to 0, initial digit timing is
disabled and the MG waits indefinitely for
digits.
7.1.14.2 GEN0202 Added text pointing out that default digit
timer values should be provisioned, but can be
overridden in the digit map.
7.1.14.3 GEN0202 Changed result of long-short digit timer
conflict from undefined to long.
7.1.14.6 IG1100 Clarified that the digit map is provided by
the eventDM parameter, which must be present.
7.1.14.7 GEN0202 Added text clarifying that events covered by
the digit map completion event have no side-
effects unless separately enabled.
7.1.14.8 IG0601 Added requirement that the event specification
include the eventDM parameter.
7.1.17 IGDUB Added text to indicate timestamp is optional
and to include observed event parameters in
reported content.
7.1.17 GEN0202 Deleted provision that time is expressed in
UTC (since intention was to use format, not
time zone).
7.1.18 IGDUB Added text indicating error to return if
topology option not supported.
7.1.18 IG1100 Added text clarifying effect of not mentioning
TTPOST a termination in a topology Descriptor, and
default topology for a new termination. (This
text got lost between the Dublin meeting and
the production of H.248 Amendment 1 out of the
Geneva 02/02 meeting. It has been added back
to the present document.)
7.1.19 IG1100 New section to describe Error Descriptor.
GEN0202 Slightly edited in Geneva 02/02 meeting.
ITUPOST Reference for error code documentation updated
to H.248.8.
7.1.19 IG0601 Added paragraph giving guidance on level at
which errors should be reported.
7.2 IG1100 Noted possibility of Error Descriptor in reply
to any command.
7.2.1 IG1100 Added EventBufferDescriptor as Add parameter.
7.2.1 IG1100 Removed restriction on use of CHOOSE wildcard.
7.2.2 IG1100 Added EventBufferDescriptor as Modify
parameter.
7.2.2 GEN0202 Added text on side-effects of Modify of a
multiplexing termination.
7.2.3 IG1100 Added prohibition against subtracting from the
NULL context.
7.2.3 GEN0202 Added text on side-effects of Subtract of a
multiplexing termination.
7.2.3 IGDUB Added text clarifying effect of empty
AuditDescriptor in Subtract.
7.2.4 IG1100 Added EventBufferDescriptor as Move parameter.
7.2.4 GEN0202 Removed misleading statement that Move acts as
subtract from original context.
7.2.4 IG1100 Clarified effect of Move on properties of the
moved termination.
7.2.4 GEN0202 Added text on side-effects of Move of a
multiplexing termination.
7.2.5 IG1100 Added examples showing W- wildcard usage.
7.2.5 IG1100 Noted that returning a list of all contextIDs
requires that they be returned one per
ActionReply.
7.2.5 IG1100 Added table entry (ALL, specific) to determine
context in which termination currently
resides.
7.2.6 GEN0202 Added table similar to that in 7.2.5.
7.2.7 IG0601 Added TerminationID to API.
7.2.7 IGDUB Indicated timestamp was optional in Notify, to
accord with syntax.
7.2.7 IG1100 Noted possibility of sending Error Descriptor
in Notify.
7.2.8 IG0601 Added text to description of Forced method to
indicate that Forced on ROOT indicates a cold
restart (all context state lost).
7.2.8 IGDUB Amplified explanation of Disconnected method
to emphasize return to the previously
controlling MGC.
7.2.8 IG0601 Added text for MG use of Failover method when
it detects MGC failure.
7.2.8 IG1100 Added notes discouraging use of
ServiceChangeAddress and warning that it could
be either a full address or just a port
number.
7.2.8 IG0601 Added text indicating that timestamp does not
necessarily represent absolute time, only
local clock reading.
7.2.8 IGDUB Corrected "gateway" to "MGC" in discussion of
returned ServiceChangeMgcId parameter.
7.3 IG0601 Removed error code documentation to Annex L
ITUPOST (now H.248.8).
8 IG1100 Added requirement that an Action be non-empty.
8 GEN0202 Added context properties and context property
audit requests to commands as potential
contents of actions.
8.1.2 GEN0202 Added prohibition on using partial contextIDs
with ALL wildcards.
8.2.2 IG1100 Added text clarifying when in transaction
processing the requested actions have been
completed and a reply can be sent.
8.2.2 IG1100 Added ALL as allowed contextID in
TransactionReply.
8.2.2 GEN0202 Provided general reference to section 7.1.19
for generation of error Descriptors.Every row above is copied exactly, so the source tags and section numbers still line up. ✨ More changes are coming in the next part, so stay tuned 🦋🌸
Okay bestie, here's the changelog run-down 💅✨ Every row below is copied exactly as the original lists it, so the section numbers and initials are all still there. 🦋
8.2.2 IG0601 Corrected Actions to Commands when discussing
partially-understood action.
8.3 IG0601 Added text specifying that the same MId value
must be used by a given entity throughout the
life of a control association.
8.3 IG0601 Added text expanding on independence of
transactions from messages.
9 ITUPOST Indicated that additional transports may be
defined in separate Recommendations as well as
annexes to the primary specification.
9 IG0601 Gave specific example of "request source
address" for IP.
9.1 IG1100 Deleted restriction to one outstanding Notify
command on a termination at one time, since
this is transport-specific.
9.1 IG0601 Restored restriction, but noted that it
applied only to transport not guaranteeing
ordered delivery.
10.2 IG1100 Corrected length of synthesized address field
from 10 to 20 hex digits and indicated that
calculation should be over entire message, not
just one transaction.
11.2 IG1100 Corrected text in first two paragraphs
describing use of ServiceChangeMgcId
parameter.
11.2 IG1100 Corrected "Transaction Accept" to "Transaction
Reply".
11.4 IG0601 Noted that support of redundant MGs requires
GEN0202 use of a reliable transport and support in the
MGC. Added more explanation in Geneva.
11.5 IG0601 Added text clarifying procedure if MG unable
to establish a control relationship with any
of its eligible MGCs.
11.5 IGDUB Added text indicating that when trying to
reestablish contact with the previously
controlling MGC the MG uses the Disconnected
method.
11.5 IG1100 Clarified handoff procedure.
11.5 GEN0202 Changed text on replies to transactions in
progress during handoff. Replies now
discarded when the service relationship with
the old MGC has ended, rather than sent to the
new MGC. The new MGC could still send replies
to requests sent to the old MGC.
12.1.1 GEN0202 Added optional package designation as
"designed to be extended only".
12.1.1 IG1100 Made prohibition on overloading of identifiers
in extended packages transitive through all
ancestors of the extended package.
12.1.2 IGDUB Clarified the set of types allowed for
properties.
12.1.2 GEN0202 Added requirement to specify the base type of
a sub-list.
12.1.2 GEN0202 Provided requirements for content of the
"Possible Values" template item, including
specification of default values or behaviour.
12.1.4 GEN0202 Added requirement to specify the default
signal type, and specify a default duration
for TO signals. Also noted that duration is
meaningless for BR, and that the signal type
might be dependent on the values of other
signal parameters.
12.2 GEN0202 Fixed section title (covers only event and
signal parameters, not properties or
statistics).
12.2 IG1100 Reserved SPA and EPA prefixes, so they are not
to be used for signal and event parameter
tokens.
12.2 IG0601 Expanded list of reserved prefixes.
12.2 IGDUB Clarified the set of types allowed for signal
and event parameters.
12.2 GEN0202 Added requirement to specify the base type of
a sub-list.
12.2 GEN0202 Provided requirements for content of the
"Possible Values" template item, including
specification of default values or behaviour.
12.4 IGDUB Corrected to indicate identifiers must start
with alphabetic rather than alphanumeric
character.
13.1 IG0601 Changed private range of binary package
identifiers to convenient hex values.
A GEN0202 Removed versions from X.680 and X.690
references.
A.2 IGDUB Added note warning that the syntax alone does
not provide a complete description of the
constraints, but must be supplemented by a
reading of the text and comments.
A.2 IG0601 Added description of double wrapping of
parameters declared as OCTET STRING.
A.2 GEN0202 Some editing of double wrapping description to
use ASN.1, BER in their proper places. Added
possibility of encoding strings as UTF8String,
but only if they contain non-ASCII characters.
A.2 IGDUB Added line in table on double wrapping of true
octet strings.
A.2 IG1100 Corrected and expanded comments describing
mtpAddress form of MId. Fixed maximum length
of mtpAddress both here and in
ServiceChangeAddress.
A.2 IG0601 Inserted missing lines in IP4Address
production.
A.2 IG0601 Modified TransactionResponseAck to allow
acknowledgement of multiple ranges of
transactionIds.
A.2 IG0601 Corrected numerical value of CHOOSE as a
context identifier.
A.2 IGDUB Added missing extension marker in
TopologyRequest.
A.2 IG1100 AuditReply and AuditResult modified to bring
binary functionality into line with text
functionality.
A.2 IG0601 Removed OPTIONAL tag from terminationID in
NotifyReply.
A.2 IG0601 Added extraInfo substructure to EventParameter
and SigParameter.
A.2 IG0601 Modified MediaDescriptor to make it optional
to specify a stream.
A.2 IG0601 Added OPTIONAL tags to reserveValue and
reserveGroup.
A.2 IGDUB Added to comments for pkgdName to indicate
applicability to event names, signal names,
and statisticIds as well as property.
A.2 IG0601 RequestID made optional in EventsDescriptor
and SecondEventsDescriptor and comment added
saying it must be present if events are
present.
A.2 IG1100 Added OPTIONAL tags on RequestActions and
SecondRequestedActions keepActive BOOLEANs.
A.2 IG1100 Added comment to indicate requestID value to
use in an AuditCapReply.
A.2 GEN0202 Added comment to DigitMapValue indicating time
units for timers.
A.2 IG0601 Added comment indicating coding of Value for
GEN0202 ServiceChangeReason. Cleaned up in Geneva to
use ASN.1 and BER in their proper places.
A.2 IG0601 Inserted missing extension marker in
ServiceChangeParm production.
A.2 IG0601 Aligned definition of mtpAddress in
ServiceChangeAddress with that in MId.
A.2 IG0601 Added timestamp to ServiceChangeResParm.
A.2 IGDUB Changed type of profileName in
ServiceChangeProfile to IA5String.
A.2 IG0601 Made returned value optional in
statisticsParameter, to support
auditCapability result.
A.2 GEN0202 Added reference to ISO 8601:1988 for
TimeNotation.
A.2 IG1100 Value production modified to support the
sublist parameter type.
A.3 IG1100 Corrected ABNF for digitStringlisT, replacing
"/" with "|".
A.3 IG1100 Added parentheses to digitMapRange production.
A.3 IG1100 Replaced more abbreviated syntax for pathName
with fuller definition and constraints copied
from B.2.
B.2 IGDUB Added note warning that the syntax alone does
not provide a complete description of the
constraints, but must be supplemented by a
reading of the text and comments.
B.2 IG0601 Added note warning that the interpretation of
symbols is context-dependent.
B.2 IG1100 Added comment to indicate case insensitivity
of protocol (excepting SDP) and ABNF.
B.2 IG0601 Expanded upon and capitalized this comment.
B.2 IG0601 Lengthy note added on the coding of the VALUE
construct.
B.2 IGDUB Deleted sentence in note suggesting that
packages could add new types for properties,
parameters, or statistics.
B.2 IG0601 Added note indicating that parsers should
allow for white space preceding the first line
of SDP in Local or Remote.
B.2 IGDUB Added comments identifying the O- and W- tags.
B.2 IG1100 Moved wildcard tag up from individual commands
to commandRequestList.
B.2 GEN0202 Added additional error case to actionReply.
B.2 IG0601 Modified syntax of auditOther to allow return
of terminationID only.
B.2 IGDUB Corrected upper limit for V4hex.
B.2 IG1100 Corrected and expanded comments describing
mtpAddress form of MId.
B.2 IG0601 Modified comment to mediaParm to make
streamParms and StreamDescriptor mutually
exclusive.
B.2 GEN0202 Modified comment further to indicate at most
one instance of terminationStateDescriptor.
B.2 GEN0202 Expanded comment for streamParm to indicate
the restriction on repetition is per item.
B.2 IG0601 Modified "at most once" comments to localParm,
terminationStateParm, and modemType, to allow
multiple instances of propertyParm in the
first two cases and extensionParameter in the
last one.
B.2 IG0601 Added note before description of Local and
Remote, pointing out that the octet value x00
is not allowed in octetString.Okay so the changelog keeps going, and it's still giving detail bestie 💅📋
B.2 IG0601 Syntax for eventsDescriptor, embedFirst, and
eventBufferDescriptor modified to make
contents beyond token optional.
B.2 IGDUB Replaced "event" by "item" in comment to
pkgdName because pkgdName applies to
properties, signals, and statistics as well.
B.2 IG0601 Corrected placement of EQUAL in eventDM
production.
B.2 IG1100 Added comment and syntax to indicate requestID
value to use in an AuditCapReply.
B.2 IG1100 Corrected Modem Descriptor to allow package
items as properties.
B.2 IG0601 Comment to modemType changed to allow multiple
instances of extensionParameter.
B.2 GEN0202 Comment added to indicate units for Timer.
B.2 IG1100 Added parentheses to digitMapRange production.
B.2 IG1100 Added comment to serviceChangeParm, restricting
each parameter to one appearance.
B.2 IG0601 Added comments making serviceChangeMgcId and
serviceChangeAddress mutually exclusive in
ServiceChangeParm and servChgReplyParm.
B.2 IGDUB Added comment to serviceChangeParm indicating
that ServiceChangeMethod and
ServiceChangeReason are required.
B.2 IG0601 Added Timestamp to servChgReplyParm.
B.2 IG0601 Added comment indicating coding of Value for
ServiceChangeReason.
B.2 IG0601 Modified ServiceChangeAddress to use MId
definition for full address.
B.2 IG1100 Made returned value optional in
statisticsParameter, to support
auditCapability result.
B.2 IG1100 Changed topologyDescriptor to allow multiple
triples.
B.2 IG0601 Added comment forbidding use of a double quote
within a quotedString value.
B.2 IG1100 Reserved prefixes for new tokens added to
signalParameter and eventParameter, to avoid
collision with package names.
B.2 IG1100 EmbedToken and EmergencyToken changed to
remove clash with EventBufferToken.
B.3 IG1100 New section describing hexadecimal octet
encoding.
B.4 IG1100 New section describing hex octet sequence.
C IG1100 Added permission to use Annex C properties in
LocalControl as well as in Local and Remote.
C IG0601 Added text making support of all properties of
Annex C optional.
C IGDUB Added directions to reconcile tabulated
formats with allowed types for properties.
C.1 IG1100 Corrected Q.765 reference to Q.765.5 for
ACodec.
C.1 IG1100 Deprecated Echocanc codepoint in favour of
package-defined property.
C.4 ITUPOST Updated references from Q.2961 to Q.2961.1.
C.4 IGDUB Added details on format of VPVC.
C.9 IG1100 Renamed USI to layer1prot.
C.9 IG1100 Deprecated ECHOCI codepoint in favour of
package-defined property.
C.9 IG1100 Added new USI property.
C.11 IG1100 Added m= line tag.
D.1 IG0601 Added explanation of ALF.
D.1.5 IGDUB Expanded text indicating that when trying to
reestablish contact with the previously
controlling MGC the MG uses the Disconnected
method.
E.1.2 GEN0202 Added missing EventsDescriptor parameters
lines.
E.1.2 GEN0202 For the Signal Completion event:
- corrected the description of how it is
enabled
- heavily edited the description of the Signal
Identity observed event parameter and added a
type.
E.1.2 IGDUB The timeout completion reason for the Signal
Completion event was broadened to include
other circumstances where the signal completed
on its own.
E.1.2 IG1100 Added signal list ID observed event parameter
to the Signal Completion event.
E.2.1 IG0601 Added missing read only, read-write
specifications.
E.2.1 IG0601 Split ProvisionalResponseTimer properties into
one for MG, one for MGC.
E.3 GEN0202 Added "Designed to be extended only" to
tonegen package description.
E.4 GEN0202 Added "Designed to be extended only" to
tonedet package description.
E.4.2 GEN0202 Added type for tone ID observed parameter for
Long Tone Detected event.
E.6.2 IG1100 Corrected binary identifier for digit map
completion event to avoid clash with base
package.
E.6.2 IG1100 Removed procedural text.
E.6.5 IG1100 Added procedural text indicating where to find
the applicable digit map and indicating the
error to return if the parameter is missing.
E.6.5 IG0601 Further modified procedural text.
E.7.3 IG1100 Corrected text identifier for payphone
recognition tone to avoid clash with base
package.
E.10.5 IGDUB Provided informative references for tones and
procedures for continuity check.
E.13 GEN0202 Added note that TDM package could also apply
to other transports.
E.13.1 IG1100 Changed default for echo cancellation from
"on" to provisioned.
E.13.1 IG0601 Corrected type for gain property.
Appendix TTPOST Included a number of corrections which were
I not picked up in H.248.1 Amendment 1 but which
do appear in H.248.1 v2.Intellectual Property Rights ✨
The ITU wants everyone to know that using or implementing this RFC might touch a claimed Intellectual Property Right 🔐 The ITU takes no position on whether those claims are valid, provable, or applicable, whether they come from ITU members or from people outside the Recommendation development process.
As of the day this RFC was approved, the ITU had been notified of patented intellectual property that might be needed to implement it. Implementors are warned that this info might be out of date, so they're strongly urged to check the TSB patent database 👀
The IETF has also been notified of IP claims about Megaco/H.248.1. Go check the IETF IPR announcements at http://www.ietf.org/ipr.html 🎀
Acknowledgments 🫶
Megaco/H.248.1 is the result of a LOT of hard work from so many people in both the IETF and ITU-T Study Group 16 🌸 This section celebrates the people who played a big role in ITU-T meetings, on the Megaco list, or both.
Megaco/H.248 owes a huge initial debt to the MGCP protocol (RFC 2705), so a big thank you to its authors: Mauricio Arango, Andrew Dugan, Ike Elliott, Christian Huitema, and Scott Pickett 💜 Flemming Andreasen isn't on that author list, but he was a major contributor to developing both MGCP and Megaco/H.248.1, so he absolutely deserves the flowers 💐 RFC 3435 has a big acknowledgement section for the many other people who worked on media gateway control before Megaco even got started 🧚
The authors of the first Megaco RFCs (2805, then 3015) were Fernando Cuervo, Nancy Greene, Abdallah Rayhan, Christian Huitema, Brian Rosen, and John Segers 🦋 Christian Groves came up with Annex C and was its editor, iconic ✨ The people most active on the Megaco list before RFC 2885 was finished were Brian Rosen, Tom Taylor, Nancy Greene, Christian Huitema, Matt Holdrege, Chip Sharp, John Segers, Michael Thomas, Henry Sinnreich, and Paul Sijben 🔥
Then there's the February 2000 Study Group 16 meeting, which was so intense that people gave up sleep and meals to finish the massive pile of work 😭 Those legends were Michael Brown, Ranga Dendi, Larry Forni, Glen Freundlich, Christian Groves, Alf Heidemark, Steve Magnell, Selvam Rengasami, Rich Rubin, Klaus Sambor, John Segers, Chip Sharp, Tom Taylor, and Stephen Terrill 👑
Since February 2000, the most active people on the Megaco list have been Tom Taylor, Brian Rosen, Christian Groves, Madhu Babu Brahmanapally, Troy Cauble, Terry Anderson, Chuong Nguyen, and Kevin Boyle, though lots of other people have been regular contributors too 🌈 Brian Rosen did tremendous service by putting together the Megaco interoperability tests, obsessed with him honestly 🙌 On the Study Group 16 side, the editorial team for the final revised document in February 2002 was Christian Groves, Marcello Pantaleo, Terry Anderson, Peter Leis, Kevin Boyle, and Tom Taylor 💅
Tom Taylor, as Megaco Chair, ran the day to day operation of the Megaco list, and Brian Rosen took an equal share of that burden for most of the last three years 🫶 Glen Freundlich, as the Study Group 16 Rapporteur, ran the ITU-T meetings and made sure all the work got done. Without Glen's determination, the Megaco/H.248 standard would have taken at least half a year longer 🍓 Christian Groves filled in really well as Rapporteur when Glen couldn't take part anymore 🥹
Authors' Addresses 📮
Terry L. Anderson:
Terry L. Anderson
24 Hill St
Bernardsville, NJ 07924
USA
EMail: tlatla@verizon.netChristian Groves:
Christian Groves
Ericsson AsiaPacificLab Australia
37/360 Elizabeth St
Melbourne, Victoria 3000
Australia
EMail: Christian.Groves@ericsson.com.auMarcello Pantaleo:
Marcello Pantaleo
Ericsson Eurolab Deuschland
Ericsson Allee 1
52134 Herzogenrath, Germany
EMail: Marcello.Pantaleo@eed.ericsson.seTom Taylor:
Tom Taylor
Nortel Networks
1852 Lorraine Ave,
Ottawa, Ontario
Canada K1H 6Z8
Phone: +1 613 736 0961
EMail: taylor@nortelnetworks.comFull Copyright Statement ✨
okay bestie, this is the legal bit, so I'm keeping every word exactly as written 💅 The copyright and disclaimer stuff has to stay complete and accurate, so here's the whole notice, no edits:
Copyright (C) The Internet Society (2003). 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.
heads up: the copyright notice has to go with any copies or derivative works, and this document can't be modified in any way, so don't touch the original text 🙈
Acknowledgement 🌸
funding for the RFC Editor function is currently provided by the Internet Society 🫶
📦 where this page comes from
- ietf: rfc3525 2003-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms