idnits 2.17.1 draft-foster-mgcp-basic-packages-10.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2769 has weird spacing: '...rmation r-c...' == 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: Caller-id: When requested as an event by the Call Agent, the event MUST not parameterized. However, parameters are included when the event is reported i.e.: == 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: Stutter Dial Tone (sl): Stutter Dial Tone MUST not parameterized when requested as an event. However, the "del" parameter is reported. -- 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 (February 2003) is 7733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2-3T' on line 679 -- Looks like a reference, but probably isn't: '2-3' on line 686 ** Obsolete normative reference: RFC 2327 (ref. '15') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '22') (Obsoleted by RFC 4733, RFC 4734) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. Foster 2 Internet Draft F. Andreasen 3 Document: Cisco Systems 4 Category: Informational February 2003 6 Basic MGCP Packages 8 Status of this Document 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute 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 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 IESG NOTE: 30 This document is being published for the information of the 31 community. It describes a non-IETF protocol that is currently being 32 deployed in a number of products. Implementers should be aware that 33 the IETF Megaco working group and the ITU-T Study Group 16 have 34 produced a standards track RFC "Megaco Protocol Version 1.0" (RFC 35 3015, also published as ITU recommendation H.248) which addresses the 36 same problem space and are developing extensions to that protocol for 37 functions of this type. 39 Abstract 41 This document provides a basic set of Media Gateway Control Protocol 42 (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, 43 announcement server and script packages are updates of packages from 44 RFC 2705 with additional explanation and in some cases new versions 45 of these packages. In addition to these, five new packages are 46 defined here. These are the signal list, resource reservation, media 47 format, supplementary services and digit map extension packages. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119. 55 Basic MGCP Packages February 2003 57 Table of Contents 59 1. Introduction......................................................3 60 1.1. List of Packages...............................................3 61 1.2. Changes to Existing RFC 2705 Packages..........................3 62 1.2.1. Change in signal types.....................................3 63 1.2.2. Operation Complete and Operation Failure...................3 64 1.2.3. Package Versions...........................................4 65 1.2.4. Event Definitions, Aliases and Interoperability Issues.....4 66 1.2.5. New Events.................................................4 67 1.3. New Packages and Excluded Packages.............................5 68 2. Packages..........................................................5 69 2.1. Generic Media Package.........................................7 70 2.2. DTMF package.................................................10 71 2.3. Trunk Package................................................15 72 2.4. Line Package.................................................22 73 2.5. Handset Emulation Package....................................30 74 2.6. Supplementary Services Tone Package..........................32 75 2.7. Digit Map Extension..........................................34 76 2.8. Signal List Package..........................................34 77 2.9. Media Format Parameter Package................................35 78 2.10. RTP Package..................................................39 79 2.11. Resource Reservation Package................................44 80 2.11.1. Description..............................................44 81 2.11.2. Parameter Encoding.......................................47 82 2.11.3 Events....................................................48 83 2.12. Announcement Server Package.................................50 84 2.13. Script Package..............................................51 85 3.0. IANA Considerations............................................53 86 4.0. Security Considerations........................................53 87 5.0. Acknowledgements...............................................54 88 6.0. Normative References...........................................54 89 7.0. Informative References.........................................55 90 8.0. Authors' Addresses.............................................55 91 9.0. Full Copyright Statement.......................................57 92 Basic MGCP Packages February 2003 94 1. Introduction 96 This document provides a basic set of Media Gateway Control Protocol 97 (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, 98 announcement server and script packages are updates of packages from 99 RFC 2705 with additional explanation and in some cases new versions 100 of these packages. In addition to these, five new packages are 101 defined here. These are the signal list, resource reservation, media 102 format, supplementary services and digit map extension packages. 104 1.1. List of Packages 106 The basic set of packages specified in this document is for use with 107 MGCP 1.0 as defined in [1]. Included are the following packages: 109 ------------------------------------------- 110 | Package | Name | 111 |-------------------------------------------| 112 | Generic Media Package | G | 113 | DTMF package | D | 114 | Trunk Package | T | 115 | Line Package | L | 116 | Handset Package | H | 117 | Supplementary Services Package | SST | 118 | Digit Map Extension | DM1 | 119 | Signal List Package | SL | 120 | Media Format Package | FM | 121 | RTP Package | R | 122 | Resource Reservation Package | RES | 123 | Announcement Server Package | A | 124 | Script Package | Script | 125 ------------------------------------------- 127 1.2. Changes to Existing RFC 2705 Packages 129 1.2.1. Change in signal types 131 MGCP 1.0 as defined in RFC 2705 (and now updated in [1]) provided 132 some additional clarification on the meaning of On-Off (OO) signals 133 compared to earlier versions of MGCP. This lead to some inconsistency 134 in some of the signal definitions in the accompanying packages in RFC 135 2705. This has been corrected in the packages that are included here 136 by changing some of the signals from type On-Off to type Time-Out 137 (TO). 139 1.2.2. Operation Complete and Operation Failure 141 Another change also made to improve consistency and interoperability 142 was to add the "operation complete" and "operation failure" events in 143 packages where there are TO signals defined but where the "operation 144 complete" and "operation failure" events were not previously included 145 as part of the package. By definition, all packages that contain 146 Time-Out type signals now contain the "operation failure" ("of") and 147 Basic MGCP Packages February 2003 149 "operation complete" ("oc") events as defined in [1], irrespective of 150 whether they are provided as part of the package description or not. 152 If a package without Time-Out signals does contain definitions for 153 the "oc" and "of" events, the event definitions provided in the 154 package may over-ride those indicated here. Such practice is however 155 discouraged and is purely allowed to avoid potential backwards 156 compatibility problems. 158 It is considered good practice to explicitly mention that the "oc" 159 and "of" events are supported in accordance with their default 160 definitions. If no definition is included in the package, the default 161 syntax and semantics is assumed. 163 Please refer to [1] for additional details on these events. 165 1.2.3. Package Versions 167 The generic, line, trunk, handset, RTP, DTMF, announcement server and 168 script packages included in this document are new versions of 169 packages that were previously contained in RFC 2705. The updated base 170 MGCP 1.0 specification [1] provides an optional capability of 171 auditing package versions. Any gateway that implements versioned 172 packages SHOULD also implement this option. 174 1.2.4. Event Definitions, Aliases and Interoperability Issues 176 Some event definitions or clarifications of previous event 177 definitions have also been added in order to improve 178 interoperability. 180 In some cases events have aliases either in the same or in other 181 packages and a recommendation has been made for the use of alternates 182 by Call Agents for future implementations. For maximum 183 interoperability, gateways MUST still implement these events (in fact 184 they MUST always implement all of the events, signals, etc. in a 185 package). 187 Some events that were previously defined require specific 188 provisioning in both the gateway and the Call Agent in order to allow 189 for interoperability. In those cases, a warning to that affect has 190 been included. 192 1.2.5. New Events 194 In some cases new events have been added to existing packages. Any 195 changes to existing packages of course have resulted in the package 196 version number being updated from unversioned (version 0) to version 197 1. 199 Basic MGCP Packages February 2003 201 1.3. New Packages and Excluded Packages 203 Two packages from RFC 2705 have not been included. These are the "MF" 204 and the "NAS" package. These packages are still valid as are all 205 unversioned (version 0) packages defined in RFC 2705. The reason 206 these packages were not included are: 208 * The original MF package had no defined way to outpulse MF digits 209 so that MF CAS is now provided by other packages (i.e. the "MS", 210 "MO" and "MD" packages) in a separate document. 211 * The "N" package as defined in RFC 2705 was incomplete. A new 212 MGCP "NAS" package has been developed and provided in a separate 213 document. 215 New packages have also been included beyond what was included in RFC 216 2705. These are the signal list, resource reservation, media format, 217 supplementary services and digit map extension packages. The Resource 218 Reservation ("RES") and Media Format ("FM") packages in particular 219 are different from other packages in this document in that they 220 contain new LocalConnectionOptions. This is allowed by the new 221 extension rules in [1]. Future packages of this type MUST use a 222 packages prefix in front of local connection options ("/") so as to avoid name-space problems. 224 However because of the timing of the arrival of these packages 225 relative to updating MGCP 1.0, this was not done for the "RES" and 226 "FM" packages. The resulting new local connection options will be 227 registered with IANA. For future cases where a package prefix is 228 included, only the package name needs to be registered. 230 2. Packages 232 For those packages that involve MGCP events, the terms "signal" and 233 "event" are used to differentiate a request from a Call Agent to a 234 Media Gateway to apply an event ("signal"), from requesting the 235 detection of an "event" that occurs on the Media Gateway and is 236 "Notified" to the Call Agent. 238 For packages that involve events and signals the tables contain five 239 columns: 241 Symbol: the (package) unique symbol used to identify the event. 243 Definition: a short description of the event. 245 R: an x appears in this column if the event can be requested by 246 the Call Agent. Alternatively, one or more of the following 247 symbols may appear. An "S" is included if the event-state may be 248 audited. A "C" indicates that the event can be detected on a 249 connection, and a "P" indicates the event is persistent. 251 S: if nothing appears in this column for an event, then the event 252 cannot be signaled by the Call Agent. Otherwise, the following 253 symbols identify the type of event: 255 Basic MGCP Packages February 2003 257 * OO On/Off signal 259 * TO Time-Out signal. 261 * BR Brief signal. 263 In addition, a "C" will be included if the signal can be 264 generated on a connection. 266 Duration: specifies the default duration of TO signals. If a 267 duration is left unspecified then the default timeout will be 268 assumed to be infinite unless explicitly noted in the description 269 of the signal. A duration may also be declared as being variable 270 in a case where signals involve complex sequencing (e.g. scripts 271 or digit out-pulsing) where the amount of time may vary with 272 either processing time or the signaling environment. 274 Default time-out values may be over-ridden by the Call Agent for any 275 Time-Out event defined in this document (with the exception of those 276 that have a default value of "variable") by a "to" signal parameter 277 which specifies the timeout value in milliseconds (see [1]). Example: 279 S: sst/cw(to=20000) 281 indicates a timeout value of 20 seconds. 283 As indicated in [1]: by default, a supplied time-out value MAY be 284 rounded to the nearest non-zero value divisible by 1000, i.e. whole 285 second. However, individual signal definitions within a package may 286 define other rounding rules. 288 Note that Time-Out signals that involve other parameters still allow 289 the use of the "to" signal parameter e.g.: 291 S: T/sit(1,to=3000) 293 The order of the "to" parameter relative to the other parameters is 294 not important. 296 Note: as per [1], On-Off (OO) signals are parameterized with "+" 297 (meaning turn on) or "-" (meaning turn off). If the parameter is 298 missing, the default is to turn on the signal. Unlike Time-Out 299 signals, On-Off signals do not stop when an event occurs. 301 Other than the "to" parameter for Time-out (TO) signals and the "+" 302 and "-" for On-Off (OO) signals, signals and events in the packages 303 in this document do not have parameters unless explicitly indicated 304 in the description of the event for that package. 306 In some of the signal definitions below, specific tone definitions 307 are provided even though actual frequencies may vary from country to 308 country. 310 Basic MGCP Packages February 2003 312 2.1. Generic Media Package 314 Package Name: G 315 Version: 1 317 The generic media package groups the events and signals that can be 318 observed on several types of endpoints, such as trunk gateway 319 endpoints, access gateway endpoints or residential gateway endpoints. 321 --------------------------------------------------------------- 322 | Symbol | Definition | R | S Duration | 323 |---------------------------------------------------------------| 324 | cf | Confirm Tone | | BR | 325 | cg | Congestion Tone | | TO infinite | 326 | ft | Fax Tone | x | | 327 | it | Intercept Tone | | TO infinite | 328 | ld | Long Duration Connection | C | | 329 | mt | Modem Tone | x | | 330 | oc | Operation Complete | x | | 331 | of | Operation Failure | x | | 332 | pat(###) | Pattern Detected | x | OO | 333 | pt | Preemption Tone | | TO infinite | 334 | rbk(...) | Ringback | | TO,C 180 seconds| 335 | rt | Ringback Tone | | TO,C 180 seconds| 336 --------------------------------------------------------------- 338 New events added to this package from the previously unversioned 339 package: "oc" 341 Changes: "it" and "pt" signals changed from OO to TO. 343 Note that default time-out values may be over-ridden by the Call 344 Agent for any Time-Out signal defined in this package by a "to" 345 signal parameter. Refer to section 2 of this document as well as [1] 346 for details. 348 The events and signals are defined as follows: 350 Confirmation Tone (cf): 351 This is also referred to as "positive indication tone" in ITU-T 352 E.182. In North America, Confirmation Tone uses the same 353 frequencies and levels as dial tone (350 and 440 Hertz) but with a 354 cadence of 0.1 second on, 0.1 second off repeated three times. See 355 GR-506-CORE [7] Section 17.2.4. It is considered an error to try 356 and play confirmation tone on a phone that is on hook and an error 357 MUST consequently be returned when such attempts are made (error 358 code 402 - phone on hook). 360 Congestion Tone (cg): 361 Refer to ITU-T E.180 [8] and E.182 [10]. This maps to re-order 362 tone in North America (refer to GR-506-CORE [7] Section 17.2.7). 364 Basic MGCP Packages February 2003 366 Fax Tone (ft): 367 The fax tone event is generated whenever a fax call is detected by 368 the presence of V.21 fax preamble. The fax tone event SHOULD also 369 be generated when the T.30 CNG tone is detected. See ITU-T 370 Recommendations T.30 and V.21. 372 Intercept Tone(it): 373 This is a country specific tone as defined in ITU-T, E.180 374 Supplement 2 [9]. 376 Long Duration Connection (ld): 377 The "long duration connection" is detected when a connection has 378 been established for more than some time. The default value is 1 379 hour, however the provisioning process may change this. 381 This event is detected on a connection. When no connection is 382 specified as part of the request, the event applies to all 383 connections for the endpoint, regardless of when the connections 384 are created. The "all connections" wildcard (see [1]) may also be 385 used for this case, and is in fact preferred for consistency. In 386 either case, the name of the connection on which the event was 387 detected will be included when the event is observed, e.g.: 389 G/ld@0A3F58 391 Modem Tone (mt): 392 Indicates V.25 Answer tone (ANS) with or without phase reversals 393 or V.8 Modified Answer Tone (ANSam) tone with or without phase 394 reversals. Note that this implies the presence of a data call. 395 Also note that despite the name of the event, devices other than 396 modems may generate such tones, e.g. a fax machine. 398 Operation Complete (oc): 399 The standard definition of operation complete [1]. 401 Operation Failure (of): 402 The standard definition of operation failure [1]. 404 Pattern Detected (pat(###)): 405 This event requires special provisioning that needs to be agreed 406 on between the Call Agent and media gateway in order to ensure 407 interoperability. It is retained in order to maintain backwards 408 compatibility with version 0 of the "G" package. This event MUST 409 be parameterized with a decimal numeric value from 0 to 999 410 specifying the pattern to detect. When reported, the pattern is 411 also included as a parameter. 413 Preemption Tone (pt): 414 This is a country specific tone and is defined in ITU-T, E.180 415 Supplement 2. 417 Basic MGCP Packages February 2003 419 Ringback (rbk(connectionID)): 420 This is an alias for "rt@connectionID" and is included here for 421 backwards compatibility only. It is recommended that Call Agents 422 use "rt@connectionID" instead of "rbk(connectionID)" for ring-back 423 over a connection for new implementations. Although the ringback 424 signal is applied on a connection, the "rbk" signal does not 425 support the "@connection" syntax. When the signal is requested, it 426 MUST be parameterized with a connection-ID or a connection-ID 427 wildcard as specified in [1]. 429 Ringback Tone (rt): 430 Refer to ITU-T E.180 and ITU-T E.182. Also referred to as ringing 431 tone - a tone advising the caller that a connection has been made 432 and that a calling signal is being applied to the called party or 433 service point. In North America this tone is a combination of two 434 AC tones with frequencies of 440 and 480 Hertz and levels of -19 435 dBm each, to give a combined level of -16 dBm. The cadence for 436 Audible Ring Tone is 2 seconds on followed by 4 seconds off. See 437 GR-506-CORE - LSSGR: SIGNALING, Section 17.2.5. 439 This signal can be applied directly to an endpoint or 440 alternatively on a connection using the syntax "rt@connectionID". 441 When the ringback signal is applied to an endpoint, it is 442 considered an error to try and play ring back tones, if the 443 endpoint is considered on hook and an error MUST consequently be 444 returned when such attempts are made (error code 402 - phone on 445 hook). When the ringback signal is applied to a connection, no 446 such check is to be made. 448 Note that as specified in [1], signals requested on a connection 449 MUST be played regardless of the connection mode. For example, in 450 a call-waiting situation, ringback tone may be played on a 451 connection in "inactive" mode. 453 Basic MGCP Packages February 2003 455 2.2. DTMF package 457 Package name: D 458 Version: 1 460 -------------------------------------------------------------- 461 | Symbol | Definition | R | S Duration | 462 |--------------------------------------------------------------| 463 | 0 | DTMF 0 | x | BR | 464 | 1 | DTMF 1 | x | BR | 465 | 2 | DTMF 2 | x | BR | 466 | 3 | DTMF 3 | x | BR | 467 | 4 | DTMF 4 | x | BR | 468 | 5 | DTMF 5 | x | BR | 469 | 6 | DTMF 6 | x | BR | 470 | 7 | DTMF 7 | x | BR | 471 | 8 | DTMF 8 | x | BR | 472 | 9 | DTMF 9 | x | BR | 473 | # | DTMF # | x | BR | 474 | * | DTMF * | x | BR | 475 | A | DTMF A | x | BR | 476 | B | DTMF B | x | BR | 477 | C | DTMF C | x | BR | 478 | D | DTMF D | x | BR | 479 | DD(..) | DTMF Tone Duration | x | TO 3 seconds | 480 | DO(..) | DTMF OO Signal | | OO | 481 | L | Long Duration Indicator | x | | 482 | oc | Operation Complete | x | | 483 | of | Operation Failure | x | | 484 | T | Interdigit Timer | x | TO 16 seconds | 485 | X | DTMF Tones Wildcard, | x | | 486 | | match any digit 0-9 | | | 487 -------------------------------------------------------------- 489 Changes from the previous version of the package: events "dd", "do", 490 "oc" were added. 492 Note that DTMF tones including the DTMF tones wildcard can use the 493 eventRange notation defined in [1] when requesting events, e.g. 494 "D/[0-9](N)". 496 Note that default time-out values may be over-ridden by the Call 497 Agent for any Time-Out signal defined in this package by a "to" 498 signal parameter. Refer to section 2 of this document as well as [1] 499 for details. 501 The events are defined as follows: 503 DTMF tones (0-9,#,*,A,B,C,D): 504 Detection and generation of DTMF tones is described in GR-506-CORE 505 - LSSGR: SIGNALING, Section 15. Note that it is considered an 506 error to try and play DTMF tones on a phone that is on hook and an 507 error MUST consequently be returned when such attempts are made 508 (error code 402 - phone on hook). The event codes can be specified 509 Basic MGCP Packages February 2003 511 in a digit map. When requested as a signal, as per GR-506-CORE, 512 section 15, a minimum tone duration of 50 ms will be followed by a 513 minimum interdigit silence period of 45 ms, i.e. if requested in a 514 signal list such as "S: sl/s(d/5,d/6,d/7)", then interdigit timing 515 requirements will be satisfied. 517 Note that some types of endpoints such as announcement endpoints 518 MAY allow detection and/or generation of DTMF tone over a 519 connection. However, this requires consistent provisioning between 520 the Call Agent and announcement server (it is not required in 521 order to be compliant with the DTMF package). 523 DTMF Tone Duration (dd(dg=,to=