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]