idnits 2.17.1 draft-dugan-ipdc-connection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 246 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 188: '... MUST This word, or the ad...' RFC 2119 keyword, line 191: '... MUST NOT This phrase means that ...' RFC 2119 keyword, line 194: '... SHOULD This word, or the adj...' RFC 2119 keyword, line 199: '... MAY This word, or the adjec...' RFC 2119 keyword, line 201: '...lude this option MUST be prepared to ...' (40 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '... This docum...' == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... and its w...' == Line 18 has weird spacing: '... and may be...' == Line 19 has weird spacing: '...me. It is i...' == (241 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. -- 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.) -- The document date (August 1998) is 9376 days in the past. Is this intentional? 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: '1' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1322, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1323, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-03 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-00 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- 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' Summary: 12 errors (**), 0 flaws (~~), 28 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT IPDC Connection Control Protocol August 1998 2 INTERNET DRAFT Andrew Dugan 3 Level 3 Communications 4 Title: draft-dugan-ipdc-connection-00.txt Date: August 1998 6 IPDC 7 Connection Control Protocol 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The protocol described in this document is a member of the IP Device 31 Control (IPDC) family of protocols. The IPDC protocols are proposed 32 as a protocol suite, components of which can be used individually or 33 together to perform connection control, media control, and signaling 34 transport for environments where the service control logic is 35 separated from the network access server. Please see the references 36 section for other IPDC documents. 38 The protocol specification presented here is intended for use between 39 a media gateway controller and a media gateway. The media gateway 40 may be capable of acting as a voice over IP gateway, voice over ATM 41 gateway, dialup modem media gateway, circuit switch, or cross- 42 connect. Using the IP Connection Control protocol presented here, 43 the media gateway controller can setup, modify and teardown 44 connections within or between media gateways. 46 Table of Contents 48 1.0 INTRODUCTION 49 1.1 BACKGROUND 50 1.2 SPECIFICATION OF REQUIREMENTS 51 2.0 MESSAGES 52 2.1 RCON - REQUEST CONNECTION 53 2.2 ACON - ACCEPT CONNECTION 54 2.3 MCON - MODIFY CONNECTION 55 2.4 AMCN - ACCEPT MODIFY CONNECTION 56 2.5 RCR - RELEASE CONNECTION REQUEST 57 2.6 ACR - RELEASE CONNECTION COMPLETED 58 3.0 AVP VALUES 59 3.1 BEARER CAPABILITY AVP 60 3.2 CAUSE CODE AVP 61 3.3 CONNECTION DIRECTION AVP 62 3.4 CONNECTION ID AVP 63 3.5 DYNAMIC PAYLOAD TYPE AVP 64 3.6 ENDPOINT 1 IPDC-RESOURCE 65 3.7 ENDPOINT 2 IPDC-RESOURCE 66 3.8 QOS AVP 67 3.9 RADIUS - CALLED PHONE NUMBER 68 3.10 RADIUS - CALLING PARTY NUMBER AVP 69 3.11 REQUESTED PRIORITY AVP 70 3.12 SESSION KEY AVP 71 3.13 STATISTICS REQUEST AVP 72 3.14 STATISTICS REPORT AVP 73 4.0 PROTOCOL DEFINITION 74 4.1 LOOPBACK CONNECTION 75 5.0 SECURITY CONSIDERATIONS 76 6.0 RIGHTS AND PERMISSIONS 77 7.0 ACKNOWLEDGMENTS 78 8.0 REFERENCES 79 9.0 AUTHOR'S ADDRESS 81 1.0 Introduction 83 The protocol specification presented here is intended for use between 84 a media gateway and a media gateway controller. The media gateway 85 may be capable of acting as a voice over IP gateway, dialup modem 86 access server, or circuit switch. Using the IP Connection Control 87 protocol within this document, the controller entity can send 88 messages to the media gateway to setup and teardown connections 89 within an media gateway or between media gateways. 91 1.1 Background 93 This protocol is part of the IP Device Control (IPDC) family of 94 protocols. The IPDC protocols have been proposed as a protocol suite 95 which can be used individually or together to perform connection 96 control, media control, and signaling transport for environments 97 where the service control logic is separated from the network . 98 Please see the references section for other IPDC documents. 100 This document describes the commands and attribute value pairs that 101 are necessary within the IPDC protocol to allow the media gateway 102 controller to perform call and media control on the media gateway. 103 This control provides the ability for the service control logic to 104 setup, modify and teardown connections within the media gateway. 106 A media gateway may support multiple types of connections within 107 itself and to other media gateways. These connections are based upon 108 the specification of two media gateway entities or endpoints for each 109 connection request. The IPDC base specification describes the format 110 for the specification of these endpoints. This format may be seen in 111 the definition of the IPDC-Reference AVP. The base document 112 describes a set of References for device based endpoints as well as 113 other entity types for packet based endpoints. The following 114 endpoint types and corresponding reference types are supported within 115 the IPCC command set. 117 GSTN: This endpoint specifies a channel that interconnects the 118 media gateway with a channel on the GSTN. Entity type: access- 119 termintion or trunk-termination 121 RTP: This endpoint specifies IP addresses and ports to support an 122 RTP connection between the media gateway and RTP ports on another 123 device. Entity type: RTP-port 125 H.323: This endpoint specifies the H.323 address of another device 126 that is capable of receiving an H.323 connection from the media 127 gateway. Entitiy type: H.323-spec 129 SIP: This endpoint specifies the SIP address of another device 130 that is capable of receiving using SIP to establish a connection 131 from the media gateway: Entity type: SIP-spec 133 ATM: (for further study). Entity type: type ATM-spec 135 Modem: The modem endpoint specifies an internal media gateway 136 resource that may be used for terminating modem calls. Entity 137 type: modem 139 Playback: The playback endpoint specifies an internal media 140 gateway resource that may be used for streaming audio out on the 141 other endpoint involved in the connection. Entity type: stream- 142 source 144 Record: The record endpoint specifies an internal media gateway 145 resource that may be used for collecting and storing streaming 146 audio coming from the other endpoint involved in the 147 connection. Entity type: stream-recorder 149 Conference: The conference endpoint specifies an internal media 150 gateway resource that may be used for terminating the call to an 151 audio bridge. Entity type: conf-port 153 Fax: The fax endpoint specifies an internal media gateway resource 154 that may be used for collecting or forwarding faxes. Entity type: 155 Fax-port 157 Other Internal Device: Media gateways will have other resources 158 that do not have currently assigned reference types. This port 159 type is a generic placeholder for these types of devices. Entity 160 type: Device 162 It is important to note that the IPDC Connection Control 163 specification is limited to the establishment of connections between 164 endpoints and is not a protocol for controlling the services on those 165 endpoints. For example, if the protocol is used to establish a 166 connection between a GSTN port and a conference resource, the 167 protocol does not provide any mechanisms for controlling such things 168 as authentication and admission of callers to a conference, control 169 of which media streams are played out on which ports, etc. 170 Similarly, if the connection is to a fax endpoint, the protocol does 171 not provide the commands to instruct the device to collect a fax and 172 store it in a particular mailbox or to transmit a specific fax out 173 the other port in the connection. The control interfaces for 174 instructing the server to perform its application function are 175 expected to be provided by an interface that is outside the scope of 176 IPDC. 178 Using the endpoint types allowed in the call control commands it is 179 possible to establish connections between any two types of endpoints. 180 It is also to establish connections between endpoints of the same 181 type. 183 1.2 Specification of Requirements 185 In this document, several words are used to signify the requirements 186 of the specification. These words are often capitalized. 188 MUST This word, or the adjective "required", means that the 189 definition is an absolute requirement of the specification. 191 MUST NOT This phrase means that the definition is an absolute 192 prohibition of the specification. 194 SHOULD This word, or the adjective "recommended", means there 195 may exist valid reasons in particular circumstances to ignore this 196 item, but the full implications must be understood and carefully 197 weighed before choosing a different course. 199 MAY This word, or the adjective "optional", means that this 200 item is one of an allowed set of alternatives. An implementation 201 which does not include this option MUST be prepared to inter-operate 202 with another implementation which does include the option. 204 2.0 Messages 206 This section describes the IPCC commands that are described within 207 this document. All IPCC implementations that support the connection 208 control extension MUST support all of the following commands: 210 Command Command Code DESCRIPTION 211 ------------------------------------------------------------------------- 212 RCON 1200 Request Connection between two 213 endpoints 214 ACON 1201 Accept Connection 215 MCON 1202 Modify Connection 216 AMCN 1203 Accept modify connection 217 RCR 1204 Release channel request 218 ACR 1205 Release channel complete 220 2.1 RCON - Request Connection 222 The RCON command is sent from the controller to the media gateway to 223 request a connection between two endpoints. 225 The table below identifies the AVPs that may be used with the RCON 226 command. Because there are a number of different types of endpoints 227 types that may be used within the RCON command, and some of the AVPs 228 may be used with some types of connections and not others, the table 229 includes an indication of which endpoints may use each of the AVPs. 230 This indication includes a definition of whether the AVP is required 231 with the use of that endpoint or whether the AVP may be optionally 232 included under some circumstances. Generally, if the parameter may be 233 optionally included, the Notes column of the table describes the 234 conditions under which it may be used. 236 AVP Type R/O Notes 237 ----------------------------------------------------------------- 238 Command R-All Required on all IPDC commands. 239 Host-IP-Address R-All Required on all IPDC commands. 240 Endpoint1 IPDC-Reference R-All Specifies the first endpoint 241 in this connection. 242 Endpoint2 IPDC-Reference R-All Specifies the second endpoint 243 in this connection. 244 Connection Direction R-All Specifies whether this 245 connection should be 246 established as bi-directional 247 or uni-directional. 248 Dynamic Payload Type R-RTP Specifies the payload type for 249 RTP connections as defined in 250 H.235. 252 Session Key O-RTP Specifies the session key for 253 RTP connections as defined in 254 H.235. 255 Bearer Capability R-All Identifies whether this is a 256 voice of the Channel (BCC) 257 or data call. 258 Radius - Called R-Modem Used only for authentication 259 Phone number on modem termination calls. 260 This information must be passed 261 from the access device to any 262 authentication servers being 263 used for modem terminations. 264 Radius - Calling R-Modem 265 Party number 266 Requested Priority O-All Required only for priority 267 calls. If set to forced, the 268 media gateway will attempt to 269 connect the call even if it 270 requires the tear-down of an 271 existing non-priority call. 272 Statistics Request O-All Indicates whether statistics 273 should be collected on this 274 call and identifies the 275 statistics group(s) to be 276 collected. 277 QoS O-H.323 Used for networks where 278 O-RTP Quality of Service controls 279 O-SIP are available. 280 Event Script O-All The script is an ASCII text 281 string of variable length, 282 formatted according to the 283 scripting language defined by 284 the script type parameter. 285 Script Type O-All This parameter specifies the 286 script type used in the event 287 script. The script type 288 presented in this document 289 is script type 1, and is the 290 default if this parameter 291 is not specified 292 Symbol Set O-All The symbol set used in the 293 script may be specified as 294 well. The symbol set defined 295 in this document is symbol set 296 1, and is the default if this 297 parameter is not specified. 298 Maximum Buffer Size O-All If parameter is not specified, 299 default buffer size is 512 300 bytes. 302 Table 1 - RCON AVPs 304 2.2 ACON - Accept Connection 306 The media gateway as a successful response to an RCON message sends 307 the ACON message. If the RCON message fails, the media gateway would 308 have sent a message reject (MRJ) response. The source and 309 destination endpoints are optional to handle the case where the media 310 gateway manages and allocates its own endpoints. If the media 311 gateway selects the endpoint for a connection the media gateway MUST 312 return the endpoint address in the ACON. The media gateway allocates 313 its own endpoints in cases where the RCON message uses a wildcard or 314 group designator as a source or destination endpoint. 316 AVP Type R/O Notes 317 ------------------------------------------------------------------- 318 Command R-All Required on all IPDC commands. 319 Host-IP-Address R-All Required on all IPDC commands. 320 Connection ID R-All Required for all call control 321 messages. 322 Endpoint 1 IPDC-Reference O-All See the IPDC base specification 323 for a description of this AVP. 324 Endpoint 2 IPDC-Reference O-All See the IPDC base specification 325 for a description of this AVP. 327 Table - 2 ACON AVPS 329 2.3 MCON - Modify Connection 331 The MCON command allows the media gateway controller to change 332 parameters or endpoints for a connection. With the use of an existing 333 connection ID, any AVP specified within the MCON message will be 334 interpreted as a request to change the setting for that AVP within 335 the call. 337 AVP Type R/O Notes 338 --------------------------------------------------------------------- 339 Command R-All Required on all IPDC commands 340 Host-IP-Address R-All Required on all IPDC commands 341 Connection ID R-All Required for all call control 342 messages 343 Endpoint 1 IPDC-Reference O-All See the IPDC base specification 344 for a description of this AVP. 345 Endpoint 2 IPDC-Reference O-All See the IPDC base specification 346 for a description of this AVP. 347 Connection Direction O-All Specifies whether this 348 connection 349 should be established as 350 bi-directional or uni-directional 351 Dynamic Payload Type O-RTP Specifies the payload type for 352 RTP connections as defined in 353 H.235. 354 Session Key O-RTP Specifies the session key for RTP 355 connections as defined in H.235. 356 QOS O-H.323 Used for packet networks where 357 O-RTP Quality of Service controls are 358 O-SIP available. 359 Statistics Request O-All Indicates whether statistics 360 should be collected on this 361 call and identifies the 362 statistics group(s) to be 363 collected. 364 Event Script O-All ASCII text string formatted 365 according to the scripting 366 language defined by the script 367 type parameter. 368 Script Type O-All This parameter specifies the 369 script type used in the event 370 script. The script type 371 presented in this document is 372 script type 1, and is the default 373 if this parameter is not 374 specified. 375 Symbol Set O-All The symbol set used in the script 376 may be specified as well. The 377 symbol set defined in this 378 document is symbol set 1, and is 379 the default if this parameter 380 is not specified. 381 Maximum Buffer Size O-All If parameter is not specified, 382 default buffer size is 512 bytes. 384 Table 3 - MCON AVPs 386 2.4 AMCN - Accept Modify Connection 388 This command is sent in response to an MCON. Since the MCON command 389 is also a request to query the state of a connection, all AVPs within 390 the response are required if they are applicable to the connection 391 type. 393 AVP Type R/O Notes 394 ------------------------------------------------------------------ 395 Command R-All Required on all IPDC commands 396 Host-IP-Address R-All Required on all IPDC commands 397 Connection ID R-All Required for all call control 398 messages 399 Endpoint 1 IPDC-Reference O-All See the IPDC base specification 400 for a description of this AVP. 401 This AVP as well as the 402 endpoint 2 are optional because 403 they MUST only be returned when 404 the MCON request contained 405 wildcards or groups identifiers 406 and the ACON responds with the 407 allocated references. 408 Endpoint 2 IPDC-Reference O-All See the IPDC base specification 409 for a description of this AVP 411 Table 4 - AMCN AVPs 413 2.5 RCR - Release Connection request 415 This command is sent from the media gateway controller to request the 416 media gateway to tear-down a connection and free any allocated 417 resources for that connection. 419 AVP Type R/O Notes 420 ---------------------------------------------------------------- 421 Command R-All Required on all IPDC commands. 422 Host-IP-Address R-All Required on all IPDC commands 423 Connection ID R-All Required for all call control 424 messages 425 Cause code R-All 427 Table 5 - RCR AVPs 429 2.6 ACR - Release Connection completed 431 This command is sent in response to a request to release a 432 connection. The message contains a number of statistical AVPs that 433 are required in for packet connections. 435 AVP Type R/O Notes 436 ----------------------------------------------------------------- 437 Command R-All Required on all IPDC commands. 438 Host-IP-Address R-All Required on all IPDC commands 439 Connection ID R-All Required on all call control 440 messages 441 Packet Statistics O-H.323 This AVP contains RTP 442 O-RTP statistics for packet based 443 O-SIP connections. 445 Table 6 - ACR AVPs 447 3.0 AVP Values 449 This section will define the new AVPs that are applicable to the 450 commands described within this document. Some of the base AVPs such 451 as command and host-IP-address are defined in the IPDC base 452 specification document, others such as event type, script type, 453 symbol set and buffer size are defined in the IPMC specification 454 document [4]. 456 3.1 Bearer Capability AVP 458 0 1 2 3 459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | AVP Code | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | AVP Length | Reserved |P|T|V|E|H|M| 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Bearer Capability | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 AVP Code 470 1301 Bearer Capability 472 AVP Length 474 The length of this attribute MUST be 12. 476 AVP Flags 478 The flag field MUST have bit one (Mandatory Support) set. 479 The flag field MUST not have bit four (Vendor Specific AVP) set. 481 Bearer Capability 483 The Bearer Capability is used for data connections to specify the 484 type of connection expected on the GSTN side of the media gateway. 485 The encoding is the same as the octet "Information Transfer 486 Capability" from the User Service Information parameter from ANSI 487 T1.113.3. The following bearer types have been defied: 489 Voice Call 0 490 64K Data Call 8 491 56K Data Call 9 492 Modem Call (3.1K audio) 16 494 The bearer capability field is of type Interger32 496 3.2 Cause Code AVP 498 0 1 2 3 499 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | AVP Code | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | AVP Length | Reserved |P|T|V|E|H|M| 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Cause Code Type | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Cause Code | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 AVP Code 512 1302 Cause Code 514 AVP Length 516 The length of this attribute MUST be at least 16 to accommodate 8 517 bytes of AVP header information plus a 4 byte cause code type and 518 a 4 byte cause code 520 AVP Flags 522 The flag field MUST have bit one (Mandatory Support) set. 523 The flag field MUST not have bit four (Vendor Specific AVP) set. 525 Cause Code Type 527 The cause code is used for release of connections in order to 528 indicate the reason why a connection is being torn down. The AVP 529 is made up of two values. The first value is contained in the 530 first 4 bytes and indicates the type of cause code contained in 531 the next field. Values for this attribute may be: 533 1 ISDN 534 Other values reserved for future use 536 The cause code values indicates the reason why a connection is 537 being torn down. Values for this attribute may be: 539 A one byte value. For ISDN cause codes, the encoding is defined in 540 ANSI T1.113.3, using the CCITT coding standard. The following is a 541 list of ISDN cause codes values is for reference only: 543 1 Unassigned (unallocated) number 544 2 No route to specified transit network 545 3 No route to destination 546 6 Channel unacceptable 547 7 Call awarded and being delivered in 548 an established channel 549 16 Normal call clearing 550 17 User busy 551 18 No user responding 552 19 No answer from user (user alerted) 553 21 Call rejected 554 22 Number changed 555 26 Non-selected user clearing 556 27 Destination out of order 557 28 Invalid number format (incomplete number) 558 29 Facility rejected 559 30 Response to status enquiry 560 31 Normal, unspecified 561 34 No circuit/channel available 562 38 Network out of order 563 41 Temporary failure 564 42 Switching system congestion (gateway controller, 565 media gateway, IP network) 566 43 Access information discarded 567 44 Requested circuit/channel not available 568 47 Resource unavailable, unspecified 569 50 Requested facility not subscribed 570 57 Bearer capability not authorized 571 58 Bearer capability not presently available 572 63 Service or option not available 573 65 Bearer capability not implemented 574 66 Channel type not implemented 575 69 Requested facility not implemented 576 70 Only restricted digital information bearer 577 capability is available 579 79 Service or option not implemented, unspecified 580 81 Invalid call reference value 581 82 Identified channel does not exist 582 83 A suspended call identity exists but this call 583 identity does not 584 84 Call identity in use 585 85 No call suspended 586 86 Call having the requested call identity has been cleared 587 88 Incompatible destination 588 91 Invalid transit network selection 589 95 Invalid message, unspecified 590 96 Mandatory information element is missing 591 97 Message type non-existent or not implemented 592 98 Message not compatible with call state, message type 593 non-existent/implemented 594 99 Information element non-existent or not implemented 595 100 Invalid information element contents 596 101 Message not compatible with call state 597 102 Recovery on time expiry 598 111 Protocol error, unspecified 599 127 Interworking, unspecified 601 3.3 Connection Direction AVP 603 0 1 2 3 604 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | AVP Code | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | AVP Length | Reserved |P|T|V|E|H|M| 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Connection Direction | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 AVP Code 614 1303 Connection Direction 616 AVP Length 618 The length of this attribute MUST be 12. 620 AVP Flags 622 The flag field MUST have bit one (Mandatory Support) set. 623 The flag field MUST not have bit four (Vendor Specific AVP) set. 625 Connection Direction 626 The Connection Direction AVP supports the capability to establish 627 a one-way or two way connection with the RCON or MCON commands. 628 The values for this attribute may be 630 1 = Uni-directional connection from endpoint 1 to endpoint 2 631 2 = Uni-directional connection from endpoint 2 to endpoint 1 632 3 = Bi-directional connection 634 3.4 Connection ID AVP 636 0 1 2 3 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | AVP Code | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | AVP Length | Reserved |P|T|V|E|H|M| 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Connection ID | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 AVP Code 648 1304 Connection ID 650 AVP Length 652 The length of this attribute MUST be 12. 654 AVP Flags 656 The flag field MUST have bit one (Mandatory Support) set. 657 The flag field MUST not have bit four (Vendor Specific AVP) set. 659 Connection ID 661 The connection ID is used for all connection related messages 662 within IPDC. It must remain the same for all messages exchanged 663 for the same connection. The data is a 4 byte value that is 664 assigned by the media gateway for each connection established by 665 the gateway. The connection ID is returned to the media gateway 666 controller in the ACON response to each RCON request. 668 The value of the Connection ID attribute should be assigned by the 669 media gateway such that it is guaranteed to be unique within that 670 media gateway for a long period of time. The recommended method of 671 assigning Connection Ids is to use monotonically increasing 672 numbers that are continuous across reboot. If it is not possible 673 to maintain consistency across reboot, the media gateway may also 674 generate a random number to begin the sequence again. 676 The Connection ID field is of type integer32 678 3.5 Dynamic Payload Type AVP 680 0 1 2 3 681 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | AVP Code | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | AVP Length | Reserved |P|T|V|E|H|M| 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Payload Type . . . 688 +-+-+-+-+-+-+-+-+-+-+-+- 690 AVP Code 692 1305 Dynamic Payload Type 694 AVP Length 696 The length of this is variable. 698 AVP Flags 700 The flag field MUST have bit one (Mandatory Support) set. 701 The flag field MUST not have bit four (Vendor Specific AVP) set. 703 Payload Type 705 The Dynamic Payload Type is an optional attribute for all 706 connections that used the RTP endpoint type. The value of this 707 field takes on a value as defined in H.235. 709 The Dynamic Payload Type field is of type data. 711 3.6 Endpoint 1 IPDC-Resource 713 0 1 2 3 714 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | AVP Code | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | AVP Length | Reserved |P|T|V|E|H|M| 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Entity Type Code | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Endpoint 1 Entity name . . . 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 AVP Code 728 1306 Endpoint 1 IPDC-Resource 730 AVP Length 732 This is a variable length field. 734 AVP Flags 736 The flag field MUST have bit one (Mandatory Support) set. 737 The flag field MUST not have bit four (Vendor Specific AVP) set. 739 Entity Type Code 741 This field identifies the type of endpoint address specified in 742 the Endpoint 1 field of this AVP. The allowable values are: 744 ACCESS_TERMINATION 5 745 TRUNK_TERMINATION 6 746 DEVICE 8 747 MODEM 9 748 CONFERENCE_PORT 10 749 FAX_PORT 11 750 STREAM_SOURCE 12 751 STREAM_RECORDER 13 752 RTP_PORT 14 753 ATM_SPEC 15 754 H323_SPEC 16 755 SIP_SPEC 17 757 Endpoint 1 Entity Name 759 The Endpoint 1 IPDC-Resource AVP is used to identify the source 760 endpoint for a connection. The value of this field is of type 761 IPDC_Resource and the definition of this type may be found in the 762 IPDC base document. For each of the allowable Entity Code Types 763 for this AVP, the base document provides a description of how to 764 populate the entity name field. 766 This AVP is of data type data. 768 3.7 Endpoint 2 IPDC-Resource 770 0 1 2 3 771 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | AVP Code | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | AVP Length | Reserved |P|T|V|E|H|M| 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Entity Type Code | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Endpoint 2 Entity name . . . 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 AVP Code 784 1307 Endpoint 2 IPDC-Resource 786 AVP Length 788 The length of this attribute MUST be at least 12 to accommodate 8 789 bytes of AVP header information plus a minimum 4 byte data field. 790 The character coding of this attribute is likely to make this 791 field considerably longer than 12. 793 AVP Flags 795 The flag field MUST have bit one (Mandatory Support) set. 796 The flag field MUST not have bit four (Vendor Specific AVP) set. 798 Entity Type Code 800 in 6 This field identifies the type of endpoint address specified in 801 the Endpoint 2 field of this AVP. The allowable values are: 803 ACCESS_TERMINATION 5 804 TRUNK_TERMINATION 6 805 DEVICE 8 806 MODEM 9 807 CONFERENCE_PORT 10 808 FAX_PORT 11 809 STREAM_SOURCE 12 810 STREAM_RECORDER 13 811 RTP_PORT 14 812 ATM_SPEC 15 813 H323_SPEC 16 814 SIP_SPEC 17 816 Endpoint 2 IPDC-Resource 818 The Endpoint 2 IPDC-Resource AVP is used to identify the 819 Destination endpoint for a connection.. The value of this field is 820 of type IPDC_Resource and the definition of this type may be found 821 in the IPDC base document. For each of the allowable Entity Code 822 Types for this AVP, the base document provides a description of 823 how to populate the entity name field. 825 3.8 QOS AVP 827 0 1 2 3 828 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | AVP Code | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | AVP Length | Reserved |P|T|V|E|H|M| 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | QOS Type | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | QOS value | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 AVP Code 841 1308 QOS 843 AVP Length 845 The length of this attribute is variable, but it must be at least 846 12. 848 AVP Flags 850 The flag field MUST have bit one (Mandatory Support) set. 851 The flag field MUST not have bit four (Vendor Specific AVP) set. 853 QOS 855 The QOS AVP is used on packet based connections to specify the 856 Quality of Service type and value that should be used when 857 establishing the connection. This attribute may only be used when 858 the packet network supports the specified Quality of Service 859 Mechanism. 861 The AVP is made up of two fields. The first is a type indicator 862 which may have the following values: 864 0x00000001 MPLS 865 0x00000002 ToS bits 866 0x00000003 ATM 868 The second is QOS and specifies the Quality of Service value that 869 should be used when establishing the connection. This attribute 870 coupled with the QOS Type completes the definition of how the 871 media gateway should setup the connection. This attribute may only 872 be used when the packet network supports the specified Quality of 873 Service Mechanism. 874 The following QOS values may be specified with this attribute. 875 For MPLS 4 byte, network defined, MPLS tag 877 For ToS 1 byte (4 bits used, big-Endian) as defined in RFC 878 1349 880 0x00000008 Minimize delay 881 0x00000004 Maximize throughput 882 0x00000002 Maximize reliability 883 0x00000001 Minimize monetary cost 884 0x00000000 Normal service 886 For ATM 888 0x00000001 Constant bit rate 889 0x00000002 Real-Time variable bit rate 890 0x00000003 Non-Real-Time variable bit rate 891 0x00000004 Available bit rate 892 0x00000005 Unspecified bit rate 894 3.9 Radius - Called Phone Number 896 0 1 2 3 897 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | AVP Code | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | AVP Length | Reserved |P|T|V|E|H|M| 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Called Phone number . . . 904 +-+-+-+-+-+-+-+-+-+-+-+-+- 906 AVP Code 908 1309 Radius - Called Phone Number 910 AVP Length 912 The length of this attribute is variable. 914 AVP Flags 916 The flag field MUST have bit one (Mandatory Support) set. 918 The flag field MUST not have bit four (Vendor Specific AVP) set. 920 Called Phone Number 922 The Radius - Called Phone Number is used for data connections to 923 provide some of the information necessary to authenticate the 924 caller. This information may be used in a query to a RADUIS 925 server to provide additional information about the service being 926 accessed. It is important to note that this attribute is not 927 intended for use for anything other than passing the value to 928 Radius for user authentication. 930 The Radius - Called Phone Number field is of type String with a 931 minimum length of 1. 933 3.10 Radius - Calling Party Number AVP 935 0 1 2 3 936 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | AVP Code | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | AVP Length | Reserved |P|T|V|E|H|M| 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Calling Party Number . . . 943 +-+-+-+-+-+-+-+-+-+-+-+-+- 945 AVP Code 947 1301 Radius - Calling Party Number 949 AVP Length 951 The length of this attribute MUST be at least 9 to accommodate 8 952 bytes of AVP header and at least one digit for calling party 953 number 955 AVP Flags 957 The flag field MUST have bit one (Mandatory Support) set. 958 The flag field MUST not have bit four (Vendor Specific AVP) set. 960 Calling party Number 962 The Radius - Calling Party Number is used for data connections to 963 provide some of the information necessary to authenticate the 964 caller. This information may be used in a query to a RADUIS 965 server to provide additional verification of the calling party. 967 The Radius - Calling Party Number field is of type String and may 968 have a variable length including a zero length (not present). 970 3.11 Requested Priority AVP 972 0 1 2 3 973 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | AVP Code | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | AVP Length | Reserved |P|T|V|E|H|M| 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Requested Priority | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 AVP Code 984 1311 Request Priority 986 AVP Length 988 The length of this attribute MUST be at exactly 12 to accommodate 989 8 bytes of AVP header information plus a 4 byte indication of 990 whether this is a priority call. 992 AVP Flags 994 The flag field MUST have bit one (Mandatory Support) set. 995 The flag field MUST not have bit four (Vendor Specific AVP) set. 997 Requested Priority 999 The Requested Priority AVP is used to indicate to the media 1000 gateway that this is a priority. This requires that the media 1001 gateway allocate any necessary internal resources for the 1002 establishment of the connection even if it requires the teardown 1003 of an existing non-priority connection. This implies that the 1004 media gateway must know which of its current connections are 1005 priority connections and which connections are candidates for 1006 arbitrary selection as one that may be torn down. 1007 The Request Priority field is of type Interger32. 1009 3.12 Session Key AVP 1011 0 1 2 3 1012 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | AVP Code | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | AVP Length | Reserved |P|T|V|E|H|M| 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Session Key . . . 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 AVP Code 1023 1312 Session Key 1025 AVP Length 1027 The length of this attribute is variable. 1029 AVP Flags 1031 The flag field MUST have bit one (Mandatory Support) set. 1032 The flag field MUST not have bit four (Vendor Specific AVP) set. 1034 Session Key 1036 The Session Key is an optional attribute for all connections that 1037 use the RTP endpoint type. This field is used to specify 1038 encryption information and takes on a value as defined in H.235. 1040 The Session Key field is of type integer 32. 1042 3.13 Statistics Request AVP 1044 0 1 2 3 1045 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | AVP Code | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | AVP Length | Reserved |P|T|V|E|H|M| 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Statistics Group ID | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 o o o 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Statistics Group ID | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 AVP Code 1061 1313 Statistics Request 1063 AVP Length 1065 The length of this attribute MUST be at least 12 to accommodate 8 1066 bytes of AVP header information plus at minimum a single 1067 statistics group ID. 1069 AVP Flags 1071 The flag field MUST have bit one (Mandatory Support) set. 1072 The flag field MUST not have bit four (Vendor Specific AVP) set. 1074 Statistics Group ID 1076 The Statistics request AVP is used to request the collection and 1077 reporting of statistics for a call. The data field(s) of this AVP 1078 contain one or more group IDs that represent statistics groups 1079 that should be collected. Currently only one statistics group has 1080 been identified. This group collects statistics for RTP based 1081 connections. 1083 1 Packet statistics group ID 1085 Other values may be used for extensions to the protocol or vendor 1086 specific statistics groups. 1088 Statistics collected based upon this request are generated and 1089 sent to the media gateway controller at the end of the call for 1090 which they were collected. 1092 3.14 Statistics Report AVP 1094 0 1 2 3 1095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | AVP Code | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | AVP Length | Reserved |P|T|V|E|H|M| 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Statistics Group ID | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Number of audio packets received | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Number of audio packets dropped | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Number of audio packets sent and received | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Number of audio bytes sent and received | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Number of audio bytes received | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Number of audio bytes dropped | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Number of signaling packets sent and received | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Number of signaling packets received | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Number of signaling packets dropped | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Number of signaling bytes sent and received | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Number of signaling bytes received | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Number of signaling bytes dropped | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Estimated Average Latency | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 AVP Code 1132 1314 Statistics Report 1134 AVP Length 1136 The length of this attribute MUST be at least 16 to accommodate 8 1137 bytes of header, a group ID and at least one statistic. 1139 AVP Flags 1141 The flag field MUST have bit one (Mandatory Support) set. 1142 The flag field MUST not have bit four (Vendor Specific AVP) set. 1144 Connection Packet Statistics 1146 This AVP is used to report statistics about the a particular 1147 statistics group that was associated with a connection. The 1148 example AVP format shown above is the only statistics group 1149 currently defined. This group collects statistics about the RTP 1150 session associated with a connection. The packet statistics group 1151 contains 13 four byte values that hold the following information 1152 elements 1154 Number of audio packets sent and received:The total number of 1155 packets of audio data sent and received on the RTP connection 1156 Number of audio packets received: The number of packets of audio 1157 data that were received by the media gateway during on the RTP 1158 connection. 1160 Number of audio packets dropped: The number of packets of audio 1161 data that were lost during the RTP connection 1163 Number of audio bytes sent and received: The total number of bytes 1164 of audio data sent and received on the RTP connection 1166 Number of audio bytes received: The number of bytes of audio data 1167 received during on the RTP connection. 1169 Number of audio bytes dropped: The number of bytes of audio data 1170 that was lost during the RTP connection 1172 Number of signaling packets sent and received: The number of RTCP 1173 packets sent and received by an media gateway during and RTCP 1174 connection 1176 Number of signaling packets received: The number of RTCP packets 1177 received by the access server during a connection 1179 Number of signaling packets dropped The number of RTCP packets 1180 lost during an RTCP connection 1182 Number of signaling bytes sent and received: The number of RTCP 1183 bytes sent and received during an RTCP connection 1185 Number of signaling bytes received: The number of RTCP bytes 1186 received during by an media gateway during a connection 1188 Number of signaling bytes dropped: The number of RTCP bytes 1189 dropped during an RTCP connection 1191 Estimated average latency: Estimated latency between the two 1192 endpoints in an RTP connection. RFP 1889 for a description on how 1193 to measure estimated average latency. 1195 Inter-arrival jitter: Estimated measurement of the variation in 1196 packet latency between two endpoints in an RTP connection. See RFP 1197 1889 for a description on how to measure inter-arrival jitter. 1199 4.0 Protocol Definition 1201 This section describes how to establish any unusual or confusing 1202 connection types within the IPCC protocol. The only connection type 1203 currently described within this section is the loopback. Others may 1204 be described as they are identified as being difficult to understand. 1206 4.1 Loopback Connection 1208 The IPCC message set may be used to establish may types of 1209 connections, one such connection that may not be obvious from the 1210 message definitions above is the ability to establish a loopback 1211 connection. Two types of loopbacks may be established in the context 1212 of this protocol. 1214 The first type of loopback may be used to perform continuity testing 1215 on the GSTN network. This is the traditional loopback connection 1216 that would be used to perform a continuity test as required for SS7 1217 ISUP. This may be established by simply specifying the same GSTN 1218 reference channel value for both Endpoint 1 and Endpoint 2. The 1219 media gateway will establish a loopback connection on that channel. 1221 The second type of loopback exists within the IP network and may be 1222 used to verify connectivity or measure performance statistics. The 1223 mechanisms to perform these types of tests are outside the scope of 1224 the is protocol, but the ability to establish this type of connection 1225 is not. This type of connection may be established by taking an RTP 1226 connection and looping it back on itself. To do this, the following 1227 types of values may be specified for Endpoint 1 and Endpoint 2 for a 1228 connection. 1230 Endpoint 1 reference: /rtp-term/134.37.41.2:3056/- 1231 Endpoint 2 reference: /rtp-term/-/134.37.45.4/ 1233 In this example, the receive RTP port is specified for Endpoint 1 and 1234 the transmit port is specified for Endpoint 2. This in effect 1235 establishes a one-way connection that takes RTP packets in on 1236 endpoint 1 and transmits them out on endpoint 2. The address 1237 specification for the transmit side of Endpoint 2 should be set to 1238 the IP address and port of the far-end device that will be performing 1239 the loopback tests. 1241 5.0 Security Considerations 1243 Security issues are not discussed in this memo. The security 1244 mechanisms recommended are those specified in [3]. 1246 6.0 Rights and Permissions 1248 The contributors to this document are listed in the author's address 1249 and acknowledgement sections of the document. All contributors to 1250 this document and the organizations we represent grant an unlimited 1251 perpetual, non-exclusive, royalty-free, world-wide right and license 1252 to any party under the copyrights in the contribution. This license 1253 includes the right to copy, publish and distribute the contribution 1254 in any way, and to prepare derivative works that are based on or 1255 incorporate all or part of the contribution, the license to such 1256 derivative works to be of the same scope as the license of the 1257 original contribution. The contributors grant permission to reference 1258 the names and addresses of the contributors and of the organizations 1259 we represent. We agree that no information in the contribution is 1260 confidential and that the any party may freely disclose any 1261 information in the contribution. 1263 The contributors to this document represent that the organizations we 1264 represent jointly own any intellectual property associated with this 1265 document. The contributors to this document will grant any party a 1266 perpetual, non-exclusive, royalty-free, world-wide right to 1267 implement, use and distribute the technology or works when 1268 implementing, using or distributing technology based upon the 1269 specific specification. 1271 The contributors represent that we have disclosed the existence of 1272 any proprietary or intellectual property rights in the contribution 1273 that are reasonably and personally known to the contributors. The 1274 contributors do not represent that we personally know of all 1275 potentially pertinent proprietary and intellectual property rights 1276 owned or claimed by the organization he represents (if any) or third 1277 parties. 1279 The contributors represent that there are no limits to the 1280 contributors' ability to make the grants, acknowledgments and 1281 agreements above that are reasonably and personally known to the 1282 contributors. 1284 7.0 Acknowledgments 1286 The author wishes to acknowledge the following individuals for their 1287 contribution to the IP Call Control protocol: 1289 Ascend Communications Inc. Ilya Akramovich 1290 Selsius Systems Bob Bell 1291 Tekelec Dan Brendes 1292 3Com Corporation Peter Chung 1293 3Com Corporation Russ Dehlinger 1294 Level 3 Communications Isaac Elliott 1295 Cisco Systems, Inc. Cary Fitzgerald 1296 Cisco Systems, Inc. Jan Gronski 1297 Stratus Computer, Inc. Tom Hess 1298 Level 3 Communications Geoff Jordan 1299 Ascend Communications, Inc. Tony Lam 1300 Xcom Technologies Shawn Lewis 1301 Ascend Communications, Inc. Dave Mazik 1302 Vertical Networks Alan Mikhak 1303 Alcatel Telecom Pete O'Connell 1304 Vertical Networks Scott Pickett 1305 Ericsson Shyamal Prasad 1306 3Com Corporation Paul Richards 1307 Ascend Communications, Inc. Dale Skran 1308 Lucent Technologies Louise Spergel 1309 Lucent Technologies Raj Srinivasan 1310 Nortel Tom Taylor 1311 Nortel Michael Thomas 1313 8 References 1315 [1] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, draft- 1316 calhoun-diameter-03.txt, May 1998 1317 [2] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-Draft,draft- 1318 calhoun-diameter-framework-00.txt, May 1998 1319 [3] Taylor, "IP Device Control Base Protocol", 1320 [4] Elliott, "IP Media Control Protocol", 1321 [5] Skran, "IP Device Control Framework" 1322 [6] Pickett,Mikhak, "IP Device Management Protocol" 1323 [7] Bell, "IP Signaling Protocol" 1325 9 Author's Address 1326 Questions about this memo can be directed to: 1328 Andrew Dugan 1329 Level 3 Communications 1330 1450 Infinite Drive 1331 Louisville, CO 80027 1333 Phone: 1-303-926-3429 1334 Fax: 1-303-926-3406 1335 Email: andrew.dugan@L3.com