RFC 3660
Basic Media Gateway Control Protocol (MGCP) Packages
(part 1 of 13 💖)
RFC 3660: Basic Media Gateway Control Protocol (MGCP) Packages 🎀
- Written by: B. Foster and F. Andreasen, both from Cisco Systems
- Stream: Network Working Group
- Category: Informational
- Date: December 2003
- Updates: RFC 2705 (the title block doesn't list anything it obsoletes)
Status of This Memo
Okay so this memo is just giving information to the Internet community 💅 It is not a standard of any kind, and distribution is unlimited ✨
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
IESG Note
This document is being published for the information of the community 🌸 It describes a non-IETF protocol that's already being deployed in a bunch of products. Implementers should be aware of RFC 3525 [37] 🫶 That one was developed in the IETF Megaco Working Group and the ITU-T SG16, and the IETF and ITU-T both consider it the standards-based way to meet the needs MGCP was designed for. It includes reviewed security considerations too, which is so important 😭 The IETF Megaco Working Group and ITU-T Study Group 16 are also working on extensions to RFC 3525 [37] for the kinds of functions addressed in this document. Main character energy from RFC 3525 👑
Abstract
This document gives you a basic set of Media Gateway Control Protocol (MGCP) packages 🦋 The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705, with extra explanation and, in some cases, new versions of those packages. On top of that, five brand new packages are defined here: the signal list, resource reservation, media format, supplementary services and digit map extension packages 🧚
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. List of Packages . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes to Existing RFC 2705 Packages. . . . . . . . . . 3
1.2.1. Change in Signal Types . . . . . . . . . . . . . 3
1.2.2. Operation Complete and Operation Failure . . . . 3
1.2.3. Package Versions . . . . . . . . . . . . . . . . 4
1.2.4. Event Definitions, Aliases and Interoperability
Issues . . . . . . . . . . . . . . . . . . . . . 4
1.2.5. New Events . . . . . . . . . . . . . . . . . . . 5
1.3. New Packages and Excluded Packages . . . . . . . . . . . 5
2. Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Generic Media Package. . . . . . . . . . . . . . . . . . 7
2.2. DTMF Package . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Trunk Package. . . . . . . . . . . . . . . . . . . . . . 16
2.4. Line Package . . . . . . . . . . . . . . . . . . . . . . 24
2.5. Handset Emulation Package. . . . . . . . . . . . . . . . 33
2.6. Supplementary Services Tone Package. . . . . . . . . . . 36
2.7. Digit Map Extension. . . . . . . . . . . . . . . . . . . 37
2.8. Signal List Package. . . . . . . . . . . . . . . . . . . 38
2.9. Media Format Parameter Package . . . . . . . . . . . . . 39
2.10. RTP Package. . . . . . . . . . . . . . . . . . . . . . . 43
2.11. Resource Reservation Package . . . . . . . . . . . . . . 48
2.11.1. Description. . . . . . . . . . . . . . . . . . . 48
2.11.2. Parameter Encoding . . . . . . . . . . . . . . . 52
2.11.3. Events . . . . . . . . . . . . . . . . . . . . . 53
2.12. Announcement Server Package. . . . . . . . . . . . . . . 55
2.13. Script Package . . . . . . . . . . . . . . . . . . . . . 56
3. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 59
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 59
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1. Normative References . . . . . . . . . . . . . . . . . . 60
6.2. Informative References . . . . . . . . . . . . . . . . . 62
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 641. Introduction 🌈
This document gives you a basic set of Media Gateway Control Protocol (MGCP) packages ✨ The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages are updates of packages from RFC 2705 [38], with extra explanation and in some cases new versions of these packages. Plus, five new packages are defined here: the signal list, resource reservation, media format, supplementary services and digit map extension packages 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [31] 📖
1.1. List of Packages
The basic set of packages in this document is for use with MGCP 1.0 as defined in [1] 🍓 These are the packages included:
-------------------------------------------
| Package | Name |
|-------------------------------------------|
| Generic Media Package | G |
| DTMF package | D |
| Trunk Package | T |
| Line Package | L |
| Handset Package | H |
| Supplementary Services Package | SST |
| Digit Map Extension | DM1 |
| Signal List Package | SL |
| Media Format Package | FM |
| RTP Package | R |
| Resource Reservation Package | RES |
| Announcement Server Package | A |
| Script Package | Script |
-------------------------------------------1.2. Changes to Existing RFC 2705 Packages 🦋
1.2.1. Change in signal types
MGCP 1.0, as defined in RFC 2705 [38] (and now updated in [1]), gave some extra clarification on what On-Off (OO) signals mean, compared to earlier versions of MGCP. That led to a bit of inconsistency in some of the signal definitions in the accompanying packages in RFC 2705 [38] 🙈 This has been fixed in the packages included here, by changing some of the signals from type On-Off to type Time-Out (TO).
1.2.2. Operation Complete and Operation Failure
Another change, made to improve consistency and interoperability, was adding the "operation complete" and "operation failure" events to packages that have TO signals defined, but where those two events weren't previously part of the package. By definition, every package that contains Time-Out type signals now contains the "operation failure" ("of") and "operation complete" ("oc") events as defined in [1], whether or not they're included in the package description 🫶
If a package without Time-Out signals contains definitions for the "oc" and "of" events, the event definitions provided in that package may over-ride those indicated here. Such practice is, however, discouraged, and it is purely allowed to avoid potential backwards compatibility problems 💅
It is considered good practice to explicitly mention that the "oc" and "of" events are supported in accordance with their default definitions. If no definition is included in the package, the default syntax and semantics are assumed ✨
Please refer to [1] for additional details on these events.
1.2.3. Package Versions
The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages included in this document are new versions of packages that were previously in RFC 2705 [38] 🎀 The updated base MGCP 1.0 specification [1] provides an optional capability of auditing package versions. Any gateway that implements versioned packages SHOULD also implement this option.
1.2.4. Event Definitions, Aliases and Interoperability Issues
Some event definitions, or clarifications of previous event definitions, have also been added to improve interoperability 🧚
In some cases, events have aliases either in the same package or in other packages, and a recommendation has been made for Call Agents to use alternates for future implementations. For maximum interoperability, gateways MUST still implement these events (in fact, they MUST always implement all of the events, signals, etc. in a package) 🔥
Some events that were previously defined require specific provisioning in both the gateway and the Call Agent in order to allow for interoperability. In those cases, a warning to that effect has been included ⭐
1.2.5. New Events
In some cases, new events have been added to existing packages. Any changes to existing packages have of course resulted in the package version number being updated from unversioned (version 0) to version 1 💜
1.3. New Packages and Excluded Packages 🙈
Two packages from RFC 2705 [38] have not been included: the "MF" and the "NAS" packages 😭 These packages are still valid, as are all unversioned (version 0) packages defined in RFC 2705 [38]. The reasons these packages weren't included are:
- The original MF package had no defined way to outpulse MF digits, so MF CAS is now provided by other packages (i.e., the "MS", "MO" and "MD" packages) in a separate document.
- The "N" package, as defined in RFC 2705 [38], was incomplete. A new MGCP "NAS" package has been developed and is provided in a separate document.
New packages have also been included beyond what was in RFC 2705 [38]: the signal list, resource reservation, media format, supplementary services and digit map extension packages. The Resource Reservation ("RES") and Media Format ("FM") packages in particular are different from the other packages in this document, because they contain new LocalConnectionOptions. This is allowed by the new extension rules in [1] 👑 Future packages of this type MUST use a packages prefix in front of local connection options (<package-name>/<Local Connection Option>) so as to avoid name-space problems. However, because of the timing of these packages' arrival relative to the update of MGCP 1.0, this was not done for the "RES" and "FM" packages. The resulting new local connection options have been registered with IANA. For future cases where a package prefix is included, only the package name needs to be registered 🦋
2. Packages ✨
okay bestie, so this is where the packages get their vibe 💅. For packages with MGCP events, the RFC splits two words that sound alike but mean very different things. A signal 📣 is when the Call Agent tells a Media Gateway to apply something. An event 👀 is when the Media Gateway detects something happening on its end and gets "Notified" to the Call Agent. signal goes out, event comes back, periodt 🦋
For packages with events and signals, the tables have five columns:
- Symbol: the package-unique symbol that identifies the event.
- Definition: a short description of the event.
- R: an
xshows up here if the Call Agent can request the event. Or you might see one or more of these instead: anSif the event-state may be audited, aCif the event can be detected on a connection, and aPif the event is persistent. - S: if this column is empty for an event, the Call Agent can't signal it. Otherwise, the symbol tells you the type of signal:
OOOn/Off signalTOTime-Out signal.BRBrief signal.
On top of that, a C shows up here if the signal can be generated on a connection 🎀
- Duration: the default duration of TO signals. If no duration is given, the default timeout is infinite, unless the event description says otherwise. A duration can also be marked as variable 🌀 when the signal involves complex sequencing (like scripts or digit out-pulsing) and the time depends on processing time or the signaling environment.
Default time-out values can be overridden by the Call Agent for any Time-Out event defined in this document (except the ones with a default of "variable") using a "to" signal parameter, which sets the timeout in milliseconds (see [1]). This example asks for a 20 second timeout:
S: sst/cw(to=20000)As [1] explains, a supplied time-out value MAY be rounded by default to the nearest non-zero value divisible by 1000, which means a whole second. Individual signal definitions in a package can set different rounding rules, though 🤓
Time-Out signals that take other parameters can still use the "to" parameter, like this:
S: T/sit(1,to=3000)The order of the "to" parameter compared to the others doesn't matter 🙌
Note: as [1] says, On-Off (OO) signals take a "+" (turn on) or "-" (turn off) parameter. If the parameter is missing, the signal turns on by default. Unlike Time-Out signals, On-Off signals do not stop when an event occurs 🔥
Besides the "to" parameter for Time-Out (TO) signals and the "+" and "-" for On-Off (OO) signals, the signals and events in this document's packages don't take parameters, unless the event description says so for that package 💜
Some tone definitions below give specific tones, even though the real frequencies can change from country to country 🌍
2.1. Generic Media Package 🎀
Package Name: G Version: 1
The generic media package groups events and signals that can be seen on several kinds of endpoints, like trunk gateway endpoints, access gateway endpoints, or residential gateway endpoints 🏠
---------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
| cf | Confirm Tone | | BR |
| cg | Congestion Tone | | TO infinite |
| ft | Fax Tone | x | |
| it | Intercept Tone | | TO infinite |
| ld | Long Duration Connection | C | |
| mt | Modem Tone | x | |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| pat(###) | Pattern Detected | x | OO |
| pt | Preemption Tone | | TO infinite |
| rbk(...) | Ringback | | TO,C 180 seconds|
| rt | Ringback Tone | | TO,C 180 seconds|
---------------------------------------------------------------New events were added to this package from the previously unversioned package: "oc" 🌸
Changes: "it" and "pt" signals went from OO to TO ⭐
Default time-out values can still be overridden by the Call Agent for any Time-Out signal in this package, using a "to" signal parameter. Check section 2 of this document, and [1], for the details 📖
Here are the events and signals, one by one 👑
Confirmation Tone (cf): This is also called "positive indication tone" in ITU-T E.182. In North America, Confirmation Tone uses the same frequencies and levels as dial tone (350 and 440 Hertz), but with a cadence of 0.1 second on, 0.1 second off, repeated three times. See GR-506-CORE [7] Section 17.2.4. Trying to play confirmation tone on a phone that's on-hook is an error 🚫 so an error MUST be returned when someone tries it (error code 402 - phone on-hook).
Congestion Tone (cg): Check out ITU-T E.180 [8] and E.182 [10]. This maps to re-order tone in North America (see GR-506-CORE [7] Section 17.2.7) 🔊
Fax Tone (ft): The fax tone event is generated whenever a fax call is detected by the presence of V.21 fax preamble. The fax tone event SHOULD also be generated when the T.30 CNG tone is detected. See ITU-T Recommendations T.30 [21] and V.21 [22] 📠
Intercept Tone (it): This is a country-specific tone, defined in ITU-T E.180 Supplement 2 [9] 🌏
Long Duration Connection (ld): The "long duration connection" is detected when a connection has been up for longer than a provisioned amount of time. The default value is 1 hour ⏰
This event is detected on a connection. If the request doesn't name a connection, the event applies to all connections for the endpoint, no matter when they were created. The "all connections" wildcard (see [1]) can also be used here, and it's actually the preferred option for consistency 💖 Either way, the name of the connection where the event was detected gets included when the event is observed, like this:
G/ld@0A3F58Modem Tone (mt): This is V.25 Answer tone (ANS), with or without phase reversals, or V.8 Modified Answer Tone (ANSam), with or without phase reversals. It means there's a data call happening 💻 Also, even though it's called modem tone, other devices can make these tones too, like a fax machine 📠
Operation Complete (oc): This is the standard definition of operation complete [1] ✅
Operation Failure (of): This is the standard definition of operation failure [1] ❌
Pattern Detected (pat(###)): This event needs special provisioning agreed on between the Call Agent and the media gateway so that they stay interoperable 🤝 It's kept around to stay backwards compatible with version 0 of the "G" package. This event MUST be parameterized with a decimal numeric value from 0 to 999 that specifies the pattern to detect. When it's reported, the pattern is also included as a parameter 🧩
Preemption Tone (pt): This is a country-specific tone, defined in ITU-T E.180 Supplement 2 [9] 🌍
Ringback (rbk(connectionID)): This is an alias for "rt@connectionID", and it's only here for backwards compatibility 🕰️ It is recommended that Call Agents use "rt@connectionID" instead of "rbk(connectionID)" for ring-back over a connection in new implementations. Even though the ringback signal is applied on a connection, the "rbk" signal doesn't support the "@connection" syntax. When the signal is requested, it MUST be parameterized with a connection-ID or a connection-ID wildcard, as specified in [1] 📞
Ringback Tone (rt): Check out ITU-T E.180 [8] and ITU-T E.182 [10]. It's also called ringing tone, and it tells the caller that a connection has been made and that a calling signal is being applied to the called party or service point 🔔 In North America, this tone is two AC tones mixed together, at 440 and 480 Hertz, each at -19 dBm, for a combined level of -16 dBm.
The cadence for Audible Ring Tone is 2 seconds on, then 4 seconds off. See GR-506-CORE [7] - LSSGR: SIGNALING, Section 17.2.5 🎶
This signal can be applied straight to an endpoint, or on a connection using the syntax "rt@connectionID". When the ringback signal goes to an endpoint, it's an error to play ringback tone if the endpoint is considered on-hook, so an error MUST be returned when someone tries it (error code 402 - phone on-hook). When the ringback signal goes to a connection, that check isn't made 🙅♀️
Note that, as [1] specifies, signals requested on a connection MUST be played regardless of the connection mode. For example, during a call-waiting situation, ringback tone may be played on a connection in "inactive" mode 📵✨
2.2. DTMF package 💅
Package name: D 🎹 Version: 1
--------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|--------------------------------------------------------------|
| 0 | DTMF 0 | x | BR |
| 1 | DTMF 1 | x | BR |
| 2 | DTMF 2 | x | BR |
| 3 | DTMF 3 | x | BR |
| 4 | DTMF 4 | x | BR |
| 5 | DTMF 5 | x | BR |
| 6 | DTMF 6 | x | BR |
| 7 | DTMF 7 | x | BR |
| 8 | DTMF 8 | x | BR |
| 9 | DTMF 9 | x | BR |
| # | DTMF # | x | BR |
| * | DTMF * | x | BR |
| A | DTMF A | x | BR |
| B | DTMF B | x | BR |
| C | DTMF C | x | BR |
| D | DTMF D | x | BR |
| DD(..) | DTMF Tone Duration | x | TO 3 seconds |
| DO(..) | DTMF OO Signal | | OO |
| L | Long Duration Indicator | x | |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| T | Interdigit Timer | x | TO 16 seconds |
| X | DTMF Tones Wildcard, | x | |
| | match any digit 0-9 | | |
--------------------------------------------------------------Changes from the previous version of the package: events "dd", "do", "oc" were added. 🌸
Okay so, DTMF tones including the DTMF tones wildcard can use the eventRange notation from [1] when you request events, e.g., D/[0-9](N). Slay, right? ✨
Also, default time-out values can be over-ridden by the Call Agent for any Time-Out signal in this package by using a "to" signal parameter. Check section 2 of this document, plus [1], for the details. 🦋
The events work like this:
DTMF tones (0-9,#,*,A,B,C,D)
Detection and generation of DTMF tones is described in GR-506-CORE [7] - LSSGR: SIGNALING, Section 15. Bestie, listen up: trying to play DTMF tones on a phone that's on-hook is an error, and an error MUST be returned when someone tries it (error code 402 - phone on-hook). 💀 The event codes can be specified in a digit map. When requested as a signal, as per GR-506-CORE [7], section 15, a minimum tone duration of 50 ms is followed by a minimum interdigit silence period of 45 ms. So if you request a signal list like S: sl/s(d/5,d/6,d/7), the interdigit timing requirements get satisfied. 🎀
Note that some types of endpoints, such as announcement endpoints, MAY allow detection and/or generation of a DTMF tone over a connection. However, this needs consistent provisioning between the Call Agent and the announcement server. It's not required in order to be compliant with the DTMF package, so no stress! 🫶
DTMF Tone Duration (dd(dg=<tone>,to=<time>,su=<TrueOrFalse>))
This event tells you if or when the specified <tone> lasts longer than the <time> value you gave, and it gets reported once that duration is exceeded. ⏱️ The parameters can come in any order. The value of <tone> can be any DTMF tone symbol (without the package name) from the DTMF package, including X for events but not signals. If this parameter is absent, any DTMF tone that happens gets reported. 👀
The parameter <time> is in milliseconds and the gateway may round it to the nearest 10 ms. The minimum <time> you can request for an event is 40 ms. For a signal, the minimum is 50 ms. For either an event or a signal, the maximum <time> is 60000 ms. If you request it as an event without "to=<time>", the event reports the full duration of the tone (up to 60000 ms) once the tone finishes. 🙈
When it's reported as an ObservedEvent, both parameters are always supplied. Here, <tone> is the actual tone detected, and <time> is either:
- The <time> specified in the request (possibly rounded), or
- If the request did not contain a
"to=<time>"parameter, the full duration of the tone.
The parameter "su" MAY be included when this is requested as an event, but it's not reported. It tells you whether the requested DTMF digits should be suppressed in-band when requested. The possible values are "true", which means in-band DTMF should be suppressed, and "false", which means DTMF should keep passing in-band. If it's missing, the default is "false". The "su" parameter MUST NOT be included when requesting "D/dd" as a signal. 🚫
When used as a signal, dd lets you generate a DTMF tone as a TO signal. Here, an extra 50 ms of silence gets tacked onto the end before the operation complete happens. For example, S: dd(dg=5,to=2500) plays the DTMF tone for the number "5" for 2.5 seconds, then 50 ms of silence. The operation complete (if requested) gets notified after that silence interval. Any value from 50 ms to 60000 ms can be requested, and gateways that generate or detect the tone may round the time to the nearest 10 ms. 💖
The dd event can stand in for the "long duration" event to detect a digit pressed for longer than 2 seconds. For example, to check if a user holds the long "#" for more than 2 seconds, you can make a request with the RequestedEvents line R: d/dd(N)(dg=#,to=2000). The resulting ObservedEvents line would be O: d/dd(dg=#,to=2000). 🧚
Now, suppose the RequestedEvents line instead contains:
R: d/[0-9*#],d/ddSuppose the user then pushes "#" for 2.5 seconds. In this case, two events get notified:
O: d/#when the "#" key is first pressed, and
O: d/dd(dg=#,to=2500)when the "#" key is finally released. 😭
DTMF OO Signal (do(dg=<tone>,<on-or-off>))
This signal generates a DTMF tone as an on-off signal. The <tone> parameter is any of the symbols for a specific tone in the DTMF package (that's "0" to "9", "A", "B", "C", "D", "*", or "#"). The <on-or-off> indicator is "+" for on and "-" for off, as per [1]. The <tone> parameter MUST be supplied. If it's not, a return code of 538 - "Event/signal parameter error" comes back in the response. 🚨 If the <on-or-off> parameter is missing, the default is to turn the signal on as usual (so "+" is the default). The order of the parameters doesn't matter, since "+" and "-" are reserved characters and are easy to tell apart from the <tone> parameter. 🌈
Long Duration Indicator (l)
The "long duration indicator" is observed when a DTMF signal is produced for longer than two seconds. In this case, the gateway detects two successive events. First, when the signal is recognized, you get the DTMF signal. Then, 2 seconds later, you get the long duration signal. ⭐
Operation Complete (oc)
This is the standard definition of operation complete [1]. 👑
Operation Failure (of)
This is the standard definition of operation failure [1]. 🥀
Timer (t)
Timer T can be used as an event or as a time-out (TO) signal. As a signal, its only behaviour is the normal characteristics of a "TO" signal as defined in [1]. In other words, if no event happens before the time-out, an operation complete event gets generated. 🍓
As an event, Timer T is a digit input timer that you can use in two ways:
- When timer T is used with the accumulate according to digit map action, the timer doesn't start until the first DTMF tone is entered. It restarts after each new DTMF tone is entered, until either a digit map match or mismatch happens. In this case, timer T works as an inter-digit timer, as shown here:
R: D/[0-9T](D)- When timer T is used without the "accumulate according to digit map" action, the timer starts immediately and gets simply cancelled (but not restarted) as soon as a DTMF tone is entered. In this case, timer T can be an inter-digit timer when overlap sending is used, as in:
R: D/[0-9](N), D/T(N)When used with the "accumulate according to digit map" action, timer T takes on one of two values: T-partial or T-critical. When at least one more symbol is needed for the "current dial string" to match any one of the patterns in the digit map, timer T takes on the value T-partial, which corresponds to partial dial timing. If a timer is all that's required to produce a match, timer T takes on the value T-critical, which corresponds to critical dial timing. When timer T is used without the "accumulate according to digit map" action, timer T takes on the value T-critical. The default value for T-partial is 16 seconds, and the default value for T-critical is 4 seconds. The provisioning process may alter both of these. If timer T isn't used, then inter-digit timing won't be performed. 🧁
Here's how that plays out. Consider the digit map:
(xxxxxxx|x11T)and assume DTMF and timer T are accumulated according to the digit map. At the first DTMF input, say "4", timer T starts with a value of T-partial, since at least one more symbol is required. If "1" is then input, it restarts timer T with a value of T-partial again. If "1" is now input again, the current dial string is "411", and a timer is all that's required to produce a match. So timer T is now restarted with the value T-critical. 📞
Finally, consider these subtle examples (all assuming DTMF and timer T are being accumulated according to the digit map). The digit map:
(1[2-3T].)will match immediately on the input "1", since zero or more matches of the range are specified. 🤯
The digit map:
(1[2-3].T)and an input of "1" will lead to timer T being set to T-critical. 🎯
A digit map of:
(1[2-3T].)Wait, correction from the original: the second subtle example in the source is (1[2-3].T), and the third is (1[2-3]T.). Here they are, correctly:
(1[2-3]T.)and an input of "1" will lead to timer T being set to T-partial. Furthermore, on a subsequent input of "2" or "3", a perfect match gets triggered immediately, since timer T is completely irrelevant at that point. ✨
DTMF Tones Wildcard (X)
The DTMF tones wildcard matches any DTMF digit between 0 and 9. The actual event code generated will be the event code for the digit detected. The DTMF tones wildcard is often used to detect DTMF input that gets matched against a digit map. 🦋
2.3. Trunk Package 🌷
Package Name: T Version: 1
Okay so here's the whole trunk package lineup at a glance 🎀✨
----------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|----------------------------------------------------------------|
| as | Answer Supervision | x | BR |
| bl | Blocking | | BR |
| bz | Busy | | TO 30 sec. |
| co1 | Continuity Tone (go tone, | x | TO 3 sec. |
| | or return tone) | | |
| co2 | Continuity Test (go tone, | x | TO 3 sec. |
| | or return tone in dual tone | | |
| | procedures) | | |
| ct(...) | Continuity Transponder | | OO |
| lb | Loopback | | OO |
| nm | New Milliwatt Tone | x | TO 3 sec |
| mm | Newest Milliwatt Tone | x | TO 3 sec |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| om | Old Milliwatt Tone | x | TO 3 sec |
| pst | Permanent Signal Tone | | TO infinite |
| qt | Quiet Termination | | TO infinite |
| ro | Reorder Tone | x | TO 30 sec. |
| sit(#) | Special Information Tone | x | TO 2 sec. |
| | | | (see notes) |
| tl | Test Line | x | TO infinite |
| tp(###) | Test Pattern | x | TO 3 sec |
| zz | No Circuit | x | TO 2 sec |
----------------------------------------------------------------New events added to this package from the previously unversioned package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp". 🌸
Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals changed from OO to TO; "as" and "bl" changed from OO to BR. 🦋
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details. 💜
The definition of the trunk package events are as follows:
Answer Supervision (as): This event is used to indicate the occurrence answer supervision. In most cases, it is a result of a steady off-hook in response to a call request. This event is included for backwards compatibility with the previous version of the package. The preferred alternative is to use the "answer" event in the appropriate CAS packages [34] (Note: check the details on the use of "answer" in the particular CAS package; in most cases "answer" as an event is an indication of a steady off-hook regardless of whether or not it is an indication of answer supervision). For details on when answer supervision is appropriate refer to [5]. 💅
Blocking (bl): This event is used to indicate an incoming off-hook for the purposes of blocking a one-way trunk in CAS trunks. This event is included for backwards compatibility with the previous version of the package. The preferred alternative is the "block" event in the appropriate CAS packages [34]. 🙈
Busy Tone (bz): Refer to ITU-T E.180 [8]. In North America, station Busy is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for Station Busy Tone is 0.5 seconds on, followed by 0.5 seconds off, then repeating. See GR-506-CORE [7]- LSSGR: SIGNALING, Section 17.2.6. 📞
Continuity Tone (co1): A tone at 2010 Hz (see section 3.1.1.3 of [2]). When generated as a signal, the frequency of the tone must be within + or - 8 Hz, while the frequency of the tone corresponding to the event must be within + or - 30 Hz. 🎶
Continuity Test (co2): A tone at 1780 Hz (see section 3.1.1.3 of [2]). When generated as a signal, the frequency of the tone must be within + or - 20 Hz, while the frequency of the tone corresponding to the event must be within + or - 30 Hz.
In continuity testing the tone corresponding to the signal at the originating gateway is referred to as the "go" tone, and the tone corresponding to the event at that same gateway is referred to as the "return" or "check" tone. 🔥
Note that generation and notification of continuity tones are done as per continuity test requirements as defined in ITU-T Q.724 [3], as well as by Bellcore GR-317-CORE [2] specifications, i.e., the semantics of notification of the return tone is more than that the tone was received, but is an indication that the test has passed. Details are provided in the following paragraphs. 👑
The continuity tones represented by co1 and co2 are used when the Call Agent wants to initiate a continuity test. There are two types of tests, single tone and dual tone; In the case of the dual tone, either tone can be sent and the opposite received depending on the trunk interconnections (4-wire or 2-wire) as indicated below:
Originating Terminating
============ ===========
4w -------------- 1780 Hz -----------> 2w
<------------- 2010 Hz ------------ (transponder)
2w -------------- 2010 Hz -----------> 2w/4w
<------------- 1780 Hz ------------ (transponder)
4w -------------- 2010 Hz -----------> 4w
<------------- 2010 Hz ------------ (loopback)The Call agent is expected to know, through provisioning information, which test should be applied to a given endpoint. As an example, for a 4-wire to 2-wire connection, the Call Agent might send a request like the following to an originating gateway:
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
S: t/co1
R: t/co2,t/oc,t/ofOn a terminating side of a trunk, the call agent may request a continuity test connection (connection mode "conttest") to the terminating gateway as follows:
CRCX 3001 ds/ds1-2/4@tgw34.example.net
C: 3748ABC364
M: conttestAlternatively, rather than using a connection mode, the "T/ct" signal can be used (see description of this signal further below):
RQNT 3001 ds/ds1-2/4@tgw34.example.net
X: 1233472
S: t/ct(in=co1,out=co2,+)The originating gateway would send the requested "go" tone, and would look for the appropriate "return tone". Once the return tone is received, the originating gateway removes the go tone and checks to see that the return tone has been removed within the specified performance limits (i.e., GR-246-CORE, T1.113.4, Annex B [23]). When it detects that the test is successful, the gateway will send a notification of the return tone event (Note that notification of the return tone event therefore must not be sent prior to detection of the removal of the return tone). ✨
The "T/co1" and "T/co2" signals are TO signals so that an operation complete event will occur when the signal times out. If a timeout value other than the default is desired, the "to" parameter may be used (e.g., "S: T/co1(to=2000)"). ⏰
If the gateway detects the failure of the continuity test prior to the timeout, an operation failure event will be generated. Otherwise, the failure of the continuity test is determined by the failure to receive the return tone event before the timeout occurs (operation complete event). As with TO signals in general, operation complete and operation fail events are parameterized with the name of the signal. 🧚
In the example above where the go tone is "co1" and the return tone is "co2":
- A notification of the "co2" event indicates success (i.e.,
O: t/co2). - A notification of the operation failure event indicates failure prior to timeout (i.e.,
O: t/of(t/co1)). - A notification of the operation complete event indicates that the return tone was not received properly prior to the occurrence of the timeout (i.e.,
O: t/oc(t/co2)).
On a terminating end of a trunk, either a "loopback" connection (single tone test) or "conttest" connection (dual tone test) is made (or alternatively the "T/lb" or "T/ct" signals are requested). It is up to the termination end to make sure that the return tone is removed as soon as the go tone disappears. The Call Agent requests the removal of "contest" or "loopback" connections (or "T/lb" or "T/ct" signals) at a termination end when the results of the continuity test are obtained. 🦋
When "conttest" is used, the endpoint is provisioned as to which transponder test is being performed (2010 Hz received and 1780 Hz sent or vice versa). In the case of the corresponding "T/ct" signal, the Call Agent can specify which tone is received and sent as parameters. 🌈
Note that continuity tones in the trunk package are only ever sent to the telephony endpoint. For network-based continuity, there are continuity tones available in the RTP ("R") package. Although a transponder (dual tone) test can be done, a single tone test is generally sufficient in the case of continuity testing across an IP network. 💜
Continuity Transponder (ct(in=<tone-in>,out=<tone-out>, <+ or ->)): This signal is used to provide transponder functionality independent of the connection mode, i.e., this is an alternative way to provide the same functionality as the "conttest" connection mode. The parameters can be provided in any order. The <tone-in> and <tone-out> parameters can have values "co1" or "co2", corresponding to the 2010 Hz and 1780 Hz tones associated with those symbols. If one of the tones is "co1", then the other must be "co2" and vice versa (i.e., <tone-in> and <tone-out> must have different values; if loopback is required, then the "lb" signal in this package or "loopback" connection mode should be used). 🍓
On detecting <tone-in>, <tone-out> will be generated in return. The tone corresponding to <tone-out> will continue to be generated until either:
- The signal is explicitly turned off (e.g., "S: t/ct(-)") or
- Removal of the
<tone-in>tone is detected.
Note that while the signal is active (regardless of whether a tone is active or not), media from the endpoint will not be forwarded to or from the packet network (i.e., the continuity transponder signal must be explicitly turned off by the Call Agent in order to resume passing media between the packet network and the endpoint). 🙈
Loopback (lb): This signal is used to provide loopback functionality independent of the connection mode, i.e., this is an alternative way to provide the same functionality as "loopback" connection mode. 🔁
Okay so, the loop-back thing is lowkey the most important part here 🫶 Note that while the loop-back signal is active (whether or not a tone is playing), media from the endpoint will NOT be forwarded to or from the packet network 🙅♀️ The Call Agent has to explicitly turn the loopback signal off to get media flowing between the packet network and the endpoint again. Main character energy for the Call Agent, honestly 👑
New Milliwatt Tone (nm): 🌈 1004 Hz tone. Refer to [4] and section 8.2.5 of [5].
Newest Milliwatt Tone (mm): 🦋 1013.8 Hz. Refer to [4].
Operation Complete (oc): ✨ This is the standard definition of operation complete [1].
Operation Failure (of): 💀 This is the standard definition of operation failure [1].
Old Milliwatt Tone (om): 🍓 1000 Hz tone. Refer to [4] and section 8.2.5 of [5].
Permanent Signal Tone (pst): 🌸 In North America, this tone is applied to a busy line verify/operator interrupt under specific circumstances, as described in [17].
Quiet Termination (qt): 🤫 Quiet Termination is used in a 102 trunk test. Reference section 6.20.5 [5] as well as [4].
Reorder Tone (ro): 🔁 This maps to congestion tone in the ITU-T E.182 specification. In North America, reorder tone is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for reorder tone is 0.25 seconds on, followed by 0.25 seconds off, repeating continuously (until time-out). See GR-506-CORE [7], Section 17.2.7.
Special Information Tone (sit(#)): 🎀 As described in ITU-T E.180 [8], the special information tone consists of a tone period in which 3 tones are produced, followed by a silent period of 1 second (total TO period of approximately 2 seconds). When used as a signal, it MUST be parameterized with a parameter value from 1 to 7, with the following meaning as defined in SR-2275, section 6.21.2 of [5]:
-------------------------------------------
| sit(1) | RO' | reorder SIT, intra-LATA |
| sit(2) | RO" | reorder SIT, inter-LATA |
| sit(3) | NC' | no circuit SIT, intra-LATA |
| sit(4) | NC" | no circuit SIT, inter-LATA |
| sit(5) | IC | intercept SIT |
| sit(6) | VC | vacant code SIT |
| sit(7) | IO | ineffective other SIT |
-------------------------------------------When requested as an event, the event MUST be parameterized with a decimal number from 1 to 7 to indicate which tone the gateway is required to detect. The resulting notification also includes the parameter. Other countries may have one or more special information tones with country-specific definitions (refer to ITU-T E.180 supp. 2 [9]). In this case, special information tone 1 as defined in [9] is sit(1), special information tone 2 is sit(2), and so on. 🌍
As an example, the Call Agent might make a request such as:
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
R: t/sit(N)(2)If the tone is detected, the resulting notification might appear as follows:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: AB123FE0
O: t/sit(2)Test Line (tl): 🧪 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0). Refer to section 8.2.5 of [5].
Test Pattern (tp(###)): 🌟 The tp(###) signal inserts the pattern ### continuously into the channel until the timeout period expires. The parameter is provided as a decimal number from 0 to 255. If the parameter is omitted, the default value is decimal 95.
In RequestedEvents, the parameter MAY be supplied to indicate what pattern the Call Agent wishes the gateway to detect. If the parameter is omitted, the value 95 is assumed. The pattern MUST be returned in the ObservedEvent (even if the parameter was not requested).
A typical use for the test pattern signal is the test line 108 (digital loopback) test (refer to section 8.2.5 of [5]). At the termination side of a trunk, the Call Agent would request a connection in "loopback" mode, which would do a digital loopback. On the origination side of the trunk, the Call Agent would request that the test pattern be injected into the digital channel, and would check to see that the pattern was returned within the timeout period. As an example, the Call Agent would make the following request on the origination side:
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
S: t/tp
R: t/tp, t/oc, t/ofIn this case, the Call Agent will either receive:
- An ObservedEvent indicating that the test has passed (i.e.,
O:t/op(95)), or - An ObservedEvent indicating that the timeout occurred before the pattern was received (i.e.,
O:t/oc(t/tp)), indicating that the test failed. Of course, an operation failure would indicate failure as well.
No Circuit (zz): 🙈 This is an alias for Special Information Tone 2, i.e., sit(2).
2.4. Line Package 📞
Package Name: L Version: 1
----------------------------------------------------------------
|Symbol | Definition | R | S Duration |
|----------------------------------------------------------------|
|adsi(string) | ADSI Display | | BR |
|aw | Answer Tone | x | OO |
|bz | Busy Tone | | TO 30 sec. |
|ci(ti,nu,na) | Caller-id | | BR |
|dl | Dial Tone | | TO 16 sec. |
|e | Error Tone | x | TO 2 sec. |
|hd | Off-hook Transition | S | |
|hf | Flash-hook | x | |
|ht | On Hold Tone | | OO |
|hu | On-hook Transition | S | |
|lsa | Line Side Answer Sup. | | OO |
|mwi | Message Waiting ind. | | TO 16 sec. |
|nbz | Network busy | x | TO infinite |
|oc | Operation Complete | x | |
|of | Operation Failure | x | |
|osi | Network Disconnect | | TO 900 ms |
|ot | Off-hook Warning Tone | | TO infinite |
|p | Prompt Tone | x | BR |
|rg | Ringing | | TO 180 sec. |
|r0, r1, r2, | Distinctive Ringing | | TO 180 sec. |
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|ro | Reorder Tone | | TO 30 sec. |
|rs | Ringsplash | | BR |
|s(###) | Distinctive Tone Pattern | x | BR |
|sit(#) | Special Information Tone | | TO 2 sec. |
| | | | (see notes) |
|sl | Stutter Dial Tone | | TO 16 sec. |
|v | Alerting Tone | | OO |
|vmwi | Visual Message | | OO |
| | Waiting Indicator | | |
|wt | Call Waiting Tone | | TO 12 sec |
|wt1, wt2, | Alternative Call | | TO 12 sec |
|wt3, wt4 | Waiting Tones | | (see notes) |
|y | Recorder Warning Tone | | TO infinite |
|z | Calling Card Service Tone| | BR |
----------------------------------------------------------------New events added to this package from the previously unversioned package: ht, osi, and lsa. ✨
Changes in event types: signals y and z changed from OO to TO and BR respectively. Ringing tones were extended to allow for a ring repetition signal parameter. 🔄
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a to signal parameter. Refer to section 2 of this document, as well as [1] for details. ⏰
The description of events and signals in the line package is as follows:
ADSI Display (adsi): 📟 This signal is included here to maintain compatibility with the previous version of this package. The signal is not well-defined, and its use is discouraged. 🙃
Answer Tone (aw): 📣 This event is included here to maintain compatibility with the previous version of this package. The event is not well-defined, and its use is discouraged.
Busy Tone (bz): 📵 Refer to ITU-T E.180 [8]. In North America, station Busy is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for Station Busy Tone is 0.5 seconds on, followed by 0.5 seconds off, repeating. See GR-506-CORE [7], Section 17.2.6. It is considered an error to try and play busy tone on a phone that is on-hook, and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook). 🚫
Caller-id (ci(time, number, name)): 🪪 See GR-1188 [24], GR-30-CORE [14], and GR-31 [25]. For backwards compatibility, each of the three fields is optional, but each of the commas will always be included. In accordance with the general MGCP grammar, it is RECOMMENDED to always include all three fields. An empty quoted string can then be used in lieu of omitting a parameter:
The time parameter is coded as "MM/DD/HH/MM", where MM is a two-digit decimal value for a Month between 01 and 12, DD is a two-digit value for a Day between 01 and 31, and Hour and Minute are two-digit values coded according to military local time, e.g., 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m. (Note: two digits MUST always be provided for each of the values of month, day, hour, minutes, e.g., the month of January is indicated by the two digits "01" rather than just "1".) 🗓️
The number parameter is coded as an ASCII character string of decimal digits that identify the calling line number. White spaces are permitted if the string is quoted, but they will be ignored. If a quoted-string is provided, the string itself is UTF-8 encoded (RFC 2279) as usual for signal parameters.
The name parameter is coded as a string of ASCII characters that identify the calling line name. White spaces are permitted if the string is quoted. If a quoted-string is provided, the string itself is UTF-8 encoded (RFC 2279).
A "P" in the number or name field is used to indicate a private number or name, and an "O" is used to indicate an unavailable number or name. Other letters MAY be used to provide additional clarification as per provider or vendor specifications. 🔐
The following example illustrates the use of the caller-id signal:
S: l/ci(09/14/17/26, "555 1212", "John Doe")An example indicating that the name and number are private:
S: l/ci(09/14/17/26,P,P)Dial Tone (dl) 📞: Check out ITU-T E.180 [8] for the deets. In North America, dial tone is two continuous AC tones at 350 and 440 Hertz, each at -13dBm, which adds up to a combined -10 dBm 💅. See GR-506-CORE [7] - LSSGR: SIGNALING, Section 17.2.1. Trying to play dial tone on a phone that's on-hook is an error, so an error MUST be returned when that happens (error code 402 - phone on-hook) 🚫.
Error Tone (e) 🫥: This one sticks around for backwards compatibility. It's not well defined, so using it is discouraged.
Off-hook Transition (hd) 📲: See GR-506-CORE [7], Section 12. Asking for off-hook on a phone that's already off-hook is an error, so an error MUST be returned (error code 401 - phone off-hook) ✨.
Flash Hook (hf) ⚡: See GR-506-CORE [7], Section 12. Asking for flash hook on a phone that's on-hook is an error, so an error MUST be returned (error code 402 - phone on-hook) 🙅♀️.
Tone On Hold (ht) 🎶: This tone reassures a calling subscriber who's been placed on "hold" 🫶. Refer to ITU-T E.182 [10].
On-hook Transition (hu) 🌙: See GR-506-CORE [7], Section 12. The timing for the on-hook signal is for flash response enabled, unless it's provisioned otherwise ⏱️. Asking for flash hook on a phone that's on-hook is an error, so an error MUST be returned (error code 402 - phone on-hook) 💀.
Line Side Answer Supervision (lsa) 🔌: This gives you Reverse Loop Current Feed (RLCF) on the line (refer to GR-506-CORE [7]). It's how you tell that the called party has answered, for some line-side equipment 👑.
Message Waiting Indicator (mwi) 💌: The message waiting tone uses the same frequencies and levels as dial tone (350 and 440 Hertz at -13dBm each), but with a cadence of 0.1 second on, 0.1 second off, repeated 10 times, followed by steady dial tone 🎀. See GR-506-CORE [7], Section 17.2.3. Playing message-waiting indicator on an on-hook phone is an error, so an error MUST be returned (error code 402 - phone on-hook) 🙈.
Network Busy (nbz) 🚧: This is only here to keep compatibility with the previous version of this package 🧚. The "nbz" signal is an alias for re-order tone signal("ro"). Future Call Agent implementations that need a network busy signal should use the "ro" signal 🍓. It is also recommended that future Call Agents not request to be notified of the "nbz" event (a network busy event is generally not required in a line package; hence, "ro" is only a signal, not an event) 🤓.
Operation Complete (oc) ✅: This is the standard definition of operation complete [1] 💖.
Operation Failure (of) ❌: This is the standard definition of operation failure [1] 🥀.
Network Disconnect (osi) 👋: Network Disconnect means the far-end party has disconnected 📴. The signal that goes out on the line is provisioned in the media gateway, since it can vary from country to country 🌍. In North America, this signal is an open switch interval, which results in a Loop Current Feed Open Signal (LCFO) being applied to the line (refer to GR-506-CORE [7], see also See GR-505-CORE [6], Section 4.5.2.1) ⭐. The default time-out value for this signal is 900 ms ⏳.
Off-hook Warning Tone (ot) 😖: Also known as receiver Off-Hook Tone (ROH Tone), this is the irritating noise a phone makes when it isn't hung up properly 📢. In North America, ROH Tone is made by combining four tones at 1400 Hertz, 2060 Hertz, 2450 Hertz and 2600 Hertz, with a cadence of 0.1 second on, 0.1 second off, then repeating 🔁. GR-506-CORE [7], Section 17.2.8 has the details on required power levels 🔥. Playing off-hook warning tone on an on-hook phone is an error, so an error MUST be returned (error code 402 - phone on-hook) 😭.
Prompt Tone (p) 💬: The definition of the prompt tone and how it's used can be found in requirement GR-220 [20]. The tone in GR-220 (requirement "R3-170" or GR-220) is a 300 ms burst of a 400 Hz tone 🌸.
Ringing (rg) 🔔: See GR-506-CORE [7], Section 14. The provisioning process may define the ringing cadence 🎵. The ringing signal can be parameterized with the signal parameter "rep", which specifies the maximum number of ringing cycles (repetitions) to apply. The value for "rep" is written in decimal and can be anything from 1 to 255 🔢. The following applies the ringing signal for up to 6 ringing cycles:
S: l/rg(rep=6)If the "rep" parameter is specified, the signal times-out when the number of repetitions is completed (i.e., an operation complete event can be requested and will occur at the end of the timeout/number of rings) ✨.
If the "rep" parameter is supplied, then any timeout ("to") value that's included will be ignored, i.e.:
S: l/rg(rep=6,to=12000)This will be treated the same as the previous example, where the parameter "to=12000" wasn't included 🙃. Of course, if the "to" parameter is included without the "rep", it will be acted upon, i.e.:
S: l/rg(to=12000)This will ring for 12 seconds ⏰.
Trying to ring a phone that's off-hook is an error, so an error MUST be returned (error code 401 - phone off-hook) 🚫.
Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7) 🎀: See GR-506-CORE [7], Section 14. The default values for r1 to r5 are the ones defined for distinctive ringing pattern 1 to 5 in GR-506-CORE [7] 🎶. The default values for r0, r6 and r7 are normal ringing (i.e., the same cadence "rg") 🔔. The provisioning process may define the ringing cadence for each of these signals. The distinctive ringing signals can be parameterized with the signal parameter "rep", which specifies the maximum number of ringing cycles (repetitions) to apply. The value for "rep" is written in decimal and can be anything from 1 to 255 💅.
The following applies the ringing signal for up to 6 ringing cycles:
S: l/r1(rep=6)If the "rep" parameter is specified, the signal times-out when the number of repetitions is completed (i.e., an operation complete event can be requested and will occur at the end of the timeout/number of rings) 🌈.
If the "rep" parameter is supplied, then any timeout ("to") value that's included will be ignored, i.e.:
S: l/r1(rep=6,to=12000)This will be treated the same as the previous example, where the parameter "to=12000" wasn't included 🫶. Of course, if the "to" parameter is included without the "rep", it will be acted upon, i.e.:
S: l/r1(to=12000)This will ring for 12 seconds ⏲️.
Trying to ring a phone that's off-hook is an error, so an error MUST be returned (error code 401 - phone off-hook) 📵.
Reorder Tone (ro) 🔁: This maps to congestion tone in the ITU-T E.182 [10] specification 🌀. In North America, reorder tone is two AC tones at 480 and 620 Hertz, each at -24 dBm, which combine to -21 dBm 🧡. The cadence for reorder tone is 0.25 seconds on, followed by 0.25 seconds off, repeating continuously 🎢.
Ringsplash (rs) 💥: Also known as "Reminder ring", this is a burst of ringing that can be applied to the physical forwarding line (when idle). It tells the user that a call has been forwarded and reminds them that a Call Forward sub-feature is active 📣. In the US, it's defined as a 0.5(-0,+0.1) second burst of power ringing (see [11]) 🫧.
Distinctive Tone Pattern (s(###)) 🎹: This is used to signal or detect a tone pattern defined by the parameter, where the parameter can have a value from 0 to 999 🔮. When specified as an event, the parameter MUST be included. The parameter will also be included when the event is reported 🧾. This event (the definition of tones tied to each parameter value) needs special provisioning in the Call Agent and gateway to insure interoperability 🛠️. This signal is included here to maintain compatibility with the previous version of this package 🕰️.
Special Information Tone(sit(#)) 🚨: As described in ITU-T E.180 [8], the special information tone is a tone period in which 3 tones are produced, followed by a silent period of 1 second (total TO period of approximately 2 seconds) 🎵. It MAY be parameterized with a parameter value from 1 to 7, with the following meanings as defined in SR-2275, section 6.21.2 [5] 📚:
-------------------------------------------
| sit(1) | RO' | reorder SIT, intra-LATA |
| sit(2) | RO" | reorder SIT, inter-LATA |
| sit(3) | NC' | no circuit SIT, intra-LATA |
| sit(4) | NC" | no circuit SIT, inter-LATA |
| sit(5) | IC | intercept SIT |
| sit(6) | VC | vacant code SIT |
| sit(7) | IO | ineffective other SIT |
-------------------------------------------If the parameter is left out, the NC' SIT tone that corresponds to the signal "L/sit(3)" is assumed 🫠.
Other countries may have one or more special information tones with country-specific definitions (refer to ITU-T E.180 supp. 2 [9]) 🌏. In this case, special information tone 1 as defined in [9] is sit(1), special information tone 2 is sit(2), and so on 🔢.
Stutter Dial Tone (sl) 🫨: Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE [7] and "special dial tone" in ITU-T E.182 [10]) is used to confirm some action and request additional input from the user ✅. An example is canceling call-waiting before entering a destination address 📱.
The stutter dial tone signal may be parameterized with the signal parameter "del", which specifies a delay in milliseconds to apply between the confirmation tone and the dial tone ⏸️. The parameter can have any value from 0 to 10000 ms, rounded to the nearest non-zero value divisible by 100 (i.e., tenth of a second) 🧮. The following applies stutter dial tone with a delay of 1.5 seconds between the confirmation tone and the dial tone:
S: l/sl(del=1500)Playing stutter dial tone on an on-hook phone is an error, so an error MUST be returned (error code 402 - phone on-hook) 🙅♀️.
Alerting Tone (v) 🛎️: This is a 440 Hz tone lasting 2 seconds, followed by 1/2 second of tone every 10 seconds 🎈. It's included for backwards compatibility with the previous version of the package 💜.
Visual Message Waiting Indicator (vmwi): okay this one's giving "patience, bestie" 💅 The VMWI messages have to follow the requirements in [13] and the CPE guidelines in [12], and you can also peek at section 6.6 of GR-30-CORE [14] 🎀 The gateway only sends VMWI messages to the attached equipment when the line is idle 📞 If new messages show up while the line is busy, the VMWI indicator message just waits until the line goes back to idle 🫶 After the gateway restarts, the signal state is "off", so the Call Agent MUST refresh the CPE's visual indicator if it's supposed to be "on" 🔥
Alternative Call Waiting Tones (wt, wt1, .., wt4): refer to ITU-T E.180 [8] 📣 For North American tone definitions, check GR-506-CORE [7], Section 14.2. "wt" and "wt1" are both aliases for the default Call Waiting tone. In North America that's a 440-Hz tone played for 300 plus or minus 50 ms, then repeated once after 10 seconds 🔁
These are timeout signals with a default timeout of 12 seconds, which lets the tone play twice from a single request (see GR-571-CORE [16]). Sometimes only one tone is wanted, though (Requirement R3-73 of GR-575-CORE [18]). In that case the Call Agent can send a shorter timeout to skip the second tone ✂️ For example, S: wt(to=2000) stops the signal after 2 seconds, so the second tone never happens.
Signals wt2, wt3 and wt4 are alternates for distinctive call-waiting tone patterns (see GR-506-CORE, Section 14.2 [7]). Trying to apply the call-waiting tone to a phone that's on-hook is an error, so an error MUST be returned when that happens (error code 402 - phone on-hook) 🙅♀️
Recorder Warning Tone(y): refer to ITU-T E.180 [8], and also Bellcore document SR-2275 [5], section 6.20 🎙️ When recording equipment is in use, this tone is connected to the line so the other party knows the conversation is being recorded. The typical value is a 1400 Hz tone lasting 0.5 second, repeated every 15 seconds.
Calling Card Service Tone(z): this one tells the customer that their credit card info needs to be keyed in 💳 It's usually 60 ms of 941 + 1477 Hz (the DTMF #digit), followed by 940 ms of 350 + 440 Hz (dial tone), decaying exponentially with a time constant of 200 ms. See Bellcore document SR-2275 [5], section 6.20.
2.5. Handset Emulation Package ✨
Package Name: H Version: 1
----------------------------------------------------------------
|Symbol | Definition | R | S Duration |
|----------------------------------------------------------------|
|adsi(string) | ADSI Display | x | BR |
|aw | Answer Tone | x | OO |
|bz | Busy Tone | x | TO 30 sec. |
|ci(ti,nu,na) | Caller-id | x | BR |
|dl | Dial Tone | x | TO 16 sec. |
|e | Error Tone | x | TO 2 sec. |
|hd | Off-hook Transition | S | BR |
|hu | On-hook Transition | S | BR |
|hf | Flash Hook | x | BR |
|ht | Tone On Hold | x | OO |
|lsa | Line Side Answer Sup. | x | OO |
|mwi | Message Waiting Ind. | x | TO 16 sec. |
|nbz | Network Busy | x | TO infinite |
|oc | Operation Complete | x | |
|ot | Off-hook Warning Tone | x | TO infinite |
|of | Operation Failure | x | |
|osi | Network Disconnect | x | TO 900 ms |
|p | Prompt Tone | x | BR |
|rg | Ringing | x | TO 180 sec. |
|r0, r1, r2, | Distinctive Ringing | x | TO 180 sec. |
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|ro | Reorder Tone | x | TO 30 sec. |
|rs | Ringsplash | x | BR |
|s(###) | Distinctive Tone Pattern | x | BR |
|sit(#) | Sit Tone | x | TO 2 sec. |
|sl | Stutter Dial Tone | x | TO 16 sec. |
|v | Alerting Tone | x | OO |
|vmwi | Vis. Message Waiting Ind.| x | OO |
|wt | Call Waiting tone | x | TO 12 sec. |
|wt1, wt2, | Alternative Call | x | TO 12 sec |
|wt3, wt4 | Waiting Tones | | (see notes) |
|y | Recorder Warning Tone | x | TO infinite |
|z | Calling Card Serv. Tone | x | BR |
----------------------------------------------------------------The handset emulation package is basically the line package's big sister 💜 The difference is that events like "off-hook" can be signaled as well as detected 📲
The changes from the original package are the same ones made for the line package, plus the "hu" and "hd" signal types moved from OO to BR 🔄
Event definitions match the line package, with these exceptions:
ASDI: when the Call Agent asks for this as an event, it isn't parameterized. The parameter does get included when the event is reported 🧚
Caller-id: when requested as an event, the event MUST not be parameterized. Parameters are included when it's reported, like this:
O: l/ci(09/14/17/26,"555 1212","John Doe")Line Side Answer Supervision: when requested as an event, this tells you when the reverse loop current feed (RLCF) was turned on and off ⚡ It isn't parameterized when requested, but a parameter is included in the report:
O: l/lsa(+) to indicate RLCF was turned on
O: l/lsa(-) to indicate RLCF was turned offRinging (rg): when requested as an event, the Call Agent may optionally include the rep parameter, which asks for a report after some number of rings 🔔 For example:
RQNT 1234 aaln/1@rgw2.example.net
X: AB123FE0
R: h/rg(N)(rep=3)The resulting notification after that many rings is detected includes the parameter again:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: AB123FE0
O: h/rg(rep=3)If the parameter wasn't in the request, it isn't in the report either. In that case the event is reported as soon as ringing is detected 🫶
Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7): same deal as "rg". If the "rep" parameter is included when one of these is requested as an event, it gets reported too. If it wasn't requested with the parameter, the parameter isn't in the report either. In that case the event is reported as soon as ringing with the requested cadence is detected 🎶
Stutter Dial Tone (sl): Stutter Dial Tone MUST not be parameterized when requested as an event. However, the "del" parameter is reported 💅
RQNT 1234 aaln/1@rgw2.example.net
X: AB123FE0
R: h/slThe resulting notification shows the delay between the confirmation tone and the dial tone:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: AB123FE0
O: h/sl(del=1500)Just like with the signal, the report gives the delay rounded to the nearest 100 ms ⏱️
Visual Message Waiting: when requested as an event by the Call Agent, this tells you when the visual message waiting indicator was turned on and off 👀 It isn't parameterized when requested, but a parameter is included in the report:
O: l/vmwi(+) to indicate message waiting turned on
O: l/vmwi(-) to indicate message waiting turned offNote that:
- All TO signals in the handset package can include a "to" parameter when requested as a signal.
- However, requests to be notified about these events MUST NOT include the "to" parameter, i.e., the "to" parameter is not valid in RequestedEvents. 🙅♀️
2.6. Supplementary Services Tone Package 🎀
Okay bestie, this one is all about the tones that make phone calls feel like phone calls 📞✨ Here's the header info:
Package Name: SST
Version: 0Here's the full cheat sheet of signals and how they behave 💅
---------------------------------------------------------------
|Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
|cd | Conference Depart | | BR |
|cj | Conference Join | | BR |
|cm | Comfort Tone | | TO infinite |
|cw | Caller Waiting Tone | | TO 30 sec. |
|ht | On Hold Tone | | OO |
|ni | Negative Indication | | TO infinite |
|nu | Number Unobtainable | | TO infinite |
|oc | Operation Complete | x | |
|of | Operation Failure | x | |
|pr | Pay Phone Recognition | | BR |
|pt | Pay Tone | | BR |
----------------------------------------------------------------Note that the Call Agent is allowed to over-ride the default time-out values for any Time-Out signal in this package, using a "to" signal parameter 🙌 For the details, check section 2 of this document, and also [1] 📖
Now the events, one by one 🦋
- Conference Depart (cd): a tone that tells you a participant has left a conference call 👋 The tone characteristics are left up to the specific gateway implementation.
- Conference Join (cj): a tone that tells you a party has joined a conference call 🎉 The tone characteristics are left up to the specific gateway implementation.
- Comfort Tone (cm): this one says the call is being processed and the caller should just wait 🫶 Refer to ITU-T E.182 [10].
- Caller Waiting Tone (cw): not to be confused with a call-waiting tone 🙈 This one advises a caller that the station they're calling is busy, but has call waiting service active. Refer to ITU-T E.182 [10].
- Tone on-hold (ht): a tone that reassures a calling subscriber who has been placed on "hold" 🎶 Refer to ITU-T E.182 [10].
- Negative Indication (ni): a tone that tells a subscriber their request for service can't be accepted 💀 For North America, this maps to the re-order tone (see GR-506-CORE [7], Section 17.2.7).
- Number Unobtainable Tone (nu): refer to ITU-T E.180, supplement 2 [9] 📞 This one is also called "vacant tone," and in North America it maps to a "re-order tone" (see GR-506-CORE [7], Section 17.2.7).
- Operation Complete (oc): the standard definition of operation complete [1] ✅
- Operation Failure (of): the standard definition of operation failure [1] ❌
- Pay Phone Recognition (pr): a tone that advises an operator the endpoint has been identified as a payphone 🪙 Refer to ITU-T E.182 [10].
- Pay Tone (pt): a tone that indicates payment is required 💸 Refer to ITU-T E.182 [10].
2.7. Digit Map Extension 🧚
This package is giving "make the digit map do exactly what I mean" energy 💜 It defines an Extension Digit Map Letter that overrides the shortest possible match behavior for a given entry in a digit map (see [1]). Here's the header info:
Package Name: dm1 ("dm" followed by the number "1")
Version: 0
Extension Digit Map Letters: PSo the letter P (for partial match override) goes at the end of a digit map entry, and it tells the gateway to only count that entry as a match if the current dial string doesn't partially match another entry 👀 Let's look at an example digit map:
([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP)With a current dial string of 1234567, we would NOT consider it a match (even though the rules in [1] would normally say it is) 🙅♀️ But a current dial string of 411 would still be a match as usual ✨ And a current dial string of 8234 would be a match too, since there's no other partial match 🌸
Tea time: the digit map letter P is not an event! It's just a syntactic and semantic digit map extension 🍵 So the P doesn't show up in the list of requested or observed events.
Support for this package is strongly RECOMMENDED 🔥
2.8. Signal List Package 🌈
Okay, the Signal List package is where things get fun 🎀 Here's the header info:
Package Name: SL
Version: 0And here's the cheat sheet 💅
---------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------|
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| s(list) | Signal List | | TO variable |
---------------------------------------------------------- Operation Complete (oc): this is the standard definition of operation complete from [1] ✅
- Operation Failure (of): this is the standard definition of operation failure from [1] ❌
- Signal List (s(<list>)): the
<list>is a comma-separated list of signals to be played out 🎶 Each signal in<list>MUST be either type BR or type TO. Even though it's a list, the signal list is still treated as a single parameterized signal of type Time-Out, so it's giving unity 👑 The signals are played to completion one after the other, in the left to right order you specify. The package for each signal in the list must be specified. For example, to play out the DTMF digits 123456:
S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6)This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being played out in order 🔢
Heads up! It is illegal to include an OO signal as one of the signals in the list, or to request recursive definitions (signal lists within signal lists) 🚫 If this or any other unsupported signal is included, the gateway MUST return error code 538 (event/signal parameter error) 💀
Note that as the gateway plays the ordered list, if it hits a TO signal with an infinite timeout, it will keep playing that signal until the Signal List signal is stopped. That means the signals later in the list will never get played 😭
If the operation complete (oc) event is requested, it will be detected once, when the last signal in the list has been played out, regardless of whether there are any TO signals in the list 🏁 The operation complete event will only report the signal list name itself, without the parameters supplied, like this:
O: sl/oc(sl/s)Should any of the signals in the signal list result in an error, an operation failure event for the Signal List signal MUST be generated 🚨 Only the signal list name will be included, so it's not possible to tell which signal in the list actually failed 🙈
Note that if an event occurs while the SL/S signal is playing, the SL/S signal is stopped like this:
- If the signal in the list that was playing when the event occurred is of type BR, the BR signal is played to completion, and no other signals in the list are played.
- If the signal in the list that was playing when the event occurred is of type TO, the TO signal stops immediately, and no other signals in the list are played.
2.9. Media Format Parameter Package ✨
okay bestie, this one is all about the media format parameter Local Connection Option (LCO) 🎀. Its vibe is very "fmtp" coded, since it's similar to the "fmtp" attribute in SDP [15]. It works with every media format that the matching SDP fmtp attribute could be used with, so basically any media format MIME type 🦋.
Here's the deal: Package Name: FM and Version: 0 💅. The param gets encoded as the keyword "fmtp" or "o-fmtp", then a colon, then a quoted string. That string starts with the media format name (MIME subtype only), then a space, then the media format parameters for that format 🫶. From here on I'll use "codec" and "media format" interchangeably, no cap.
Multiple formats can show up in two ways. You can repeat the "fmtp" local connection option multiple times, like this:
L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY"Or you can use a single "fmtp" keyword, a colon, and a semi-colon separated list of quoted strings, one for each media format parameter:
L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY"And yes, you can mix the two 🌈.
Now here's the tea 🍵. If the same codec can be requested with and without the special "fmtp" format, this could happen:
L:a:codec1;codec1, fmtp:"codec1 formatX"But it's not clear whether the fmtp parameter applies to the first or the second occurrence of the codec 💀. Codec ordering matters, since codecs are listed in preferred order, and the syntax above has no way to say whether "formatX" is preferred (tied to the first "codec1") or not (tied to the second "codec1"). To fix this, when the same codec is requested with multiple formats, the codec name in the "fmtp" format string gets a colon and an <order>. The <order> is a number from one to N, for N occurrences of the same codec in the codec list. So:
L:a:codec1;codec1, fmtp:"codec1:2 formatX"means "formatX" is tied to the second instance of "codec1" in the "a:codec1;codec1" list. If someone supplies an invalid instance number (say instance 3 when there are only two instances), error code 524 - inconsistency in local connection options gets returned 🙈.
Pre-pending "fmtp" with "o-" (so "o-fmtp") means the format is optional. In that case, the gateway may decide not to use the fmtp parameter, or only use part of it 🌸.
If the "fmtp" in an LCO is not optional (no "o-" in front), and the LCO value is either not recognized or not supported, then the associated codec is considered "not supported" 😭.
When auditing capabilities, the "fmtp" local connection option MUST be returned with a semi-colon separated list of supported formats and/or multiple independent "fmtp" parameters, like this:
A: a:telephone-event, fmtp:"telephone-event 0-15,32-35",...
A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",...One example pairs the media format parameter LCO with the media format "telephone-event", as defined in RFC 2833 [33] 🧚. If "telephone-event" is used without the "fmtp" media format parameter, the DTMF digits (telephone events 0-15 from RFC 2833 [33]) are assumed. That practice is discouraged though 🙈. On the other hand, the media format parameter LCO MAY be used to specify the exact set of events being requested via RFC 2833 [33]. Example:
L: a:PCMU;telephone-event,fmtp:"telephone-event 16"This indicates that if telephone events are supported at all, this request is specifically for event 16 🎯.
The Call Agent can also mark some format parameters as "required" and others as optional. In the example below, telephone events 0-15 are a "must", while telephone events 16, 70 and 71 are optional 👑.
L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71",
fmtp:"telephone-event 0-15"If the gateway cannot support telephone events 0-15, it MUST NOT include the "telephone-event" media format in the SDP in its response. But if it can support those telephone events, it SHOULD indicate support for them, plus any of the events 16, 70 and 71 that it supports 💖.
If someone makes a request to audit the capabilities of an endpoint, and that endpoint supports the "telephone event" media format with events "0-16", the audit would include this:
A: a:telephone-event, fmtp: "telephone-event 0-16"Another example is redundancy with RFC 2198 [32] 🔥. Same deal as the SDP, except the literal string ("red" in this case) gets used instead of the payload type:
L: a:G729;pcmu;red,fmtp:"red pcmu/g729"The matching media description in the SDP, as part of the connection request acknowledgment, might look like this:
m=audio 12345 RTP/AVP 98 18 0
a=rtpmap:98 red/8000/1
a=fmtp:98 0/18If we combine telephone events and redundancy, an example local connection option might look like this (carriage return added for formatting reasons here):
L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729",
fmtp: "telephone-event 16"Note that we again use the literal string for the encoding method, not its payload type. This is a general principle that should be used with this LocalConnectionOption 🍓.
The corresponding SDP might look like this:
m=audio 12345 RTP/AVP 97 98 18 0
a=rtpmap:97 red/8000/1
a=fmtp:97 0/18
a=rtpmap:98 telephone event
a=fmtp:98 16The fmtp LCO may be used in any situation where the corresponding SDP attribute may be used ✨. Here's an example of a local connection option that uses a media type other than audio, with a "foobar" fmtp parameter:
L: a:image/tiff, fmtp:"tiff foobar"Heads up: local connection options tied to a package should normally include the package prefix, following the package extension rules in [1]. The "fmtp" and "o-fmtp" LCO in the "FM" package are the exception 🙈. The package prefix is left off for those two because they were created before the extension rules in [1] existed.
These two LocalConnectionOptions have been registered with IANA 🦋.
2.10. RTP Package 🎀
Package Name: R Version: 1
-------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|-------------------------------------------------------------|
| co1 | Continuity Tone (single | C | TO,C 3 sec. |
| | or return tone) | | |
| co2 | Continuity Test (go tone, | C | TO,C 3 sec. |
| | in dual tone procedures) | | |
| iu(..) | ICMP Unreachable | C | |
| | Received | | |
| ji(..) | Jitter Buffer Size Changed | C | |
| ma | Media Start | C | |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| pl(..) | Packet Loss Exceeded | C | |
| qa | Quality Alert | C | |
| rto(..) | RTP/RTCP Timeout | C | |
| sr | Sampling Rate Changed | C | |
| uc | Used Codec Changed | C | |
-------------------------------------------------------------Okay so the changes in event types are: "co1" and "co2" signals changed from OO to TO. 👀
New events added to this package from the previously unversioned package: "iu", "rto", "ma". ✨
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details. 🫶
The events in this package all refer to media streams (connections), i.e., they cannot be detected on an endpoint. Furthermore, with the exception of the "iu" event, which is defined for any type of media, all other events in this package are defined for RTP media streams only (i.e., if they are used on connections that do not use RTP, the behavior is not defined). 🦋
Signals requested (e.g., "co1" and "co2") must indicate the connection ID (e.g., "S: r/co1@connectionID"). An event may be requested for all existing connections using the "*" wildcard for the connectionID as described in [1]. 💅
Example:
R: r/uc@* (request to detect uc on all connections) or
R: r/uc@connectionID (request to detect uc only on a specific
connection)An event detected on a connection will include the connectionID, e.g.:
O: r/uc@connectionID(15)Continuity tones (co1 and co2) 🌈
These are the same as the events defined in the Trunk package, except in this case, they are only played over a network connection and the connectionID MUST be supplied (e.g., "s: r/co1@connectionID"). They can be used in conjunction with the Network LoopBack (netwloop) or Network Continuity Test (netwtest) modes to test the continuity of an RTP circuit. However, in the case of testing IP continuity, a one-tone test is sufficient i.e., generating and detecting "co1" at one end, with connection mode in network loopback mode at the other end. Note that the test can also be done using telephone events rather than tones, i.e., event 167 in RFC 2833 [33] corresponds to "co1". In this case, connection requests are made with local connection options such as:
L: a:PCMU;telephone-event,fmtp:"telephone-event 167"in order to request support for telephone event 167. If both ends support the event, then the network loopback proceeds as usual, except that telephone events corresponding to the co1 tone are sent, as opposed to the co1 tone itself. 🧚
ICMP Unreachable Received (iu) 🚫
This event indicates that some number of ICMP unreachable packets [19] was received for this connection since an RQNT was received requesting this event. This notification indicates that packets that were sent by the gateway on this connection either did not arrive at their destination or were not accepted (e.g., the port was closed). When this event is requested, a single parameter with a decimal number from 1 to 255 may be included to indicate the number of ICMP un-reachable packets that must occur before the event is notified. If no parameter is supplied, with the request then a default value of 3 is assumed. This is a one-shot event in that once the event occurs, a further request is required in order to re-initiate counting. 🙈
The observed event is parameterized with two parameters:
- The first parameter is the number of ICMP unreachable packets received (i.e., the same value that was included in the request - or the value 3, if the requested event was not parameterized)
- The second parameter is the error code indicated in the ICMP unreachable packet, e.g.:
0 = net unreachable;
1 = host unreachable;
2 = protocol unreachable;
3 = port unreachable;
4 = fragmentation needed and DF set;
5 = source route failed.
etc.An example of a request might be as follows:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: r/iu@364823(N)(5)In this case, a notify will occur if 5 ICMP port unreachable packets are received as a result of RTP and/or RTCP packets being sent from this gateway on the connection with connection ID 364823. 💌
The resulting NTFY with observed events might be as follows:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: r/iu@364823(5,3)The first parameter indicates 5 ICMP unreachable packets were received since the RQNT with this request was sent. The second parameter ("3") specifies the reason, which in this case, is "port unreachable". 🎯
Jitter Buffer Size Changed (ji) 🍓
This event is only included here to maintain compatibility with the previous version of this package. This event is used to indicate that the gateway has made an adjustment to the depth of the jitter buffer. The syntax for requesting notification is "ji", which tells the media gateway that the controller wants notification of any jitter buffer size changes. The syntax for notification from the media gateway to the controller is "JI(####)", where the #### is a decimal number from 1 to 65536, indicating the new size of the jitter buffer in milliseconds. 🌸
Media Start (ma) 🎬
The media start event occurs on a connection when the first valid RTP media packet is received on the connection. This event can be used to synchronize a local signal, e.g., ringback, with the arrival of media from the other party. 📞
The event is detected on a connection. If no connection is specified, the event applies to all connections for the endpoint, regardless of when the connections are created (i.e., if a connection is not specified, the event will occur when the first valid RTP packet arrives on any one of the connections on that endpoint). 🫶
Operation complete (oc) ✅
This is the standard definition of operation complete [1].
Operation failure (of) ❌
This is the standard definition of operation failure [1].
Packet Loss Exceeded (pl) 📉
Packet loss rate exceeds the threshold of the specified decimal number (with a range of 1 to 100,000) of packets per 100,000 packets, where the packet loss number is indicated in parenthesis. For example, PL(10) is a drop rate of 10 in 100,000 packets. This event is requested with a parameter indicating at what packet loss rate the Call Agent wishes to be reported. If the packet loss exceeds that value, the event is reported with that same parameter. The event is only reported once when the packet loss threshold is exceeded. Once reported, a following request will re-initiate packet loss measurements and report when the threshold is exceeded again. 💜
Quality alert (qa) 🚨
The packet loss rate or the combination of delay and jitter exceeding a quality threshold. The quality thresholds for delay, jitter and packet loss rate are provisioned values. ⭐
RTP/RTCP Timeout (rto(<timeout>,st=<start-time>)) ⏰
This event indicates that neither RTP nor RTCP packets have been received on this connection for a period of time equal to the <timeout> value (in seconds). The timeout value can be supplied as a decimal number from 1 to 65535 in the parameter when the request is made. The <timeout> parameter will be supplied in ObservedEvents when the event is reported - it then simply repeats the value used. If an RTP or RTCP packet is received before the timer expires, then the timer is reset and re-started. The event will only be generated if the timer expires without an RTP or RTCP packet arriving on the specified connection during the specified period of time. Note that if the event is requested without the <timeout> parameter, then a default timeout of 60 seconds is assumed. The <timeout> value will still be reported in ObservedEvents, even if no timeout value was indicated in the request (the default value will be indicated in that case). This is a one-shot event in that once the event occurs, a further request is required in order to re-initialize the timer. 💀
Another optional <start-time> parameter may also be included. This is used to indicate when the timer starts. It can have one of the following values:
- "im" for immediate i.e., the timer starts as soon as the request is received. This is the default.
- "ra" to indicate that the timer should start only after an RTCP packet has been received from the other end (i.e., the timer will be initiated when the first RTCP packet is received after the request is made). Note that in the case where the other end does not support RTCP, the timer will never be initiated.
Note that either the <timeout> or <start-time> may be included in the request, but only the <timeout> value is included in the report.
An example of a request might be as follows:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: r/rto@364823(N)(120,st=im)In this case, a notify will occur if there is a period of time when no RTP or RTCP packets have been received on connection 364823 for 120 seconds. 🕰️
The resulting NTFY with observed events would be as follows:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: r/rto@364823(120)Sampling Rate Changed (sr) 🎵
This event is only included here to maintain compatibility with the previous version of this package. This event indicates that the packetization period changed to some decimal number in milliseconds enclosed in parenthesis, as in SR(20). 🎶
Used Codec Changed (uc) 🎙️
This event is only included here to maintain compatibility with the previous version of this package. This event is requested without a parameter, but when reported, the hexadecimal payload type is enclosed in parenthesis, as in UC(8), to indicate the codec was changed to PCM A-law. Codec Numbers are specified in RFC 3551 [26], or in a new definition of the audio profiles for RTP that replaces this RFC. 🌟
2.11. Resource Reservation Package ✨
Package Name: RES
Version: 0
2.11.1. Description 💖
okay bestie, the "RES" package is all about resource reservations 🦋 It gives you local connection option support for them, plus an event that tells you when a reservation gets lost 😭
There are four LocalConnectionOption parameters that do the heavy lifting here: "reservation request", "reservation direction", "reservation confirmation" and "resource sharing". Let's get into them 💅
Reservation Request LocalConnectionOption 🌸
The gateways can be told to make a reservation on a connection using RSVP. When a reservation is needed, the Call Agent picks the reservation profile, and it's either "controlled load" or "guaranteed service". No reservation? Just ask for "best effort", which is the default value for this parameter. Very chill 🧚
Whether RSVP happens at all depends on whether the reservation request parameter showed up in a connection request for this connection (with either "controlled load" or "guaranteed service" set). Now here's the tea. If a modify connection (MDCX) request needs a change to the reservation but doesn't include "reservation request" in its LocalConnectionOptions, and the earlier connection request for that connection did include it, then "reservation request" defaults to whatever value was saved for that connection. ✨
And if an MDCX request explicitly includes a "reservation request" asking for "best effort" on a connection that already has a reservation, the existing reservation gets torn down. Bye bye, reservation 👋
Reservation Direction LocalConnectionOption 🎀
Once a reservation has been requested on a connection, the gateway looks at the reservation direction parameter to figure out which direction the reservations need, and then does the following:
- Start emitting RSVP "PATH" messages if the reservation direction LocalConnectionOptions parameter specified "send-only" or "send-receive".
- Start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the reservation direction parameter specified "receive-only" or "send-receive".
If an RSVP reservation is requested but the reservation direction LocalConnectionOption parameter is missing, the direction defaults to the previously saved value of that parameter for the connection. And if there was never a previous reservation direction parameter for that connection, the value gets deduced from the connection mode. That looks like this:
- Start emitting RSVP "PATH" messages if the connection is in "send-only", "send-receive", "conference", "network loop back" or "network continuity test" mode (if a remote connection descriptor has been received).
- Start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the connection is in "receive-only", "send-receive", "conference", "network loop back" or "network continuity test" mode.
Reservation Confirmation LocalConnectionOption 🍓
The reservation confirmation parameter is the other big one for RSVP reservations. It decides what the resource reservation pre-condition (see [1]) is before the gateway acknowledges a successful connection request 🔥
- If the reservation confirmation parameter is set to "none", the gateway will "Ack" the connection request without waiting for the reservation to finish. This is the default behavior.
- If the "reservation confirmation" parameter is set to "send-only", the gateway will "Ack" once the PATH message has been sent and the matching RESV has been received, showing the reservation worked in the send direction.
- If the "reservation confirmation" parameter is set to "receive-only", the gateway will "Ack" once reservation confirm for a reservation has been received.
- If the reservation confirmation parameter is set to "send-receive", the gateway will "Ack" only after the PATH message has been sent and the matching RESV has been received for the send direction, and reservation confirm has been received for the receive direction.
A few notes, because these details matter 🙈
The values "receive-only" and "send-receive" are what tell the gateway to ask for a reservation confirm (RESVCONF) when it sends out the RESV.
Pre-conditions SHOULD only be added for the direction(s) where resource reservations were requested. If a direction gets added as a pre-condition but wasn't requested in the resource reservation, that direction MUST simply be ignored as a pre-condition.
Here, resource reservation success is the pre-condition for the final acknowledgement of the connection request. If the reservation fails, the connection request fails too (error code 404 - insufficient bandwidth), and so does any other part of the transaction, like a notification request that came along with the connection request. Picture this: you send a request to ring the phone and watch for off-hook, all in one connection request. If the reservation fails, the phone won't ring 📞 And if the phone is already off-hook, the command fails and no resource reservation happens either. Rough day 💀
A provisional response SHOULD be provided if confirmation is expected to happen outside the normal retry timers. In fact, a provisional response MUST be provided if the reservation confirmation parameter has the value "send-receive". Why so strict? Without a provisional response, SDP information can't be returned until the final "Ack", and that won't happen until the reservation is complete. That can cause a deadlock, because the SDP information usually has to reach the other end so it can start the RSVP PATH message going the other direction 🔒 The SDP information and connectionID MUST be included in both the provisional response and the final response. Also, so that a lost final response can be spotted fast, final responses that come after provisional responses for a transaction SHALL be acknowledged. That means they SHALL include an empty "ResponseAck" parameter in the final response (see [1]). Ack-ception 🫶
If the transaction time falls outside the expected bounds (time T-HIST - see the section on provisional responses in [1]), error code 406 (transaction timeout) SHOULD be returned ⏰
One more thing: if the reservation confirmation parameter is left out, its value defaults to the previously saved value. If there's no previously saved value, or the parameter is "none", then a successful resource reservation is not a pre-condition for acknowledging the connection request. The gateway can "Ack" right away without waiting for the reservation to finish, and no provisional response is needed 🌈
Resource Sharing LocalConnectionOption 🧚♀️
Sometimes network resources can be shared across multiple connections. Call-waiting is a classic example, since only one connection will ever be active at a time. In a 3-way calling setup with a similar set of connections, sharing isn't possible. Only the Call Agent knows what's possible, because it depends on the feature being invoked 👑
So the resource sharing LocalConnectionOption parameter exists to let the Call Agent say when sharing is allowed. It can have one of these values:
- The value "$" means "this connection". It's used when doing a create connection and shows the intent to share resources with this connection.
- A connection ID means this is a request to share resources with the connection that has that connection ID (letting multiple connections share resources with the one indicated).
- An empty value means a request to stop sharing this connection's resources with other connections.
For a CRCX, the default for the resource sharing local connection option is empty. For an MDCX, the default is its current value 💜
The RSVP filters are deduced from the characteristics of the connection. The RSVP resource profiles are deduced from the connection's bandwidth and packetization period 🎀
Heads up: if RSVP is used with PacketCable Dynamic Quality of Service [35], then the parameters in NCS [36] get used instead of the reservation direction, confirmation and reservation sharing parameters described here. Different rules for a different crowd 🙈
2.11.2. Parameter Encoding 🍓
The Local Connection Options for the "RES" package consist of the following:
- The resource reservation parameter, encoded as the keyword
r, followed by a colon and the valueg(guaranteed service),cl(controlled load) orbe(best effort). - The reservation direction parameter, encoded as the keyword
r-dirfollowed by a colon and the valuesendonly,recvonlyorsendrecv. - The reservation confirmation parameter, encoded as the keyword
r-cnffollowed by a colon and the valuenone,sendonly,recvonlyorsendrecv. - The resource sharing parameter, encoded as the keyword
r-shfollowed by a colon and either:- The wild-card character
$indicating this connection, indicating future plans to share resources with this connection, or - A connection ID, indicating a request to share resources with the connection having the specified connection ID (and all other connections sharing resources with that connection), or
- An empty value (i.e.,
r-sh:with no value indicated), indicating a request to no longer share the resources of this connection with other connections
- The wild-card character
Quick note on naming 🌷 Normally, local connection options tied to a package include the package prefix, as per the package extension rules in [1]. The local connection options in the "RES" package are the exceptions. The package prefix is left off for "RES" because it was created before the extension rules in [1] were defined. History, babe 📜✨
2.11.3. Events ✨
okay bestie, the resource reservation package has two events, and they're both about the reservation going sideways mid-call 😭
------------------------------------------------------
| Symbol | Definition | R | S Duration |
|------------------------------------------------------|
| re | Resource Error | C | |
| rl | Resource Lost | C | |
------------------------------------------------------Resource Error (re):
this is the "hey, something went wrong with the reservation while the call was alive" event 💀 You don't ask for it with a parameter, but it comes back with one. It may or may not mean the reservation is gone for good, since any reservation error gets reported, whether it's permanent or just temporary 🫶 If you request it on an endpoint without naming a connection ID, it covers every connection on that endpoint, the ones that exist now and the ones that show up later 🦋 When it's reported, the connectionID is always included, along with a reason as a parameter. One of these reasons MUST be included as the parameter when the event is reported:
- "resverr" is used to indicate that a ResvErr message was received.
- "patherr" is used to indicate that a PathErr message was received.
- "other"
On top of one of those reasons, additional information about the type of error MAY be included as a second parameter, in the form of a quoted string 💅
Example reports might look like:
O: res/rl@0A3F58(resverr)or
O: res/rl@0A3F58(resverr, "some additional commentary")Note that this event will not be reported if an error happens while the reservation is first being set up. It only shows up if the error came after setup was already done 🙈
Resource Lost (rl):
if the reservation gets lost during the life of a connection, you can report that with the "rl" event 🍓 You don't request it with a parameter, but it's reported with one. If you request it on an endpoint without specifying the connection ID, it applies to all present and future connections on that endpoint, same as before 🌈
When it's reported, the connectionID is always supplied with a reason for the loss as a parameter. One of these reasons MUST be supplied as the parameter when the event is reported:
- "resvtear" indicating that the reservation loss was indicated by ResvTear message.
- "pathtear" indicating that the reservation loss was indicated by PathTear message.
- "other"
Extra info about the error MAY be included as a second parameter, as a quoted string, same deal as Resource Error 💖
Example reports might look like:
O: res/rl@0A3F58(ResvTear)or
O: res/rl@0A3F58(ResvTear, "some other commentary")Note that this event won't be reported if an error happens while the reservation is first being set up. It only fires if the reservation was lost after it had already been set up ✨
2.12. Announcement Server Package 🎀
Package Name: A
Version: 1
---------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
| ann(url) | Play an Announcement | | TO, C variable |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
---------------------------------------------------------------So this version changed things up to match the standard way of reporting operation failure and operation complete events. Lowkey a glow-up 🌸
The announcement signal gets qualified by a URL name, like this:
S: ann(http://scripts.example.net/all-lines-busy.au)A list of initial parameters, separated by commas, MAY follow the URL name. Standard parameters aren't part of this package though. Using extra parameters is optional and would give you a proprietary interface, so be careful with that one 👀
The gateway SHOULD support one or more standard URL schemes, such as:
- file, http, ftp (RFC 1738 [28]), which indicate where the audio file is located (where to load the file from before playing the audio file on the gateway).
- RTSP URL (section 3.2 of RFC 2326 [29]), which in this case allows the media gateway to directly initiate playing of the announcement via an RTSP server.
For a successful response (return code of "200"), the pre-condition is correct syntax and capability, meaning support is available for the request. Standard MGCP return codes apply if something fails. Any extra detail about the failure goes in the operation failure event, as a comment after the name of the failed event in the form of a quoted string 🫠
If the announcement can't be played out for a reason that only shows up after a successful response has already been sent, an operation failure event gets returned. The failure MAY be explained with some commentary, in the form of a quoted string, like this:
O: a/of(a/ann,"file not found")The "operation complete" event gets detected once the announcement has been played out:
O: a/oc(a/ann)2.13. Script Package 🧚
Package Name: Script
Version: 1
-----------------------------------------------------------------
| Symbol | Definition | R | S | Duration |
|-----------------------------------------------------------------|
| ir(..) | Intermediate Results/Req.| x | BR | |
| java(url,...) | Load & Run java script | | TO | variable |
| oc | operation complete | x | | |
| of | operation failure | x | | |
| perl(url,...) | Load & Run perl script | | TO | variable |
| tcl(url,...) | Load & Run TCL script | | TO | variable |
| vxml(url,...) | Load & Run VXML doc. | | TO | variable |
| xml(url,...) | Load & Run XML script | | TO | variable |
-----------------------------------------------------------------Quick tea on what changed: "vxml" got added as a language type for loading and running VXML documents, the operation failure and operation complete events were updated to match the standard reporting style, and the "ir" event is new 🎉
The current definition sets keywords for the most common languages. More languages may be defined in later versions of this package 🌈
The "signal" that specifies the scripting language is parameterized with a URL that says where the script lives. A comma-separated list of arguments MAY be optionally followed after that URL, to use as initial parameters when running the script. URL schemes may include file, ftp, or http schemes, using the syntax from RFC 2396 [30]. For example:
S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2,
...,argn)The argument list "arg1,arg2,...,argn" gets passed to the script/document as a list of initial parameters 💅
Same as the announcement package, a successful response (return code of "200") needs correct syntax and capability, meaning support is available for the request. Standard MGCP return codes apply for failures. Some further failure indications that aren't specific to the application or script MAY be provided in the operation failure event, as a comment in the form of a quoted string after the name of the failed event:
O: script/of(script/vxml,"file not found")The script produces an output made of one or several text strings, separated by commas. This gives you the return status of the script, plus any return parameters (if there are any) 👑
O: script/oc(script/vxml,return-status=<status>,
name1=value1,name2=value2,...)Here, <status> can be either "success" or "failure". After that come the output parameters as a comma-separated list of name-value pairs 🦋
Intermediate Result/Request (ir(<params>)):
this provides a way for:
- The script to inform the Call Agent of intermediate results (e.g., a case where it is important because of timing concerns to inform the Call Agent prior to operation complete).
- The script to request some information from the Call Agent.
- The Call Agent to inform the script of some event or information that may be important for the operation of the script (in this case "ir" is used as a signal).
Parameters (i.e., <params>) SHOULD be a comma-separated list of name-value pairs, e.g., ir(name1=value1,name2=value2,..). The Call Agent MAY include event parameters when it requests this event. In that case, the MGCP syntax requirements mean the action has to be specified, like R: ir(N)(nam1=value1,name2=value2,..) 🧠
If the Call Agent requests "ir" as a signal, at least one parameter MUST be provided.
When the Call Agent requests the "ir" signal, it MUST also repeat the original script signal. This keeps things consistent with how TO signals work in MGCP: if the original "script" signal isn't included, the signal/script gets stopped 🛑 The catch is a possible race condition, where a request to send an "ir" signal lands right as the script stops. To dodge that confusion, the following is RECOMMENDED: when the script signal goes along with an "ir" signal, include a parameter (of the script signal) saying this isn't a new instance of the script. That way, if no script is running right now, a new one doesn't start up 🙅♀️
The "ir" signal only goes with an executing script. If none are running when someone requests the event or signal, or if a new script request isn't included with the request, then the "ir" signal/event won't be executed. The "ir" event, with its parameters, gets passed to an existing script for parsing and execution, and MGCP treats it as opaque. If no such script exists, response code "800" gets returned, which means the script isn't executing 💀
The following response code is associated with this package:
Code Text Explanation
800 Script not Request for "ir" signal or event
Executing but no script is executing at the
time the request was received.Package-specific error codes include the package name after the error code. So if error code 800 shows up in response to a request with a transaction ID of 1001, it gets sent like this:
800 1001 /SCRIPT3. IANA Considerations ✨
okay bestie, so IANA is the registry people 💅 and this is where the packages and their versions got registered. Here's the full list, no cap:
Package Title Name Version
------------- ---- -------
Announcement A 1
DTMF D 1
Digit Map Extension DM1 0
Media Format FM 0
Generic G 1
Handset H 1
Line L 1
RTP R 1
Resource Reservation RES 0
Script SCRIPT 1
Supplementary Tones SST 0
Signal List SL 0
Trunk T 1The extension digit map letter that got registered is the one for DM1:
Package Letter
------- ------
DM1 PAnd these Local Connections got registered too 🎀:
Field Name
------- -----
Media Format fmtp
Reservation Confirmation r-cnf
Reservation Direction r-dir
Resource Sharing r-sh4. Security Considerations 🔐
okay, this part is lowkey short but it's giving very important energy. The MGCP packages in this document do not need any further security considerations beyond the ones in the base MGCP specification [1]. So the security stuff is all handled over there, periodt 💀
5. Acknowledgements 🫶
Huge shoutout to the people who wrote the original MGCP 1.0 spec: Mauricio Arango, Andrew Dugan, Isaac Elliott, Christian Huitema, and Scott Picket. Iconic 👑
Thanks also to the reviewers of this doc, including but not limited to: Jerry Kamitses (Sonus Networks); Dave Auerbach and Dan Wing (Cisco Systems); Ed Guy (EMC Software); and Martin Wakley (Nortel Networks). They're the real MVPs 🌸
6. References 📚
6.1. Normative References
[1] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[2] Bellcore, "LSSGR: Switching System Generic Requirements for Call Control Using the Integrated Services Digital Network User Part (ISDNUP)", GR-317-CORE, Issue 2, December 1997.
[3] ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724, November 1988.
[4] ANSI, "OAM&P - Terminating Test Line Access and Capabilities", T1.207-2000.
[5] Bellcore, "Notes on the Network", Special Report SR-2275, Issue 3, December 1997.
[6] Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997.
[7] Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE, Issue 1, June 1996.
[8] ITU-T, "Technical Characteristics of Tones for the Telephone Service", ITU-T E.180, March 1998.
[9] ITU-T, "Various Tones Used in National Networks", ITU-T E.180, Supplement 2, January 1994.
[10] ITU-T, "Applications of Tones and Recorded Announcements in Telephone Services", ITU-T E.182, March 1998.
[11] Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586, Issue 1, June 2000.
[12] Bellcore, "CPE Compatibility Considerations for the Voiceband Data Transmission Interface", SR-TSV-002476, December 1992.
[13] Bellcore, "LSSGR: Visual Message Waiting Indicator Generic Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000.
[14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section 6.6, GR-30-CORE, Issue 02, December 1998.
[15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[16] Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue 01, June 2000.
[17] Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR-531-CORE, Issue 1, June 2000.
[18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000.
[19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[20] Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR-220, Issue 2, April 2002.
[21] ITU-T, "Procedure for document facsimile transmission in the general switched telephone network", ITU-T T.30, April 1999.
[22] ITU-T, "300 bits per second duplex modem standardized for use in the general switched telephone network", ITU-T V.21, November 1988.
[23] Telcordia Technologies, "Telcordia Technologies Specification of Signaling System Number 7", GR-246-CORE, Issue 7, December 2002.
[24] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Name Delivery Generic Requirements (FSD 01-02-1070)", GR-1188, Issue 02, December 2000.
[25] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000.
[26] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[27] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[28] Berners-Lee, T., Masinter, L. and M. McCahill, Eds., "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[29] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[30] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[31] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[32] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[33] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[34] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001.
[35] PacketCableTM, Dynamic Quality if Service Specification, http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07-030815.pdf
[36] PacketCableTM Network-Based Call Signaling Protocol http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08-030728.pdf
[37] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Eds., "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[38] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.
7. Authors' Addresses 💌
Bill Foster
Cisco Systems
Phone: +1 250 758 9418
EMail: bfoster@cisco.com
Flemming Andreasen
Cisco Systems
Edison, NJ 08837
EMail: fandreas@cisco.com8. Full Copyright Statement ©️
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🦋
📦 where this page comes from
- ietf: rfc3660 2003-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms