idnits 2.17.1 draft-rajeshkumar-mmusic-sdp-atm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 59 longer pages, the longest (page 24) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 59 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 148 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 106 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 47 has weird spacing: '.... These conne...' == Line 60 has weird spacing: '... fields defin...' == Line 62 has weird spacing: '...tribute lines...' == Line 64 has weird spacing: '...tribute lines...' == Line 76 has weird spacing: '...xisting path ...' == (143 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 3112, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 3115, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 3118, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 3130, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 3133, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 3140, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 3149, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3154, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 3157, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 3164, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 3167, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 3171, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 3174, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 3176, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 3179, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 3190, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 3194, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 3196, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 3213, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 3217, but no explicit reference was found in the text == Unused Reference: '42' is defined on line 3231, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '3') (Obsoleted by RFC 3551) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-sap-v2-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-mmusic-sap-v2 (ref. '17') ** Obsolete normative reference: RFC 2543 (ref. '18') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 1349 (ref. '19') (Obsoleted by RFC 2474) -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' ** Obsolete normative reference: RFC 2705 (ref. '25') (Obsoleted by RFC 3435) -- No information found for draft-ietf-Megaco-merged - is the name correct? -- Possible downref: Normative reference to a draft: ref. '26' ** Obsolete normative reference: RFC 1826 (ref. '27') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. '28' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '32' -- Possible downref: Non-RFC (?) normative reference: ref. '33' -- Possible downref: Non-RFC (?) normative reference: ref. '34' -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' -- Possible downref: Non-RFC (?) normative reference: ref. '37' -- Possible downref: Non-RFC (?) normative reference: ref. '38' -- Possible downref: Non-RFC (?) normative reference: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' -- Possible downref: Non-RFC (?) normative reference: ref. '41' -- Possible downref: Non-RFC (?) normative reference: ref. '42' -- Possible downref: Non-RFC (?) normative reference: ref. '43' -- Possible downref: Non-RFC (?) normative reference: ref. '44' -- Possible downref: Non-RFC (?) normative reference: ref. '45' -- Possible downref: Non-RFC (?) normative reference: ref. '46' -- Possible downref: Non-RFC (?) normative reference: ref. '47' -- Possible downref: Non-RFC (?) normative reference: ref. '48' ** Obsolete normative reference: RFC 1305 (ref. '49') (Obsoleted by RFC 5905) Summary: 17 errors (**), 0 flaws (~~), 31 warnings (==), 42 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft Rajesh Kumar 4 Document: draft-rajeshkumar-mmusic-sdp-atm-02.txt Mohamed Mostafa 5 July 1, 2000 Cisco Systems 6 Expires: January 1, 2001 8 Conventions for the use of the Session Description Protocol (SDP) 9 for ATM Bearer Connections 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as work in progress. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document described conventions for using the Session Description 35 Protocol (SDP) described in RFC2327 for controlling ATM Bearer 36 Connections, and any associated ATM Adaptation Layer (AAL). The AALs 37 addressed are Type 1, Type 2 and Type 5. This list of conventions is 38 meant to be exhaustive. Individual applications can use subsets of 39 these conventions. Further, these conventions are meant to comply 40 strictly with the SDP syntax as defined in rfc2327. 42 1. Introduction 44 SDP will be used in conjunction with a connection handling / 45 device control protocol such as Megaco (H.248) [26], 46 SIP [18] or MGCP [25] to communicate the information 47 needed to set up ATM bearer connections. These connections include 48 voice connections, voiceband data connections, clear channel circuit 49 emulation connections and baseband data connections (such as fax 50 relay, modem relay, SSCOP, frame relay etc.). 52 These conventions use standard SDP syntax as defined in rfc2327 53 to describe the ATM-level and AAL-level connections, addresses and 54 other parameters. In general, parameters associated with layers 55 higher than the ATM adaptation layer are included only if they are 56 tightly coupled to the ATM or AAL layers. Since the syntax conforms to 57 rfc2327, standard SDP parsers should react in a well-defined and safe 58 manner on receiving session descriptions based on the SDP conventions 59 in this document. This 60 is done by extending the values of fields defined in rfc2327 61 rather than by defining new fields. This is true for all SDP lines 62 except the of the media attribute lines, in which case new 63 attributes are defined. The SDP protocol allows the definition 64 of new attributes in the media attribute lines which are free-form. 65 For the remaining lines, the fact that the field in 66 an SDP descriptor 67 is set to "ATM" should preclude the misinterpretation of extended 68 parameter values by rfc2327-compliant SDP parsers. 70 These conventions are meant to address the following ATM applications: 72 * Applications in which a new SVC is set-up for each service 73 connection. These SVCs could be AAL1 or AAL5 SVCs or 74 single-CID AAL2 SVCs. 76 * Applications in which existing path resources are assigned 77 to service connections. These resources could be 78 AAL1 PVCs (or SPVCs), AAL5 PVCs (or SPVCs), AAL2 single-CID 79 PVCs (or SPVCs), or channels (CIDs) within AAL2 PVCs (or 80 SPVCs) that multiplex multiple CIDs. 82 This document is limited to the case when the network type is ATM. 83 This includes raw RTP encapsulation over AAL5 with no intervening IP 84 layer [46]. It does not address SDP usage for IP, with or without 85 ATM as a lower layer. 87 In some cases, IP connection set-up is independent 88 of lower layers, which are configured prior to it. For example, AAL5 89 PVCs that connect IP routers can be used for VoIP calls. 91 In other cases, VoIP call set-up is closely tied to ATM-level 92 connection set-up. 93 This might require a chaining of IP and ATM descriptors, as described in 94 section 5.7.39. 96 This document makes no assumptions on who constructs the session 97 descriptions (media gateway, intermediate ATM/AAL2 switch, media 98 gateway controller etc.). This will be different in different 99 applications. Further, it allows the use of one session description 100 for both directions of a connection (as in SIP applications) or the 101 use of separate session descriptions for different directions. It 102 addresses the ATM multicast and anycast capabilities. 104 This document makes no assumptions about how the SDP description will 105 be coded. Although the descriptions shown here are encoded as text, 106 alternate codings are possible: 108 - Binary encoding such as ASN.1. This is an option (in addition to 109 text encoding) in the Megaco context. 111 - Use of extended ISUP parameters (Q.1901) to encode the information in 112 SDP descriptors, with conversion to/from binary/text-based SDP 113 encoding when needed. 115 2. Representation of Certain Fields within SDP description lines 117 This document uses all the syntactic conventions of standard SDP as 118 defined in RFC2327. 120 2.1 Representation of Extension Attributes 122 The SDP protocol (RFC2327) requires that non-standard attributes 123 and codec names use an "X-" prefix. 125 In this internet draft, the "X-" prefix is used consistently for 126 codec names (Table 1) that have not been registered with IANA. 128 However, this prefix is not used for the extension SDP attributes 129 defined in this document. This has been done to enhance legibility. 131 This document suggests that parsers be flexible in the use of the 132 "X-" prefix convention. They should accept codec names and 133 attribute names with or without the "X-" prefix. 135 2.2 Representation of Parameter Values 137 Parsers designed to this document should be flexible enough to 138 accommodate decimal and hexadecimal representations. The former 139 do not have a prefix, while the latter should use a 0x prefix. 140 In either case, if the bit field is smaller or larger 141 than the binary equivalent of the SDP representation, then leading 142 0 bits should be added or removed as needed. Thus, 3 and 143 0x3 translate into the following five-bit pattern: 0 0011. 144 The SDP representations 0x12 and 18 translate into the following 145 five-bit pattern: 1 0010. 147 Both single-character and multi-character string values are 148 enclosed in double quotes (i.e. "). By contrast, single quotes 149 (i.e. ') are used for emphasizing keywords rather than to 150 refer to characters or strings. 152 2.3 Directionality Convention 154 This section defined the meaning of the terms 'forward' and 155 'backward' as used in this document. This is specially applicable 156 to parameters that have a specific direction associated with them. 158 In this document, 'forward' refers to the direction away from the 159 Media Gateway, while 'backward' refers to the direction towards the 160 Media Gateway. This convention must be used in all SDP-based session 161 descriptions regardless of whether underlying bearer is an SVC, a 162 dynamically allocated PVC/SPVC or a dynamically allocated CID. This 163 is regardless of which side originates the service connection. If ATM 164 SVC or AAL2 Q.2630.1 signaling is used, the directionality convention 165 is independent of which side originates the SVC or AAL2 connection. 167 This provides a simple way of identifying the direction in which a 168 parameter is applicable, in a manner that is independent of the 169 underlying ATM or AAL2 bearer. This simplicity comes at a price, 170 described below. 172 Note that, the convention used by all ATM/AAL2 signaling 173 specifications (e.g. Q.2931 Section 1.3.3 and Q.2630.1) 174 mandates that 175 forward direction is from the end initiating setup/establishment 176 via bearer signaling towards the end receiving the 177 setup/ establishment request. The backward direction is in the 178 opposite direction. In some cases, the 'forward' and 179 'backward' directions of the ATM signaling convention might 180 be the exact opposite of the SDP convention described above, 181 requiring the media gateway to perform the necessary translation. 182 An example case in which this is needed is described below. 184 Consider an SDP description sent by a media gateway 185 controller to the gateway originating a service-level call. 186 In the backward SVC call set-up model, this gateway terminates 187 (rather than originates) an SVC call. The media gateway refers 188 to the traffic descriptor (and hence the PCR) in the direction 189 away from this gateway as the forward traffic descriptor and 190 forward PCR. Clearly, this is at odds with ATM SVC signaling which 191 refers to this very PCR as the backward PCR. The gateway needs 192 to be able to perform the required swap of directions. In this 193 example, the media gateway terminating the service level call 194 (and hence originating the SVC call) does not need to perform 195 this swap. 197 3. Capabilities Provided by SDP conventions 199 To support these applications, the SDP conventions in this document 200 provide the following session establishment capabilities: 202 * Identification by an ATM network element of its own address, 203 in one of several possible formats. A connection peer can 204 initiate SVC set-up to this address. 206 * Identification of the ATM bearer connection that is to be 207 bound to the narrowband telephony connection. This is either 208 a VCC in AAL1/AAL5 applications or a channel (identified by 209 a CID) in AAL2 applications. This is useful in PVC/SPVC 210 applications. 212 Note that the difference between the PVCs and SPVCs 213 is in the way the bearer virtual circuit connection is set 214 up. From the perspective of this document, the terms PVC and 215 SPVC are equivalent. This is because the bearer connection is 216 already set prior to the time when the SDP description is used 217 to bind it to a narrowband telephony connection. 219 * In AAL1/AAL5 applications, declaration of a set of payload 220 types that can be bound to the ATM bearer connection. 221 RTP payload types that have been registered with IANA are 222 re-used for AAL1 or AAL5. In the manner of standard SDP, 223 unregistered payload types are mapped dynamically. 225 * In AAL2 applications, declaration of a set of profiles that 226 can be bound to the ATM bearer connection. A mechanism for 227 dynamically defining custom profiles within the SDP session 228 description is included. This allows the use of custom 229 profiles for connections that span multi-network interfaces. 231 * A means of correlating narrowband telephony connections with 232 underlying ATM bearer connections. The backbone network 233 connection identifier or bnc-id specified in ITU Q.BICC 234 standardization work is used for this purpose. In order to 235 provide a common SDP base for applications based on 236 ISUP+/Q.BICC and SIP/SIP+, the neutral term 'eecid' is used 237 in lieu of 'bnc-id' in the SDP session descriptor. 239 * A means of specifying the explicit mapping of one codec type 240 and one packetization period into a service type. Service 241 types are voice, voiceband data and facsimile. This is useful 242 in determining the encoding to use when the connection is 243 upspeeded in response to modem or facsimile tones. 245 * A means of describing the QoS class, ATM transfer capability / 246 service category, broadband bearer class, traffic parameters, 247 CPS parameters and SSCS parameters related the underlying 248 bearer connection. 250 4. Format of the ATM Session Description 252 The sequence of lines in the session descriptions in this document 253 conforms to rfc2327 [1]. In general, a session description consists of 254 a session-level part followed by zero or more media-level parts. ATM 255 session descriptions consist of a session level part followed by one 256 or two media-level parts. The only two media applicable are the ATM 257 medium and RTCP control (where applicable). 259 Session descriptor with one media-level part 261 v= (protocol version, zero or one line) 262 o= (origin, zero or one line) 263 s= (session name, zero or one line) 264 c= (connection information, one line) 265 t= (timestamp, zero or one line) 266 m= (media information and transport address, one line) 267 b= (bandwidth, zero or one line) 268 k= (encryption key, zero or one line) 269 a= (media attribute, zero or more lines) 271 Session descriptor with two media-level parts 272 (used in h.323 annex C applications) 274 Session-level part 276 v= (protocol version, zero or one line) 277 o= (origin, zero or one line) 278 s= (session name, zero or one line) 279 c= (connection information, one line) 280 t= (timestamp, zero or one line) 282 media-level part (audio medium) 283 m= (media information and transport address, one line) 284 b= (bandwidth, zero or one line) 285 k= (encryption key, zero or one line) 286 a= (media attribute, zero or more lines) 288 media-level part (control medium) 289 m= (media information and transport address, one line) 290 c= (connection information for control only, one line) 292 In general, the 'v', 'o', 's', and 't' lines are mandatory. 293 However, in the Megaco [26] context, these lines have been made optional. 294 The 'o', 's', and 't' lines are omitted in most MGCP applications. 296 Note that SDP session descriptors for ATM can contain 297 bandwidth (b=) and encryption key (k=) lines. If used, these lines should 298 strictly conform to the SDP standard (rfc2327). The bandwidth (b=) line 299 is redundant in the ATM context since this information can be expressed 300 with greater precision in the atmFtrfcDesc and atmBtrfcDesc 301 media attribute lines. The encryption key line (k=) can be used 302 to indicate an encryption key for the bearer, and a method to 303 obtain the key. At present, the encryption of ATM and AAL2 bearers 304 has not been conventionalized, unlike the encryption of RTP payloads. 305 Nor has the authentication of ATM or AAL2 bearer signaling. 306 In the ATM and AAL2 contexts, the term 'bearer' can include 'bearer 307 signaling' as well as 'bearer payloads'. 309 The order of lines in an ATM session description is exactly in the 310 rfc2327-conformant order depicted above. However, there is no order 311 of the media attribute ('a') lines with respect to other 'a' lines. 313 The SDP protocol version for session descriptions using these 314 conventions is 0. In conformance with standard SDP, it is strongly 315 recommended that the 'v' line be included at the beginning of each 316 SDP session description. In some contexts such as Megaco, the 317 'v' line is optional and may be omitted unless several session 318 descriptions are provided in sequence, in which case the 319 'v' line serves as a delimiter. Depending on the application, 320 sequences of session descriptions might refer to: 321 - Different connections or sessions. 322 - Alternate ways of realizing the same connection or session. 324 The 'o', 's' and 't' lines are included for strict conformance with 325 RFC2327. It is possible that these lines might not carry useful 326 information in some ATM-based narrowband telephony applications. 327 Therefore, some applications might omit these lines, although 328 it is recommended that they not do so. For maximum 329 interoperability, it is preferable that SDP parsers not 330 reject session descriptions that do not contain these lines. 332 5. Structure of the Session Description Lines 334 5.1 The Origin Line 336 The origin line for an ATM-based narrowband telephony session is 337 structured as follows: 339 o= 340 342 The is set to "-". 344 The can be set to one of the following: 346 * an NTP timestamp referring to the moment when the SDP session 347 descriptor was created. 348 * a Call ID, connection ID or context ID that uniquely 349 identifies the session within the scope of a media gateway. 350 Since calls can comprise multiple connections (sessions), 351 call IDs are generally not suitable for this purpose. 353 NTP time stamps can be represented as decimal or hex integers. 354 The part of the NTP timestamp that refers to an integer number 355 of seconds is sufficient. Since this is a 32-bit field, the decimal 356 or hex equivalent of a 32-bit field is adequate if NTP time stamps 357 are used for this purpose. 359 On the other hand, call IDs, connection IDs and context IDs can be 360 represented in decimal or hex format, or as a string of alphanumeric 361 characters. The MGCP connection ID can be 32 hex digits long. 363 In general, to cover all cases, the 364 can comprise of up to 32 digits or 34 alphanumeric characters. The 365 additional two characters allow the inclusion of a "0x" prefix when 366 hex numbers are represented alphanumerically. 368 The refers to the version of the SDP session descriptor 369 (not that of the SDP protocol). This is can be set to one of the 370 following: 372 * 0. 373 * an NTP timestamp referring to the moment when the SDP session 374 descriptor was modified. If the SDP session descriptor has not 375 been modified by an intermediate entity (such as an MGC), 376 then the timestamp will be the same as the 377 timestamp, if any. 379 It is adequate to allow up to 32 decimal or hex digits for 380 the . 382 The in SDP session descriptions for ATM 383 applications should be assigned the string value "ATM". 385 The and parameters are identical to 386 those for the connection information ('c') line. Each of these 387 parameters can be set to a "-". However, it is not recommended 388 that these fields be omitted without being set to a "-" since 389 this is not explicitly allowed by standard SDP (rfc2327). It 390 is recognized that some parser-builders follow this practice. 392 5.2 The Session Name Line 394 In general, the session name line is structured as follows: 396 s= 398 For ATM-based narrowband telephony sessions, the 399 parameter is set to a "-". The resulting 400 lines is: 402 s=- 403 It is not recommended that the be omitted without 404 being set to a "-" since this is not explicitly allowed by 405 standard SDP (rfc2327). It is recognized that some parser-builders 406 follow this practice. 408 s=- 410 5.3 The Connection Information Line 412 The connection information line for ATM-based narrowband telephony 413 sessions is structured as follows: 415 c= 417 The field in the 'c' line should be set to "ATM". 419 When the SDP description is built by a media gateway, the 420 refers to the ATM address of the media gateway 421 building the SDP description. When this description is forwarded 422 to the another gateway, it still contains the original gateway's 423 ATM address. When the media gateway controller builds part or 424 all of the SDP description, the local descriptor contains the 425 ATM address of the local media gateway, while the remote descriptor 426 contains the ATM address of the remote media gateway. Additionally, 427 in all contexts, the 'm' line can have an ATM address in the 428 subparameter which, if present, is the 429 remote address if the 'c' line address is local, and vice versa. 431 The can be NSAP, E164 or GWID (ALIAS). 433 The format depends on the . 435 NSAP: If the ATMaddressType is NSAP, the ATMaddress is expressed as 436 a string of 40 hex characters without the "0x" prefix. As an option, 437 dots can be included after 16-bit fields, with the first dot following 438 an 8-bit field. The last octet of the NSAP 439 address is the 'selector' field that is not used for ATM addressing 440 and is available for non-standard use. The prior six octets of the 441 NSAP are an IEEE 802 MAC address assigned to the gateway. For 442 example: 444 c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 446 E164: If the ATMaddressType is E164, the ATMaddress is expressed as 447 a decimal number with up to 15 digits. For example: 449 c=ATM E164 9738294382 451 The use of E.164 numbers in the B-ISDN context is defined in ITU E.191. 452 There is a disparity between the ATM forum and the ITU 453 in the use of E.164 numbers for ATM addressing. The ATM forum (e.g. UNI 454 Signaling 4.0) allows only International Format E.164 numbers, while 455 the ITU (e.g. Q.2931) allows private numbering plans. Since the goal 456 of this SDP specification is to interoperate with all bearer signaling 457 protocols, it allows the use of numbers that do not conform to the 458 E.164 International Format. However, to maximize overall consistency, 459 network administrators can restrict the provisioning of numbers to the 460 E.164 International Format. 462 GWID (ALIAS): If the ATMaddressType is GWID meaning that the address is a 463 private Voice Gateway identifier (unique within context of network), 464 the ATMaddress is expressed as alphanumeric string ("A"-"Z", "a"-"z", "0"- 465 "9",".","-","_"). For example: 467 c=ATM GWID officeABCmgx101vism12 469 Since these SDP conventions can be used for more than gateways, the 470 string "ALIAS" can be used instead of "GWID" in the 'c' line. Thus, 471 the example above is equivalent to: 473 c=ATM ALIAS officeABCmgx101vism12 475 An example of a GWID (ALIAS)is the CLLI code used for telecom 476 equipment. For all practical purposes, it should be adequate for the 477 GWID (ALIAS) to be a variable length string with a maximum size of 32 478 characters. Since this identifier is private to a network, some 479 network administrations might restrict it to a smaller size (e.g. 10 480 characters). 482 The connection information line is always present in an SDP session 483 descriptor. However, if there is no address to transmit, this line 484 can be represented in one of the equivalent ways: 486 c=ATM - - 488 This might be used when the address is known a priori. It is not 489 recommended that or be omitted 490 without being set to a "-" since this is not explicitly allowed 491 by standard SDP (rfc2327). It is recognized that some parser-builders 492 follow this practice. 494 5.4 The Timestamp Line 496 The timestamp line for an SDP session descriptor is structured as 497 follows: 499 t= 501 For ATM-based narrowband telephony sessions, the 502 parameter can be made equal to the NTP timestamp (if any) used for 503 the in the 'o' line. It can also be set to 0 504 indicating its irrelevance. If it made equal to the NTP timestamp 505 in seconds, the fractional part of the NTP timestamp is omitted. 506 In this case, 507 it is adequate to allow the hex or decimal equivalent of a 32-bit 508 field. Per Ref. [49], NTP time stamps need a 32 bit unsigned 509 representation of seconds, and a 32 bit unsigned representation of 510 fractional seconds. 512 The parameter is set to 0 in the ATM-based narrowband 513 telephony context. 515 5.5 Media Information Line for AAL1 and AAL5 sessions 517 See Section 6.0 for the representation, in SDP, of the parameters 518 in the media information line. 520 The media information line for AAL1-based narrowband telephony 521 sessions is structured as follows: 523 m=audio AAL1/AVP 524 ... 526 The media information line for AAL5-based narrowband telephony 527 sessions is similar, with the exception that the string "AAL5" 528 replaces the string "AAL1". This is depicted below: 530 m=audio AAL5/AVP 531 ... 533 In most AAL1 and AAL2 applications, the ordering of payload types 534 implies a preference (preferred payload types before less favored 535 ones). 537 Note that it is not possible to make this line identical to the 'm' 538 line in VoAAL2 due to basic differences between the two 539 applications. 541 The parameter can be in one of two basic 542 formats: with explicit designation of subparameter types within 543 the parameter, or with implicit 544 inference of subparameter type from subparameter position in 545 the parameter. 547 With explicit designation of subparameter types, the 548 parameter can be in one of the following 549 formats: 550 * VCCI- 551 * -/VCCI- 552 * BCG-/VCCI- 553 * PORT-/VPI-/VCI- 554 * BCG-/VPI-/VCI- 555 * VPCI-/VCI- 557 With implicit inference of subparameter type from 558 subparameter position, the parameter can 559 be in one of the following formats: 560 * 561 * -/ 562 * / 563 * / 564 * // 565 * // 566 * / 568 In the implicit case, the application context and/or the existence 569 and positions of hyphens and slashes is used to differentiate 570 between the various options. Within the SDP 571 media information line, , , , and are 572 decimal numbers (no prefix) or hexadecimal numbers (0x prefix). The 573 and are identical 574 to their definitions above for the connection information line with 575 the difference that this address refers to the remote peer in the 576 media information line. 578 A "$" notation implies 'any'. A "$" can be used in lieu the entire 579 parameter or some or all of its subparameters. 580 The constant strings in the can be retained 581 in the "$" wildcard or omitted consistent with the 'explicit' and 582 'implicit' formats described above. 584 Note that a "$" can be used in lieu of the concatenation 585 - in the following ways: 586 * The entire concatenation, -, is 587 replaced with a "$". 588 * is replaced with a "$", but is 589 not. 591 There are contexts such as SVC-based applications where there 592 is no need to communicate the parameter 593 across the MGC - MG interface. In these contexts, 594 it is sufficient to use a "$", "$/$" or "$/$/$" for the 595 parameter in both directions of 596 communication. 598 When the network uses PVCs the VCCI values are pre-provisioned. If 599 connections are established via SVCs or SPVCs, the VCCI is selected 600 from the list of available VCCIs. The VCCI can be signaled end-to- 601 end within the Generic Information Transport (GIT) as part of the 602 ITU Recommendation Q.2931 Setup message per ITU Recommendation 603 Q.2941.2. The VCCI glare avoidance scheme defined in [32] and [44] 604 is not adequate for preventing glare when a pool of existing 605 PVCs/SPVCs is dynamically assigned to calls. In this 606 context, a mechanism for glare reduction such as assigning 607 the nearest available values from different ends of the VCCI range 608 is needed. 610 The definition of guarantees uniqueness between a pair of ATM 611 nodes. When the MGC communicates with an ATM MG, it can qualify the 612 with the ATM address of the remote node. Network administrations 613 have the option of provisioning the uniquely in a network, 614 or in subnets of the network. In this case, the ATM address of the 615 far end can be omitted. 617 The parameter is used to identify the physical trunk port 618 on a stand-alone gateway or on a multiplexer into which the 619 gateway is plugged as a tributary module. It can be represented as a 620 decimal or 621 hex number of up to 32 digits, or an alphanumeric string of up to 32 622 characters. In general, to cover all cases, the 623 can comprise of up to 32 digits or 34 alphanumeric characters. The 624 additional two characters allow the inclusion of a "0x" prefix when 625 hex numbers are represented alphanumerically. 627 The and have their usual ATM connotation. 629 In some applications, it is meaningful to use a VPCI, a sixteen 630 bit field, in SDP descriptors. The VPCI is similar to the VPI, except 631 for its width and the fact that it retains its value across VP 632 crossconnects. Normally, the VPCI values are unique within the set 633 of VPs controlled by an SVC/SPVC signaling channel. 635 In some applications, it is meaningful to bundle a set of connections 636 between a pair of ATM nodes into a bearer connection group. The 637 subparameter is an eight bit field that allows the bundling of up 638 to 255 connections. 640 Although RTP encapsulation defined in rfc1889 is not used, the 641 payload type variables are used exactly as defined in rfc1890. 642 Hence, the protocols used for VoAAL1 and VoAAL5 are identified as 643 AAL1/AVP and AAL5/AVP in the media information line. 645 Following the text string "AAL1/AVP" or "AAL5/AVP", there is a 646 list of payload types. The ordering of these payload types 647 (preferred codecs before less favored ones) can indicate 648 preference is some applications. These can be either statically 649 assigned or dynamically mapped payload types. Encodings that 650 are not statically mapped to payload types by IANA [31] are to 651 be dynamically mapped at the time of connection establishment 652 to payload types in the decimal range 96-127. The SDP 'atmmap' 653 attribute (similar to 'rtpmap') is used for this purpose. 655 The following are examples of the use of the media information line 656 in the descriptions of AAL1 narrowband telephony sessions. 658 Example 1: 659 m=audio 27 AAL1/AVP 18 0 96 660 a=atmmap:96 G727-32 662 implies that the AAL1 VCCI=27 and that the supported encoding 663 formats are G.729 (or G.729a), PCM Mu-law and 32 kbps G.727. 665 Example 2: 666 m=audio 3/4/50 AAL1/AVP 8 15 668 implies that the AAL1 virtual circuit used has VPI=4, VCI=50 and is 669 on trunk port #3. Further, it implies that the encoding formats are 670 G.711 A-law and G.728. 672 Example 3: 673 m=audio $ AAL1/AVP 8 15 675 implies that any AAL1 VCC may be used (subject to glare rules). 677 Example 4: 678 m=audio 2/6/$ AAL1/AVP 8 15 680 implies that any VCI on VPI= 6 of trunk port #2 may be used. 682 In some applications, an "-" can be used in lieu of the 683 . It is also legal to use an "-" instead of 684 the string "AAL1/AVP". In this case, the coding scheme and 685 the adaptation schemes are described elsewhere, or defaulted. 687 Example 5: 688 m=audio 234 - - 689 a=aalType:AAL1 691 Example 6: 692 m=audio 234 AAL1/AVP - 694 Examples 5 and 6 both indicate an audio medium, a VCCI of 234, AAL1 695 adaptation and an unspecified codec. 697 5.6 Media Information Line for AAL2 sessions 699 See Section 6.0 for the representation, in SDP, of the parameters 700 in the media information line. 702 The media information line for AAL2-based narrowband telephony 703 sessions is structured as follows: 705 m=audio ... 706 ... ... 707 709 In most applications, the ordering of profiles implies 710 a preference (preferred profiles before less favored ones). If 711 so, then there can be multiple instances of the same profile 712 type in the same 'm' line. 714 Note that it is not possible to make this line identical to the 'm' 715 line in Voice-over-AAL1 due to basic differences between the two 716 applications. 718 The parameter can be in one of the following 719 formats: 721 * / 722 * -// 723 * /// 724 * /// 725 * // 726 * / 728 The parameter can be in one of two basic 729 formats: with explicit designation of subparameter types within 730 the parameter, or with implicit 731 inference of subparameter type from subparameter position in 732 the parameter. 734 With explicit designation of subparameter types, the 735 parameter can be in one of the following 736 formats: 737 * VCCI-/CID- 738 * -/VCCI-/CID- 739 * BCG-/VCCI-/CID- 740 * PORT-/VPI-/VCI-/CID- 741 * BCG-/VPI-/VCI-/CID- 742 * VPCI-/VCI-/CID- 744 With implicit inference of subparameter type from 745 subparameter position, the parameter can 746 be in one of the following formats: 747 * / 748 * -// 749 * // 750 * // 751 * /// 752 * /// 753 * // 755 In the implicit case, the application context and/or the existence 756 and positions of hyphens and slashes is used to differentiate 757 between the various options. Within the SDP 758 media information line, , , , , and 759 are decimal numbers (no prefix) or hexadecimal numbers (0x 760 prefix). The and are identical 761 to their definitions above for the connection information line with 762 the difference that this address refers to the remote peer in the 763 media information line. 765 A "$" notation implies 'any'. A "$" can be used in lieu the entire 766 parameter or some or all of its subparameters. 767 The constant strings in the can be retained 768 in the "$" wildcard or omitted consistent with the 'explicit' and 769 'implicit' formats described above. 771 Note that a "$" can be used in lieu of the concatenation 772 - in the following ways: 773 * The entire concatenation, -, is 774 replaced with a "$". 775 * is replaced with a "$", but is 776 not. 778 There are contexts such as SVC-based applications where there 779 is no need to communicate the parameter 780 across the media gateway controller - media gateway interface. In these 781 contexts, it is sufficient to use a "$", "$/$", "$/$/$" or "$/$/$/$" 782 for the parameter. 784 When the network uses PVCs the VCCI values are pre-provisioned. If 785 connections are established via single-CID SVCs or S/PVCs, the VCCI 786 is selected from the list of available VCCIs. The VCCI can be 787 signaled end-to-end within the Generic Information Transport (GIT) 788 as part of the ITU Recommendation Q.2931 Setup message per ITU 789 Recommendation Q.2941.2. The VCCI glare avoidance scheme defined in 790 [32] and [44] 791 is not adequate for preventing glare when a pool of existing 792 PVCs/SPVCs is dynamically assigned to calls. In this 793 context, a mechanism for glare reduction such as assigning 794 the nearest available values from different ends of the VCCI range 795 is needed. 797 The definition of guarantees uniqueness between a pair of ATM 798 nodes. When the MGC communicates with an ATM MG, it can qualify the 799 with the ATM address of the remote node. Network administrations 800 have the option of provisioning the uniquely in a network, 801 or in subnets of the network. In this case, the ATM address of the 802 far end can be omitted. 804 If no intermediate subcell switching or multiplexing is involved, 805 identical CIDs within the same VCC are used at both MGs. 806 If intermediate subcell switching or multiplexing is involved, 807 then the CIDs can be different at the two MGs. However, at 808 an MG and at the first-hop AAL2 switch it interfaces to, the same 809 CIDs within the same VCC are used. Since calls can be initiated at 810 either end, CIDs within the same VCC may be assigned at each end, 811 giving rise to the possibility of glare. In this context, 812 a mechanism for glare reduction such as assigning the nearest 813 available values from different ends of the CID range is needed. 815 The parameter is used to identify the physical trunk port 816 on a stand-alone gateway or on a multiplexer into which the 817 gateway is plugged as a tributary module. It can be represented as a 818 decimal or 819 hex number of up to 32 digits, or an alphanumeric string of up to 32 820 characters. If represented in hex format, the 32 digits do not include 821 the "0x" prefix ("x" is not a digit, anyway). 823 The and have 824 their usual ATM connotation. 826 In some applications, it is meaningful to use a VPCI, a sixteen 827 bit field, in SDP descriptors. The VPCI is similar to the VPI, except 828 for its width and the fact that it retains its value across VP 829 crossconnects. Normally, the VPCI values are unique within the set 830 of VPs controlled by an SVC/SPVC signaling channel. 832 In some applications, it is meaningful to bundle a set of connections 833 between a pair of ATM nodes into a bearer connection group. The 834 subparameter is an eight bit field that allows the bundling of up 835 to 255 connections. 837 The parameter indicates the type of profile. It is 838 expressed in the format AAL2/ where 839 identifies the source of the definition of the profile. 841 The can be assigned a string value indicating the 842 source of the subsequent profile numbers 843 until the next field. The following rules apply to 844 the contents of the field: 846 - = "ITU" indicates profiles defined by ITU. 847 Examples: profiles defined in the I.366.2 specification [13]. 848 - = "ATMF" indicates profiles defined by ATM 849 forum. Examples: profiles defined in the AF-VTOA-0113 850 specification [44]. 851 - = "custom" indicates profiles defined by 852 an organization other than the ITU or ATMF. In multi-vendor 853 networks where this value is used, care 854 should be taken to preclude inconsistent definitions. 855 - = 856 An equipment vendor or service provider can use its registered, 857 globally unique corporate name (e.g. Cisco, Telcordia etc.) as a 858 string value of the . It is suggested that organizations 859 maintain consistent definitions of the advertised AAL2 profiles 860 that bear their corporate name. 861 - The can be based on IEEE Standard 802-1990, 862 Section 5.1, 863 which defines the globally unique, IEEE-administered, three-octet 864 OUIs used in MAC addresses and protocol identifiers. In this case, 865 the field shall be assigned a string value of 866 "IEEE:" concatenated with where is the hex representation 867 of a three-octet field identical to the IEEE OUI. As a hex representation, 868 it can be preceded by a 0x prefix, which can also be omitted. For example, 869 "IEEE:00000C" refers to Cisco Systems, Inc. 871 The parameter is expressed as a decimal number. The value 872 of for profiles of the type AAL2/ITU or AAL2/ATMF are in 873 range 1-255 in accordance with ITU-T I.366.2 Annex P [13] and AF-VTOA- 874 0113 [44]. For other types of profiles, a range of 1-255 should be 875 adequate. 877 For example, the media information line may look like: 879 m=audio 123/5 AAL2/ITU 1 881 This media line indicates that the media contains audio. The VCCI 882 for the AAL2 connection is decimal 123 and the CID is decimal 5. The 883 AAL2 connection uses ITU profile 1 as defined in I.366.2 [13]. 885 m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1 887 implies that any AAL2 VCC may be used (subject to glare rules). If 888 this list is preferentially ordered, then AAL2/ITU 8 has the highest 889 priority. 891 In some applications, an "-" can be used in lieu of the 892 and fields. This is possible when the coding scheme is 893 described elsewhere e.g. when 'aal2_SSCS_3662' attribute indicates 894 = "on" and any other competing options as "off", and the 895 attribute indicates AAL2. An example 896 of the use of the 'm' line in this case is: 898 m=audio 123/5 - - 899 a=aalType:AAL2 900 a=aal2_SSCS_3662:audio off off on off on off off off - - - 902 Besides indicating an audio medium, a VCCI of 123 and a CID of 5, 903 the 'm' line indicates an unspecified profile. 905 5.7 The Media Attribute Lines 907 In an SDP line sequence, the media information line 'm' is 908 followed by one or more media attribute or 'a' lines. Media 909 attribute lines are per the format below: 911 a=: 913 or 915 a= 917 In general, media attribute lines are optional except when needed to 918 qualify the media information line. This qualification is necessary 919 when the "m" line for an AAL1 or AAL5 session specifies a payload 920 type that needs to be dynamically mapped. The 'atmmap' media 921 attribute line defined below is used for this purpose. 923 In attribute lines, subparameters that are meant to be left 924 unspecified are set to a "-". These are generally inapplicable or, if 925 applicable, are known by other means such as provisioning. In some 926 cases, a media attribute line with all parameters set to "-" carries 927 no information and should be preferably omitted. In other cases, 928 such as the 'lij' media attribute line, the very presence of the 929 media attribute line conveys meaning. 931 There are no restrictions placed by rfc2327 [1] regarding the order 932 of 'a' lines with respect to other 'a' lines. However, these lines 933 must not contradict each other or the other SDP lines. Inconsistencies 934 are not to be ignored 935 and should be flagged as errors. Repeated lines shall result in the 936 later lines supplanting earlier ones. 938 Applications will selectively use the optional media attribute 939 lines listed below. This is meant to be an exhaustive list for 940 describing the general attributes of ATM bearer networks. However, 941 it is recognized that this list might have overlooked some attributes, 942 which particular applications might need. If these are common 943 enough for general interoperability between vendors (as opposed 944 to innovation and proprietary differentiation by particular 945 vendors), then these should be brought to the attention of the 947 IETF MMUSIC working group for incorporation into future releases 948 of this document. 950 * The attributes defined in RFC2327 which allow indication of 951 the direction in which a session is active. These are 952 a=sendonly, a=recvonly, a=sendrecv, a=inactive. 953 * The 'Ptime' attribute defined in RFC2327. It indicates the 954 packet period. The 'ptime' media attribute line should not 955 be used in AAL2 applications, since this information is included 956 in the profiles listed in the 'm' line. This information can 957 also be included in the 'vsel', 'dsel' and 'fsel' lines. If 958 the 'ptime' line is included in AAL2 applications, then it can 959 be ignored or flagged as an error. The latter is preferred 960 for robustness and simplicity. The 'ptime' is not applicable 961 in the AAL1 context, where is should be flagged as an error. 962 In the AAL5 context, 963 the 'Ptime' media attribute line, if used, should be consistent 964 with the 'vsel', 'dsel' and 'fsel' lines, if any. Here, 965 consistency means the ability to yield a non-empty intersection 966 with one of these lines. 967 * The 'atmmap' attribute. In the AAL1 and AAL5 contexts, this is 968 used to dynamically map payload types into codec strings. 969 * The 'eecid' attribute. This stands for 'end-to-end connection 970 identifier'. It provides a means of correlating narrowband 971 telephony connections with underlying ATM bearer connections. 972 In the Q.BICC/ISUP+ context, the eecid is synonymous with the 973 bnc-id (backbone network connection identifier). In the SDP 974 session description, the more general term 'eecid' is used in 975 order to provide a common SDP baseline for ATM telephony 976 applications using Q.BICC/ISUP+ and SIP/SIP+. 977 * The 'aalType' attribute. This is used to indicate the nature 978 of the ATM adaptation layer (AAL). 979 * The 'silenceSupp' attribute, used to indicate the use of 980 of voice activity detection for silence suppression, and to 981 optionally parameterize the silence suppression function. 982 * The 'ecanf' and 'ecanb' attributes, used to indicate the use of 983 of echo cancellation, and to parameterize the this function. 984 * The 'gcf' and 'gcb' attributes, used to indicate the use of 985 of gain control, and to parameterize the this function. 986 * The 'profiledesc' attribute which can be used to describe 987 AAL2 profiles. Although any AAL2 profile can be so described, 988 this attribute is useful for describing, at connection 989 establishment time, custom profiles that might not be known 990 to the far end. This attribute applies in the AAL2 context 991 only. 992 * The 'vsel' attribute which indicates a prioritized list of 993 3-tuples for voice service. Each 3-tuple indicates a codec, 994 an optional packet length and an optional packetization 995 period. This complements the 'm' line information and should 996 be consistent with it. 997 * The 'dsel' attribute which indicates a prioritized list of 998 3-tuples for voiceband data service. Each 3-tuple indicates a 999 codec, an optional packet length and an optional packetization 1000 period. This complements the 'm' line information and should 1001 be consistent with it. 1003 * The 'fsel' attribute which indicates a prioritized list of 1004 3-tuples for facsimile service. Each 3-tuple indicates a 1005 codec, an optional packet length and an optional packetization 1006 period. This complements the 'm' line information and should 1007 be consistent with it. 1008 * The 'capability' attribute which indicates the ATM transfer 1009 capability (ITU nomenclature) synonymous with the ATM Service 1010 Category (ATMF nomenclature). 1011 * The 'qosclass' attribute which indicates the QoS class of the 1012 ATM bearer connection. 1013 * The 'bcob' attribute which indicates the broadband connection 1014 oriented bearer class. 1015 * The 'stc' attribute which indicates susceptibility to 1016 clipping. 1017 * The 'upcc' attribute which indicates susceptibility the 1018 user plane connection configuration. 1019 * The 'atmQOSfparms' and 'atmQOSbparms' attributes are 1020 used to describe certain key ATM QoS parameters in the forward 1021 and backward directions respectively. 1022 * The 'aal2QOSfparms' and 'aal2QOSbparms' attributes which 1023 are placeholders for AAL2-level impairments, yet to be defined. 1024 These attributes may be withdrawn if not needed. 1025 * The 'atmFtrfcDesc' and 'atmBtrfcDesc' attributes which are 1026 used to describe ATM traffic descriptor parameters in the 1027 forward and backward directions respectively. 1028 * The 'aal2FtrfcDesc' and 'aal2BtrfcDesc' attributes which 1029 are placeholders for AAL2-level traffic descriptors, 1030 yet to be defined. These attributes may be withdrawn if not 1031 needed. 1032 * The 'abrFparms' and 'abrBparms' attributes which are 1033 used to describe ABR-specific parameters in the 1034 forward and backward directions respectively. These parameters 1035 are per the UNI 4.0 signaling specification [5]. 1036 * The 'clkrec' attribute which indicates the clock recovery 1037 method for AAL1 unstructured data transfer (UDT). 1038 * The 'fec' attribute which indicates the use of 1039 forward error correction. 1040 * The 'prtfl' attribute which indicates indicate the fill 1041 level of partially filled cells. 1042 * The 'bearertype' attribute is used to indicate 1043 whether the underlying bearer is an ATM PVC/SPVC, an ATM SVC, 1044 or an AAL2 CID connection within an existing ATM PVC/SPVC. 1045 * When present, the 'structure' attribute is used to indicate 1046 the presence or absence of AAL1 structured data transfer (SDT), 1047 and the size of the SDT blocks. 1048 * When present, the 'sbc' media attribute line denotes the 1049 subchannel count in the case of n x 64 clear channel 1050 communication. 1051 * When present, the 'fcpssdusize' and 'bcpssdusize' 1052 attributes are used to indicate the maximum size of the 1053 CPCS SDU payload in the forward and backward directions. 1054 * When present, the 'aal2CPS' attribute is used to 1055 indicate that an AAL2 CPS sublayer as defined in 1056 ITU I.363.2 [13] is associated with VCC referred to in the 1057 'm' line. Optionally, it can be used to indicate selected 1058 CPS options and parameter values for this VCC. 1060 * When present, the 'aal2_sscs_3661' attribute is used to 1061 indicate the presence of an AAL2 SSCS sublayer as defined 1062 in ITU I.366.1 [12]. Optionally, it can be used to indicate 1063 selected options and parameter values for this SSCS. 1064 * When present, the 'aal2_SSCS_3662' attribute is used to 1065 indicate the presence of an AAL2 SSCS sublayer as defined 1066 in ITU I.366.2. Optionally, it can be used to indicate 1067 selected options and parameter values for this SSCS. 1068 * When present, the 'aal2_sscs_3652' attribute is used to 1069 indicate the use, in conjunction with AAL2, of a 1070 service-specific coordination function, as defined in 1071 ITU I.365.2 [40], for Connection Oriented Network Service 1072 (SSCF-CONS). 1073 * When present, the 'aal2_sscs_3653' attribute is 1074 used to indicate the use, in conjunction with AAL2, 1075 of a service-specific coordination function, as defined 1076 in ITU I.365.3 [41], for Connection Oriented Transport Service 1077 (SSCF-COTS). 1078 * When present, the 'AAL5app' attribute is used to 1079 indicate the presence of an application that uses AAL5, 1080 and to point to the controlling standard for the 1081 application layer. 1082 * When present, the 'lij' attribute is used to indicate the 1083 presence of a connection that uses the Leaf-initiated-join 1084 capability described in UNI 4.0 [5], and to optionally 1085 describe parameters associated with this capability. 1086 * When present, the 'anycast' attribute line is used to 1087 indicate the applicability of the anycast function described 1088 in UNI 4.0 [5], and to optionally qualify it with certain 1089 parameters. 1090 * When present, the 'wtp' media attribute line is used to specify 1091 the circuit used to deliver a tapped stream. 1092 * The 'fmtp' attribute line defined in the SDP standard can be 1093 used to describe higher-layer parameters. These that pertain 1094 to layers higher than the ATM adaptation layer and that are 1095 not closely coupled with the ATM or ATM adaptation layers. 1096 Examples are the B-HLI and B-LLI IEs specified in ITU Q.2931 [15], 1097 and the user-to-user information element described in 1098 ITU Q.2957 [48]. 1099 * The 'chain' attribute line is used to chain consecutive SDP 1100 descriptions. 1102 5.7.1 The 'atmmap' attribute 1104 The 'atmmap' attribute is defined on the basis of the 'rtpmap' 1105 attribute used in RFC2327. 1107 a=atmmap: 1109 The 'atmmap' attribute is used to dynamically map encoding names 1110 into payload types. This is necessary for those encoding names which 1111 have not been assigned a static payload type through IANA. Payload 1112 types and encoding techniques that have been registered with IANA 1113 for RTP are retained for narrowband telephony based on AAL1 or 1114 AAL5. 1116 The range of statically defined payload types is in the range 1117 0-95. All static assignments of payload types to codecs are 1118 listed in [31]. The range of payload types defined dynamically 1119 via the 'atmmap' attribute is 96-127. 1121 The encoding names in Table 1 are case-insensitive. 1123 Table 1: Encoding Names and Payload Types 1124 |---------------------|--------------|---------------------------| 1125 | Encoding Technique | Encoding Name| Payload type | 1126 |---------------------|--------------|---------------------------| 1127 | PCM - Mu law | "PCMU" | 0 (Statically Mapped) | 1128 |---------------------|--------------|---------------------------| 1129 | 32 kbps ADPCM | "G726-32" | 2 (Statically Mapped) | 1130 |---------------------|--------------|---------------------------| 1131 |Dual rate 5.3/6.3kbps| "G723" | 4 (Statically Mapped) | 1132 |---------------------|--------------|---------------------------| 1133 | PCM- A law | "PCMA" | 8 (Statically Mapped) | 1134 |---------------------|--------------|---------------------------| 1135 | 7 KHz audio coding | "G722" | 9 (Statically Mapped) | 1136 | within 64 kbps | | | 1137 |---------------------|--------------|---------------------------| 1138 | LD-CELP | "G728" | 15 (Statically Mapped) | 1139 |---------------------|--------------|---------------------------| 1140 | CS-ACELP | "G729" | 18 (Statically Mapped) | 1141 |(normal/low-complexity) | | 1142 |---------------------|--------------|---------------------------| 1143 | Low-complexity | "X-G729a" | None, map dynamically | 1144 | CS-ACELP | | | 1145 |---------------------|--------------|---------------------------| 1146 |Normal | "X-G729b" | None, map dynamically | 1147 |CS-ACELP w/ ITU | | | 1148 |defined silence | | | 1149 |suppression | | | 1150 |---------------------|--------------|---------------------------| 1151 |Low-complexity | "X-G729ab" | None, map dynamically | 1152 |CS-ACELP w/ ITU | | | 1153 |defined silence | | | 1154 |suppression | | | 1155 |---------------------|--------------|---------------------------| 1156 | 16 kbps ADPCM | "X-G726-16" | None, map dynamically | 1157 |---------------------|--------------|---------------------------| 1158 | 24 kbps ADPCM | "X-G726-24" | None, map dynamically | 1159 |---------------------|--------------|---------------------------| 1160 | 40 kbps ADPCM | "X-G726-40" | None, map dynamically | 1161 |---------------------|--------------|---------------------------| 1162 | Dual rate 5.3/6.3 |"X-G7231-H" | None, map dynamically | 1163 | kbps - high rate | | | 1164 |---------------------|--------------|---------------------------| 1165 | Dual rate 5.3/6.3 |"X-G7231-L" | None, map dynamically | 1166 | kbps - low rate | | | 1167 |---------------------|--------------|---------------------------| 1168 | Dual rate 5.3/6.3 |"X-G7231a-H" | None, map dynamically | 1169 | kbps - high rate w/ | | | 1170 | ITU-defined silence | | | 1171 | suppression | | | 1172 |---------------------|--------------|---------------------------| 1174 ------------------------------------------------------------------ 1175 | Dual rate 5.3/6.3 |"X-G7231a-L" | None, map dynamically | 1176 | kbps - high rate w/ | | | 1177 | ITU-defined silence | | | 1178 | suppression | | | 1179 |---------------------|--------------|---------------------------| 1180 | 16 kbps EADPCM | "X-G727-16" | None, map dynamically | 1181 |---------------------|--------------|---------------------------| 1182 | 24 kbps EADPCM | "X-G727-24" | None, map dynamically | 1183 |---------------------|--------------|---------------------------| 1184 | 32 kbps EADPCM | "X-G727-32" | None, map dynamically | 1185 |---------------------|--------------|---------------------------| 1186 |n x 64 kbps Clear | "X-CCD" | None, map dynamically | 1187 |Channel without CAS | | | 1188 |per af-vtoa-78 [7] | | | 1189 |---------------------|--------------|---------------------------| 1190 |n x 64 kbps Clear | "X-CCD-CAS" | None, map dynamically | 1191 |Channel with CAS | | | 1192 |per af-vtoa-78 [7] | | | 1193 |---------------------|--------------|---------------------------| 1194 |GSM Full Rate | "GSM" | 3 (Statically Mapped) | 1195 |---------------------|--------------|---------------------------| 1196 |GSM Half Rate | "X-GSM-HR" | None, map dynamically | 1197 |---------------------|--------------|---------------------------| 1198 |GSM-Enhanced Full Rate "X-GSM-EFR" | None, map dynamically | 1199 |---------------------|--------------|---------------------------| 1200 |GSM-Enhanced Half Rate "X-GSM-EHR" | None, map dynamically | 1201 |---------------------|--------------|---------------------------| 1202 |Group 3 fax demod. "X-FXDMOD-3" | None, map dynamically | 1203 |---------------------|--------------|---------------------------| 1205 5.7.2 The 'eecid' attribute 1207 The 'eecid' attribute is synonymous with the 4-byte'bnc-id' 1208 parameter used by T1SI, the ATM forum and the ITU (Q.1901) 1209 standardization effort. The term 'eecid' stands for 'end-to-end 1210 connection identifier', while 'bnc-id' stands for 'backbone network 1211 connection identifier'. The name "backbone" is slightly misleading 1212 since it refers to the entire ATM network including the ATM edge and 1213 ATM core networks. In Q.1901 terminology, an ATM "backbone" 1214 connects TDM or analog edges. 1216 While the term 'bnc-id' might be used in the bearer signaling plane 1217 and in an ISUP (Q.1901) call control plane, SDP session descriptors 1218 use the neutral term 'eecid'. This provides a common SDP baseline 1219 for applications that use ISUP and applications that use 1220 SIP/SIP+. 1222 In the forward SVC establishment model, the call-originating gateway 1223 initiates SVC establishment and transmits an eecid to the call- 1224 terminating gateway via SDP. 1226 In backward SVC establishment model, the call-originating gateway 1227 does not initiate SVC establishment. However, it transmits an 1228 eecid to the call-terminating gateway via SDP. The call-terminating 1229 gateway initiates SVC establishment. 1231 The value of the eecid attribute values needs to be unique within 1232 the gateway initiating the SVC set-up but not across multiple 1233 gateways. Hence, the SVC-initiating gateway has complete control 1234 over using and releasing values of this parameter. The eecid 1235 attribute is used to correlate, one-to-one, received SVC SETUP 1236 requests with service connection requests from the media gateway 1237 controller. In the forward call model, the call-terminating gateway 1238 uses the ATM address of the call-originating gateway in the 'c' line 1239 of the session description to qualify the eecid. This is because 1240 multiple call-originating gateways can sending identical eecids. 1242 Within an SDP session description, the eecid attribute is used as 1243 follows: 1245 a=eecid: 1247 where consists of up to 8 hex digits (equivalent to 4 1248 octets). 1250 This SDP document does not specify how the eecid (synonymous 1251 with bnc-id) is to be communicated through bearer signaling 1252 (Q.931, UNI, PNNI, AINI, IISP, proprietary signaling equivalent, 1253 Q.2630.1). This is a task of these bearer signaling protocols. 1254 However, the following informative statements are made to 1255 convey a sense of the interoperability that is a goal of 1256 current standardization efforts: 1257 - ITU Q.2941.3 and the ATMF each recommend the use of the 1258 GIT IE for carrying the eecid (synonymous with bnc-id) 1259 in the set-up message of ATM signaling protocols (Q.2931, 1260 UNI 4.0, PNNI, AINI, IISP). 1261 The coding for carrying the eecid (bnc-id) in the GIT IE 1262 is defined in ITU Q.2941.3 and accepted by the ATM forum. 1263 - Another alternate method is to use the called party 1264 subaddress IE in the backward SVC call establishment model, 1265 and the calling party subaddress IE in the forward SVC call 1266 establishment model. This might be construed to be a protocol 1267 violation and is not the recommended means of carrying 1268 the eecid (bnc-id). The GIT IE is the preferred method of 1269 transporting the eecid (bnc-id) in ATM signaling messages. 1271 - The establish request (ERQ) message of the Q.2630.1 [37] 1272 signaling protocol can use the SUGR (Served User Generated 1273 Reference) IE to transport the eecid (bnc-id). 1275 In the backward path set-up model, the call-originating gateway can 1276 release and re-use an eecid when it receives Q.2931 set-up or 1277 Q.2630.1 establish request from the call-terminating end. 1279 In the forward path set-up model, the call-originating gateway can 1280 release and re-use an eecid when it receives a Q.2931 [15] connect or 1281 Q.2630.1 [37] establish confirm from the call-terminating end. This 1282 message need not carry the eecid. The Q.2931 call reference or the 1283 Q.2630.1 Destination Signaling Association Identifier (DSAID) points 1284 to the eecid. 1286 However, in both cases (backward and forward models), 1287 it is recommended that this eecid be retained until the connection 1288 terminates since it can serve as a handle for applications such 1289 as lawful wiretaps (CALEA). 1291 5.7.3 The 'aalType' attribute 1293 When present, the 'aalType' attribute is used to indicate 1294 the ATM adaptation layer. If this information is redundant 1295 with the 'm' line, it can be omitted. The format of the 1296 'aalType' media attribute line is as follows: 1298 a=aalType: 1300 Here, can take on the following string values: 1301 "AAL1", "AAL1_SDT", "AAL1_UDT", "AAL2", "AAL3/4", "AAL5" 1302 and "User defined AAL". 1303 Note that this document addresses AAL1, AAL2 and AAL5 only. 1304 Currently, there are no known narrowband telephony applications 1305 or standards that use AAL3/4. 1307 5.7.4 The 'silenceSupp' attribute 1309 When present, the 'silenceSupp' attribute is used to indicate 1310 the use or non-use of silence suppression. 1311 The format of the 'silenceSupp' media attribute line is 1312 as follows: 1314 a=silenceSupp: 1315 1317 If any of the parameters in the silenceSupp media attribute line 1318 is not specified, is inapplicable or is implied, then it is set to 1319 "-". 1321 The can take on values of "on" or "off". If it 1322 is "on", then silence suppression is enabled. 1324 The is a 16-bit field which can be represented in 1325 decimal or hex. Each increment (tick) of this timer represents 1326 a millisecond. The maximum value of this timer is between 1 and 3 1327 minutes. This timer represents the time-lag before silence 1328 suppression kicks in. Even though this can, theoretically, be 1329 as low as 1 ms, most DSP algorithms take more than that to 1331 detect silence. Setting to a large value (say 1332 1 minute> is equivalent to disabling silence suppression 1333 within a call. However, idle channel suppression between calls 1334 on the basis of silence suppression is still operative in 1335 non-switched, trunking applications if = "on" 1336 and is a large value. 1338 The specifies the preferred silence suppression 1339 method that is preferred or already selected. It can 1340 take on the string values of "standard" and "custom". If 1341 its value is "standard", then a standard method (e.g. ITU-defined) 1342 is preferred to custom methods if such a standard 1343 is defined. Otherwise, a custom method may be used. If 1344 is set to "custom", then a custom method, if 1345 available, is preferred to the standard method. 1347 The indicates whether SIDs (Silence Insertion 1348 Descriptors) are to be used, and whether they use fixed comfort 1349 noise or sampled background noise. It can take on the 1350 string values of "No SID", "Fixed Noise", "Sampled Noise". 1352 If the value of is "Fixed Noise", then 1353 provides its level. It can take on integer values in the range 1354 0-127, as follows: 1355 value Meaning 1356 0-29 Reserved 1357 30 -30 dBm0 1358 31 -31 dBm0 1359 . . . . . . 1360 77 -77 dBm0 1361 78 -78 dBm0 1362 79-126 reserved 1363 127 Idle Code (no noise) 1365 A hex representation, preceded by a 0x prefix, of 1366 is allowed. 1368 5.7.5 The 'ecanf' and 'ecanb' attributes 1370 When present, the 'ecanf' and 'ecanb' attributes are used to indicate 1371 the use or non-use of echo cancellation in the forward 1372 and backward directions respectively. See Section 1373 2.3 for a definition of the terms 'forward' and 'backward'. 1375 The format of the 'ecanf' and 'ecanb' media attribute lines is 1376 as follows: 1378 a=ecanf: 1379 a=ecanb: 1381 If any of the parameters in the ecanf and ecanb media attribute lines 1382 is not specified, is inapplicable or is implied, then it is set to 1383 "-". 1385 If the 'ecanf' or 'ecanb' 1386 media attribute lines is not present, then means other than 1387 the SDP descriptor must be used to determine the applicability 1388 and nature of echo cancellation in that direction. Examples 1389 of such means are MIB provisioning, the local connection options 1390 structure in MGCP etc. 1392 The parameter can take on values of "on" or "off". If it 1393 is "on", then echo cancellation is enabled. If it is "off", 1394 then echo cancellation is disabled. 1396 The parameter can take on the string values "G165" and "G168" 1397 respectively. 1399 When SDP is used with some media gateway control protocols such as MGCP 1400 and Megaco [26], there exist means outside SDP descriptions to specify 1401 the echo cancellation properties of a connection. Nevertheless, this 1402 media attribute line is included for completeness. As a result, the 1403 SDP can be used for describing echo cancellation in applications 1404 where alternate means for this are unavailable. 1406 5.7.6 The 'gcf' and 'gcb' attributes 1408 When present, the 'gcf' and 'gcb' attributes are used to indicate 1409 the use or non-use of gain control in the forward 1410 and backward directions respectively. See Section 1411 2.3 for a definition of the terms 'forward' and 'backward'. 1413 The format of the 'gcf' and 'gcb' media attribute lines is 1414 as follows: 1416 a=gcf: 1417 a=gcb: 1419 If any of the parameters in the gcf and gcb media attribute lines 1420 is not specified, is inapplicable or is implied, then it is set to 1421 "-". 1423 If the 'gcf' or 'gcb' 1424 media attribute line is not present, then means other than 1425 the SDP descriptor must be used to determine the applicability 1426 and nature of gain control in that direction. Examples of such 1427 means are MIB provisioning, the local connection options 1428 structure in MGCP etc. 1430 The parameter can take on values of "on" or "off". If it 1431 is "on", then gain control is enabled. If it is "off", then 1432 gain control is disabled. 1434 The parameter is represented as the decimal or hex 1435 equivalent of a 16-bit binary field. A value of 0xFFFF implies 1436 automatic gain control. Otherwise, this number indicates the 1437 number of decibels of inserted loss. The upper bound, 65,535 dB 1438 (0xFFFE) of inserted loss, is an absurdly large number and is a 1439 carryover from Megaco [26]. In practical applications, the inserted loss 1440 is much lower. 1442 When SDP is used with some media gateway control protocols such as MGCP 1443 and Megaco [26], there exist means outside SDP descriptions to specify 1444 the gain control properties of a connection. Nevertheless, this 1445 media attribute line is included for completeness. As a result, the 1446 SDP can be used for describing gain control in applications 1447 where alternate means for this are unavailable. 1449 5.7.7 The 'profiledesc' attribute 1451 There is one 'profiledesc' media attribute line for each AAL2 1452 profile that is intended to be described. The 'profiledesc' media 1453 attribute line is structured as follows: 1455 a=profiledesc: 1456 1457 1458 ... 1459 1461 Here, and are identical to their 1462 definition, above, for the 'm' line. 1464 The profile elements (rows in the profile tables of ITU I.366.2 or 1465 AF-VTOA-0113) are represented as four-tuples following the 1466 parameter in the 'profiledesc' media attribute line. If a member of 1467 one of these four-tuples is not specified or is implied, then it is 1468 set to "-". 1470 The parameter is represented by D1-D2, where D1 and 1471 D2 are decimal integers in the range 0 through 15. 1473 The parameter can take one of the values in column 2 1474 of Table 1. Additionally, it can take on the following descriptor 1475 strings: "PCMG", "SIDG" and "SID729". These stand for generic PCM, 1476 generic SID and G.729 SID respectively. 1478 The is a decimal integer representation of the AAL2 1479 packet length in octets. 1481 The is a decimal integer representation of the AAL2 1482 packetization interval in ms. 1484 For instance, the 'profiledesc' media attribute line below defines 1485 the AAL2/custom 100 profile. This profile is reproduced in the table 1486 below. For a description of the parameters in this profile such as 1487 M and the sequence number interval, see ITU I.366.2. 1489 a=profiledesc:AAL2/custom 100 0-7 PCMG 40 5 0-7 SIDG 1 5 8-15 1490 G726-32 40 10 8-15 SIDG 1 5 1492 If the parameter is to be omitted or implied, then the 1493 same profile can be represented as follows: 1495 a=profiledesc:AAL2/custom 100 0-7 PCMG 40 - 0-7 SIDG 1 - 8-15 1496 G726-32 40 - 8-15 SIDG 1 - 1498 If a gateway has a provisioned or hard coded definition of a 1499 profile, then any definition provided via the 'profiledesc' line 1500 overrides it. The exception to this rule is with regard to standard 1501 profiles such as ITU-defined profiles and ATMF-defined profiles. In 1502 general, these should not be defined via a 'profiledesc' media 1503 attribute line. If they are, then the definition needs to be 1504 consistent with the standard definition else the SDP session 1505 descriptor should be rejected with an appropriate error code. 1507 |---------------------------------------------------------------| 1508 | UUI | Packet |Encoding | | |Packet|Seq.No. | 1509 | Code | Length |per ITU |Description of | M |Time |Interval| 1510 |point |(octets)|I.366.2 | Algorithm | |(ms) |(ms) | 1511 |Range | | 2/99 | | | | | 1512 | | | version | | | | | 1513 |---------------------------------------------------------------| 1514 | 0-7 | 40 | Figure | PCM, G.711-64,| 1 | 5 | 5 | 1515 | | | B-1 | generic | | | | 1516 |------|--------|---------|---------------|-----|------|--------| 1517 | 0-7 | 1 | Figure | Generic SID | 1 | 5 | 5 | 1518 | | | I-1 | | | | | 1519 |------|--------|---------|---------------|-----|------|--------| 1520 | 8-15 | 40 | Figure | ADPCM, | 2 | 10 | 5 | 1521 | | | E-2 | G.726-32 | | | | 1522 |------|--------|---------|---------------|-----|------|--------| 1523 | 8-15 | 1 | Figure | Generic SID | 1 | 5 | 5 | 1524 | | | I-1 | | | | | 1525 |------|--------|---------|---------------|-----|------|--------| 1527 5.7.8 The 'vsel' attribute 1529 The 'vsel' attribute which indicates a prioritized list of 1530 one or more 1531 3-tuples for voice service. Each 3-tuple indicates a codec, 1532 an optional packet length and an optional packetization 1533 period. This complements the 'm' line information and should 1534 be consistent with it. 1536 The 'vsel' line is structured as follows: 1538 a=vsel: 1539 1540 ... 1541 1543 where the parameter can take one of the values in 1544 column 2 of Table 1. The is a decimal integer 1545 representation of the packet length in octets. The is a 1546 decimal integer representation of the 1547 packetization interval in ms. The parameters 1548 and can be set to "-" when not needed. 1549 Also, the entire 'vsel' media attribute line can be omitted when not 1550 needed. 1552 For example, 1554 a=vsel:G729 10 10 G726-32 40 10 1556 indicates first preference of G.729 or G.729a (both are 1557 interoperable) as the voice encoding scheme. A packet length of 10 1558 octets and a packetization interval of 10 ms are associated with 1559 this codec. G726-32 is the second preference stated in this line, 1560 with an associated packet length of 40 octets and a packetization 1561 interval of 10 ms. If the packet length and packetization 1562 interval are intended to be omitted, then this media attribute line 1563 becomes 1565 a=vsel:G729 - - G726-32 - - 1567 The media attribute line 1569 a=vsel:G726-32 40 10 1571 indicates preference for or selection of 32 kbps ADPCM with a packet 1572 length of 40 octets and a packetization interval of 10 ms. 1574 This media attribute line can be used in the AAL1, AAL2 and 1575 AAL5 contexts. In the AAL1 context, it has the very limited 1576 utility of indicating whether the codec type is PCMU or PCMA. 1577 The and are not meaningful in this 1578 case, and should be set to "-". Its greatest utility in AAL2, 1579 where it determines the use of some or all of the rows in 1580 a given profile table. If multiple 3-tuples are present, they 1581 can indicate a hierarchical assignment of some rows in that 1582 profile to voice service e.g. row A preferred to row B etc. 1583 If multiple profiles are present on the 'm' line, the profile 1584 qualified by this attribute is the first (i.e. highest priority) 1585 profile. 1587 5.7.9 The 'dsel' attribute 1589 The 'dsel' attribute which indicates a prioritized list of 1590 one or more 3-tuples for voiceband data service. The 1591 flag indicates whether this definition of voiceband data 1592 includes fax ("on" value) or not ("off" value). If is 1593 "on", then the 'dsel' line must be consistent with any 'fsel' line 1594 in the session description. In this case, an 1595 error event is generated in the case of inconsistency. 1596 Each 3-tuple indicates a codec, 1597 an optional packet length and an optional packetization 1598 period. This complements the 'm' line information and should 1599 be consistent with it. 1601 The 'dsel' line is structured as follows: 1603 a=dsel: 1604 1605 ... 1606 1608 where the parameter can take one of the values in 1609 column 2 of Table 1. The and 1610 parameters are per their definition, above, for the 'vsel' 1612 media attribute line. The parameters 1613 and ) can be set to "-" when not needed. 1614 The flag is presumed to be "off" if it is set to "-". 1615 Also, the entire 'dsel' media attribute line can be omitted when not 1616 needed. 1618 For example, 1620 a=dsel:- G726-32 20 5 PCMU 40 5 1622 indicates that this line does not address facsimile, and that the 1623 first preference for the voiceband data codes is 32 kbps ADPCM, 1624 while the second preference is PCMU. The packet length 1625 and the packetization interval associated with G726-32 are 20 octets and 1626 5 ms respectively. For PCMU, they are 40 octets and 5 ms respectively. 1628 This media attribute line can be used in the AAL1, AAL2 and 1629 AAL5 contexts. In the AAL1 context, it has the very limited 1630 utility of indicating whether the codec type is PCMU or PCMA. 1631 The and are not meaningful in this 1632 case, and should be set to "-". Its greatest utility in AAL2, 1633 where it determines the use of some or all of the rows in 1634 a given profile table. If multiple 3-tuples are present, they 1635 can indicate a hierarchical assignment of some rows in that 1636 profile to voiceband data service e.g. row A preferred to row B etc. 1637 If multiple profiles are present on the 'm' line, the profile 1638 qualified by this attribute is the first (i.e. highest priority) 1639 profile. 1641 5.7.10 The 'fsel' attribute 1643 The 'fsel' attribute which indicates a prioritized list of 1644 one or more 3-tuples for facsimile service. If an 'fsel' line 1645 is present, any 'dsel' line with set to "on" in the session 1646 description must be checked for consistency with it. In this case, 1647 an error event is generated in the case of inconsistency. 1648 Each 3-tuple indicates a codec, 1649 an optional packet length and an optional packetization 1650 period. This complements the 'm' line information and should 1651 be consistent with it. 1653 The 'fsel' line is structured as follows: 1655 a=dsel: 1656 1657 ... 1658 1660 where the parameter can take one of the values in 1661 column 2 of Table 1. The and 1662 parameters are per their definition, above, for the 'vsel' 1663 media attribute line. The parameters 1664 and can be set to "-" when not needed. 1665 Also, the entire 'fsel' media attribute line can be omitted when not 1666 needed. 1668 For example, 1670 a=fsel:FXDMOD-3 - - 1672 indicates demodulation and remodulation of ITU-T group 3 fax at the 1673 gateway. 1675 a=fsel:PCMU 40 5 G726-32 20 5 1677 indicates a first and second preference of Mu-law PCM and 32 kbps 1678 ADPCM as the facsimile encoding scheme. The packet length 1679 and the packetization interval associated with G726-32 are 20 octets and 1680 5 ms respectively. For PCMU, they are 40 octets and 5 ms respectively. 1682 This media attribute line can be used in the AAL1, AAL2 and 1683 AAL5 contexts. In the AAL1 context, it has the very limited 1684 utility of indicating whether the codec type is PCMU or PCMA. 1685 The and are not meaningful in this 1686 case, and should be set to "-". Its greatest utility in AAL2, 1687 where it determines the use of some or all of the rows in 1688 a given profile table. If multiple 3-tuples are present, they 1689 can indicate a hierarchical assignment of some rows in that 1690 profile to facsimile service e.g. row A preferred to row B etc. 1691 If multiple profiles are present on the 'm' line, the profile 1692 qualified by this attribute is the first (i.e. highest priority) 1693 profile. 1695 5.7.11 The 'capability' attribute 1697 When present, the 'capability' attribute indicates the ATM Transfer 1698 Capability described in ITU I.371 [28], equivalent to the ATM Service 1699 Category described in the UNI 4.1 Traffic Management specification [6]. 1701 The 'capability' media attribute line is structured in one of 1702 the following ways: 1704 a=capability: 1706 a=capability: 1708 Possible values of the are enumerated 1709 below: 1711 "CBR", "nrt-VBR", "rt-VBR", "UBR", "ABR", "GFR" 1713 Possible values of the are enumerated 1714 below: 1716 "DBR","SBR","ABT/IT","ABT/DT","ABR" 1718 Some applications might use non-standard and values 1719 not listed above. Equipment designers will need to agree on 1720 the meaning and implications of non-standard transfer 1721 capabilities / service capabilities. An example of a 1722 a non-standard value is "UBR+", which is UBR with 1723 minimum cell rate (MCR). 1725 The field essentially serves as a subscript 1726 to the and fields. In general, it can 1727 take on any integer value, or the "-" value indicating that 1728 it does not apply or that the underlying data is to be known 1729 by other means, such as provisioning. 1731 The following combinations are recognized in the ATMF and 1732 ITU specifications: 1734 Meaning 1736 nrt-VBR 1 nrt-VBR.1 1737 nrt-VBR 2 nrt-VBR.2 1738 nrt-VBR 3 nrt-VBR.3 1739 rt-VBR 1 rt-VBR.1 1740 rt-VBR 2 rt-VBR.2 1741 rt-VBR 3 rt-VBR.3 1742 UBR 1 UBR.1 1743 UBR 2 UBR.2 1744 GFR 1 GFR.1 1745 GFR 2 GRR.2 1747 Meaning 1749 SBR 1 SBR1 1750 SBR 2 SBR2 1751 SBR 3 SBR3 1753 It is beyond the scope of this specification to examine the 1754 equivalence of some of the ATMF and ITU definitions. These 1755 need to be recognized from the ATMF and ITU 1756 source specifications and exploited, as much as possible, 1757 to simplify ATM node design. 1759 These string values in the 'capability' attribute are case- 1760 insensitive. When the bearer connection is a single AAL2 CID 1761 connection within a multiplexed AAL2 VC, the 'capability' 1762 attribute does not apply. 1764 5.7.12 The 'qosclass' attribute 1766 When present, the 'qosclass' attribute indicates the QoS class 1767 specified in ITU I.2965.1 [34]. 1769 The 'qosclass' media attribute line is structured as follows: 1771 a=qosclass: 1773 Here, is an integer in the range 0 - 5. 1775 Meaning 1777 0 Default QoS 1778 1 Stringent 1779 2 Tolerant 1780 3 Bi-level 1781 4 Unbounded 1782 5 Stringent bi-level 1784 5.7.13 The 'bcob' attribute 1786 When present, the 'bcob' attribute represents the broadband 1787 connection oriented bearer class defined in ITU Q.2961.2 [33]. 1788 The 'bcob' media attribute line is structured as 1789 follows: 1791 a=bcob: 1793 Here, is the decimal or hex representation of a 5-bit 1794 field. Currently, all values are unused and 1795 reserved with the following exceptions: 1797 Meaning 1799 1 BCOB-A 1800 3 BCOB-C 1801 16 BCOB-X 1802 24 BCOB-VP (transparent VP service) 1804 5.7.14 The 'stc' attribute 1806 When present, the 'stc' attribute represents susceptibility 1807 to clipping. The 'stc' media attribute line is structured as 1808 follows: 1810 a=stc: 1812 Here, is the decimal equivalent of a 2-bit field. 1813 Currently, all values are unused and reserved with the 1814 following exceptions: 1816 value Binary Equivalent Meaning 1818 0 00 Not susceptible to clipping 1819 1 01 Susceptible to clipping 1821 5.7.15 The 'upcc' attribute 1823 When present, the 'upcc' attribute represents the user plane 1824 connection configuration. The 'upcc' media attribute line is 1825 structured as follows: 1827 a=upcc: 1829 Here, is the decimal equivalent of a 2-bit field. 1830 Currently, all values are unused and reserved with the 1831 following exceptions: 1833 value Binary Equivalent Meaning 1835 0 00 Point to point 1836 1 01 Point to multipoint 1838 5.7.16 The 'atmQOSfparms' and 'atmQOSbparms' attributes 1840 When present, the 'atmQOSfparms' and 'atmQOSbparms' 1841 attributes are used to describe certain key ATM QoS parameters 1842 in the forward and backward directions respectively. See Section 1844 2.3 for a definition of the terms 'forward' and 'backward'. 1846 The 'atmQOSfparms' and 'atmQOSbparms' media attribute lines 1847 are structured as follows: 1849 a=atmQOSfparms: 1850 a=atmQOSbparms: 1852 The parameter can take on the string values of 1853 "pp" and "2p". These refer to the peak-to-peak and two-point 1854 CDV as defined in UNI 4.0 [5] and ITU Q.2965.2 [35] respectively. 1856 The CDV parameters, and , refer to the acceptable 1857 and cumulative CDVs respectively. These are expressed in units 1858 of microseconds and represented as the decimal or hex equivalent 1859 of 24-bit fields. These use the cell loss ratio, , as the 1860 "alpha" quantiles defined in the ATMF TM 4.1 specification [6] 1861 and in ITU I.356 [47]. 1863 The CTD parameters, and , refer to the acceptable and 1864 cumulative CTDs respectively in milliseconds. 1865 These are represented as the decimal or hex 1866 equivalent of 16-bit fields. 1867 These parameters are equivalent to the maximum end-to-end 1868 transit delay defined in ATMF TM 4.1 1869 specification [6] and Q.2965.2 [35]. 1871 The parameter refers to forward and backward acceptable 1872 cell loss ratios. This is the ratio between the number of cells 1873 lost and the number of cells transmitted. It is 1874 expressed as the decimal or hex equivalent of an 8-bit field. This field 1875 expresses an order of magnitude n, where n is an integer in the range 1876 1-15. The Cell Loss Ratio takes on the value 10 raised to the power 1877 of minus n. 1879 If any of these parameters is not specified, is inapplicable or is 1880 implied, then it is set to "-". 1882 An example use of these attributes for an rt-VBR, 1883 single-CID AAL2 voice VC is: 1885 a=atmQOSfparms:pp 8125 3455 32000 - 11 1886 a=atmQOSbparms:pp 4675 2155 18000 - 12 1888 This implies a forward acceptable peak-to-peak CDV of 8.125 ms, a 1889 backward acceptable peak-to-peak CDV of 4.675 ms, forward 1890 cumulative peak-to-peak CDV of 3.455 ms, a backward cumulative 1891 peak-to-peak CDV of 2.155 ms, a forward acceptable maximum 1892 cell transfer delay of 32 ms, a backward acceptable maximum 1893 cell transfer delay of 18 ms, an unspecified forward cumulative 1894 cell transfer delay, an unspecified backward cumulative cell transfer 1895 delay, a forward cell loss ratio of 1896 10 raised to minus 11 and a backward cell loss ratio of 10 to 1897 the minus 12. 1899 In certain applications (such as SIP-based applications), an SDP 1900 descriptor might have both the atmQOSfparms and atmQOSbparms 1901 attributes. In other applications (such as Megaco-based applications), 1902 the remote descriptor can have the atmQOSfparms attribute 1904 while the local descriptor can have the atmQOSbparms attribute. 1906 5.7.17 The 'aal2QOSfparms' and 'aal2QOSbparms' attributes 1908 It is recognized that means of characterizing impairments in AAL2 1909 packet streams are not clearly defined at this time. These AAL2 media 1910 attributes will constructed along the line of the 'atmQOSfparms' 1911 and 'atmQOSbparms' attributes. 1913 5.7.18 The 'atmFtrfcDesc' and 'atmBtrfcDesc' attributes 1915 When present, the 'atmFtrfcDesc' and 'atmBtrfcDesc' attributes 1916 are used to indicate ATM traffic descriptor parameters in the 1917 forward and backward directions respectively. See Section 1918 2.3 for a definition of the terms 'forward' and 'backward'. 1920 The 'atmFtrfcDesc' and 'atmBtrfcDesc' media attribute lines 1921 are structured as follows: 1923 a=atmFtrfcDesc: 1924 a=atmBtrfcDesc: 1926 If any of these parameters in these media attribute 1927 lines is not specified, is inapplicable or is implied, then it is 1928 set to "-". 1930 The (CLP level) parameter indicates whether the rates and 1931 bursts described in these media 1932 attribute lines apply to CLP 1933 values of 0, (0+1). It can take on the following string values: 1934 "0", "0+1" and "-". If rates and bursts for both values are to 1935 be described, then it is necessary to use two separate 1936 media attribute lines for each direction in the same session 1937 descriptor. If the parameter is set to "-", then it 1938 implies that the CLP parameter is not applicable. This is true 1939 when the 'atmFtrfcDesc' or 'atmBtrfcDesc' attribute is used to 1940 describe an AAL2 1941 CID rather than an ATM VC connection. 1943 The meaning, units and applicability of the remaining parameters 1944 are per the ATMF TM 4.1 specification [6] and are 1945 reiterated below: 1947 PARAMETER MEANING UNITS APPLICABILITY 1948 PCR Cells/ CBR, rt-VBR, nrt-VBR, 1949 second ABR, UBR, GFR; 1950 CLP=0,0+1 1952 SCR Cells/ rt-VBR, nrt-VBR; 1953 second CLP=0,0+1 1955 MBS Cells rt-VBR, nrt-VBR, 1956 GFR; 1957 CLP=0,0+1 1959 CDVT Microsec. CBR, rt-VBR, nrt-VBR, 1960 ABR, UBR, GFR; 1961 CLP=0,0+1 1963 MCR Cells/ ABR,GFR; 1964 second CLP=0+1 1966 MFS Cells GFR; 1967 CLP=0,0+1 1969 Frame "on"/"off" CBR, rt-VBR, nrt-VBR, 1970 Discard ABR, UBR, GFR; 1971 Allowed CLP=0+1 1973 CLP "on"/"off" CBR, rt-VBR, nrt-VBR, 1974 tagging ABR, UBR, GFR; 1975 Enabled CLP=0 1977 indicates that frame discard is permitted. It can take on the string 1978 values of "on" or "off". Note that, in the GFR case, frame discard 1979 is always enabled. Hence, this subparameter can be set to "-" in 1980 the case of GFR. Since the parameter is independent 1981 of CLP, it is meaningful in the case when = "0+1". 1982 It should be set to "-" for the case when = "0". 1984 (tag enable) indicates that CLP tagging is allowed. 1985 These can take on the string values of "on" or "off". 1986 Since the parameter applies only to cells with 1987 a CLP of 0, it is meaningful in the case when = "0". 1988 It should be set to "-" for the case when = "0+1". 1990 An example use of these media attribute lines for an rt-VBR, 1991 single-CID AAL2 voice VC is: 1993 a=atmFtrfcDesc:0+1 200 100 20 - - - on - 1994 a=atmFtrfcDesc:0 200 80 15 - - - - off 1995 a=atmBtrfcDesc:0+1 200 100 20 - - - on - 1996 a=atmBtrfcDesc:0 200 80 15 - - - - off 1998 This implies a forward and backward PCR of 200 cells per second 1999 all cells regardless of CLP, forward and backward PCR of 200 cells 2000 per second for cells with CLP=0, a forward and backward SCR of 100 2001 cells per second for all cells regardless of CLP, a forward and 2002 backward SCR of 80 cells per second for cells with CLP=0, 2003 a forward and backward MBS of 20 cells for all cells regardless 2004 of CLP, a forward and backward MBS of 15 cells for cells with 2005 CLP=0, an unspecified CDVT which can be known by other means, 2006 and an MCR and MFS which are unspecified because they are 2007 inapplicable. Frame discard is enabled in both the forward and 2008 backward directions. Tagging is not enabled in either direction. 2010 In certain applications (such as SIP-based applications), an SDP 2011 descriptor might have both the atmFtrfcDesc and atmBtrfcDesc 2012 attributes. In other applications (such as Megaco-based applications), 2013 the remote descriptor can have the atmFtrfcDesc attribute 2015 while the local descriptor can have the atmBtrfcDesc attribute. 2017 5.7.19 The 'aal2FtrfcDesc' and 'aal2BtrfcDesc' attributes 2019 It might be meaningful to construct descriptors for traffic 2020 at the AAL2 packet (subcell) level. These can tentatively be 2021 named the 'aal2FtrfcDesc' and 'aal2BtrfcDesc' attributes 2022 When constructed, these can be similar in some aspects to the 2023 'aal2FtrfcDesc' and 'aal2BtrfcDesc' attributes. 2025 5.7.20 The 'abrFparms' and 'abrBparms' attributes 2027 When present, the 'abrFparms' and 'abrBparms' attributes 2028 are used to indicate the 'additional' ABR parameters specified 2029 in the UNI 4.0 signaling specification [5]. These refer to the 2030 forward and backward directions respectively. See Section 2031 2.3 for a definition of the terms 'forward' and 'backward'. 2033 The 'abrFparms' and 'abrBparms' media attribute lines 2034 are structured as follows: 2036 a=abrFparms: 2037 a=abrBparms: 2039 These parameters are mapped into the ABR service parameters in 2040 [6] in the manner described below. These parameters can be 2041 represented in SDP as decimal integers, with fractions permitted 2042 for some. Details of the meaning, units and applicability of 2043 these parameters are in [5] and [6]. 2045 If any of these parameters in the 'abrFparms' or 'abrBparms' 2046 media attribute lines is not specified, is inapplicable or is implied, 2047 then it is set to "-". 2049 SDP ATMF SDP REPRESENTATION 2050 PARAMETER EQUIVALENT 2052 NRM Decimal/hex equivalent of 3 bit field 2053 TRM -ditto- 2054 CDF -ditto- 2055 ADTF Decimal/Hex equivalent of 10 bit field 2057 In certain applications (such as SIP-based applications), an SDP 2058 descriptor might have both the abrFparms and abrBparms 2059 attributes. In other applications (such as Megaco-based applications), 2060 the remote descriptor can have the abrFparms attribute 2061 while the local descriptor can have the abrBparms attribute. 2063 5.7.21 The 'clkrec' attribute 2065 When present, the 'clkrec' attribute is used to indicate 2066 the clock recovery method. This attribute is meaningful in the 2067 case of AAL1 unstructured data transfer (UDT). The format of the 2068 'clkrec' media attribute line is as follows: 2070 a=clcrec: 2072 The field can take on the following string 2073 values: "NULL", "SRTS" or "adaptive". These are defined in 2074 ITU I.363.1 [10]. "NULL" indicates that the stream (e.g. T1/E1) 2075 encapsulated in ATM is synchronous to the ATM network or 2076 is retimed using slip buffers. 2078 5.7.22 The 'fec' attribute 2080 When present, the 'fec' attribute is used to indicate the use of 2081 forward error correction. Currently, there exists a forward error 2082 correction method defined for AAL1 in ITU I.363.1 [10]. The format of the 2083 'fec' media attribute line is as follows: 2085 a=fec: 2087 The flag indicates the presence of absence of Forward 2088 Error Correction. It can take on the string values of "NULL", "loss 2089 sensitive" and "delay sensitive". An "NULL" value implies disabling 2090 this capability. FEC can be enabled differently for delay-sensitive 2091 and loss-sensitive connections. 2093 5.7.23 The 'prtfl' attribute 2095 When present, the 'prtfl' attribute is used to indicate the fill 2096 level of partially filled cells. This is the number of non-pad payload 2097 octets, not including any AAL SAR or convergence sublayer octets. For 2098 example, in some AAL1 applications that use partially filled cells with 2099 padding at the end, this attribute indicates the number of leading 2100 payload octets not including any AAL overhead. 2102 The format of the 'prtfl' media attribute line is as follows: 2104 a=prtfl: 2106 Here, can be expressed as a decimal (no prefix) 2107 or hex (0x prefix) integer. In general, permitted values are integers 2108 in the range 1 - 46 inclusive. However, this upper bound is 2109 different for different adaptations since the AAL overhead is 2110 different. 2112 In the case of AAL1 SDT used for n x 64 (n>=2) clear channel 2113 transmission, 2114 this media attribute line applies to both P and non-P cells. 2115 A value of 46 indicates no padding in P-cells and a padding of 2116 one in non-P cells. If partial fill is enabled, structures 2117 shall not be 2118 split across cell boundaries and shall fit in any cell. Hence, 2119 their size shall be less than or equal to the partial fill 2120 size (maximum of 46). Further, the partial fill size is preferably 2121 an integer multiple of the structure size. If not, then the 2122 partial fill size stated in the SDP description shall be 2123 truncated to an integer multiple (e.g. a partial fill size of 2124 40 is truncated to 36 to support six 6 x 64 channels). 2126 5.7.24 The 'bearertype' attribute 2128 When present, the 'bearertype' attribute is used to indicate 2130 whether the underlying bearer is an ATM PVC/SPVC, an ATM SVC, 2131 or an AAL2 CID connection within an existing ATM PVC/SPVC. 2132 Additionally, for ATM SVCs and AAL2 CID connections, the 2133 'bearertype' attribute can be used to indicate whether the 2134 media gateway initiates connection set-up via bearer signaling 2135 (Q.2931-based or Q.2630.1 based. The format of the 'bearertype' 2136 media attribute line is as follows: 2138 a=bearertype: 2140 The field can take on the following string values: 2141 "PVC", "SVC", "CID", with semantics as defined above. 2143 In the case when the underlying bearer is a PVC/SPVC, or a CID 2144 assigned by the MGC rather than through bearer signaling, the 2145 flag can be omitted or set to "-". In the 2146 case when bearer signaling is used, this flag can be omitted 2147 when it is known by default or by other means 2148 whether the media gateway initiates 2149 the connection set-up via bearer signaling. Only when this is to 2150 be indicated explicitly that the flag takes 2151 on the values of "on" or "off". An "on" value indicates that 2152 the media gateway is responsible for initiating connection set-up 2153 via bearer signaling (SVC signaling or Q.2630.1 signaling), 2154 an "off" value indicates otherwise. 2156 5.7.25 The 'structure' attribute 2158 This attribute applies to AAL1 connections only. When present, 2159 the 'structure' attribute is used to indicate the presence or 2160 absence of structured data transfer (SDT), and the size in octets 2161 of the SDT 2162 blocks. The format of the 'structure' media attribute line is as 2163 follows: 2165 a=structure: 2167 where the flag indicates the presence of absence of SDT. 2168 It can take on the values of "on" or "off". An "on" value implies 2169 AAL1 structured data transfer (SDT), while an "off" value implies 2170 AAL1 unstructured data transfer (UDT). 2172 The block size field, , is an optional 16-bit field (Q.2931) 2173 that can be represented in decimal (no prefix) or in hex (0x prefix). 2174 It can be omitted or set to a "-" when not applicable, as in the case 2175 of unstructured data transfer (UDT). For SDT, it can be omitted or set 2176 to a "-" when is known by other means. For instance, 2177 af-vtoa-78 [7] fixes the structure size for n x 64 service, 2178 with or without CAS. The theoretical maximum value of is 65,535, 2179 although most services use much less. 2181 5.7.26 The 'sbc' attribute 2183 The 'sbc' media attribute line denotes the subchannel count and 2184 is meaningful only in the case of n x 64 clear channel 2185 communication. A clear n x 64 channel can use AAL1 2186 (ATM forum af-vtoa-78) or AAL2 adaptation (ITU I.366.2). Although 2187 no such standard definition exists, it is also possible to use 2188 AAL5 for this purpose. An n x 64 clear channel is represented 2190 by the encoding names of "X-CCD" and "X-CCD-CAS" in 2191 Table 1. 2193 The format of the 'sbc' media attribute line is as follows: 2195 a=sbc: 2197 Here, can be expressed as a decimal (no prefix) 2198 or hex (0x prefix) integer. This attribute indicates the 2199 number of DS0s in a T1 or E1 frame that are aggregated for 2200 transmitting clear channel data. For T1-based applications, it 2201 can take on integral values in the inclusive range [1...24]. For 2202 E1-based applications, it can take on integral values in the 2203 inclusive range [1...31]. When omitted, other means are to be used 2204 to determine the subchannel count. 2206 5.7.27 The 'fcpssdusize' and 'bcpssdusize' attributes 2208 When present, the 'fcpssdusize' and 'bcpssdusize' attributes are used to 2209 indicate the maximum size of the CPCS SDU payload in the forward and 2210 backward directions respectively. See section 2.3 for a definition of the 2211 terms 'forward' and 'backward'. 2213 The format of these media attribute line is as follows: 2215 a=fcpssdusize: 2216 a=bcpssdusize: 2218 The fields is a 16-bit integer that can be 2219 represented in decimal (no prefix)or in hex (0x prefix). 2221 The meaning and values of these fields are as follows: 2223 Application Field Meaning Values 2225 AAL5 Maximum CPCS-SDU size 1- 65,535 2227 AAL2 Maximum CPCS-SDU size 45 or 64 2229 In certain applications (such as SIP-based applications), an SDP 2230 descriptor might have both the fcpssdusize and bcpssdusize 2231 attributes. In other applications (such as Megaco-based applications), 2232 the remote descriptor can have the fcpssdusize attribute 2233 while the local descriptor can have the bcpssdusize attribute. 2235 5.7.28 The 'aal2CPS' attribute 2237 When present, the 'aal2CPS' attribute is used to indicate 2238 describe parameters associated with the AAL2 CPS layer. 2240 The format of the 'aal2CPS' media attribute line is as 2241 follows: 2243 a=aal2CPS: 2245 Each of these fields can be set to a "-" when the intention 2246 is to not specify them in an SDP descriptor. 2248 The integer can take on values between 1 and 255. 2249 It represents the number of channels (CIDs) multiplexed into 2250 the AAL2 VCC. It can be represented in decimal (no prefix) 2251 or in hex (0x prefix). 2253 The integer represents the "combined use" timerCU 2254 defined in ITU I.363.2. This timer is represented as an 2255 integer number of microseconds. 2257 5.7.29 The 'aal2_sscs_3661' attribute 2259 When present, the 'aal2_sscs_3661' attribute is used to indicate 2260 the presence of an AAL2 SSCS sublayer as defined in ITU I.366.1 [12]. 2261 Optionally, it can be used to indicate selected options and 2262 parameter values for this SSCS. 2264 The format of the 'aal2_sscs_3661' media attribute line is as 2265 follows: 2267 a=aal2_sscs_3661: 2269 Each of these fields can be set to a "-" when the intention 2270 is to not specify them in an SDP descriptor. 2272 The flag indicates the presence of absence of assured data 2273 transfer as defined in I.366.1. The flag indicates the 2274 presence of absence of transmission error detection as defined 2275 in I.366.1. Each of these flags can take on the values of "on" 2276 or "off". An "on" value indicates presence of the capability. 2278 The and fields are 16-bit integers that 2279 can be represented in decimal (no prefix)or in hex (0x prefix). 2280 The meaning and values of the and fields 2281 are as follows: 2283 Field Meaning Values 2285 Maximum SSSAR-SDU size 1- 65,535 2286 forward direction 2288 Maximum SSSAR-SDU size 1- 65,535 2289 backward direction 2291 In certain applications (such as SIP-based applications), an SDP 2292 descriptor might have an 'aal2_sscs_3661' media attribute line 2293 with the and subparameters. In applications 2294 (such as Megaco-based applications), the remote descriptor can have the 2295 subparameter while the local descriptor can have the 2296 subparameter. 2298 5.7.30 The 'aal2_SSCS_3662' attribute 2300 When present, the 'aal2_SSCS_3662' attribute is used to indicate 2301 the presence of an AAL2 SSCS sublayer as defined in ITU I.366.2 [13]. 2302 Optionally, it can be used to indicate selected options and 2303 parameter values for this SSCS. 2305 The format of the 'aal2_SSCS_3662' media attribute line is as 2306 follows: 2308 a=aal2_SSCS_3662: 2309 2310 2312 Each of these fields can be set to a "-" when the intention 2313 is to not specify them in an SDP descriptor. 2315 The field can take on the following string values: "audio" 2316 and "multirate". These correspond to the audio and multirate 2317 Service Access Points (SAPs) defined in ITU I.366.2. 2319 The flag indicates whether the transport of circuit 2320 mode data is enabled or disabled, corresponding to the string 2321 values of "on" and "off" respectively. 2323 The flag indicates whether the transport of frame 2324 mode data is enabled or disabled, corresponding to the string 2325 values of "on" and "off" respectively. 2327 The flag indicates whether facsimile demodulation 2328 and remodulation are enabled or disabled, corresponding to the 2329 string values of "on" and "off" respectively. 2331 The flag indicates whether the transport of Channel 2332 Associated Signaling (CAS) bits in AAL2 type 3 packets is enabled 2333 or disabled, corresponding to the string values of "on" and "off" 2334 respectively. 2336 The flag indicates whether the transport of DTMF dialled 2337 digits in AAL2 type 3 packets is enabled or disabled, corresponding 2338 to the string values of "on" and "off" respectively. 2340 The flag indicates whether the transport of MF dialled 2341 digits in AAL2 type 3 packets is enabled or disabled, corresponding 2342 to the string values of "on" and "off" respectively. This flag 2343 enables MF dialled digits in a generic manner, without specifying 2344 type (e.g. R1, R2 etc.). 2346 The flag indicates whether the transport, in AAL2 type 3 2347 packets, of MF dialled digits for signaling system R1 is enabled 2348 or disabled, corresponding to the string values of "on" and "off" 2349 respectively. 2351 The flag indicates whether the transport, in AAL2 type 3 2352 packets, of MF dialled digits for signaling system R2 is enabled 2353 or disabled, corresponding to the string values of "on" and "off" 2354 respectively. 2356 The field indicates whether PCM encoding, if used, 2357 is based on the A-law or the Mu-law. This can be used to qualify 2358 the 'generic PCM' codec stated in some of the AAL2 profiles. The 2359 field can take on the string values of "A" 2360 and "Mu". 2362 The and fields are 16-bit integers that 2363 can be represented in decimal (no prefix)or in hex (0x prefix). 2364 The meaning and values of the and fields 2365 are as follows: 2367 Field Meaning Values 2369 Maximum length of a 1- 65,535 2370 frame mode data unit, 2371 forward direction 2373 Maximum length of a 1- 65,535 2374 frame mode data unit, 2375 backward direction 2377 In certain applications (such as SIP-based applications), an SDP 2378 descriptor might have an 'aal2_SSCS_3662' media attribute line 2379 with the and subparameters. In applications 2380 (such as Megaco-based applications), the remote descriptor can have the 2381 subparameter while the local descriptor can have the 2382 subparameter. 2384 5.7.31 The 'aal2_sscs_3652' attribute 2386 When present, the 'aal2_sscs_3652' attribute is used to indicate 2387 the use, in conjunction with AAL2, of a service-specific 2388 coordination function, as defined in ITU I.365.2 [40], for Connection 2389 Oriented Network Service (SSCF-CONS). The format of the 2390 'aal2_sscs_3652' media attribute line is as follows: 2392 a=aal2_sscs_3652 2394 5.7.32 The 'aal2_sscs_3653' attribute 2396 When present, the 'aal2_sscs_3653' attribute is used to indicate 2397 the use, in conjunction with AAL2, of a service-specific 2398 coordination function, as defined in ITU I.365.3 [41], for Connection 2399 Oriented Transport Service (SSCF-COTS). The format of the 2400 'aal2_sscs_3653' media attribute line is as follows: 2402 a=aal2_sscs_3653 2404 5.7.33 The 'AAL5app' attribute 2406 When present, the 'AAL5app' attribute is used to indicate 2407 the presence of an application that uses AAL5, and to optionally 2408 point to the 2409 controlling standard for the application layer. The format of the 2410 'AAL5app' media attribute line is as follows: 2412 a=AAL5app: 2414 The field can take on the string values listed 2415 below, along with their meaning. Additionally, it can be set to "-" 2416 if the controlling standard for the application is known by other 2417 means such as by default or through provisioning. 2419 Meaning 2421 "h323c" Annex C of H.323 which specifies direct 2422 RTP on AAL5 [45]. 2424 "af83" af-vtoa-0083.001, which specifies 2425 variable size AAL5 PDUs with PCM voice 2426 and a null SSCS [46]. 2428 "assuredSSCOP" SSCOP as defined in ITU Q.2110 [43], 2429 assured operation. 2431 "nonassuredSSCOP" SSCOP as defined in ITU Q.2110 [43], 2432 non-assured operation. 2434 "itu_i3651" Frame relay SSCS per ITU I.365.1 [39]. 2436 "itu_i3652" Service-specific coordination function, 2437 as defined in ITU I.365.2, for Connection 2438 Oriented Network Service (SSCF-CONS) [40]. 2440 "itu_i3653" Service-specific coordination function, 2441 as defined in ITU I.365.3, for Connection 2442 Oriented Transport Service (SSCF-COTS) [41]. 2444 "FRF11" Use of the FRF.11 frame relay standard 2445 to transmit telephony payloads. 2447 5.7.34 The 'lij' attribute 2449 When present, the 'lij' attribute is used to indicate 2450 the presence of a connection that uses the Leaf-initiated-join 2451 capability described in UNI 4.0 [5], and to optionally describe 2452 parameters associated with this capability. The format of the 2453 'lij' media attribute line is as follows: 2455 a=lij: 2457 The (screening indication) is a 4-bit field expressed as a 2458 decimal 2459 or hex integer. It is defined in the UNI 4.0 signaling specification 2460 [5]. It is expected that the values of this field will be defined 2461 later by the ATMF and/or ITU. Currently, all values are reserved 2462 with the exception of 0, which indicates a 'Network Join without Root 2463 Notification'. 2465 The (leaf sequence number) is a 32-bit field expressed as a 2466 decimal 2467 or hex integer. Per the UNI 4.0 signaling specification [5], it is 2468 used by a joining leaf to associate messages and responses during 2469 LIJ (leaf initiated join) procedures. 2471 Each of these fields can be set to a "-" when the intention 2472 is to not specify them in an SDP descriptor. 2474 5.7.35 The 'anycast' attribute 2476 When present, the 'anycast' attribute line is used to indicate 2477 the applicability of the anycast function described in UNI 2479 4.0 [5]. Optional parameters to qualify this function are 2480 provided. The format of the 'anycast' attribute is: 2482 a=anycast: 2484 The is per Annex 5 of UNI 4.0 [5]. Within 2485 an SDP descriptor, it can be represented in one of the formats 2486 (NSAP, E.164, GWID/ALIAS) described elsewhere in this document. 2488 The remaining subparameters mirror the connection scope selection 2489 information element in UNI 4.0 [5]. Their meaning and representation 2490 is as shown below: 2492 PARAMETER MEANING REPRESENTATION 2493 Coding standard for the Decimal or hex 2494 connection scope selection IE equivalent of 2495 Definition: UNI 4.0 [5] 2 bits 2497 Type of connection scope Decimal or hex 2498 Definition: UNI 4.0 [5] equivalent of 2499 4 bits 2501 Connection scope selection Decimal or hex 2502 Definition: UNI 4.0 [5] equivalent of 2503 8 bits 2505 Currently, all values of and are reserved with 2506 the exception of = 3 (ATMF coding standard) and = 1 2507 (connection scope type of 'organizational'). 2509 Each of these fields can be set to a "-" when the intention 2510 is to not specify them in an SDP descriptor. 2512 5.7.36 The 'wtp' attribute 2514 This is used for CALEA (lawful wiretap) conformance. It specifies the 2515 VCC and/or CID to be used for delivering a tapped stream. An odd-even 2516 convention is used. 2517 The stream directed towards the tapped party (or towards a 2518 party to which the tapped party's call is redirected) is copied into a 2519 circuit with an even VCCI (if there are no CIDs or one CID per VCC) or a 2520 circuit with an even CID (if there are multiple CIDs per VCC). VCCIs 2521 used are 0,2,4... CIDs used are 8, 10, 12 ... 2522 The stream from the tapped party (or from a 2523 party to which the tapped party's call is redirected) is copied into a 2524 circuit with the next odd VCCI (if there are no CIDs or one CID per VCC) or a 2525 circuit with the next odd CID (if there are multiple CIDs per VCC). The odd 2526 value in the pair is automatically derived by adding 1 to the even value and is 2527 not specified in the 'wtp' attribute line. The resulting VCCI values are 2528 1, 3, 5 ... The resulting CID values are 9, 11, 13 ... 2530 This attribute has the following format: 2532 a=wtp: 2534 where is defined in sections above on the 'm' lines 2535 for AAL1, AAL5 and AAL2. The wildcarding rules for are 2536 applicable. Note that the semantics of the allow 2537 specification of the ATM address of the remote delivery site. 2539 When SVC(s) are used for delivering the tapped streams 2540 to another site, all terms in except the ATM address 2541 of the remote delivery site are wildcarded. 2543 5.7.37 Specification of Higher-layer attributes 2545 This conventions in this ATM SDP document are limited to the ATM and adaptation 2546 layers. Parameters associated with layers higher than the ATM adaptation 2547 layer are addressed only if these are tightly coupled to the ATM or 2548 adaptation layers. 2550 ATM signaling standards provide 'escape mechanisms' to 2551 represent, signal and negotiate higher-layer parameters. Examples 2552 are the B-HLI and B-LLI IEs specified in ITU Q.2931 [15], and 2553 the user-to-user information element described in ITU Q.2957 [48]. 2555 SDP as described in rfc2327 has a similar mechanism to 2556 describe higher-layer parameters. This is the 'fmtp' or the 2557 format-specific parameters attribute. This attribute is expressed in 2558 the following manner: 2559 a=fmtp: 2561 It is suggested that applications use this attribute, described in 2562 detail in rfc2327 [1], to express higher-layer parameters. Conventions 2563 for the use of the 'fmtp' attribute to describe higher-layer information 2564 are beyond the scope of the present document. However, it is recognized 2565 that in some applications it is necessary to describe higher-layer 2566 information within the same SDP descriptor as the ATM and AAL 2567 information. 2569 5.7.38 Use of the second media-level part in H.323 Annex C applications 2571 Section 4 mentions that H.323 annex C applications have a second media level part 2572 for the ATM session description. This is used to convey information about the RTCP 2573 stream. Although the RTP stream is encapsulated in AAL5 with no intervening IP 2574 layer, the RTCP stream is sent to an IP address and RTCP port. This media level 2575 part has the following format: 2576 m= 2577 m= control H323c - 2578 c= IN IP4 2580 Consistency with rfc2327 is maintained in the location and format of these lines. 2581 The is set o "-". The 'c' line in the second media-level part pertains 2582 to RTCP only. 2584 The and subparameters indicate the port number and IP 2585 address on which the media gateway is prepared to receive RTCP packets. Since this 2586 refers to the RTCP packets and not to RTP packets, the port number is odd. If an 2587 even port is specified, then the next odd number is used. 2589 Any of the subparameters on these lines can be set to "-" if they are known by 2590 other means. 2592 The range and format of the and subparameters is per 2593 [1]. The is a decimal number between 1024 and 65535. It is an odd 2594 number. If an even number in this range is specified, the next odd number is used. 2595 The is expressed in the usual dotted decimal IP address 2596 representation, from 0.0.0.0 to 255.255.255.255, resulting in an alphanumeric 2598 string of 7 to 15 characters. 2600 5.7.39 Chaining SDP descriptors 2602 The start of an SDP descriptor is marked by a 'v' line. In some 2603 applications, consecutive SDP descriptions are alternative descriptions 2604 of the same session. In others, these describe different layers of the 2605 same connection (e.g. IP, ATM, frame relay). This is useful when these 2606 connectivity at these layers are established at the same time e.g. an 2607 IP-based session over an ATM SVC. To distinguish between the 2608 alternation and concatenation of SDP descriptions, a 'chain' attribute 2609 can be used in the case of concatenation. 2611 When present, the 'chain' attribute binds an SDP description to the 2612 next or previous SDP description. The next or previous description is 2613 separated from the current one by a 'v' line. It is not necessary that 2614 this description also have a 'chain' media attribute line. 2616 Chaining averts the need to set up a single SDP description for a 2617 session that is simultaneously created at multiple layers. It allows 2618 the SDP descriptors for different layers to remain simple and clean. 2619 Chaining is not needed in the Megaco context, where it is possible to 2620 create separate terminations for the different layers of a connection. 2622 The 'chain' media attribute line has the following format: 2624 a=chain: 2626 The field can take on the following string values: 2627 "next", "previous" and "NULL". The value "NULL" is not equivalent to 2628 omitting the chain attribute from a description since it expressly 2629 precludes the possibility of chaining. If the 'chain' attribute is 2630 absent in an SDP description, chaining can still be realized by its 2631 presence in the previous or next description. 2633 6.0 List of Parameters with Representations 2635 This section provides a list of the parameters used in this document, 2636 and the formats used to represent them in SDP descriptions. 2638 In the representations of these parameters, string values (including 2639 single-character strings) are enclosed in double quotes (" "). 2640 Decimal numbers are do not have a prefix, while hex numbers 2641 are preceded by a 0x. 2643 In general, a "-" value can be used for any field that 2644 is not specified, is inapplicable or is implied. 2646 PARAMETER MEANING REPRESENTATION 2648 User name Constant "-" 2650 Session ID Decimal, Hex, 2651 or Alphanumeric 2652 At most 32 digits or 2653 34 characters. 2655 Version of Decimal or Hex 2656 SDP descriptor At most 32 digits 2658 Network type Constant "ATM" 2660 ATM address type String values: 2661 "NSAP", "E164", "GWID", 2662 "ALIAS" 2664 ATM address "NSAP": 40 hex digits, 2665 optionally dotted 2666 "E164": up to 15 decimal digits 2667 "GWID": up to 32 characters 2668 "ALIAS": up to 32 characters 2670 Session name Constant "-" 2672 Session start Decimal or hex equivalent 2673 time of 32-bit field 2675 Session stop Constant "0" 2676 time 2678 Virtual Circuit Decimal or hex equivalent 2679 Connection of 16 bits 2680 Identifier 2682 Bearer Connection Decimal or hex equivalent 2683 Group of 8 bits 2685 Port ID Decimal, Hex, 2686 or Alphanumeric. 2687 At most 32 digits or 2688 34 characters. 2690 Virtual Path Decimal or hex equivalent 2691 Identifier of 8 or 12 bits 2693 Virtual Circuit Decimal or hex equivalent 2694 Identifier of 16 bits 2696 Virtual Path Decimal or hex equivalent 2697 Connection of 16 bits 2698 Identifier 2700 Channel Decimal or hex equivalent 2701 Identifier of 8 bits 2703 Payload Decimal integer 0-127 2704 Type 2706 Profile String values: 2707 Class "ITU", "ATMF", 2708 "custom", , 2709 "IEEE:" 2710 : IEEE-registered OUI 2712 Profile Decimal integer 1-255 2714 End-to-end Up to 8 hex digits 2715 Connection 2716 Identifier 2718 AAL type String values: 2719 "AAL1","AAL1_SDT","AAL1_UDT", 2720 "AAL2", "AAL3/4", 2721 "AAL5", "User defined AAL" 2723 Silence suppression String values: 2724 Enable "on", "off" 2726 Kick-in timer Decimal or hex representation 2727 for silence of 16-bit field 2728 suppression 2730 Preferred Silence String values: 2731 Suppression Method "standard", "custom" 2733 SID Use String values: 2734 Method "No SID", "Fixed Noise", 2735 "Sampled Noise" 2737 Fixed Noise Decimal or hex representation 2738 Level of a 7-bit field 2740 Enable Echo String values: 2741 Cancellation "on", "off" 2743 Type of Echo String values: 2744 Cancellation "G165", "G168" 2746 Enable Gain String values: 2747 Control "on", "off" 2749 Level of inserted Decimal or hex equivalent 2750 Loss of 16-bit field 2752 UUI code range Decimal integer 0-15 2754 Encoding name String values: 2755 "PCMG", "SIDG", "SID729", 2756 any value from column 2 2757 of Table 1 2759 Packet length Decimal integer 0-45 2761 Packetization Decimal integer 1-500 2762 Interval 2764 Facsimile included String values: "on", "off" 2766 ATM service String values: 2767 category defined "CBR", "nrt-VBR", "rt-VBR", 2768 by the ATMF "UBR", "ABR", "GFR" 2770 ATM transfer String values: 2771 capability "DBR","SBR","ABT/IT","ABT/DT", 2772 defined by the "ABR" 2773 ITU 2775 QoS Class Decimal integer 0-5 2777 Broadband Bearer Decimal or hex representation 2778 Class of 5-bit field 2780 Susceptibility Decimal equivalent of 2781 to clipping a 2-bit field 2783 User plane Decimal equivalent of 2784 connection a 2-bit field 2785 configuration 2787 CDV type String values: 2788 "pp", "2p" 2790 Acceptable CDV Integer or hex equivalent 2791 of 24-bit field 2793 Cumulative CDV Integer or hex equivalent 2794 of 24-bit field 2796 Acceptable CTD Integer or hex equivalent 2797 of 16-bit field 2799 Cumulative CTD Integer or hex equivalent 2800 of 16-bit field 2802 Acceptable Integer or hex equivalent 2803 Cell Loss Ratio of 8-bit field 2805 CLP level String values: 2806 "0", "0+1" 2808 Peak Cells/second 2809 Cell Rate 2811 Sustained Cells/second 2812 Cell Rate 2814 Maximum Cells 2815 Burst Size 2817 CDVT Decimal integer or 2818 fraction, range determined 2819 by application. 2821 Minimum Cells/second 2822 Cell Rate 2824 Maximum Cells 2825 Frame Size 2827 Frame Discard String Values: 2828 Allowed "on", "off" 2830 CLP tagging String Values: 2831 Enabled "on", "off" 2833 NRM Decimal/hex equivalent 2834 of 3 bit field 2836 TRM - ditto- 2838 CDF -ditto- 2840 ADTF Decimal/Hex equivalent 2841 of 10 bit field 2843 Clock Recovery String values: 2844 Method "NULL", "SRTS", 2845 "adaptive" 2847 Forward Error String values: 2848 Correction Enable "NULL", "loss sensitive" 2849 "delay sensitive" 2851 Partial Fill Decimal integer 1-46 2852 or hex equivalent 2854 Bearer Type String Values: 2855 "PVC", "SVC", "CID" 2857 Structure Present String values: 2858 "on", "off" 2860 Block Size Decimal or hexadecimal 2861 equivalent of 16 bits 2863 Subchannel Count T1: Decimal integer 1-24 2864 or hex equivalent 2865 E1: Decimal integer 1-31 2866 or hex equivalent 2868 Maximum AAL5: Decimal or hex 2869 CPCS SDU size equivalent of 16 bits 2870 AAL2: 45 or 64 2872 Maximum number of Decimal integer 1-255 2873 subcell channels or hex equivalent 2875 Timer, combined use Integer decimal; range 2876 determined by application 2878 Assured Data String values: 2879 Transfer Enable "on", "off" 2881 Transmission Error String values: 2882 Detection Enable "on", "off" 2884 Maximum SSSAR-SDU Decimal or hex 2885 size, forward equivalent of 16-bit 2886 direction field 2888 Maximum SSSAR-SDU Decimal or hex 2889 size, backward equivalent of 16-bit 2890 direction field 2892 Service Access String values: 2893 Point "audio", "multirate" 2895 Circuit Mode String values: 2896 Enable "on", "off" 2898 Frame Mode String values: 2899 Enable "on", "off" 2901 Fax Demodulation String values: 2902 Enable "on", "off" 2904 Enable CAS transport String values: 2905 via Type 3 packets "on", "off" 2907 Enable DTMF transport String values: 2908 via Type 3 packets "on", "off" 2910 Enable MF transport String values: 2911 via Type 3 packets "on", "off" 2913 Enable MF (R1) String values: 2914 transport via "on", "off" 2915 Type 3 packets 2917 Enable MF (R2) String values: 2918 transport via "on", "off" 2919 Type 3 packets 2921 PCM encoding String values: 2922 " A", " Mu" 2924 Maximum length of a Decimal or hex 2925 frame mode data unit, equivalent of 2926 forward direction 16-bit field 2928 Maximum length of a -ditto- 2929 frame mode data unit, 2930 backward direction 2932 Application that uses String values: 2933 AAL5 "h323c","af83", 2934 "assuredSSCOP", 2935 "nonassuredSSCOP", 2936 "itu_i3651", "itu_i3652", 2937 "itu_i3653", "FRF11" 2939 Screening Indication Decimal or hex 2940 equivalent of 4 bits. 2942 Leaf Sequence Number Decimal or hex 2943 equivalent of 32 bits. 2945 Coding standard for the Decimal or hex 2946 connection scope selection equivalent of 2947 IE 2 bits 2948 Definition: UNI 4.0 [5] 2950 Type of connection scope Decimal or hex 2951 Definition: UNI 4.0 [5] equivalent of 4 bits 2953 Connection scope selection Decimal or hex equivalent 2954 Definition: UNI 4.0 [5] of 8 bits 2956 RTCP port number for Odd decimal in range 1024 to 2957 H.323 Annex C applications 65535 2959 IP address for receipt Dotted decimal, 7-15 chars 2960 of RTCP packets 2962 Chain pointer String values: "next", 2963 "previous", "NULL" 2965 7.0 Examples of ATM session descriptions using SDP 2967 An example of a complete AAL1 session description in SDP is: 2969 v=0 2970 o=- A3C47F21456789F0 0 ATM NSAP 2971 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 2972 s=- 2973 c=ATM NSAP 2974 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 2975 t=0 0 2976 m=audio $ AAL1/AVP 18 0 96 2977 a=atmmap:96 G727-32 2978 a=eecid:B3D58E32 2980 An example of a complete AAL2 session description in SDP is: 2982 v=0 2983 o=- A3C47F21456789F0 0 ATM NSAP 2984 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 2985 s=- 2986 c=ATM NSAP 2987 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 2988 t=0 0 2989 m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1 2990 a=eecid:B3E32 2992 The AAL2 session descriptor below is the same as the one above 2993 except that it states an explicit preference for a voice codec, a 2994 voiceband data codec and a voiceband fax codec. Further, it defines 2995 the profile AAL2/custom 100 rather than assume that the far-end is 2996 cognizant of the elements of this profile. 2998 v=0 2999 o=- A3C47F21456789F0 0 ATM NSAP 3000 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 3001 s=- 3002 c=ATM NSAP 3003 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 3004 t=0 0 3005 m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1 3006 a=eecid:B3E32 3007 a=profiledesc:AAL2/custom 100 0-7 PCMG 40 5 0-7 SIDG 1 3008 5 8-15 G726-32 40 10 8-15 SIDG 1 5 3009 a=vsel:G726-32 40 10 3010 a=dsel:PCMU - - 3011 a=fsel:G726-32 40 10 3013 8.0 Representation of data media 3015 The following encoding names in Table 1 can refer to data as well 3016 as audio media: X-CCD and X-CCD-CAS in Table 1. 3018 The following encoding names in Table 1 refer to data media: 3019 X-FXDMOD-3 in Table 1. 3021 In the AAL1 context, X-CCD and X-CCD-CAS can be represented as 3022 "audio" codecs that are dynamically mapped into payload types. This 3023 is done through the 'atmmap' attribute, as described earlier. For 3024 example: 3025 m=audio 27 AAL1/AVP 98 3026 a=atmmap:98 X-CCD 3028 implies that AAL1 VCCI=27 is used for n x 64 transmission. 3030 Currently, AAL1 in unsuitable for transmitting demodulated facsimile 3031 because it lacks the bearer plane mechanisms (equivalent to AAL2 3032 type 3 messages) for transmitting control information. 3034 In the AAL2 context, these "codecs" can be assigned profile types and 3035 numbers. Even though it is not possible to construct 3036 profile tables as described in ITU I.366.2 for these "codecs", it 3037 is preferable to adopt the common AAL2 profile convention in their 3038 case. An example AAL2 profile mapping for these could be as follows: 3040 PROFILE TYPE PROFILE NUMBER "CODEC" (ONLY ONE) 3041 "custom" 200 X-CCD 3042 "custom" 201 X-FXDMOD-3 3044 The profile does not identify the number of subchannels ('n' in nx64). 3045 This is known by other means such as the 'sbc' media attribute line. 3046 Currently, there is no definition of n x 64 trunking with CAS for AAL2. 3048 For example, the media information line: 3049 m=audio $ AAL2/custom 200 3050 a=sbc:6 3052 implies a 384 kbps n x 64 circuit using AAL2 adaptation. 3054 In the case of fax demodulation and remodulation (ITU 3055 I.366.2), parameters such as information type, image data 3056 size and control type are negotiated in the 'bearer plane' 3057 via type 3 messages. There is no need to define 3058 several encoding names for these control streams. 3060 9.0 Security Considerations 3062 9.1 Bearer Security 3063 At present, standard means of encrypting ATM and AAL2 bearers 3064 are not conventionalized in the same manner as means of encrypting RTP 3065 payloads. Nor has the authentication of ATM or AAL2 bearer 3066 signaling. 3068 If and when an ATM or AAL2 bearer encryption convention is 3069 conventionalized, 3070 the SDP encryption key line (k=) defined in rfc2327 can be used 3071 to represent the encryption key and the method of obtaining the 3072 key. In the ATM and AAL2 contexts, the term 'bearer' can include 3073 'bearer signaling' as well as 'bearer payloads'. 3075 9.2 Security of the SDP description 3077 The SDP session descriptions might originate in untrusted areas 3078 such as 3079 equipment owned by end-subscribers or located at end-subscriber 3080 premises. SDP relies on the security mechanisms of the encapsulating 3081 protocol or layers below the encapsulating protocol. Examples of 3082 encapsulating protocols are the Session Initiation Protocol (SIP), 3083 MGCP and Multimedia Gateway Control Protocol (MEGACO). No additional 3084 security mechanisms are needed. SIP, MGCP and MEGACO 3085 can use IPSec authentication as described in RFC1826 [Ref. 3086 27]. IPSec encryption can be optionally used with authentication to 3087 provide an additional, potentially more expensive level of security. 3088 IPSec security associations can be made between equipment located in 3089 untrusted areas and equipment located in trusted areas through 3090 configured shared secrets or the use of a certificate authority. 3092 10.0 Remaining Tasks 3094 In the authors' opinion, the following tasks need to be done to 3095 complete the definition of the basic conventions needed to describe 3096 ATM connections in SDP. 3098 - Adequate representation of AAL2 parameters, such as some of the 3099 parameters found in Q.2630.1. 3101 - Additional, detailed examples of the use of these SDP conventions. 3103 - Address the so-called UBR+ service category. Where is it defined? 3105 - Add a table of contents. 3107 References 3109 [1] IETF RFC 2327, 'SDP: Session Description Protocol', April '98, 3110 Mark Handley and Van Jacobson. 3112 [2] IETF RFC 1889, 'RTP: A Transport Protocol for Real-Time 3113 Applications', Jan. 1996. 3115 [3] IETF RFC 1890, 'RTP Profile for Audio and Video Conferences 3116 with Minimal Control', Jan. 1996. 3118 [4] ATMF UNI 3.1 Specification, af-uni-0010.002. Of special 3119 interest for this document is Section 5.4.5.5, ATM Adaptation 3120 Layer Parameters. 3122 [5] ATMF UNI 4.0 Signaling Specification, af-sig-0061.000. 3124 [6] ATMF Traffic Management Specification, Version 4.1, af-tm- 3125 0121.000. 3127 [7] ATMF Circuit Emulation Service (CES) Interoperability 3128 Specification, version 2.0, af-vtoa-0078.000, Jan. 97. 3130 [8] ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for 3131 Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997. 3133 [9] ATMF Specifications of (DBCES) Dynamic Bandwidth Utilization - 3134 in 64kbps Timeslot Trunking over ATM - using CES, af-vtoa- 3135 0085.000, July 1997. 3137 [10] ITU-T I.363.1, B-ISDN ATM Adaptation Layer Specification: Type 3138 1 AAL, August 1996. 3140 [11] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type 3141 2 AAL, Sept. 1997. 3143 [12] ITU-T I.366.1, Segmentation and Reassembly Service Specific 3144 Convergence Sublayer for AAL Type 2, June 1998. 3146 [13] ITU-T I.366.2, AAL Type 2 Reassembly Service Specific 3147 Convergence Sublayer for Trunking, Feb. 99. 3149 [14] Draft ietf-avt-telephone-tones-05.txt, RTP payloads for 3150 Telephone Signal Events, S.B.Petrack, Nov. 17, 1998. 3152 [15] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling. 3154 [16] Amendment 1, 2, 3 and 4 to ITU-T Q.2931, B-ISDN Application 3155 Protocol for Access Signaling. 3157 [17] SAP: Session Announcement Protocol , draft-ietf-mmusic-sap-v2- 3158 04.txt, Mark Handley, Colin Perkins and Edmund Whelan . 3160 [18] rfc2543, Handley, M., H. Schulzrinne , Schooler, E. and 3161 Rosenberg, J., "Session Initiation Protocol (SIP)", March 3162 1999. 3164 [19] rfc1349, Type of Service in the Internet Protocol Suite. P. 3165 Almquist. July 1992. 3167 [20] rfc2474, Definition of the Differentiated Services Field (DS 3168 Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. 3169 Baker, D. Black. December 1998. 3171 [21] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type 3172 5 AAL, Aug. 1996. 3174 [22] ATMF PNNI 1.0, af-pnni-0055.000, March 1996. 3176 [23] ietf-avt-rtp-new-05.txt, Oct. 21, 1999, RTP: A Transport 3177 Protocol for Real-Time Applications. 3179 [24] ietf-avt-profile-new-07.txt, Oct. 21, 1999, RTP Profile for 3180 Audio and Video Conferences with Minimal Control. 3182 [25] Media Gateway Control Protocol (MGCP), Mauricio Arango, Isaac 3183 Elliott, Christian Huitema, Scott Pickett, Version 1.0, 3184 RFC2705. 3186 [26] draft-ietf-Megaco-merged-00.txt, April, 2000, Media Gateway 3187 control (Megaco) protocol, Fernando Cuervo, Nancy Greene, Christian 3188 Huitema, Abdallah Rayhan, Brian Rosen, John Segers. 3190 [27] IP Authentication Header, R. Atkinson, August 1995, RFC1826. 3192 [28] ITU I.371, Traffic Control and Congestion Control in the BISDN. 3194 [29] ITU E.191, BISDN Numbering and Addressing. 3196 [30] ATM Forum Addressing: Reference Guide, af-ra-0106.000. 3198 [31] http://www.isi.edu/in-notes/iana/assignments/rtp-parameters 3199 for a list of codecs with static payload types. 3201 [32] ITU Q.2941-2, Digital Subscriber Signalling System No. 2 3202 (DSS 2): Generic identifier transport extensions. 3204 [33] ITU Q.2961, Digital subscriber signalling system no.2 (DSS 2) 3205 - additional traffic parameters. Also, Amendment 2 to Q.2961. 3207 [34] ITU Q. 2965.1, Digital subscriber signalling system no.2 (DSS 2) 3208 - Support of Quality of Service classes. 3210 [35] ITU Q. 2965.2, Digital subscriber signalling system no.2 (DSS 2) 3211 - Signalling of individual Quality of Service parameters. 3213 [36] ITU Q.1901, Bearer Independent Call Control Protocol. 3215 [37] ITU Q.2630.1, AAL type 2 signaling protocol - capability set 1. 3217 [38] ITU I.363.5, B-ISDN ATM Adaptation Layer specification: Type 5 3218 AAL. 3220 [39] I.365.1,Frame relaying service specific convergence sublayer 3221 (FR-SSCS). 3223 [40] I.365.2, B-ISDN ATM adaptation layer sublayers: service 3224 specific coordination function to provide the connection 3225 oriented network service. 3227 [41] I.365.3, B-ISDN ATM adaptation layer sublayers: service 3228 specific coordination function to provide the 3229 connection-oriented transport service. 3231 [42] I.365.4, B-ISDN ATM adaptation layer sublayers: Service specific 3232 convergence sublayer for HDLC applications. 3234 [43] Q.2110, B-ISDN ATM adaptation layer - service specific connection oriented 3235 protocol (SSCOP). 3237 [44] af-vtoa-0113.000, ATM trunking using AAL2 for narrowband services. 3239 [45] H.323-2, Packet-based multimedia communications systems. 3241 [46] af-vtoa-0083.000, Voice and Telephony Over ATM to the Desktop. 3243 [47] I.356, BISDN ATM layer cell transfer performance. 3245 [48] ITU Q.2957, Digital Subscriber Signaling System No. 2, User to user 3246 signaling. 3248 [49] rfc1305, Network Time Protocol, version 3. 3250 Acknowledgements 3251 The authors wish to thank several colleagues at Cisco and in the 3252 industry who have contributed towards the development of these SDP 3253 conventions, and who have reviewed, implemented and tested these 3254 constructs. Valuable technical ideas that have been incorporated 3255 into this internet draft have been provided by Hisham Abdelhamid, 3256 David Auerbach, Robert Biskner, Bruce Buffam, Steve Casner, Alex Clemm, 3257 Bill Foster, Snehal Karia, Raghu Thirumalai Rajan, Joe Stone, Bruce 3258 Thompson, Dan Wing and Ken Young of Cisco, Michael Brown, Rade 3259 Gvozdanovic, Graeme Gibbs, Tom-PT Taylor and Sophia Scoggins of 3260 Nortel Networks, Brian Rosen, Tim Dwight and Michael Mackey 3261 of Marconi, Ed Guy and Petros Mouchtaris of Telcordia, Christian 3262 Groves of Ericsson, Charles Eckel of Vovida Networks, Tom Jepsen of 3263 Fujitsu and Mahamood Hussain of Hughes Software Systems. 3264 The authors also wish to thank the ISC device control group, 3265 and the MMUSIC and MEGACO subgroups of the IETF, especially Bill Foster, 3266 Jeorg Ott and Brian Rosen for their help in the preparation of this 3267 document. 3269 If there are names of contributors that have been overlooked, please 3270 let the authors know before the document goes on standards track. 3272 Authors' Addresses 3274 Rajesh Kumar 3275 Cisco Systems, Inc. 3276 M/S SJC01/3 3277 170 West Tasman Drive 3278 San Jose, CA 95134-1706 3279 Phone: 1-800-250-4800 3280 Email: rkumar@cisco.com 3282 Mohamed Mostafa 3283 Cisco Systems, Inc. 3284 M/S SJC01/3 3285 170 West Tasman Drive 3286 San Jose, CA 95134-1706 3287 Phone: 1-800-250-4800 3288 Email: mmostafa@cisco.com 3290 Full Copyright Statement 3292 Copyright (C) The Internet Society (March 2, 2000). All Rights 3293 Reserved. 3295 This document and translations of it may be copied and furnished to 3296 others, and derivative works that comment on or otherwise explain it 3297 or assist in its implementation may be prepared, copied, published 3298 and distributed, in whole or in part, without restriction of any 3299 kind, provided that the above copyright notice and this paragraph 3300 are included on all such copies and derivative works. However, this 3301 document itself may not be modified in any way, such as by removing 3302 the copyright notice or references to the Internet Society or other 3303 Internet organizations, except as needed for the purpose of 3304 developing Internet standards in which case the procedures for 3305 copyrights defined in the Internet Standards process must be 3306 followed, or as required to translate it into languages other than 3307 English. 3309 The limited permissions granted above are perpetual and will not be 3310 revoked by the Internet Society or its successors or assigns. 3312 This document and the information contained herein is provided on an 3313 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3314 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3315 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3316 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3317 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."