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 | | ------------------------------------------------------------- Changes in event types: "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  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 .
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  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  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 firstname.lastname@example.org 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 email@example.com 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 . Operation failure (of): This is the standard definition of operation failure . 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 firstname.lastname@example.org 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 email@example.com 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 , 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 The "RES" package provides local connection option support for resource reservations as well as an event to indicate reservation loss. A number of LocalConnectionOption parameters are used in doing resource reservations: "reservation request", "reservation direction", "reservation confirmation" and "resource sharing". Reservation Request LocalConnectionOption: The gateways can be instructed to perform a reservation on a given connection using RSVP. When a reservation is needed, the Call Agent will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service". The absence of reservation can be indicated by asking for the "best effort" service, which is the default value for this parameter. Whether or not RSVP will be done is dependent on whether the reservation request LocalConnectionOption parameter has been included in a connection request for this connection (with either "controlled load" or "guaranteed service" indicated). If a modify connection
(MDCX) request requires a change in the reservation and the "reservation request" parameter is not included in the LocalConnectionOptions, but was included in the LocalConnectionOptions for a previous connection request for that connection, then the "reservation request" value defaults to its previously saved value for that connection. If a modify connection (MDCX) request explicitly contains a "reservation request", indicating a request for "best effort" for a connection that has an existing reservation, the existing reservation will be torn down. Reservation Direction LocalConnectionOption: When reservation has been requested on a connection, the gateway will examine the reservation direction LocalConnectionOption parameter to determine the direction that the reservations require and do 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 reservation direction defaults to the previously saved value of the reservation direction parameter for that connection. If there was no previous reservation direction parameter for that connection, the value is deduced from the connection mode. That is: * 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: Another LocalConnectionOption parameter for RSVP reservations is the reservation confirmation parameter, which determines what the resource reservation pre-condition (see ) is for acknowledging a successful connection request:
* If the reservation confirmation parameter is set to "none", the gateway will "Ack" the connection request without waiting for reservation completion. This is the default behavior. * If the "reservation confirmation" parameter is set to "send-only", the gateway will "Ack" when the PATH message has been sent and the corresponding RESV is received to indicate successful reservation in the send direction. * If the "reservation confirmation" parameter is set to "receive-only", the gateway will "Ack" when 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 corresponding RESV has been received for send direction, and reservation confirm has been received for the receive direction. Note that: Values "receive-only" and "send-receive" are triggers for the gateway to request reservation confirm (RESVCONF) when it sends out the RESV. Pre-conditions SHOULD only be added for the direction(s) for which resource reservations have been requested. If a direction is added as a pre-condition, and that direction was not requested in the resource reservation, the direction MUST simply be ignored as a pre-condition. In this approach, resource reservation success is the pre- condition to final acknowledgement of the connection request. If the reservation fails, the connection request also fails (error code 404 - insufficient bandwidth) - as will any other part of the transaction, e.g., a notification request included as part of the connection request. A typical example of this would be a request to ring the phone and look for off-hook, included with the connection request. If the reservation fails, the phone will not ring. Similarly, if the phone is already off-hook, the command fails and there will be no resource reservation. A provisional response SHOULD be provided if confirmation is expected to occur outside the normal retry timers and in fact a provisional response MUST be provided if the reservation confirmation parameter has value "send-receive" (without a provisional response, SDP information cannot be returned until the
final "Ack" which will not occur until the reservation is complete. This can result in a deadlock since the SDP information typically needs to be passed to the other end in order for it to initiate the RSVP PATH message in the other direction). The SDP information and connectionID MUST be included in both the provisional response and the final response. Note that in order to ensure rapid detection of a lost final response, final responses issued after provisional responses for a transaction SHALL be acknowledged, i.e., they SHALL include an empty "ResponseAck" parameter in the final response (see ). If the transaction time is outside the expected bounds (time T-HIST - see the section on provisional responses in ), error code 406 (transaction timeout) SHOULD be returned. Also note that if the reservation confirmation parameter is omitted, the value of the reservation confirmation parameter defaults to its previously saved value. If there is no previously saved value for the reservation confirmation parameter, or the reservation confirmation parameter has the value "none", then successful resource reservation is not a pre-condition to providing an acknowledgement to the connection request (i.e., the gateway can "Ack" right away without waiting for the reservation to complete and a provisional response will not be necessary). Resource Sharing LocalConnectionOption: It may be possible to share network resources across multiple connections. An example is a call-waiting scenario, where only one connection will ever be active at a time. In a 3-way calling scenario with a similar set of connections, sharing is not possible. Only the Call Agent knows what may be possible, depending on the feature that is being invoked. In order to allow the Call Agent to indicate that sharing is possible, a resource sharing LocalConnectionOption parameter is introduced. This parameter can have one of the following values: * A value "$" can be specified where $ refers to "this connection". This value is used when doing a create connection and indicates the intent to share resources with this connection. * A connection ID can be specified which indicates that this is a request to share resources with the connection having this connection ID (allowing multiple connections to share resources with the connection indicated).
* The value can be empty, which indicates a request to no longer share the resources of this connection with other connections. In the case of a CRCX, the default value for the resource sharing local connection option is empty, and for an MDCX, the default value is its current value. The RSVP filters will be deduced from the characteristics of the connection. The RSVP resource profiles will be deduced from the connection's bandwidth and packetization period. Note that if RSVP is used with PacketCable Dynamic Quality of Service , then the parameters in NCS  would be used instead of the reservation direction, confirmation and reservation sharing parameters described here. 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 value "g" (guaranteed service), "cl" (controlled load) or "be" (best effort). * The reservation direction parameter, encoded as the keyword "r-dir" followed by a colon and the value "sendonly", "recvonly" or "sendrecv". * The reservation confirmation parameter, encoded as the keyword "r-cnf" followed by a colon and the value "none", "sendonly", "recvonly" or "sendrecv". * The resource sharing parameter, encoded as the keyword "r-sh" followed 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 Note that normally local connection options that are associated with a package have the package prefix included as per the package extension rules in . The local connection options in the "RES" package are exceptions. The package prefix is not included in the case of the "RES" package because it was created before the extension rules in  were defined. 2.11.3. Events The following events are included as part of the resource reservation package: ------------------------------------------------------ | Symbol | Definition | R | S Duration | |------------------------------------------------------| | re | Resource Error | C | | | rl | Resource Lost | C | | ------------------------------------------------------ Resource Error (re): This is an indication that an error in the resource reservation occurred during the life of the connection. This event is not requested with a parameter, but is reported with a parameter (see possible values below). This event may or may not indicate the permanent loss of the reservation (i.e., any error associated with the reservation whether permanent or temporary will be reported). If requested on an endpoint (without specifying the connection ID), the request refers to all present and future connections on that endpoint. When reported, the connectionID is always supplied along with a reason for the error indicated as a parameter. One of the following possible reasons for loss 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" In addition to a parameter indicating one of the reasons above, additional information on the type of error MAY be included as a second parameter in the form of a quoted string.
Example report might include: 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 occurs while a resource reservation is initially being set up (i.e., the event was only reported as a result of an error that occurred after the reservation was set up). Resource Lost (rl): Loss of reservation during the life of a connection can be reported by using the "rl" event. This event is not requested with a parameter, but is reported with a parameter (see below for possible values). If requested on an endpoint (without specifying the connection ID), the request refers to all present and future connections on that endpoint. When reported, the connectionID is always supplied along with a reason for the loss indicated as a parameter. One of the following possible reasons for loss 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" In addition to a parameter indicating one of the reasons above, additional information on the type of error MAY be included as a second parameter in the form of a quoted string. Example report might include: O: res/rl@0A3F58(ResvTear) or O: res/rl@0A3F58(ResvTear, "some other commentary")
Note that this event will not be reported if an error occurs while a resource reservation is initially being set up (i.e., the event is only reported if the reservation was lost after it was initially 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 | | --------------------------------------------------------------- Changes from the previous version: change to conform to standard reporting of operation failure and operation complete events. The announcement signal is qualified by a URL name: S: ann(http://scripts.example.net/all-lines-busy.au) The URL name MAY be followed by a list of initial parameters, separated by commas. However, standard parameters are not included as part of this package definition (Note: use of additional parameters is optional and would result in a proprietary interface). The gateway SHOULD support one or more standard URL schemes such as: * file, http, ftp (RFC 1738 ), 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 ), which in this case allows the media gateway to directly initiate playing of the announcement via an RTSP server. The pre-condition for a successful response (return code of "200") is correct syntax and capability (support is available for this request). Standard MGCP return codes apply in the case of failure. Further indications of failure are provided 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 cannot be played out for a reason determined after a successful response to the request has been provided, an operation failure event will be returned. The failure MAY be explained by some commentary (in the form of a quoted string), as in: O: a/of(a/ann,"file not found") The "operation complete" event will be detected when the announcement is 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 | ----------------------------------------------------------------- Changes from the previous version of the package: "vxml" was added as a language type for loading and running VXML documents; change to conform with standard reporting of operation failure and operation complete events; addition of "ir" event. The current definition defines keywords for the most common languages. More languages may be defined in later versions of this package. The "signal" specifying the scripting language is parameterized with a URL indicating the location of the script. The URL parameter MAY be optionally followed by a comma-separated list of arguments as initial parameters to use in running the script. URL schemes may include file ftp, or http schemes with syntax according to RFC 2396 . As an example: S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2, ...,argn)
The argument list "arg1,arg2,...,argn" is passed to the script/document as a list of initial parameters. The pre-condition for a successful response (return code of "200") is correct syntax and capability (support is available for this request). Standard MGCP return codes apply in the case of failure. Some further (non-application/script specific) failure indications MAY be provided in the operation failure event as a comment in the form of a quoted string following the name of the failed event. Example O: script/of(script/vxml,"file not found") The script produces an output, which consists of one or several text strings, separated by commas. This provides the return-status of the script as well as return parameters (if there are any) O: script/oc(script/vxml,return-status=<status>, name1=value1,name2=value2,...) where <status> can have one of the values "success" or "failure". This is then followed by 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 which case, the MGCP syntax requirements require that the action be specified (e.g., "R: ir(N)(nam1=value1,name2=value2,..)"). If the Call Agent requests "ir" as a signal, at least one parameter MUST be provided.
When requesting the "ir" signal, the Call Agent MUST also repeat the original script signal. This is in order to be consistent with the semantics of TO signals in MGCP (i.e., if the original "script" signal is not included, then the signal/script will be stopped). The only problem with this is that there is a possible race condition in which a request to send an "ir" signal could occur just as the script stopped. In order to avoid this confusion, the following is RECOMMENDED: when the script signal is included with an "ir" signal, include a parameter (of the script signal) to indicate that this is not a new instance of the script i.e., if there is no script executing at the present time do not start executing a new one. The "ir" signal is only associated with an executing script. If none are running when a request for the event/signal is made, or if a new script request is not included with the request, then the "ir" signal/event will not be executed (i.e., the "ir" event with its parameters is passed to an existing script for parsing and execution and is considered opaque as far as MGCP as concerned. If no such script exists, response code "800" will be returned, indicating that the script is not 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. Note that package specific error codes include the package name following the error code. For example, if error code 800 occurs in response to a request with a transaction ID of 1001, it would be sent as: 800 1001 /SCRIPT
3. IANA Considerations The following packages and their versions have been registered with IANA as per the instructions in . 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 1 The following extension digit map letter has been registered with IANA: Package Letter ------- ------ DM1 P The following Local Connections have been registered with IANA: Field Name ------- ----- Media Format fmtp Reservation Confirmation r-cnf Reservation Direction r-dir Resource Sharing r-sh 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 . 5. Acknowledgements Special thanks are due to the authors of the original MGCP 1.0 specification: Mauricio Arango, Andrew Dugan, Isaac Elliott, Christian Huitema, and Scott Picket.
Thanks also to the reviewers of this document, including but not limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing, Cisco Systems; Ed Guy, EMC Software; Martin Wakley, Nortel Networks. 6. References 6.1. Normative References  Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.  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.  ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724, November 1988.  ANSI, "OAM&P - Terminating Test Line Access and Capabilities", T1.207-2000.  Bellcore, "Notes on the Network", Special Report SR-2275, Issue 3, December 1997.  Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997.  Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE, Issue 1, June 1996.  ITU-T, "Technical Characteristics of Tones for the Telephone Service", ITU-T E.180, March 1998.  ITU-T, "Various Tones Used in National Networks", ITU-T E.180, Supplement 2, January 1994.  ITU-T, "Applications of Tones and Recorded Announcements in Telephone Services", ITU-T E.182, March 1998.  Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586, Issue 1, June 2000.  Bellcore, "CPE Compatibility Considerations for the Voiceband Data Transmission Interface", SR-TSV-002476, December 1992.  Bellcore, "LSSGR: Visual Message Waiting Indicator Generic Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000.
 Bellcore, "LSSGR Voiceband Data Transmission Interface", Section 6.6, GR-30-CORE, Issue 02, December 1998.  Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.  Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue 01, June 2000.  Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR- 531-CORE, Issue 1, June 2000.  Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000.  Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.  Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR- 220, Issue 2, April 2002.  ITU-T, "Procedure for document facsimile transmission in the general switched telephone network", ITU-T T.30, April 1999.  ITU-T, "300 bits per second duplex modem standardized for use in the general switched telephone network", ITU-T V.21, November 1988.  Telcordia Technologies, "Telcordia Technologies Specification of Signaling System Number 7", GR-246-CORE, Issue 7, December 2002.  Telcordia Technologies, "LSSGR: CLASS Feature: Calling Name Delivery Generic Requirements (FSD 01-02-1070)", GR-1188, Issue 02, December 2000.  Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000.  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.  Berners-Lee, T., Masinter, L. and M. McCahill, Eds., "Uniform Resource Locators (URL)", RFC 1738, December 1994.
 Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References  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.  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.  Foster, B., "MGCP CAS Packages", RFC 3064, February 2001.  PacketCableTM, Dynamic Quality if Service Specification, http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07- 030815.pdf  PacketCableTM Network-Based Call Signaling Protocol http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08- 030728.pdf  Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Eds., "Gateway Control Protocol Version 1", RFC 3525, June 2003.  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: firstname.lastname@example.org Flemming Andreasen Cisco Systems Edison, NJ 08837 EMail: email@example.com
8. 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.