diff options
Diffstat (limited to 'doc/rfc/rfc3108.txt')
| -rw-r--r-- | doc/rfc/rfc3108.txt | 6163 |
1 files changed, 6163 insertions, 0 deletions
diff --git a/doc/rfc/rfc3108.txt b/doc/rfc/rfc3108.txt new file mode 100644 index 0000000..857dcc0 --- /dev/null +++ b/doc/rfc/rfc3108.txt @@ -0,0 +1,6163 @@ + + + + + + +Network Working Group R. Kumar +Request for Comments: 3108 M. Mostafa +Category: Standards Track Cisco Systems + May 2001 + + + Conventions for the use of the Session Description Protocol (SDP) + for ATM Bearer Connections + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document describes conventions for using the Session Description + Protocol (SDP) described in RFC 2327 for controlling ATM Bearer + Connections, and any associated ATM Adaptation Layer (AAL). The AALs + addressed are Type 1, Type 2 and Type 5. This list of conventions is + meant to be exhaustive. Individual applications can use subsets of + these conventions. Further, these conventions are meant to comply + strictly with the SDP syntax as defined in RFC 2327. + +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 + + + +Kumar & Mostafa Standards Track [Page 1] + +RFC 3108 ATM SDP May 2001 + + + 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 + + + +Kumar & Mostafa Standards Track [Page 2] + +RFC 3108 ATM SDP May 2001 + + + 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..........................................110 + +1. Introduction + + SDP will be used in conjunction with a connection handling /device + control protocol such as Megaco (H.248) [26], SIP [18] or MGCP [25] + to communicate the information needed to set up ATM and AAL2 bearer + connections. These connections include voice connections, voiceband + data connections, clear channel circuit emulation connections, video + connections and baseband data connections (such as fax relay, modem + relay, SSCOP, frame relay etc.). + + These conventions use standard SDP syntax as defined in RFC 2327 [1] + to describe the ATM-level and AAL-level connections, addresses and + other parameters. In general, parameters associated with layers + higher than the ATM adaptation layer are included only if they are + tightly coupled to the ATM or AAL layers. Since the syntax conforms + to RFC 2327, standard SDP parsers should react in a well-defined and + safe manner on receiving session descriptions based on the SDP + conventions in this document. This is done by extending the values + of fields defined in RFC 2327 rather than by defining new fields. + This is true for all SDP lines except the of the media attribute + lines, in which case new attributes are defined. The SDP protocol + allows the definition of new attributes in the media attribute lines + which are free-form. For the remaining lines, the fact that the + <networkType> field in an SDP descriptor is set to "ATM" should + preclude the misinterpretation of extended parameter values by RFC + 2327-compliant SDP parsers. + + + + +Kumar & Mostafa Standards Track [Page 3] + +RFC 3108 ATM SDP May 2001 + + + These conventions are meant to address the following ATM + applications: + + 1. Applications in which a new SVC is set-up for each service + connection. These SVCs could be AAL1 or AAL5 SVCs or single- + CID AAL2 SVCs. + + 2. Applications in which existing path resources are assigned to + service connections. These 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. + + Note that the difference between PVCs and SPVCs is in the way the + bearer virtual circuit connection is set up. SPVCs are a class of + PVCs that use bearer signaling, as opposed to node-by-node + provisioning, for connection establishment. + + This document is limited to the case when the network type is ATM. + This 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 is independent of lower layers, + which are configured prior to it. 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. This + might require a chaining of IP and ATM descriptors, as described in + section 5.6.4.1. + + This document makes no assumptions on who constructs the session + descriptions (media gateway, intermediate ATM/AAL2 switch, media + gateway controller etc.). This will be different in different + applications. Further, it allows the use of one session description + for both directions of a connection (as in SIP and MGCP applications) + or the use of separate session descriptions for different directions. + It also addresses the ATM multicast and anycast capabilities. + + This document makes no assumptions about how the SDP description will + be 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. + + + +Kumar & Mostafa Standards Track [Page 4] + +RFC 3108 ATM SDP May 2001 + + + - Use of extended ISUP parameters [36] to encode the information in + SDP descriptors, with conversion to/from binary/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 + document are to be interpreted as described in RFC 2119 [62]. + +2. Representation of Certain Fields within SDP description lines + + This document conforms to the syntactic conventions of standard SDP + as defined in RFC 2327 [1]. + +2.1 Representation of Extension Attributes + + The SDP protocol [1] requires that non-standard attributes and codec + names use an "X-" prefix. + + In this internet document, 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, this prefix is not used for the extension SDP attributes + defined in this document. This has been done to enhance legibility. + + This document suggests that parsers be flexible in the use of 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 the format of their representation in SDP, the + parameters defined in this document fall into the following 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. + + No prefixes are needed for classes 1 - 3, since the format is fixed. + For class 4, a "0x" prefix shall always be used to differentiate the + hexadecimal from the decimal format. + + + + +Kumar & Mostafa Standards Track [Page 5] + +RFC 3108 ATM SDP May 2001 + + + 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. Thus, 3 and 0x3 translate into the following five-bit + pattern: 0 0011. The SDP representations 0x12 and 18 translate into + the following five-bit pattern: 1 0010. + + Leading 0 digits shall not be used in decimal representations. + Generally, these are also not used in hexadecimal representations. + Exceptions are when an exact number of hex digits is expected, as in + the case of NSAP addresses. Parsers shall not reject leading zeros + in hex values. + + Both single-character and multi-character string values are enclosed + in double quotes (i.e., "). By contrast, single quotes (i.e., ') are + used for emphasizing keywords rather than to refer to characters or + strings. + + In the text representation of decimal and hex numbers, digits to the + left are more significant than digits to the right. + +2.3 Directionality Convention + + This section defined the meaning of the terms 'forward' and + 'backward' as used in this document. This is specially applicable to + parameters that have a specific direction associated with them. + + In this document, 'forward' refers to the direction away from the ATM + node under consideration, while 'backward' refers to the direction + towards the ATM node. This convention must be used in all SDP-based + session descriptions regardless of whether underlying bearer is an + SVC, a dynamically allocated PVC/SPVC or a dynamically allocated CID. + This is regardless of which side originates the service connection. + 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 provides a simple way of identifying the direction in which a + parameter is applicable, in a manner that is independent of the + underlying ATM or AAL2 bearer. This simplicity comes at a price, + described below. + + The convention used by all ATM/AAL2 signaling specifications (e.g., + Q.2931 Section 1.3.3 and Q.2630.1) mandates that forward direction is + from the end initiating setup/establishment via bearer signaling + towards the end receiving the setup/establishment request. The + backward direction is in the opposite direction. In some cases, the + 'forward' and 'backward' directions of the ATM signaling convention + + + +Kumar & Mostafa Standards Track [Page 6] + +RFC 3108 ATM SDP May 2001 + + + might be the exact opposite of the SDP convention described above, + requiring the media gateway to perform the necessary translation. An + example case in which this is needed is described below. + + Consider an SDP description sent by a media gateway controller to the + gateway 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 refers to the traffic descriptor (and hence + the PCR) in the direction away from this gateway as the forward + traffic descriptor and forward PCR. Clearly, this is at odds with + ATM SVC signaling which refers to this very PCR as the backward PCR. + The gateway needs to be able to perform the required swap of + directions. In this example, the media gateway terminating the + service level call (and hence originating the SVC call) does not need + to perform this swap. + + Certain parameters within attributes are defined exclusively for the + forward or backward directions. Examples for the forward direction + are the <fsssar> subparameter within the 'aal2sscs3661unassured' + media attribute line, the <fsssar>, <fsscopsdu> and <fsscopuu> + subparameters within the 'aal2sscs3661assured' media attribute line, + the <fsscopsdu> and <fsscopuu> subparameters within the 'aal5sscop' + media attribute line, and the <fmaxFrame> parameter within the + 'aal2sscs3662' media attribute line. Examples for the backward + direction are the <bsssar> subparameter within the + 'aal2sscs3661unassured' media attribute line, the <bsssar>, + <bsscopsdu> and <bsscopuu> subparameters within the + 'aal2sscs3661assured' media attribute line, the <bsscopsdu> and + <bsscopuu> subparameters within the 'aal5sscop' media attribute line, + and the <bmaxFrame> parameter within the 'aal2sscs3662' media + attribute line. + +2.4 Case convention + + As defined in RFC 2327 [1], SDP syntax is case-sensitive. Since + these ATM conventions conform strictly with SDP syntax, they are + case-sensitive. 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 is suggested, but not required, that + SDP parsers for ATM applications be case-tolerant where ignoring case + does not result in ambiguity. Encoding names, which are defined + outside the SDP protocol, are case-insensitive. + + + + + + + + + +Kumar & Mostafa Standards Track [Page 7] + +RFC 3108 ATM SDP May 2001 + + +2.5 Use of special characters in SDP parameter values + + In general, RFC 2327-conformant string values of SDP parameters [1] + do not include special characters that are neither alphabets nor + digits. An exception is the "/" character used in the value + "RTP/AVP" of transport sub-field of the 'm' line. + + String values used in SDP descriptions of ATM connections retain this + convention, while allowing the use of the special character "/" in a + manner commensurate with [1]. In addition, the special characters + "$" and "-" are used in the following manner. A "$" value is a + wildcard that allows the recipient of the SDP description to select + any permitted value of the parameter. A "-" value indicates that it + is not necessary to specify the value of the parameter in the SDP + description because this parameter is irrelevant for this + application, or because its value can be known from another source + such as provisioning, defaults, another protocol, another SDP + descriptor or another part of the same SDP descriptor. If the use of + these special characters is construed as a violation of RFC 2327 [1] + syntax, then reserved string values can be used. The string "CHOOSE" + can be used in lieu of "$". The string "OMIT" can be used in lieu 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 provide the following 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. + + + + +Kumar & Mostafa Standards Track [Page 8] + +RFC 3108 ATM SDP May 2001 + + + * 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. In order to + provide a common SDP base for applications based on Q.1901 and + SIP/SIP+, the neutral term 'eecid' is used in lieu 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 in determining the 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 + 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 + + The sequence of lines in the session descriptions in this document + conforms to RFC 2327 [1]. In general, a session description consists + of a session-level part followed by zero or more media-level parts. + ATM session descriptions consist of a session-level part followed by + one or two media-level parts. The only two media applicable are the + ATM bearer medium and RTCP control (where applicable). + + The session level part consists of the following lines: + + v= (protocol version, zero or one line) + o= (origin, zero or one line) + s= (session name, zero or one line) + + + +Kumar & Mostafa Standards Track [Page 9] + +RFC 3108 ATM SDP May 2001 + + + 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. These are present in the media-level parts. + + The media-level part for the ATM bearer consists of the following + 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 consists of the following + lines: + + m= (media information and transport address, one line) + c= (connection information for control only, one line) + + In general, the 'v', 'o', 's', and 't' lines are mandatory. However, + in the Megaco [26] context, these lines have been made optional. The + 'o', 's', and 't' lines are omitted in most MGCP [25] applications. + + Note that SDP session descriptors for ATM can contain bandwidth (b=) + and encryption key (k=) lines. Like all other lines, these lines + should strictly conform to the SDP standard [1]. + + The bandwidth (b=) line is not necessarily redundant in the ATM + context since, in some applications, it can be used to convey + application-level information which does not map directly into the + atmTrfcDesc media attribute line. For instance, the 'b' line can be + used in SDP descriptors in RTSP commands to describe content + bandwidth. + + The encryption key line (k=) can be used to indicate an encryption + key for the bearer, and a method to obtain the key. At present, the + encryption of ATM and AAL2 bearers has not been conventionalized, + unlike the encryption of RTP payloads. Nor has the authentication or + encryption of ATM or AAL2 bearer signaling. 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 in the + RFC 2327-conformant order depicted above. However, there is no order + of the media attribute ('a') lines with respect to other 'a' lines. + + + +Kumar & Mostafa Standards Track [Page 10] + +RFC 3108 ATM SDP May 2001 + + + The SDP protocol version for session descriptions using these + conventions is 0. In conformance 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 provided in sequence, in which case the 'v' line + serves as a delimiter. Depending on the application, sequences 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. It is possible that these lines might not carry useful + information in some ATM-based applications. Therefore, some + applications might omit these lines, although it is recommended that + they not do so. For maximum interoperability, it is preferable that + SDP parsers not reject session descriptions that do not contain these + lines. + +5. Structure of the Session Description Lines + +5.1 The Origin Line + + The origin line for an ATM-based session is structured as follows: + + 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 when 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 time stamps can be represented as decimal or hex integers. The + part of the NTP timestamp that refers to an integer number of seconds + is sufficient. This is a 32-bit field + + On the other hand, call IDs, connection IDs and context IDs can be + can be 32 hex digits long. + + + + +Kumar & Mostafa Standards Track [Page 11] + +RFC 3108 ATM SDP May 2001 + + + The <sessionID> field is represented as a decimal or hex number of up + to 32 digits. A "0x" prefix is used before the hex representation. + The <version> refers to the version of the SDP session descriptor + (not that of the SDP protocol). This is can be set to one of the + following: + + * 0. + * an NTP timestamp referring to the moment when the SDP session + descriptor was modified. If the SDP session descriptor has not + been modified by an intermediate entity (such as an MGC), then + the <version> timestamp will be the same as the <sessionId> + timestamp, if any. 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. This is 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 a "$" 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. These parameters should not me omitted + since this would violate SDP syntax [1]. + + As with the 'c' line, SDP parsers are not expected to check the + consistency of <networkType> with <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 as follows: + + s=<sessionName> + + For ATM-based sessions, the <sessionName> parameter is set to a "-". + The resulting line is: + + s=- + + + + + + + +Kumar & Mostafa Standards Track [Page 12] + +RFC 3108 ATM SDP May 2001 + + +5.3 The Connection Information Line + + In general, the connection information line [1] is structured as + follows: + + c=<networkType> <addressType> <address> + + For ATM networks, additional values of <networkType>, <addressType> + and <address> are defined, over and above those listed in [1]. The + ABNF syntax (Section 9) for ATM SDP does not limit the ways in which + <networkType> can be combined with <addressType>, <address> pairs. + However, some combinations will not be valid in certain applications, + while others will never be valid. Invalid combinations should be + rejected by application-specific functions, and not by generic + parsers. The ABNF syntax does limit the ways in which <addressType> + and <address> can be paired. + + For ATM networks, the value of <networkType> should be set to "ATM". + Further, this may be wildcarded to "$" or "-". If this is done, an + node using ATM as the basic transport mechanism will select a value + of "ATM". A node that interfaces with multiple network types ("IN", + "ATM" etc.) that include ATM can also choose a value of "ATM". + + When the SDP description is built by a node such as a media gateway, + the <address> refers to the address of the node building the SDP + description. When this description is forwarded to another node, it + still contains the original node's address. When the media gateway + controller builds part or all of the SDP description, the local + descriptor contains the address of the local node, while the remote + descriptor contains the address of the remote node. If the <address> + and/or <addressType> are irrelevant or are known by other means, they + can be set to a "$" or a "-", as described below. + + Additionally, in all contexts, the 'm' line can have an ATM address + in the <virtualConnectionId> subparameter which, if present, is the + remote address if the 'c' line address is local, and vice versa. + + For ATM networks, the <addressType> can be NSAP, E164 or GWID + (ALIAS). For ATM networks, the <address> syntax depends on the + syntax of the <addressType>. SDP parsers should check the + consistency of <addressType> with <address>. + + NSAP: If the addressType is NSAP, the address is expressed in the + standard dotted hex form. This is 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 of the NSAP address is the 'selector' + field that is available for non-standard use. An example of a line + with an NSAP address is: + + + +Kumar & Mostafa Standards Track [Page 13] + +RFC 3108 ATM SDP May 2001 + + + c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 + + A "0x" prefix shall not be used in this case since this is always in + hexadecimal format. + + E164: If the addressType is E164, the address is expressed as a + decimal number with up to 15 digits. For example: + + c=ATM E164 9738294382 + + The use of E.164 numbers in the B-ISDN context is defined in ITU + E.191. There is a disparity between the ATM forum and the ITU in the + use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI + Signaling 4.0) allows only International Format E.164 numbers, while + the ITU (e.g., Q.2931) allows private numbering plans. Since the + goal of this SDP specification is to interoperate with all bearer + signaling protocols, it allows the use of numbers that do not conform + to the E.164 International Format. However, to maximize overall + consistency, network administrators can restrict the provisioning of + numbers to the E.164 International Format. + + GWID (ALIAS): If the addressType is GWID, it means that the address + is a Gateway Identifier or Node Alias. This may or may not be + globally unique. In this format, the address is expressed as an + alphanumeric string ("A"-"Z", "a"-"z", "0" - "9",".","-","_"). For + example: + + c=ATM GWID officeABCmgx101vism12 + + Since these SDP conventions can be used for more than gateways, the + string "ALIAS" can be used instead of "GWID" in the 'c' line. Thus, + the example above is equivalent to: + + c=ATM ALIAS officeABCmgx101vism12 + + An example of a GWID (ALIAS)is the CLLI code used for telecom + equipment. For all practical purposes, it should be adequate for the + GWID (ALIAS) to be a variable length string with a maximum size of 32 + characters. + + The connection information line is always present in an SDP session + descriptor. However, each of the parameters on this line can be + wildcarded to a "$" or a "-", independently of whether other + parameters on this line are wildcarded or not. Not all syntactically + legal wildcard combinations are meaningful in a particular + application. + + + + + +Kumar & Mostafa Standards Track [Page 14] + +RFC 3108 ATM SDP May 2001 + + + Examples of meaningful wildcard combinations in the ATM context are: + + c=- - - + c=$ $ $ + c=ATM - - + c=ATM $ $ + c=ATM <addressType> - + c=ATM <addressType> $ + + Specifying the ATM address type without specifying the ATM address is + useful when the recipient is asked to select an ATM address of a + certain type (NSAP, E.164 etc.). + + Examples of syntactically legal wildcard combinations of dubious + utility are: + + c=- $ - + c=- $ $ + c=- <addressType> - + c=$ <addressType> $ + c=- <addressType> <address> + c=$ <addressType> <address> + + Note that <addressType> and/or <address> should not omitted without + being set to a "-" or "$" since this would violate basic SDP syntax + [1]. + +5.4 The Timestamp Line + + The timestamp line for an SDP session descriptor is structured as + follows: + + 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, the <startTime>parameter can be + made equal to the NTP timestamp referring to the moment when the SDP + session descriptor was created. It can also be set to 0 indicating + its irrelevance. If it made equal to the NTP timestamp in seconds, + the fractional part of the NTP timestamp is omitted. When equated to + the integer part of an NTP timestamp, the <startTime> field is 10 + digits wide. This is 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 <stopTime> parameter is set to 0 for ATM-based SDP descriptors. + + + + +Kumar & Mostafa Standards Track [Page 15] + +RFC 3108 ATM SDP May 2001 + + +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]. + These are: "audio", "video", "application", "data" and "control". + + When the <transport> parameter 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 + + In applications in which the media-level part of a session descriptor + is bound to an ATM virtual circuit, the <virtualConnectionId> can be + in one of the following 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> + + In applications in which the media-level part of a session descriptor + is bound to a subchannel within an ATM virtual circuit, the + <virtualConnectionId> can be in one of the following formats: + + * <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> + + + +Kumar & Mostafa Standards Track [Page 16] + +RFC 3108 ATM SDP May 2001 + + + * <ex_vpci>/<ex_vci>/<ex_cid> + * <addressType>-<address>/<ex_vpci>/<ex_vci>/<ex_cid> + * <address>/<ex_vpci>/<ex_vci>/<ex_cid> + + Here, + + <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. An "0x" prefix is used before their values when + they are in the hex format. + + The <portId> is always a hexadecimal number. An "0x" prefix is not + used with it. + + The <addressType> and <address> are identical to their definitions + above for the connection information line with the difference that + this address refers to the remote peer in the media information line. + Since the <virtualConnectionId>, as defined here, is meant for use in + ATM networks, the values of <addressType> and <address> in the + <virtualConnectionId> 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]. The <vpci> is similar to the <vpi>, except for its width + and the fact that it retains 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 this 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]. The <vcci> is similar to the <vci>, except for the fact that + it retains its value across VC crossconnects. + + In general, <vpci> and <vcci> values are unique between a pair of + nodes. When they are unique between a pair of nodes but not unique + within a network, they need to be qualified, at any node, by the ATM + + + +Kumar & Mostafa Standards Track [Page 17] + +RFC 3108 ATM SDP May 2001 + + + address of the remote node. These parameters can be pre-provisioned + or signaled. When signaled, the <vpci> is encapsulated in the + connection identifier information element of SVC signaling messages. + The <vcci> is 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 it to the other end + via SVC signaling. A glare avoidance scheme is defined in [32] and + [44]. This mechanism works in SVC applications. A different glare + avoidance technique is needed when a pool of existing PVCs/SPVCs is + dynamically assigned to calls. One such scheme for glare reduction + is the assignment of <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 this + case, the ATM address of the far end is not needed to qualify these + parameters. + + In the AAL2 context, the definition of a VCC implies that there is no + CID-level switching between its ends. If either end can assign <cid> + values, then a glare reduction mechanism is needed. One such scheme + for glare reduction is the assignment of <cid> values from different + ends of the <cid> range, using the lowest or highest available value + as applicable. + + The <portId> parameter is used to identify 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 is meaningful 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 allows the bundling of + up to 255 VPCs or VCCs. + + In some applications, it is necessary to wildcard the + <virtualConnectionId> parameter, or some elements of this parameter. + The "$" wildcard character can be substituted for the entire + <virtualConnectionId> parameter, or some of its terms. In the latter + case, the constant strings that qualify the terms in the + <virtualConnectionId> are retained. The concatenation + <addressType>-<address> can be wildcarded in the following ways: + + * The entire concatenation, <addressType>-<address>, is replaced + with a "$". + * <address> is replaced with a "$", but <addressType> is not. + + + + + + +Kumar & Mostafa Standards Track [Page 18] + +RFC 3108 ATM SDP May 2001 + + + 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 is also permissible to set the entire <virtualConnectionId> + parameter to a "-" indicating its irrelevance. + +5.5.2 The Transport Parameter + + The <transport> parameter indicates the method used to encapsulate + the service payload. These methods are not defined in this document, + which refers to existing ATMF and ITU-T standards, which, in turn, + might refer to other standards. For ATM applications, the following + <transport> values are defined: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kumar & Mostafa Standards Track [Page 19] + +RFC 3108 ATM SDP May 2001 + + + 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 has a + value of "RTP/AVP". This is because these applications use the RTP + protocol [2] and audio/video profile [3]. The fact that RTP is + carried directly over AAL5 per [45] can be indicated explicitly via + the aalApp media attribute. + + A value of "AAL1/custom", "AAL2/custom" or "AAL5/custom" for the + <transport> parameter can indicate non-standard or semi-standard + encapsulation schemes defined by a corporation or a multi-vendor + agreement. Since there is no standard administration of this + convention, care should be taken to preclude inconsistencies within + the scope of a deployment. + + + + + +Kumar & Mostafa Standards Track [Page 20] + +RFC 3108 ATM SDP May 2001 + + + The use of <transport> values "AAL1/<corporateName>", + "AAL2/<corporateName>", "AAL5/<corporateName>", "AAL1/IEEE:<oui>", + "AAL2/IEEE:<oui>" and "AAL5/IEEE:<oui>" is similar. These indicate + non-standard transport mechanisms or AAL2 profiles which should be + used consistently within the scope of an application or deployment. + The parameter <corporateName> is the registered, globally unique name + of a corporation (e.g., Cisco, Telcordia etc.). The parameter <oui> + is the hex representation of a three-octet field identical to the OUI + maintained by the IEEE. Since this is always represented 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 ordering of payload types + implies a preference (preferred payload types before less favored + ones). The payload type can be statically assigned or dynamically + mapped. Although the transport is not the same, SDP in the ATM + context leverages the encoding names and payload types registered + with IANA [31] for RTP. Encoding names not listed in [31] use a "X-" + prefix. Encodings that are not statically mapped to payload types in + [31] are to be dynamically mapped at the time of connection + establishment to payload types in the decimal range 96-127. The SDP + 'atmmap' attribute (similar to 'rtpmap') is used for this purpose. + + In addition to listing 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 ordering of profiles implies a preference + (preferred profiles before less favored ones). The <profile> + parameter is expressed as a decimal number in the range 1-255. + + + + + + + +Kumar & Mostafa Standards Track [Page 21] + +RFC 3108 ATM SDP May 2001 + + +5.5.5 Media information line construction + + Using the parameter definitions above, the 'm' for AAL1-based audio + media can be constructed as follows: + + m=audio <virtualConnectionId> AAL1/ATMF <payloadType#1> + <payloadType#2>...<payloadType #n> + + Note that only those payload types, whether statically mapped or + dynamically assigned, that are consistent with af-vtoa-78 [7] can be + used in this construction. + + Backwards compatibility note: The transport value "AAL1/AVP" used in + previous versions of this document should be considered equivalent to + the value "AAL1/ATMF" defined above. "AAL1/AVP" is unsuitable + because the AVP profile is closely tied to RTP. + + An example 'm' line use for audio media over AAL1 is: + + m=audio VCCI-27 AAL1/ATMF 0 + + This indicates the use of an AAL1 VCC with VCCI=24 to carry PCMU + audio that is encapsulated according to ATMF's af-vtoa-78 [7]. + + Another example of the use of the 'm' line use for audio media over + AAL1 is: + + m=audio $ AAL1/ATMF 0 8 + + This indicates that any AAL1 VCC may be used. If it exists already, + then its selection is subject to glare rules. The audio media on + this VCC is encapsulated according to ATMF's af-vtoa-78 [7]. The + encodings to be used are either PCMU or PCMA, in preferential order. + + The 'm' for AAL5-based audio media can be constructed as follows: + + m=audio <virtualConnectionId> AAL5/ATMF <payloadType#1> + <payloadType#2>...<payloadType #n> + + An example 'm' line use for audio media over AAL5 is: + + m=audio PORT-2/VPI-6/$ AAL5/ITU 9 15 + + 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 media on this VCC is encapsulated + according to ITU-T H.222.1 [51]. The encodings to be used are either + ITU-T G.722 or ITU-T G.728 (LD-CELP), in preferential order. + + + +Kumar & Mostafa Standards Track [Page 22] + +RFC 3108 ATM SDP May 2001 + + + The 'm' for AAL5-based H.323 Annex C audio [45] can be constructed as + follows: + + m=audio <virtualConnectionId> RTP/AVP <payloadType#1> + <payloadType#2>...<payloadType #n> + + For example: + + m=audio PORT-9/VPI-3/VCI-$ RTP/AVP 2 96 + a=rtpmap:96 X-G727-32 + a=aalType:AAL5 + a=aalApp:itu_h323c - - + + 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' + (rather than the 'atmmap') attribute is used to dynamically map the + payload type of 96 into the codec name X-G727-32 (Table 2). This + name represents 32 kbps EADPCM. + + The 'm' line for AAL5-based video media can be constructed as + follows: + + m=video <virtualConnectionId> AAL5/ITU <payloadType#1> + <payloadType#2>...<payloadType #n> + + In this case, the use of AAL5/ITU as the transport points to H.222.1 + as the controlling standard [51]. An example 'm' line use for video + media is: + + m=video PORT-9/VPI-3/VCI-$ AAL5/ITU 33 + + This indicates that any VCI on VPI= 3 of trunk port #9 may be used. + The video media 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). This is statically mapped per [31] to a payload + type of 33. + + Using the parameter definitions in the previous subsections, the + media information line for AAL2-based audio media can be constructed + as follows: + +m=<media> <virtualConnectionId> <transport#1> <format list#1> + <transport#2> <format list#2> ... <transport#M> <format list#M> + + where <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, each + followed by a <format list>. This is because it is possible to + + + +Kumar & Mostafa Standards Track [Page 23] + +RFC 3108 ATM SDP May 2001 + + + consider definitions from multiple sources (ATMF, ITU and non- + standard documents) when selecting AAL2 profile to be bound to a + connection. + + In most applications, the ordering of profiles implies a preference + (preferred profiles before less favored ones). Therefore, there can + be multiple instances of the same <transport> value in the same 'm' + line. + + An example 'm' line use for audio media over AAL2 is: + + m=audio VCCI-27/CID-19 AAL2/ITU 7 AAL2/custom 100 AAL2/ITU 1 + + This indicates the use of CID #19 on VCCI #27 to carry audio. It + provides a preferential list of profiles for this connection: profile + AAL2/ITU 7 defined in [13], AAL2/custom 100 defined in an + application-specific or interoperability document and profile + AAL2/ITU 1 defined in [13]. + + Another example of the use of the 'm' line use for audio media over + AAL2 is: + + m=audio VCCI-$/CID-$ AAL2/ATMF 6 8 + + This indicates that any AAL2 CID may be used, subject to any + applicable glare avoidance/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. The profiles they define + fall under the <transport> category "AAL2/ATMF". This application + does not order profiles preferentially. This rule is known a priori. + It is not embedded in the 'm' line. + + Another example of the use of the 'm' line use for audio media over + AAL2 is: + + m=audio VCCI-20/CID-$ AAL2/xyzCorporation 11 + + AAL2 VCCs in this application are single-CID VCCs. Therefore, it is + possible to wildcard the CID. The single-CID VCC with VCCI=20 is + selected. The AAL2 profile to be used is AAL2/xyzCorporation 11 + defined by xyzCorporation. + + In some applications, an "-" can be used in lieu of: + + - <format list> + - <transport> and <format list> + + + + +Kumar & Mostafa Standards Track [Page 24] + +RFC 3108 ATM SDP May 2001 + + + This implies that these parameters are irrelevant or are known by + other means (such as defaults). For example: + + m=audio VCCI-234 - - + a=aalType:AAL1 + + indicates the use of VCCI=234 with AAL1 adaptation and unspecified + encoding. + + In another example application, the 'aal2sscs3662' attribute can + indicate <faxDemod> = "on" and any other competing options as "off", + and the <aalType> attribute can indicate AAL2. Thus: + + 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 adaptation layer of AAL2, and the use of the audio SAP + [13] to carry demodulated facsimile. + + The media information line for "data" media has one of the following + 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, rather than + the 'm' line, are used to indicate the adaptation type for the data + media. Examples of the representation of data media are listed + below. + + m=data PORT-7/VPI-6/VCI-$ - - + a=aalApp:AAL5_SSCOP- - + + 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:6 + + implies that VCI 50 on VPI 6 on port 7 uses structured AAL1 to + transfer 6 x 64 kbps circuit emulation data. This may be alternately + represented as: + + + + +Kumar & Mostafa Standards Track [Page 25] + +RFC 3108 ATM SDP May 2001 + + + m=data PORT-7/VPI-6/VCI-50 - - + b=AS:384 + a=aalType:AAL1_SDT + + The following lines: + + m=data VCCI-123/CID-5 - - + a=aalType:AAL2 + a=sbc:2 + + imply that CID 5 of VCCI 123 is used to transfer 2 x 64 kbps circuit + emulation data. + + In the AAL1 context, it is also permissible to represent circuit mode + data as an "audio" codec. If this is done, the codec types used are + X-CCD or X-CCD-CAS. These encoding names are 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:6 + + 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 it is not possible to construct a profile + table as described in ITU I.366.2 for this "codec", it is preferable + to adopt the common AAL2 profile convention in its case. An example + AAL2 profile mapping for the X-CCD codec could be as follows: + + PROFILE TYPE PROFILE NUMBER "CODEC" (ONLY ONE) + "custom" 200 X-CCD + + The profile does not identify the number of subchannels ('n' in + nx64). This is known by other means such as the 'sbc' media + attribute line. + + For example, the media information line: + + m=audio $ AAL2/custom 200 + a=sbc:6 + + implies 384 kbps circuit emulation using AAL2 adaptation. + + It is not necessary to define a profile with the X-CCD-CAS codec, + since this method of CAS transport [7] is not used in AAL2 + applications. + + + + +Kumar & Mostafa Standards Track [Page 26] + +RFC 3108 ATM SDP May 2001 + + +5.6 The Media Attribute Lines + + In an SDP line sequence, the media information line 'm' is followed + by one or more media attribute or 'a' lines. Media attribute lines + are per the format below: + + a=<attribute>:<value> + + or + + a=<value> + + In general, media attribute lines are optional except when needed to + qualify the media information line. This qualification is necessary + when the "m" line for an AAL1 or AAL5 session specifies a payload + type that needs to be dynamically mapped. The 'atmmap' media + attribute line defined below is used for this purpose. + + In attribute lines, subparameters that are meant to be left + unspecified are set to a "-". These are generally inapplicable or, + if applicable, are known by other means such as provisioning. In + some cases, a media attribute line with all parameters set to "-" + carries no information and should be preferably omitted. In other + cases, such as the 'lij' media attribute line, the very presence of + the media attribute line conveys meaning. + + There are no restrictions placed by RFC 2327 [1] regarding the order + of 'a' lines with respect 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 + information. These 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 specification for SDP, RFC 2327 [1], allows the definition f + new attributes. In keeping with this spirit, some of the attributes + defined in this document can also be used in SDP descriptions of IP + nd other non-ATM sessions. For example, the 'vsel', 'dsel' and + 'fsel' attributes defined below refer generically to codec-s. These + can be bed for service-specific codec negotiation and assignment in + non-ATM s well as ATM applications. + + SDP media attributes defined in this document for use in the ATM + context are classified as: + + + + +Kumar & Mostafa Standards Track [Page 27] + +RFC 3108 ATM SDP May 2001 + + + * 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 + + The following is a summary list of the SDP media attributes that can + be used to describe ATM bearer connections. These are detailed in + subsequent subsections. + + * 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. + + + + +Kumar & Mostafa Standards Track [Page 28] + +RFC 3108 ATM SDP May 2001 + + + * 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]. + + + + + + +Kumar & Mostafa Standards Track [Page 29] + +RFC 3108 ATM SDP May 2001 + + +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. The term '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. + + While the term 'bnc-id' might be used in the bearer signaling plane + and in an ISUP (Q.1901) call control plane, SDP session descriptors + use the neutral term 'eecid'. This provides 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 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 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 values needs to be unique within the + node terminating the SVC set-up but not across multiple nodes. + Hence, 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. + + + +Kumar & Mostafa Standards Track [Page 30] + +RFC 3108 ATM SDP May 2001 + + + 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). This + is a task of 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> + + + + + + + +Kumar & Mostafa Standards Track [Page 31] + +RFC 3108 ATM SDP May 2001 + + + 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 + + When present, the 'capability' attribute indicates the ATM Transfer + Capability described in ITU I.371 [28], equivalent to the ATM Service + Category described in the UNI 4.1 Traffic Management specification + [6]. + + The 'capability' media attribute line is structured in one of the + following ways: + + a=capability:<asc> <subtype> + + a=capability:<atc> <subtype> + + Possible values of the <asc> are enumerated below: + + "CBR", "nrt-VBR", "rt-VBR", "UBR", "ABR", "GFR" + + Possible values of the <atc> are enumerated below: + + "DBR","SBR","ABT/IT","ABT/DT","ABR" + + Some applications might use non-standard <atc> and <asc> values not + listed above. Equipment designers will need to agree on the meaning + and implications of non-standard transfer capabilities / service + capabilities. + + The <subtype> field essentially serves as a subscript to the <asc> + and <atc> fields. In general, it can take on any integer value, or + the "-" value indicating that it does not apply or that the + underlying data is to be known by other means, such as provisioning. + + For an <asc> value of CBR and an <atc> value of DBR, the <subtype> + field can be assigned values from Table 4-6 of ITU Q.2931 [15]. + These are: + + + + + + + + + + + +Kumar & Mostafa Standards Track [Page 32] + +RFC 3108 ATM SDP May 2001 + + + <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 values of the <asc> and <atc> parameters, the following + values can be assigned to the <subtype> field, 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 SBR3 + + It is beyond the scope of this specification to examine the + equivalence of some of the ATMF and ITU definitions. These need to + be recognized from the ATMF and ITU source specifications and + exploited, as much as possible, to simplify ATM node design. + + When the bearer connection is a single AAL2 CID connection within a + multiplexed AAL2 VC, the 'capability' attribute does not apply. + +5.6.1.4 The 'qosClass' attribute + + When present, the 'qosClass' attribute indicates the QoS class + specified in ITU I.2965.1 [34]. + + The 'qosClass' media attribute line is structured as follows: + + a=qosClass:<qosClass> + + Here, <qosClass> is an integer in the range 0 - 5. + + + +Kumar & Mostafa Standards Track [Page 33] + +RFC 3108 ATM SDP May 2001 + + + <qosClass> Meaning + + 0 Default QoS + 1 Stringent + 2 Tolerant + 3 Bi-level + 4 Unbounded + 5 Stringent bi-level + +5.6.1.5 The 'bcob' attribute + + When present, the 'bcob' attribute represents the broadband + connection oriented bearer class defined in [5], [15] and [33]. It + can also be used to indicate whether end-to-end timing is required. + + The 'bcob' media attribute line is structured as follows: + + a=bcob:<bcob> <eetim> + + Here, <bcob> is the decimal or hex representation of a 5-bit field. + The following values are currently defined: + + <bcob> Meaning + + 0x01 BCOB-A + 0x03 BCOB-C + 0x05 Frame relaying bearer service + 0x10 BCOB-X + 0x18 BCOB-VP (transparent VP service) + + The <eetim> parameter can be assigned a value of "on" or "off" + depending on whether end-to-end timing is required or not (Table 4-8 + of [15]). + + Either of these parameters can be left unspecified by setting it to a + "-". A 'bcob' media attribute line with all parameters set to "-" + carries no information and should be omitted. + +5.6.1.6 The 'stc' attribute + + When present, the 'stc' attribute represents susceptibility to + clipping. The 'stc' media attribute line is structured as follows: + + a=stc:<stc> + + Here, <stc> is the decimal equivalent of a 2-bit field. Currently, + all values are unused and reserved with the following exceptions: + + + + +Kumar & Mostafa Standards Track [Page 34] + +RFC 3108 ATM SDP May 2001 + + + <stc> value Binary Equivalent Meaning + + 0 00 Not susceptible to clipping + 1 01 Susceptible to clipping + +5.6.1.7 The 'upcc' attribute + + When present, the 'upcc' attribute represents the user plane + connection configuration. The 'upcc' media attribute line is + structured as follows: + + a=upcc:<upcc> + + Here, <upcc> is the decimal equivalent of a 2-bit field. Currently, + all values are unused and reserved with the following exceptions: + + <upcc> value Binary Equivalent Meaning + + 0 00 Point to point + 1 01 Point to multipoint + +5.6.1.8 The 'atmQOSparms' attribute + + When present, the 'atmQOSparms' attribute is used to describe certain + key ATM QoS parameters. + + The 'atmQOSparms' media attribute line is structured as follows: + + a=atmQOSparms:<directionFlag><cdvType><acdv><ccdv><eetd><cmtd><aclr> + + The <directionFlag> can be assigned the following string values: "f", + "b" and "fb". "f" and "b" indicate the forward and backward + directions respectively. "fb" refers to both directions (forward and + backward). Conventions for the forward and backward directions are + per section 2.3. + + The <cdvType> parameter can take on the string values of "PP" and + "2P". These refer to the peak-to-peak and two-point CDV as defined + in UNI 4.0 [5] and ITU Q.2965.2 [35] respectively. + + The CDV parameters, <acdv> and <ccdv>, refer to the acceptable and + cumulative CDVs respectively. These are expressed in units of + microseconds and represented as the decimal equivalent of a 24-bit + field. These use the cell loss ratio, <aclr>, as the "alpha" + quantiles defined in the ATMF TM 4.1 specification [6] and in ITU + I.356 [47]. + + + + + +Kumar & Mostafa Standards Track [Page 35] + +RFC 3108 ATM SDP May 2001 + + + The transit delay parameters, <eetd> and <cmtd>, refer to the end- + to-end and cumulative transit delays respectively in milliseconds. + These are represented as the decimal equivalents of 16-bit fields. + These parameters are defined in Q.2965.2 [35], UNI 4.0 [5] and Q.2931 + [15]. + + The <aclr> parameter refers to forward and backward acceptable cell + loss ratios. This is the ratio between the number of cells lost and + the number of cells transmitted. It is expressed as the decimal + equivalent of an 8-bit field. This field expresses an order of + magnitude n, where n is an integer in the range 1-15. The Cell Loss + Ratio takes on the value 10 raised to the power of minus n. + + The <directionFlag> is always specified. Except for the + <directionFlag>, the remaining parameters can be set to "-" to + indicate that they are not specified, inapplicable or implied. + However, there must be some specified parameters for the line to be + useful in an SDP description. + + There can be several 'atmQOSparms' lines in an SDP description. + + An example use of these attributes for an rt-VBR, single-CID AAL2 + voice VC is: + + a=atmQOSparms:f PP 8125 3455 32000 - 11 + a=atmQOSparms:b PP 4675 2155 18000 - 12 + + This 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. + + An example of specifying the same parameters for the forward and + backward directions is: + + a=atmQOSparms:fb PP 8125 3455 32000 - 11 + + This 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. + + + + +Kumar & Mostafa Standards Track [Page 36] + +RFC 3108 ATM SDP May 2001 + + +5.6.1.9 The 'atmTrfcDesc' attribute + + When present, the 'atmTrfcDesc' attribute is used to indicate ATM + traffic descriptor parameters. There can be several 'atmTrfcDesc' + lines in an SDP description. + + The 'atmTrfcDesc' media attribute line is structured as follows: + + a=atmTrfcDesc:<directionFlag><clpLvl> + <pcr><scr><mbs><cdvt><mcr><mfs><fd><te> + + The <directionFlag> can be assigned the following string values: "f", + "b" and "fb". "f" and "b" indicate the forward and backward + directions respectively. "fb" refers to both directions (forward and + backward). Conventions for the forward and backward directions are + per section 2.3. + + The <directionFlag> is always specified. Except for the + <directionFlag>, the remaining parameters can be set to "-" to + indicate that they are not specified, inapplicable or implied. + However, there must be some specified parameters for the line to be + useful in an SDP description. + + The <clpLvl> (CLP level) parameter indicates whether the rates and + bursts described in these media attribute lines apply to CLP values + of 0 or (0+1). It can take on the following string values: "0", + "0+1" and "-". If rates and bursts for both <clpLvl> values are to + be described, then it is necessary to use two separate media + attribute lines for each direction in the same session descriptor. + If the <clpLvl> parameter is set to "-", then it implies that the CLP + parameter is known by other means such as default, MIB provisioning + etc. + + The meaning, units and applicability of the remaining parameters are + per [6] and [28]: + + 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 + + + +Kumar & Mostafa Standards Track [Page 37] + +RFC 3108 ATM SDP May 2001 + + + <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> indicates that frame discard is permitted. It can take on the + string values of "on" or "off". Note that, in the GFR case, frame + discard is always enabled. Hence, this subparameter can be set to + "-" in the case of GFR. Since the <fd> parameter is independent of + CLP, it is meaningful in the case when <clpLvl> = "0+1". It should + be set to "-" for the case when <clpLvl> = "0". + + <te> (tag enable) indicates that CLP tagging is allowed. These can + take on the string values of "on" or "off". Since the <te> parameter + applies only to cells with a CLP of 0, it is meaningful in the case + when <clpLvl> = "0". It should be set to "-" for the case when + <clpLvl> = "0+1". + + An example use of these media attribute lines for an rt-VBR, single- + CID AAL2 voice VC is: + + 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 - - - - off + + This implies a forward and backward PCR of 200 cells per second all + cells regardless of CLP, forward and backward PCR of 200 cells per + second for cells with CLP=0, a forward and backward SCR of 100 cells + per second for all cells regardless of CLP, a forward and backward + SCR of 80 cells per second for cells with CLP=0, a forward and + backward MBS of 20 cells for all cells regardless of CLP, a forward + + + +Kumar & Mostafa Standards Track [Page 38] + +RFC 3108 ATM SDP May 2001 + + + and backward MBS of 15 cells for cells with CLP=0, an unspecified + CDVT which can be known by other means, and an MCR and MFS which are + unspecified because they are inapplicable. Frame discard is enabled + in both the forward and backward directions. Tagging is not enabled + in either direction. + + The <pcr>, <scr>, <mbs>, <cdvt>, <mcr> and <mfs> are represented as + decimal integers, with range as defined in Section 6. See section + 2.2 regarding the omission of leading zeros in decimal + representations. + +5.6.1.10 The 'abrParms' attribute + + When present, the 'abrParms' attribute is used to indicate the ' + additional' ABR parameters specified in the UNI 4.0 signaling + specification [5]. There can be several 'abrParms' lines in an SDP + description. + + The 'abrParms' media attribute line is structured as follows: + + a=abrParms:<directionFlag><nrm><trm><cdf><adtf> + + The <directionFlag> can be assigned the following string values: "f", + "b" and "fb". "f" and "b" indicate the forward and backward + directions respectively. "fb" refers to both directions (forward and + backward). Conventions for the forward and backward directions are + per section 2.3. + + The <directionFlag> is always specified. Except for the + <directionFlag>, the remaining parameters can be set to "-" to + indicate that they are not specified, inapplicable or implied. + However, there must be some specified parameters for the line to be + useful in an SDP description. + + These parameters are mapped into the ABR service parameters in [6] in + the manner described below. These parameters can be represented in + SDP as decimal integers, with fractions permitted for some. Details + of the meaning, units and applicability of these parameters are in + [5] and [6]. + + In SDP, these parameters are represented as the decimal or hex + equivalent of the binary fields mentioned below. + + + + + + + + + +Kumar & Mostafa Standards Track [Page 39] + +RFC 3108 ATM SDP May 2001 + + ++-----------+----------------------------------+-----------------------+ +| 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 present, the 'abrSetup' attribute is used to indicate the ABR + parameters needed during call/connection establishment (Section + 10.1.2.2 of the UNI 4.0 signaling specification [5]). This line is + structured as follows: + + a=abrSetup:<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf> + + These parameters are defined as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + +Kumar & Mostafa Standards Track [Page 40] + +RFC 3108 ATM SDP May 2001 + + ++-----------+----------------------------------+-----------------------+ +| 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 | ++-----------+----------------------------------+-----------------------+ + + See Section 2.3 for a definition of the terms 'forward' and + 'backward'. + + If any of these parameters in the 'abrSetup' media attribute line is + not specified, is inapplicable or is implied, then it is set to h "- + ". + +5.6.1.12 The 'bearerType' attribute + + When present, the 'bearerType' attribute 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. Additionally, for ATM SVCs and + AAL2 CID connections, the 'bearerType' attribute can be used to + indicate whether the media gateway initiates connection set-up via + bearer signaling (Q.2931-based or Q.2630.1 based). The format of the + 'bearerType' media attribute line is as follows: + + + + +Kumar & Mostafa Standards Track [Page 41] + +RFC 3108 ATM SDP May 2001 + + + a=bearerType: <bearerType> <localInitiation> + + The <bearerType> field can take on the following string values: + + "PVC", "SVC", "CID", with semantics as defined above. Here, "PVC" + includes both the PVC and SPVC cases. + + In the case when the underlying bearer is a PVC/SPVC, or a CID + assigned by the MGC rather than through bearer signaling, the + <localInitiation> flag can be omitted or set to "-". In the case + when bearer signaling is used, this flag can be omitted when it is + known by default or by other means whether the media gateway + initiates the connection set-up via bearer signaling. Only when this + is to be indicated explicitly that the <localInitiation> flag takes + on the values of "on" or "off". An "on" value indicates that the + media gateway is responsible for initiating connection set-up via + bearer signaling (SVC signaling or Q.2630.1 signaling), an "off" + value indicates otherwise. + +5.6.1.13 The 'lij' attribute + + When present, the 'lij' attribute 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 format of the 'lij' media attribute line is as + follows: + + a=lij: <sci><lsn> + + The <sci> (screening indication) is a 4-bit field expressed as a + decimal or hex integer. It is defined in the UNI 4.0 signaling + specification [5]. It is possible that the values of this field will + be defined later by the ATMF and/or ITU. Currently, all values are + reserved with the exception of 0, which indicates a 'Network Join + without Root Notification'. + + The <lsn> (leaf sequence number) is a 32-bit field expressed as a + decimal or hex integer. Per the UNI 4.0 signaling specification [5], + it is used by a joining leaf to associate messages and responses + during LIJ (leaf initiated join) procedures. + + Each of these fields can be set to a "-" when the intention is to not + specify them in an SDP descriptor. + + + + + + + + +Kumar & Mostafa Standards Track [Page 42] + +RFC 3108 ATM SDP May 2001 + + +5.6.1.14 The 'anycast' attribute + + When present, the 'anycast' attribute line is used to indicate the + applicability of the anycast function described in UNI 4.0 [5]. + Optional parameters to qualify this function are provided. The format + of the 'anycast' attribute is: + + a=anycast: <atmGroupAddress> <cdStd> <conScpTyp> <conScpSel> + + The <atmGroupAddress> is per Annex 5 of UNI 4.0 [5]. Within an SDP + descriptor, it can be represented in one 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]. Their meaning and representation + is as shown below: + + 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 bits + + Currently, all values of <cdStd> and <conScpTyp> are reserved with + the exception of <cdStd> = 3 (ATMF coding standard) and <conScpTyp> = + 1 (connection scope type of 'organizational'). + + Each of these fields can be set to a "-" when the intention is to not + specify them in an SDP descriptor. + +5.6.1.15 The 'cache' attribute + + This attribute is used to enable SVC caching. This attribute has the + following format: + + a=cache:<cacheEnable><cacheTimer> + + + + + + + +Kumar & Mostafa Standards Track [Page 43] + +RFC 3108 ATM SDP May 2001 + + + The <cacheEnable> flag indicates whether caching is enabled or not, + corresponding to the string values of "on" and "off" respectively. + + The <cacheTimer> indicates the period of inactivity following which + the SVC is to be released by sending an SVC release message into the + network. This is specified as the decimal or hex equivalent of a + 32-bit field, indicating the timeout in seconds. As usual, leading + zeros can be omitted. For instance, + + a=cache:on 7200 + + implies that the cached SVC is to be deleted if it is idle for 2 + hours. + + The <cacheTimer> can be set to "-" if it is inapplicable or implied. + +5.6.1.16 The 'bearerSigIE' attribute + + ATM signaling standards provide 'escape mechanisms' to 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 is + defined to allow a similar escape mechanism that can be used with + these ATM SDP conventions. The format of this media attribute line + is as follows: + + a=bearerSigIE: <bearerSigIEType> <bearerSigIELng> <bearerSigIEVal> + + When an 'bearerSigIE' media attribute line is present, all its + subparameters are mandatory. The "0x" prefix is not used since these + are always represented in hex. + + The <bearerSigIEType> is represented as exactly 2 hex digits. It is + the unique IE identifier as defined in the ITU Q-series standards. + Leading zeros are not omitted. 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, which stand for Broadband Low-layer Information and + Broadband High-layer Information respectively, are defined in ITU + Q.2931 [15]. Both of these refer to layers above the ATM adaptation + layer. + + The <bearerSigIELng> consists of 1-4 hex digits. It is the length of + the information element in octets. Leading zeros may be omitted. + + + + + + +Kumar & Mostafa Standards Track [Page 44] + +RFC 3108 ATM SDP May 2001 + + + The <bearerSigIEVal> is the value of the information element, + represented as a hexadecimal bit map. Although the size of this bit + map is network/ service dependent, setting an upper bound of 256 + octets (512 hex digits) is adequate. Since this 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 + + The following is a summary list of the SDP media attributes that can + be used to describe the ATM Adaptation Layer (AAL). These are + detailed in subsequent subsections. + + * The 'aalApp' attribute, which is used to point 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 in the + case of 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 indicate the fill level + of partially filled cells. + + * The 'structure' attribute, which is used to indicate the + presence or absence of AAL1 structured data transfer (SDT), and + the size of the SDT blocks. + + * The 'cpsSDUsize' attribute, which is used to indicate the + maximum size of the CPCS SDU payload. + + * The 'aal2CPS' attribute, which is used to indicate 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 be + used to indicate selected CPS options and parameter values for + this VCC. + + * The 'aal2CPSSDUrate' attribute, which is used to place an upper + bound on the SDU bit rate for an AAL2 CID. + + + + +Kumar & Mostafa Standards Track [Page 45] + +RFC 3108 ATM SDP May 2001 + + + * The 'aal2sscs3661unassured' attribute, which is used to + indicate the presence of an AAL2 SSCS sublayer with unassured + transmission as defined in ITU I.366.1 [12]. Optionally, it + can be used to indicate selected options and parameter values + for this SSCS. + + * The 'aal2sscs3661assured' attribute, which is used to indicate + the presence of an AAL2 SSCS sublayer with assured transmission + as defined in ITU I.366.1 [12]. Optionally, it can be used to + indicate selected options and parameter values for this SSCS. + + * The 'aal2sscs3662' attribute, which is used to indicate the + presence of an AAL2 SSCS sublayer as defined in ITU I.366.2. + Optionally, it can be used to indicate selected options and + parameter values for this SSCS. + + * The 'aal5sscop' attribute, which is used to indicate the + existence of an SSCOP protocol layer over an AAL5 CPS layer, + and the parameters which pertain to this SSCOP layer. + +5.6.2.1 The 'aalApp' attribute + + When present, the 'aalApp' attribute is used to point to the + controlling standard for an application layer above the ATM + adaptation layer. The format of the 'aalApp' media attribute line is + as follows: + + a=aalApp: <appClass> <oui> <appId> + + If any of the subparameters, <appClass>, <oui> or <appId>, is meant + to be left, unspecified, it is set to "-". However, an 'aalApp' + attribute line with all subparameters set to "-" carries no + information and should be omitted. + + The <appClass>, or application class, field can take on the string + values listed below. + + This list is not exhaustive. An "X-" prefix should be used with + <appClass> values not listed here. + + <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]. + + + +Kumar & Mostafa Standards Track [Page 46] + +RFC 3108 ATM SDP May 2001 + + + "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>, or Organizationally Unique Identifier, refers to the + organization responsible for defining the <appId>, or Application + Identifier. The <oui> is maintained by the IEEE. One of its uses is + in 802 MAC addresses. It is a three-octet field represented as one + to six hex digits. Since this is always represented in hex, the "0x" + prefix is not used. Leading zeros may be omitted. + + + +Kumar & Mostafa Standards Track [Page 47] + +RFC 3108 ATM SDP May 2001 + + + The <appId> subparameter refers to the application ID, a hex number + consisting of up to 8 digits. Leading zeros may be omitted. The + "0x" prefix is not used, since the representation is always + hexadecimal. Currently, the only organization that has defined + application identifiers is the ATM forum. These have been defined in + the context of AAL2 ([44], [52], Section 5 of [61]). Within SDP, + these can be used with <appClass> = itu_i3662. The <oui> value for + the ATM forum is 0x00A03E. + + In the following example, the aalApp media attribute line is used to + indicate '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]. The SSCS used is per ITU I.366.2 + [13]. + + a=aalApp:itu_i3662 A03E A + + If leading zeros are not dropped, this can be represented as: + + a=aalApp:itu_i3662 00A03E 0000000A + + Since application identifiers have been specified only in the context + of the AAL2 SSCS defined in ITU I.366.2 [13],the <appClass> can be + set to '-' without ambiguity. The aalApp media attribute line can be + reduced to: + + a=aalApp:- A03E A + + or + + a=aalApp:- 00A03E 0000000A + +5.6.2.2 The 'cbrRate' attribute + + When present, the 'cbrRate' attribute is used to represent the CBR + rate octet defined in Table 4-6 of ITU Q.2931 [15]. The format of + this media attribute line is: + + a=cbrRate: <cbrRate> + + Here, <cbrRate> is represented as exactly two hex digits. The "0x" + prefix is omitted since this parameter is always represented in hex. + Values currently defined by the ITU are: + + + + + + + + +Kumar & Mostafa Standards Track [Page 48] + +RFC 3108 ATM SDP May 2001 + + + +------------+-----------------------------------------------+ + | 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 is preferable that the cbrRate attribute be omitted rather than + set to an unspecified value of "-", since it conveys no information + in the latter case. + +5.6.2.3 The 'sbc' attribute + + The 'sbc' media attribute line denotes the subchannel count and is + meaningful only in the case of 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). Although no such standard definition + exists, it is also possible to use AAL5 for this purpose. An n x 64 + clear channel is represented by the encoding names of "X-CCD" and + "X-CCD-CAS" in Table 2. + + The format of the 'sbc' media attribute line is as follows: + + a=sbc:<sbc> + + + + + +Kumar & Mostafa Standards Track [Page 49] + +RFC 3108 ATM SDP May 2001 + + + Here, <sbc> can be expressed as a decimal or hex integer. This + attribute indicates the number of DS0s in a T1 or E1 frame that are + aggregated for transmitting clear channel data. For T1-based + applications, it can take on integral values in the inclusive range + [1...24]. For E1-based applications, it can take on integral values + in the inclusive range [1...31]. When omitted, other means are to be + used to determine the subchannel count. + + Use of the 'sbc' attribute provides a direct way to indicate the + number of 64 kbps subchannels bundled into an n x 64 clear channel. + An alternate mechanism to indicate this exists within the SDP + bandwidth information, or 'b', line [1]. In this case, instead of + specifying the number of subchannels, the aggregate bandwidth in kbps + is specified. The syntax of the 'b' line, copied verbatim from [1], + is as follows: + + b=<modifier>:<bandwidth-value> + + In the case of n x 64 clear channels, the <modifier> is assigned a + text string value of "AS", indicating that the 'b' line is + application-specific. The <bandwidth-value> parameter, which is a + decimal number indicating the bandwidth in kbps, is limited to one of + the following values in the n x 64 clear channel application 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, 1984 + + Thus, for n x 64 circuit mode data service, + + a=sbc:6 + + is equivalent to + + b=AS:384 + + The media attribute line + + a=sbc:2 + + is equivalent to + + b=AS:128 + + + + + + + + +Kumar & Mostafa Standards Track [Page 50] + +RFC 3108 ATM SDP May 2001 + + +5.6.2.4 The 'clkrec' attribute + + When present, the 'clkrec' attribute is used to indicate the clock + recovery method. This attribute is meaningful in the case of AAL1 + unstructured data transfer (UDT). The format of the 'clkrec' media + attribute line is as follows: + + a=clkrec:<clkrec> + + The <clkrec> field can take on the following string values: "NULL", + "SRTS" or "ADAPTIVE". SRTS and adaptive clock recovery are defined + in ITU I.363.1 [10]. "NULL" indicates that the stream (e.g., T1/E1) + encapsulated in ATM is synchronous to the ATM network or is retimed, + before AAL1 encapsulation, via slip buffers. + +5.6.2.5 The 'fec' attribute + + When present, the 'fec' attribute is used to indicate the use of + forward error correction. Currently, there exists a forward error + correction method defined for AAL1 in ITU I.363.1 [10]. The format + of the 'fec' media attribute line is as follows: + + a=fec:<fecEnable> + + The <fecEnable> flag indicates the presence of absence of Forward + Error Correction. It can take on the string values of "NULL", + "LOSS_SENSITIVE" and "DELAY_SENSITIVE". An "NULL" value implies + disabling this capability. FEC can be enabled differently for + delay-sensitive and loss-sensitive connections. + +5.6.2.6 The 'prtfl' attribute + + When present, the 'prtfl' attribute is used to indicate the fill + level of cells. When this attribute is absent, then other means + (such as provisionable defaults) are used to determine the presence + and level of partial fill. + + This attribute indicates the number of non-pad payload octets, not + including any AAL SAR or convergence sublayer octets. For example, + in some AAL1 applications that use partially filled cells with + padding at the end, this attribute indicates the number of leading + payload octets not including any AAL overhead. + + The format of the 'prtfl' media attribute line is as follows: + + a=prtfl:<partialFill> + + Here, <partialFill> can be expressed as a decimal or a hex integer. + + + +Kumar & Mostafa Standards Track [Page 51] + +RFC 3108 ATM SDP May 2001 + + + In general, permitted values are integers in the range 1 - 48 + inclusive. However, this upper bound is different for different + adaptations since the AAL overhead, if any, is different. If the + specified partial fill is greater than or equal to the maximum fill, + then complete fill is used. Using a 'partial' fill of 48 always + disables partial fill. + + In the AAL1 context, this media attribute line applies uniformly to + both P and non-P cells. In AAL1 applications that do not distinguish + between P and non-P cells, a value of 47 indicates complete fill + (i.e., the absence of partial fill). In AAL1 applications that + distinguish between P and non-P cells, a value of 46 indicates no + padding in P-cells and a padding of one in non-P cells. + + If partial fill is enabled (i.e there is padding in at least some + cells), then AAL1 structures must not be split across cell + boundaries. These shall fit in any cell. Hence, their size shall be + less than or equal to the partial fill size. Further, the partial + fill size is preferably an integer multiple of the structure size. + If not, then the partial fill size stated in the SDP description + shall be truncated to an integer multiple (e.g., a partial fill size + of 40 is truncated to 36 to support six 6 x 64 channels). + +5.6.2.7 The 'structure' attribute + + This attribute applies to AAL1 connections only. When present, the ' + structure' attribute is used to indicate the presence or absence of + structured data transfer (SDT), and the size in octets of the SDT + blocks. The format of the 'structure' media attribute line is as + follows: + + a=structure: <structureEnable> <blksz> + + where the <structureEnable> flag indicates the presence of absence of + SDT. It can take on the values of "on" or "off". An "on" value + implies AAL1 structured data transfer (SDT), while an "off" value + implies AAL1 unstructured data transfer (UDT). + + The block size field, <blksz>, is an optional 16-bit field [15] that + can be represented in decimal or hex. It is set to a "-" when not + applicable, as in the case of unstructured data transfer (UDT). For + SDT, it can be set to a "-" when <blksz> is known by other means. + For instance, af-vtoa-78 [7] fixes the structure size for n x 64 + service, with or without CAS. The theoretical maximum value of + <blksz> is 65,535, although most services use much less. + + + + + + +Kumar & Mostafa Standards Track [Page 52] + +RFC 3108 ATM SDP May 2001 + + +5.6.2.8 The 'cpsSDUsize' attribute + + When present, the 'cpsSDUsize' attribute is used to indicate the + maximum size of the CPCS SDU payload. There can be several ' + cpsSDUsize' lines in an SDP description. + + The format of this media attribute line is as follows: + + a=cpsSDUsize:<directionFlag><cpcs> + + The <directionFlag> can be assigned the following string values: "f", + "b" and "fb". "f" and "b" indicate the forward and backward + directions respectively. "fb" refers to both directions (forward and + backward). Conventions for the forward and backward directions are + per section 2.3. + + The <cpcs> fields is a 16-bit integer that can be represented in + decimal or in hex. The meaning and values of these fields are as + follows: + + Application Field Meaning Values + + AAL5 <cpcs> Maximum CPCS-SDU size 1- 65,535 + + + AAL2 <cpcs> Maximum CPCS-SDU size 45 or 64 + +5.6.2.9 The 'aal2CPS' attribute + + When present, the 'aal2CPS' attribute is used to describe parameters + associated with the AAL2 CPS layer. + + The format of the 'aal2CPS' media attribute line is as follows: + a=aal2CPS:<cidLowerLimit><cidUpperLimit><timerCU> <simplifiedCPS> + + Each of these fields can be set to a "-" when the intention is to not + specify them in an SDP descriptor. + + The <cidLowerLimit> and <cidUpperLimit> can be assigned integer + values between 8 and 255 [11], with the limitation that + <cidUpperLimit> be greater than or equal to <cidLowerLimit>. For + instance, for POTS applications based on [52], <cidLowerLimit> and + <cidUpperLimit> can have values of 16 and 223 respectively. + + The <timerCU> integer represents the "combined use" timerCU defined + in ITU I.363.2. This timer is represented as an integer number of + microseconds. It is represented as the decimal integer equivalent of + 32 bits. + + + +Kumar & Mostafa Standards Track [Page 53] + +RFC 3108 ATM SDP May 2001 + + + The <simplifiedCPS> parameter can be assigned the values "on" or + "off". When it is "on", the AAL2 CPS simplification described in + [52] is adopted. Under this simplification, each ATM cell contains + exactly on AAL2 packet. If necessary, octets at the end of the cell + are padded with zeros. Since the <timerCU> value in this context is + always 0, it can be set to "-". + +5.6.2.10 The 'aal2CPSSDUrate' attribute + + When present, the 'aal2CPSSDUrate' attribute is used to place an + upper bound on the SDU bit rate for an AAL2 CID. This is useful for + limiting the bandwidth used by a CID, specially if the CID is used + for frame mode data defined in [13], or with the SSSAR defined in + [12]. The format of this media attribute line is as follows: + + a=aal2CPSSDUrate: <fSDUrate><bSDUrate> + + The fSDUrate and bSDUrate are the maximum forward and backward SDU + rates in bits/second. These are represented as decimal integers, + with range as defined in Section 6. If any of these parameters in + these media attribute lines is not specified, is inapplicable or is + implied, then it is set to "-". + +5.6.2.11 The 'aal2sscs3661unassured' attribute + + When present, the 'aal2sscs3661unassured' attribute is used to + indicate the options that pertain to the unassured transmission SSCS + defined in ITU I.366.1 [12]. This SSCS can be selected via the + aalApp attribute defined below, or by virtue of the presence of the ' + aal2sscs3661unassured' attribute. The format of this media attribute + line is as follows: + + a=aal2sscs3661unassured: <ted> <rastimer> <fsssar> <bsssar> + + Each of these fields can be set to a "-" when the intention is to not + specify them in an SDP descriptor. + + The <ted> flag indicates the presence or absence of transmission + error detection as defined in I.366.1. It can be assigned the values + of "on" or "off". An "on" value indicates presence of the + capability. + + The <rastimer> subparameter indicates the SSSAR reassembly timer in + microseconds. It is represented as the decimal equivalent of 32 + bits. + + + + + + +Kumar & Mostafa Standards Track [Page 54] + +RFC 3108 ATM SDP May 2001 + + + The <fsssar> and <bsssar> fields are 24-bit integers that can be + represented in decimal or in hex. The meaning and values of the + <fsssar> and <bsssar> fields are as follows: + + Field Meaning Values + + <fsssar> Maximum SSSAR-SDU size 1- 65,568 + forward direction + + <bsssar> Maximum SSSAR-SDU size 1- 65,568 + backward direction + + If present, the SSTED (Service-Specific Transmission Error Detection) + sublayer is above the SSSAR (Service-Specific Segmentation and + Reassembly) sublayer [12]. Since the maximum size of the SSTED-SDUs + can be derived from the maximum SSSAR-SDU size, it need not be + specified separately. + +5.6.2.12 The 'aal2sscs3661assured' attribute + + When present, the 'aal2sscs3661assured' attribute is used to indicate + the options that pertain to the assured transmission SSCS defined in + ITU I.366.1 [12] on the basis of ITU Q.2110 [43]. This SSCS can be + selected via the aalApp attribute defined below, or by virtue of the + presence of the 'aal2sscs3661assured' attribute. The format of this + media attribute line is as follows: + + a=aal2sscs3661assured: <rastimer> <fsssar> <bsssar> <fsscopsdu> + <bsscopsdu><fsscopuu> <bsscopuu> + + Each of these fields can be set to a "-" when the intention is to not + specify them in an SDP descriptor. + + The <rastimer> subparameter indicates the SSSAR reassembly timer in + microseconds. It is represented as the decimal equivalent of 32 + bits. + + The <fsssar> and <bsssar> fields are 24-bit integers that can be + represented in decimal or in hex. The <fsscopsdu>, <bsscopsdu>, + <fsscopuu> and <bsscopuu> fields are 16-bit integers that can be + represented in decimal or in hex. The meaning and values of these + fields is as follows: + + Field Meaning Values + + <fsssar> Maximum SSSAR-SDU size 1- 65,568 + forward direction + + + + +Kumar & Mostafa Standards Track [Page 55] + +RFC 3108 ATM SDP May 2001 + + + <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 direction + + The SSTED (Service-Specific Transmission Error Detection) sublayer is + above the SSSAR (Service-Specific Segmentation and Reassembly) + sublayer [12]. The SSADT (Service-Specific Assured Data Transfer) + sublayer is above the SSTED sublayer. Since the maximum size of the + SSTED-SDUs and SSADT-SDUs can be derived from the maximum SSSAR-SDU + size, they need not be specified separately. + + The SSCOP protocol defined in [43] is used by the Assured Data + Transfer service defined in [12]. In the context of the ITU I.366.1 + SSCS, it is possible to use the 'aal2sscs3661assured' attribute to + limit the maximum sizes of the SSCOP SDUs and UU (user-to-user) + fields in either direction. Note that it is necessary for the + parameters on the 'aal2sscs3661assured' media attribute line to be + consistent with each other. + +5.6.2.13 The 'aal2sscs3662' attribute + + When present, the 'aal2sscs3662' attribute is used to indicate the + options that pertain to the SSCS defined in ITU I.366.2 [13]. This + SSCS can be selected via the aalApp attribute defined below, or by + the presence of the 'aal2sscs3662' attribute. + + The format of this media attribute line is as follows: + + a=aal2sscs3662: <sap> <circuitMode> <frameMode> <faxDemod> + <cas> <dtmf> <mfall> <mfr1> <mfr2> + <PCMencoding> <fmaxFrame> <bmaxFrame> + + Each of these fields can be set to a "-" when the intention is to not + specify them in an SDP descriptor. Additionally, the values of these + fields need to be consistent with each other. Inconsistencies should + be flagged as errors. + + + + +Kumar & Mostafa Standards Track [Page 56] + +RFC 3108 ATM SDP May 2001 + + + The <sap> field can take on the following string values: "AUDIO" and + "MULTIRATE". These correspond to the audio and multirate Service + Access Points (SAPs) defined in ITU I.366.2. + + For the multirate SAP, the following parameters on the aal2sscs3662 + attribute line do not apply: <faxDemod>,<cas>, <dtmf>, <mfall>, + <mfr1>, <mfr2> and <PCMencoding>. These are set to "-" for the + multirate SAP. + + The <circuitMode> flag indicates whether the transport of circuit + mode data is enabled or disabled, corresponding to the string values + of "on" and "off" respectively. For the multirate SAP, it cannot + have a value of "off". For the audio SAP, it can be assigned a value + of "on", "off" or "-". Note that the <sbc> attribute, defined + elsewhere in this document, can be used to specify the number of 64 + kbps subchannels bundled into a circuit mode data channel. + + The <frameMode> flag indicates whether the transport of frame mode + data is enabled or disabled, corresponding to the string values of + "on" and "off" respectively. + + The <faxDemod> flag indicates whether facsimile demodulation and + remodulation are enabled or disabled, corresponding to the string + values of "on" and "off" respectively. + + The <cas> flag indicates whether the transport of Channel Associated + Signaling (CAS) bits in AAL2 type 3 packets is enabled or disabled, + corresponding to the string values of "on" and "off" respectively. + + The <dtmf> flag indicates whether the transport of DTMF dialled + digits in AAL2 type 3 packets is enabled or disabled, corresponding + to the string values of "on" and "off" respectively. + + The <mfall> flag indicates whether the transport of MF dialled digits + in AAL2 type 3 packets is enabled or disabled, corresponding to the + string values of "on" and "off" respectively. This flag enables MF + dialled digits in a generic manner, without specifying type (e.g., + R1, R2 etc.). + + The <mfr1> flag indicates whether the transport, in AAL2 type 3 + packets, of MF dialled digits for signaling system R1 is enabled or + disabled, corresponding to the string values of "on" and "off" + respectively. + + The <mfr2> flag indicates whether the transport, in AAL2 type 3 + packets, of MF dialled digits for signaling system R2 is enabled or + disabled, corresponding to the string values of "on" and "off" + respectively. + + + +Kumar & Mostafa Standards Track [Page 57] + +RFC 3108 ATM SDP May 2001 + + + The <PCMencoding> field indicates whether PCM encoding, if used, is + based on the A-law or the Mu-law. This can be used to qualify the ' + generic PCM' codec stated in some of the AAL2 profiles. The + <PCMencoding> field can take on the string values of "PCMA" and + "PCMU". + + The <fmaxFrame> and <bmaxFrame> fields are 16-bit integers that can + be represented in decimal or in hex. The meaning and values of the + <fmaxFrame> and <bmaxFrame> fields are as follows: + + 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 direction + +5.6.2.14 The 'aal5sscop' attribute + + When present, the 'aal5sscop' attribute is used to indicate the + existence of an SSCOP [43] protocol layer over an AAL5 CPS layer + [21], and the parameters which pertain to this SSCOP layer. SSCOP + over AAL5 can also be selected via the aalApp attribute defined + below. The format of the 'aal5sscop' media attribute line is as + follows: + + a=aal5sscop: <fsscopsdu> <bsscopsdu> <fsscopuu> <bsscopuu> + + Each of these fields can be set to a "-" when the intention is to not + specify them in an SDP descriptor. + + The representation, meaning and values of the <fsscopsdu>, + <bsscopsdu>, <fsscopuu> and <bsscopuu> fields are identical to those + for the 'aal2sscs3661assured' media attribute line (Section + 5.6.2.12). Note that it is necessary for the parameters on the ' + aal5sscop' media attribute line to be consistent with each other. + +5.6.3 Service attributes + + The following is a summary list of the SDP media attributes that can + be used to describe the services that use the ATM Adaptation Layer + (AAL). These attributes are detailed in subsequent subsections. + + * The 'atmmap' attribute. In the AAL1 and AAL5 contexts, this is + used to dynamically map payload types into codec strings. + + + +Kumar & Mostafa Standards Track [Page 58] + +RFC 3108 ATM SDP May 2001 + + + * The 'silenceSupp' attribute, used to indicate the use of of + voice activity detection for silence suppression, and to + optionally parameterize the silence suppression function. + + * The 'ecan' attribute, used to indicate the use of of echo + cancellation, and to parameterize the this function. + + * The 'gc' attribute, used to indicate the use of of gain + control, and to parameterize the this function. + + * The 'profileDesc' attribute, which can be used to describe AAL2 + profiles. Although any AAL2 profile can be so described, this + attribute is useful for describing, at connection establishment + time, custom profiles that might not be known to the far end. + This attribute applies in the AAL2 context only. + + * The 'vsel' attribute, which indicates a prioritized list of 3- + tuples for voice service. Each 3-tuple indicates a codec, an + optional packet length and an optional packetization period. + This complements the 'm' line information and should be + consistent with it. + + * The 'dsel' attribute, which indicates a prioritized list of 3- + tuples for voiceband data service. Each 3-tuple indicates a + codec, an optional packet length and an optional packetization + period. This complements the 'm' line information and should + be consistent with it. + + * The 'fsel' attribute, which indicates a prioritized list of 3- + tuples for facsimile service. Each 3-tuple indicates a codec, + an optional packet length and an optional packetization period. + This complements the 'm' line information and should be + consistent with it. + + * The 'onewaySel' attribute, which indicates a prioritized list + of 3-tuples for one direction of an asymmetric connection. + Each 3-tuple indicates a codec, an optional packet length and + an optional packetization period. This complements the 'm' + line information and should be consistent with it. + + * The 'codecconfig' attribute, which is used to represent the + contents of the single codec information element (IE) defined + in ITU Q.765.5 [57]. + + * The 'isup_usi' attribute which is used to represent 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]. + + + +Kumar & Mostafa Standards Track [Page 59] + +RFC 3108 ATM SDP May 2001 + + + * The 'uiLayer1_Prot' attribute, which is used to represent 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 defined on the basis of the 'rtpmap' + attribute used in RFC 2327. + + a=atmmap:<payloadType> <encodingName> + + The 'atmmap' attribute is used to dynamically map encoding names into + payload types. This is necessary for those encoding names which have + not been assigned a static payload type through IANA [31]. Payload + types and encoding techniques that have been registered with IANA for + RTP are retained for AAL1 and AAL5. + + The range of statically defined payload types is in the range 0-95. + All static assignments of payload types to codecs are listed in [31]. + The range of payload types defined dynamically via the 'atmmap' + attribute is 96-127. + + In addition to reiterating the payload types and encoding names in + [31], Table 2 defines non-standard encoding names (with "X-" + prefixes). Note that [31], rather than Table 2, is the authoritative + list of standard codec names and payload types in the ATM context. + + Table 2: Encoding Names and Payload Types + + |---------------------|--------------|---------------------------| + | 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) | | + + + +Kumar & Mostafa Standards Track [Page 60] + +RFC 3108 ATM SDP May 2001 + + + |---------------------|--------------|---------------------------| + | 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] | | | + |---------------------|--------------|---------------------------| + + + + +Kumar & Mostafa Standards Track [Page 61] + +RFC 3108 ATM SDP May 2001 + + + |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) | + |---------------------|--------------|---------------------------| + + + +Kumar & Mostafa Standards Track [Page 62] + +RFC 3108 ATM SDP May 2001 + + + | 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 + + When present, the 'silenceSupp' attribute is used to indicate the use + or non-use of silence suppression. The format of the 'silenceSupp' + media attribute line is as follows: + + a=silenceSupp: <silenceSuppEnable> <silenceTimer> <suppPref> <sidUse> + <fxnslevel> + + + + +Kumar & Mostafa Standards Track [Page 63] + +RFC 3108 ATM SDP May 2001 + + + If any of the parameters in the silenceSupp media attribute line is + not specified, is inapplicable or is implied, then it is set to "-". + + The <silenceSuppEnable> can take on values of "on" or "off". If it + is "on", then silence suppression is enabled. + + The <silenceTimer> is a 16-bit field which can be represented in + decimal or hex. Each increment (tick) of this timer represents a + millisecond. The maximum value of this timer is between 1 and 3 + minutes. This timer represents the time-lag before silence + suppression kicks in. Even though this can, theoretically, be as low + as 1 ms, most DSP algorithms take more than that to detect silence. + Setting <silenceTimer> to a large value (say 1 minute> is equivalent + to disabling silence suppression within a call. However, idle + channel suppression between calls on the basis of silence suppression + is still operative in non-switched, trunking applications if + <silenceSuppEnable> = "on" and <silenceTimer> is a large value. + + The <suppPref> specifies the preferred silence suppression method + that is preferred or already selected. It can take on the string + values of "standard" and "custom". If its value is "standard", then + a standard method (e.g., ITU-defined) is preferred to custom methods + if such a standard is defined. Otherwise, a custom method may be + used. If <suppPref> is set to "custom", then a custom method, if + available, is preferred to the standard method. + + The <sidUse> indicates whether SIDs (Silence Insertion Descriptors) + are to be used, and whether they use fixed comfort noise or sampled + background noise. It can take on the string values of "No SID", + "Fixed Noise", "Sampled Noise". + + If the value of <sidUse> is "Fixed Noise", then <fxnslevel> provides + its level. It can take on integer values in the range 0-127, as + follows: + + +-----------------------+---------------------+ + | <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)| + +-----------------------+---------------------+ + + + + +Kumar & Mostafa Standards Track [Page 64] + +RFC 3108 ATM SDP May 2001 + + + In addition to the decimal representation of <fxnslevel>, a hex + representation, preceded by a "0x" prefix, is also allowed. + +5.6.3.3 The 'ecan' attribute + + When present, the 'ecan' attribute s is used to indicate the use or + non-use of echo cancellation. There can be several 'ecan' lines in + an SDP description. + + The format of the 'ecan' media attribute line is as follows: + + a=ecan:<directionFlag><ecanEnable><ecanType> + + The <directionFlag> can be assigned the following string values: "f", + "b" and "fb". "f" and "b" indicate the forward and backward + directions respectively. "fb" refers to both directions (forward and + backward). Conventions for the forward and backward directions are + per section 2.3. + + The <directionFlag> is always specified. Except for the + <directionFlag>, the remaining parameters can be set to "-" to + indicate that they are not specified, inapplicable or implied. + However, there must be some specified parameters for the line to be + useful in an SDP description. + + If the 'ecan' media attribute lines is not present, then means other + than the SDP descriptor must be used to determine the applicability + and nature of echo cancellation for a connection direction. Examples + of such means are MIB provisioning, the local connection options + structure in MGCP etc. + + The <ecanEnable> parameter can take on values of "on" or "off". If + it is "on", then echo cancellation is enabled. If it is "off", then + echo cancellation is disabled. + + The <ecanType> parameter can take on the string values "G165" and + "G168" respectively. + + When SDP is used with some media gateway control protocols such as + MGCP and Megaco [26], there exist means outside SDP descriptions to + specify the echo cancellation properties of a connection. + Nevertheless, this media attribute line is included for completeness. + As a result, the SDP can be used for describing echo cancellation in + applications where alternate means for this are unavailable. + + + + + + + +Kumar & Mostafa Standards Track [Page 65] + +RFC 3108 ATM SDP May 2001 + + +5.6.3.4 The 'gc' attributes + + When present, the 'gc' attribute is used to indicate the use or non- + use of gain control. There can be several 'gc' lines in an SDP + description. + + The format of the 'gc' media attribute line is as follows: + + a=gc:<directionFlag><gcEnable><gcLvl> + + The <directionFlag> can be assigned the following string values: "f", + "b" and "fb". "f" and "b" indicate the forward and backward + directions respectively. "fb" refers to both directions (forward and + backward). Conventions for the forward and backward directions are + per section 2.3. + + The <directionFlag> is always specified. Except for the + <directionFlag>, the remaining parameters can be set to "-" to + indicate that they are not specified, inapplicable or implied. + However, there must be some specified parameters for the line to be + useful in an SDP description. + + If the 'gc' media attribute lines is not present, then means other + than the SDP descriptor must be used to determine the applicability + and nature of gain control for a connection direction. Examples of + such means are MIB provisioning, the local connection options + structure in MGCP etc. + + The <gcEnable> parameter can take on values of "on" or "off". If it + is "on", then gain control is enabled. If it is "off", then gain + control is disabled. + + The <gcLvl> parameter is represented as the decimal or hex equivalent + of a 16-bit binary field. A value of 0xFFFF implies automatic gain + control. Otherwise, this number indicates the number of decibels of + inserted loss. The upper bound, 65,535 dB (0xFFFE) of inserted loss, + is a large number and is a carryover from Megaco [26]. In practical + applications, the inserted loss is much lower. + + When SDP is used with some media gateway control protocols such as + MGCP and Megaco [26], there exist means outside SDP descriptions to + specify the gain control properties of a connection. Nevertheless, + this media attribute line is included for completeness. As a result, + the SDP can be used for describing gain control in applications where + alternate means for this are unavailable. + + + + + + +Kumar & Mostafa Standards Track [Page 66] + +RFC 3108 ATM SDP May 2001 + + +5.6.3.5 The 'profileDesc' attribute + + There is one 'profileDesc' media attribute line for each AAL2 profile + that is intended to be described. The 'profileDesc' media attribute + line is structured as follows: + + 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> + + Here, <aal2transport> can have those values of <transport> (Table 1) + that pertain to AAL2. These are: + + AAL2/ATMF + AAL2/ITU + AAL2/custom + AAL2/<corporateName> + AAL2/IEEE:<oui> + + The parameter <profile> is identical to its definition for the 'm' + line (Section 5.5.4). + + The profile elements (rows in the profile tables of ITU I.366.2 or + AF-VTOA-0113) are represented as four-tuples following the <profile> + parameter in the 'profileDesc' media attribute line. If a member of + one of these four-tuples is not specified or is implied, then it is + set to "-". + + The <uuiCodeRange> parameter is represented by D1-D2, where D1 and D2 + are decimal integers in the range 0 through 15. + + The <encodingName> parameter can take one of the values in column 2 + of Table 2. Additionally, it can take on the following descriptor + strings: "PCMG", "SIDG" and "SID729". These stand for generic PCM, + generic SID and G.729 SID respectively. + + The <packetLength> is a decimal integer representation of the AAL2 + packet length in octets. + + The <packetTime> is a decimal integer representation of the AAL2 + packetization interval in microseconds. + + For instance, the 'profileDesc' media attribute line below defines + the AAL2/custom 100 profile. This profile is reproduced in the Table + 3 below. For a description of the parameters in this profile such as + M and the sequence number interval, see ITU I.366.2 [13]. + + + +Kumar & Mostafa Standards Track [Page 67] + +RFC 3108 ATM SDP May 2001 + + + 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 + + If the <packetTime> parameter is to be omitted or implied, then the + same profile can be represented as follows: + + 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 has a provisioned or hard coded definition of a profile, + then any definition provided via the 'profileDesc' line overrides it. + The exception to this rule is with regard to standard profiles such + as ITU-defined profiles and ATMF-defined profiles. In general, these + should not be defined via a 'profileDesc' media attribute line. If + they are, then the definition needs to be consistent with the + standard definition 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 + + The 'vsel' attribute indicates a prioritized list of one or more 3- + tuples for voice service. Each 3-tuple indicates a codec, an + optional packet length and an optional packetization period. This + complements the 'm' line information and should be consistent with + it. + + + + +Kumar & Mostafa Standards Track [Page 68] + +RFC 3108 ATM SDP May 2001 + + + The 'vsel' attribute refers to all directions of a connection. For a + bidirectional connection, these are the forward and backward + directions. For a unidirectional connection, this 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 these, the 'onewaySel' attribute (section + 5.6.3.9) should be used. See section 5.6.3.9 for the requirement to + not use the 'vsel' and 'onewaySel' attributes in the same SDP + descriptor. + + The 'vsel' line is structured as follows: + + a=vsel:<encodingName #1> <packetLength #1><packetTime #1> + <encodingName #2> <packetLength #2><packetTime #2> + ... + <encodingName #N> <packetLength #N><packetTime #N> + + where 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. The parameters <packetLength> and <packetTime> can be + set to "-" when not needed. Also, the entire 'vsel' media attribute + line can be omitted when not needed. + + For example, + + a=vsel:G729 10 10000 G726-32 40 10000 + + 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 are associated with this + codec. G726-32 is the second preference stated in this line, with an + associated packet length of 40 octets and a packetization interval of + 10 ms. If the packet length and packetization interval are intended + to be omitted, then this media attribute line becomes + + a=vsel:G729 - - G726-32 - - + + The media attribute line + + a=vsel:G726-32 40 10000 + + indicates preference for or selection of 32 kbps ADPCM with a packet + length of 40 octets and a packetization interval of 10 ms. + + + + +Kumar & Mostafa Standards Track [Page 69] + +RFC 3108 ATM SDP May 2001 + + + This media attribute line can be used in ATM as well as non-ATM + contexts. Within the ATM context, it can be applied to the AAL1, + AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are + not meaningful in the AAL1 case and should be set to "-". In the + AAL2 case, this line determines the use of some or all of the rows in + a given profile table. If multiple 3-tuples are present, they can + indicate 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 present on the 'm' line, the profile qualified by this + attribute is the first profile. If a single profile that has been + selected for a connection is indicated in the 'm' line, the 'vsel' + attribute qualifies the use, for voice service, of codecs within that + profile. + + With most of the encoding names in Figure 2, the packet length and + packetization period can be derived from each other. One of them can + be set to "-" without a loss of information. There are some + exceptions such as the IANA-registered encoding names G723, DVI4 and + L16 for which this is not true. Therefore, there is a need to retain + both the packet length and packetization period in the definition of + the 'vsel' line. + +5.6.3.7 The 'dsel' attribute + + The 'dsel' attribute indicates a prioritized list of one or more 3- + tuples for voiceband data service. The <fxIncl> flag indicates + whether this definition of voiceband data includes fax ("on" value) + or not ("off" value). If <fxIncl> is "on", then the 'dsel' line must + be consistent with any 'fsel' line in the session description. In + this case, an error event is generated in the case of inconsistency. + Each 3-tuple indicates a codec, an optional packet length and an + optional packetization period. This complements the 'm' line + information and should be consistent with it. + + The 'dsel' attribute refers to all directions of a connection. For a + bidirectional connection, these are the forward and backward + directions. For a unidirectional connection, this 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 these, 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. + + + + + + +Kumar & Mostafa Standards Track [Page 70] + +RFC 3108 ATM SDP May 2001 + + + The 'dsel' line is structured as follows: + + a=dsel:<fxIncl> <encodingName #1> <packetLength #1><packetTime #1> + <encodingName #2> <packetLength #2><packetTime #2> + ... + <encodingName #N> <packetLength #N><packetTime #N> + + + where the <encodingName> parameter can take one of the values in + column 2 of Table 2. The <packetLength> and <packetTime> parameters + are per their definition, above, for the 'vsel' media attribute line. + The parameters <packetLength> and <packetTime>) can be set to "-" + when not needed. The <fxIncl> flag is presumed to be "off" if it is + set to "-". Also, the entire 'dsel' media attribute line can be + omitted when not needed. + + For example, + + a=dsel:- G726-32 20 5000 PCMU 40 5000 + + indicates that this line does not address facsimile, and that the + first preference for the voiceband data codes is 32 kbps ADPCM, while + the second preference is PCMU. The packet length and the + packetization interval associated with G726-32 are 20 octets and 5 ms + respectively. For PCMU, they are 40 octets and 5 ms respectively. + + This media attribute line can be used in ATM as well as non-ATM + contexts. Within the ATM context, it can be applied to the AAL1, + AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are + not meaningful in the AAL1 case and should be set to "-". In the + AAL2 case, this line determines the use of some or all of the rows in + a given profile table. If multiple 3-tuples are present, they can + indicate a hierarchical assignment of some rows in that profile to + voiceband data service (e.g., row A preferred to row B etc.) If + multiple profiles are present on the 'm' line, the profile qualified + by this attribute is the first profile. If a single profile that has + been selected for a connection is indicated in the 'm' line, the ' + dsel' attribute qualifies the use, for voiceband data service, of + codecs within that profile. + + With most of the encoding names in Figure 2, the packet length and + packetization period can be derived from each other. One of them can + be set to "-" without a loss of information. There are some + exceptions such as the IANA-registered encoding names G723, DVI4 and + L16 for which this is not true. Therefore, there is a need to retain + both the packet length and packetization period in the definition of + the 'dsel' line. + + + + +Kumar & Mostafa Standards Track [Page 71] + +RFC 3108 ATM SDP May 2001 + + +5.6.3.8 The 'fsel' attribute + + The 'fsel' attribute indicates 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 this case, an error event is generated in + the case of inconsistency. Each 3-tuple indicates a codec, an + optional packet length and an optional packetization period. This + complements the 'm' line information and should be consistent with + it. + + The 'fsel' attribute refers to all directions of a connection. For a + bidirectional connection, these are the forward and backward + directions. For a unidirectional connection, this 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 these, 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 as follows: + + a=fsel:<encodingName #1> <packetLength #1><packetTime #1> + <encodingName #2> <packetLength #2><packetTime #2> + ... + <encodingName #N> <packetLength #N><packetTime #N> + + where the <encodingName> parameter can take one of the values in + column 2 of Table 2. The <packetLength> and <packetTime> parameters + are per their definition, above, for the 'vsel' media attribute line. + The parameters <packetLength> and <packetTime> can be set to "-" when + not needed. Also, the entire 'fsel' media attribute line can be + omitted when not needed. + + For example, + + a=fsel:FXDMOD-3 - - + + indicates demodulation and remodulation of ITU-T group 3 fax at the + gateway. + + a=fsel:PCMU 40 5000 G726-32 20 5000 + + + + + + +Kumar & Mostafa Standards Track [Page 72] + +RFC 3108 ATM SDP May 2001 + + + indicates a first and second preference of Mu-law PCM and 32 kbps + ADPCM as the facsimile encoding scheme. The packet length and the + packetization interval associated with G726-32 are 20 octets and 5 ms + respectively. For PCMU, they are 40 octets and 5 ms respectively. + + This media attribute line can be used in ATM as well as non-ATM + contexts. Within the ATM context, it can be applied to the AAL1, + AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are + not meaningful in the AAL1 case and should be set to "-". In the + AAL2 case, this line determines the use of some or all of the rows in + a given profile table. If multiple 3-tuples are present, they can + indicate a hierarchical assignment of some rows in that profile to + facsimile service (e.g., row A preferred to row B etc.). If multiple + profiles are present on the 'm' line, the profile qualified by this + attribute is the first profile. If a single profile that has been + selected for a connection is indicated in the 'm' line, the 'fsel' + attribute qualifies the use, for facsimile service, of codecs within + that profile. + + With most of the encoding names in Figure 2, the packet length and + packetization period can be derived from each other. One of them can + be set to "-" without a loss of information. There are some + exceptions such as the IANA-registered encoding names G723, DVI4 and + L16 for which this is not true. Therefore, there is a need to retain + both the packet length and packetization period in the definition of + the 'fsel' line. + +5.6.3.9 The 'onewaySel' attribute + + The 'onewaySel' (one way select) attribute can be used with + connections that have asymmetric codec configurations. There can be + several 'onewaySel' lines in an SDP description. The 'onewaySel' + line is structured as follows: + + a=onewaySel:<serviceType> <directionFlag> + <encodingName #1> <packetLength #1><packetTime #1> + <encodingName #2> <packetLength #2><packetTime #2> + ... + <encodingName #N> <packetLength #N><packetTime #N> + + The <serviceType> parameter can be assigned the following string + values: "v", "d", "f", "df" and "all". These indicate voice, + voiceband data (fax not included), fax, voiceband data (fax included) + and all services respectively. + + The <directionFlag> can be assigned the following string values: "f", + "b" and "fb". "f" and "b" indicate the forward and backward + directions respectively. "fb" refers to both directions (forward and + + + +Kumar & Mostafa Standards Track [Page 73] + +RFC 3108 ATM SDP May 2001 + + + backward) and shall not be used with the 'onewaySel' line. + Conventions for the forward and backward directions are per section + 2.3. + + Following <directionFlag>, there is a prioritized list of one or more + 3-tuples. Each 3-tuple indicates a codec, an optional packet length + and an optional packetization period. This complements the 'm' line + information and should be consistent with it. + + Within each 3-tuple, 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. + + The 'onewaySel' attribute must not be used in SDP descriptors that + have one or more of the following attributes: 'vsel', 'dsel', 'fsel'. + If it is present, then command containing the SDP description may be + rejected. An alternate response to such an ill-formed SDP descriptor + might the selective ignoring of some attributes, which must be + coordinated via an application-wide policy. + + The <serviceType>, <directionFlag> and <encodingName> parameters may + not be set to "-". However, the parameters <packetLength> and + <packetTime> can be set to "-" when not needed. + + For example, + + a=onewaySel:v f G729 10 10000 + a=onewaySel:v b G726-32 40 10000 + + indicates that for voice service, the codec to be used in the forward + direction is G.729 or G.729a (both are interoperable), and the codec + to be used in the backward direction is G726-32. A packet length of + 10 octets and a packetization interval of 10 ms are associated with + the G.729/G.729a codec. A packet length of 40 octets and a + packetization interval of 10 ms are associated with the G726-32 + codec. + + For example, + + a=onewaySel:d f G726-32 20 5000 + a=onewaySel:d b PCMU 40 5000 + + indicates that for voiceband service (fax not included), the codec to + be used in the forward direction is G726-32), and the codec to be + used in the backward direction is PCMU. A packet length of 20 octets + + + + +Kumar & Mostafa Standards Track [Page 74] + +RFC 3108 ATM SDP May 2001 + + + and a packetization interval of 5 ms are associated with the G726-32 + codec. A packet length of 40 octets and a packetization interval of + 5 ms are associated with the PCMU codec. + + This media attribute line can be used in ATM as well as non-ATM + contexts. Within the ATM context, it can be applied to the AAL1, + AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are + not meaningful in the AAL1 case and should be set to "-". In the + AAL2 case, these lines determine the use of some or all of the rows + in a given profile table. If multiple 3-tuples are present, they can + indicate 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 present on the 'm' line, the profile qualified by this + attribute is the first profile. + + With most of the encoding names in Figure 2, the packet length and + packetization period can be derived from each other. One of them can + be set to "-" without a loss of information. There are some + exceptions such as the IANA-registered encoding names G723, DVI4 and + L16 for which this is not true. Therefore, there is a need to retain + both the packet length and packetization period in the definition of + the 'onewaySel' line. + +5.6.3.10 The 'codecconfig' attribute + + When present, the 'codecconfig' attribute is used to represent the + contents of the single codec information element (IE) defined in + [57]. The contents of this IE are: a single-octet Organizational + Identifier (OID) field, followed by a single-octet Codec Type field, + followed by zero or more octets of a codec configuration bit-map. + The semantics of the codec configuration bit-map are specific to the + organization [57, 58]. The 'codecconfig' attribute is represented as + follows: + + a=codecconfig:<q7655scc> + + The <q7655scc> (Q.765.5 single codec IE contents) parameter is + represented as 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 to the left are more significant than digits to the right. + Leading zeros shall not be omitted. + + An example of the use of this media attribute is: + + a=codecconfig:01080C + + + + + +Kumar & Mostafa Standards Track [Page 75] + +RFC 3108 ATM SDP May 2001 + + + The first octet indicates an Organizational Identifier of 0x01 (the + ITU-T). Using ITU Q.765.5 [57], the second octet (0x08) indicates a + codec type of G.726 (ADPCM). The last octet, 0x0C indicates that 16 + kbps and 24 kbps rates are NOT supported, while the 32 kbps and 40 + kbps rates ARE supported. + +5.6.3.11 The 'isup_usi' attribute + + When present, the 'isup_usi' attribute is used to represent the + bearer capability information element defined in Section 4.5.5 of ITU + Q.931 [59] (excluding the information element identifier and length). + This information element is reiterated as the user service + information element (IE) in Section 3.57 of ITU Q.763 [60]. The ' + isup_usi' attribute is represented as follows: + + a=isup_usi:<isupUsi> + + The <isupUsi> parameter is represented as 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 to the left are more + significant than digits to the right. Leading zeros shall not be + omitted. + +5.6.3.12 The 'uiLayer1_Prot' attribute + + When present, the 'uiLayer1_Prot' attribute is used to represent the + 'User Information Layer 1 protocol' field within the bearer + capability information element defined in Section 4.5.5 of [59], and + reiterated as the user service information element (IE) in Section + 3.57 of [60]. The 'User Information Layer 1 protocol' field consists + of the five least significant bits of Octet 5 of this information + element. + + Within SDP, the 'uiLayer1_Prot' attribute is represented as follows: + + a='uiLayer1_Prot':<uiLayer1Prot> + + The <uiLayer1Prot> parameter is represented as 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 to the + left are more significant than digits to the right. These hex digits + are constructed from an octet with three leading '0' bits and last + five bits equal to the 'User Information Layer 1 protocol' field + described 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 as follows: + + + + +Kumar & Mostafa Standards Track [Page 76] + +RFC 3108 ATM SDP May 2001 + + + 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 stuffing + +5.6.4 Miscellaneous media attributes + + The 'chain' media attribute line, which is used to chain consecutive + SDP descriptions, cannot be classified as an ATM, AAL or service + attribute. It is detailed in the following subsection. + +5.6.4.1 The 'chain' attribute + + The start of an SDP descriptor is marked by a 'v' line. In some + applications, consecutive SDP descriptions are alternative + descriptions of the same session. In others, these describe + different layers of the same connection (e.g., IP, ATM, frame relay). + This is useful when these connectivity at these layers are + established at the same time (e.g., an IP-based session over an ATM + SVC). To distinguish between the alternation and concatenation of + SDP descriptions, a 'chain' attribute can be used in the case of + concatenation. + + When present, the 'chain' attribute binds an SDP description to the + next or previous SDP description. The next or previous description + is separated from the current one by a 'v' line. It is not necessary + that this description also have a 'chain' media attribute line. + + Chaining averts the need to set up a single SDP description for a + session that is simultaneously created at multiple layers. It allows + the SDP descriptors for different layers to remain simple and clean. + Chaining is not needed in the Megaco context, where it is possible to + create separate terminations for the different layers of a + connection. + + The 'chain' media attribute line has the following format: + + a=chain:<chainPointer> + + The <chainPointer> field can take on the following string values: + "NEXT", "PREVIOUS" and "NULL". The value "NULL" is not equivalent to + omitting the chain attribute from a description since it expressly + + + +Kumar & Mostafa Standards Track [Page 77] + +RFC 3108 ATM SDP May 2001 + + + precludes the possibility of chaining. If the 'chain' attribute is + absent in an SDP description, chaining can still be realized by the + presence of a chain media attribute line in the previous or next + description. + +5.6.5 Use of the second media-level part in H.323 Annex C applications + + Section 4 mentions that H.323 annex C applications have a second + media level part for the ATM session description. This is used to + convey information about the RTCP stream. Although the RTP stream is + encapsulated in AAL5 with no intervening IP layer, the RTCP stream is + sent to an IP address and RTCP port. This media-level part has the + following format: + + m= control <rtcpPortNum> H323c - + c= IN IP4 <rtcpIPaddr> + + Consistency with RFC 2327 is maintained in the location and format of + these lines. The <fmt list> in the 'm' line is set to "-". The 'c' + line in the second media-level part pertains to RTCP only. + + The <rtcpPortNum> and <rtcpIPaddr> subparameters indicate the port + number and IP address on which the media gateway is prepared to + receive RTCP packets. + + Any of the subparameters on these lines can be set to "-" if they are + known by other means. + + The range and format of the <rtcpPortNum> and <rtcpIPaddr> + subparameters is per [1]. The <rtcpPortNum> is a decimal number + between 1024 and 65535. It is an odd number. If an even number in + this range is specified, the next odd number is used. The + <rtcpIPaddr> is expressed in the usual dotted decimal IP address + representation, from 0.0.0.0 to 255.255.255.255. + +5.6.6 Use of the eecid media attribute in call establishment + procedures + + This informative section supplements the definition of the eecid + attribute (Section 5.6.1.1) by describing example procedures for its + use. These procedures assume a bearer-signaling mechanism for + connection set-up that is independent of service-level call control. + These procedures are independent of the media gateway control + protocol (MGCP, Megaco, SIP etc.), the protocol used between media + gateway controllers (ITU Q.1901, SIP etc.) and the protocol used for + bearer connection set-up (Q.2931, UNI, PNNI, AINI, IISP, Q.2630.1 + etc.). + + + + +Kumar & Mostafa Standards Track [Page 78] + +RFC 3108 ATM SDP May 2001 + + + 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 the diagram above, the originating media gateway originates the + service-level call. The terminating media gateway terminates it. In + the forward bearer connection set-up model, the originating media + gateway initiates bearer connection set-up. In the backward bearer + connection set-up model, the terminating gateway initiates bearer + connection set-up. + + Example use of the Backward Bearer Connection Set-up Model: + + (1) The originating media gateway controller (OMGC) initiates + service-level call establishment by sending the appropriate + control message to the originating media gateway (OMG). + + (2) The originating media gateway (OMG) provides its NSAP address + and an eecid value to the OMGC, using the following 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:B3D58E32 + + (3) The originating media gateway controller (OMGC) signals the + terminating media gateway controller (TMGC) through the + appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.). + It provides the TMGC with the NSAP address and the eecid + provided by the OMG. + + + + + +Kumar & Mostafa Standards Track [Page 79] + +RFC 3108 ATM SDP May 2001 + + + (4) The TMGC sends the appropriate control message to the TMG. This + includes the session descriptor received from the OMG. This + descriptor contains the NSAP address of the OMG and the EECID + assigned by the OMG. Additionally, the TMGC instructs the TMG + to set up an SVC to the OMG. It also requests the TMG to notify + the TMGC when SVC set-up is complete. Depending on the control + protocol used, this can be done through a variety of means. 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 the following local descriptor: + + v=0 + o=- 2873397497 0 ATM - - + s=- + c=ATM - - + t=0 0 + m=audio $ - - + a=bearerType:SVC on + + The 'bearerType' attribute indicates that an SVC is to be used and + that the <localInitiation> flag is on i.e., the SVC is to be set up + by the TMG. + + (5) The TMG acknowledges the control message from the TMGC. It + returns the following SDP descriptor with the acknowledge: + + 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 8 + + The NSAP address information provided in this descriptor is not + needed. It can be omitted (by setting it to "- -"). + + (6) The TMG sends an SVC set-up message to the OMG. Within the GIT + information element, it includes eecid (B3D58E32) received from + the OMG. + + (7) The OMG uses the eecid to correlate the SVC set-up request with + service-level control message received before from the OMGC. + + (8) The OMG returns an SVC connect message to the TMG. On receiving + this message, the TMG sends an event notification to the TMGC + indicating successful SVC set-up. + + + +Kumar & Mostafa Standards Track [Page 80] + +RFC 3108 ATM SDP May 2001 + + + 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: + + (1) The originating media gateway controller (OMGC) initiates + service-level call establishment by sending the appropriate + controlsmessage to the originating media gateway (OMG). + + (2) The originating media gateway (OMG) provides its NSAP address to + the OMGC, using the following 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 + + The NSAP address information provided in this descriptor is not + needed. It can be omitted (by setting it to "- -"). + + (3) The originating media gateway controller (OMGC) signals the + terminating media gateway controller (TMGC) through the + appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.). + Although this is not necessary, it can provide the TMGC with the + NSAP address provided by the OMG. + + (4) The TMGC sends the appropriate control message to the TMG. This + includes the session descriptor received from the OMG. This + descriptor contains the NSAP address of the OMG. + + (5) The TMG acknowledges the control message from the TMGC. Along + with the acknowledgement, it provides 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:B3D58E32 + + + + +Kumar & Mostafa Standards Track [Page 81] + +RFC 3108 ATM SDP May 2001 + + + (6) The terminating media gateway controller (TMGC) signals the + originating media gateway controller (OMGC) through the + appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.). + It provides the OMGC with the NSAP address and the eecid + provided by the TMG. + + (7) The OMGC sends the appropriate control message to the OMG. This + includes the session descriptor received from the TMG. This + descriptor contains the NSAP address of the TMG and the EECID + assigned by the TMG. Additionally, the OMGC instructs the OMG + to set up an SVC to the TMG. It also requests the OMG to notify + the OMGC when SVC set-up is complete. Depending on the control + protocol used, this can be done through a variety of means. 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 the following local descriptor: + + v=0 + o=- 2873397874 0 ATM - - + s=- + c=ATM - - + t=0 0 + m=audio $ - - + a=bearerType:SVC on + + The 'bearerType' attribute indicates that an SVC is to be used and + that the <localInitiation> flag is on i.e., the SVC is to be set up + by the TMG. + + (8) The OMG acknowledges the control message from the OMGC. + + (9) The OMG sends an SVC set-up message to the TMG. Within the GIT + information element, it includes eecid (B3D58E32) received from + the TMG. + + (10) The TMG uses the eecid to correlate the SVC set-up request with + the service-level control message received before from the TMGC. + + (11) The TMG returns an SVC connect message to the OMG. On receiving + this message, the OMG sends an event notification to the OMGC + indicating successful SVC set-up. + + Note that, for this example, the "v=", "o=", "s=" and "t=" + lines can be omitted in the Megaco context. + + + + + + + +Kumar & Mostafa Standards Track [Page 82] + +RFC 3108 ATM SDP May 2001 + + +6. List of Parameters with Representations + + This section provides a list of the parameters used in this document, + and the formats used to represent them in SDP descriptions. In + general, a "-" value can be used for any field that is not specified, + is inapplicable 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 + + + + + +Kumar & Mostafa Standards Track [Page 83] + +RFC 3108 ATM SDP May 2001 + + +<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 + + + + +Kumar & Mostafa Standards Track [Page 84] + +RFC 3108 ATM SDP May 2001 + + +<eecid> End-to-end Up to 8 hex digits + Connection + Identifier + +<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 + + + + +Kumar & Mostafa Standards Track [Page 85] + +RFC 3108 ATM SDP May 2001 + + +<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 + + + + + +Kumar & Mostafa Standards Track [Page 86] + +RFC 3108 ATM SDP May 2001 + + +<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 + + + + +Kumar & Mostafa Standards Track [Page 87] + +RFC 3108 ATM SDP May 2001 + + +<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" + + + + + +Kumar & Mostafa Standards Track [Page 88] + +RFC 3108 ATM SDP May 2001 + + +<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 + + + + + +Kumar & Mostafa Standards Track [Page 89] + +RFC 3108 ATM SDP May 2001 + + +<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 + + + +Kumar & Mostafa Standards Track [Page 90] + +RFC 3108 ATM SDP May 2001 + + +<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 + + + + + +Kumar & Mostafa Standards Track [Page 91] + +RFC 3108 ATM SDP May 2001 + + +<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 packets + + + + + + + + + + + + + + + + +Kumar & Mostafa Standards Track [Page 92] + +RFC 3108 ATM SDP May 2001 + + +7. Examples of ATM session descriptions using SDP + + An example of a complete AAL1 session description in SDP is: + + 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:B3D58E32 + + An example of a complete AAL2 session description in SDP is: + + 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 + + The AAL2 session descriptor below is the same as the one above except + that it states an explicit preference for a voice codec, a voiceband + data codec and a voiceband fax codec. Further, it defines the + profile AAL2/custom 100 rather than assume that the far-end is + cognizant of the elements of this profile. + + 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 10000 + + + + +Kumar & Mostafa Standards Track [Page 93] + +RFC 3108 ATM SDP May 2001 + + + An example of an SDP session descriptor for an AAL5 switched virtual + circuit for delivering 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 - - + + An example of an SDP session descriptor for an AAL5 permanent virtual + circuit for delivering 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 + + At present, standard means of encrypting ATM and AAL2 bearers are not + conventionalized in the same manner as means of encrypting RTP + payloads. Nor has the authentication of ATM or AAL2 bearer + signaling. + + 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'. + + + + + +Kumar & Mostafa Standards Track [Page 94] + +RFC 3108 ATM SDP May 2001 + + +8.2 Security of the SDP description + + The SDP session descriptions might originate in untrusted areas such + as equipment owned by end-subscribers or located at end-subscriber + premises. SDP relies on the security mechanisms of the encapsulating + protocol or layers below the encapsulating protocol. 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 be optionally 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 through configured shared + secrets or 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. Readers are referred to [1] for an + ABNF description of the SDP base line protocol, and to rfc2848, + rfc2543, rfc2045 and rfc2326 for application-specific conventions for + SDP use. For case conventions, see section 2.4. + +; 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 + + + + +Kumar & Mostafa Standards Track [Page 95] + +RFC 3108 ATM SDP May 2001 + + +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" / "-" / "$" + + + +Kumar & Mostafa Standards Track [Page 96] + +RFC 3108 ATM SDP May 2001 + + + ; 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) + + + +Kumar & Mostafa Standards Track [Page 97] + +RFC 3108 ATM SDP May 2001 + + +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" +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) / + + + +Kumar & Mostafa Standards Track [Page 98] + +RFC 3108 ATM SDP May 2001 + + + (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" + + + +Kumar & Mostafa Standards Track [Page 99] + +RFC 3108 ATM SDP May 2001 + + + ; 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 / + + + +Kumar & Mostafa Standards Track [Page 100] + +RFC 3108 ATM SDP May 2001 + + + "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 / + + + +Kumar & Mostafa Standards Track [Page 101] + +RFC 3108 ATM SDP May 2001 + + + "uiLayer1_Prot" ":" uiLayer1Prot / + "chain" ":" chainPointer + +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 + + + +Kumar & Mostafa Standards Track [Page 102] + +RFC 3108 ATM SDP May 2001 + + +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 + + + +Kumar & Mostafa Standards Track [Page 103] + +RFC 3108 ATM SDP May 2001 + + +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 + + [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. + + + +Kumar & Mostafa Standards Track [Page 104] + +RFC 3108 ATM SDP May 2001 + + + [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. + + + + +Kumar & Mostafa Standards Track [Page 105] + +RFC 3108 ATM SDP May 2001 + + + [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-parameters for 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. + + + +Kumar & Mostafa Standards Track [Page 106] + +RFC 3108 ATM SDP May 2001 + + + [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. + + + + +Kumar & Mostafa Standards Track [Page 107] + +RFC 3108 ATM SDP May 2001 + + + [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/Specs for 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. + + + + + + + + + + + + + + + + + + + + + +Kumar & Mostafa Standards Track [Page 108] + +RFC 3108 ATM SDP May 2001 + + +Acknowledgements + + The authors wish to thank several colleagues at Cisco and in the + industry who have contributed towards the development of these SDP + conventions, and who have reviewed, implemented and tested these + constructs. 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 + + 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.com + + + + + + + +Kumar & Mostafa Standards Track [Page 109] + +RFC 3108 ATM SDP May 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kumar & Mostafa Standards Track [Page 110] + |