RFC 3108
Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
RFC 3108 💖 Conventions for the Use of the Session Description Protocol (SDP) for ATM Bearer Connections
okay bestie, title block tea ☕ this one comes from the Network Working Group and was written by R. Kumar and M. Mostafa of Cisco Systems. It's a Standards Track doc, dated May 2001. The header doesn't say it obsoletes or updates anything, so there's nothing listed there to replace or patch 🦋
Status of This Memo 🎀
this is an Internet standards track protocol doc for the whole Internet community, and it's literally asking for discussion and suggestions 🫶 For where the protocol stands in standardization, check the current "Internet Official Protocol Standards" list (that's STD 1) 💅 Distribution is unlimited, so share away 🌸
Copyright Notice ⭐
Copyright (C) The Internet Society (2001). All Rights Reserved.Abstract 🦋
so this doc sets out conventions for using the Session Description Protocol (SDP) from RFC 2327 to control ATM Bearer Connections and any ATM Adaptation Layer (AAL) that goes with them 🔥 The AALs it covers are Type 1, Type 2 and Type 5. The list is meant to be exhaustive, but individual apps can pick subsets of it ✨ And these conventions are meant to follow the SDP syntax from RFC 2327 strictly, no cap 💜
Table of Contents 📖
1. Introduction................................................... 3
1.1 Key words to indicate Requirement Levels..................... 5
2. Representation of Certain Fields within SDP description lines.. 5
2.1 Representation of Extension Attributes....................... 5
2.2 Representation of Parameter Values........................... 5
2.3 Directionality Convention.................................... 6
2.4 Case convention............................................... 7
2.5 Use of special characters in SDP parameter values............. 8
3. Capabilities Provided by SDP conventions....................... 8
4. Format of the ATM Session Description.......................... 9
5. Structure of the Session Description Lines.................... 11
5.1 The Origin Line.............................................. 11
5.2 The Session Name Line........................................ 12
5.3 The Connection Information Line.............................. 13
5.4 The Timestamp Line........................................... 15
5.5 Media Information Line for ATM connections................... 16
5.5.1 The Virtual Connection ID.................................. 16
5.5.2 The Transport Parameter.................................... 19
5.5.3 The Format List for AAL1 and AAL5 applications............. 21
5.5.4 The Format List for AAL2 applications...................... 21
5.5.5 Media information line construction........................ 22
5.6 The Media Attribute Lines.................................... 27
5.6.1 ATM bearer connection attributes........................... 28
5.6.1.1 The 'eecid' attribute.................................... 30
5.6.1.2 The 'aalType' attribute.................................. 31
5.6.1.3 The 'capability' attribute............................... 32
5.6.1.4 The 'qosClass' attribute................................. 33
5.6.1.5 The 'bcob' attribute..................................... 34
5.6.1.6 The 'stc' attribute...................................... 34
5.6.1.7 The 'upcc' attribute..................................... 35
5.6.1.8 The 'atmQOSparms' attribute.............................. 35
5.6.1.9 The 'atmTrfcDesc' attribute............................. 37
5.6.1.10 The 'abrParms' attribute................................. 39
5.6.1.11 The 'abrSetup' attribute................................. 40
5.6.1.12 The 'bearerType' attribute............................... 41
5.6.1.13 The 'lij' attribute...................................... 42
5.6.1.14 The 'anycast' attribute.................................. 43
5.6.1.15 The 'cache' attribute.................................... 43
5.6.1.16 The 'bearerSigIE' attribute.............................. 44
5.6.2 ATM Adaptation Layer (AAL) attributes...................... 45
5.6.2.1 The 'aalApp' attribute................................... 46
5.6.2.2 The 'cbrRate' attribute.................................. 48
5.6.2.3 The 'sbc' attribute...................................... 49
5.6.2.4 The 'clkrec' attribute................................... 51
5.6.2.5 The 'fec' attribute...................................... 51
5.6.2.6 The 'prtfl' attribute.................................... 51
5.6.2.7 The 'structure' attribute................................ 52
5.6.2.8 The 'cpsSDUsize' attribute............................... 53
5.6.2.9 The 'aal2CPS' attribute.................................. 53
5.6.2.10 The 'aal2CPSSDUrate' attribute........................... 54
5.6.2.11 The 'aal2sscs3661unassured' attribute.................... 54
5.6.2.12 The 'aal2sscs3661assured' attribute...................... 55
5.6.2.13 The 'aal2sscs3662' attribute............................. 56
5.6.2.14 The 'aal5sscop' attribute................................ 58
5.6.3 Service attributes......................................... 58
5.6.3.1 The 'atmmap' attribute................................... 60
5.6.3.2 The 'silenceSupp' attribute.............................. 63
5.6.3.3 The 'ecan' attribute..................................... 65
5.6.3.4 The 'gc' attributes...................................... 66
5.6.3.5 The 'profileDesc' attribute.............................. 67
5.6.3.6 The 'vsel' attribute..................................... 68
5.6.3.7 The 'dsel' attribute..................................... 70
5.6.3.8 The 'fsel' attribute..................................... 72
5.6.3.9 The 'onewaySel' attribute................................ 73
5.6.3.10 The 'codecconfig' attribute.............................. 75
5.6.3.11 The 'isup_usi' attribute................................. 76
5.6.3.12 The 'uiLayer1_Prot' attribute............................ 76
5.6.4 Miscellaneous media attributes............................. 77
5.6.4.1 The 'chain' attribute..................................... 77
5.6.5 Use of the second media-level part in H.323 Annex C
applications............................................... 78
5.6.6 Use of the eecid media attribute in call establishment
procedures................................................. 78
6. List of Parameters with Representations....................... 83
7. Examples of ATM session descriptions using SDP................. 93
8. Security Considerations........................................ 94
8.1 Bearer Security.............................................. 94
8.2 Security of the SDP description.............................. 95
9. ATM SDP Grammar................................................ 95
References........................................................104
Acknowledgements..................................................109
Authors' Addresses................................................109
Full Copyright Statement..........................................1101. Introduction ✨
okay so SDP is going to team up with a connection handling or device control protocol, like Megaco (H.248) [26], SIP [18] or MGCP [25], to pass along the info needed to set up ATM and AAL2 bearer connections 🌈 Those connections can be voice, voiceband data, clear channel circuit emulation, video, and baseband data (things like fax relay, modem relay, SSCOP, frame relay etc.) 🎧
These conventions use the standard SDP syntax from RFC 2327 [1] to describe the ATM-level and AAL-level connections, addresses and other parameters 💖 Generally, stuff from layers higher than the ATM adaptation layer only gets included if it's tightly coupled to ATM or AAL 🧚 Since the syntax follows RFC 2327, regular SDP parsers should react in a well-defined and safe way when they get session descriptions built with these conventions 🫶 This works by extending the values of fields RFC 2327 already defines, rather than making new fields. That's true for every SDP line except the media attribute lines, where new attributes get defined, because SDP lets media attribute lines be free-form ✨ For the other lines, having <networkType> set to "ATM" should stop RFC 2327-compliant SDP parsers from misreading the extended parameter values 💅
These conventions are meant to address the following ATM applications:
- Applications where a new SVC gets set up for each service connection. These SVCs could be AAL1 or AAL5 SVCs, or single-CID AAL2 SVCs 🦋
- Applications where existing path resources get assigned to service connections. Those resources could be:
- AAL1/AAL5 PVCs, SPVCs or cached SVCs,
- AAL2 single-CID PVCs, SPVCs or cached SVCs,
- CIDs within AAL2 SVCs/PVCs/SPVCs that multiplex multiple CIDs.
- Subchannels (identified by CIDs) within AAL1 [8] or AAL2 [11] SVCs/PVCs/SPVCs.
Quick aside 🌸 PVCs and SPVCs differ in how the bearer virtual circuit connection gets set up. SPVCs are a class of PVCs that use bearer signaling for connection establishment, as opposed to node-by-node provisioning 🧠
This doc is only about the case where the network type is ATM. That includes raw RTP encapsulation [45] or voice sample encapsulation [46] over AAL5 with no intervening IP layer. It does NOT address SDP usage for IP, with or without ATM as a lower layer 🙈
In some cases, IP connection set-up doesn't depend on the lower layers, which get configured beforehand 🍓 For example, AAL5 PVCs that connect IP routers can be used for VoIP calls. In other cases, VoIP call set-up is closely tied to ATM-level connection set-up. That might need a chaining of IP and ATM descriptors, as described in section 5.6.4.1 💜
This doc makes no assumptions about who constructs the session descriptions (media gateway, intermediate ATM/AAL2 switch, media gateway controller etc.) 👑 That'll be different in different applications. It also allows one session description for both directions of a connection (as in SIP and MGCP applications), or separate session descriptions for different directions. And it addresses the ATM multicast and anycast capabilities too 🔥
This doc also makes no assumptions about how the SDP description gets coded. Although the descriptions shown here are encoded as text, alternate codings are possible:
- Binary encoding such as ASN.1. This is an option (in addition to text encoding) in the Megaco context.
- Use of extended ISUP parameters [36] to encode the information in SDP descriptors, with conversion to and from binary or text-based SDP encoding when needed.
1.1 Key words to indicate Requirement Levels 💖
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [62] 🎀
2. Representation of Certain Fields within SDP description lines 🧚
this doc follows the syntactic conventions of standard SDP as defined in RFC 2327 [1] 🌈
2.1. Representation of Extension Attributes ✨
okay bestie, so the SDP protocol [1] is super strict that non-standard attributes and codec names gotta use an X- prefix 🎀 no cap
In this doc, the X- prefix is used consistently for codec names (Table 2) that have not been registered with the IANA 💅 The IANA-registered codec names listed in [31] do not use this prefix, regardless of whether they are statically or dynamically assigned payload types ✨
However, the prefix is NOT used for the extension SDP attributes defined in this document. This was done to enhance legibility 🧚
This document suggests that parsers be flexible about the X- prefix convention. They SHOULD accept codec names and attribute names with or without the X- prefix 🫶
2.2. Representation of Parameter Values 🌸
Depending on how they're written in SDP, the parameters in this doc fall into these classes:
(1) Parameters always represented in a decimal format.
(2) Parameters always represented in a hexadecimal format.
(3) Parameters always represented as character strings.
(4) Parameters that can be represented in either decimal or
hexadecimal format.Classes 1 - 3 don't need any prefixes since the format is fixed 💖 For class 4, a 0x prefix SHALL always be used to tell hex apart from decimal.
For both decimal and hex representations, if the underlying bit field is smaller or larger than the binary equivalent of the SDP representation, then leading 0 bits SHOULD be added or removed as needed. So 3 and 0x3 both turn into the five-bit pattern 0 0011, and 0x12 and 18 both turn into 1 0010 🦋
Leading 0 digits SHALL NOT be used in decimal representations. Generally they aren't used in hex either, except when an exact number of hex digits is expected, like with NSAP addresses. Parsers SHALL NOT reject leading zeros in hex values 🙈
Both single-character and multi-character string values are wrapped in double quotes, like ". Single quotes, like ', are used for emphasizing keywords rather than for referring to characters or strings ✨
In text representations of decimal and hex numbers, digits on the left are more significant than digits on the right 🔥
2.3. Directionality Convention 🦋
This bit explains what 'forward' and 'backward' mean in this doc. It's especially important for parameters that have a specific direction attached to them 💅
In this document, 'forward' means the direction away from the ATM node under consideration, and 'backward' means the direction towards that ATM node. This convention MUST be used in all SDP-based session descriptions, no matter whether the underlying bearer is an SVC, a dynamically allocated PVC/SPVC or a dynamically allocated CID. It doesn't matter which side originates the service connection either. If ATM SVC or AAL2 Q.2630.1 signaling is used, the directionality convention is independent of which side originates the SVC or AAL2 connection 👑
This gives us a simple way to figure out which direction a parameter applies to, in a way that doesn't depend on the underlying ATM or AAL2 bearer. Obviously there's a catch, which we'll get to 😭
The convention used by all ATM/AAL2 signaling specifications (e.g., Q.2931 Section 1.3.3 and Q.2630.1) says the forward direction goes from the end that initiates setup/establishment via bearer signaling towards the end that receives the setup/establishment request. Backward is the opposite way. Sometimes the 'forward' and 'backward' directions of the ATM signaling convention are the exact opposite of the SDP convention above, so the media gateway has to do the translation itself. There's an example of this coming up 🌈
Okay so picture this: an SDP description is sent by a media gateway controller to the gateway that's originating a service-level call. In the backward SVC call set-up model, this gateway terminates (rather than originates) an SVC call. The media gateway calls the traffic descriptor (and therefore the PCR) in the direction away from this gateway the forward traffic descriptor and forward PCR. Clearly, that clashes with ATM SVC signaling, which calls this very same PCR the backward PCR 🙈 So the gateway needs to be able to swap the directions. In this example, the media gateway that terminates the service level call (and therefore originates the SVC call) does not need to do this swap 💖
Some parameters are only defined for one direction. Forward-direction examples are the <fsssar> subparameter in the 'aal2sscs3661unassured' media attribute line, the <fsssar>, <fsscopsdu> and <fsscopuu> subparameters in the 'aal2sscs3661assured' media attribute line, the <fsscopsdu> and <fsscopuu> subparameters in the 'aal5sscop' media attribute line, and the <fmaxFrame> parameter in the 'aal2sscs3662' media attribute line. Backward-direction examples are the <bsssar> subparameter in the 'aal2sscs3661unassured' media attribute line, the <bsssar>, <bsscopsdu> and <bsscopuu> subparameters in the 'aal2sscs3661assured' media attribute line, the <bsscopsdu> and <bsscopuu> subparameters in the 'aal5sscop' media attribute line, and the <bmaxFrame> parameter in the 'aal2sscs3662' media attribute line 🧚
2.4. Case convention 💖
As defined in RFC 2327 [1], SDP syntax is case-sensitive. Since these ATM conventions follow SDP syntax strictly, they're case-sensitive too. SDP line types (e.g., "c", "m", "o", "a") and fields in the SDP lines SHOULD be built according to the case conventions in [1] and in this document. It's suggested, but not REQUIRED, that SDP parsers for ATM applications be case-tolerant where ignoring case doesn't create any ambiguity 🫶 Encoding names are defined outside the SDP protocol, so they're case-insensitive 🎀
2.5. Use of special characters in SDP parameter values 🌈
Generally, RFC 2327-conformant string values of SDP parameters [1] don't include special characters that are neither letters nor digits. The one exception is the "/" character used in the value "RTP/AVP" in the transport sub-field of the 'm' line 💅
String values used in SDP descriptions of ATM connections keep this convention, but they're allowed to use the special character "/" in a way that matches [1]. On top of that, the special characters "$" and "-" have their own jobs ✨ A "$" value is a wildcard, so the recipient of the SDP description can pick any permitted value of the parameter. A "-" value means you don't need to specify the parameter in the SDP description, because it's irrelevant for this application, or because its value can be known from somewhere else, like provisioning, defaults, another protocol, another SDP descriptor, or another part of the same SDP descriptor 🦋
If using these special characters counts as a violation of RFC 2327 [1] syntax, then reserved string values can be used instead. The string "CHOOSE" can be used in place of "$", and the string "OMIT" can be used in place of "-" for an omitted parameter 🌸
3. Capabilities Provided by SDP conventions 🎀
To support the applications listed in section 1, the SDP conventions in this document give you these session control capabilities:
- Identification of the underlying bearer network type as ATM 💜
- Identification by an ATM network element of its own address, in one of several possible formats. A connection peer can initiate SVC set-up to this address. A call agent or connection peer can select an pre-established bearer path to this address 🦋
- Identification of the ATM bearer connection that is to be bound to the service-level connection. Depending on the application, this is either a VCC or a subchannel (identified by a CID) within a VCC 🧚
- Identification of media type: audio, video, data 🌈
- In AAL1/AAL5 applications, declaration of a set of payload types that can be bound to the ATM bearer connection. The encoding names and payload types defined for use in the RTP context [31] are re-used for AAL1 and AAL5, if applicable 🍓
- In AAL2 applications, declaration of a set of profiles that can be bound to the ATM bearer connection. A mechanism for dynamically defining custom profiles within the SDP session description is included. This allows the use of custom profiles for connections that span multi-network interfaces 👑
- A means of correlating service-level connections with underlying ATM bearer connections. The backbone network connection identifier or bnc-id specified in ITU Q.1901 [36] standardization work is used for this purpose. To give applications based on Q.1901 and SIP/SIP+ a common SDP base, the neutral term
'eecid'is used in place of'bnc-id'in the SDP session descriptor 💖 - A means of mapping codec types and packetization periods into service types (voice, voiceband data and facsimile). This is useful for working out which encoding to use when the connection is upspeeded in response to modem or facsimile tones ✨
- A means of describing the adaptation type, QoS class, ATM transfer capability/service category, broadband bearer class, traffic parameters, CPS parameters and SSCS parameters related to the underlying bearer connection 💅
- Means for enabling or describing special functions such as leaf- initiated-join, anycast and SVC caching 🌸
- For H.323 Annex C applications, a means of specifying the IP address and port number on which the node will receive RTCP messages 🫶
- A means of chaining consecutive SDP descriptors so that they refer to different layers of the same connection 🔥
4. Format of the ATM Session Description ✨
Okay bestie, so the line order in these session descriptions follows RFC 2327 [1] 💅. A session description is normally a session-level part followed by zero or more media-level parts. ATM session descriptions have one session-level part followed by one or two media-level parts. The only two media that apply are the ATM bearer medium and RTCP control (where applicable) 🦋.
The session level part has these lines:
v= (protocol version, zero or one line)
o= (origin, zero or one line)
s= (session name, zero or one line)
c= (connection information, one line)
b= (bandwidth, zero or more lines)
t= (timestamp, zero or one line)
k= (encryption key, zero or one line)In ATM session descriptions, there are no media attribute lines in the session level part. Those live in the media-level parts 🌸.
The media-level part for the ATM bearer has these lines:
m= (media information and transport address, one line)
b= (bandwidth, zero or more lines)
k= (encryption key, zero or more lines)
a= (media attribute, zero or more lines)The media-level part for RTCP control has these lines:
m= (media information and transport address, one line)
c= (connection information for control only, one line)Generally the v=, o=, s=, and t= lines are mandatory 🔥. But in the Megaco [26] context these lines have been made optional, and the o=, s=, and t= lines are omitted in most MGCP [25] applications 🧚.
Note that ATM SDP session descriptors can contain bandwidth (b=) and encryption key (k=) lines 💜. Like all the other lines, these should strictly conform to the SDP standard [1].
The bandwidth (b=) line isn't necessarily redundant in the ATM context, because in some applications it can carry application-level information that doesn't map directly into the atmTrfcDesc media attribute line 🍓. For example, the b line can be used in SDP descriptors inside RTSP commands to describe content bandwidth ✨.
The encryption key line (k=) can indicate an encryption key for the bearer, plus a method to get that key 🔑. Right now, though, encryption of ATM and AAL2 bearers hasn't been conventionalized the way encryption of RTP payloads has 😭. Authentication or encryption of ATM or AAL2 bearer signaling hasn't been standardized either. In the ATM and AAL2 contexts, the term "bearer" can include "bearer signaling" as well as "bearer payloads" 🌈.
The order of lines in an ATM session description is exactly the RFC 2327-conformant order shown above 🎀. There is no ordering requirement for the media attribute (a=) lines with respect to other a= lines 💖.
The SDP protocol version for session descriptions using these conventions is 0. In line with standard SDP, it is strongly recommended that the v= line be included at the beginning of each SDP session description 🫶. In some contexts, such as Megaco, the v= line is optional and may be omitted, unless several session descriptions are sent in sequence. In that case the v= line works as a delimiter 💅. Depending on the application, a sequence of session descriptions might refer to:
- Different connections or sessions.
- Alternate ways of realizing the same connection or session.
- Different layers of the same session (section 5.6.4.1).
The o=, s=, and t= lines are included for strict conformance with RFC 2327 🙈. They might not carry useful information in some ATM-based applications, so some applications might omit them, although it is recommended that they not do so. For maximum interoperability, it is preferable that SDP parsers do not reject session descriptions that lack these lines 🦋.
5. Structure of the Session Description Lines 🌸
5.1 The Origin Line
The origin line for an ATM-based session is structured like this 💖:
o=<username> <sessionID> <version> <networkType>
<addressType> <address>The <username> is set to "-" 🎀.
The <sessionID> can be set to one of the following:
- An NTP timestamp referring to the moment the SDP session descriptor was created.
- A Call ID, connection ID, or context ID that uniquely identifies the session within the scope of the ATM node. Since calls can comprise multiple connections (sessions), call IDs are generally not suitable for this purpose 🙅♀️.
NTP timestamps can be written as decimal or hex integers. Only the part of the NTP timestamp that counts whole seconds is needed. This is a 32-bit field ⭐.
Call IDs, connection IDs, and context IDs can be 32 hex digits long 🔮.
The <sessionID> field is written as a decimal or hex number of up to 32 digits. A "0x" prefix goes in front of the hex representation 💜.
The <version> refers to the version of the SDP session descriptor, not the version of the SDP protocol itself 🧚. It can be set to one of the following:
0.- An NTP timestamp referring to the moment the SDP session descriptor was modified. If an intermediate entity (such as an MGC) has not modified the SDP session descriptor, the
<version>timestamp will be the same as the<sessionID>timestamp, if there is one. As with the<sessionID>, only the integer part of the NTP timestamp is used 🫶.
When equated to the integer part of an NTP timestamp, the <version> field is 10 digits wide 🍓. That's more restricted than [1], which allows unlimited size. As in [1], the most significant digit is non-zero when an NTP timestamp is used 🌈.
The <networkType> in SDP session descriptions for ATM applications should be assigned the string value "ATM", or wildcarded to "$" or "-" ✨.
The <addressType> and <address> parameters are identical to those for the connection information (c=) line (Section 5.3) 🦋. Each of these parameters can be wildcarded per the conventions described for the c= line in Section 5.3. They should not be omitted, since that would violate SDP syntax [1] 😭.
As with the c= line, SDP parsers are not expected to check the consistency of <networkType> with the <addressType>, <address> pairs. The <addressType> and <address> need to be consistent with each other 💅.
5.2 The Session Name Line
In general, the session name line is structured like this 🎀:
s=<sessionName>For ATM-based sessions, the <sessionName> parameter is set to "-". The resulting line is:
s=-5.3 The Connection Information Line 💖
okay so the connection information line [1] is basically the 'c' line, and in general it looks like this:
c=<networkType> <addressType> <address>ATM networks get extra values of <networkType>, <addressType> and <address> on top of the ones in [1] 🦋. The ABNF syntax (Section 9) for ATM SDP doesn't limit how <networkType> can be mixed with <addressType>, <address> pairs. BUT some combos won't be valid for certain apps, and others will never be valid ✨. Invalid combos should get rejected by application-specific functions, NOT generic parsers 🙅♀️. The ABNF does limit how <addressType> and <address> can be paired, though 💅.
For ATM networks, <networkType> should be set to "ATM" 🎀. It can also be wildcarded to "$" or "-". If you do that, a node using ATM as its basic transport will pick "ATM" 🌸. And a node that talks to multiple network types ("IN", "ATM" etc.) that include ATM can also choose "ATM" 💜.
When a node like a media gateway builds the SDP description, <address> is the address of the node building it 🌈. When that description gets forwarded to another node, it still has the original node's address, which is so iconic 👑. When the media gateway controller builds part or all of the SDP description, the local descriptor has the local node's address, and the remote descriptor has the remote node's address 🧚. If <address> and/or <addressType> are irrelevant or already known by other means, you can set them to "$" or "-" (more on that below) 🫶.
Also, in ALL contexts, the 'm' line can have an ATM address in the <virtualConnectionId> subparameter 😭. If it's there, it's the remote address when the 'c' line address is local, and vice versa 🔥.
For ATM networks, <addressType> can be NSAP, E164 or GWID (ALIAS) 💖. The <address> syntax depends on which <addressType> you picked, and SDP parsers should check that <addressType> and <address> actually match 🙈.
NSAP: if the addressType is NSAP, the address is written in the standard dotted hex form. That's a string of 40 hex digits with dots after the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th digits 🍓. The last octet is the 'selector' field, which is free for non-standard use ✨. Here's an example line with an NSAP address:
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00A "0x" prefix shall not be used in this case, since it's always hexadecimal anyway 🙅♀️.
E164: if the addressType is E164, the address is a decimal number with up to 15 digits 📞. For example:
c=ATM E164 9738294382The use of E.164 numbers in the B-ISDN context is defined in ITU E.191 🌸. Now here's the drama: the ATM Forum and the ITU don't agree on E.164 numbers for ATM addressing 😭. The ATM Forum (e.g., UNI Signaling 4.0) only allows International Format E.164 numbers, while the ITU (e.g., Q.2931) allows private numbering plans 💀. Since this SDP spec's goal is to interoperate with ALL bearer signaling protocols, it allows numbers that don't follow the E.164 International Format 🫶. BUT, to keep things consistent overall, network admins can restrict provisioning to the E.164 International Format 👑.
GWID (ALIAS): if the addressType is GWID, the address is a Gateway Identifier or Node Alias 🦋. That may or may not be globally unique, no cap 🤷♀️. The address is an alphanumeric string made of "A"-"Z", "a"-"z", "0" - "9", ".", "-", "_" 🎀. For example:
c=ATM GWID officeABCmgx101vism12Since these SDP conventions can be used for more than gateways, you can use the string "ALIAS" instead of "GWID" in the 'c' line 🧚. So the example above is the same as:
c=ATM ALIAS officeABCmgx101vism12An example of a GWID (ALIAS) is the CLLI code used for telecom equipment 💜. For all practical purposes, the GWID (ALIAS) should be a variable length string with a max size of 32 characters 🌈.
The connection information line is ALWAYS present in an SDP session descriptor ✨. Each parameter on this line can be wildcarded to "$" or "-", independently of whether the other parameters are wildcarded too 🦋. Not every syntactically legal wildcard combo is meaningful in a particular application, though 🙈.
Examples of meaningful wildcard combos in the ATM context are:
c=- - -
c=$ $ $
c=ATM - -
c=ATM $ $
c=ATM <addressType> -
c=ATM <addressType> $Specifying the ATM address type WITHOUT the ATM address is useful when the recipient is asked to pick an ATM address of a certain type (NSAP, E.164 etc.) 💖.
Examples of syntactically legal wildcard combos of dubious utility are:
c=- $ -
c=- $ $
c=- <addressType> -
c=$ <addressType> $
c=- <addressType> <address>
c=$ <addressType> <address>Note that <addressType> and/or <address> should not be omitted without being set to "-" or "$", since that would violate basic SDP syntax [1] 🚫.
5.4 The Timestamp Line ⭐
The timestamp line for an SDP session descriptor looks like this:
t= <startTime> <stopTime>Per Ref. [49], NTP time stamps use a 32 bit unsigned representation of seconds, and a 32 bit unsigned representation of fractional seconds ⏰. For ATM-based sessions, <startTime> can be made equal to the NTP timestamp for the moment the SDP session descriptor was created 🌸. It can also be set to 0 to say it doesn't matter 🫶. If it's made equal to the NTP timestamp in seconds, the fractional part gets left out 💅. When it's equal to the integer part of an NTP timestamp, the <startTime> field is 10 digits wide 🔢. That's tighter than [1], which allows unlimited size 😤. Just like [1], the most significant digit is non-zero when an NTP timestamp is used 🎀.
<stopTime> is set to 0 for ATM-based SDP descriptors 🧚.
5.5 Media Information Line for ATM connections 🎶
The general format of the media information line, adapted for AAL1 and AAL5 applications, is:
m=<media> <virtualConnectionId> <transport> <format list>The general format of the media information line, adapted for AAL2 applications, is:
m=<media> <virtualConnectionId> <transport#1> <format list#1>
<transport#2> <format list#2> ... <transport#M> <format list#M>Note that <virtualConnectionId> is equivalent to <port> in [1] 🦋.
The subparameter <media> can take on ALL the values defined in [1] 🌈. Those are: "audio", "video", "application", "data" and "control" 💜.
When <transport> has more than one value in the 'm' line, the <transport> <format list> pairs can be arranged in preferential order 👑.
5.5.1 The Virtual Connection ID 🦋
Okay so, when the media-level part of a session descriptor is bound to an ATM virtual circuit, the <virtualConnectionId> can come in one of these formats 💅:
* <ex_vcci>
* <addressType>-<address>/<ex_vcci>
* <address>/<ex_vcci>
* <ex_bcg>/<ex_vcci>
* <ex_portId>/<ex_vpi>/<ex_vci>
* <ex_bcg>/<ex_vpi>/<ex_vci>
* <ex_vpci>/<ex_vci>
* <addressType>-<address>/<ex_vpci>/<ex_vci>
* <address>/<ex_vpci>/<ex_vci>And when the media-level part is bound to a subchannel inside an ATM virtual circuit, the <virtualConnectionId> can be one of these 🌸:
* <ex_vcci>/<ex_cid>
* <addressType>-<address>/<ex_vcci>/<ex_cid>
* <address>/<ex_vcci>/<ex_cid>
* <ex_bcg>/<ex_vcci>/<ex_cid>
* <ex_portId>/<ex_vpi>/<ex_vci>/<ex_cid>
* <ex_bcg>/<ex_vpi>/<ex_vci>/<ex_cid>
* <ex_vpci>/<ex_vci>/<ex_cid>
* <addressType>-<address>/<ex_vpci>/<ex_vci>/<ex_cid>
* <address>/<ex_vpci>/<ex_vci>/<ex_cid>Here's the decoder ring 💖:
<ex_vcci> = VCCI-<vcci>
<ex_vpci> = VPCI-<vpci>
<ex_bcg> = BCG-<bcg>
<ex_portId> = PORT-<portId>
<ex_vpi> = VPI-<vpi>
<ex_vci> = VCI-<vci>
<ex_cid> = CID-<cid>The <vcci>, <vpi>, <vci>, <vpci> and <cid> are decimal numbers or hexadecimal numbers. If they're in hex, you put an "0x" prefix in front of the value ✨.
The <portId> is always a hexadecimal number 🧚. You do not use an "0x" prefix with it, so no drama there.
The <addressType> and <address> are the same as their definitions for the connection information line, with one twist: this address refers to the remote peer in the media information line 🫶. Since the <virtualConnectionId> is meant for ATM networks, the values of <addressType> and <address> in it are limited to ATM-specific values 💜.
The <vpi>, <vci> and <cid> are the Virtual Path Identifier, Virtual Circuit Identifier and Channel Identifier, respectively. The <vpi> is an 8 or 12 bit field. The <vci> is a 16-bit field. The <cid> is an 8-bit field ([8] and [11]). For AAL1 applications, it corresponds to the channel number defined in Annex C of [8] 🔥.
The <vpci> is a 16-bit field defined in Section 4.5.16 of ITU Q.2931 [Ref. 15] 🌈. It's similar to the <vpi>, except for its width, and the fun part is that it keeps its value across VP crossconnects. In some applications, the size of the <vpci> is the same as the size of the <vpi> (8 or 12 bits). In that case, the most significant 8 or 4 bits are ignored 🙈.
The <vcci> is a 16-bit field defined in ITU Recommendation Q.2941.2 [32] 👑. It's similar to the <vci>, except that 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. When signaled, the <vpci> gets encapsulated in the connection identifier information element of SVC signaling messages, and the <vcci> gets encapsulated in the Generic Information Transport (GIT) information element of SVC signaling messages. In an ATM node pair, either node can assign <vcci> values and signal them to the other end via SVC signaling. A glare avoidance scheme is defined in [32] and [44], and it works in SVC applications. A different glare avoidance technique is needed when a pool of existing PVCs/SPVCs gets dynamically assigned to calls. One scheme for glare reduction is to assign <vcci> values from different ends of the <vcci> range, using the lowest or highest available value as applicable 🍓.
When <vpci> and <vcci> values are pre-provisioned, administrations have the option of provisioning them uniquely in a network. In that case, the ATM address of the far end isn't needed to qualify these parameters ✨.
In the AAL2 context, the definition of a VCC implies there's no CID-level switching between its ends. If either end can assign <cid> values, then a glare reduction mechanism is needed. One scheme for glare reduction is to assign <cid> values from different ends of the <cid> range, using the lowest or highest available value as applicable 💀.
The <portId> parameter identifies the physical trunk port on an ATM module. It can be represented as a hexadecimal number of up to 32 hex 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 the <virtualConnectionId> parameter, or some of its elements. The "$" wildcard character can replace the entire <virtualConnectionId> parameter, or some of its terms. When you wildcard only some terms, the constant strings that qualify those terms stay in place ✨. The concatenation <addressType>-<address> can be wildcarded in these ways:
- The entire concatenation, <addressType>-<address>, is replaced with a "$".
- <address> is replaced with a "$", but <addressType> is not.
Examples of wildcarding the <virtualConnectionId> in the AAL1 and AAL5 contexts are:
$
VCCI-$
BCG-100/VPI-20/VCI-$Examples of wildcarding the <virtualConnectionId> in the AAL2 context are:
$
VCCI-40/CID-$
BCG-100/VPI-20/VCI-120/CID-$
NSAP-$/VCCI-$/CID-$
$/VCCI-$/CID-$It's also allowed to set the entire <virtualConnectionId> parameter to a "-", which means it doesn't matter 🧚💅.
5.5.2 The Transport Parameter 🎀
The <transport> parameter tells you the method used to encapsulate the service payload 💖. These methods aren't defined in this document. Instead it points at existing ATMF and ITU-T standards, which might point at other standards too 🌈. For ATM applications, these <transport> values are defined:
Table 1: List of Transport Parameter values used in SDP in the ATM context
+---------------------------------------------------------------------+
| | Controlling Document for |
| Transport | Encapsulation of Service Payload |
+------------------------+--------------------------------------------+
| AAL1/ATMF | af-vtoa-0078.000 [7] |
+------------------------+--------------------------------------------+
| AAL1/ITU | ITU-T H.222.1 [51] |
+------------------------+--------------------------------------------+
| AAL5/ATMF | af-vtoa-0083.000 [46] |
+------------------------+--------------------------------------------+
| AAL5/ITU | ITU-T H.222.1 [51] |
+------------------------+--------------------------------------------+
| AAL2/ATMF | af-vtoa-0113.000 [44] and |
| | af-vmoa-0145.000 [52] |
+------------------------+--------------------------------------------+
| AAL2/ITU | ITU-T I.366.2 [13] |
+------------------------+--------------------------------------------+
| AAL1/custom | Corporate document or |
| AAL2/custom | application-specific interoperability |
| AAL5/custom | statement. |
+------------------------+--------------------------------------------+
| AAL1/<corporateName> | |
| AAL2/<corporateName> | |
| AAL5/<corporateName> | |
| AAL1/IEEE:<oui> | Corporate document |
| AAL2/IEEE:<oui> | |
| AAL5/IEEE:<oui> | |
+------------------------+--------------------------------------------+
| RTP/AVP | Annex C of H.323 [45] |
+------------------------+--------------------------------------------+In H.323 Annex C applications [45], the <transport> parameter is "RTP/AVP". That's because these apps use the RTP protocol [2] and the audio/video profile [3] 🦋. The fact that RTP rides directly over AAL5 per [45] can be spelled out explicitly with the aalApp media attribute ✨.
A value of "AAL1/custom", "AAL2/custom" or "AAL5/custom" for the <transport> parameter can point to non-standard or semi-standard encapsulation schemes defined by a corporation or a multi-vendor agreement 🍓. Since there's no standard administration for this convention, care should be taken to preclude inconsistencies within the scope of a deployment. Bestie, be careful here 😭.
The "AAL1/<corporateName>", "AAL2/<corporateName>", "AAL5/<corporateName>", "AAL1/IEEE:<oui>", "AAL2/IEEE:<oui>" and "AAL5/IEEE:<oui>" <transport> values work the same way 🌸. They indicate non-standard transport mechanisms or AAL2 profiles, which should be used consistently within the scope of an application or deployment. The <corporateName> is the registered, globally unique name of a corporation (for example, Cisco or Telcordia etc.) 👑. The <oui> is the hex representation of a three-octet field, identical to the OUI maintained by the IEEE. Since it's always in hex, the "0x" prefix shall not be used. Leading zeros can be omitted. For example, "IEEE:00000C" and "IEEE:C" both refer to Cisco Systems, Inc. 💅
5.5.3 The Format List for AAL1 and AAL5 applications 🌈
In the AAL1 and AAL5 contexts, the <format list> is a list of payload types:
<payloadType#1> <payloadType#2>...<payloadType#n>In most AAL1 and AAL5 applications, the order of payload types implies a preference, with preferred payload types first and less favored ones after ⭐. The payload type can be statically assigned or dynamically mapped. Even though the transport isn't the same, SDP in the ATM context reuses the encoding names and payload types that IANA [31] registered for RTP 💜. Encoding names not listed in [31] use an "X-" prefix. Encodings that aren't statically mapped to payload types in [31] are dynamically mapped at connection establishment to payload types in the decimal range 96-127. The SDP 'atmmap' attribute (similar to 'rtpmap') is used for this purpose 🎀.
On top of the IANA-registered encoding names and payload types found in [31], Table 2 defines a few non-standard encoding names (with "X-" prefixes) 🧚.
5.5.4 The Format List for AAL2 applications 🫶
In the AAL2 context, the <format list> is a list of AAL2 profile types:
<profile#1> <profile#2>...<profile#n>In most applications, the order of profiles implies a preference, with preferred profiles first and less favored ones after 🔥. The <profile> parameter is a decimal number in the range 1-255 ✨.
5.5.5 Media information line construction ✨
okay so, using the parameter definitions from above, you can build the m line for AAL1-based audio media like this 💖
m=audio <virtualConnectionId> AAL1/ATMF <payloadType#1>
<payloadType#2>...<payloadType #n>Bestie, only payload types that are consistent with af-vtoa-78 [7] can be used in this construction. That's true whether they're statically mapped or dynamically assigned 🎀
Backwards compatibility tea ☕: the transport valueAAL1/AVPfrom earlier versions of this document should be treated as equivalent toAAL1/ATMF.AAL1/AVPis unsuitable because the AVP profile is closely tied to RTP. 🙈
Here's an example m line for audio over AAL1 🦋
m=audio VCCI-27 AAL1/ATMF 0This means an AAL1 VCC with VCCI=24 is used to carry PCMU audio, encapsulated according to ATMF's af-vtoa-78 [7]. The vibes are immaculate 💅
Here's another one, for audio over AAL1 🌸
m=audio $ AAL1/ATMF 0 8This means any AAL1 VCC can be used. If one already exists, picking it is subject to glare rules. The audio on this VCC is encapsulated according to ATMF's af-vtoa-78 [7]. The encodings are PCMU or PCMA, in preferential order 👑
Now the m line for AAL5-based audio media can be built like this ✨
m=audio <virtualConnectionId> AAL5/ATMF <payloadType#1>
<payloadType#2>...<payloadType #n>Here's an example for audio over AAL5 🧚
m=audio PORT-2/VPI-6/$ AAL5/ITU 9 15This implies that any VCI on VPI=6 of trunk port #2 may be used. The identities of the terms in the virtual connection ID are implicit in the application context. The audio on this VCC is encapsulated according to ITU-T H.222.1 [51]. The encodings are ITU-T G.722 or ITU-T G.728 (LD-CELP), in preferential order 🍓
The m line for AAL5-based H.323 Annex C audio [45] can be built like this 🌈
m=audio <virtualConnectionId> RTP/AVP <payloadType#1>
<payloadType#2>...<payloadType #n>For example, ngl this one's a whole vibe 😭
m=audio PORT-9/VPI-3/VCI-$ RTP/AVP 2 96
a=rtpmap:96 X-G727-32
a=aalType:AAL5
a=aalApp:itu_h323c - -This implies that any VCI on VPI=3 of trunk port #9 may be used. This VC encapsulates RTP packets directly on AAL5 per [45]. The rtpmap attribute (rather than atmmap) dynamically maps payload type 96 to the codec name X-G727-32 (Table 2). That name represents 32 kbps EADPCM 💜
The m line for AAL5-based video media can be built like this 🎀
m=video <virtualConnectionId> AAL5/ITU <payloadType#1>
<payloadType#2>...<payloadType #n>In this case, AAL5/ITU as the transport points to H.222.1 as the controlling standard [51]. Here's an example m line for video 🦋
m=video PORT-9/VPI-3/VCI-$ AAL5/ITU 33This means any VCI on VPI=3 of trunk port #9 may be used. The video on this VCC is encapsulated according to ITU-T H.222.1 [51]. The encoding scheme is an MPEG 2 transport stream (MP2T in Table 1). It's statically mapped per [31] to payload type 33 ⭐
Now for AAL2-based audio media, using the parameter definitions from the previous subsections, the media information line can be built like this 🫶
m=<media> <virtualConnectionId> <transport#1> <format list#1>
<transport#2> <format list#2> ... <transport#M> <format list#M>Here, <format list#i> has the form <profile#i_1>...<profile#i_N>. Unlike the m line for AAL1 or AAL5 applications, the m line for AAL2 applications can have multiple <transport> parameters, and each one is followed by a <format list>. That's because definitions can come from multiple sources (ATMF, ITU and non-standard documents) when choosing the AAL2 profile to bind to a connection 🌸
In most applications, the order of profiles implies a preference, with preferred profiles listed before less favored ones. So the same <transport> value can appear more than once in the same m line 💅
Here's an example m line for audio over AAL2 👑
m=audio VCCI-27/CID-19 AAL2/ITU 7 AAL2/custom 100 AAL2/ITU 1This means CID #19 on VCCI #27 is used to carry audio. It gives a preferential list of profiles for this connection: profile AAL2/ITU 7 defined in [13], profile AAL2/custom 100 defined in an application-specific or interoperability document, and profile AAL2/ITU 1 defined in [13] 🍓
Another AAL2 audio example 🧚
m=audio VCCI-$/CID-$ AAL2/ATMF 6 8This means any AAL2 CID may be used, subject to any applicable glare avoidance or reduction rules. The profiles that can be bound to this connection are AAL2/ATMF 6, defined in af-vtoa-0113.000 [44], and AAL2/ATMF 8, defined in af-vmoa-0145.000 [52]. These sources use non-overlapping profile number ranges, and the profiles they define fall under the <transport> category "AAL2/ATMF". This application doesn't order profiles by preference. That rule is known a priori and isn't embedded in the m line 🌈
One more AAL2 audio example, bestie 💜
m=audio VCCI-20/CID-$ AAL2/xyzCorporation 11AAL2 VCCs in this application are single-CID VCCs, so it's possible to wildcard the CID. The single-CID VCC with VCCI=20 gets selected. The AAL2 profile to be used is AAL2/xyzCorporation 11, defined by xyzCorporation 🎀
In some applications, a "-" can stand in for:
- <format list>
- <transport> and <format list>
This implies that these parameters are irrelevant or are known by other means (such as defaults). For example 🦋
m=audio VCCI-234 - -
a=aalType:AAL1This indicates the use of VCCI=234 with AAL1 adaptation and unspecified encoding 💖
In another example application, the aal2sscs3662 attribute can indicate <faxDemod> = "on" with any other competing options set to "off", and the aalType attribute can indicate AAL2. So 🙈
m=audio VCCI-123/CID-5 - -
a=aalType:AAL2
a=aal2sscs3662:audio off off on off on off off off - - -Besides indicating an audio medium, a VCCI of 123 and a CID of 5, the m line indicates an unspecified profile. The media attribute lines indicate an AAL2 adaptation layer, and the use of the audio SAP [13] to carry demodulated facsimile 📠✨
The media information line for "data" media has one of the following formats 🌸
m=data <virtualConnectionId> - -
m=data - - -The data could be circuit emulation data carried over AAL1 or AAL2, or packet data carried over AAL5. Media attribute lines, not the m line, indicate the adaptation type for data media. Here are some examples of how data media gets represented 💅
m=data PORT-7/VPI-6/VCI-$ - -
a=aalApp:AAL5_SSCOP- -This implies that any VCI on VPI=6 of trunk port #7 may be used. This VC uses SSCOP on AAL5 to transport data 👑
m=data PORT-7/VPI-6/VCI-50 - -
a=aalType:AAL1_SDT
a=sbc:6This implies that VCI 50 on VPI 6 on port 7 uses structured AAL1 to transfer 6 x 64 kbps circuit emulation data. It can also be represented as 🍓
m=data PORT-7/VPI-6/VCI-50 - -
b=AS:384
a=aalType:AAL1_SDTThe following lines 🧚
m=data VCCI-123/CID-5 - -
a=aalType:AAL2
a=sbc:2imply that CID 5 of VCCI 123 is used to transfer 2 x 64 kbps circuit emulation data 🌈
In the AAL1 context, it's also allowed to represent circuit mode data as an "audio" codec. If you do that, the codec types used are X-CCD or X-CCD-CAS. Those encoding names get dynamically mapped into payload types through the atmmap attribute. For example 💜
m=audio VCCI-27 AAL1/AVP 98
a=atmmap:98 X-CCD
a=sbc:6This implies that AAL1 VCCI=27 is used for 6 x 64 transmission 🎀
In the AAL2 context, the X-CCD codec can be assigned a profile type and number. Even though a profile table as described in ITU I.366.2 can't be constructed for this "codec", it's preferable to adopt the common AAL2 profile convention for it. An example AAL2 profile mapping for the X-CCD codec could look like this 🦋
PROFILE TYPE PROFILE NUMBER "CODEC" (ONLY ONE)
"custom" 200 X-CCDThe profile doesn't identify the number of subchannels ('n' in nx64). That's known by other means, such as the sbc media attribute line. For example, this media information line 💖
m=audio $ AAL2/custom 200
a=sbc:6implies 384 kbps circuit emulation using AAL2 adaptation 🌸
It's not necessary to define a profile with the X-CCD-CAS codec, since this method of CAS transport [7] isn't used in AAL2 applications 🫶
5.6. The Media Attribute Lines ✨
okay so, in an SDP line sequence, the media information line 'm' gets followed by one or more media attribute lines (the 'a' lines) 💖 they look like this:
a=<attribute>:<value>or
a=<value>generally, media attribute lines are optional 🦋 they only become necessary when they're needed to qualify the media information line. that qualifying is needed when the "m" line for an AAL1 or AAL5 session specifies a payload type that has to be dynamically mapped. the 'atmmap' media attribute line (defined below) is the one for this job 🫶
in attribute lines, subparameters that are meant to be left unspecified get set to a "-" 🌸 these are usually inapplicable, or if they are applicable, they're known some other way, like through provisioning. in some cases, an 'a' line with every parameter set to "-" carries no info and should be preferably omitted 💀 in other cases, like the 'lij' media attribute line, the very presence of the line means something 👑
RFC 2327 [1] doesn't place any restrictions on the order of 'a' lines relative to other 'a' lines. however, these lines must not contradict each other or the other SDP lines. inconsistencies are not to be ignored and should be flagged as errors 🚨 repeated media attribute lines can carry additional info, and those should not be inconsistent with each other.
applications will selectively use the optional media attribute lines listed below. this is meant to be an exhaustive list for describing the general attributes of ATM bearer networks ✨
the base SDP spec, RFC 2327 [1], allows the definition of new attributes. in that same spirit, some attributes defined in this document can also be used in SDP descriptions of IP and other non-ATM sessions. for example, the 'vsel', 'dsel' and 'fsel' attributes refer generically to codecs. they can be used for service-specific codec negotiation and assignment in non-ATM as well as ATM applications 🎀
SDP media attributes defined in this document for use in the ATM context are classified as:
- ATM bearer connection attributes (Section 5.6.1)
- AAL attributes (Section 5.6.2)
- Service attributes (Section 5.6.3).
- Miscellaneous media attributes, that cannot be classified as ATM, AAL or service attributes (Section 5.6.4).
in addition to these, the SDP attributes defined in [1] can also be used in the ATM context 💅 examples are:
- The attributes defined in RFC 2327 which allow indication of the direction in which a session is active. These are
a=sendonly,a=recvonly,a=sendrecv,a=inactive. - The 'Ptime' attribute defined in RFC 2327. It indicates the packet period. It is not recommended that this attribute be used in ATM applications, since packet period information is provided with other parameters (e.g., the profile type and number in the 'm' line, and the 'vsel', 'dsel' and 'fsel' attributes). Also, for AAL1 applications, 'ptime' is not applicable and should be flagged as an error. If used in AAL2 and AAL5 applications, 'ptime' should be consistent with the rest of the SDP description 🙈
- The 'fmtp' attribute used to designate format-specific parameters.
5.6.1. ATM bearer connection attributes 🦋
here's the summary list of the SDP media attributes that can be used to describe ATM bearer connections. each one gets a proper breakdown in the subsections after this 💜
- The 'eecid' attribute. This stands for 'end-to-end connection identifier'. It provides a means of correlating service-level connections with underlying ATM bearer connections. In the Q.1901 [36] context, the eecid is synonymous with the bnc-id (backbone network connection identifier).
- The 'aalType' attribute. This is used to indicate the nature of the ATM adaptation layer (AAL).
- The 'capability' attribute, which indicates the ATM transfer capability (ITU nomenclature), synonymous with the ATM Service Category (ATMF nomenclature).
- The 'qosClass' attribute, which indicates the QoS class of the ATM bearer connection.
- The 'bcob' attribute, which indicates the broadband connection oriented bearer class, and whether end-to-end timing is required.
- The 'stc' attribute, which indicates susceptibility to clipping.
- The 'upcc' attribute, which indicates the user plane connection configuration.
- The 'atmQOSparms' attribute, which is used to describe certain key ATM QoS parameters.
- The 'atmTrfcDesc' attribute, which is used to describe ATM traffic descriptor parameters.
- The 'abrParms' attribute, which is used to describe ABR-specific parameters. These parameters are per the UNI 4.0 signaling specification [5].
- The 'abrSetup' attribute, which is used to indicate the ABR parameters needed during call/connection establishment.
- The 'bearerType' attribute, which is used to indicate whether the underlying bearer is an ATM PVC/SPVC, an ATM SVC, or a subchannel within an existing ATM SVC/PVC/SPVC.
- The 'lij' attribute, which is used to indicate the presence of a connection that uses the Leaf-initiated-join capability described in UNI 4.0 [5], and to optionally describe parameters associated with this capability.
- The 'anycast' attribute, which is used to indicate the applicability of the anycast function described in UNI 4.0 [5], and to optionally qualify it with certain parameters.
- The 'cache' attribute, which is used to enable SVC caching and to specify an inactivity timer for SVC release.
- The 'bearerSigIE' attribute, which can be used to represent ITU Q-series information elements in bit-map form. This is useful in describing parameters that are not closely coupled to the ATM and AAL layers. Examples are the B-HLI and B-LLI IEs specified in ITU Q.2931 [15], and the user-to-user information element described in ITU Q.2957 [48].
5.6.1.1. The 'eecid' attribute 💖
the 'eecid' attribute is synonymous with the 4-byte 'bnc-id' parameter used by T1SI, the ATM forum and the ITU (Q.1901) standardization effort. 'eecid' stands for 'end-to-end connection identifier', while 'bnc-id' stands for 'backbone network connection identifier'. the name "backbone" is slightly misleading, since it refers to the entire ATM network, including the ATM edge and ATM core networks. in Q.1901 terminology, an ATM "backbone" connects TDM or analog edges 🌈
the term 'bnc-id' might be used in the bearer signaling plane and in an ISUP (Q.1901) call control plane, but SDP session descriptors use the neutral term 'eecid' ✨ this gives a common SDP baseline for applications that use ISUP (Q.1901) and applications that use SIP/SIP+.
Section 5.6.6 depicts the use of the eecid in call establishment procedures. in these procedures, the eecid is used to correlate service-level calls with SVC set-up requests 🎀
in the forward SVC establishment model, the call-terminating gateway selects an eecid and transmits it via SDP to the call-originating gateway. the call originating gateway then transmits this eecid to the call terminating gateway via the bearer set-up message (SVC set-up or Q.2630.1 establish request).
in the backward SVC establishment model, the call-originating gateway selects an eecid and transmits it via SDP to the call-terminating gateway. the call terminating gateway then transmits this eecid to the call originating gateway via the bearer set-up message (SVC set-up or Q.2630.1 establish request).
the value of the eecid attribute needs to be unique within the node terminating the SVC set-up, but not across multiple nodes. so the SVC-terminating gateway has complete control over using and releasing values of this parameter 👑 the eecid attribute is used to correlate, one-to-one, received bearer set-up requests with service-level call control signaling.
within an SDP session description, the eecid attribute is used as follows:
a=eecid:<eecid>where <eecid> consists of up to 8 hex digits (equivalent to 4 octets). since this is always represented in hex, the "0x" prefix shall not be used 🙅
within the text representation of the <eecid> parameter, hex digits to the left are more significant than hex digits to the right (Section 2.2).
this SDP document does not specify how the eecid (synonymous with bnc-id) is to be communicated through bearer signaling (Q.931, UNI, PNNI, AINI, IISP, proprietary signaling equivalent, Q.2630.1). that's a job for these bearer signaling protocols. however, the following informative statements are made to convey a sense of the interoperability that is a goal of current standardization efforts 🫶
- ITU Q.2941.3 and the ATMF each recommend the use of the GIT IE for carrying the eecid (synonymous with bnc-id) in the set-up message of ATM signaling protocols (Q.2931, UNI 4.0, PNNI, AINI, IISP). The coding for carrying the eecid (bnc-id) in the GIT IE is defined in ITU Q.2941.3 and accepted by the ATM forum.
- Another alternate method is to use the called party subaddress IE. In some networks, this might be considered a protocol violation and is not the recommended means of carrying the eecid (bnc-id). The GIT IE is the preferred method of transporting the eecid (bnc-id) in ATM signaling messages 🙈
- The establish request (ERQ) message of the Q.2630.1 [37] signaling protocol can use the SUGR (Served User Generated Reference) IE to transport the eecid (bnc-id).
the node assigning the eecid can release and re-use it when it receives a Q.2931 [15] set-up message or a Q.2630.1 [37] establish request message containing the eecid 🔥
however, in both cases (backward and forward models), it is recommended that this eecid be retained until the connection terminates. since the eecid space is large enough, it is not necessary to release it as soon as possible 💅
5.6.1.2. The 'aalType' attribute 🌸
when present, the 'aalType' attribute is used to indicate the ATM adaptation layer. if this information is redundant with the 'm' line, it can be omitted 🍓 the format of the 'aalType' media attribute line is as follows:
a=aalType: <aalType>here, <aalType> can take on the following string values: "AAL1", "AAL1_SDT", "AAL1_UDT", "AAL2", "AAL3/4", "AAL5" and "USER_DEFINED_AAL". note that "AAL3/4" and "USER DEFINED AAL" are not addressed in this document 🧚
5.6.1.3 The 'capability' attribute ✨
okay so when this attribute shows up, it tells you the ATM Transfer Capability from ITU I.371 [28] 💅 which is basically the same thing as the ATM Service Category in the UNI 4.1 Traffic Management spec [6]. main character energy 🎀
The 'capability' line comes in one of two shapes 🦋
a=capability:<asc> <subtype>
a=capability:<atc> <subtype>The <asc> values are:
"CBR", "nrt-VBR", "rt-VBR", "UBR", "ABR", "GFR"The <atc> values are:
"DBR","SBR","ABT/IT","ABT/DT","ABR"Some apps might use non-standard <atc> and <asc> values that aren't on these lists 👀 so equipment designers will need to agree on what those mean and what they imply, no cap.
The <subtype> is lowkey like a subscript on the <asc> and <atc> fields 🧚 It can be any integer in general, or "-", which means it doesn't apply, or the underlying data is known some other way, like provisioning.
For an <asc> of CBR and an <atc> of DBR, the <subtype> can be picked from Table 4-6 of ITU Q.2931 [15] 🌸
<asc>/<atc> <subtype> Meaning
"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)Note that [15] does not define a <subtype> value of 3 🙈
For other <asc> and <atc> values, these <subtype> values can be assigned, based on [6] and [28] 💖
<asc>/<atc> <subtype> Meaning
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 SBR3It's beyond the scope of this spec to check whether some of the ATMF and ITU definitions are equivalent 🫶 those need to be recognised from the ATMF and ITU source specs and used as much as possible, so ATM node design gets simpler.
When the bearer connection is a single AAL2 CID connection inside a multiplexed AAL2 VC, the 'capability' attribute does not apply 🚫
5.6.1.4 The 'qosClass' attribute
when this one's present, it indicates the QoS class from ITU I.2965.1 [34] ✨
The 'qosClass' line looks like this:
a=qosClass:<qosClass>Here, <qosClass> is an integer from 0 to 5 🔥
<qosClass> Meaning
0 Default QoS
1 Stringent
2 Tolerant
3 Bi-level
4 Unbounded
5 Stringent bi-level5.6.1.5 The 'bcob' attribute
when it's present, 'bcob' represents the broadband connection oriented bearer class from [5], [15] and [33] 👑 it can also be used to say whether end-to-end timing is required 🕰️
The 'bcob' line is structured like this:
a=bcob:<bcob> <eetim>Here, <bcob> is the decimal or hex form of a 5-bit field. These values are defined right now:
<bcob> Meaning
0x01 BCOB-A
0x03 BCOB-C
0x05 Frame relaying bearer service
0x10 BCOB-X
0x18 BCOB-VP (transparent VP service)The <eetim> can be "on" or "off", depending on whether end-to-end timing is required or not (Table 4-8 of [15]) ⭐
Either of these can be left unspecified by setting it to a "-" 🌈 A 'bcob' line with every parameter set to "-" carries no information, so it should be omitted 💀
5.6.1.6 The 'stc' attribute
when present, 'stc' represents susceptibility to clipping 🎧 the line looks like this:
a=stc:<stc>Here, <stc> is the decimal equivalent of a 2-bit field. Right now, every value is unused and reserved, except these two 🍓
<stc> value Binary Equivalent Meaning
0 00 Not susceptible to clipping
1 01 Susceptible to clipping5.6.1.7 The 'upcc' attribute
when present, 'upcc' represents the user plane connection configuration 🧚♀️ the line is:
a=upcc:<upcc>Here, <upcc> is the decimal equivalent of a 2-bit field. Right now, every value is unused and reserved, except these two 💜
<upcc> value Binary Equivalent Meaning
0 00 Point to point
1 01 Point to multipoint5.6.1.8 The 'atmQOSparms' attribute
when present, 'atmQOSparms' is used to describe some key ATM QoS parameters 🌸
The 'atmQOSparms' line is structured like this:
a=atmQOSparms:<directionFlag><cdvType><acdv><ccdv><eetd><cmtd><aclr>The <directionFlag> can be "f", "b" or "fb" ✨ "f" is forward, "b" is backward, and "fb" means both directions (forward and backward). The conventions for forward and backward are per section 2.3 🦋
The <cdvType> can be "PP" or "2P" 🎀 these mean peak-to-peak and two-point CDV, as defined in UNI 4.0 [5] and ITU Q.2965.2 [35] respectively.
<acdv> and <ccdv> are the acceptable and cumulative CDVs 🫶 they're in microseconds and written as the decimal equivalent of a 24-bit field. They use the cell loss ratio, <aclr>, as the "alpha" quantiles from the ATMF TM 4.1 spec [6] and ITU I.356 [47] 🌈
<eetd> and <cmtd> are the end-to-end and cumulative transit delays, in milliseconds 🕰️ each is the decimal equivalent of a 16-bit field, and they're defined in Q.2965.2 [35], UNI 4.0 [5] and Q.2931 [15] 💅
<aclr> is the forward and backward acceptable cell loss ratio 📉 it's the number of cells lost divided by the number of cells sent. It's the decimal equivalent of an 8-bit field, and that field expresses an order of magnitude n, where n is an integer from 1 to 15. The Cell Loss Ratio is 10 raised to the power of minus n 🔥
The <directionFlag> is always there ✨ apart from that, everything else can be set to "-" to say it's not specified, not applicable or implied 🙈 but there's a catch: there must be some specified parameters for the line to be useful in an SDP description 👀
You can have several 'atmQOSparms' lines in one SDP description 💖
Here's an example for an rt-VBR, single-CID AAL2 voice VC 🎧
a=atmQOSparms:f PP 8125 3455 32000 - 11
a=atmQOSparms:b PP 4675 2155 18000 - 12This implies 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, a backward cumulative peak-to-peak CDV of 2.155 ms, a forward end-to-end transit delay of 32 ms, a backward end-to-end transit delay of 18 ms, an unspecified forward cumulative transit delay, an unspecified backward cumulative transit delay, a forward cell loss ratio of 10 raised to minus 11 and a backward cell loss ratio of 10 to the minus 12 🦋
And here's how you'd give the same parameters for both directions 🎀
a=atmQOSparms:fb PP 8125 3455 32000 - 11This implies a forward and backward acceptable peak-to-peak CDV of 8.125 ms, a forward and backward cumulative peak-to-peak CDV of 3.455 ms, a forward and backward end-to-end transit delay of 32 ms, an unspecified cumulative transit delay in the forward and backward directions, and a cell loss ratio of 10 raised to minus 11 in the forward and backward directions 💜
5.6.1.9 The 'atmTrfcDesc' attribute 🦋
okay so this one is giving traffic descriptor vibes 💅 When it's there, atmTrfcDesc is how you spell out the ATM traffic descriptor parameters. You can have several atmTrfcDesc lines in one SDP description, so go wild 🌸
The line looks like this:
a=atmTrfcDesc:<directionFlag><clpLvl>
<pcr><scr><mbs><cdvt><mcr><mfs><fd><te>The <directionFlag> can be "f", "b" or "fb". "f" is forward, "b" is backward, and "fb" means both directions 🧚 The forward and backward conventions come from section 2.3, so check there if you're confused about which way is which.
The <directionFlag> is always specified 💖 Everything except the <directionFlag> can be set to "-" to say "not specified, inapplicable or implied." BUT there has to be at least some specified parameters or the line isn't useful in an SDP description. no cap 🙈
The <clpLvl> (CLP level) tells you whether the rates and bursts apply to CLP values of 0 or (0+1) ✨ It can be "0", "0+1" or "-". If you want rates and bursts for both <clpLvl> values, you need two separate lines for each direction in the same session descriptor. And if <clpLvl> is "-", that means CLP is known some other way, like a default or MIB provisioning etc. 🎀
The meaning, units and applicability of the other parameters come from [6] and [28]. Here's the tea:
PARAMETER MEANING UNITS APPLICABILITY
<pcr> PCR Cells/ CBR, rt-VBR, nrt-VBR,
second ABR, UBR, GFR;
CLP=0,0+1
<scr> SCR Cells/ rt-VBR, nrt-VBR;
second CLP=0,0+1
<mbs> MBS Cells rt-VBR, nrt-VBR,
GFR;
CLP=0,0+1
<cdvt> CDVT Microsec. CBR, rt-VBR, nrt-VBR,
ABR, UBR, GFR;
CLP=0,0+1
<mcr> MCR Cells/ ABR,GFR;
second CLP=0+1
<mfs> MFS Cells GFR;
CLP=0,0+1
<fd> Frame "on"/"off" CBR, rt-VBR, nrt-VBR,
Discard ABR, UBR, GFR;
Allowed CLP=0+1
<te> CLP "on"/"off" CBR, rt-VBR, nrt-VBR,
tagging ABR, UBR, GFR;
Enabled CLP=0<fd> is all about frame discard being permitted 🍓 It can be "on" or "off". In the GFR case, frame discard is always enabled, so you can set this one to "-" for GFR. Since <fd> doesn't depend on CLP, it only matters when <clpLvl> = "0+1". It should be "-" when <clpLvl> = "0".
<te> (tag enable) says CLP tagging is allowed, with "on" or "off" as the values 💜 It only applies to cells with a CLP of 0, so it's only meaningful when <clpLvl> = "0". It should be "-" when <clpLvl> = "0+1".
Here's an example for an rt-VBR, single-CID AAL2 voice VC, which is a total vibe 🌈
a=atmTrfcDesc:f 0+1 200 100 20 - - - on -
a=atmTrfcDesc:f 0 200 80 15 - - - - off
a=atmTrfcDesc:b 0+1 200 100 20 - - - on -
a=atmTrfcDesc:b 0 200 80 15 - - - - offSo what does this one actually mean? Forward and backward PCR of 200 cells per second for all cells regardless of CLP. Forward and backward PCR of 200 cells per second for cells with CLP=0. Forward and backward SCR of 100 cells per second for all cells regardless of CLP, and 80 cells per second for cells with CLP=0. Forward and backward MBS of 20 cells for all cells regardless of CLP, and 15 cells for cells with CLP=0. CDVT is unspecified and can be known some other way. MCR and MFS are unspecified because they're inapplicable. Frame discard is enabled in both directions, and tagging is not enabled in either direction ✨
The <pcr>, <scr>, <mbs>, <cdvt>, <mcr> and <mfs> are all decimal integers, within the range defined in Section 6. See section 2.2 about leaving off leading zeros in decimal representations 🫶
5.6.1.10 The 'abrParms' attribute 🔥
When it's present, abrParms is used to indicate the "additional" ABR parameters from the UNI 4.0 signaling specification [5]. Again, you can have several abrParms lines in an SDP description 💅
The line looks like this:
a=abrParms:<directionFlag><nrm><trm><cdf><adtf>The <directionFlag> works exactly like before: "f", "b" or "fb", with the conventions from section 2.3 🌸 It's always specified, and everything else can be "-" for not specified, inapplicable or implied. Same rule as always: there has to be some specified parameters or the line is useless in an SDP description 🙈
These parameters get mapped into the ABR service parameters in [6], kind of like this. In SDP they can be decimal integers, with fractions allowed for some of them. For the full scoop on meaning, units and applicability, check [5] and [6] ✨
In SDP, these parameters are written as the decimal or hex version of the binary fields below:
+-----------+----------------------------------+-----------------------+
| 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 | |
+-----------+----------------------------------+-----------------------+5.6.1.11 The 'abrSetup' attribute 🎀
When it's present, abrSetup tells you the ABR parameters needed during call/connection establishment. That's Section 10.1.2.2 of the UNI 4.0 signaling specification [5], so it's giving official 👑 The line is structured like this:
a=abrSetup:<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>Here's what each one is:
+-----------+----------------------------------+-----------------------+
| 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 |
+-----------+----------------------------------+-----------------------+Check section 2.3 for what 'forward' and 'backward' mean here 🧚
If any of these parameters in the abrSetup line isn't specified, is inapplicable or is implied, then it gets set to h "- " 🍓
5.6.1.12 The 'bearerType' attribute 🦋
When it's present, bearerType tells you what the underlying bearer is: an ATM PVC/SPVC, an ATM SVC, or a subchannel inside an existing ATM SVC/PVC/SPVC 💖 For ATM SVCs and AAL2 CID connections, it can also say whether the media gateway starts connection set-up through bearer signaling (Q.2931-based or Q.2630.1 based). The format looks like this:
a=bearerType: <bearerType> <localInitiation>The <bearerType> field can be "PVC", "SVC" or "CID", with the semantics already defined above. "PVC" covers both the PVC and SPVC cases 🌈
If the underlying bearer is a PVC/SPVC, or a CID assigned by the MGC instead of through bearer signaling, the <localInitiation> flag can be left out or set to "-" ✨ When bearer signaling is used, the flag can be left out if it's already known by default or some other means whether the media gateway starts connection set-up via bearer signaling. You only need to include it when you want to say so explicitly, and then it's "on" or "off". An "on" value means the media gateway is responsible for starting connection set-up via bearer signaling (SVC signaling or Q.2630.1 signaling). An "off" value means it isn't 🫶
5.6.1.13 The 'lij' attribute ✨
okay so the lij attribute 🦋 says "hey, this connection uses the Leaf-initiated-join capability" from UNI 4.0 [5], and it can also optionally describe the parameters for that capability 💅. The format is:
a=lij: <sci><lsn>The <sci> (screening indication) is a 4-bit field written as a decimal or hex integer 🎀. It's defined in the UNI 4.0 signaling spec [5]. The ATMF and/or ITU might define its values later 👀. For now, every value is reserved except 0, which means 'Network Join without Root Notification' ✨.
The <lsn> (leaf sequence number) is a 32-bit field, also a decimal or hex integer. Per UNI 4.0 [5], a joining leaf uses it to match messages with responses during LIJ (leaf initiated join) procedures 🫶.
Each of these fields can be set to "-" if you don't want to specify it in an SDP descriptor 💖.
5.6.1.14 The 'anycast' attribute 🌸
when this line is present, it's telling you the anycast function from UNI 4.0 [5] applies, and you can add some optional parameters to qualify it 🧚. The format is:
a=anycast: <atmGroupAddress> <cdStd> <conScpTyp> <conScpSel>The <atmGroupAddress> follows Annex 5 of UNI 4.0 [5]. Inside an SDP descriptor, it can be written in any of the formats (NSAP, E.164, GWID/ALIAS) described elsewhere in this document 🌈.
The remaining subparameters mirror the connection scope selection information element in UNI 4.0 [5], so they have the same meaning there. Here's the breakdown:
PARAMETER MEANING REPRESENTATION
<cdStd> Coding standard for the Decimal or hex
connection scope selection IE equivalent of
Definition: UNI 4.0 [5] 2 bits
<conScpTyp> Type of connection scope Decimal or hex
Definition: UNI 4.0 [5] equivalent of
4 bits
<conScpSel> Connection scope selection Decimal or hex
Definition: UNI 4.0 [5] equivalent of
8 bitsCurrently, all values of <cdStd> and <conScpTyp> are reserved, except <cdStd> = 3 (ATMF coding standard) and <conScpTyp> = 1 (connection scope type of 'organizational') 🔥.
Each of these fields can be set to "-" if you don't want to specify it in an SDP descriptor 💅.
5.6.1.15 The 'cache' attribute 💜
this one turns on SVC caching 🌙. The format is:
a=cache:<cacheEnable><cacheTimer>The <cacheEnable> flag says whether caching is on or off, using the string values "on" and "off" respectively 💖.
The <cacheTimer> is the period of inactivity after which the SVC gets released, which means an SVC release message gets sent into the network ⏳. It's the decimal or hex equivalent of a 32-bit field, and the timeout is in seconds. As usual, leading zeros can be omitted. For instance:
a=cache:on 7200this implies that the cached SVC is to be deleted if it's idle for 2 hours 🫠.
The <cacheTimer> can be set to "-" if it's inapplicable or implied ✨.
5.6.1.16 The 'bearerSigIE' attribute 🦋
okay so ATM signaling standards have these things called 'escape mechanisms' 🚪, which let you represent, signal and negotiate higher-layer parameters. Examples are the B-HLI and B-LLI IEs specified in ITU Q.2931 [15], and the user-to-user information element described in ITU Q.2957 [48] 💅.
The 'bearerSigIE' (bearer signaling information element) attribute gives you a similar escape mechanism that works with these ATM SDP conventions 🎀. The format is:
a=bearerSigIE: <bearerSigIEType> <bearerSigIELng> <bearerSigIEVal>When a 'bearerSigIE' media attribute line is present, all of its subparameters are mandatory 🙈. The "0x" prefix isn't used, since these are always represented in hex 🔥.
The <bearerSigIEType> is exactly 2 hex digits. It's the unique IE identifier from the ITU Q-series standards 🌸. Leading zeros are not omitted here. Some pertinent values are 7E (User-user IE per ITU Q.2957 [48]), 5F (B-LLI IE) and 5D (B-HLI IE) 💖. B-LLI and B-HLI stand for Broadband Low-layer Information and Broadband High-layer Information, and they're defined in ITU Q.2931 [15]. Both of them refer to layers above the ATM adaptation layer 🧚.
The <bearerSigIELng> is 1-4 hex digits long. It's the length of the information element in octets, and leading zeros may be omitted 🍓.
The <bearerSigIEVal> is the value of the information element, written as a hexadecimal bit map 🌈. The size of this bit map depends on the network or service, but setting an upper bound of 256 octets (512 hex digits) is adequate ✨. Since it's a bit map, leading zeros should not be omitted 🙈. The number of hex digits in this bit map is even 💜.
5.6.2 ATM Adaptation Layer (AAL) attributes 🌷
this is the summary list of the SDP media attributes you can use to describe the ATM Adaptation Layer (AAL) 💅. Each one gets its own subsection after this, so hang tight 🫶.
- 💖 The
'aalApp'attribute, which points to the controlling standard for an application layer above the ATM adaptation layer. - 🎀 The
'cbrRate'attribute, which represents the CBR rate octet defined in Table 4-6 of ITU Q.2931 [15]. - 🌸 The
'sbc'attribute, which denotes the subchannel count for n x 64 clear channel communication. - ⏱️ The
'clkrec'attribute, which indicates the clock recovery method for AAL1 unstructured data transfer (UDT). - 🛡️ The
'fec'attribute, which indicates the use of forward error correction. - 🧩 The
'prtfl'attribute, which indicates the fill level of partially filled cells. - 🧱 The
'structure'attribute, which indicates whether AAL1 structured data transfer (SDT) is present or absent, and the size of the SDT blocks. - 📦 The
'cpsSDUsize'attribute, which indicates the maximum size of the CPCS SDU payload. - 🌈 The
'aal2CPS'attribute, which indicates that an AAL2 CPS sublayer, as defined in ITU I.363.2 [13], is associated with the VCC referred to in the 'm' line. Optionally, it can indicate selected CPS options and parameter values for this VCC. - 🦋 The
'aal2CPSSDUrate'attribute, which places an upper bound on the SDU bit rate for an AAL2 CID. - 🌙 The
'aal2sscs3661unassured'attribute, which indicates the presence of an AAL2 SSCS sublayer with unassured transmission, as defined in ITU I.366.1 [12]. Optionally, it can indicate selected options and parameter values for this SSCS. - ✨ The
'aal2sscs3661assured'attribute, which indicates the presence of an AAL2 SSCS sublayer with assured transmission, as defined in ITU I.366.1 [12]. Optionally, it can indicate selected options and parameter values for this SSCS. - 🎀 The
'aal2sscs3662'attribute, which indicates the presence of an AAL2 SSCS sublayer as defined in ITU I.366.2. Optionally, it can indicate selected options and parameter values for this SSCS. - 🔥 The
'aal5sscop'attribute, which indicates the existence of an SSCOP protocol layer over an AAL5 CPS layer, along with the parameters that pertain to this SSCOP layer.
5.6.2.1 The 'aalApp' attribute 💅
okay so when this one shows up, the 'aalApp' attribute points you to the standard that controls an application layer sitting above the ATM adaptation layer 🦋 the line looks like this:
a=aalApp: <appClass> <oui> <appId>if any of the subparameters (<appClass>, <oui> or <appId>) is meant to be left unspecified, you set it to "-" 🌸 but here's the tea: an 'aalApp' line where every single subparameter is "-" tells you literally nothing, so it should be omitted 🙈
the <appClass> (application class) field takes one of the string values below. this list is not exhaustive, so anything not on it gets an "X-" prefix 💜
<appClass> Meaning
"itu_h323c" Annex C of H.323 which specifies direct
RTP on AAL5 [45].
"af83" af-vtoa-0083.001, which specifies
variable size AAL5 PDUs with PCM voice
and a null SSCS [46].
"AAL5_SSCOP" SSCOP as defined in ITU Q.2110 [43]
running over an AAL5 CPS [21].
No information is provided regarding
any layers above SSCOP such as Service
Specific Coordination Function (SSCF)
layers.
"itu_i3661_unassured" SSCS with unassured transmission,
per ITU I.366.1 [12].
"itu_i3661_assured" SSCS with assured transmission,
per ITU I.366.1 [12]. This uses SSCOP [43].
"itu_i3662" SSCS per ITU I.366.2 [13].
"itu_i3651" Frame relay SSCS per ITU I.365.1 [39].
"itu_i3652" Service-specific coordination function,
as defined in ITU I.365.2, for Connection
Oriented Network Service (SSCF-CONS) [40].
This uses SSCOP [43].
"itu_i3653" Service-specific coordination function,
as defined in ITU I.365.3, for Connection
Oriented Transport Service (SSCF-COTS) [41].
This uses SSCOP [43].
"itu_i3654" HDLC Service-specific coordination function,
as defined in ITU I.365.4 [42].
"FRF5" Use of the FRF.5 frame relay standard [53],
which references ITU I.365.1 [39].
"FRF8" Use of the FRF.8.1 frame relay standard [54].
This implies a null SSCS and the mapping of
the frame relay header into the ATM header.
"FRF11" Use of the FRF.11 frame relay standard [55].
"itu_h2221" Use of the ITU standard H.222.1 for
audiovisual communication over AAL5 [51].the <oui> (Organizationally Unique Identifier) is the organization that's responsible for defining the <appId> (Application Identifier) 🎀 the IEEE maintains it, and one of its uses is in 802 MAC addresses. it's a three-octet field written as one to six hex digits, and since it's always hex, there's no "0x" prefix. leading zeros can be dropped 🍓
the <appId> is the application ID: a hex number with up to 8 digits. leading zeros can be dropped here too, and again no "0x" prefix because it's always hexadecimal ✨ right now the only org that has defined application identifiers is the ATM forum 👑 those were defined for AAL2 ([44], [52], Section 5 of [61]), and inside SDP you use them with <appClass> = itu_i3662. the <oui> for the ATM forum is 0x00A03E 🧚
here's the main example, using the aalApp line to say 'Loop Emulation Service using CAS (POTS only) without the Emulated Loop Control Protocol (ELCP) [52].' the Application ID is defined by the ATM forum [61] and the SSCS is per ITU I.366.2 [13] 💖
a=aalApp:itu_i3662 A03E Aif you don't drop the leading zeros, it looks like this:
a=aalApp:itu_i3662 00A03E 0000000Asince application identifiers have only been specified in the context of the AAL2 SSCS from ITU I.366.2 [13], you can set <appClass> to '-' without any ambiguity 🦋 so the line shrinks to:
a=aalApp:- A03E Aor
a=aalApp:- 00A03E 0000000A5.6.2.2 The 'cbrRate' attribute 🌈
when this one's present, the 'cbrRate' attribute carries the CBR rate octet defined in Table 4-6 of ITU Q.2931 [15]. the format is:
a=cbrRate: <cbrRate>the <cbrRate> is always exactly two hex digits, and the "0x" prefix is left off since it's always hex 🌸 these are the values the ITU has defined so far:
+------------+-----------------------------------------------+
| VALUE | MEANING |
| (hex) | |
+------------+-----------------------------------------------+
| 01 | 64 kbps |
+------------+-----------------------------------------------+
| 04 | 1544 kbps |
+------------+-----------------------------------------------+
| 05 | 6312 kbps |
+------------+-----------------------------------------------+
| 06 | 32064 kbps |
+------------+-----------------------------------------------+
| 07 | 44736 kbps |
+------------+-----------------------------------------------+
| 08 | 97728 kbps |
+------------+-----------------------------------------------+
| 10 | 2048 kbps |
+------------+-----------------------------------------------+
| 11 | 8448 kbps |
+------------+-----------------------------------------------+
| 12 | 34368 kbps |
+------------+-----------------------------------------------+
| 13 | 139264 kbps |
+------------+-----------------------------------------------+
| 40 | n x 64 kbps |
+------------+-----------------------------------------------+
| 41 | n x 8 kbps |
+------------+-----------------------------------------------+it's preferable to just omit the cbrRate attribute rather than set it to "-", because "-" conveys no information at all 🙈
5.6.2.3 The 'sbc' attribute 🍓
the 'sbc' media attribute line gives the subchannel count, and it only matters for n x 64 clear channel communication 💅 a clear n x 64 channel can use AAL1 (ATM forum af-vtoa-78) or AAL2 adaptation (ITU I.366.2). there's no standard definition for it yet, but using AAL5 for this is also possible 🫶 an n x 64 clear channel is represented by the encoding names "X-CCD" and "X-CCD-CAS" in Table 2.
the format is:
a=sbc:<sbc>the <sbc> can be written as a decimal or hex integer 💜 it tells you how many DS0s in a T1 or E1 frame are aggregated for clear channel data. for T1-based applications it's an integral value in the inclusive range [1...24], and for E1-based applications it's an integral value in the inclusive range [1...31]. if it's omitted, other means are to be used to figure out the subchannel count 🔥
the 'sbc' attribute is the direct way to say how many 64 kbps subchannels are bundled into an n x 64 clear channel. there's also an alternate route through the SDP bandwidth information, or 'b', line [1]. instead of counting subchannels there, you give the aggregate bandwidth in kbps. the 'b' line syntax, copied verbatim from [1], looks like this:
b=<modifier>:<bandwidth-value>for n x 64 clear channels, the <modifier> is the text string "AS", which says the 'b' line is application-specific 🌈 the decimal <bandwidth-value> (in kbps) is limited to these values in this context:
64, 128, 192, 256, 320, 384, 448, 512, 576, 640, 704, 768, 832,
896, 960, 1024, 1088, 1152, 1216, 1280, 1344, 1408, 1472, 1600,
1664, 1728, 1792, 1856, 1920, 1984so for n x 64 circuit mode data service, this:
a=sbc:6is equivalent to this:
b=AS:384and this:
a=sbc:2is equivalent to this:
b=AS:1285.6.2.4 The 'clkrec' attribute 🦋
when present, the 'clkrec' attribute tells you the clock recovery method ⭐ it matters for AAL1 unstructured data transfer (UDT). the format is:
a=clkrec:<clkrec>the <clkrec> field takes one of these string values: "NULL", "SRTS" or "ADAPTIVE" 🧚 SRTS and adaptive clock recovery are both defined in ITU I.363.1 [10]. "NULL" means the stream (like a T1/E1) that's encapsulated in ATM is either synchronous to the ATM network or gets retimed via slip buffers before AAL1 encapsulation 💖
5.6.2.5 The 'fec' attribute 🫶
when present, the 'fec' attribute says whether forward error correction is in use 🔥 right now there's one FEC method defined for AAL1, in ITU I.363.1 [10]. the format is:
a=fec:<fecEnable>the <fecEnable> flag shows the presence or absence of Forward Error Correction 👑 its string values are "NULL", "LOSS_SENSITIVE" and "DELAY_SENSITIVE". a "NULL" value means this capability is disabled. FEC can be turned on differently for delay-sensitive and loss-sensitive connections 🌸
5.6.2.6 The 'prtfl' attribute ✨
Okay so, the 'prtfl' attribute tells you how full each cell is 🧁 If it's not there, you fall back to other stuff, like provisionable defaults, to figure out whether partial fill is happening and how much.
This attribute counts the non-pad payload octets 💅 It does NOT include any AAL SAR or convergence sublayer octets. Think of an AAL1 app that uses partly filled cells with padding at the end. Here, 'prtfl' counts the leading payload octets, without any AAL overhead 🦋
The line looks like this:
a=prtfl:<partialFill><partialFill> can be written as a decimal or a hex integer 🔢
Generally, the allowed values are integers from 1 to 48 inclusive. The upper bound changes between adaptations, though, because the AAL overhead varies 🌈 If the partial fill you ask for is greater than or equal to the maximum fill, you get complete fill. And a partial fill of 48 always turns partial fill off 🙈
In AAL1, this line applies the same way to both P and non-P cells. If the app doesn't tell P and non-P cells apart, a value of 47 means complete fill, which is the same as no partial fill at all. If the app DOES tell them apart, a value of 46 means no padding in P-cells and one octet of padding in non-P cells 🎀
Now the important bit 🚨 If partial fill is on (so there's padding in at least some cells), AAL1 structures must not be split across cell boundaries. They shall fit inside any cell, which means their size has to be less than or equal to the partial fill size. Also, the partial fill size is preferably an integer multiple of the structure size. If it isn't, the partial fill size in the SDP description shall be truncated to a multiple. For example, a partial fill of 40 gets truncated to 36, so you can fit six 6 x 64 channels 💖
5.6.2.7 The 'structure' attribute 🌸
This one only applies to AAL1 connections. When it's there, 'structure' tells you whether structured data transfer (SDT) is on, plus the size in octets of the SDT blocks 🧚
The line looks like this:
a=structure: <structureEnable> <blksz><structureEnable> is the presence or absence flag for SDT. It can be "on" or "off". "on" means AAL1 structured data transfer (SDT), and "off" means AAL1 unstructured data transfer (UDT) 🦋
<blksz> is the block size. It's an optional 16-bit field [15] and you can write it in decimal or hex. If it doesn't apply, like with unstructured data transfer (UDT), set it to "-". For SDT, you can also set it to "-" when <blksz> is already known some other way. For instance, af-vtoa-78 [7] fixes the structure size for n x 64 service, with or without CAS 💅 The theoretical max value of <blksz> is 65,535, although most services use way less 🙈
5.6.2.8 The 'cpsSDUsize' attribute 💜
When it's present, 'cpsSDUsize' tells you the maximum size of the CPCS SDU payload. You can have several 'cpsSDUsize' lines in one SDP description 🌈
The line looks like this:
a=cpsSDUsize:<directionFlag><cpcs><directionFlag> can be "f", "b" or "fb". "f" is forward, "b" is backward, and "fb" covers both directions. The forward and backward conventions follow section 2.3 🧭
<cpcs> is a 16-bit integer, decimal or hex. Here's what it means for each application:
Application Field Meaning Values
AAL5 <cpcs> Maximum CPCS-SDU size 1- 65,535
AAL2 <cpcs> Maximum CPCS-SDU size 45 or 645.6.2.9 The 'aal2CPS' attribute 🎀
When it's present, 'aal2CPS' describes parameters for the AAL2 CPS layer 🍓
The line looks like this:
a=aal2CPS:<cidLowerLimit><cidUpperLimit><timerCU> <simplifiedCPS>Any of these fields can be set to "-" if you don't want to specify it in an SDP descriptor 🫶
<cidLowerLimit> and <cidUpperLimit> can be integers from 8 to 255 [11]. The only rule is that <cidUpperLimit> has to be greater than or equal to <cidLowerLimit>. For example, for POTS applications based on [52], you could use 16 and 223 ✨
<timerCU> is the "combined use" timerCU from ITU I.363.2. It's measured in microseconds, and it's written as the decimal integer equivalent of 32 bits ⏱️
<simplifiedCPS> can be "on" or "off". When it's "on", the AAL2 CPS simplification from [52] kicks in. Under this simplification, each ATM cell carries exactly one AAL2 packet. If needed, the octets at the end of the cell get padded with zeros 🧸 Since <timerCU> is always 0 in this context, it can be set to "-" 💖
5.6.2.10 The 'aal2CPSSDUrate' attribute 🔥
When it's present, 'aal2CPSSDUrate' puts an upper bound on the SDU bit rate for an AAL2 CID. This is super handy for limiting how much bandwidth a CID uses, especially if the CID is carrying frame mode data defined in [13] or using the SSSAR defined in [12] 🦋
The line looks like this:
a=aal2CPSSDUrate: <fSDUrate><bSDUrate>fSDUrate and bSDUrate are the maximum forward and backward SDU rates, in bits per second. They're decimal integers, with the range defined in Section 6 👑 If any of these parameters isn't specified, doesn't apply, or is implied, set it to "-" 🌸
5.6.2.11 The 'aal2sscs3661unassured' attribute 🌈
When it's present, 'aal2sscs3661unassured' tells you the options for the unassured transmission SSCS defined in ITU I.366.1 [12]. You can pick this SSCS with the aalApp attribute (defined below), or just by including the 'aal2sscs3661unassured' attribute itself 🧚
The line looks like this:
a=aal2sscs3661unassured: <ted> <rastimer> <fsssar> <bsssar>Any of these fields can be set to "-" if you don't want to specify it in an SDP descriptor 🫶
<ted> is the transmission error detection flag, as defined in I.366.1. It can be "on" or "off", and "on" means the capability is there 🔍
<rastimer> is the SSSAR reassembly timer, in microseconds. It's the decimal equivalent of 32 bits ⏱️
<fsssar> and <bsssar> are 24-bit integers, decimal or hex. Here's what they mean:
Field Meaning Values
<fsssar> Maximum SSSAR-SDU size 1- 65,568
forward direction
<bsssar> Maximum SSSAR-SDU size 1- 65,568
backward directionIf it's present, the SSTED (Service-Specific Transmission Error Detection) sublayer sits above the SSSAR (Service-Specific Segmentation and Reassembly) sublayer [12]. Since you can work out the max SSTED-SDU size from the max SSSAR-SDU size, you don't need to specify it separately 🧠
5.6.2.12 The 'aal2sscs3661assured' attribute 💎
When it's present, 'aal2sscs3661assured' tells you the options for the assured transmission SSCS defined in ITU I.366.1 [12], built on ITU Q.2110 [43] 🌟 You can pick this SSCS with the aalApp attribute (defined below), or just by including the 'aal2sscs3661assured' attribute itself 💅
The line looks like this:
a=aal2sscs3661assured: <rastimer> <fsssar> <bsssar> <fsscopsdu>
<bsscopsdu><fsscopuu> <bsscopuu>Any of these fields can be set to "-" if you don't want to specify it in an SDP descriptor 🫶
<rastimer> is the SSSAR reassembly timer, in microseconds. It's the decimal equivalent of 32 bits ⏱️
<fsssar> and <bsssar> are 24-bit integers, decimal or hex. <fsscopsdu>, <bsscopsdu>, <fsscopuu> and <bsscopuu> are 16-bit integers, decimal or hex too. Here's what they mean:
Field Meaning Values
<fsssar> Maximum SSSAR-SDU size 1- 65,568
forward direction
<bsssar> Maximum SSSAR-SDU size 1- 65,568
backward direction
<fsscopsdu> Maximum SSCOP-SDU size 1- 65,528
forward direction
<bsscopsdu> Maximum SSCOP-SDU size 1- 65,528
backward direction
<fsscopuu> Maximum SSCOP-UU field 1- 65,524
size, forward direction
<bsscopuu> Maximum SSCOP-UU field 1- 65,524
size, backward directionThe SSTED (Service-Specific Transmission Error Detection) sublayer sits above the SSSAR (Service-Specific Segmentation and Reassembly) sublayer [12]. Then the SSADT (Service-Specific Assured Data Transfer) sublayer sits above SSTED. Since you can derive the max SSTED-SDU and SSADT-SDU sizes from the max SSSAR-SDU size, they don't need to be specified separately 🧩
The SSCOP protocol from [43] is what the Assured Data Transfer service in [12] runs on. Within the ITU I.366.1 SSCS, you can use 'aal2sscs3661assured' to cap the max SSCOP SDU sizes and the UU (user-to-user) field sizes in either direction 💜 Just make sure all the parameters on this 'aal2sscs3661assured' line agree with each other, because they have to be consistent 🙏
5.6.2.13 The 'aal2sscs3662' attribute ✨
okay so the aal2sscs3662 attribute is basically the options menu for the SSCS from ITU I.366.2 [13] 💅 when it shows up, it tells you which options apply to that SSCS. and bestie, there are two ways to pick this SSCS: through the aalApp attribute (defined below) or just by having this attribute there 🎀
The format of this media attribute line is:
a=aal2sscs3662: <sap> <circuitMode> <frameMode> <faxDemod>
<cas> <dtmf> <mfall> <mfr1> <mfr2>
<PCMencoding> <fmaxFrame> <bmaxFrame>Every one of these fields can be set to a "-" if you don't want to specify it in an SDP descriptor 🦋 Also, the values have to match up with each other, and if they don't, that should get flagged as an error 😭
The <sap> field can be "AUDIO" or "MULTIRATE" 🌸 These match up with the audio and multirate Service Access Points (SAPs) from ITU I.366.2.
For the multirate SAP, the <faxDemod>, <cas>, <dtmf>, <mfall>, <mfr1>, <mfr2> and <PCMencoding> parameters don't apply, so they get set to "-" 🙈
The <circuitMode> flag says whether circuit mode data transport is enabled ("on") or disabled ("off") ✨ For the multirate SAP, it can't be "off" (it's giving no off-switch, main character energy 👑). For the audio SAP, it can be "on", "off" or "-". Quick note: the <sbc> attribute, defined elsewhere in this document, is what you'd use to say how many 64 kbps subchannels get bundled into a circuit mode data channel 🧚
The <frameMode> flag says whether frame mode data transport is enabled ("on") or disabled ("off") 🌈
The <faxDemod> flag says whether facsimile demodulation and remodulation are enabled ("on") or disabled ("off") 📠
The <cas> flag says whether Channel Associated Signaling (CAS) bits get carried in AAL2 type 3 packets, with "on" for enabled and "off" for disabled 💜
The <dtmf> flag says whether DTMF dialled digits get carried in AAL2 type 3 packets, "on" or "off" 🎶
The <mfall> flag says whether MF dialled digits get carried in AAL2 type 3 packets, "on" or "off" ✨ This one is the generic option: it turns MF digits on without naming a type (like R1 or R2) 🫶
The <mfr1> flag says whether MF dialled digits for signaling system R1 get carried in AAL2 type 3 packets, "on" or "off" 🔥
The <mfr2> flag does the same thing, but for signaling system R2, "on" or "off" 💖
The <PCMencoding> field says whether PCM encoding, if it's used, is A-law or Mu-law 🦋 This is how you qualify the 'generic PCM' codec mentioned in some of the AAL2 profiles. The string values are "PCMA" and "PCMU" 🌸
The <fmaxFrame> and <bmaxFrame> fields are 16-bit integers, and you can write them in decimal or hex 🍓 Here's what they mean:
Field Meaning Values
<fmaxFrame> Maximum length of a 1- 65,535
frame mode data unit,
forward direction
<bmaxFrame> Maximum length of a 1- 65,535
frame mode data unit,
backward direction5.6.2.14 The 'aal5sscop' attribute 🎀
okay so when the aal5sscop attribute is present, it tells you there's an SSCOP [43] protocol layer sitting over an AAL5 CPS layer [21], plus the parameters for that SSCOP layer 🦋 SSCOP over AAL5 can also be picked through the aalApp attribute, bestie. The format of the aal5sscop media attribute line is:
a=aal5sscop: <fsscopsdu> <bsscopsdu> <fsscopuu> <bsscopuu>Each of these fields can be set to a "-" if you don't want to specify it in an SDP descriptor ✨
The representation, meaning and values of the <fsscopsdu>, <bsscopsdu>, <fsscopuu> and <bsscopuu> fields are exactly the same as the ones for the 'aal2sscs3661assured' media attribute line (Section 5.6.2.12) 💅 And it's necessary for the parameters on the 'aal5sscop' line to be consistent with each other, so keep those in sync 🫶
5.6.3 Service attributes 💜
Here's a summary list of the SDP media attributes that describe the services using the ATM Adaptation Layer (AAL) 🧚 We'll go through each of them in the subsections after this 🌈
- The
atmmapattribute. In the AAL1 and AAL5 contexts, this is used to dynamically map payload types into codec strings 🎶 - The
silenceSuppattribute, used to indicate the use of voice activity detection for silence suppression, and to optionally parameterize the silence suppression function 🤫 - The
ecanattribute, used to indicate the use of echo cancellation, and to parameterize that function 🔊 - The
gcattribute, used to indicate the use of gain control, and to parameterize that function 🎚️ - The
profileDescattribute, which can be used to describe AAL2 profiles. Any AAL2 profile can be described this way, but it's especially handy for describing custom profiles at connection establishment time that the far end might not know about 💖 This attribute applies in the AAL2 context only. - The
vselattribute, which indicates a prioritized list of 3-tuples for voice service. Each 3-tuple has a codec, an optional packet length and an optional packetization period. It complements the 'm' line information and should be consistent with it 🎤 - The
dselattribute, which indicates a prioritized list of 3-tuples for voiceband data service. Each 3-tuple has a codec, an optional packet length and an optional packetization period. It complements the 'm' line information and should be consistent with it 💾 - The
fselattribute, which indicates a prioritized list of 3-tuples for facsimile service. Each 3-tuple has a codec, an optional packet length and an optional packetization period. It complements the 'm' line information and should be consistent with it 📠 - The
onewaySelattribute, which indicates a prioritized list of 3-tuples for one direction of an asymmetric connection. Each 3-tuple has a codec, an optional packet length and an optional packetization period. It complements the 'm' line information and should be consistent with it 🦋 - The
codecconfigattribute, which represents the contents of the single codec information element (IE) defined in ITU Q.765.5 [57] 🌸 - The
isup_usiattribute, which represents the bearer capability information element defined in Section 4.5.5 of ITU Q.931 [59], and reiterated as the user service information element (IE) in Section 3.57 of ITU Q.763 [60] 🍓 - The
uiLayer1_Protattribute, which represents the 'User Information Layer 1 protocol' field within the bearer capability information element defined in Section 4.5.5 of ITU Q.931 [59] 👑
5.6.3.1 The 'atmmap' attribute 🧚
The atmmap attribute is built on the basis of the rtpmap attribute from RFC 2327 💅
a=atmmap:<payloadType> <encodingName>The atmmap attribute is how you dynamically map encoding names into payload types ✨ That's necessary for encoding names that haven't been given a static payload type through IANA [31]. Payload types and encoding techniques already registered with IANA for RTP stay the same for AAL1 and AAL5 🫶
The static payload types cover 0-95, and every static assignment of payload types to codecs is listed in [31] 🌈 The dynamic range that atmmap covers is 96-127 🎀
Table 2 adds non-standard encoding names with "X-" prefixes, on top of re-listing the payload types and encoding names from [31] 💜 Quick reminder, though: [31], not Table 2, is the authoritative list of standard codec names and payload types in the ATM context 😭
Table 2: Encoding Names and Payload Typesokay bestie, the encoding lineup is HERE 💅🎀 This is the big table of encoding names and payload types, so you can see which codecs get a fixed payload type number and which ones have to be mapped dynamically 🦋✨
|---------------------|--------------|---------------------------|
| Encoding Technique | Encoding Name| Payload type |
|---------------------|--------------|---------------------------|
| PCM - Mu law | "PCMU" | 0 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| 32 kbps ADPCM | "G726-32" | 2 (Statically Mapped) |
|---------------------|--------------|---------------------------|
|Dual rate 5.3/6.3kbps| "G723" | 4 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| PCM- A law | "PCMA" | 8 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| 7 KHz audio coding | "G722" | 9 (Statically Mapped) |
| within 64 kbps | | |
|---------------------|--------------|---------------------------|
| LD-CELP | "G728" | 15 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| CS-ACELP | "G729" | 18 (Statically Mapped) |
|(normal/low-complexity) | |
|---------------------|--------------|---------------------------|
| Low-complexity | "X-G729a" | None, map dynamically |
| CS-ACELP | | |
|---------------------|--------------|---------------------------|
|Normal | "X-G729b" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
+---------------------+--------------+---------------------------+
|Low-complexity | "X-G729ab" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
|---------------------|--------------|---------------------------|
| 16 kbps ADPCM | "X-G726-16" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 24 kbps ADPCM | "X-G726-24" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 40 kbps ADPCM | "X-G726-40" | None, map dynamically |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231-H" | None, map dynamically |
| kbps - high rate | | |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231-L" | None, map dynamically |
| kbps - low rate | | |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231a-H" | None, map dynamically |
| kbps - high rate w/ | | |
| ITU-defined silence | | |
| suppression | | |
|----------------------------------------------------------------|
+---------------------+--------------+---------------------------+
| Dual rate 5.3/6.3 |"X-G7231a-L" | None, map dynamically |
| kbps - high rate w/ | | |
| ITU-defined silence | | |
| suppression | | |
|---------------------|--------------|---------------------------|
| 16 kbps EADPCM | "X-G727-16" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 24 kbps EADPCM | "X-G727-24" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 32 kbps EADPCM | "X-G727-32" | None, map dynamically |
|---------------------|--------------|---------------------------|
|n x 64 kbps Clear | "X-CCD" | None, map dynamically |
|Channel without CAS | | |
|per af-vtoa-78 [7] | | |
|---------------------|--------------|---------------------------|
|n x 64 kbps Clear | "X-CCD-CAS" | None, map dynamically |
|Channel with CAS | | |
|per af-vtoa-78 [7] | | |
|---------------------|--------------|---------------------------|
|GSM Full Rate | "GSM" | 3 (Statically Mapped) |
|---------------------|--------------|---------------------------|
|GSM Half Rate | "GSM-HR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Full Rate "GSM-EFR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Half Rate "GSM-EHR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Group 3 fax demod. | "X-FXDMOD-3" | None, map dynamically |
|---------------------|--------------|---------------------------|
| Federal Standard | "1016" | 1 (Statically Mapped) |
| FED-STD 1016 CELP | | |
|---------------------|--------------|---------------------------|
| DVI4, 8 KHz [3] | "DVI4" | 5 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| DVI4, 16 KHz [3] | "DVI4" | 6 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| LPC [3], Linear | "LPC" | 7 (Statically Mapped) |
| Predictive Coding | | |
|---------------------|--------------|---------------------------|
| L16 [3], Sixteen | "L16" | 10 (Statically Mapped) |
| Bit Linear PCM, | | |
| Double channel | | |
|---------------------|--------------|---------------------------|
| L16 [3], Sixteen | "L16" | 11 (Statically Mapped) |
| Bit Linear PCM, | | |
| Single channel | | |
|---------------------|--------------|---------------------------|
| QCELP [3] | "QCELP" | 12 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG1/MPEG2 audio | "MPA" | 14 (Statically Mapped) |
|---------------------|--------------|---------------------------|
+---------------------+--------------+---------------------------+
| DVI4, 11.025 KHz[3] | "DVI4" | 16 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| DVI4, 22.05 KHz [3] | "DVI4" | 17 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG1/MPEG2 video | "MPV" | 32 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG 2 audio/video | "MP2T" | 33 (Statically Mapped) |
| transport stream | | |
|---------------------|--------------|---------------------------|
| ITU H.261 video | "H261" | 31 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| ITU H.263 video | "H263" | 33 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| ITU H.263 video |"H263-1998" | None, map dynamically |
| 1998 version | | |
|---------------------|--------------|---------------------------|
|MPEG 1 system stream | "MP1S" | None, map dynamically |
|---------------------|--------------|---------------------------|
|MPEG 2 program stream| "MP2P" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Redundancy | "RED" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Variable rate DVI4 | "VDVI" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Cell-B | "CelB" | 25 |
|---------------------|--------------|---------------------------|
|JPEG | "JPEG" | 26 |
|---------------------|--------------|---------------------------|
|nv | "nv" | 28 |
|---------------------|--------------|---------------------------|
|L8, Eight Bit Linear | "L8" | None, map dynamically |
|PCM | | |
|---------------------|--------------|---------------------------|
| ITU-R Recommendation| "BT656" | None, map dynamically |
| BT.656-3 for | | |
| digital video | | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "FR-AMR" | None, map dynamically |
|-Full Rate (3GPP)[58]| | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "HR-AMR" | None, map dynamically |
|-Half Rate (3GPP)[58]| | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "UMTS-AMR" | None, map dynamically |
|- UMTS(3GPP) [58] | | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "AMR" | None, map dynamically |
|- Generic [58] | | |
|---------------------|--------------|---------------------------|5.6.3.2 The 'silenceSupp' attribute 🤫
okay so the 'silenceSupp' attribute is how you tell everyone whether silence suppression is on 🎀 It only shows up when you want it to. The line looks like this:
a=silenceSupp: <silenceSuppEnable> <silenceTimer> <suppPref> <sidUse>
<fxnslevel>If any parameter on the silenceSupp line is not specified, is inapplicable, or is implied, it gets set to "-" 💅
<silenceSuppEnable> is either "on" or "off". "on" means silence suppression is enabled ✨
<silenceTimer> is a 16-bit field that you can write in decimal or hex 🔢 Each tick of this timer is one millisecond ⏱️ The maximum value is somewhere between 1 and 3 minutes. It's the time lag before silence suppression kicks in. Theoretically it could be as low as 1 ms, but most DSP algorithms need longer than that to detect silence 🙈 If you set <silenceTimer> to a huge value (like 1 minute), that's the same as turning silence suppression off during a call. BUT idle channel suppression between calls is still a thing in non-switched, trunking applications, as long as <silenceSuppEnable> is "on" and the timer is set to a large value 😭
<suppPref> is the preferred silence suppression method, either one that's already picked or one that's preferred. The string values are "standard" and "custom" 🎀 If it's "standard", a standard method (like an ITU-defined one) is preferred over custom methods, if such a standard exists. Otherwise, a custom method is allowed. If <suppPref> is "custom", then a custom method is preferred over the standard one, as long as one is available 👑
<sidUse> tells you whether SIDs (Silence Insertion Descriptors) are used, and whether they use fixed comfort noise or sampled background noise 🦋 The string values are "No SID", "Fixed Noise", and "Sampled Noise".
If <sidUse> is "Fixed Noise", then <fxnslevel> gives the level. It's an integer from 0 to 127, and it breaks down like this 📊
+-----------------------+---------------------+
| <fxnslevel> value | Meaning |
+-----------------------+---------------------+
| 0-29 | Reserved |
| 30 | -30 dBm0 |
| 31 | -31 dBm0 |
| . . . | . . . |
| 77 | -77 dBm0 |
| 78 | -78 dBm0 |
| 79-126 | reserved |
| 127 | Idle Code (no noise)|
+-----------------------+---------------------+You can also write <fxnslevel> in hex with a "0x" prefix, if you're feeling extra 🌸
5.6.3.3 The 'ecan' attribute 🌊
When it's present, the 'ecan' attribute is how you say whether echo cancellation is on or off. You can have several 'ecan' lines in one SDP description, which is very iconic of them 💖
The format is:
a=ecan:<directionFlag><ecanEnable><ecanType><directionFlag> can be "f", "b", or "fb". "f" is the forward direction, "b" is the backward direction, and "fb" covers both 🔁 The conventions for forward and backward are in section 2.3.
<directionFlag> is always specified 💅 Everything else can be set to "-" to show it's not specified, inapplicable, or implied. But there has to be some specified parameter for the line to be useful in an SDP description 🙃
If there's no 'ecan' line, then the applicability and nature of echo cancellation for a connection direction has to be figured out some other way. Some examples are MIB provisioning, or the local connection options structure in MGCP, etc. 🧚
<ecanEnable> is "on" (echo cancellation is enabled) or "off" (echo cancellation is disabled) ✨
<ecanType> can be the string values "G165" and "G168" 🎀
When SDP is used with media gateway control protocols like MGCP and Megaco [26], there are already ways outside SDP to specify a connection's echo cancellation properties. This attribute line is still included for completeness 🫶 So SDP can describe echo cancellation in places where those other ways aren't available.
5.6.3.4 The 'gc' attributes 🎚️
When it's present, the 'gc' attribute is how you say whether gain control is used. Like 'ecan', you can have several 'gc' lines in one SDP description 🍓
The format is:
a=gc:<directionFlag><gcEnable><gcLvl><directionFlag> works exactly like it does for 'ecan': "f", "b", or "fb", with the conventions from section 2.3 📍 It's always specified, and the other parameters can be "-" if they're not specified, inapplicable, or implied. Again, there has to be some specified parameter for the line to be useful 🙈
If there's no 'gc' line, then the applicability and nature of gain control for a connection direction has to come from somewhere else, like MIB provisioning or the local connection options structure in MGCP etc. 🌈
<gcEnable> is "on" (gain control is enabled) or "off" (gain control is disabled) 💜
<gcLvl> is the decimal or hex form of a 16-bit binary field. A value of 0xFFFF means automatic gain control 🤖 Otherwise, the number is how many decibels of inserted loss there are. The upper bound is 65,535 dB (0xFFFE) of inserted loss, which is a super big number that got carried over from Megaco 😭 In practical applications the inserted loss is way lower.
When SDP is used with protocols like MGCP and Megaco [26], there are already ways outside SDP to specify a connection's gain control properties. This line is still included for completeness, so SDP can describe gain control where those other ways aren't available 🫶
5.6.3.5 The 'profileDesc' attribute 🧁
There's one 'profileDesc' media attribute line for each AAL2 profile you want to describe ✨ It's structured like this:
a=profileDesc: <aal2transport> <profile> <uuiCodeRange#1>
<encodingName#1> <packetLength#1> <packetTime#1>
<uuiCodeRange#2> <encodingName#2> <packetLength#2>
<packetTime#2>... <uuiCodeRange#N> <encodingName#N>
<packetLength#N> <packetTime#N><aal2transport> can be any of the <transport> values in Table 1 that relate to AAL2. Those are:
AAL2/ATMFAAL2/ITUAAL2/customAAL2/<corporateName>AAL2/IEEE:<oui>
The <profile> parameter is exactly the same as its definition for the 'm' line (Section 5.5.4) 💅
The profile elements (the rows in the profile tables of ITU I.366.2 or AF-VTOA-0113) are written as four-tuples after <profile> in the 'profileDesc' line 🦋 If any member of one of those four-tuples is not specified or is implied, it's set to "-".
<uuiCodeRange> is written as D1-D2, where D1 and D2 are decimal integers from 0 through 15 🔢
<encodingName> can be one of the values in column 2 of Table 2. On top of that, it can also be "PCMG", "SIDG", or "SID729", which mean generic PCM, generic SID, and G.729 SID 🎶
<packetLength> is a decimal integer for the AAL2 packet length in octets 📏
<packetTime> is a decimal integer for the AAL2 packetization interval in microseconds ⏱️
Here's an example. This 'profileDesc' line defines the AAL2/custom 100 profile, which is reproduced in Table 3 below. For what the profile's parameters mean (like M and the sequence number interval), check out ITU I.366.2 [13] 📚
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 5000 0-7 SIDG 1 5000 8-15
G726-32 40 10000 8-15 SIDG 1 5000If <packetTime> is omitted or implied, the same profile can be written like this:
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 - 0-7 SIDG 1 - 8-15
G726-32 40 - 8-15 SIDG 1 -If a gateway already has a provisioned or hard-coded definition of a profile, then any definition sent via the 'profileDesc' line overrides it 👑 The exception is standard profiles, like ITU-defined and ATMF-defined ones. In general these should not be defined through a 'profileDesc' media attribute line. If they are, the definition needs to match the standard definition, or else the SDP session descriptor should be rejected with an appropriate error code 💀
Table 3: Example of a custom AAL2 profile
|---------------------------------------------------------------|
| UUI | Packet |Encoding | | |Packet|Seq.No. |
| Code | Length |per ITU |Description of | M |Time |Interval|
|point |(octets)|I.366.2 | Algorithm | |(ms) |(ms) |
|Range | | 2/99 | | | | |
| | | version | | | | |
|---------------------------------------------------------------|
| 0-7 | 40 | Figure | PCM, G.711-64,| 1 | 5 | 5 |
| | | B-1 | generic | | | |
|------|--------|---------|---------------|-----|------|--------|
| 0-7 | 1 | Figure | Generic SID | 1 | 5 | 5 |
| | | I-1 | | | | |
|------|--------|---------|---------------|-----|------|--------|
| 8-15 | 40 | Figure | ADPCM, | 2 | 10 | 5 |
| | | E-2 | G.726-32 | | | |
|------|--------|---------|---------------|-----|------|--------|
| 8-15 | 1 | Figure | Generic SID | 1 | 5 | 5 |
| | | I-1 | | | | |
|------|--------|---------|---------------|-----|------|--------|5.6.3.6 The 'vsel' attribute 🎀
okay so the vsel attribute gives you a prioritized list of one or more 3-tuples for voice service 💖 each 3-tuple tells you a codec, an optional packet length, and an optional packetization period. it complements the m line info and should be consistent with it 💅
the vsel attribute refers to all directions of a connection ✨ for a bidirectional connection, that means the forward and backward directions. for a unidirectional connection, it can be either the backward or forward direction 🦋
the vsel attribute is not meant to be used with bidirectional connections that have asymmetric codec configurations described in a single SDP descriptor 🙈 for those, use the onewaySel attribute (section 5.6.3.9) instead. see section 5.6.3.9 for the requirement to not use the vsel and onewaySel attributes in the same SDP descriptor, bestie 💜
the vsel line is structured like this 🌸
a=vsel:<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>the <encodingName> parameter can take one of the values in column 2 of Table 2 🍓 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. both <packetLength> and <packetTime> can be set to - when not needed 🫶 and the entire vsel media attribute line can be omitted when it's not needed too, no cap.
for example 🧚
a=vsel:G729 10 10000 G726-32 40 10000this indicates first preference of G.729 or G.729a (both are interoperable) as the voice encoding scheme 👑 a packet length of 10 octets and a packetization interval of 10 ms go with this codec. G726-32 is the second preference in this line, with a packet length of 40 octets and a packetization interval of 10 ms 🔥
if the packet length and packetization interval are meant to be left out, the media attribute line becomes
a=vsel:G729 - - G726-32 - -and this one
a=vsel:G726-32 40 10000indicates preference for, or selection of, 32 kbps ADPCM with a packet length of 40 octets and a packetization interval of 10 ms 🦋
this media attribute line works in ATM as well as non-ATM contexts ✨ in the ATM context, it can be applied to the AAL1, AAL2 and AAL5 adaptations. the <packetLength> and <packetTime> aren't meaningful in the AAL1 case, so they get set to - 🌈 in the AAL2 case, this line decides the use of some or all of the rows in a given profile table. if there are multiple 3-tuples, they can show a hierarchical assignment of some rows in that profile to voice service (like, row A preferred to row B, etc.) 💅 if multiple profiles are on the m line, the profile qualified by this attribute is the first profile. and if a single profile has been selected for a connection and is indicated in the m line, the vsel attribute qualifies the use, for voice service, of the codecs inside that profile 😭
with most of the encoding names in Figure 2, the packet length and packetization period can be derived from each other ✨ so one of them can be set to - without losing any information. there are some exceptions, like the IANA-registered encoding names G723, DVI4 and L16, where that isn't true 🙈 which is why we need to keep both the packet length and packetization period in the definition of the vsel line. iykyk 💜
5.6.3.7 The 'dsel' attribute 🦋
the dsel attribute gives you a prioritized list of one or more 3-tuples for voiceband data service 🌸 the <fxIncl> flag tells you whether this definition of voiceband data includes fax (on value) or doesn't (off value) 💖 if <fxIncl> is on, then the dsel line must be consistent with any fsel line in the session description. in that case, an error event is generated when things are inconsistent 😭 each 3-tuple indicates a codec, an optional packet length and an optional packetization period. this complements the m line info and should be consistent with it ✨
the dsel attribute refers to all directions of a connection too 👑 for a bidirectional connection, that's the forward and backward directions. for a unidirectional connection, it can be either the backward or forward direction 🌈
the dsel attribute is not meant to be used with bidirectional connections that have asymmetric codec configurations described in a single SDP descriptor 🙈 for those, the onewaySel attribute (section 5.6.3.9) should be used. see section 5.6.3.9 for the requirement to not use the dsel and onewaySel attributes in the same SDP descriptor 💜
the dsel line is structured like this 🍓
a=dsel:<fxIncl> <encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>the <encodingName> parameter can take one of the values in column 2 of Table 2 🫶 the <packetLength> and <packetTime> parameters work the same way as they were defined above for the vsel media attribute line. both can be set to - when not needed. the <fxIncl> flag is presumed to be off if it's set to - ✨ and the entire dsel media attribute line can be omitted when it isn't needed.
for example 🧚
a=dsel:- G726-32 20 5000 PCMU 40 5000this indicates that the line doesn't address facsimile, and that the first preference for voiceband data codecs is 32 kbps ADPCM, while the second preference is PCMU 🔥 the packet length and packetization interval for G726-32 are 20 octets and 5 ms. for PCMU, they're 40 octets and 5 ms 🌈
this media attribute line works in ATM as well as non-ATM contexts 🦋 in the ATM context, it can be applied to the AAL1, AAL2 and AAL5 adaptations. the <packetLength> and <packetTime> aren't meaningful in the AAL1 case, so they get set to - 💅 in the AAL2 case, this line decides the use of some or all of the rows in a given profile table. multiple 3-tuples can show a hierarchical assignment of some rows in that profile to voiceband data service (like row A preferred to row B, etc.) 💖 if there are multiple profiles on the m line, the profile qualified by this attribute is the first profile. and if a single profile has been selected for a connection and is indicated in the m line, the dsel attribute qualifies the use, for voiceband data service, of the codecs inside that profile 👑
with most of the encoding names in Figure 2, the packet length and packetization period can be derived from each other 🌸 so one of them can be set to - without losing any information. the exceptions are IANA-registered encoding names like G723, DVI4 and L16, where that's not true 😭 so we need both the packet length and packetization period in the definition of the dsel line. no cap 💜
5.6.3.8 The 'fsel' attribute 🌈
the fsel attribute gives you a prioritized list of one or more 3-tuples for facsimile service ✨ if an fsel line is present, any dsel line with <fxIncl> set to on in the session description must be consistent with it. in that case, an error event is generated when there's an inconsistency 🙈 each 3-tuple indicates a codec, an optional packet length and an optional packetization period. this complements the m line info and should be consistent with it 💅
the fsel attribute refers to all directions of a connection 🦋 for a bidirectional connection, that means the forward and backward directions. for a unidirectional connection, it can be either the backward or forward direction 🌸
the fsel attribute is not meant to be used with bidirectional connections that have asymmetric codec configurations described in a single SDP descriptor 🙈 for those, the onewaySel attribute (section 5.6.3.9) should be used. see section 5.6.3.9 for the requirement to not use the fsel and onewaySel attributes in the same SDP descriptor 💜
the fsel line is structured like this 🍓
a=fsel:<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>the <encodingName> parameter can take one of the values in column 2 of Table 2 🫶 the <packetLength> and <packetTime> parameters work the same way as they were defined above for the vsel media attribute line. both can be set to - when not needed, and the entire fsel media attribute line can be omitted when it isn't needed either ✨
for example 🧚
a=fsel:FXDMOD-3 - -this indicates demodulation and remodulation of ITU-T group 3 fax at the gateway 👑
a=fsel:PCMU 40 5000 G726-32 20 5000this indicates a first and second preference of Mu-law PCM and 32 kbps ADPCM as the facsimile encoding scheme 🔥 the packet length and packetization interval for G726-32 are 20 octets and 5 ms. for PCMU, they're 40 octets and 5 ms 🌈
this media attribute line works in ATM as well as non-ATM contexts 🦋 in the ATM context, it can be applied to the AAL1, AAL2 and AAL5 adaptations. the <packetLength> and <packetTime> aren't meaningful in the AAL1 case, so they get set to - 💅 in the AAL2 case, this line decides the use of some or all of the rows in a given profile table. multiple 3-tuples can show a hierarchical assignment of some rows in that profile to facsimile service (like row A preferred to row B, etc.) 💖 if there are multiple profiles on the m line, the profile qualified by this attribute is the first profile. and if a single profile has been selected for a connection and is indicated in the m line, the fsel attribute qualifies the use, for facsimile service, of the codecs inside that profile 👑
with most of the encoding names in Figure 2, the packet length and packetization period can be derived from each other 🌸 so one of them can be set to - without losing any information. there are exceptions, like the IANA-registered encoding names G723, DVI4 and L16, where that's not true 😭 which means we need both the packet length and packetization period in the definition of the fsel line 💜
5.6.3.9 The 'onewaySel' attribute
okay bestie, this one is for connections with asymmetric codec configurations 👀 so the forward and backward legs don't have to match, and that is so real 💅 You can have several 'onewaySel' lines in one SDP description ✨ The shape is:
a=onewaySel:<serviceType> <directionFlag>
<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>The <serviceType> can be one of these string values: "v", "d", "f", "df" and "all" 🎀 They mean voice, voiceband data (fax not included), fax, voiceband data (fax included), and all services, in that order.
The <directionFlag> can be "f", "b" or "fb" 🦋 "f" is the forward direction and "b" is the backward direction. "fb" means both directions, but it SHALL NOT be used with the 'onewaySel' line. The conventions for forward and backward are per section 2.3.
After <directionFlag> comes a prioritized list of one or more 3-tuples 💜 Each 3-tuple is a codec, an optional packet length, and an optional packetization period. This complements the 'm' line info and SHOULD be consistent with it.
Inside each 3-tuple, the <encodingName> can be any of the values in column 2 of Table 2 🌸 The <packetLength> is a decimal integer of the packet length in octets. The <packetTime> is a decimal integer of the packetization interval in microseconds.
⚠️ The 'onewaySel' attribute MUST NOT be used in SDP descriptors that have one or more of these attributes: 'vsel', 'dsel', 'fsel'. If it shows up anyway, the command containing the SDP description MAY be rejected 😭 An alternate response to an ill-formed SDP descriptor might be selectively ignoring some attributes, which MUST be coordinated through an application-wide policy.
The <serviceType>, <directionFlag> and <encodingName> parameters may not be set to "-" 🙅♀️ But <packetLength> and <packetTime> can be set to "-" when they aren't needed ✨
Here's an example:
a=onewaySel:v f G729 10 10000
a=onewaySel:v b G726-32 40 10000This says that for voice service, the forward codec is G.729 or G.729a (both are interoperable), and the backward codec is G726-32. The G.729/G.729a codec goes with a packet length of 10 octets and a packetization interval of 10 ms. The G726-32 codec goes with a packet length of 40 octets and a packetization interval of 10 ms. Iconic 🧚
Here's another one:
a=onewaySel:d f G726-32 20 5000
a=onewaySel:d b PCMU 40 5000This says that for voiceband service (fax not included), the forward codec is G726-32), and the backward codec is PCMU. The G726-32 codec goes with a packet length of 20 octets and a packetization interval of 5 ms. The PCMU codec goes with a packet length of 40 octets and a packetization interval of 5 ms. Main character energy 💖
This media attribute line works in ATM and non-ATM contexts 🌈 In ATM, it can be applied to the AAL1, AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> aren't meaningful in the AAL1 case and SHOULD be set to "-" 🍓 In the AAL2 case, these lines decide how some or all of the rows in a given profile table get used. If there are multiple 3-tuples, they can give a hierarchical assignment of some rows in that profile to voice service (e.g., row A preferred to row B etc.) 👑 If multiple profiles are on the 'm' line, the profile qualified by this attribute is the first profile.
Most of the encoding names in Figure 2 let you derive the packet length and packetization period from each other, so one of them can be set to "-" without losing any info 🫶 The exceptions are the IANA-registered encoding names G723, DVI4 and L16, where that's not true. So we need to keep both the packet length and the packetization period in the 'onewaySel' line, no shortcuts 💅
5.6.3.10 The 'codecconfig' attribute
When it's present, the 'codecconfig' attribute holds the contents of the single codec information element (IE) defined in [57] ✨ Those contents are a single-octet Organizational Identifier (OID) field, then a single-octet Codec Type field, then zero or more octets of a codec configuration bit-map. What the bit-map means is specific to the organization [57, 58] 🦋 The attribute looks like this:
a=codecconfig:<q7655scc>The <q7655scc> (Q.765.5 single codec IE contents) is a string of hex digits 🔢 The number of hex digits is even (range 4 -32). The "0x" prefix SHALL be omitted, since this value is always hexadecimal. As with other hex values [Section 2.2], digits on the left are more significant than digits on the right. Leading zeros SHALL NOT be omitted 🙈
Here's an example:
a=codecconfig:01080CThe first octet is an Organizational Identifier of 0x01, which is the ITU-T 🌸 Going by ITU Q.765.5 [57], the second octet (0x08) is a codec type of G.726 (ADPCM). The last octet, 0x0C, says that the 16 kbps and 24 kbps rates are NOT supported, while the 32 kbps and 40 kbps rates ARE supported 💜
5.6.3.11 The 'isup_usi' attribute
When it's present, the 'isup_usi' attribute holds the bearer capability information element from Section 4.5.5 of ITU Q.931 [59] (without the information element identifier and length) ✨ That same information element shows up again as the user service information element (IE) in Section 3.57 of ITU Q.763 [60]. The attribute looks like this:
a=isup_usi:<isupUsi>The <isupUsi> parameter is a string of hex digits 🔢 The number of hex digits is even (allowed range 4 -24). The "0x" prefix SHALL be omitted, since this value is always hexadecimal. As with other hex values [Section 2.2], digits on the left are more significant than digits on the right. Leading zeros SHALL NOT be omitted 🙈
5.6.3.12 The 'uiLayer1_Prot' attribute
When it's present, the 'uiLayer1_Prot' attribute holds the 'User Information Layer 1 protocol' field inside the bearer capability information element from Section 4.5.5 of [59], which is repeated as the user service information element (IE) in Section 3.57 of [60] 🎀 That field is made of the five least significant bits of Octet 5 of this information element.
In SDP, it looks like this:
a='uiLayer1_Prot':<uiLayer1Prot>The <uiLayer1Prot> parameter is a string of two hex digits 🌷 The "0x" prefix SHALL be omitted, since this value is always hexadecimal. As with other hex values [Section 2.2], digits on the left are more significant than digits on the right. These hex digits come from an octet with three leading '0' bits, and its last five bits equal the 'User Information Layer 1 protocol' field from above. As specified in [59] and [26], bit 5 of this field is the most significant bit 🧠 The resulting values of the <uiLayer1Prot> parameter are:
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 stuffing5.6.4 Miscellaneous media attributes
The 'chain' media attribute line is used to chain consecutive SDP descriptions 🔗 It doesn't fit in the ATM, AAL or service attribute buckets, so it gets its own subsection, which is next 💖
5.6.4.1 The 'chain' attribute
An SDP descriptor starts with a 'v' line 🦋 In some apps, consecutive SDP descriptions are alternative descriptions of the same session. In others, they describe different layers of the same connection (e.g., IP, ATM, frame relay). That's useful when connectivity at those layers gets set up at the same time (e.g., an IP-based session over an ATM SVC) 🌈 To tell apart alternation from concatenation of SDP descriptions, a 'chain' attribute can be used for concatenation.
When it's present, the 'chain' attribute binds an SDP description to the next or previous one 🫶 That next or previous description is separated from the current one by a 'v' line. It doesn't need to have a 'chain' media attribute line too.
Chaining means you don't have to set up a single SDP description for a session that gets created at multiple layers at once, so each layer's SDP stays simple and clean ✨ Chaining isn't needed in the Megaco context, since you can just create separate terminations for the different layers of a connection 👑
The 'chain' media attribute line looks like this:
a=chain:<chainPointer>The <chainPointer> can be one of these string values: "NEXT", "PREVIOUS" and "NULL" 💅 The value "NULL" is NOT the same as leaving out the chain attribute, because it flat-out rules out chaining. If the 'chain' attribute is absent from an SDP description, chaining can still happen if the previous or next description has a chain media attribute line 🧚
5.6.5 Use of the second media-level part in H.323 Annex C applications
Section 4 says that H.323 annex C applications have a second media level part for the ATM session description 🎀 This one carries info about the RTCP stream. The RTP stream is encapsulated in AAL5 with no IP layer in between, but the RTCP stream goes to an IP address and RTCP port 🦋 This media-level part looks like this:
m= control <rtcpPortNum> H323c -
c= IN IP4 <rtcpIPaddr>Consistency with RFC 2327 is kept in where these lines go and how they're formatted ✨ The <fmt list> in the 'm' line is set to "-". The 'c' line in the second media-level part is only about RTCP 💜
The <rtcpPortNum> and <rtcpIPaddr> subparameters are the port number and IP address the media gateway is ready to receive RTCP packets on 🌸
Any of the subparameters on these lines can be set to "-" if they're known some other way 🙌
The range and format of <rtcpPortNum> and <rtcpIPaddr> follow [1] 💖 The <rtcpPortNum> is a decimal number between 1024 and 65535, and it's an odd number. If an even number in that range is specified, the next odd number is used 🍓 The <rtcpIPaddr> is written as a usual dotted decimal IP address, from 0.0.0.0 to 255.255.255.255 🌈
5.6.6. Use of the eecid media attribute in call establishment procedures
okay so this part is informative 💅 and it's basically the "how do we actually use this?" section for the eecid attribute from Section 5.6.1.1 🎀 These example procedures assume a bearer-signaling mechanism for connection set-up that's totally independent of service-level call control ✨ They also don't care which media gateway control protocol you're using (MGCP, Megaco, SIP etc.), which protocol the media gateway controllers talk to each other over (ITU Q.1901, SIP etc.), or which protocol sets up the bearer connection (Q.2931, UNI, PNNI, AINI, IISP, Q.2630.1 etc.). Very flexible, very iconic 🦋
Inter-MGC
+---------+ Protocol +---------+
| MGC |------------------| MGC |
+---------+ +---------+
| |
|Media Gateway |Media Gateway
|Control Protocol |Control Protocol
| |
+------------+ (ATM Network) +------------+
|Originating |------------------|Terminating |
|Media | Bearer Setup |Media |
|Gateway | Protocol |Gateway |
+------------+ +------------+In that diagram, the originating media gateway is the one that originates the service-level call, and the terminating media gateway is the one that terminates it 🌸 In the forward bearer connection set-up model, the originating media gateway starts the bearer connection set-up. In the backward bearer connection set-up model, it's the terminating gateway that starts it 💜
Example use of the Backward Bearer Connection Set-up Model:
Step 1: The originating media gateway controller (OMGC) kicks off the service-level call establishment by sending the right control message to the originating media gateway (OMG) 🚀
Step 2: The OMG hands its NSAP address and an eecid value over to the OMGC, using this SDP description:
v=0
o=- 2873397496 0 ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
t=0 0
m=audio $ AAL2/ITU 8
a=eecid:B3D58E32Step 3: The OMGC signals the terminating media gateway controller (TMGC) through whatever appropriate mechanism you like (ISUP with Q.1901 extensions, SIP etc.) 📡 It passes the TMGC the NSAP address and the eecid that the OMG provided.
Step 4: The TMGC sends the appropriate control message to the terminating media gateway (TMG) 💖 This includes the session descriptor the OMG sent over, and that descriptor has the NSAP address of the OMG plus the EECID the OMG assigned. On top of that, the TMGC tells the TMG to set up an SVC to the OMG, and it asks the TMG to let the TMGC know when the SVC set-up is complete. Depending on which control protocol you're using, this can be done in a bunch of different ways 🧚 In the Megaco context, the request to set up an SVC (not the notification request for the SVC set-up event) can be made through this local descriptor:
v=0
o=- 2873397497 0 ATM - -
s=-
c=ATM - -
t=0 0
m=audio $ - -
a=bearerType:SVC onThe bearerType attribute says an SVC is to be used, and that the <localInitiation> flag is on, meaning the SVC is set up by the TMG 🎀
Step 5: The TMG acknowledges the control message from the TMGC and sends back this SDP descriptor with the acknowledgement:
v=0
o=- 2873397498 0 ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/ITU 8The NSAP address info in this descriptor isn't needed, so you can leave it out by setting it to "- -" 🙈
Step 6: The TMG sends an SVC set-up message to the OMG. Inside the GIT information element, it includes the eecid (B3D58E32) it got from the OMG 🔥
Step 7: The OMG uses that eecid to match the SVC set-up request up with the service-level control message it received earlier from the OMGC 🧩
Step 8: The OMG sends an SVC connect message back to the TMG. Once the TMG gets that, it sends an event notification to the TMGC saying the SVC set-up worked 🥳
Note that, for this example, the"v=","o=","s="and"t="lines can be omitted in the Megaco context. 💅
Example use of the Forward Bearer Connection Set-up Model:
Step 1: The OMGC starts the service-level call establishment by sending the right control message to the OMG 🚀
Step 2: The OMG gives the OMGC its NSAP address, using this SDP description:
v=0
o=- 2873397496 0 ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
t=0 0
m=audio $ AAL2/ITU 8The NSAP address info in this descriptor isn't needed, so it can be omitted by setting it to "- -" ✨
Step 3: The OMGC signals the TMGC through the appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.) 📡 Even though it isn't necessary, it can give the TMGC the NSAP address the OMG provided.
Step 4: The TMGC sends the right control message to the TMG 💖 It includes the session descriptor from the OMG, and that descriptor has the OMG's NSAP address.
Step 5: The TMG acknowledges the control message from the TMGC. Along with that acknowledgement, it sends an SDP descriptor with a locally assigned eecid:
v=0
o=- 2873397714 0 ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/ITU 8
a=eecid:B3D58E32Step 6: The TMGC signals the OMGC through the appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.) 🫶 It gives the OMGC the NSAP address and the eecid the TMG provided.
Step 7: The OMGC sends the right control message to the OMG 🌈 It includes the session descriptor from the TMG, which has the TMG's NSAP address and the EECID the TMG assigned. The OMGC also tells the OMG to set up an SVC to the TMG, and asks the OMG to notify it when the SVC set-up is complete. Depending on the control protocol, this can be done in a variety of ways. In the Megaco context, the SVC set-up request (not the notification request for the SVC set-up event) can be made through this local descriptor:
v=0
o=- 2873397874 0 ATM - -
s=-
c=ATM - -
t=0 0
m=audio $ - -
a=bearerType:SVC onThe bearerType attribute says an SVC is to be used, and that the <localInitiation> flag is on, meaning the SVC is set up by the TMG 🎀
Step 8: The OMG acknowledges the control message from the OMGC 👑
Step 9: The OMG sends an SVC set-up message to the TMG. Inside the GIT information element, it includes the eecid (B3D58E32) it got from the TMG 🔥
Step 10: The TMG uses that eecid to match the SVC set-up request up with the service-level control message it got earlier from the TMGC 🧩
Step 11: The TMG sends an SVC connect message back to the OMG. Once the OMG gets that, it sends an event notification to the OMGC saying the SVC set-up is successful 🥳
Note that, for this example, the"v=","o=","s="and"t="lines can be omitted in the Megaco context. 💅
6. List of Parameters with Representations ✨
okay so this section is basically your cheat sheet 🍓 It lists the parameters used in this document and the formats you use to represent them in SDP descriptions. Generally speaking, a "-" value can be used for any field that's not specified, isn't applicable, or is implied 💜
PARAMETER MEANING REPRESENTATION
<username> User name Constant "-"
<sessionID> Session ID Up to 32 decimal or
hex digits
<version> Version of "0" or 10 decimal digits
SDP descriptor
<networkType> Network type Constant "ATM" for ATM transport
<addressType> Address type String values:
"NSAP", "E164", "GWID",
"ALIAS"
<address> Address "NSAP": 40 hex digits, dotted
"E164": up to 15 decimal digits
"GWID": up to 32 characters
"ALIAS": up to 32 characters
<sessionName> Session name Constant "-"
<startTime> Session start "0" or 10 decimal digits
time
<stopTime> Session stop Constant "0"
time
<vcci> Virtual Circuit Decimal or hex equivalent
Connection of 16 bits
Identifier
<ex_vcci> Explicit "VCCI-" prefixed to <vcci>
representation
of <vcci>
<bcg> Bearer Connection Decimal or hex equivalent
Group of 8 bits
<ex_bcg> Explicit "BCG-" prefixed to <bcg>
representation
of <bcg>
<portId> Port ID Hex number of up to 32 digits
<ex_portId> Explicit "PORT-" prefixed to <portId>
representation
of <portId>
<vpi> Virtual Path Decimal or hex equivalent
Identifier of 8 or 12 bits
<ex_vpi> Explicit "VPI-" prefixed to <vpi>
representation
of <vpi>
<vci> Virtual Circui t Decimal or hex equivalent
Identifier of 16 bits
<ex_vci> Explicit "VCI-" prefixed to <vci>
representation
of <vci>
<vpci> Virtual Path Decimal or hex equivalent
Connection of 16 bits
Identifier
<ex_vpci> Explicit "VPCI-" prefixed to <vpci>
representation
of <vpci>
<cid> Channel Decimal or hex equivalent
Identifier of 8 bits
<ex_cid> Explicit "CID-" prefixed to <cid>
representation
of <cid>
<payloadType> Payload Decimal integer 0-127
Type
<transport> Transport Values listed in
Table 1.
<profile> Profile Decimal integer 1-255
<eecid> End-to-end Up to 8 hex digits
Connection
Identifierokay the table keeps going, bestie 💅🎀
<aalType> AAL type String values:
"AAL1","AAL1_SDT","AAL1_UDT",
"AAL2", "AAL3/4",
"AAL5", "USER_DEFINED_AAL"
<asc> ATM service String values:
category defined "CBR", "nrt-VBR", "rt-VBR",
by the ATMF "UBR", "ABR", "GFR"
<atc> ATM transfer String values:
capability "DBR","SBR","ABT/IT","ABT/DT",
defined by the "ABR"
ITU
<subtype> <asc>/<atc> Decimal integer 1-10
subtype
<qosClass> QoS Class Decimal integer 0-5
<bcob> Broadband Bearer Decimal or hex representation
Class of 5-bit field
<eetim> End-to-end timing String values: "on",
required "off".
<stc> Susceptibility Decimal equivalent of
to clipping a 2-bit field
<upcc> User plane Decimal equivalent of
connection a 2-bit field
configuration
<directionFlag> Direction Flag String values: "f", "b",
"fb"
<cdvType> CDV type String values:
"PP", "2P"
<acdv> Acceptable CDV Decimal equivalent
of 24-bit field
<ccdv> Cumulative CDV Decimal equivalent
of 24-bit field
<eetd> End-to-end transit Decimal equivalent
delay of 16-bit field
<cmtd> Cumulative transit Decimal equivalent
delay of 16-bit field
<aclr> Acceptable Decimal equivalent
Cell Loss Ratio of 8-bit field
<clpLvl> CLP level String values:
"0", "0+1"
<pcr> Peak Decimal
Cell Rate equivalent of a 24-bit field.
<scr> Sustained Decimal
Cell Rate equivalent of a 24-bit field
<mbs> Maximum Decimal
Burst Size equivalent of 16-bit field
<cdvt> CDVT Decimal equivalent of 24-bit
field.
<mcr> Minimum Decimal
Cell Rate equivalent of a 24-bit field
<mfs> Maximum Decimal
Frame Size equivalent of a 16-bit field
<fd> Frame Discard String Values:
Allowed "on", "off"
<te> CLP tagging String Values:
"on", "off"
<nrm> NRM Decimal/hex equivalent
of 3 bit field
<trm> TRM -ditto-
<cdf> CDF -ditto-
<adtf> ADTF Decimal/Hex equivalent
of 10 bit field
<ficr> Forward Initial Decimal equivalent of
Cell Rate 24-bit field
<bicr> Backward Initial Decimal equivalent of
Cell Rate 24-bit field
<ftbe> Forward Transient Decimal equivalent of
Buffer Exposure 24-bit field
<btbe> Backward Transient Decimal equivalent of
Buffer Exposure 24-bit field
<crmrtt> Cumulative RM Decimal equivalent of
round-trip time 24-bit field
(Microseconds)
<frif> Forward rate Decimal integer
increase factor 0 -15
<brif> Backward rate Decimal integer
increase factor 0 -15
<frdf> Forward rate Decimal integer
decrease factor 0 -15
<brdf> Backward rate Decimal integer
decrease factor 0 -15
<bearerType> Bearer Type String Values:
"PVC", "SVC", "CID"
<localInitiation> Local Initiation String values:
"on", "off"
<sci> Screening Indication Decimal or hex
equivalent of 4 bits.
<lsn> Leaf Sequence Number Decimal or hex
equivalent of 32 bits.
<cdStd> Coding standard for Decimal or hex
connection scope equivalent of 2 bits.
selection IE
Definition: UNI 4.0 [5]
<conScpTyp> Type of connection scope Decimal or hex
Definition: UNI 4.0 [5] equivalent of 4 bits
<conScpSel> Connection scope selection Decimal or hex
Definition: UNI 4.0 [5] equivalent of 8 bits
<cacheEnable> Enable SVC caching String values: "on",
"off"
<cacheTimer> Timer for cached SVC Decimal or hex equivalent
deletion of 32-bit field
<bearerSigIEType> Bearer Signaling IE Type 2 hex digits
<bearerSigIELng> Bearer Signaling IE Length 1-4 hex digits
<bearerSigIEVal> Bearer Signaling IE Value Even number of hex
digits, 2-512
<appClass> Application String values:
specification "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"
<oui> Organizationally 1 to 6 hex digits
Unique Identifier
<appId> Application Identifier 1 to 8 digits
<cbrRate> CBR Rate Two hex digits.
<sbc> Subchannel Count T1: Decimal integer 1-24
or hex equivalent
E1: Decimal integer 1-31
or hex equivalent
<clkrec> Clock Recovery String values:
Method "NULL", "SRTS",
"ADAPTIVE"
<fecEnable> Forward Error String values:
Correction Enable "NULL", "LOSS_SENSITIVE"
"DELAY_SENSITIVE"
<partialFill> Partial Fill Decimal integer 1-48
or hex equivalent
<structureEnable> Structure Present String values:
"on", "off"
<blksz> Block Size Decimal or hexadecimal
equivalent of 16 bits
<cpcs> Maximum AAL5: Decimal or hex
CPCS SDU size equivalent of 16 bits
AAL2: 45 or 64, decimal
or hex representation
<cidLowerLimit> AAL2 CID lower limit Decimal integer 8-255
or hex equivalent
<cidUpperLimit> AAL2 CID upper limit Decimal integer 8-255
or hex equivalent
<timerCU> Timer, combined use Integer decimal; range
(microseconds) determined by application.
Use decimal equivalent of
32 bits.
<simplifiedCPS> Simplified CPS [52] String values:
"on", "off"
<fSDUrate> Forward SDU rate Decimal equivalent of
(bits per second) 24-bit field
<bSDUrate> Backward SDU rate Decimal equivalent of
(bits per second) 24-bit field
<ted> Transmission Error String values:
Detection Enable "on", "off"
<rastimer> SSSAR reassembly Integer decimal,
(microseconds) Range determined by
application. Use decimal
equivalent of 32 bits.
<fsssar> Maximum SSSAR-SDU Decimal 1- 65568
size, forward or hex equivalent
direction
<bsssar> Maximum SSSAR-SDU Decimal 1- 65568
size, backward or hex equivalent
direction
<fsscopsdu> Maximum SSCOP-SDU Decimal 1- 65528
size, forward or hex equivalent
direction
<bsscopsdu> Maximum SSCOP-SDU Decimal 1- 65528
size, backward or hex equivalent
direction
<fsscopuu> Maximum SSCOP-UU Decimal 1- 65524
field size, forward or hex equivalent
direction
<bsscopuu> Maximum SSCOP-UU Decimal 1- 65524
field size, backward or hex equivalent
direction
<sap> Service Access String values:
Point "AUDIO", "MULTIRATE"
<circuitMode> Circuit Mode String values:
Enable "on", "off"
<frameMode> Frame Mode String values:
Enable "on", "off"
<faxDemod> Fax Demodulation String values:
Enable "on", "off"
<cas> Enable CAS transport String values:
via Type 3 packets "on", "off"
<dtmf> Enable DTMF transport String values:
via Type 3 packets "on", "off"
<mfall> Enable MF transport String values:
via Type 3 packets "on", "off"
<mfr1> Enable MF (R1) String values:
transport via "on", "off"
Type 3 packets
<mfr2> Enable MF (R2) String values:
transport via "on", "off"
Type 3 packets
<PCMencoding> PCM encoding String values:
"PCMA", "PCMU"
<fmaxFrame> Maximum length of a Decimal or hex
frame mode data unit, equivalent of
forward direction 16-bit field<bmaxFrame> Maximum length of a -ditto-
frame mode data unit,
backward direction
<silenceSuppEnable> Silence suppression String values:
Enable "on", "off"
<silenceTimer> Kick-in timer Decimal or hex representation
for silence of 16-bit field
suppression
<suppPref> Preferred Silence String values:
Suppression Method "standard", "custom"
<sidUse> SID Use String values:
Method "No SID", "Fixed Noise",
"Sampled Noise"
<fxnslevel> Fixed Noise Decimal or hex representation
Level of a 7-bit field
<ecanEnable> Enable Echo String values:
Cancellation "on", "off"
<ecanType> Type of Echo String values:
Cancellation "G165", "G168"
<gcEnable> Enable Gain String values:
Control "on", "off"
<gcLvl> Level of inserted Decimal or hex equivalent
Loss of 16-bit field
<aal2transport> AAL2 transport Values listed in Table 1
that begin with the string
"AAL2"
<uuiCodeRange> UUI code range Decimal integer 0-15
<encodingName> Encoding name String values:
"PCMG", "SIDG", "SID729",
any value from column 2
of Table 2
<packetLength> Packet length Decimal integer 0-45
<packetTime> Packetization Decimal integer 1-65,536
Interval in microsec.
<fxIncl> Facsimile included String values: "on", "off"
<serviceType> Service type String values: "v", "d", "f",
"df", "all"
<q7655scc> Contents of the Even number of hex
Q.765.5 Single digits (4-32)
Codec IE
<isupUsi> ISUP User Service Even number of hex digits
Information (4-24)
<uiLayer1Prot> User Information Two hex digits
Layer 1 Protocol
<chainPointer> Chain pointer String values: "NEXT",
"PREVIOUS", "NULL"
<rtcpPortNum> RTCP port number for Odd decimal in range 1,024 to
H.323 Annex C 65,535.
applications Preferred: Odd number in
the range 49,152 to 65,535
<rtcpIPaddr> IP address for receipt Dotted decimal, 7-15 chars
of RTCP packets7. Examples of ATM session descriptions using SDP ✨
Let's look at some real-life examples of ATM session descriptions, bestie! 🦋 Here's a full AAL1 session description in SDP:
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL1/AVP 18 0 96
a=atmmap:96 X-G727-32
a=eecid:B3D58E32Now an AAL2 session description in SDP, and it's giving clean vibes 💅:
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1
a=eecid:B3E32The next AAL2 descriptor is basically the same as the one above, except it's way more specific 🎀. It states an explicit preference for a voice codec, a voiceband data codec and a voiceband fax codec. It also defines the profile AAL2/custom 100 instead of just assuming the far-end knows what's in that profile. Main character energy 👑:
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1
a=eecid:B3E32
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 5000 0-7 SIDG 1
5000 8-15 G726-32 40 10000 8-15 SIDG 1 5000
a=vsel:G726-32 40 10000
a=dsel:off PCMU - -
a=fsel:G726-32 40 10000Next up is an SDP session descriptor for an AAL5 switched virtual circuit that delivers MPEG-2 video 🎬✨:
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=video $ AAL5/ITU 33
a=eecid:B3E32
a=aalType:AAL5
a=bearerType:SVC on
a=atmTrfcDesc:f 0+1 7816 - - - - - off -
a=atmTrfcDesc:b 0+1 0 - - - - - on -
a=cpsSDUsize:f 20680
a=aalApp:itu_h2221 - -And finally, an SDP session descriptor for an AAL5 permanent virtual circuit that delivers MPEG-2 video 🌸:
v=0
o=- A3C47F21456789F0 0 ATM - -
s=-
c=ATM - -
t=0 0
m=video PORT-$/VPI-0/VCI-$ AAL5/ITU 33
a=bearerType:PVC -
a=atmTrfcDesc:f 0+1 7816 - - - - - off -
a=atmTrfcDesc:b 0+1 0 - - - - - on -
a=cpsSDUsize:f 20680
a=aalApp:itu_h2221 - -8. Security Considerations 🔐
8.1 Bearer Security
Okay, this part is serious, bestie 😭. Right now, the standard ways of encrypting ATM and AAL2 bearers are not conventionalized the same way we do encryption for RTP payloads. Authentication of ATM or AAL2 bearer signaling isn't sorted out either 🙈.
The SDP encryption key line (k=) defined in RFC 2327 can be used to represent the encryption key and the method of obtaining the key. In the ATM and AAL2 contexts, the term 'bearer' can include 'bearer signaling' as well as 'bearer payloads', so keep that in mind 💜.
8.2 Security of the SDP description
The SDP session descriptions might come from untrusted areas, like equipment owned by end-subscribers or sitting at end-subscriber premises. Yikes 💀. SDP relies on the security mechanisms of the encapsulating protocol, or the layers below it. Examples of encapsulating protocols are the Session Initiation Protocol (SIP), MGCP and Multimedia Gateway Control Protocol (MEGACO). No additional security mechanisms are needed. SIP, MGCP and MEGACO can use IPSec authentication as described in RFC 1826 [Ref. 27]. IPSec encryption can optionally be used with authentication to provide an additional, potentially more expensive, level of security 🔥. IPSec security associations can be made between equipment located in untrusted areas and equipment located in trusted areas, either through configured shared secrets or through the use of a certificate authority 🧚.
9. ATM SDP Grammar 📜
This appendix provides an Augmented BNF (ABNF) grammar for the ATM conventions for SDP. ABNF is defined in rfc2234. This is not a complete ABNF description of SDP. For an ABNF description of the SDP base line protocol, readers are referred to [1], and for application-specific conventions for SDP use, check out rfc2848, rfc2543, rfc2045 and rfc2326. For case conventions, see section 2.4. Bookmark this, it's giving research energy 🤓💖.
; Constant definitions
safe = alpha-numeric / "'" / "-" / "." / "/" / ":" / "?" / DQUOTE /
"#" / "$" / "&" / "*" / ";" / "=" / "@" / "[" / "]" / "^" / "_" /
"`" / "{" / "|" / "}" / "+" / "~"
DQUOTE = %x22 ; double quote
alpha-numeric = ALPHA / DIGIT
ALPHA = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" /
"k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" /
"u" / "v" / "w" / "x" / "y" / "z" /
"A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
"K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" /
"U" / "V" / "W" / "X" / "Y" / "Z"
DIGIT = "0" / POS-DIGIT
POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
hex-prefix = "0" ("x" / "X")
HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F"
space = %d32
EOL = (CR / LF / CRLF) ; as per Megaco RFC
CR = %d13
LF = %d10
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
generic-U8 = (hex-prefix hex-U8) / decimal-uchar
generic-U12 = (hex-prefix hex-U12) / 1*4 (DIGIT)
generic-U16 = (hex-prefix hex-U16) / 1*5(DIGIT)
generic-U24 = (hex-prefix hex-U24) / 1*8(DIGIT)
generic-U32 = (hex-prefix hex-U32) / 1*10(DIGIT)
hex-U8 = 1*2(HEXDIG)
hex-U12 = 1*3(HEXDIG)
hex-U16 = 1*4(HEXDIG)
hex-U24 = 1*6(HEXDIG)
hex-U32 = 1*8(HEXDIG)
generic-U8-or-null = generic-U8 / "-"
generic-U12-or-null = generic-U12 / "-"
generic-U16-or-null = generic-U16 / "-"
generic-U24-or-null = generic-U24 / "-"
generic-U32-or-null = generic-U32 / "-"
decimal-U8-or-null = decimal-uchar / "-"
decimal-U12-or-null = 1*4(DIGIT) / "-"
decimal-U16-or-null = 1*5(DIGIT) / "-"
decimal-U24-or-null = 1*8 (DIGIT) / "-"
decimal-U32-or-null = 1*10(DIGIT) / "-"
on-off-or-null = "on" / "off" / "-"
; ABNF definition of SDP with ATM conventions
SDP-infoset = 1*(announcement)announcement = proto-version
origin-field session-name-field information-field uri-field
email-fields phone-fields connection-field bandwidth-fields
time-fields key-field attribute-fields media-descriptions
proto-version = ["v=" 1*4(DIGIT) EOL] ; use "v=0" for ATM SDP
origin-field = ["o=" username space sess-id space sess-version space
net-type-addr EOL]
username = 1* safe ; for ATM use "-"
sess-id = (1*32 DIGIT) / (hex-prefix 1*32 HEXDIG)
sess-version = (1*10 DIGIT) / (hex-prefix 1*8 HEXDIG)
net-type-addr= nettype space addrtype-addr
netttype = "ATM" / "IN" / "TN" / "-" / "$"
; Other nettype values may be defined in the future in other documents
; Validity of nettype and addrtype-addr combination to be checked at
; application level, not protocol syntax level
addrtype-addr = atm-addrtype-addr / ip-addrtype-addr / tn-addrtype-addr
; ip-addrtype-addr per rfc2327
; tn-addrtype-addr per rfc2848
; ATM address definition
atm-addrtype-addr = atm-nsap-addr / atm-e164-addr / atm-alias-addr
atm-nsap-addr = ("NSAP" / "-" / "$") space (nsap-addr / "-" / "$")
atm-e164-addr = ("E164" / "-" / "$") space (e164-addr / "-" / "$")
atm-alias-addr = ("GWID" / "ALIAS" / "-" / "$") space (alias-addr /
"-" / "$")
nsap-addr = 2(HEXDIG) "." 9(4(HEXDIG) ".") 2(HEXDIG)
e164-addr = 1*15 (DIGIT)
alias-addr = 1*32(alpha-numeric / "-" / "." / "_")
session-name-field = ["s=" text EOL] ; for ATM use "s=-"
text = byte-string
byte-string = 1*(byte-string-char) ; definition per rfc2327
byte-string-char = %x01-09/ %x0B/ %x0C/ %x0E-FF ; all ASCII except
NUL, CR & LF
; Definitions of information-field, uri-field, email-fields,
; phone-fields per rfc2327. These fields are omitted in
; ATM SDP descriptions. If received, they are ignored in the ATM
; context
connection-field = ["c=" c-net-type-addr]
; connection-field required, not optional, in ATM
c-net-type-addr = nettype space c-addrtype-addr
c-addrtype-addr = atm-addrtype-addr / c-ip-addrtype-addr /
tn-addrtype-addr
; atm-addrtype-addr defined above
; c-ip-addrtype-addr per rfc2327
; difference in address usage between 'o' and 'c' lines per rfc2327
; tn-addrtype-addr per rfc2848
bandwidth-fields = *("b=" bwtype ":" bandwidth EOL)
bwtype = 1*(alpha-numeric)
bandwidth = 1*(DIGIT)
time-fields = *( "t=" start-time space stop-time
*(EOL repeat-fields) EOL)
[zone-adjustments EOL]
start-time = time / "0"Okay so we're picking up right where stop-time walks in, and bestie, this part is all about the grammar bits that make ATM SDP descriptors tick 🧚✨ Let's go!
stop-time = time / "0" ; always "0" in ATM
time = POS-DIGIT 9*(DIGIT) ; same as rfc2327
; repeat-fields and zone-adjustments per rfc2327, not used in ATM
; Definition of optional key-field per rfc2327
;
attribute-fields = *("a=" attribute EOL)
; SDP descriptors for ATM do not have session-level media attribute
; lines. If these are provided, they should be ignored.
media-descriptions = *(media-description)
media-description = media-field information-field *(connection-field)
bandwidth-fields key-field attribute-fields
; Definitions of information-field per RFC 2327. These fields are
; omitted in ATM SDP descriptions. If received, they are ignored in
; the ATM context
;
; In ATM, the connection-field is used in media-description to indicate
; the IP address associated with the RTCP control protocol in H.323.C
; applications. In this case, the connection field is per the RFC 2327
; definition for IP v4-based connections. Otherwise, it is not used in
; media-description. If received as part of media-description,
; it is ignored.
;
; Definition of optional bandwidth-fields as above.
: Definition of optional key-field as in RFC 2327
media-field = rfc2327-media-field / rfc2848-media-field /
atm-media-field
; rfc2327-media-field and rfc2848-media-field defined in those rfc's
atm-media-field = "m=" media space vcId space transport-fmts EOL
; superset of rfc2327 definition
media = "audio" / "video" / "data" / "application" / "control" /
1*(alpha-numeric)
vcId = "$" / "-" / ex-vcci / (ex-vcci "/" ex-cid) /
(atm-type-addr-m "/" ex-vcci) /
(atm-type-addr-m "/" ex-vcci "/" ex-cid) /
(ex-bcg "/" ex-vcci) / (ex-bcg "/" ex-vcci "/" ex-cid)
(ex-portid "/" ex-vpi "/" ex-vci) /
(ex-portid "/" ex-vpi "/" ex-vci "/" ex-cid) /
(ex-bcg "/" ex-vpi "/" ex-vci) /
(ex-bcg "/" ex-vpi "/" ex-vci "/" ex-cid) /
(ex-vpci "/" ex-vci) /
(ex-vpci "/" ex-vci "/" ex-cid) /
(atm-type-addr-m "/" ex-vpci "/" ex-vci) /
(atm-type-addr-m "/" ex-vpci "/" ex-vci "/" ex-cid)
atm-type-addr-m = atm-nsap-addr-m / atm-e164-addr-m / atm-alias-addr-m
atm-nsap-addr-m = ["NSAP-"] (nsap-addr / "$")
atm-e164-addr-m = ["E164-"] (e164-addr / "$")
atm-alias-addr-m = ["GWID-" / "ALIAS-"] (alias-addr / "$")
; The -m at the end indicates use in the media field
; Wildcarding rules different from ATM address on 'o' and 'c' lines
ex-vcci = "VCCI-" vcci
ex-cid = "CID-" cid
ex-bcg = "BCG-" bcg
ex-portid = "PORT-" portid
ex-vpi = "VPI-" vpi
ex-vci = "VCI-" vci
ex-vpci = "VPCI-" vpci
vcci = generic-U16
cid = generic-U8
bcg = generic-U8
portid = 1*32 (HEXDIG)
vpi = generic-U12
vci = generic-U16
vpci = generic-U16
transport-fmts = generic-transport-fmts / known-transport-fmts / "- -"
generic-transport-fmts = generic-transport 1*(space fmt)
generic-transport = 1*(alpha-numeric / "/")
fmt = 1*(alpha-numeric)
known-transport-fmts = aal1-transport space aal1-fmt-list /
aal2-transport space aal2-fmt-list
*(space aal2-transport space aal2-fmt-list) /
aal5-transport space aal5-fmt-list /
rtp-transport space rtp-fmt-list /
tn-proto space tn-fmt-list /
h323c-proto "-"
h323c-proto = "H323c"
; h323c-proto used for RTCP control ports in H.323 annex C
; applications. tn-proto and tn-fmt-list per rfc2848
aal1-transport = "AAL1" "/" aal1-transport-list
aal1-transport-list = "ATMF" / "ITU" / "custom" / "IEEE:" oui /
corporate-name
corporate-name = 1*(safe)
aal2-transport = "AAL2" "/" aal2-transport-list
aal2-transport-list = aal1-transport-list
aal5-transport = "AAL5" "/" aal5-transport-list
aal5-transport-list = aal1-transport-list
rtp-transport = "RTP" "/" rtp-transport-list
rtp-transport-list = "AVP"
aal1-fmt-list = (payload-type *(space payload-type)) / "-"
payload-type = decimal-uchar
aal5-fmt-list = aal1-fmt-list
rtp-fmt-list = aal1-fmt-list
aal2-fmt-list = (profile *(space profile)) / "-"
profile = decimal-uchar
attribute-fields = *("a=" attribute EOL)
attribute = known-attribute / (generic-att-field ":" att-value) /
generic-att-field
generic-att-field = 1*(alpha-numeric)
att-value = byte-string
known-attribute = atm-attribute / PINT-attribute / rfc2327-attribute
; PINT-attribute as defined in rfc2848
; rfc2327 attribute as defined in that rfc
atm-attribute =
"eecid" ":" eecid /
"aalType" ":" aalType /
"capability" ":" (asc / atc) space subtype /
"qosclass" ":" qosclass /
"bcob" ":" bcob space eetim /
"stc" ":" stc /
"upcc" ":" upcc /
"atmQOSparms" ":" directionFlag space cdvType
space acdv space ccdv space eetd space cmtd
space aclr /
"atmTrfcDesc" ":" directionFlag space clpLvl
space pcr space scr space mbs space cdvt space
mcr space mfs space fd space te /
"abrParms" ":" directionFlag space nrm space trm space cdf
space adtf /
"abrSetup" ":" ficr space bicr space ftbe space btbe space
crmrtt space frif space brif space frdf space brdf /
"bearertype" ":" bearerType space localInitiation /
"lij" ":" sci space lsn /
"anycast" ":" atmGroupAddress space cdStd space
conScpTyp space conScpSel /
"cache" ":" cacheEnable space cacheTimer /
"bearerSigIE" ":" bearerSigIEType space
bearerSigIELng space bearerSigIEVal /
"aalApp" ":" appClass space oui space appId /
"cbrRate" ":" cbrRate /
"sbc" ":" sbc /
"clkrec" ":" clkrec /
"fec" ":" fecEnable /
"prtfl" ":" partialFill /
"structure" ":" structureEnable space blksz /
"cpsSDUsize" ":" directionFlag space cpcs /
"aal2CPS" ":" cidLowerLimit space cidUpperLimit space
timerCU space simplifiedCPS /
"aal2CPSSDUrate" ":" fSDUrate space bSDUrate /
"aal2sscs3661unassured" ":" ted space rastimer space fsssar
space bsssar /
"aal2sscs3661assured" ":" rastimer space fsssar space bsssar
space fsscopsdu space bsscopsdu space fsscopuu
space bsscopuu /
"aal2sscs3662" ":" sap space circuitMode space frameMode
space faxDemod space cas space dtmf space mfall space mfr1
space mfr2 space PCMencoding space fmaxFrame
space bmaxFrame /
"aal5sscop" ":" fsscopsdu space bsscopsdu space fsscopuu
space bsscopuu /
"atmmap" ":" payload-type space encoding-name /
"silenceSupp" ":" silenceSuppEnable space silenceTimer
space suppPref space sidUse space fxnslevel /
"ecan" ":" directionFlag space ecanEnable space ecanType /
"gc" ":" directionFlag space gcEnable space gcLvl /
"profileDesc" ":" aal2-transport space profile space
1*(profile-row) /
"vsel" ":" 1*(encoding-name space packet-length space
packet-time space) /
"dsel" ":" fxIncl space
1*(encoding-name space packet-length space
packet-time space) /
"fsel" ":" 1*(encoding-name space packet-length space
packet-time space) /
"onewaySel" ":" serviceType space directionFlag space
1*(encoding-name space packet-length space
packet-time space) /
"codecconfig" ":" q7655scc /
"isup_usi" ":" isupUsi /
"uiLayer1_Prot" ":" uiLayer1Prot /
"chain" ":" chainPointerNow the big attribute-value rules, bestie. These are the nitty-gritty details that tell each a= line exactly what it's allowed to say 💅🎀
eecid = 8 (HEXDIG)
aalType = "AAL1" / "AAL2" / "AAL3/4" / "AAL5" / "USER_DEFINED_AAL"
asc = "CBR" / "nrt-VBR" / "rt-VBR" / "UBR" / "ABR" / "GFR"
atc = "DBR" / "SBR" / "ABT/IT" / "ABT/DT" / "ABR"
subtype = decimal-U8-or-null
qosclass = decimal-U8-or-null
bcob = generic-U8
eetim = on-off-or-null
stc = decimal-uchar
upcc = decimal-uchar
directionFlag = "f" / "b" / "fb"
cdvType = "PP" / "2P" / "-"
acdv = decimal-U32-or-null
ccdv = decimal-U32-or-null
eetd = decimal-U16-or-null
cmtd = decimal-U16-or-null
aclr = decimal-U8-or-null
clpLvl = "0" / "0+1" / "-"
pcr = decimal-U24-or-null
scr = decimal-U24-or-null
mbs = decimal-U16-or-null
cdvt = decimal-U24-or-null
mcr = decimal-U24-or-null
mfs = decimal-U16-or-null
fd = on-off-or-null
te = on-off-or-null
nrm = generic-U8-or-null
trm = generic-U8-or-null
cdf = generic-U8-or-null
adtf = generic-U16-or-null
ficr = decimal-U24-or-null
bicr = decimal-U24-or-null
ftbe = decimal-U24-or-null
btbe = decimal-U24-or-null
crmrtt = decimal-U24-or-null
frif = 1*2 (DIGIT)
brif = 1*2 (DIGIT)
frdf = 1*2 (DIGIT)
brdf = 1*2 (DIGIT)
bearerType = "PVC" / "SVC" / "CID"
localInitiation = on-off-or-null
sci = generic-U8-or-null
lsn = generic-U32-or-null
atmGroupAddress = atm-type-addr
cdStd = generic-U8-or-null
conScpTyp = generic-U8-or-null
conScpSel = generic-U8-or-null
cacheEnable = on-off-or-null
cacheTimer = generic-U32-or-null
bearerSigIEType = 2 * (HEXDIG)
bearerSigIELng = 1*4 (HEXDIG)
bearerSigIEVal = 2*512 (HEXDIG)
appClass = "-" /
"itu_h323c" / "af83" / "AAL5_SSCOP" / "itu_i3661_unassured" /
"itu_ i3661_assured"/ "itu_i3662"/ "itu_i3651" /
"itu_i3652" / "itu_i3653" / "itu_i3654" / "FRF11" / "FRF5" /
"FRF8" / "itu_h2221"
oui = "-" / 1*6 (HEXDIG)
appId = "-" / 1*8 (HEXDIG)
cbrRate = 2 (HEXDIG)
sbc = generic-U8
clkrec = "NULL" / "SRTS" / "ADAPTIVE"
fecEnable = "NULL" / "LOSS_SENSITIVE" / "DELAY_SENSITIVE"
partialFill = generic-U8
structureEnable = on-off-or-null
blksz = generic-U16-or-null
cpcs = generic-U16
cidLowerLimit = generic-U8-or-null
cidUpperLimit = generic-U8-or-null
timerCU = decimal-U32-or-null
simplifiedCPS = on-off-or-null
fSDUrate = decimal-U24-or-null
bSDUrate = decimal-U24-or-null
ted = on-off-or-null
rastimer = decimal-U32-or-null
fsssar = generic-U24-or-null
bsssar = generic-U24-or-null
fsscopsdu = generic-U16-or-null
bsscopsdu = generic-U16-or-null
fsscopuu = generic-U16-or-null
bsscopuu = generic-U16-or-null
sap = "AUDIO" / "MULTIRATE" / "-"
circuitMode = on-off-or-null
frameMode = on-off-or-null
faxDemod = on-off-or-null
cas = on-off-or-null
dtmf = on-off-or-null
mfall = on-off-or-null
mfr1 = on-off-or-null
mfr2 = on-off-or-null
PCMencoding = "PCMA" / "PCMU" / "-"
fmaxframe = generic-U16-or-null
bmaxframe = generic-U16-or-null
silenceSuppEnable = on-off-or-null
silenceTimer = generic-U16-or-null
suppPref = "standard" / "custom" / "-"
sidUse = "No SID" / "Fixed Noise" / "Sampled Noise" / "-"
fxnslevel = generic-U8-or-null
ecanEnable = on-off-or-null
ecanType = "G165" / "G168" / "-"
gcEnable = on-off-or-null
gcLvl = generic-U16-or-null
profile-row = uuiCodeRange space encoding-name space packet-length
space packet-time space
uuiCodeRange = decimal-uchar "-" decimal-uchar / "-"
encoding-name = "-" /
"PCMG" / "SIDG" / "SID729" /
"PCMU" / "G726-32" / "G723" / "PCMA" / "G722" / "G728" /
"G729" / "X-G729a" / "X-G729b" / "X-G729ab" /
"X-G726-16" / "X-G726-24" / "X-G726-40" / "X-G7231-H" /
"X-G7231-L" / "X-G7231a-H" / "X-G7231a-L" /
"X-G727-16" / "X-G727-24" / "X-G727-32" /
"X-CCD" / "X-CCD-CAS" / "GSM" / "GSM-HR" / "GSM-EFR" /
"GSM-EHR" / "X-FXDMOD-3" / "1016" / "DVI4" / "L16" /
"LPC" / "MPA" / "QCELP" / "H263" / "H263-1998" /
"JPEG" / "H261" / "MPV" / "MP2T" / "nv" / "RED" /
"CelB" / "L8" / "VDVI" / "MP1S" / "MP2P" / "BT656" /
"FR-AMR" / "HR-AMR" / "UMTS-AMR" / "AMR"
packet-length = decimal-U8-or-null
packet-time = decimal-U16-or-null
fxIncl = on-off-or-null
serviceType = "v" / "d" / "f" / "df" / "all"
q7655scc = 4*32 (HEXDIG)
isupUsi = 4*24 (HEXDIG)uiLayer1Prot = 2 (HEXDIG)
chainPointer = "NEXT" / "PREVIOUS" / "NULL"References 📚✨
okay bestie, here are all the sources I leaned on, so you can check my homework 🤓💅
- [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. RFC 1889 will be obsoleted, in a substantially backwards compatible manner, by a work in progress that will become an RFC. 🦋
- [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996. RFC 1890 will be obsoleted, in a fully backwards compatible manner, by a work in progress that will become an RFC. 🌸
- [4] ATMF UNI 3.1 Specification, af-uni-0010.002. Of special interest for this document is Section 5.4.5.5, ATM Adaptation Layer Parameters.
- [5] ATMF UNI 4.0 Signaling Specification, af-sig-0061.000.
- [6] ATMF Traffic Management Specification, Version 4.1, af-tm-0121.000.
- [7] ATMF Circuit Emulation Service (CES) Interoperability Specification, version 2.0, af-vtoa-0078.000, Jan. 97.
- [8] ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997.
- [9] ATMF Specifications of (DBCES) Dynamic Bandwidth Utilization - in 64kbps Timeslot Trunking over ATM - using CES, af-vtoa-0085.000, July 1997.
- [10] ITU-T I.363.1, B-ISDN ATM Adaptation Layer Specification: Type 1 AAL, August 1996.
- [11] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type 2 AAL, Sept. 1997.
- [12] ITU-T I.366.1, Segmentation and Reassembly Service Specific Convergence Sublayer for AAL Type 2, June 1998.
- [13] ITU-T I.366.2, AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking, Feb. 99.
- [14] Petrack, S., "RTP payloads for Telephone Signal Events", Work in Progress.
- [15] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling.
- [16] Amendment 1, 2, 3 and 4 to ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling.
- [17] Handley, M., Perkins C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [18] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "Session Initiation Protocol (SIP)", RFC 2543, March 1999.
- [19] Almquist, P., "Type of Service in the Internet Protocol Suite", July 1992.
- [20] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", December 1998.
- [21] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type 5 AAL, Aug. 1996.
- [22] ATMF PNNI 1.0, af-pnni-0055.000, March 1996.
- [23] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", Work in Progress.
- [24] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", Work in Progress.
- [25] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP)", RFC 2705, October 1999.
- [26] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.
- [27] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
- [28] ITU I.371, Traffic Control and Congestion Control in the BISDN.
- [29] ITU E.191, BISDN Numbering and Addressing.
- [30] ATM Forum Addressing: Reference Guide, af-ra-0106.000.
- [31]
http://www.iana.org/assignments/rtp-parametersfor a list of codecs with static payload types. - [32] ITU Q.2941-2, Digital Subscriber Signalling System No. 2 (DSS 2): Generic identifier transport extensions.
- [33] ITU Q.2961, Digital subscriber signalling system no.2 (DSS 2) - additional traffic parameters. Also, Amendment 2 to Q.2961.
- [34] ITU Q. 2965.1, Digital subscriber signalling system no.2 (DSS 2) - Support of Quality of Service classes.
- [35] ITU Q. 2965.2, Digital subscriber signalling system no.2 (DSS 2) - Signalling of individual Quality of Service parameters.
- [36] ITU Q.1901, Bearer Independent Call Control Protocol.
- [37] ITU Q.2630.1, AAL type 2 signaling protocol - capability set 1.
- [38] ITU I.363.5, B-ISDN ATM Adaptation Layer specification: Type 5 AAL.
- [39] I.365.1, Frame relaying service specific convergence sublayer (FR-SSCS).
- [40] I.365.2, B-ISDN ATM adaptation layer sublayers: service specific coordination function to provide the connection oriented network service.
- [41] I.365.3, B-ISDN ATM adaptation layer sublayers: service specific coordination function to provide the connection-oriented transport service.
- [42] I.365.4, B-ISDN ATM adaptation layer sublayers: Service specific convergence sublayer for HDLC applications.
- [43] Q.2110, B-ISDN ATM adaptation layer - service specific connection oriented protocol (SSCOP).
- [44] af-vtoa-0113.000, ATM trunking using AAL2 for narrowband services.
- [45] H.323-2, Packet-based multimedia communications systems.
- [46] af-vtoa-0083.000, Voice and Telephony Over ATM to the Desktop.
- [47] I.356, BISDN ATM layer cell transfer performance.
- [48] ITU Q.2957, Digital Subscriber Signaling System No. 2, User to user signaling.
- [49] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
- [50] TIA/EIA/IS-J-STD-025-A, Lawfully Authorized Electronic Surveillance, May 2000.
- [51] ITU-T H.222.1, Multimedia multiplex and synchronization for audiovisual communication in ATM environments.
- [52] af-vmoa-0145.000, Voice and Multimedia over ATM, Loop Emulation Service using AAL2.
- [53] FRF.5, Frame Relay/ATM PVC Network Interworking Implementation Agreement.
- [54] FRF.8.1, Frame Relay/ATM PVC Service Interworking Implementation Agreement.
- [55] FRF.11, Voice over Frame Relay Implementation Agreement.
- [56] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [57] ITU Q.765.5, Application Transport Mechanism - Bearer Independent Call Control.
- [58]
http://www.3gpp.org/ftp/Specsfor specifications related to 3GPP, including AMR codecs. - [59] ITU Q.931, Digital Subscriber Signaling System No. 1: Network Layer.
- [60] ITU Q.763, SS7 - ISUP formats and codes.
- [61]
http://www.atmforum.com/atmforum/specs/specs.html, ATM Forum, Well-known addresses and assigned codes. - [62] Bradner, S., "Keywords for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
Acknowledgements 💖🫶
the authors gave a huge shoutout to everyone who helped make these SDP conventions happen. these people reviewed, implemented and tested the constructs, and they're absolutely iconic for it 👑
Valuable technical ideas that have been incorporated into this internet document have been provided by Hisham Abdelhamid, Flemming Andreasen, David Auerbach, Robert Biskner, Bruce Buffam, Steve Casner, Alex Clemm, Bill Foster, Snehal Karia, Raghu Thirumalai Rajan, Joe Stone, Bruce Thompson, Dan Wing and Ken Young of Cisco, Michael Brown, Rade Gvozdanovic, Graeme Gibbs, Tom-PT Taylor, Mark Watson and Sophia Scoggins of Nortel Networks, Brian Rosen, Tim Dwight and Michael Mackey of Marconi, Ed Guy and Petros Mouchtaris of Telcordia, Christian Groves of Ericsson, Charles Eckel of Vovida Networks, Tom Jepsen, Dal Chohan, Sagar Gordhan and Chris Gallon of Fujitsu, Mahamood Hussain of Hughes Software Systems and Sean Sheedy of nCUBE Corporation, Narendra Tulpule of Intel, Albrecht Schwarz of Alcatel, and Jonathan Rosenberg of Dynamicsoft. 🌈
The authors also wish to thank the ISC device control group, and the MMUSIC and MEGACO subgroups of the IETF, especially Bill Foster, Joerg Ott, Sean Sheedy and Brian Rosen for their help in the preparation of this document. 🧚
Finally, thanks are due to Narendra Tulpule of Intel whose ABNF grammar was adapted for this document. 💅
Authors' Addresses 🎀
here's where you can find the authors, in case you want to slide into their inbox about it 🍓
Rajesh Kumar
Cisco Systems, Inc.
M/S SJC01/3
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: 1-800-250-4800
EMail: rkumar@cisco.com
Mohamed Mostafa
Cisco Systems, Inc.
M/S SJC01/3
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: 1-800-250-4800
EMail: mmostafa@cisco.comFull Copyright Statement ⭐
so, the legal bit, but make it cute 🙈 the Internet Society owns the copyright here, and the whole thing is set up so that people can share and build on it without asking first. the one catch is that you can't change the document itself, like ripping out the copyright notice or the references to the Internet Society or other Internet organizations. the exception is when you're developing Internet standards, which has to follow the copyright procedures in the Internet Standards process, or when you're translating it into a language other than English. the permissions I just described are perpetual, so they won't be taken back by the Internet Society or its successors or assigns. 🦋
the document and the information in it are provided "AS IS", 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. 😭
Copyright (C) The Internet Society (2001). All Rights Reserved.
Acknowledgement 🌸
last but not least, the RFC Editor function is currently funded by the Internet Society, so a big thank you to them for keeping all of this running ✨🫶
📦 where this page comes from
- ietf: rfc3108 2001-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms