RFC 3441
Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)
RFC 3441: Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP) 💖
okay bestie, this is RFC 3441 and it's giving ATM realness for MGCP 🎀✨. Here's the tea from the title block: it's by R. Kumar at Cisco Systems, it's dated January 2003, and it's in the Informational category 🦋. Informational means it's sharing info with the Internet community, not an actual standard. It doesn't specify an Internet standard of any kind 💅. The title block doesn't list anything it obsoletes or updates, so it's a standalone doc 🌸.
Status of This Memo ✨
ok so this memo gives info to the Internet community 📚. It does not specify an Internet standard of any kind, and it's unlimited to distribute, so share the wealth 🫶.
Copyright Notice 🎀
Copyright (C) The Internet Society (2003). All Rights Reserved. Mine? Nah, the Internet Society's 😌.
Abstract 🦋
so this doc describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP) 🔥. The package brings new Local Connection Options, ATM-specific events and signals, and ATM connection parameters ✨. It also covers codec and profile negotiation 💜. It extends the MGCP that's already getting deployed in a bunch of products 🧚. Implementers should keep an eye on what's happening in the IETF Megaco Working Group and ITU SG16, since they're cooking up a possible successor to this protocol 👀💀.
Table of Contents 🌈
1.0 Conventions Used in this Document..............................2
2.0 Introduction...................................................2
3.0 Local Connection Options.......................................3
3.1 ATM Bearer Connection.........................................4
3.2 ATM Adaptation Layer (AAL)....................................8
3.3 Service Layer................................................15
3.4 ATM Bearer Traffic Management................................19
3.5 AAL Dimensioning.............................................27
4.0 Signals and Events.............................................30
5.0 Connection Parameters..........................................35
6.0 Negotiation of Profiles and Codecs in ATM Applications.........37
6.1 Consistency of Parameters...................................37
6.2 Codec/Profile Negotiation in ATM Networks...................38
7.0 Security Considerations.......................................45
8.0 IANA Considerations...........................................45
9.0 References....................................................45
10.0 Acronyms......................................................48
11.0 Acknowledgements..............................................49
12.0 Author's Address..............................................49
13.0 Full Copyright Statement......................................501.0 Conventions Used in this Document ✨
ok the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are read the way BCP 14, RFC 2119 says 🙈. That's the rule for how to interpret them 💅.
MGCP identifiers are case-insensitive 🍓. That covers package names, event names, local connection options, and every other element of the MGCP header 🫶.
2.0 Introduction 🦋
okay so MGCP [36] is how external call control elements control voice media gateways 📞. Even if the bearer network is IP, ATM, TDM, or a mix of those, MGCP itself gets transported over IP 🌐. Packages like the MGCP CAS packages [38] are modular sets of parameters (connection options, signal, event, and statistics definitions) that extend MGCP into specific contexts 🧩. There's also a related IP-based mechanism for describing ATM connections [18], which the IETF MMUSIC group came up with 💖. Since MGCP device control is so IP-centric, and to stay consistent with other MGCP package definitions, it makes sense to publish the MGCP ATM package in an IETF document 🎀.
MGCP [36] lets you audit endpoints for the package versions they support 👀. The MGCP ATM package in this doc is version 0 🔢. Even when ATM is the default package for some endpoints, the package prefix "atm" shall not be omitted from local connection option names, event names, signal names, and so on 🙅♀️. If ATM is the default package for an endpoint, it shows up as the first package in the audit response list 📋. And you don't need the ATM package to be the default in order for ATM to be supported on an endpoint 💅.
The ATM package in this doc has Local Connection Options (Section 3.0), Events and Signals (Section 4.0), and ATM Statistics Parameters (Section 5.0) 🎁. Section 6.1 has guidelines for keeping Local Connection Options consistent 🧠. Section 6.2 covers codec and profile negotiation 🎶. Section 7.0 handles security considerations 🔐, and you should absolutely read it 😭.
In the ATM networks this doc is about, services ride directly over ATM with no IP layer in between 🛤️. The Local Connection Options, Events, Signals, and Statistics Parameters described in this section aren't needed for VoIP calls that might be carried, fully or partly, over an ATM network 📵. For those, the constructs defined elsewhere for IP are enough ✨.
The ATM local connection option names, event names, and signal names MUST always have an "atm" package prefix 🚨. Backward compatibility with older implementations that use X-atm as the package name is desirable 💜.
MGCP grammar [36] must be followed when it comes to white space 🫧. The examples in this doc try to follow MGCP grammar in this and every other way too 🌸.
3.0 Local Connection Options 🎀
so the Local Connection Options (LCOs) in this section are specific to ATM applications 💅. Like other LCOs, you can use them in commands to create connections, modify connections, and audit connections 🔧. The catch is that, unless noted otherwise below, they are not to be returned when an endpoint gets audited for capabilities 🙈.
ATM Local Connection Options are split into these categories: ATM bearer connection, ATM adaptation layer, service layer, ATM bearer traffic management, and AAL dimensioning 🗂️✨.
When parameter values are written in decimal format, leading zeros get dropped 🔢🫶.
3.1 ATM Bearer Connection ✨
okay so these local connection options are the ones that set up the vibe for ATM bearer connections 🫶 bestie, the whole thing is in this table:
+---------+---------------+---------------------------------------+
| LCO | Meaning | Values |
+---------+---------------+---------------------------------------+
| ct | Connection |AAL1, AAL1_SDT, AAL1_UDT, AAL2, AAL3/4,|
| | Type |AAL5, USER_DEFINED_AAL |
+---------+---------------+---------------------------------------+
| vc |VC/Bearer type | PVC, SVC, CID |
+---------+---------------+---------------------------------------+
| se | Enable path | on, off |
| | set-up | |
+---------+---------------+---------------------------------------+
| ci | Connection | See below |
| | Element | |
| | Identifier | |
+---------+---------------+---------------------------------------+Connection type (ct) 💅: this one describes the ATM adaptation layer. The possible values are AAL1, AAL1_SDT, AAL1_UDT, AAL2, AAL3/4, AAL5 and USER_DEFINED_AAL. The user defined adaptation layer comes from amendment 2 of ITU-T Q.2931 🎀
Type of Bearer/VC (vc) 🦋: this tells you whether a PVC, a CID or an SVC is going to be used for an ATM connection. The possible values are PVC, SVC or CID. If you leave this one out, you get a default, which could be embedded or provisioned 🙈 The PVC value covers both classical PVCs and SPVCs. The CID value covers subchannels inside AAL1 [35] and AAL2 [10] virtual circuits. A value of SVC for atm/vc does not necessarily mean that the addressed media gateway should start signaling for bearer set-up, since another node, like the far-end media gateway, might handle that instead ✨
Enable path set-up (se) 🌸: this local connection option is how you explicitly turn bearer signaling on or off for path set-up. The permitted values are "on" and "off". Examples of bearer signaling are SVC signaling, ITU Q.2630.1 signaling and combinations of those. Some combos are setting up an AAL2 SVC and then assigning a CID inside it, or setting up a concatenation of an AAL2 single-CID SVC and a CID channel inside a multiplexed AAL2 VC. This parameter works with both the backward and forward bearer connection set-up methods. In the backward one, the call-terminating gateway sets up the bearer connection. In the forward one, the call-originating gateway sets up the bearer connection 👑
This option may or may not be used together with atm/sc event notification. When this option and the atm/sc event notification are both left out, the call agent is basically deferring any decision about setting up an ATM or AAL2 connection to the media gateways 🧚 If this parameter is absent, a media gateway's autonomous decision to set up an ATM or AAL2 path through bearer signaling depends on default or provisioned behaviors. Those include whether a bearer connection set-up model applies and whether it's backward or forward, plus the network type (nt), connection type (atm/ct) and bearer type/VC (atm/vc) local connection options. It also depends on whether the media gateway knows if it's the originating or terminating gateway in a call. That awareness may come from whether an SDP remote connection descriptor is present or absent in the initial create connection command 💜
Connection Element Identifier (ci) 🍓: this indicates the Virtual Circuit or CID to be used for the bearer connection. It gets used when the call agent manages VC and/or CID resources in the bearer network 💖
The ci parameter can come in one of the following formats:
VCCI-<vcci>
VCCI-<vcci>/CID-<cid>
<ATMaddressType>-<ATMaddress>/VCCI-<vcci>
<ATMaddress>/VCCI-<vcci>
<ATMaddressType>-<ATMaddress>/VCCI-<vcci>/CID-<cid>
<ATMaddress>/VCCI-<vcci>/CID-<cid>
BCG-<bcg>/VCCI-<vcci>
BCG-<bcg>/VCCI-<vcci>/CID-<cid>
BCG-<bcg>/VPI-<vpi>/VCI-<vci>
BCG-<bcg>/VPI-<vpi>/VCI-<vci>/CID-<cid>
PORT-<portId>/VPI-<vpi>/VCI-<vci>
PORT-<portId>/VPI-<vpi>/VCI-<vci>/CID-<cid>
VPCI-<vpci>/VCI-<vci>
VPCI-<vpci>/VCI-<vci>/CID-<cid>
<ATMaddressType>-<ATMaddress>/VPCI-<vpci>/VCI-<vci>
<ATMaddress>/VPCI-<vpci>/VCI-<vci>
<ATMaddressType>-<ATMaddress>/VPCI-<vpci>/VCI-<vci>/CID-<cid>
<ATMaddress>/VPCI-<vpci>/VCI-<vci>/CID-<cid>Here's the breakdown of the subparameters for ci 🎀 (this table is exact, don't touch it!):
|--------------|-----------------------|----------------------------|
| Subparameter | Meaning | Representation |
|--------------|-----------------------|----------------------------|
| vcci | VC connection Id | Decimal Integer |
| | | (16-bit equivalent) |
|--------------|-----------------------|----------------------------|
| cid | Channel Id | Decimal Integer |
| | | (8-bit equivalent) |
|--------------|-----------------------|----------------------------|
|ATMaddressType| ATM address type | "NSAP", "E164", "GWID", |
| | | "ALIAS" |
|--------------|-----------------------|----------------------------|
| ATMaddress | ATM address | 40 hex digits ("NSAP") |
| | | upto 15 digits ("EI64") |
| | | upto 32 chars ("GWID") |
| | | upto 32 chars ("ALIAS") |
|--------------|-----------------------|----------------------------|
| bcg |Bearer Connection Group| Decimal Integer |
| | | (8-bit equivalent) |
|--------------|-----------------------|----------------------------|
| vpi | Virtual Path Id | Decimal Integer |
| | | (8 or 12-bit equivalent) |
|--------------|-----------------------|----------------------------|
| vci | Virtual Channel Id | Decimal Integer |
| | | (16-bit equivalent) |
|--------------|-----------------------|----------------------------|
| portID | Port Id | Decimal Integer |
| | | (32-bit equivalent) |
|--------------|-----------------------|----------------------------|
| vpci | VP connection ID | Decimal Integer |
| | | (16-bit equivalent) |
|--------------|-----------------------|----------------------------|The CID, or Channel ID, 🩵 can refer to AAL1 as well as AAL2 applications. In AAL1 applications based on [35], it points to the octet position, starting from one, inside an n x 64 SDT frame.
The VPCI is a 16 bit field defined in Section 4.5.16 of ITU Q.2931. It's kind of like the VPI, except it's wider and it keeps its value across VP crossconnects ✨ The VCCI is a 16 bit field defined in ITU Recommendation Q.2941.2 [14]. It's similar to the VCI, except it keeps its value across VC crossconnects 🦋
In general, <vpci> and <vcci> values are unique between a pair of nodes. When they're unique between a pair of nodes but not unique within a network, they need to be qualified at any node by the ATM address of the remote node. These parameters can be pre-provisioned or signaled through SVC signaling messages. When VPCI and VCCI values are pre-provisioned, administrations have the option of provisioning them uniquely across a network. In that case, the ATM address of the far end isn't needed to qualify these parameters 🫶
The <portId> parameter identifies the physical trunk port on an ATM module. It can be written as a decimal or hex number of up to 32 digits 🔥
In some applications, it makes sense to bundle a set of connections between a pair of ATM nodes into a bearer connection group. The <bcg> subparameter is an eight bit field that lets you bundle up to 255 VPCs or VCCs 💅
In some applications, you need to wildcard some elements of the ci local connection option. The "$" wildcard character can replace some of the terms in this parameter. When you wildcard, the constant strings that qualify the terms in the ci parameter stay put. The <ATMaddressType>-<ATMaddress> concatenation can be wildcarded in these ways:
- The entire concatenation,
<ATMaddressType>-<ATMaddress>, is replaced with a"$". <ATMaddress>is replaced with a"$", but<ATMaddressType>is not.
Examples of wildcarding the ci parameter in the AAL1 and AAL5 contexts are VCCI-$ and BCG-100/VPI-20/VCI-$.
Examples of wildcarding the ci parameter in the AAL2 context are VCCI- 40/CID-$ and BCG-100/VPI-20/VCI-120/CID-$.
If the addressType is NSAP, the address is written in the standard dotted hex form 🌈 It's a string of 40 hex digits, with dots after the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th digits. The "0x" prefix isn't used, since it's always hex. The last octet of the NSAP address is the 'selector' field, which is available for non-standard use. For example:
L: atm/ci:NSAP-47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00/
VCCI-65If the ATMaddressType is E164, the ATMaddress is written as a decimal number with up to 15 digits. For example:
L: atm/ci:E164-9738294382/VCCI-100The E.164 numbers used can be in the International Format E.164 or follow a private numbering plan 🌸
If the ATMaddressType is GWID, it means the address is a Gateway Identifier or Node Alias. That may or may not be globally unique. In this format, the ATMaddress is written as an alphanumeric string ("A"-"Z", "a"-"z", "0" - "9", ".", "-", "_"). For example:
L: atm/ci:GWID-officeABCmgx101vism12The keyword "ALIAS" can be swapped in for "GWID". For example:
L: atm/ci:ALIAS-officeABCmgx101vism12An example of a GWID (ALIAS) is the CLLI code used for telecom equipment 🧚 For all practical purposes, it should be fine for the GWID (ALIAS) to be a variable length string with a maximum size of 32 characters.
Audit time 👑: when an endpoint that supports the ATM package gets audited for capabilities, the local connection options from Section 3.1 shall be returned: connection type (atm/ct) and VC/bearer type (atm/vc). If more than one value is supported, they shall be returned as a list of semicolon-separated values. Although it's not super useful, it's allowed for these values to have overlapping meanings (for example, AAL1 and AAL1_SDT) 💀 Here's an example of an audit response returning the local connection options defined in Section 3.1:
A: atm/ct:AAL1_SDT;AAL2, atm/vc:PVC;CID3.2 ATM Adaptation Layer (AAL)
These local connection options are the knobs that tune the ATM adaptation layer (AAL) 🎀 and they come in three flavours: generic AAL ones, AAL1-related ones, and AAL2-related ones. ngl the AAL5 side is kinda empty rn 🥺 because there are currently no local connection options in this category that pertain to AAL5.
Here's the generic lineup 💖
TABLE 2: Generic Local Connection Options for the AAL
+---------+---------------+---------------------------------------+
| LCO | Meaning | Values |
+---------+---------------+---------------------------------------+
| aalApp | Application |itu_h323c,af83,AAL5_SSCOP, |
| | |itu_i3661_unassured, itu_i3661_assured |
| | |itu_i3662, itu_i3651, itu_i3652, |
| | |itu_i3653, itu_i3654, |
| | |FRF5, FRF8, FRF11,itu_h2221 |
+---------+---------------+---------------------------------------+
| sbc | Subchannel | 1...24 for T1-based applications |
| | Count | 1...31 for E1-based applications |
+---------+---------------+---------------------------------------+aalApp is the one that says which controlling standard sits above the AAL 🦋 Other strings can be defined too, but if you make your own, it has to start with "X-" 🫶 Here are the built-in values:
"itu_h323c"means Annex C of H.323, which specifies direct RTP on AAL5 [12]."af83"means af-vtoa-0083.001, which specifies variable size AAL5 PDUs with PCM voice and a null SSCS [13]."AAL5_SSCOP"means SSCOP as defined in ITU Q.2110 [14] running over an AAL5 CPS [27]. No information is provided regarding any layers above SSCOP, such as Service Specific Coordination Function (SSCF) layers 🤷♀️"itu_i3661_unassured"means SSCS with unassured transmission, per ITU I.366.1 [11]."itu_i3661_assured"means SSCS with assured transmission, per ITU I.366.1 [11]. This uses SSCOP [14]."itu_i3662"means SSCS per ITU I.366.2 [2]."itu_i3651"means Frame relay SSCS per ITU I.365.1 [15]."itu_i3652"means Service-specific coordination function, as defined in ITU I.365.2, for Connection Oriented Network Service (SSCF-CONS) [16]. This uses SSCOP [14]."itu_i3653"means Service-specific coordination function, as defined in ITU I.365.3, for Connection Oriented Transport Service (SSCF-COTS) [17]. This uses SSCOP [14]."itu_i3654"means Service-specific coordination function, as defined in ITU I.365.4 [28]."FRF5"means use of the FRF.5 frame relay standard [23], which references ITU I.365.1 [15]."FRF8"means use of the FRF.8 frame relay standard [24]. This implies a null SSCS and the mapping of the frame relay header into the ATM header 🧚"FRF11"means use of the FRF.11 frame relay standard [25]."itu_h2221"means use of the ITU standard H.222.1 for audiovisual communication over AAL5 [22] 📺
sbc (subchannel count) is the number of DS0s in an n x 64 connection 🌈 These connections use an ATM adaptation layer 1 (ATM forum af-vtoa-78) or 2 (ITU I.366.2). For T1-based applications it can be any integral value in the inclusive range [1...24]. For E1-based applications it can be any integral value in the inclusive range [1...31]. When this parameter is omitted, the subchannel count must be known by other means 👀
Now the AAL Type 1 options 💜
TABLE 3: Local Connection Options for AAL Type 1
+---------+---------------+---------------------------------------+
| LCO | Meaning | Values |
+---------+---------------+---------------------------------------+
| pf | Partial fill | 1...48 |
| | | |
+---------+---------------+---------------------------------------+
| crt | Clock Recovery| NULL, SRTS, ADAPTIVE |
| | Type | |
+---------+---------------+---------------------------------------+
| fe | FEC enable | NULL, DELAY_SENSITIVE,LOSS_SENSITIVE |
+---------+---------------+---------------------------------------+Partial Fill Count (pf) shows up as the fill level of cells when it's present 🍓 If this local connection option is absent, then other means (such as provisionable defaults) decide whether partial fill happens and how full it is.
This parameter counts the non-pad payload octets, not including any AAL SAR or convergence sublayer octets. For example, in some AAL1 applications that use partially filled cells with padding at the end, this attribute counts the leading payload octets, not including any AAL overhead.
In general, permitted pf values are integers in the range 1 - 48 inclusive. The upper bound changes between adaptations, though, since the AAL overhead (if any) is different. If a specified partial fill (e.g. 47) is greater than or equal to the maximum fill (46 in this example, for AAL1 P-cells), then complete fill (46 in this example) is used. A 'partial' fill of 48 effectively disables partial fill. Values below or above the permissible range of 1-48 MUST be rejected with an error code of 532 {Unsupported value(s) in LocalConnectionOptions} ❗
In the AAL1 context, this parameter applies uniformly to both P and non-P cells. In AAL1 applications that don't distinguish between P and non-P cells, a value of 47 means complete fill (the absence of partial fill). In AAL1 applications that do distinguish between P and non-P cells, a value of 46 means no padding in P-cells and a padding of one in non-P cells.
If partial fill is enabled (meaning there is padding in at least some cells), then AAL1 structures must not be split across cell boundaries. They shall fit in any cell, so their size shall be less than or equal to the partial fill size. Further, the partial fill size is preferably an integer multiple of the structure size. If it isn't, then the partial fill size stated in the local connection options shall be truncated to an integer multiple of the structure size (e.g., a partial fill size of 40 gets truncated to 36 to support six 6 x 64 channels) 🧮
Clock recovery type (crt) is only used in AAL1 UDT (unstructured data transfer) applications 🕰️ It can be assigned "NULL", "SRTS", or "ADAPTIVE". A value of "NULL" is equivalent to omitting this parameter and implies that the stream (T1 or E1) encapsulated in ATM is either synchronous to the ATM network or is re-timed, before AAL1 encapsulation, via slip buffers. The default value used when this LCO is absent can be hardcoded or provisioned.
Forward Error Correction Enable (fe) indicates whether FEC, as defined in ITU I.363.1 [1], is enabled or not 🛡️ Possible values are "NULL", "DELAY_SENSITIVE" and "LOSS_SENSITIVE". FEC can be enabled differently for delay-sensitive and loss-sensitive connections. A "NULL" value implies disabling FEC for an AAL1 connection.
And last but not least, the AAL Type 2 options 🫧
TABLE 4: Local Connection Options for AAL Type 2
+---------+---------------+---------------------------------------+
| LCO | Meaning | Values |
+---------+---------------+---------------------------------------+
| pfl | Profile List | See below |
| | | |
+---------+---------------+---------------------------------------+
| smplCPS | Simplified CPS| on, off |
| | [21] | |
+---------+---------------+---------------------------------------+
| tmcu | Combined use | Integer microseconds |
| | timer | (32-bit equivalent) |
+---------+---------------+---------------------------------------+
| aalsap |Service access | AUDIO, MULTIRATE |
| |point | |
+---------+---------------+---------------------------------------+
| cktmd | Circuit mode | on, off |
| | | |
+---------+---------------+---------------------------------------+
| frmd | Frame mode | on,off |
| | enable | |
+---------+---------------+---------------------------------------+
| genpcm | Generic PCM | PCMA, PCMU |
| | setting | |
+---------+---------------+---------------------------------------+
| ted | Transmission | on,off |
| |error detection| |
+---------+---------------+---------------------------------------+
|rastimer | SSSAR | |
| | reassembly | Integer microseconds |
| | timer | (32-bit equivalent) |
+---------+---------------+---------------------------------------+Profile List (pfl) is a list of profiles 📜 Profile types are followed by profile numbers for each type. The ordering can imply preference, with the most preferred profile first. The same profile type can show up more than once in this list. Spaces are the delimiters inside this list, so to comply with MGCP syntax [36], you have to enclose the whole list in double quotes 💅
The format of the pfl parameter looks like this:
"<profileType#1><format list#1><profileType#2><format list#2> ...
<profileType #M><format list#M>"where <format list#i> has the form <profile#i_1>...<profile#i_N>.
The <profileType> parameter indicates the type of profile. It's expressed in the format AAL2/<profileClass>, where <profileClass> identifies the source of the definition of the profile.
The <profileClass> can be assigned a string value indicating the source of the subsequent profile numbers until the next <profileType> field. The following rules apply to the contents of the <profileClass> field:
okay so the profile class is basically the name tag on each AAL2 profile 💅 here's how the options work 🫶
<profileClass>="ITU"indicates profiles defined by ITU. Examples: profiles defined in the I.366.2 specification [2].<profileClass>="ATMF"indicates profiles defined by ATM forum. Examples: profiles defined in af-vtoa-0113 [3] or af-vmoa-0145.000 [21].<profileClass>="custom"indicates profiles defined by a corporation or a multi-vendor agreement. Since there is no standard administration of this convention, care SHOULD be taken to preclude inconsistencies within the scope of a deployment 🙈<profileClass>=<corporateName>An equipment vendor or service provider can use its registered, globally unique corporate name (e.g., Cisco, Telcordia etc.) as a string value of the<profileClass>. It is suggested that organizations maintain consistent definitions of the advertised AAL2 profiles that bear their corporate name 🎀- The
<profileClass>can be based on IEEE Standard 802-1990, Section 5.1, which defines the globally unique, IEEE-administered, three-octet OUIs used in MAC addresses and protocol identifiers. In this case, the<profileClass>field SHALL be assigned a string value of"IEEE:"concatenated with<oui>where<oui>is the hex representation of a three-octet field identical to the IEEE OUI. Since this is always represented in hex, the"0x"prefix is not used. Leading zeros MAY be omitted. For example,"IEEE:00000C"and"IEEE:C"both refer to Cisco Systems, Inc. 🧚
The <profile#> parameter is expressed as a decimal number in the range 1-255 ✨
Here's an example of the pfl parameter in action 💖
L: atm/pfl:"AAL2/ITU 8 AAL2/ATMF 7 8 AAL2/custom 100 AAL2/cisco 200"The syntax for pfl can be represented compactly in the following ABNF (RFC2234) form 🦋
pfl = "%x22" 1*(profileType (1*profile#))"%x22"
profileType = "AAL2/" profileClass space
profile# = 1-255 space ; decimal integer followed by space
profileClass =
"ATMF"/"ITU"/"custom"/corporateName/("IEEE:" oui)
corporateName = 1*ALPHA ;one or more alphanumeric characters
oui = 1*6 HEXDIG; 1-6 hex digits per IEEE Standard 802-1990
space = %d32Simplified CPS (smplCPS): this turns on the AAL2 CPS simplification described in [21] 🌸 It can be assigned the following values: on, off. Under this simplification, each ATM cell contains exactly one AAL2 packet. If necessary, octets at the end of the cell are padded with zeros 🍓
AAL2 combined use timer (tmcu): this is defined in ITU I.363.2 [10] ⭐ It is an integer number of microseconds, represented as the decimal equivalent of 32 bits.
AAL service access point (aalsap): the service access point for AAL2 is defined in ITU I.366.2 [2]. The aalsap local connection option can take on the following string values: AUDIO, MULTIRATE 🎧
Circuit mode (cktmd): this is used to enable circuit mode data [2]. It can be assigned a value of "on" or "off" 🔥
Frame mode (frmd): this is used to enable frame mode data [2]. It can be assigned a value of "on" or "off" 👑
Generic PCM setting (genpcm): this indicates whether generic PCM encoding in AAL2 profiles is A-law or Mu-law. It can be assigned the string values of "PCMA" and "PCMU" 🌈
Transmission error detection (ted): transmission error detection is defined in ITU I.366.1 [11]. The ted local connection option can take on the following values: on, off. This local connection option is useful in qualifying the aalApp local connection option, when the value of the latter is "itu_i3661_unassured" 💜
SSSAR reassembly timer (rastimer): this is defined in ITU I.366.1 [11] ✨ It is an integer number of microseconds, represented as the decimal equivalent of 32 bits.
okay now the audit part, which is kinda the main event 👀 When an endpoint supporting the ATM package gets audited for capabilities, the following local connection options from Section 3.2 SHALL be returned: application (atm/aalApp). Further, if one of the values atm/ct is "AAL2", the following additional local connection options SHALL be returned: profile list (atm/pfl), simplified CPS (atm/smplCPS), service access point (atm/aalsap), circuit mode enable (atm/cktmd), frame mode enable (atm/frmd) and generic PCM setting (atm/genpcm). If more than one value is supported, these SHALL be expressed as a list of semicolon-separated values. For atm/smplCPS, atm/cktmd and atm/frmd, an audit can return "on", "off" or "on;off" depending on whether the mode is mandatory, unsupported or optional for the endpoint 🎀
Here's an example of what an audit response looks like, returning the local connection options defined in Section 3.2 💅✨
A: atm/aalApp:itu_i3662, atm/pfl:"AAL2/ATMF 7 8", smplCPS:on;off,
aalsap:MULTIRATE, cktmd:off, frmd:off, genpcm:PCMU;PCMA3.3 Service Layer ✨
okay bestie, this is where the codec drama lives 💅 Table 5 lists the local connection options for the service layer, and yes, I'm keeping it exactly as it is:
TABLE 5: Local Connection Options for the Service Layer
+--------------+---------------+----------------------------------+
| LCO | Meaning | Values |
+--------------+---------------+----------------------------------+
| vsel | Voice codec | See below |
| | Selection | |
+--------------+---------------+----------------------------------+
| dsel | Data codec | See below |
| | Selection | |
+--------------+---------------+----------------------------------+
| fsel | Fax codec | See below |
| | Selection | |
+--------------+---------------+----------------------------------+
| ccnf | Codec | Even number (4 - 32) hex digits |
| | Configuration | |
+--------------+---------------+----------------------------------+
| usi | ISUP User | Two hex digits |
| | Information | |
+--------------+---------------+----------------------------------+Voice codec selection (vsel): this is a prioritized list of one or more 3-tuples describing voice service 🎤 Each vsel 3-tuple indicates a codec, an optional packet length and an optional packetization period.
The vsel local connection option is structured like this:
"<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>"Here <encodingName> refers to a codec name such as PCMU, G726-32, G729 etc. See [18] and [34] for a list of codecs with static payload types 🎀 The <packetLength> is a decimal integer representation of the packet length in octets. The <packetTime> is a decimal integer representation of the packetization interval in microseconds.
Voiceband data codec selection (dsel): this is a prioritized list of one or more 3-tuples describing voiceband data passthrough service 🔌 Each dsel 3-tuple indicates a codec, an optional packet length and an optional packetization period. Depending on the application, the dsel local connection option may or may not cover facsimile service. This gets flagged with an <fxIncl> flag placed in front of the list of 3-tuples. The flag tells you whether the dsel list explicitly addresses facsimile ("on" value) or doesn't ("off" value). It can also be set to "-", which is the same as setting it to "off" 🙈
If <fxIncl> is "on", then it is rarely useful to also include an fsel option. However, it is syntactically correct to do so, as long as the dsel and fsel options include an identical set of 3-tuples, perhaps in a different order.
If <fxIncl> is "off", then any fsel list may still be ignored if the media gateway does not provide separate treatment of voiceband data passthrough and fax. Since, in this case, there is no distinct facsimile service from the media gateway's perspective, any fsel list does not apply 💀
The dsel local connection option is structured like this:
"<fxIncl> <encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>"Same deal as before: <encodingName> refers to a codec name such as PCMU, G726-32, G729 etc. The <packetLength> is a decimal integer representation of the packet length in octets. The <packetTime> is a decimal integer representation of the packetization interval in microseconds.
Facsimile codec selection (fsel): this is a prioritized list of one or more 3-tuples describing fax service 📠 Each fsel 3-tuple indicates a codec, an optional packet length and an optional packetization period. If the dsel option includes facsimile, the fsel connection option should be consistent with it. Each fsel 3-tuple indicates a codec, an optional packet length and an optional packetization period (yes, that line is repeated in the original, and yes, I'm keeping it 😭). The fsel local connection option is structured like this:
"<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>"Here <encodingName> refers to a codec name such as PCMU, G726-32, G729 etc. The <packetLength> is a decimal integer representation of the packet length in octets. The <packetTime> is a decimal integer representation of the packetization interval in microseconds.
Since spaces are used as delimiters within the vsel, dsel and fsel lists, it is necessary to enclose these lists in double quotes [36]. Main character energy about punctuation 🎀
The vsel, fsel and dsel parameters complement the rest of the local connection options and should be consistent with them 🫶
Examples of how these look in practice:
L: atm/vsel:"G729 10 10000 G726-32 40 10000"
L: atm/dsel:"off PCMA 10 10000 G726-32 40 10000"
L: atm/fsel:"PCMU 40 5000 G726-32 20 5000"
L: atm/vsel:"G729 10 10000 G726-32 40 10000"
L: atm/dsel:"on PCMA 10 10000 G726-32 40 10000"The <packetLength> and <packetTime> can be set to "-" when they aren't needed. A <fxIncl> value of "-" is equivalent to setting it to "off". For example:
L: atm/vsel:"G729 - - G726-32 - -"
L: atm/dsel:"- G729 - - G726-32 - -"
L: atm/fsel:"G729-24 - -"The vsel, dsel and fsel local connection options can be used in the AAL1, AAL2 and AAL5 contexts 🌈 The <packetLength> and <packetTime> are not meaningful in the AAL1 case and should be set to "-". In the AAL2 case, these local connection options indicate the preferred use of some or all of the rows in a given profile table. If multiple 3-tuples are present, they can indicate a preferentially ordered assignment of some rows in that profile to voice, voiceband data passthrough or facsimile service (e.g., row A preferred to row B etc). If multiple profiles are specified in the pfl parameter (described in section 3.2), the profile qualified by these local connection options is the first profile in the list ⭐
Codec configuration (ccnf): this is used to convey the contents of the single codec information element (IE) defined in [30]. The contents of this IE are: a single-octet Organizational Identifier (OID) field, followed by a single-octet Codec Type field, followed by zero or more octets of a codec configuration bit-map. The semantics of the codec configuration bit-map are specific to the organization [30, 31]. Since this bit-map is always represented in hex format, the "0x" prefix is omitted. Leading zeros are not omitted 🧚 For example:
L: atm/ccnf:01080CThis indicates an Organizational Identifier of 0x01 (the ITU-T). Using [57], the second octet (0x08) indicates a codec type of G.726 (ADPCM). The last octet, 0x0C, indicates that 16 kbps and 24 kbps rates are NOT supported, while the 32 kbps and 40 kbps rates ARE supported 🔥
ISUP User Information (usi): this is used to convey the contents of the 'User Information Layer 1 protocol' field within the bearer capability information element defined in Section 4.5.5 of [32], and reiterated as the user service information element (IE) in Section 3.57 of [33]. The 'User Information Layer 1 protocol' field consists of the five least significant bits of Octet 5 of this information element.
The usi LCO is represented as a string of two hex digits. The "0x" prefix is omitted since this value is always hexadecimal. These hex digits are constructed from an octet with three leading '0' bits and the last five bits equal to the 'User Information Layer 1 protocol' field described above. Digits to the left are more significant than digits to the right. The resulting values of the usi local connection option are as follows:
VALUE MEANING
0x01 CCITT standardized rate adaption V.110 and X.30
0x02 Recommendation G.711 Mu-law
0x03 Recommendation G.711 A-law
0x04 Recommendation G.721 32 kbps ADPCM
and Recommendation I.460
0x05 Recommendations H.221 and H.242
0x06 Recommendation H.223 and H.245
0x07 Non-ITU-T standardized rate adaption
0x08 ITU-T standardized rate adaption V.120
0x09 CCITT standardized rate adaption X.31 HDLC flag stuffing3.4 ATM Bearer Traffic Management 🦋
These local connection options are used to convey ATM traffic parameters 💜
TABLE 6: Local Connection Options for ATM bearer traffic management
+---------+---------------+---------------------------------------+
| ATM LCO | Meaning | Values |
+---------+---------------+---------------------------------------+
| atc | ATM transfer |CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR, |
| | capability or |DBR,SBR,ABT/IT,ABT/DT |
| | service | |
| | category | |
+---------+---------------+---------------------------------------+
| sbt |atc subtype | 1...5 |
+---------+---------------+---------------------------------------+
| qos | QoS class | 0...5 |
+---------+---------------+---------------------------------------+
| bcob |Broadband | 0...31 |
| |Connection |(Defined values listed below) |
| |-Oriented | |
| |Bearer Class | |
+---------+---------------+---------------------------------------+
| eetim |End-to-end |on,off |
| |timing required| |
+---------+---------------+---------------------------------------+
| stc |Susceptibility | 0...3 |
| |to clipping |(Defined values listed below) |
+---------+---------------+---------------------------------------+
| upcc |User plane |0...3 |
| |connection |(Defined values listed below) |
| |configuration | |
+---------+---------------+---------------------------------------+
+---------+---------------+---------------------------------------+
| aqf |ATM QoS | List, see below |
| |parameters, | |
| |forward | |
| |direction | |
+---------+---------------+---------------------------------------+
| aqb |ATM QoS | List, see below |
| |parameters, | |
| |backward | |
| |direction | |
+---------+---------------+---------------------------------------+
| adf0+1 |ATM traffic | List, see below |
| |descriptor, | |
| |forward | |
| |direction, | |
| |CLP-independent| |
+---------+---------------+---------------------------------------+
| adf0 |ATM traffic | List, see below |
| |descriptor, | |
| |forward | |
| |direction, | |
| |CLP=0 | |
+---------+---------------+---------------------------------------+
| adb0+1 |ATM traffic | List, see below |
| |descriptor, | |
| |backward | |
| |direction, | |
| |CLP-independent| |
+---------+---------------+---------------------------------------+
| adb |ATM traffic | List, see below |
| |descriptor, | |
| |backward | |
| |direction, | |
| |CLP=0 | |
+---------+---------------+---------------------------------------+
| abrf |ABR parameters,| List, see below |
| |forward | |
| |direction | |
+---------+---------------+---------------------------------------+
| abrb |ABR parameters,| List, see below |
| |backward | |
| |direction | |
+---------+---------------+---------------------------------------+
|abrSetup |ABR connection | List, see below |
| |set-up | |
| |parameters | |
+---------+---------------+---------------------------------------+okay so, ATM transfer capability (atc) 💖 is the ATM Transfer Capability from ITU I.371 [19], which is basically the same thing as the ATM Service Category in the UNI 4.1 Traffic Management spec [8] 🦋. If you're working with I.371, atc can be DBR, SBR, ABT/IT, ABT/DT, or ABR. If you're working with the UNI 4.1 Traffic Management spec, it can be CBR, nrt-VBR, rt-VBR, UBR, ABR, or GFR. ✨
Subtype (sbt) qualifies the atc option 🎀. It takes integer values from 1...5, and these combos of atc and sbt are meaningful:
atc sbt Resulting transport
CBR/DBR 1 Voiceband signal transport (ITU G.711, G.722, I.363)
CBR/DBR 2 Circuit transport (ITU I.363)
CBR/DBR 4 High-quality audio signal transport (ITU I.363)
CBR/DBR 5 Video signal transport (ITU I.363)
nrt-VBR 1 nrt-VBR.1
nrt-VBR 2 nrt-VBR.2
nrt-VBR 3 nrt-VBR.3
rt-VBR 1 rt-VBR.1
rt-VBR 2 rt-VBR.2
rt-VBR 3 rt-VBR.3
UBR 1 UBR.1
UBR 2 UBR.2
GFR 1 GFR.1
GFR 2 GRR.2
SBR 1 SBR1
SBR 2 SBR2
SBR 3 SBR3Subtypes for the atc values of CBR or DBR are per [29] 🌸. Subtypes for the remaining atc values are per [8] and [19]. Easy peasy 💅.
QoS class (qos) is the QoS class from ITU I.2965.1 [4] 👑. It's a decimal integer from 0 - 5, and the values map like this:
----------------------------------------------------------
| VALUE | MEANING |
----------------------------------------------------------
| 0 | Default QoS |
----------------------------------------------------------
| 1 | Stringent |
----------------------------------------------------------
| 2 | Tolerant |
----------------------------------------------------------
| 3 | Bi-level |
----------------------------------------------------------
| 4 | Unbounded |
----------------------------------------------------------
| 5 | Stringent bi-level |
----------------------------------------------------------Broadband Connection-Oriented Bearer Class (bcob) 🦋 points at the bearer class from ITU Q.2961.2 [5]. It's a decimal number from 0 - 31, or its hex equivalent (0x0 - 0x1F). These are the values defined so far:
----------------------------------------------------------
| VALUE | MEANING |
----------------------------------------------------------
| 1 | BCOB-A |
----------------------------------------------------------
| 3 | BCOB-C |
----------------------------------------------------------
| 5 | Frame relaying bearer service |
----------------------------------------------------------
| 16 | BCOB-X |
----------------------------------------------------------
| 24 | BCOB-VP (transparent VP service) |
----------------------------------------------------------End-to-end timing (eetim) just tells you whether end-to-end timing is required (that's Table 4-8 of [29]) ⏰. It can be set to "on" or "off" 🫶.
Susceptibility to clipping (stc) is the local connection option that says how vulnerable a connection is to clipping 🙈. It's a decimal number from 0 - 3, or its hex equivalent (0x0 - 0x3). Every value that isn't listed below is reserved, so hands off 🚫.
----------------------------------------------------------
| VALUE | MEANING |
----------------------------------------------------------
| 0 | Not susceptible to clipping |
----------------------------------------------------------
| 1 | Susceptible to clipping |
----------------------------------------------------------User plane connection configuration (upcc) 🌈 is a decimal number from 0 - 3, or its hex equivalent (0x0 - 0x3). Again, anything not listed below is reserved 💀.
----------------------------------------------------------
| VALUE | MEANING |
----------------------------------------------------------
| 0 | Point to point |
----------------------------------------------------------
| 1 | Point to multipoint |
----------------------------------------------------------ATM QoS parameters for the forward direction (aqf) and backward direction (aqb) 🍓 are where it gets a little detailed. Forward means the direction away from the media gateway, and backward means the direction towards the gateway. If the bearer signaling at the gateway uses a different directional convention, then appropriate translations must be done by the media gateway. These parameters have this format:
"<cdvType><acdv><ccdv><eetd><cmtd><aclr>"Since spaces are used in this list, it must be enclosed in double quotes for MGCP compliance [36] 🎀. Don't forget those quotes, bestie 😭.
The <cdvType> parameter can be the string value "PP" or "2P". These refer to the peak-to-peak and two-point CDV as defined in UNI 4.0 [6] and ITU Q.2965.2 [7] respectively 🧚.
The CDV parameters, <acdv> and <ccdv>, are the acceptable and cumulative CDVs. They're in microseconds and written as the decimal or hex equivalent of 24-bit fields 🔥. They use the cell loss ratio, <aclr>, as the "alpha" quantiles defined in the ATMF TM 4.1 specification [8] and in ITU I.356 [9] 💜.
The transit delay parameters, <eetd> and <cmtd>, are the end-to-end and cumulative transit delays, measured in milliseconds. ✨ Each one is written as the decimal equivalent of a 16-bit field. 🎀 They're defined in Q.2965.2 [7], UNI 4.0 [8] and Q.2931 [29]. 💖
The <aclr> parameter covers the forward and backward acceptable cell loss ratios. 🦋 It's the number of cells lost divided by the number of cells transmitted, so it's basically a "how many cells went missing" vibe. 🌸 It's written as the decimal or hex equivalent of an 8-bit field. The field encodes an order of magnitude n, where n is an integer from 1 to 15, and the Cell Loss Ratio ends up being 10 raised to the power of minus n. 🔥
If any of these parameters isn't specified, doesn't apply, or is implied, it gets set to "-". 💅
Here are some examples of the aqf and aqb local connection options in action:
L: atm/aqf:"PP 8125 3455 32000 - 11"
L: atm/aqb:"PP 4675 2155 18000 - 12"Let's decode the first one, bestie. 🧚 It means a forward acceptable peak-to-peak CDV of 8.125 ms, a backward acceptable peak-to-peak CDV of 4.675 ms, forward cumulative peak-to-peak CDV of 3.455 ms, and a backward cumulative peak-to-peak CDV of 2.155 ms. It also sets a forward end-to-end transit delay of 32 ms and a backward end-to-end transit delay of 18 ms. The forward cumulative transit delay is unspecified, and so is the backward one. 🙈 The forward cell loss ratio is 10 raised to minus 11, and the backward cell loss ratio is 10 to the minus 12. Iconic. 👑
ATM traffic descriptors come in four flavours: forward direction CLP=0+1 (adf0+1), backward direction CLP=0+1 (adb0+1), forward direction CLP=0 (adf0), and backward direction CLP=0 (adb0). 🌈 "Forward" means away from the media gateway, and "backward" means towards the gateway. ⭐ If the bearer signaling at the gateway uses a different directional convention, the media gateway has to do the translations. The adf0+1, adb0+1, adf0 and adb0 options all follow this format:
"<pcr><scr><mbs><cdvt><mcr><mfs><fd><te>"Spaces separate the values in these lists, so the whole thing has to be wrapped in double quotes to keep MGCP happy [36]. 🫶
These parameters are defined per the ATMF TM 4.1 specification [8]. ✨ Any of them can be set to "-" if you don't want to specify it through MGCP. Table 7 gives you the quick version. 🍓
TABLE 7: ATM Traffic Descriptor Parameters
PARAMETER MEANING UNITS
pcr Peak Cell Rate Cells per second
scr Sustained Cell Rate Cells per second
mbs Maximum Burst Size Cells
cdvt Cell Delay Variation Tolerance Microseconds
mcr Minimum Cell Rate Cells per second
mfs Maximum Frame Size Cells
fd Frame Discard Allowed on/off
te CLP tagging enabled on/offThe pcr, scr, cdvt and mbs can each be written as the decimal equivalent of a 24-bit field. 💜 The mbs and mfs can also be written as the decimal equivalent of a 16-bit field. 🔥
Here are examples of these local connection options:
L: atm/adf0+1:"200 100 20 - - - on -",
atm/adf0:"200 80 15 - - - - off",
atm/adb0+1:"200 100 20 - - - on -",
atm/adb0:"200 80 15 - - - - off"Okay, let's read the first line. 🦋 It means a forward and backward PCR of 200 cells per second for all cells no matter what CLP is, and a forward and backward PCR of 200 cells per second for cells with CLP=0. The forward and backward SCR is 100 cells per second for all cells regardless of CLP, and 80 cells per second for cells with CLP=0. The forward and backward MBS is 20 cells for all cells regardless of CLP, and 15 cells for cells with CLP=0. The CDVT is unspecified, which means it can be known by other means. 💅 The MCR and MFS are unspecified because they don't apply. Frame discard is enabled in both directions, and tagging is off in both directions. Literally so clean. 🌸
ABR parameters come in two flavours too: forward direction (abrf) and backward direction (abrb). 🎀 Again, "forward" is away from the media gateway and "backward" is towards it. ✨ If the bearer signaling convention at the gateway is different, the media gateway needs to translate. The abrf and abrb options look like this:
"<nrm><trm><cdf><adtf>"Spaces are used in these lists, so they go inside double quotes for MGCP compliance [36]. 🫶 These ABR parameters are defined per [6] and [8], and Table 8 has the summary. In MGCP they're written as the decimal equivalent of the binary fields below. If you want to leave any of them unspecified, set it to "- ". 🙈
TABLE 8: ABR Parameters
+-----------+---------------------------------+-----------------------+
| PARAMETER | MEANING | FIELD SIZE |
+-----------+---------------------------------+-----------------------+
| NRM | Maximum number of cells per | 3 bits |
| | forward Resource Management cell| |
+-----------+---------------------------------+-----------------------+
| TRM | Maximum time between | 3 bits |
| |forward Resource Management cells| |
+-----------+---------------------------------+-----------------------+
| CDF | Cutoff Decrease Factor | 3 bits |
+-----------+---------------------------------+-----------------------+
| ADTF | Allowed Cell Rate Decrease | 10 bits |
| | Time Factor | |
+-----------+---------------------------------+-----------------------+ABR set-up parameters (abrSetup) are used to indicate the ABR parameters needed during call or connection establishment. 🌈 You'll find that in Section 10.1.2.2 of the UNI 4.0 signaling specification [6]. The abrSetup option has this format:
"<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>"There's only one list here, so it needs double quotes for MGCP compliance [36]. ⭐ These parameters are defined per [6], and Table 9 has the quick definitions. Again, "forward" is away from the media gateway and "backward" is towards it. If the bearer signaling convention at the gateway is different, the media gateway has to translate. And if you want to leave any of them unspecified, set it to "- ". 💖
TABLE 9: ABR Set-up Parameters
+-----------+----------------------------------+---------------------+
| PARAMETER | MEANING | REPRESENTATION |
+-----------+----------------------------------+---------------------+
| <ficr> | Forward Initial Cell Rate | Decimal equivalent |
| |(Cells per second) | of 24-bit field |
+-----------+----------------------------------+---------------------+
| <bicr> | Backward Initial Cell Rate | Decimal equivalent |
| | (Cells per second) | of 24-bit field |
+-----------+----------------------------------+---------------------+
| <ftbe> | Forward transient buffer | Decimal equivalent |
| | exposure (Cells) | of 24-bit field |
+-----------+----------------------------------+---------------------+
| <btbe> | Backward transient buffer | Decimal equivalent |
| | exposure (Cells) | of 24-bit field |
+-----------+----------------------------------+---------------------+
| <crmrtt> | Cumulative RM round-trip time | Decimal equivalent |
| | (Microseconds) | of 24-bit field |
+-----------+----------------------------------+---------------------+
| <frif> | Forward rate increase factor | Decimal integer |
| | (used to derive cell count) | 0 -15 |
+-----------+----------------------------------+---------------------+
| <brif> | Backward rate increase factor | Decimal integer |
| | (used to derive cell count) | 0 -15 |
+-----------+----------------------------------+---------------------+
| <frdf> | Forward rate decrease factor | Decimal integer |
| | (used to derive cell count) | 0 -15 |
+-----------+----------------------------------+---------------------+
| <brdf> | Backward rate decrease factor | Decimal integer |
| | (used to derive cell count) | 0 -15 |
+-----------+----------------------------------+---------------------+3.5. AAL Dimensioning ✨
okay so this section is all about dimensioning the AAL 🎀 Table 10 lists the Local Connection Options (LCOs) that you use to size things up. quick heads up on directions: forward means away from the media gateway, and backward means towards the media gateway 🧚 every one of these values is a decimal integer, and the allowed ranges are right there in the table 💅
+---------+---------------+---------------------------------------+
| LCO | Meaning | Values (Decimal Integer) |
+---------+---------------+---------------------------------------+
| str | Structure | 1...65,535 |
| | Size | |
+---------+---------------+---------------------------------------+
+---------+---------------+---------------------------------------+
| cbrRate | CBR rate | Bit map per Table 4-6 of [29] |
+---------+---------------+---------------------------------------+
| fcpcs | Forward | AAL2: 45 or 64 |
| | maximum CPCS | AAL5: 1-65,535 |
| | SDU size | |
+---------+---------------+---------------------------------------+
| bcpcs | Backward | AAL2: 45 or 64 |
| | maximum CPCS | AAL5: 1-65,535 |
| | SDU size | |
+---------+---------------+---------------------------------------+
|fSDUrate | Forward | 24-bit equivalent |
| | maximum AAL2 | |
| | CPS SDU rate | |
+---------+---------------+---------------------------------------+
|bSDUrate | Backward | 24-bit equivalent |
| | maximum AAL2 | |
| | CPS SDU rate | |
+---------+---------------+---------------------------------------+
| ffrm |Forward maximum| 1-65,535 |
| |frame block | |
| |size | |
+---------+---------------+---------------------------------------+
| bfrm |Backward | 1-65,535 |
| |maximum frame | |
| |block size | |
+---------+---------------+---------------------------------------+
|fsssar |Forward maximum| 1-65,568 |
| |SSSAR-SDU | |
| |size | |
+---------+---------------+---------------------------------------+
|bsssar |Backward | 1-65,568 |
| |maximum SSSAR | |
| |SDU size | |
+---------+---------------+---------------------------------------+
|fsscopsdu|Forward maximum| 1-65,528 |
| |SSCOP-SDU | |
| |size | |
+---------+---------------+---------------------------------------+
| | | |
|bsscopsdu|Backward | 1-65,528 |
| |maximum SSCOP | |
| |SDU size | |
+---------+---------------+---------------------------------------+
|fsscopuu |Forward maximum| 1-65,524 |
| |SSCOP-UU field | |
| |size | |
+---------+---------------+---------------------------------------+
+---------+---------------+---------------------------------------+
|bsscopuu |Backward | 1-65,524 |
| |maximum SSCOP | |
| |UU size | |
+---------+---------------+---------------------------------------+Structured Data Transfer Block Size (str) 🌸 this one only matters when structured AAL1 is in use. It tells you the size (in octets) of the block used for structured data transfer. if it isn't included as a local connection option, the structure size has to be figured out some other way. for example, af-vtoa-78 [20] fixes the structure size for n x 64 service, with or without CAS. the L: atm/str parameter is coded as the decimal equivalent of a 16-bit field [29]. the theoretical max is 65,535, but most services use way less, ngl 💖
CBR Rate (cbrRate) 🦋 this is a hexadecimal version of the bit map from Table 4-6 of ITU Q.2931 [29]. it's always exactly two hex digits. for example:
L: atm/cbrRate:04that one implies a CBR rate of 1.544 Mbps ✨
Forward maximum CPCS-SDU size (fcpcs) 🎀 the biggest the AAL2 or AAL5 CPCS SDU can be in the forward direction.
Backward maximum CPCS-SDU size (bcpcs) 🎀 same deal, but for the backward direction.
Forward maximum AAL2 CPCS-SDU rate (fSDUrate) 🍓 the max rate of AAL2 CPCS-SDUs going forward.
Backward maximum AAL2 CPCS-SDU rate (bSDUrate) 🍓 and the max rate going backward.
okay bestie, the fSDUrate and bSDUrate options can be used to rate-limit AAL2 CIDs 🔥 they're especially handy in the SSSAR [1] and frame mode [2] contexts.
Forward maximum frame mode block size (ffrm) 💜 the biggest the AAL2 frame mode data unit (I.366.2) [2] can be in the forward direction.
Backward maximum frame mode block size (bfrm) 💜 same thing, backward.
Forward maximum SSSAR-SDU size (fsssar) 🌈 the max size of the AAL2-based SSSAR-SDU (I.366.1) [1] going forward.
Backward maximum SSSAR-SDU size (bsssar) 🌈 and backward.
Forward maximum SSCOP-SDU size (fsscopsdu) 🧚 the max size of the AAL2-based SSCOP-SDU (I.366.1) [1] going forward.
Backward maximum SSCOP-SDU size (bsscopsdu) 🧚 and backward.
Forward maximum SSCOP-UU size (fsscopuu) ⭐ the max size of the AAL2-based SSCOP-UU field (I.366.1) [1] going forward.
Backward maximum SSCOP-UU size (bsscopuu) ⭐ and the backward version, same field, same citation 🫶
4.0 Signals and Events ✨
Okay bestie, so the signals and events in this package use the standard MGCP syntax and keywords [36], and they're all lined up in Table 11 💅. They're all connection events, so you can't request them on endpoints 🙈. To stay consistent with MGCP [36], the suffix @<connection-id> is required and it NOT getting dropped, even when an endpoint has only one connection 🎀. You can also wildcard it using the usual MGCP rules 🦋.
There are no auditable event-states in the ATM package 💜.
Set-up complete ("sc") 🌸
Inside the RequestedEvents (R:) structure, "sc" asks for a heads-up when an ATM or AAL2 connection set-up succeeds ✨. The ATM or AAL2 bearer path is ready to carry subscriber payload once that notification goes out 🫶.
This could be an SVC being set up, an AAL2 CID path being assigned, or a mix of the two. Some examples are setting up an AAL2 SVC and assigning a CID inside it, or setting up a concatenation of an AAL2 single-CID SVC and a CID channel inside a multiplexed AAL2 VC 🧚.
This event is only here for backward compatibility 🙈. The call agent and the media gateway are meant to lean on provisional acknowledgements when set-up has a long latency. However, if this event is requested, the media gateway must send the set-up notification through this event. In that case, a provisional acknowledgement isn't very useful, and the full acknowledgement of the create connection or modify connection doesn't need to wait for the connection to be set up 💅.
The designated trigger for ATM or AAL2 connection set-up is an "on" value for the L: atm/se local connection option, which comes with a create or modify connection command 🔥. That said, some applications use the presence of an atm/sc event notification to kick off the set-up of an ATM or AAL2 connection, and that's totally recognized 👑.
TABLE 11: Signals and Events in the ATM package
|---------------|-----------------------|-----|------|--------------|
| SYMBOL | DEFINITION | R | S | DURATION |
|---------------|-----------------------|-----|------|--------------|
| sc | Bearer path set-up | C | | |
| | complete | | | |
|---------------|-----------------------|-----|------|--------------|
| sf | Bearer path set-up | C | | |
| | failed | | | |
|---------------|-----------------------|-----|------|--------------|
| ec | Enable CAS via | | oo | |
| | type 3 packets | | | |
|---------------|-----------------------|-----|------|--------------|
| etd | Enable DTMF tone | | oo | |
| | forwarding via | | | |
| | packets | | | |
|---------------|-----------------------|-----|------|--------------|
| etm | Enable MF tone | | oo | |
| | forwarding via | | | |
| | packets | | | |
|---------------|-----------------------|-----|------|--------------|
| etr1 | Enable MF-R1 tone | | oo | |
| | forwarding via | | | |
| | packets | | | |
|---------------|-----------------------|-----|------|--------------|
| etr2 | Enable MF-R2 tone | | oo | |
| | forwarding via | | | |
| | packets | | | |
|---------------|-----------------------|-----|------|--------------|
| uc (string) | Used codec changed | C | | |
| | to codec named by | | | |
| | the string | | | |
|---------------|-----------------------|-----|------|--------------|
| ptime (#) | Packetization period | C | | |
| | changed to # | | | |
|---------------|-----------------------|-----|------|--------------|
|---------------|-----------------------|-----|------|--------------|
| pftrans (#) | Profile element | C | | |
| | changed to row # | | | |
|---------------|-----------------------|-----|------|--------------|
| cle (#) | Cell Loss | C | | |
| | threshold (# ) | | | |
| | exceeded | | | |
|---------------|-----------------------|-----|------|--------------|
| pl (#) | Packet Loss Threshold| C | | |
| | exceeded (# ) | | | |
|---------------|-----------------------|-----|------|--------------|
| qa | Quality Alert | C | | |
| | | | | |
|---------------|-----------------------|-----|------|--------------|
| of (#) | Operation failure: | C | | |
| | Loss of connectivity | | | |
| | with reason code # | | | |
-------------------------------------------------------------------Set-up failed ("sf") 🥀
Inside the RequestedEvents (R:) structure, "sf" asks for notification when an ATM or AAL2 connection set-up fails 😭. The ATM or AAL2 connection set-ups that "sf" covers are the same ones covered by the "sc" event 🎀.
In some ATM or AAL2 applications that use SVC set-up or bearer-signalled AAL2 path assignment, the "sf" event might not get used 🙈. In those cases, you've got these options:
- the call agent receives a spontaneous delete from the media gateway with an appropriate reason code (902).
- the call agent receives the
"of"event described below with the optional reason code (902).
Enable CAS via type 3 packets ("ec") 📞
This signal tells the media gateway to forward CAS signaling via type 3 packets on an AAL2 connection 💖. It doesn't stop the call agent from asking for notifications about CAS state changes too 🦋. When the gateway gets this signal request, it keeps a bidirectional type 3 CAS protocol running over the AAL2 path 🔄. That stops when the request gets cancelled through a later NotificationRequest command, or when the VoAAL2 connection gets deleted 🛑.
Enable DTMF tones via type 3 packets ("etd") ☎️
A gateway will ignore this signal request if it already forwards and receives DTMF tones via type 3 packets 🙃. Otherwise, this signal tells the media gateway to forward and receive DTMF tones via type 3 packets on an AAL2 connection 🎶. It doesn't stop the call agent from requesting DTMF tone notifications either 💅.
Enable MF tones via type 3 packets ("etm") 🎵
A gateway will ignore this signal request if it already forwards and receives MF tones via type 3 packets 🙈. Otherwise, this signal tells the media gateway to forward and receive MF tones via type 3 packets on an AAL2 connection 🌈. It doesn't stop the call agent from requesting MF tone notifications. This signal request doesn't say which MF tone type is in use, since that's known by other means 🧠.
Enable R1 MF tones via type 3 packets ("etr1") 🎀
A gateway will ignore this signal request if it already forwards and receives R1 MF tones via type 3 packets 💅. Otherwise, this signal tells the media gateway to forward and receive R1 MF tones via type 3 packets on an AAL2 connection ✨. It doesn't stop the call agent from requesting R1 MF tone notifications 🫶.
Enable R2 MF tones via type 3 packets ("etr2") 🦋
A gateway will ignore this signal request if it already forwards and receives R2 MF tones via type 3 packets 🙈. Otherwise, this signal tells the media gateway to forward and receive R2 MF tones via type 3 packets on an AAL2 connection 🧚. It doesn't stop the call agent from requesting R2 MF tone notifications 👑.
Used codec changed ("uc (string)") 🎤
If armed via an R:atm/uc, a media gateway reports a codec change through an O:atm/uc 🔥. The alphanumeric string in parentheses is optional. It's the encoding name of the codec that the switch goes to 💜. This event works with every ATM adaptation (AAL1, AAL2 and AAL5), but:
- The pftrans event is a better fit for AAL2 applications 🌸.
- Codec switches don't usually happen mid-call in AAL1 applications 🙈.
Packet time changed ("ptime(#)") ⏱️
If armed via an R:atm/ptime, a media gateway reports a packetization period change through an O:atm/ptime ✨. The decimal number in parentheses is optional. It's the new packetization period in milliseconds 💖. In AAL2 applications, the pftrans event can cover packetization period changes (and codec changes too) 🧚.
Profile element changed ("pftrans(#)") 🔄
If armed via an R:atm/pftrans, a media gateway reports a mid-call profile element change through an O:atm/ptime 🎀. This event is used with AAL2 adaptation only 💅. A profile element is a row in a profile table 📋. Profile elements that indicate silence should not trigger this event 🤫. The decimal number in parentheses is optional. It's the row number that the switch goes to 🌈. Rows are counted downward, starting from 1 ⬇️.
Cell loss exceeded ("cle(#)") 🧮
This event means the cell loss rate is over the threshold #. If the threshold is left out of the requested events and observed events parameters, it's known by other means 🔍. The optional decimal number is how many cells get dropped per 100,000 cells. For example, cle(10) means cells are getting dropped at a rate of 1 in 10,000 cells 📉.
Packet loss exceeded ("ple(#)") 📦
This event means the packet loss rate is over the threshold #. If the threshold is left out of the requested events and observed events parameters, it's known by other means 🕵️. The optional decimal number is how many packets get dropped per 100,000 packets. For example, ple(10) means packets are getting dropped at a rate of 1 in 10,000 packets 💀.
When the bearer connection uses an AAL2 CID inside a multiplexed VCC instead of a whole VCC, the 'ple' event gets used instead of 'cle' 🦋. The packets in that case are AAL2 CPS PDUs 🫧.
Quality alert ("qa") 🚨
This event means the bearer path fails some predetermined combination of quality criteria, like loss, delay, jitter and so on 😬. The exact criteria aren't defined here. They're left up to the application 🎀. If the gateway is armed to report this quality violation, it tells the call agent 📣.
Report failure ("of (#)") 🙅♀️
This means a connection failed 💔. It can also mean that a connection couldn't be established, in place of "sf" 🥲.
Most of the time, the media gateway's response to these events is to delete the connection 🗑️. Some applications might choose to report an "of" with the right reason code, which is a decimal number that can optionally go in parentheses 💅. Reason codes are the same ones used for spontaneous deletes by the gateway ✨.
5.0 Connection Parameters ✨
okay bestie, so the MGCP connection parameters structure shows up in an autonomous delete connection message 📨 and also in the response to a delete or audit connection command. It holds the standard connection parameters [36], which get redefined here for ATM 💅, plus one brand new extension parameter that belongs only to the ATM package 🦋
Here's the standard glow-up for ATM:
- Number of packets sent: if a VCC is assigned to the connection, this is the total number of ATM cells transmitted for the whole life of the connection. If a CID within an AAL2 VCC is assigned instead, it's the number of AAL2 common part sublayer (CPS) packets transmitted for the duration of the connection 📦
- Number of octets sent: for a VCC, this is the total number of ATM payload octets transmitted for the duration of the connection. For a CID within an AAL2 VCC, it's the total number of AAL2 CPS payload octets transmitted for the duration of the connection 🧮
- Number of packets received: for a VCC, this is the total number of ATM cells received for the duration of the connection. For a CID within an AAL2 VCC, it's the number of AAL2 common part sublayer (CPS) packets received for the duration of the connection 📬
- Number of octets received: for a VCC, this is the total number of ATM payload octets received for the duration of the connection. For a CID within an AAL2 VCC, it's the total number of AAL2 CPS payload octets received for the duration of the connection 🌊
- Number of packets lost: for a VCC, this is the total number of ATM cells lost for the duration of the connection, counted in the direction towards the gateway. For a CID within an AAL2 VCC, it's the number of AAL2 common part sublayer (CPS) packets lost for the duration of the connection, also towards the gateway. If these losses can't be assessed, the gateway omits this parameter 🙈
- Interarrival jitter: for a VCC, this is the interarrival jitter for ATM cells. For a CID within an AAL2 VCC, it's the interarrival jitter for AAL2 common part sublayer (CPS) packets. If it can't be determined, it's either omitted or set to 0 🫨
- Average Transmission Delay: this should be understood as the average cell transmission delay in both cases, whether a VCC or a CID is assigned to the connection. Getting it requires ATM performance monitoring techniques. If the delay can't be assessed, it's omitted or set to 0 ⏱️
Now for the one extension parameter, which is the main character here 👑
- Connection qualification ("atm/CQ"): this qualifies the connection with enough granularity that the other connection parameters can be used without any prior knowledge of the network or connection type 🎀 The defined values are:
1 ATM Virtual Circuit Connection (VCC)
2 AAL2 Channel Identifier (CID)
3 Direct transfer i.e., without an ATM or other
packet pathWhen it's omitted, the connection parameters have to be interpreted on one of these bases:
- The default interpretations for MGCP in Ref. 36.
- The call agent's prior knowledge, if it governs the type of network and connection through the network type
ntLCO [Ref. 36] and/or the connection typectLCO defined here. - The call agent's snooping of the local connection descriptor provided by one or more media gateway. This is used to determine the network and connection type. 🕵️♀️
Here's an example of connection parameter encoding for an ATM VCC, bestie 🧚:
P: PS=1245, OS=59760, PR=1244, OR=59712, PL=20, JI=0, LA=0,atm/CQ=1Note that the PL value refers to the receive direction and is unrelated to PS 🙃 Also, since atm/CQ=1, these parameters refer to ATM cells rather than to AAL2 CPS packets. Iconic, honestly 💖
Like in other applications, any of these parameters can be left out if they aren't relevant to an application. The entire P: structure is optional too 🌸
When connection parameters are audited, all the parameters normally returned with a delete connection come back. That includes the connection qualification parameter, atm/CQ 📋
Measuring or estimating some or all of these parameters might not be feasible or beneficial in some applications 🤷♀️ In those cases, they can be individually omitted, or the entire connection parameters structure can be dropped, since it's optional in MGCP. Parameters that indicate impairments might also be set to 0 to nullify their impact, if there is any 🍓
6.0 Negotiation of Profiles and Codecs in ATM Applications 🦋
6.1 Consistency of Parameters 💅
For ATM networks, the "nt" local connection option in MGCP should be set to "ATM" 🌐
In any ATM application, the following Local Connection Options should not be used 🙅♀️
- Type of service,
L: t - Resource reservation,
L: r
That's because the Local Connection Options listed in Table 6 already give you information equivalent to the L: t and L: r local connection options 🧠
The following Local Connection Option isn't meaningful in the AAL1 case, so it should not be used either:
- Packetization period,
L: p
In AAL2 applications, the following Local Connection Options should not be used:
- Encoding algorithm,
L:a - Packetization period,
L: p
The following ATM Local Connection Options give you equivalent information in the AAL2 case 🎀
- Profile list,
L: atm/pfl - Priority list of voice codec selections,
L: atm/vsel - Priority list of voiceband data passthrough codec selections,
L: atm/dsel - Priority list of fax codec selections,
L: atm/fsel
Using a disallowed local connection option should be flagged with a return code of 524 (inconsistent local connection options) 🚩 Although it's not recommended to ignore these, it's recognized that some applications choose to do so for the sake of backward compatibility 🫶 Note that the inconsistency in this case is between the local connection option (e.g., L:a) and the application (e.g., AAL2) that doesn't allow it. Literally just a vibe mismatch 💀
6.2 Codec/Profile Negotiation in ATM Networks 🌈
In AAL1 and AAL5 applications, codec negotiation is similar to the IP case 🔥 Some of the local connection options and SDP connection descriptor parameters are different though. See [18] for conventions on using the Session Description Protocol [26] in the ATM context 📖
In AAL2 applications, the L:a and L:p parameters are disallowed. Profile negotiation takes the place of codec negotiation ✨ The rest of this section explains how that works 👑
The specifics of the AAL2 bearer aren't germane to profile negotiation 🙌 The bearer could be PVC-based or SVC-based, based on single-CID or multi-CID VCs, and subcell multiplexed or not. Totally doesn't matter for this part 🫠
The most general case involves different prioritized lists of profiles at the originating gateway, the terminating gateway, the originating call agent and the terminating call agent 🌟 Whether these lists come from network policies, end subscriber service level agreements or equipment design is immaterial to the profile negotiation done during connection establishment. It's also irrelevant whether the lists are hardcoded defaults or provisionable 💜 During connection establishment, a series of ordered intersections is performed, which leaves one single ordered list at the end. The highest priority profile in that list is the selected profile 🏆
The call agent conveys its priority list through the pfl local connection option 📞 The gateway conveys its intersection results through the media information line in SDP [18]. Whether these lists imply a real priority or not, a profile is, as a general rule, preferred over the profiles that follow it in a list 💅
Each media gateway has a policy for assigning priorities to different lists (inter-list priority), which is separate from the positional ordering of profiles within a list (intra-list priority) 🧩 That policy might be a hardcoded default or provisioned. The inter-list priority sets an ordering of the following lists with respect to each other:
- 'C-list', the priority list from the call agent, received through
L: atm/pfl. - 'R-list', the priority list from the remote end, received through the SDP remote connection descriptor.
- 'L-list', the local priority list, hardcoded or provisioned.
Depending on the application, different inter-list priorities might be used when the gateway originates and terminates a call 🔄
The policy above varies depending on the type, capabilities and deployment of the media gateway. Network administrations or equipment vendors will provision or default this policy for reasons like resource usage optimization, quality of service, likelihood of finding a common profile, and so on 📊
When doing an ordered intersection of lists, the intra-list priorities of the highest priority list are used 🥇 Any profile that can't be supported because of resource limitations (bandwidth, processing power, etc.) gets eliminated from the intersection 🗑️
If one or more of these lists is absent, the remaining list(s) are used in the profile selection process 🫧 If the call agent doesn't provide a list of profiles, the C-list is absent. In that case, the intersection of the C-list, R-list and L-list simply becomes the intersection of the R-list and the L-list. If the R-list is also absent, no intersection is performed and the result of this null operation is the L-list. Previous values of the C-list and R-list, if any, aren't used 🙅♀️
Here's how the profile negotiation process goes, step by step 🎬
ORIGINATING TERMINATING
GATEWAY GATEWAY
(1) On receiving CRCX
do a policy-based ordered
intersection of the C-list,
and L-list. No R-list present.
---------------------------------->
(2)Send resulting ordered list
to the terminating gateway
via SDP.
(3) On receiving CRCX do
a policy-based
ordered
intersection of the
C-list, R-list and
L-list.
(4) The highest priority
profile in the
resulting
list is the
selected
profile.
<-----------------------------------
(5) Send selected profile
to the originating gateway
via SDP.Before the final profile shows up in step 5, if the originating gateway offered multiple profiles in step 2, it's kinda flying blind 😭. A mix of packet length and UUI (user-to-user indication) codepoint range might mean different codecs in different profiles, so it doesn't always have a usable basis for decoding AAL2 packets 🫶. The gap between when the terminating gateways start sending AAL2 packets and when the originating gateway learns the selected AAL2 profile should be kept as small as possible, so any clipping at the front of the audio stays tolerable for voice circuits ✨. It's unlikely to cause errors in modem or fax circuits, since those haven't entered their user data transfer phase yet 💅.
Once connection establishment is done, there's only one profile tied to a connection 👑. That means both endpoints are ready to receive, on the fly, packets that match any row in the profile 🦋. Some apps might link profile rows to one or more service types: voice service, voiceband data (modem) passthrough service and fax service 🎀. That binding can be set by default, through provisioning, or as part of profile negotiation during call establishment. When those service type associations get communicated to another entity, they're advisory only, and they don't limit the requirement to support on-the-fly switches to any profile element at any time 💜.
Media gateways can have internal default (or provisioned) bindings between service types and profile elements 🌸. Not all of these bindings might be meaningful in an application context (e.g., the fax service binding might be ignored and omitted) 🙈. As part of profile negotiation, applications might choose to coordinate the bindings that are meaningful. When they do, the vsel, dsel and fsel LCOs described in this document, along with the vsel, dsel and fsel media attribute lines [18], are used to pull off that coordination 🧚. Using these constructs, entities like call agents and media gateways can indicate preferred bindings for the first, most preferred profile in a profile list 🍓.
When performing ordered intersections of the C-list, L-list and R-list in the call flow above, media gateways MUST use the inter-list priority to choose between a service to profile row binding suggested by the call agent, the remote gateway or its own internal (provisioned or default) binding 👑. So a service type to profile row binding inherits its relative priority from the profile list generated by the same source 🔥. If the C-list has the highest priority, and the first profile in the C-list is selected as the first profile of the intersected list, then any service type to profile row bindings provided by the call agent via the vsel, dsel and fsel LCOs are associated with the first profile 💖. If the R-list has the highest priority, and the first profile in the R-list is selected as the first profile of the intersected list, then any service type to profile row bindings provided by the remote gateway via the vsel, dsel and fsel SDP attributes [18] are associated with the first profile 🌈. If the L-list has the highest priority, then any internal (default or provisioned) service to profile row bindings are associated with the first profile 🦋. At the end of profile negotiation (step 4 in the call flow above), there is one profile selected by the terminating media gateway. It MAY convey any applicable service type to profile row bindings for this profile to the originating gateway via the vsel, dsel and fsel SDP attributes [18] 💅.
If the first profile in the intersected list is not the first profile in the highest priority profile list, then any service to profile row bindings associated with the highest priority profile list cannot be used with the first (or only) profile in the intersected list 😭. In this case, the originating or terminating media gateway MUST attempt to associate internal (default or provisioned) service to profile row bindings with the first (or only) profile in the intersected list 🫶.
Since there's more than one service type, the service type to profile row bindings for the first profile in the intersected list could come from different sources (the call agent, the remote media gateway, internal defaults or provisioning) 🎀. For consistency, if the voiceband data (passthrough) service mappings include fax, then a different set of fax service mappings cannot apply to the profile under consideration ✨. If it's applied anyway, the set of fax service mappings must include the same codecs, packet lengths and packetization periods as the voiceband data service mappings. They can be in a different order, though 🌸.
If the media gateway lumps fax service together with voiceband data (modem) passthrough service, it can ignore any fax service to profile row bindings provided by another entity, such as the call agent or the remote gateway 🙈. From the media gateway's perspective, there's no distinct fax service in this case. So the media gateway won't indicate a separate preference for certain profile rows with fax service 🧚.
It's possible that the procedure in this section for associating service types with profile rows fails to yield mappings between a given service type and the row(s) of the first profile in the intersected list of profiles 🍓. That's acceptable, since these bindings are merely indications of the preferred codecs and packetizations for a given service 💜. They don't obviate the AAL2 requirement that, given a profile bound to a connection, a transmitter may switch to any profile row on the fly 👑.
An example of profile negotiation, bestie 🎀:
The L-list at gateway #1, which is the originating gateway in this example, is:
custom 100, itu 3, itu 1, itu 8The L-list at gateway #2, which is the terminating gateway in this example, is:
itu 2, itu 3, itu 1, itu 5The originating call agent sends the following profile list (C-list) to the originating gateway in the first create connection command:
itu 8, itu 9, atmf 7, itu 3, itu 1, custom 100Further, the originating call agent qualifies the first profile in its list with the following service type bindings:
L: atm/vsel:"G729 10 10000", atm/dsel:"on PCMU 40 5000"There is no atm/fsel local connection option. Facsimile is included with voiceband data in the atm/dsel local connection option 🦋.
In step 1 at the originating gateway, there is no remote connection descriptor, so there's no R-list 🌸. The policy for originating calls at gateway #1 is:
C-List > R-list > L-listwhere > means "has higher priority than". The term R-list can be omitted from this series of inequalities, since in the case under study, profile negotiation doesn't include any further ordered intersections at the originating gateway 💅.
In accordance with this policy, the originating gateway performs an ordered intersection of the C-list and the L-list to produce:
itu 8, itu 3, itu 1, custom 100Since the C-list has the highest priority and the first profile in the intersected profile list is also the first profile in the C-list, the service bindings provided by the originating call agent are associated with the first profile, itu 8 ✨. The originating gateway sends this result (intersected profile list and service bindings for the first profile, itu 8) via the SDP remote session descriptor to the terminating gateway. The service bindings are expressed as follows [18]:
a=vsel:G729 10 10000
a=dsel:on PCMU 40 5000The intersected profile list produced by gateway 1 becomes the R-list for gateway #2 🍓. The terminating call agent sends the following profile list (C-list) to the terminating gateway in the first create connection command:
itu 1, itu 4, itu 3, custom 110, custom 100, itu 2Any service bindings (not shown) sent by the terminating call agent apply to the first profile in this list, itu 1 🧚.
The policy for terminating calls at gateway #2 is:
R-list > L-list > C-listUsing this policy, gateway #2 produces the following ordered intersection of R-list, L-list and C-list:
itu 3, itu 1The first profile in this list, itu 3, is the one used for this connection. Gateway 2 indicates this to the call agent through the SDP local connection descriptor 👑.
Note that the service bindings provided by the originating gateway haven't been specified with respect to itu 3. Therefore, they can't be used, even though the R-list has the highest priority at the terminating gateway 🙈. Any existing internal (default or provisioned) service bindings for AAL2 profile itu 3 must be associated by the terminating gateway with the selected profile, itu 3 🔥. Those service bindings that are internally unavailable are left unspecified 😭.
Since the internal service type bindings do exist for profile itu 3 at the terminating gateway, they're selected and bound to the connection. In these bindings, fax service is lumped with voiceband data passthrough 🌈. These bindings are indicated to the originating gateway via the following SDP media attribute lines:
a=vsel:G726-32 20 5000 G726-24 15 5000
a=dsel:on PCMU 40 5000 G726-40 25 5000The vsel line maps voice service to certain rows in the itu 3 profile table. The dsel line maps voiceband data service to certain rows in the itu 3 profile table. The "on" in the dsel line indicates that voiceband data includes fax, otherwise a separate fsel line might have been used 💖. Two codecs each are indicated for voice and for voiceband data, with the first codec being the preferred one 🦋. Although the originating gateway isn't constrained by these advisory indications of profile element to service type mapping, applications may choose to limit on-the-fly switches based on the current service state (voice, voiceband data etc.). If they do, that gives greater simplicity at the expense of flexibility 💅.
7.0 Security Considerations ✨
The ATM package extends the base Media Gateway Control Protocol (MGCP) [36]. This package specifies no additional security requirements or recommendations over those of the base MGCP protocol 🔥. Literally nothing extra to worry about here, beyond what MGCP already brings to the table 💀.
8.0 IANA Considerations ✨
okay bestie, IANA stuff is actually lowkey iconic 🎀 the ATM package from this doc got registered as an MGCP package called "atm" (no quotes, we're classy 💅). Its current version is 0, which is the default 🌸 and this whole registration was done following the IANA rules in the MGCP spec, [36] 🫶
The contact person for the MGCP ATM package is the author of this document, the one in Section 12 💖
9.0 References 📚
Okay so here's the whole reading list, every single source, no skipping 💅
- [1] ITU-T I.366.1, B-ISDN ATM Adaptation Layer Specification: Type 1 AAL. ✨
- [2] ITU-T I.366.2, AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking, Nov. 2000. 🌈
- [3] af-vtoa-0113.000, ATM trunking using AAL2 for narrowband services. 🦋
- [4] ITU Q. 2965.1, Digital subscriber signalling system no.2 (DSS 2) - Support of Quality of Service classes. 💜
- [5] ITU Q.2961, Digital subscriber signalling system no.2 (DSS 2) - additional traffic parameters. Also, Amendment 2 to Q.2961. 🔥
- [6] ATMF UNI 4.0 Signaling Specification, af-sig-0061.000. 👑
- [7] ITU Q. 2965.2, Digital subscriber signalling system no.2 (DSS 2) - Signalling of individual Quality of Service parameters. 🎀
- [8] ATMF Traffic Management Specification, Version 4.1, af-tm-0121.000. 🌸
- [9] I.356, BISDN ATM layer cell transfer performance. ⭐
- [10] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type 2 AAL, Sept. 1997. 🍓
- [11] ITU-T I.366.1, Segmentation and Reassembly Service Specific Convergence Sublayer for AAL Type 2, June 1998. 🧚
- [12] H.323-2, Packet-based multimedia communications systems. 💅
- [13] af-vtoa-0083.000, Voice and Telephony Over ATM to the Desktop. 🫶
- [14] Q.2110, B-ISDN ATM adaptation layer - service specific connection oriented protocol (SSCOP). ✨
- [15] I.365.1,Frame relaying service specific convergence sublayer (FR-SSCS). 🌈
- [16] I.365.2, B-ISDN ATM adaptation layer sublayers: service specific coordination function to provide the connection oriented network service. 🦋
- [17] I.365.3, B-ISDN ATM adaptation layer sublayers: service specific coordination function to provide the connection-oriented transport service. 💜
- [18] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001. 🔥
- [19] ITU I.371, Traffic Control and Congestion Control in the BISDN. 👑
- [20] ATMF Circuit Emulation Service (CES) Interoperability Specification, af-vtoa-0078.000. 🎀
- [21] af-vmoa-0145.000, Voice and Multimedia over ATM, Loop Emulation Service using AAL2. 🌸
- [22] ITU-T H.222.1, Multimedia multiplex and synchronization for audiovisual communication in ATM environments. ⭐
- [23] FRF.5, Frame Relay/ATM PVC Network Interworking Implementation Agreement. 🍓
- [24] FRF.8, Frame Relay/ATM PVC Service Interworking Implementation Agreement. 🧚
- [25] FRF.11, Voice over Frame Relay Implementation Agreement. 💅
- [26] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 🫶
- [27] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type 5 AAL, Aug. 1996. ✨
- [28] I.365.4, B-ISDN ATM adaptation layer sublayers: Service specific convergence sublayer for HDLC applications. 🌈
- [29] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling. 🦋
- [30] ITU Q.765.5, Application Transport Mechanism - Bearer Independent Call Control. 💜
- [31] http://www.3gpp.org/ftp/Specs for specifications related to 3GPP, including AMR codecs. 🔥
- [32] ITU Q.931, Digital Subscriber Signaling System No. 1: Network Layer. 👑
- [33] ITU Q.763, SS7 - ISUP formats and codes. 🎀
- [34] http://www.iana.org/assignments/rtp-parameters 🌸
- [35] ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997. ⭐
- [36] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 🍓
- [37] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 🧚
- [38] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001. 💖
10.0 Acronyms 🧚
Okay this list is giving alphabet soup 🍜 but every single one is here, periodt 💅
AAL ATM Adaptation Layer
ABR Available Bit Rate
ABT/DT ATM Block Transfer/Delayed Transmission
ABT/IT ATM Block Transfer/Immediate Transmission
ATM Asynchronous Transfer Mode
ATMF ATM Forum
BCG Bearer Connection Group
CAS Channel Associated Signaling
CBR Constant Bit Rate
CDV Cell Delay Variation
CDVT Cell Delay Variation Tolerance
CID Channel Identifier
CLR Cell Loss Ratio
CPS Common Part Sublayer
DBR Deterministic Bit Rate
FEC Forward Error Correction
FRF Frame Relay Format
GFR Guaranteed Frame Rate
GWID Gateway Identifier
IP Internet Protocol
ITU International Telecommunications Union
LCO Local Connection Option
MBS Maximum Burst Size
MCR Minimum Cell Rate
MFS Maximum Frame Size
MGCP Media Gateway Control Protocol
nrt-VBR Non-real-time Variable Bit Rate
NSAP Network Service Access Point
PCR Peak Cell Rate
PDU Protocol Data Unit
PVC Permanent Virtual Circuit
QoS Quality of Service
rt-VBR Real-time Variable Bit Rate
SAR Segmentation and Re-assembly
SCR Sustained Cell Rate
SDT Structured Data Transfer
SDU Service Data Unit
SPVC Switched Permanent Virtual Circuit
SRTS Synchronous Residual Time-Stamp
SSCOP Service-specific Connection Oriented Protocol
SSSAR Service-specific Segmentation and Re-assembly
SVC Switched Virtual Circuit
TDM Time-Division Multiplexing
UBR Unspecified Bit Rate
UDT Unstructured Data Transfer
VC Virtual Circuit
VCCI Virtual Circuit Connection Identifier
VCI Virtual Circuit Identifier
VP Virtual Path
VPCI Virtual Path Connection Identifier
VPI Virtual Path Identifier11.0 Acknowledgements 🫶
The author wishes to thank several colleagues at Cisco and the industry who have contributed towards the development of the MGCP ATM package, and who have implemented and tested these constructs. Special thanks are due to Bill Foster, Flemming Andreasen, Raghu Thirumalai Rajan, Joe Stone, Hisham Abdelhamid, Joseph Swaminathan, Sushma Srikanth, Amit Agrawal, Mohamed Mostafa, Latha Idury, David Auerbach and Robert Biskner of Cisco systems and to Mahamood Hussain of Hughes Software Systems for their contributions. Finally, thanks are due to Scott Bradner for guiding the final phase of the publication of this document. 💜
12.0 Author's Address 🎀
Rajesh Kumar Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
Phone: 1-408-527-0811 EMail: rkumar@cisco.com
13.0 Full Copyright Statement ⭐
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. 🔥
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. 👑
📦 where this page comes from
- ietf: rfc3441 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms