Internet DRAFT - draft-sassenberg-mgcp-extended-line-packages
draft-sassenberg-mgcp-extended-line-packages
Individual Submission
INTERNET-DRAFT T. Sassenberg
Document: draft-sassenberg-mgcp-extended- Nortel Networks
line-packages-00.txt
Expires: January 2005 July 2004
Extended MGCP Line Packages
Status of this Document
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668."
This document is intended to become an "Informational" Request For
Comments (RFC) and is in full conformance with all provisions of
Section 10 of RFC2026. As described in section 4.2.3 of RFC2026, the
RFC Editor will publish this document as an Internet-Draft as it has
not been published prior to this draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
IESG NOTE:
This document is being published for the information of the
community. It describes a non-IETF protocol that is currently being
deployed in a number of products. Implementers should be aware that
the IETF Megaco working group and the ITU-T Study Group 16 have
produced a standards track RFC "Megaco Protocol Version 1.0" (RFC
3015, also published as ITU recommendation H.248), which addresses
the same problem space, and are developing extensions to that
protocol for functions of this type.
Sassenberg Expires - January 2005 [Page 1]
Extended MGCP Line Packages July 2004
Abstract
This document provides an extended set of Media Gateway Control
Protocol (MGCP) packages. The Extended Analog Line, Business Set,
Carrier, Intrusion, Display, Test, and Metering packages are newly
defined in this document.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [10].
Table of Contents
1.Introduction ....................................................2
1.1. List of Packages..............................................2
2. Packages.........................................................3
2.1. Extended Analog Line Package..................................4
2.2. Business Set Package..........................................9
2.3. Carrier Package..............................................10
2.4. Intrusion Package............................................11
2.5. Display Package..............................................12
2.6. Test Package.................................................14
2.7. Metering Package.............................................15
3.0. IANA Considerations...........................................20
4.0. Security Considerations.......................................20
5.0. Acknowledgements..............................................20
6.0. References....................................................21
6.1 Normative References..........................................21
6.2 Informative References........................................21
7.0. Authors' Addresses............................................22
8.0. Full Copyright Statement......................................22
1. Introduction
This document provides an extended set of Media Gateway Control
Protocol (MGCP) packages. The Extended Analog Line, Business Set,
Carrier, Intrusion, Display, Test, and Metering packages are newly
defined in this document. This document uses a lot of the same
wording and descriptors as the Informational RFC 3660 Basic Media
Gateway Control Protocol (MGCP) Packages.
1.1 List of Packages
Sassenberg Expires - January 2005 [Page 2]
Extended MGCP Line Packages July 2004
The basic set of packages specified in this document is for use with
MGCP 1.0 as defined in [1]. Included are the following packages:
-------------------------------------------
| Package | Name |
|-------------------------------------------|
| Extended Analog Line | XAL |
| Business Set Package | BIZ |
| Carrier Package | CARR |
| Intrusion Package | INT |
| Display Package | DISP |
| Test Package | TEST |
| Automatic Metering Package | AM |
-------------------------------------------
2. Packages
Throughout this document, as in [11], terms "signal" and "event" are
used to differentiate a request from a Call Agent to a Media Gateway
to apply an event ("signal"), from requesting the detection of an
"event" that occurs on the Media Gateway and is "Notified" to the
Call Agent.
For each of the following packages there is a table with five columns,
similar to that used in RFC3660 [11]:
Symbol: the (package) unique symbol used to identify the event.
Definition: a short description of the event.
R: an x appears in this column if the event can be requested by
the Call Agent. Alternatively, one or more of the following
symbols may appear. An "S" is included if the event-state may be
audited. A "C" indicates that the event can be detected on a
connection, and a "P" indicates the event is persistent.
S: if nothing appears in this column for an event, then the event
cannot be signaled by the Call Agent. Otherwise, the following
symbols identify the type of event:
* OO On/Off signal
* TO Time-Out signal.
Sassenberg Expires - January 2005 [Page 3]
Extended MGCP Line Packages July 2004
* BR Brief signal. Note in some cases, the duration of the
brief signal is specified by the parameters accompanying the
signal. Regardless of the length of the signal, it should be
treated as brief according to definitions in [1].
In addition, a "C" is indicated if the signal can be generated
on a connection.
Duration: specifies the default duration of TO signals. If a
duration is left unspecified then the default timeout will be
assumed to be infinite unless explicitly noted in the
description of the signal.
Default time-out values may be over-ridden by the Call Agent for any
Time-Out event defined in this document by a "to" signal parameter
which specifies the timeout value in milliseconds (see [1]). The
following example indicates a timeout value of 5 seconds.
S: xal/xdt(to=5000)
As indicated in [1] and [11]: by default, a supplied time-out value
MAY be rounded to the nearest non-zero value divisible by 1000, i.e.
whole second.
Note: as per [1] and [11], On-Off (OO) signals are parameterized with
"+" (meaning turn on) or "-" (meaning turn off). If the parameter is
missing, the default is to turn on the signal. Unlike Time-Out
signals, On-Off signals do not stop when an event occurs.
As specified in [11], other than the "to" parameter for Time-out(TO)
signals and the "+" and "-" for On-Off (OO) signals, signals and
events in the packages in this document do not have parameters,
unless explicitly indicated in the description of the event for that
package. Each of the signal/event parameters specified in this
document are designated by their ordering. Therefore, if a parameter
is not specified for a given signal/event, the entity MUST place a
blank with commas to indicate as much.
2.1 Extended Analog Line Package
Package Name: XAL
Version: 0
The Extended Analog Line Package extends the MGCP Basic Line Package
[11] with events and signals that can be observed on analog line
endpoints.
Sassenberg Expires - January 2005 [Page 4]
Extended MGCP Line Packages July 2004
---------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
| spec | Special Dial Tone | | TO 16 sec. |
| xdt | Transfer Dial Tone | | TO 16 sec. |
| cfw | Call Forward Tone | | BR |
| rev | Line Reversal | | OO |
| rack | Reset Acknowledge Tone | | BR |
| xci | Extended Caller Id | | BR |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
---------------------------------------------------------------
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, and [1]
and [11] for details.
The signals are defined as follows:
Special Dial Tone (spec):
This tone indicates that the originator's line has a condition
which prevents terminations (i.e. universal Call Forwarding). This
is also referred to as "special dial tone" in ITU-T E.182 [8]. It
is considered an error to try and play Special Dial 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).
Transfer Dial Tone (xdt):
This tone indicates a readiness to receive the transfer address
information. It is considered an error to try and play Transfer
Dial 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).
Call Forward Tone (cfw):
This tone indicates a call is being forwarded to another
destination. This may also be referred to as call diversion tone.
This tone corresponds to "special ringing tone" as defined in ITU-T
Recommendation E.182 [8]. It is considered an error to try and play
Call Forward Tone on a phone that is off hook and an error MUST
consequently be returned when such attempts are made (error code
401 - phone off hook).
Sassenberg Expires - January 2005 [Page 5]
Extended MGCP Line Packages July 2004
Line Reversal (rev):
This signal indicates the gateway should generate line reversal on
the line. Line reversal consists of reversing the polarity of the
tip/ring leads(GND becomes -48V and -48V switches to GND). There
are two ways in which line reversal is often used:
1. Line reversal on seizure - This is used to prevent a
glare condition when a call is originating from a line at the same
time that a call is terminating to the line. The line reversal
signal is applied on seizure to the terminating/called party
followed by ringing and maintained until the line is answered. Once
reversal has been applied the line cannot attempt a simultaneous
origination.
2. Line reversal on answer - In this case line reversal will
be applied to the originating party to control electronic equipment
such as coin phones or answering machines. The line reversal signal
acts as a stimulus to the equipment to perform specific actions
such as dropping coins or activating the answering machine.
This signal activates or switches off line reversal on an endpoint
(line). The gateway shall reverse the polarity of the tip and ring
wires for that line (or return it to normal), immediately after the
signal is received (regardless of the lines current call processing
state).
The On/Off parameters (+/-)accompany the Line Reversal signal
because it is defined as an On/Off signal.
Reset Acknowledge (rack):
This tone acknowledges that a subscriber, entering digits for a
telephony service, has pressed the reset digit, as defined by the
active feature. The reset digit is used when the subscriber has
made an error and wishes to clear previous digits and enter digits
again. This tone informs the subscriber the reset command has been
processed and the number can be reentered. It is considered an
error to try and play "rack" 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).
Extended Caller Id
(xci(ti, nu, na, cq, noa, npi, netid, rnu, fctype, user):
This signal extends the Line Package CallerId [11] signal to
include additional information that may be displayed on various
phone sets in various countries. Each of the parameters for this
signal is optional; however entities MUST include commas for blank
parameters to delineate the next parameter. The ordering of these
Sassenberg Expires - January 2005 [Page 6]
Extended MGCP Line Packages July 2004
parameters is not changeable. Each of these parameters can align to
a parameter type in the Multi-data Message Format (MDMF) used to
convey Caller Id data from the GW to a phone set. Refer to
specifications ETSI EN 300 659-3 [3], Bellcore GR-30 [4], Bellcore
Digest "Notice to the Industry" [5] and NTT Telephone Services
Interfaces [2].
The following parameters MAY be included in the Extended CallerId
signal:
time(ti)
Type: ASCII string
Description: This parameter is identical to the time parameter
used in the MGCP Line Package Caller-id event [11]. 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").
number(nu)
Type: UTF-8 encoded ASCII character string
Description: This parameter is identical to the number parameter
used in the MGCP Line Package Caller-id event [11]. 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.
A "P" in the number field is used to indicate a private number.
An "O" is used to indicate an unavailable number. A "C" is used
to indicate the number belongs to a Coin phone. An "S" is used
to indicate the number is not available due to a service
interaction. This field MAY contain other letters to provide
additional clarification as per provider or vendor
specifications.
name (na)
Type: UTF-8 encoded ASCII character string
Description: This parameter is identical to the name parameter
used in the MGCP Line Package Caller-id event [11]. 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).
Sassenberg Expires - January 2005 [Page 7]
Extended MGCP Line Packages July 2004
A "P" in the name field is used to indicate a private name.
An "O" is used to indicate an unavailable name. This field MAY
contain other letters to provide additional clarification as per
provider or vendor specifications.
call qualifier (cq)
Type: UTF-8 encoded ASCII character string
Description: This parameter aligns with the Call Qualifier Parm
in the Bellcore MDMF format [6] and ETSI Call Setup Message [3]
for data transfer to a phone set. The 'cq' parameter is coded as
a string of ASCII characters that identify the call qualifier.
For example, this parameter could contain an "L" conveying the
Long Distance Indicator is set for the call and allowing the
phone to display that info in an appropriate manner. White
spaces are permitted if the string is quoted. If a quoted-string
is provided, the string itself is UTF-8 encoded (RFC 2279).
nature of address (noa)
Type: integer - decimal value
Possible values: 0..127
Description: This parameter is commonly sent as the Additional
Info Parm in the Bellcore MDMF format [4] for data transfer to
the phone. This 'noa' parameter is coded as an integer value
which represents an enumerated type defined in ITU-T Q.763 [7].
numbering plan indicator (npi)
Type: integer - decimal value
Possible values: 0..7
Description: This parameter is commonly sent as the Additional
Info Parm in the Bellcore MDMF format [4] for data transfer to
the phone. This 'npi' parameter is coded as an integer value
which represents an enumerated type defined in ITU-T Q.763 [7].
network provider identity (netid)
Type: UTF-8 encoded ASCII character string
Description: This parameter displays the current Network
Provider. White spaces are permitted if the string is quoted. If
a quoted-string is provided, the string itself is UTF-8 encoded
(RFC 2279).
redirecting number (rnu)
Type: UTF-8 encoded ASCII character string
Description: The 'rnu' parameter is coded as an ASCII character
string of decimal digits that identify the redirecting 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).
Sassenberg Expires - January 2005 [Page 8]
Extended MGCP Line Packages July 2004
A "P" in this parameter is used to indicate a private number.
An "O" is used to indicate an unavailable number. A "C" is used
to indicate the number belongs to a Coin phone. An "S" is used
to indicate the number is not available due to a service
interaction. This field MAY contain other letters to provide
additional clarification as per provider or vendor
specifications.
Type of Forward Call (fctype)
Type: three-digit decimal value
Possible values: 0..255
Description: This data is commonly sent to the phone set in the
ETSI Call Setup Message, and is defined in ETSI 659-3 [3] as the
Type of Forward Call.
Type of Calling User (user)
Type: three-digit decimal value
Possible values: 0..255
Description: This data is commonly sent to the phone set in the
ETSI Call Setup Message, and is defined in ETSI 659-3 [3] as the
Type of Calling User.
For example, the following signal indicates, that the current call
time is April 1 at 1:55 PM. The caller is "John Doe" and his number
is 555-1234. This is a long distance call, from a Subscriber number,
using the Data Numbering Plan. This call was redirected, and the
redirecting number is 555-1222. The user is calling from a mobile
phone. Notice how the Type of Forward Call field is blank.
XAL/xci(04/01/13/55, "555 1234", "John Doe", "L", 3, 1,"555 1222', ,4)
As another example, the following signal indicates the current call
time is April 1 at 1:55. The caller is calling from a coin phone and
the name is not available.
XAL/xci(04/01/13/55, "C", "O" , , , , , , , )
The events are defined as follows:
Operation Complete (oc):
Apply the standard definition of operation complete [1].
Operation Failure (of):
Apply the standard definition of operation failure [1].
2.2 Business Tone Package
Package name: BIZ
Version: 0
Sassenberg Expires - January 2005 [Page 9]
Extended MGCP Line Packages July 2004
The signals in this package are similar, from a syntactical and
telephony perspective, to the "Business tone generation package"
(biztn) defined in ITU-T Q.1950 [12].
------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|------------------------------------------------------------|
| erwt | Expensive Route Warning | | BR |
| ofq | Offhook Queueing | | BR |
| ddt | Distinctive Dial tone | | TO 16 sec. |
| idt | Internal Dial tone | | TO 16 sec. |
------------------------------------------------------------
The signals defined in this package are as follows:
Expensive Route Warning (erwt) :
This signal generates an expensive route warning tone,
indicating the call has been routed over a route that has a
higher cost than a data filled threshold.
Off-hook Queueing Tone (ofq) :
This signal generates an off-hook queuing tone, indicating the
call is awaiting network resources.
Distinctive Dial Tone (ddt) :
This signal indicates the subscriber is dialing internally to
the business group. After dialing the public access code,
distinctive dial tone is typically replaced by standard dial
tone. The duration of this tone should be provisionable on the
gateway.
Internal Dial Tone (idt) :
This signal indicates the subscriber is dialing on a Private
Branch Exchange (PBX), and corresponds to the "PABX Internal
Dial Tone" as defined in ITU-T Recommendation E.182 [8]. The
duration of this tone should be provisionable on the gateway.
The events are defined as follows:
Operation Complete (oc):
Apply the standard definition of operation complete [1].
Operation Failure (of):
Apply the standard definition of operation failure [1].
2.3 Carrier Package
Sassenberg Expires - January 2005 [Page 10]
Extended MGCP Line Packages July 2004
Package Name: CARR
Version: 0
The signals in this package are similar, from a syntactical and
telephony perspective, to those defined in ITU-T H248.27 [14] for the
H.248 gateway control protocol.
--------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|--------------------------------------------------------------|
| cdt | Carrier dial tone | | BR |
| ans | Carrier answer tone | | BR |
| chg | Carrier charging tone | | BR |
| ldi | Long distance indicator tone | | BR |
--------------------------------------------------------------
The signals are defined as follows:
Carrier dial tone (cdt):
This generates a carrier dial tone, indicating that a carrier
other than the default is providing service for the call.
Carrier answer tone (ans):
This generates a carrier answer tone, also known as tone burst
on answer, indicating that a carrier other than the default is
providing service for the call.
Carrier charging tone (chg):
This generates a carrier charging tone, also known as subscriber
trunk dialing tone, indicating that a subscriber has dialed a
trunk call, and charging is about to start.
Long distance indicator tone (ldi):
This generates a long distance indicator tone, indicating that
the call is a long-distance connection.
2.4 Intrusion Package
Package Name: INT
Version: 0
The signals in this package are similar to those defined in ITU-T
Q.1950 [12]. These signals are used by operator-based telephony
services and all reflect some sort of barge-in or intrusion. Notice
each of these signals MAY be generated on a connection, if requested
in the appropriate format defined in the MGCP RFC [1].
-----------------------------------------------------------
|Symbol | Definition | R | S Duration |
Sassenberg Expires - January 2005 [Page 11]
Extended MGCP Line Packages July 2004
|-----------------------------------------------------------|
|pend | Intrusion Pending Tone | | BR C |
|int | Intrusion Tone | | BR C |
|rem | Intrusion Reminder Tone | | BR C |
|tbi | Toll Break-In Tone | | BR C |
|intq | Intrusion Queue Tone | | BR C |
|bv | Busy Verification Tone | | BR C |
------------------------------------------------------------
The signals are defined as follows:
Intrusion Pending Tone (pend):
This signal is commonly known as cut-in tone, and indicates a
third party is intending to break into the call.
Intrusion Tone (int):
This signal is commonly known as barge-in tone or operator
intervening tone, indicating a third party is breaking into the
call. Intrusion tone corresponds to "Intrusion Tone" as defined
in ITU-T Recommendation E.182 [8].
Intrusion Reminder Tone (rem):
This tone is also known as attendant camp-on tone, and indicates
a third party remains broken into the call.
Toll Break-In Tone (tbi):
This tone indicates a third party is breaking into a toll call.
Intrusion Queue Tone (intq):
This tone is commonly known as trunk queue tone and indicates a
line is already under observation by another operator.
Busy Verification Tone (bv):
This tone is also known as busy operator tone, and indicates to
an operator that a line is engaged in an active call.
2.5 Display Package
Package Name: DISP
Version: 0
The signals in this package are derived from the "Analog Display
Signaling Package" (ANDISP) defined in ITU-T H248.23 [15].
The signals in this package allow a Call Agent to convey the display
data in a similar format which the gateway sends to the phone set.
For example, these signals can be used for Calling Name and/or Number
Identification. They can be used to convey display data defined in
Sassenberg Expires - January 2005 [Page 12]
Extended MGCP Line Packages July 2004
many telephony standards for many regions. For example, in North
America, this would be the SDMF or MDMF construct, including the
checksum. This package provides an alternative to the Caller-id
events defined in the MGCP Basic Line Package [11] and the Extended
Analog Line (XAL) Package defined in this document. It avoids heavy
parsing of the Display Data block by conveying the data as a big-
endian encoded hex string.
----------------------------------------------------------
|Symbol | Definition | R | S Duration |
|----------------------------------------------------------|
|data | Data Display | | BR |
|dwa | Data Display | | BR |
-----------------------------------------------------------
The signals are defined as follows:
Data Display ( data(hex string, tas) ) :
This signal indicates the gateway should send the data to the
phone set. If there is an error while sending the data the
gateway should proceed as if the signal was never requested, but
the remainder of the command is valid (i.e. no error occurred).
The following parameters accompany the data signal:
Display Data:
Type: Hex octet string
Description: see above.
Default value: empty
Terminal Alerting Signal (tas):
Type: enumerated ASCII and should not be quoted.
Possible values:
dt - Dual Tone Alerting Signal (DT-AS)
rp - Ringing Pulse Alerting Signal (RP-AS)
lr - Line reversal followed by DT-AS
nt - no TAS
Default value: no TAS
Description: The TAS parameter indicates what type of signal
should be used to alert the phone set the data is coming. In the
off hook signaling case, the TAS parameter should specify DT-AS
(dt) or no TAS (nt). Use of the RP-AS (rp) or lr values in the
off hook case MUST be treated as if dt were signaled and MUST
not generate an error.
Display while Alerting (dwa (hex string)):
This signal indicates the gateway should send the data along
with the accompanied alerting signal. It is considered an error
to send this signal when it is not accompanied by an altering
Sassenberg Expires - January 2005 [Page 13]
Extended MGCP Line Packages July 2004
signal (i.e. ringing, call waiting). In that scenario, the
gateway MUST NACK 513, indicating the gateway is not equipped to
generate the signal [1]. If there is an error in the display
data, i.e the checksum, or there is no display data, the gateway
MUST proceed as if the display data were never requested.
The following parameter accompanies the dwa signal:
Display Data:
Type: Hex octet string
Description: see above.
Default value: empty
For example, applying the rules of ETSI 659-3 [3], this call was
made on December 09, at 2:54 PM from number (919)555-1234. The name
is unavailable. The accompanying alerting signal is the MGCP Line
Package [11] ringing.
S:DISP/dwa(802201083132303931343534020A3931393535353132333408014F34A),
L/rg
2.6 Test Package
Package Name: TEST
Version: 0
The signals in this package are similar to the Test package defined
in ITU-T H248.27 [14] for the H.248 gateway control protocol.
Telephony providers may use these signals for diagnostic purposes.
The use and characteristics of the tones associated with each signal
varies depending on the region and/or provider. Notice how each of
these signals MAY be generated on a connection using the appropriate
format defined in [1].
-------------------------------------------------------
|Symbol | Definition | R | S Duration |
|-------------------------------------------------------|
|low | Low tone | | BR C |
|high | High tone | | BR C |
|loud | Loud Tone | | BR C |
|faint | Faint Tone | | BR C |
|slow | Slow Interrupted Tone | | BR C |
|fast | Fast Interrupted Tone | | BR C |
-------------------------------------------------------
The signals are defined as follows:
Low Tone (low):
This generates a low tone.
Sassenberg Expires - January 2005 [Page 14]
Extended MGCP Line Packages July 2004
High Tone (high):
This generates a high tone.
Loud Tone (loud):
This generates a loud tone.
Faint Tone (faint):
This generates a faint tone.
Slow Tone (slow):
This generates a slow interrupted tone.
Fast Tone (fast):
This generates a fast interrupted tone.
2.7 Metering Package
Package Name: AM
Version: 0
The signals and events in this package are similar to the Automatic
Metering (AMET) package defined in ITU-T H248.26 [13] for the H.248
gateway control protocol. In addition, they are similar to the
Automatic Metering (AM) package defined in Appendix F of ETSI TS 101
909-4 [9].
This package supports the automated application of repetitive
metering pulses to an analog line. It provides a means of
verification for the number of metering pulses applied to the line.
This package assumes that pulse characteristics, such as type,
duration and pause, are provisioned on the gateway.
In order for a gateway to support this package, it MUST store two
integers with values of zero to 4294967295 (4 bytes), defined as
follows.
The "pulse count since last report" represents the number of
metering pulses that have been applied on a line since the last
meter report event. The recognition of the periodic report event
(as defined in this package - AM/pr) and generation of a
corresponding notification resets this value to zero.
The "total pulse count" represents the number of metering pulses
that have been applied on a line since the application of the
Enable Metering (AM/em) signal, as defined in this package. This
value is reset to zero each time the AM/em signal is started. The
gateway SHALL not reset the "total pulse count" if the Call Agent
Sassenberg Expires - January 2005 [Page 15]
Extended MGCP Line Packages July 2004
re-applies the signal, while it is already playing or "on". The
gateway SHALL not reset the "total pulse count" if the Call Agent
stops or cancels the AM/em signal.
A gateway SHALL only calculate these values if the Call Agent has
requested it observe or detect the Periodic Report (AM/pr) event.
--------------------------------------------------------
| Symbol | Definition | R | S Duration |
|--------------------------------------------------------|
| pr | Periodic report | X S | |
| em | Enable Metering | | OO |
| mpb | Metering Pulse Burst | | BR |
--------------------------------------------------------
The following events are defined in the Metering Package:
Periodic report (pr (rpc, tpc)):
This event is used in conjunction with the Enable Metering
(AM/em) signal defined in this package. The event is detected
when the value of "pulse count since last report" reaches the
value specified in the "report pulse count" (rpc) parameter.
A gateway SHALL not detect this event when the application of
AM/em is stopped due to a failure, an explicit command cancels
the signal, or the Call Agent request did not specify a report
pulse count. In those cases, the number of "pulses since last
report" has not or will not reach the specified "report pulse
count"; therefore, the event is not detected.
This event can be audited. If the Call Agent has requested the
AM/pr event and audits EventStates, the gateway SHALL include
the AM/pr event in the EventState parameter of the Audit
response, as defined in [1]. The gateway SHALL respond with both
the "report pulse count" and "total pulse count" parameter
values.
The following parameters MAY accompany the Periodic Report event.
The ordering of these parameters SHALL not be interchanged. If one
of these parameters is not specified, it MUST be blank and
delineated with commas.
Report Pulse Count (rpc)
Type: integer
Possible values: (0..4294967295)
Default value: infinite
Description: When the AM/pr event is requested, this parameter
specifies the period of metering reports in terms of pulse
Sassenberg Expires - January 2005 [Page 16]
Extended MGCP Line Packages July 2004
counts. When the AM/pr event is Observed or Audited, this
parameter specifies the "pulse count since last report". If this
value is not specified upon request, the gateway SHALL not
detect the event. This may be useful to a Call Agent which is
only interested in auditing the pulse counts. In that scenario,
the calculated values of "pulse count since last report" and
"total pulse count" will be equal.
Total Pulse Count (tpc)
Type: integer
Possible values: (0..4294967295)
Default value: none
Description: When the AM/pr event is Observed or Audited, this
parameter MUST specify the "total pulse count" value stored in
the gateway. This parameter SHALL not be included when the AM/pr
event is requested. If this parameter is specified in a
requested AM/pr event, it SHALL not generate an error, rather it
SHOULD be ignored.
The following signals are defined in the Metering Package:
Enable Metering (em(pr)):
This signal is used to generate a regular, time-based call
charge. It starts the automatic generation of metering pulses on
the line. If the gateway is scanning for AM/pr, it marks the
beginning of the "total pulse count" and "pulse count since last
report". Only one enable metering signal SHOULD be active at any
given time. If a new AM/em signal is requested, it SHALL replace
any currently active (on) AM/em signal. A new application of the
signal SHALL not reset the "total pulse count" or " pulse count
since last report ". It is considered an error to try and play
AM/em 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). If a line goes on hook while AM/em is on, the gateway
SHOULD disable metering pulses.
The following parameters MAY accompany this signal.
Pulse Repetition Interval (pr)
Type: Integer
Possible values: greater than zero
Default value: 1,000
Description: This parameter specifies the interval between
metering pulses on the line. It represents the time that SHOULD
elapse between the leading edge of a pulse and the leading edge
of the succeeding pulse.
Sassenberg Expires - January 2005 [Page 17]
Extended MGCP Line Packages July 2004
The following example of this signal requests the gateway to
continuously generate metering pulses at 10 milliseconds
intervals.
S: em(10)
Metering pulse burst (mpb(pc)):
This signal applies a fixed number of metering pulses to the
line. It is considered an error to try and play AM/mpb 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).
Because this is a brief signal that can have a long duration,
both the Call Agent and the gateway must be wary of the rules
defined in [1] for Brief signals and ensure this signal is not
prematurely stopped. All pulses, specified in the pulse count,
SHALL be completed even if the end user goes on hook during the
burst.
The following parameters can accompany this signal.
Pulse Count (pc)
Type: Integer
Possible values: greater than zero
Default value: 1
Description: This parameter specifies the number of metering
pulses to be applied to the line. The type, duration and pulse
repetition interval for the metering pulses comprising the burst
are provisioned in the gateway.
Pulse Repetition Interval (pr)
Type: Integer, specified in units of milliseconds.
Possible values: greater than zero
Default value: 1,000 ms
Description: This parameter specifies the interval between
metering pulses on the line. It represents the time that SHOULD
elapse between the leading edge of a pulse and the leading edge
of the succeeding pulse.
In this example, the gateway is expected to send a burst of 20
pulses with 10 milliseconds in between each pulse.
S: AM/mpb(20, 10)
The following are examples of how a Call Agent may use this package
to apply metering to an analog line and audit the pulses without
periodic notification.
First, if the Call Agent required the gateway to count the
pulses generated by the AM/em signal, but is not interested in a
Sassenberg Expires - January 2005 [Page 18]
Extended MGCP Line Packages July 2004
periodic report, the Call Agent may request the event without
including the rpc parameter. Here, the gateway will reset the
values of "total pulse count" and "report count since last
report", and start counting and generating pulses at 5
milliseconds.
RQNT 9832 aaln/1@someGW.com MGCP 1.0
X: 9482
R: AM/pr, L/hu(N)
S: AM/em(5)
Q: loop
Next, if the Call Agent were to audit the EventStates, at some
time after the above request, the gateway SHOULD respond with
the calculated pulse count totals. In this example, the
gateway's "pulse count since last report" and "total pulse
count" values are both 500.
200 82983 OK
ES: AM/pr(500,500)
In the following example, the Call Agent is interested in periodic
notification.
First the Call Agent requests the Periodic Report event and
wishes to be notified every 50 pulses.
RQNT 9832 aaln/1@someGW.com MGCP 1.0
X: 9482
R: AM/pr(50), L/hu(N)
S: AM/em(5)
Q: loop
If the gateway has already been counting and generating pulses,
and the "pulse count since last report" already exceeds 50, it
SHALL immediately generate the event, specifying the stored
values of "pulse count since last report" and "total pulse
count". In this instance, the observed Pulse Count (pc)
parameter may likely be different from the requested Pulse Count
(pc) parameter.
If this is the first request for the event, the gateway will
reset its "pulse count since last report" and "total pulse
count" values, and start counting and generating pulses.
In this example, the gateway observes the event for the second
instance.
NTFY 9283 aaln/1@someGW.com MGCP 1.0
Sassenberg Expires - January 2005 [Page 19]
Extended MGCP Line Packages July 2004
X: 9482
O: AM/pr(50, 100)
If the AM/em signal is not applied at the time of an EventStates
audit, but the gateway was requested to detect the AM/pr event, the
gateway SHALL respond with zero value, indicating there are no
pulses.
200 283 OK
ES: AM/pr (0,0)
3. IANA Considerations
The following packages must be registered with IANA before this
document becomes an Informational RFC.
Package Title Name Version
------------- ---- -------
Extended Analog Line XAL 0
Business Set Package BIZ 0
Carrier Package CARR 0
Intrusion Package INT 0
Display Package DISP 0
Test Package TEST 0
Automatic Metering AM 0
4. Security Considerations
The MGCP packages contained in this document do not require any
further security considerations beyond those indicated in the base
MGCP specification [1].
5. Acknowledgements
Special thanks to the authors of the Basic Media Gateway Control
Protocol (MGCP) Packages RFC3660: Bill Foster and Flemming Andreasen.
Wording for this document was often copied directly from RFC3660, as
it applies to these packages.
In addition, special thanks to authors of the various ITU-T Megaco
(H.248) packages from which these packages, events and signals are
based; including but not limited to Kevin Boyle and Michael Brown.
Wording for this document was often copied directly from the
referenced ITU-T Specifications, which define gateway control
protocol packages.
Sassenberg Expires - January 2005 [Page 20]
Extended MGCP Line Packages July 2004
Finally, thanks to Martin Wakley for the definition of the Line
Reversal event, and Graeme Currie for reviewing the document.
6. References
6.1 Normative References
[1] F. Andreasen, B. Foster, "Media Gateway Control Protocol (MGCP)
Version 1.0", RFC 3435, January 2003
[2] NTT Telephone Service Interfaces, Edition 5
[3] ETSI EN 300 659-3 V1.3.1, "Subscriber line protocol over the
local loop for display (and related) services", September 2000
[4] Bellcore, "LSSGR: Voiceband Data Transmission Interface Section
6.6" GR-30-CORE, Issue 2, December 1998
[5] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number
Delivery (FSD 01-02-1051)" GR-31-CORE, Issue 1, June 2000
[6] Bellcore Digest (Notice to the Industry), "Message Type Values
for SDMF and MDMF", May 1996
[7] ITU-T, "Signaling System No. 7 - ISDN user part formats and
codes" Q.763, December 1999
[8] ITU-T, "Application of tones and recorded announcements in
telephone service", E.182, March 1998
[9] ETSI, "IP Multimedia Time Critical Services", ETSI TS 101 909-4,
May 2004
[10] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14 RFC 2119, March 1997
6.2 Informative References
[11] B. Foster, F. Andreasen, "Basic MGCP Packages (MGCP) Version
1.0", RFC 3660, February 2003
[12] ITU-T, "Bearer independent call bearer control protocol"
Q.1950, December 2002
[13] ITU-T, "Gateway control protocol: Enhanced analog lines
packages" h248.26, July 2003
[14] ITU-T, "Gateway control protocol: Supplemental tones packages"
h248.27, July 2003
Sassenberg Expires - January 2005 [Page 21]
Extended MGCP Line Packages July 2004
[15] ITU-T, "Gateway control protocol: Enhanced altering packages"
h248.23, July 2003
7. Author's Address
Tania Sassenberg
Nortel Networks
35 Davis Drive
Research Triangle Park, NC 27709
Email: tsassenberg @ nortel networks . com
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. This
document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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."
Sassenberg Expires - January 2005 [Page 22]
