As per Relevance of the word february, we have this rfc below:
Network Working Group B.
Request for Comments: 3064 Cisco
Category: Informational February 2001
MGCP CAS
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document contains a collection of media gateway
Associated Signaling (CAS) packages for R1 CAS, North American CAS
CAS PBX interconnect as well as basic FXO support. Included are
packages. The "MS" package covers MF single stage dialing trunks
This includes wink start and immediate start PBX DID/DOD trunks
well as basic R1 and Feature Group D (FGD) Terminating protocol [3].
The "DT "package covers immediate start and basic DTMF and dial-
trunks and the "BL" package covers the interface to a basic
(digital or FXS interface). In addition to the Terminating protocol
there are three other FGD protocols described in [3]. These
EAIN and EANA which is covered by the enclosed "MD" package and
Operator Service Signaling protocol which is handled by the "MO
package. Support for basic FXO interconnect is provided by "DO
package
Conventions used in this
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC-2119.
IESG Note
This document is being published for the information of
community. It describes a protocol that is currently being
in a number of products. Implementers should be aware
developments in the IETF Megaco Working Group and ITU SG16 who
currently working on a potential successor to this protocol
Foster Informational [Page 1]
RFC 3064 MGCP CAS Packages February 2001
Table of
1.0.Introduction ................................................ 3
1.1. Functional Partitioning .................................... 3
1.2. CAS Trunk Types ............................................ 4
1.2.1. "MS" Package ............................................. 5
1.2.2. "DT" Package ............................................. 5
1.2.3. "BL" Package ............................................. 6
1.2.4. "DO" Package ............................................. 6
1.2.5. "MD" Package ............................................. 6
1.2.6. "MO" Package ............................................. 7
2.0. Event Packages ............................................. 7
2.1. Events and Signals for the "MS" package .................... 9
2.2. Events and Signals for the "DT" package .................... 10
2.3. Events and Signals for the "BL" package (Basic PBX) ........ 10
2.4. Events and Signals for the "DO" package .................... 11
2.5. Events and Signals for the "MD" package .................... 12
2.6. Events and Signals for the "MO" package .................... 13
2.7. Event and Signal Descriptions .............................. 13
3.0. Hook-State Signals and Events .............................. 23
3.1. Overview of Approach ....................................... 23
3.2. Suspend/Resume Processing .................................. 23
3.3. Control over Disconnect for E911 ........................... 24
3.3. Release and Release Complete ............................... 24
3.4. Blocking CAS Trunks ........................................ 26
3.5. Summary of Hook-State Events ............................... 26
4.0. Glare Handling ............................................. 27
4.1. Glare on MF Bi-directional Wink-start Trunks ............... 27
4.2. Glare Handling - Basic PBX Trunks .......................... 27
5.0. Example Call Flows ......................................... 28
5.1. PBX to PBX ("MS", "DT, and "BL" packages)................... 28
5.1.1. Call Setup Flows ......................................... 28
5.1.2. Call Tear-Down ........................................... 34
5.1.2.1. Origination End Initiates the Release .................. 35
5.1.2.2. Termination End Initiates the Release .................. 38
5.2. Example Call Flows - "DO" package .......................... 40
5.2.1. Call Setup Flows ......................................... 40
5.2.2. Call Tear-Down ........................................... 42
5.3. Example Call Setup - "MD" Package .......................... 44
5.4. Example Call Setup - "MO" Package .......................... 51
Acknowledgements ................................................ 54
References ...................................................... 55
Author's Address ................................................ 55
Full Copyright Statement ........................................ 56
Foster Informational [Page 2]
RFC 3064 MGCP CAS Packages February 2001
1.0.
1.1. Functional
There are a number of different possible approaches for
the functional responsibility between the Call Agent and the
Gateway
* The Call Agent takes all of the responsibility for the CAS
machine giving the media gateway detailed
* The media gateway contains the CAS state machine and provides
abstract interface to the Call
Timing requirements of CAS protocols often involve reacting
time intervals measured in tens of milliseconds which makes
control of timing impossible. The approach used here is to allow
media gateway to handle low level CAS protocol and timing
where at all possible and have the Call Agent involved only
higher level processing is required
Taking this approach, the ideal situation would be to allow the
Agent to treat as many CAS protocols in a similar way, leaving
details to the media gateway. Example: for an incoming MF trunk
involves a single incoming digit string, the Call Agent should
care whether this is a wink start trunk or an immediate start
(media gateway should not have to provide the wink-start signal).
Some goals in partitioning responsibility between the media
and media gateway
* Minimize the number of interactions between the Call Agent and
media gateway
* The media gateway should not have to do digit analysis (e.g.,
determine that the incoming digits contain carrier
information). This is a Call Agent's responsibility
* Provide some reasonable level of abstraction for the Call Agent
that it can reuse call flows when possible (e.g., Call
should not have to differentiate between wink start and
start interfaces when only one digit string is involved).
* The media gateway should take care of the CAS protocol (
timeouts) where possible with the Call Agent taking
responsibility where the media gateway leaves off
Foster Informational [Page 3]
RFC 3064 MGCP CAS Packages February 2001
Use of Embedded Notifications: Rather than depending on the use
embedded notifications, signals and events were defined that had
specific semantics required. There are two reasons for this
a) It allows an abstract interface for the Call Agent so that
example, the same incoming call-setup event can be used in the
of MF wink start and MF immediate start trunks, presenting a
interface to the Call Agent even though the semantics at the
state-machine level are slightly different (i.e., in the MF
start case, a wink-start signal is provided reflexively as a
of an incoming seizure, where as in the immediate start case, this
not required).
b) Potential events that might trigger an embedded
(e.g., the incoming seizure mentioned above) typically needed to
visible to the Call Agent for billing anyway
This does not say that embedded notifications cannot be used.
simply does not necessitate their use
Out-pulsing Approach: In order to provide the semantics
outpulsing, special higher level signals (e.g., "sup" for call set-
and "inf" for information) are included that contain the
semantics
Off-hook and On-hook Signals and Events: A higher level view of off
hook and on-hook events is taken in order to make the
Q.931-like. This provides the advantage that
* Similar call flows result when dealing with Q.931-based
(e.g., PRI
* It's more evident (for ease in debug) when looking at message
to exactly what is going on without having to refer to
1.2. CAS Trunk
The following describes the types of trunks supported by the
packages. Configuration of the specific trunk type (e.g., wink
versus immediate start) is done within the Media Gateway (MG)
provisioning facilities outside the scope of MGCP. The Call Agent'
responsibility is to support the particular package (i.e., in
the Call Agent does not have to differentiate between wink start
immediate start, since those differences are taken care of by
MG). However, the Call Agent needs to know which trunks
incoming, outgoing or bi-directional
Foster Informational [Page 4]
RFC 3064 MGCP CAS Packages February 2001
1.2.1. "MS"
The "MS" package is used for PBX DID/DOD trunks as indicated in
following table. It is also used for incoming or outgoing MF
start trunks (R1 and FGD Terminating protocol [6]).
Table 1 MF PBX
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|MF, wink start |Incoming - originate from PBX |
| |(the same as FGD terminating |
| | protocol) |
|MF, wink start |Outgoing - terminate on PBX |
|MF, wink start |Bi-directional |
|MF, Immediate |Incoming (originate from PBX) |
| start | |
|MF, Immediate |Outgoing (terminate on PBX) |
| start | |
--------------------------------------------------
1.2.2. "DT"
DTMF and dial-pulse (DP) trunks (except basic PBX) are covered by
"DT" package along with the DTMF "D" package
Table 2 DTMF and DP Wink Start and Immediate Start
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|DTMF, Immediate |Incoming (originate from PBX) |
| start, wink | |
| start | |
|DTMF, Immediate |Outgoing (terminate on PBX) |
| start, wink | |
| start | |
--------------------------------------------------
Foster Informational [Page 5]
RFC 3064 MGCP CAS Packages February 2001
1.2.3. "BL"
DTMF and dial-pulse (DP) basic PBX trunks are covered by the "BL
package - along with the DTMF "D" package (essentially this is like
"basic line with no features") - either digital or FXS
interface
Table 3 Basic FXS
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|Basic, DTMF and |Bi-directional |
|DP, Loop Start | |
|Basic, DTMF and |Bi-directional |
|DP, Ground Start| |
--------------------------------------
1.2.4. "DO"
The "DO" package is used for analog FXO loop-start and ground-
analog trunks as indicated in the following table
Table 4 FXO analog PBX
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|FXO, loop-start|Bi-directional |
|FXO, ground- |Bi-directional |
| start | |
--------------------------------------
1.2.5. "MD"
The MD package provides support for North American MF Feature Group
EANA and EAIN [3], allowing the Media Gateway to be at either the
office, the carrier or the tandem side of the circuit. The
Signaling Type column of the following tables is intended to
signaling differences that are of common interest to both the
Agent and Media Gateway. Configuration information that is only
interest to the Media Gateway is not identified
Foster Informational [Page 6]
RFC 3064 MGCP CAS Packages February 2001
Table 4 Feature Group D MF Trunks
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|FGD, EANA |Outgoing (End Office to Carrier) |
|FGD, EANA |Incoming (Carrier to End Office) |
|FGD, EAIN |Outgoing (End Office to Carrier) |
|FGD, EAIN |Incoming (Carrier to End Office) |
--------------------------------------------------
Note that EANA and EAIN signaling may be requested on the same
on a call-by-call basis
1.2.6. "MO"
The "MO" package is used for FGD Operator Services Signaling
outgoing trunks only. Feature Group C can also be supported by
same interface
2.0. Event
This section defines the event packages. The terms "signal"
"event" are used to differentiate a command from a Call Agent to
Media Gateway ("signal") from an "event" that is detected by
Media Gateway and then is "Notified" to the Call Agent
Each package definition includes a package name, plus the event
codes and the definitions for each of the events in the package.
the tables of events/signals for each package, there are
columns
* Code The package unique event code used for
event/signal
* Description A short description of the event/signal
* Event An "x" appears in this column if the event can
Requested by the Call Agent. Alternatively, one
more of the following symbols may appear
- "P" indicating that the event is persistent
- "S" indicating that the event is an event-state that may
audited
Foster Informational [Page 7]
RFC 3064 MGCP CAS Packages February 2001
- "C" indicating that the event/signal may be detected/
on a connection. If "C" is associated with an event,
refers to an event that can occur on the media stream
However, "C" may also be associated with a signal (in
signal column), the signal can be requested to sent over
connection
Note that the intent of being able to audit state ("S") in an
in the following packages is to answer one of the two questions
1. Has a call been initiated on this line/trunk? For example
the packages that follow, call setup initiation is indicated
either a "sup" event or an "hd" (FXS - "BL" packages) or in
case of the "DO" package below (FXO), by the "rg" event so
those events have an "S" in the event column indicating that
are auditable
2. The other question of interest is to know whether the
leg of the call is in the idle state so that a new call can
initiated. This is indicate by the "rlc" (release complete
event-state for packages that have that event
* Signal If nothing appears in this column then this
cannot be signaled on request by the Call Agent
Otherwise, one of the following symbols is
to identify the type of signal
- "OO" On/Off signal. The signal is turned on until
by the Call Agent to turn it off, and vice versa
- "TO" Timeout signal. The signal lasts for a given
unless it is superseded by a new signal or terminated
detection of an event. Default time-out values
supplied. A value of zero indicates that the time-
period is infinite. The provisioning process may
these default values
- "BR" Brief signal. The signal has a short, known duration
* Additional info Provides additional information about
event/signal, e.g., the default duration of TO signals
Unless otherwise stated, all of the events/signals
detected/applied on endpoints and audio generated by them is
forwarded on any connection the endpoint may have. Audio
by events/signals that are detected/applied on a connection
however be forwarded on the associated connection irrespective of
connection mode
Foster Informational [Page 8]
RFC 3064 MGCP CAS Packages February 2001
2.1. Events and Signals for the "MS" package
The following codes are used to identify events and signals for
"MS" package
Table 5 "MS" Package Events and
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
| bl |Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
|inf |Information Digits| x | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signal completes |
| | | | |out-pulsing |
|sus |Suspend call | P | BR | |
---------------------------------------------------------------------
Foster Informational [Page 9]
RFC 3064 MGCP CAS Packages February 2001
2.2. Events and Signals for the "DT" package
The following codes are used to identify events and signals for
"DT" package
Table 6 "DT" Package Events and
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
| bl |Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
| dl |Dial tone | - | TO |Time-out = 16 seconds |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signals completed
| | | | |out-pulsing |
|sus |Suspend call | P | BR | |
---------------------------------------------------------------------
2.3. Events and Signals for the "BL" package (Basic PBX
The following codes are used to identify events and signals for
"BL" package. This package looks very much like a simplified
package
Table 7 "BL" Package Events and
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
| bz |Busy tone | - | TO |Time-out = 30 seconds |
| dl |Dial tone | - | TO |Time-out = 16 seconds |
| hd |Off-hook | P,S | - | |
| hf |Flash hook | P | - | |
| hu |On-hook | P,S | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
| rel|Release | - | BR | |
| rg |Ringing | - | TO |Time-out = 180 seconds |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | C,TO |Time-out = 180 seconds |
---------------------------------------------------------------------
Foster Informational [Page 10]
RFC 3064 MGCP CAS Packages February 2001
2.4. Events and Signals for the "DO" package
The following codes are used to identify events and signals for
"DO" package
Table 8 "DO" Package Events and
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
| ci |Caller id | x | - | |
| hd |Offhook | - | BR | |
| hf |Hook flash | - | BR | |
| hu |Onhook | - | BR | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release call | P | - | |
| rg |Ringing | P,S | - | |
|rlc |Release complete | P,S | - | |
|sup |Call Setup | - | TO |Time-out when signal completes |
| | | | | out-pulsing |
---------------------------------------------------------------------
Foster Informational [Page 11]
RFC 3064 MGCP CAS Packages February 2001
2.5. Events and Signals for the "MD" package
The following codes are used to identify events and signals for
"MD" package
Table 9 "MD" Package Events and
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
|awk |Acknowledge wink | P | BR | |
| bl |Call Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
|cwk |Continue Wink | - | BR | |
|inf |Information Digits| x | TO |Time-out when signals completed
| | | | | out-pulsing |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signals completed
| | | | | out-pulsing |
|sus |Suspend call | P | BR | |
|swk |Start Wink | x | - | |
---------------------------------------------------------------------
Foster Informational [Page 12]
RFC 3064 MGCP CAS Packages February 2001
2.6. Events and Signals for the "MO" package
The following codes are used to identify events and signals for
"MO" package
Table 10 "MO" Package Events and
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer !Note | P | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|orbk|Operator Ringback | x | - | |
|rbz |Reverse make busy | P,S | - | |
|rcl |Operator Recall | - | BR | |
|rel |Release Call | P | BR | |
|res |Resume Call | - | BR | |
|rlc |Release complete | P,S | BR | |
|sup |Call Setup | - | TO | |
|sus |Suspend Call | - | BR | |
|swk |Start Wink | x | - | |
---------------------------------------------------------------------
!Note: There is no indication that the operator answered the call
The "ans" event is an indication that off-hook was
from the far end which simply indicates that the
address was received properly and the calling number is in
process of being outpulsed
2.7. Event and Signal
The following provides a list of the event and signal descriptions
The event/signal name appears in parenthesis followed by
corresponding Event + Signal attribute code plus a list of
packages in which the event/signal occurs
Call answer (ans; P + BR; DT,MD,MS,MO): Off-hook signal
indicates that the call has been answered and that cut-through
been established. The exception is the "MO" package where it
indicates that off-hook was received and the calling number is in
process of being sent (i.e., there is no event available to
that the operator answered the call for operator services signaling).
Acknowledgement Wink (awk; P + BR; MD): This event is only
to the "md" package. It provides an indication that all digits
been received correctly. In an outgoing trunk, the event
requested and when received indicates that the connecting
Foster Informational [Page 13]
RFC 3064 MGCP CAS Packages February 2001
received all of the addressing information. On an originating trunk
this signal is sent to inform the other end that all
information has been received. If the Call Agent is providing
transit application for example, in which incoming and
trunks are both EANA trunks, then after acknowledgement wink
received from the terminating trunk, it is passed to the
side so that the originating side knows that addressing has passed
the destination switch
Call Block (bl; S + BR; DT,MS,MD): A steady off-hook signal
to one-way incoming trunks to indicate that no further calls will
accepted. When "bl" is used as a signal then the "rel" signal
used to release the blocking condition
A Call Agent should only request the "bl" event in a case where
knows that this is a one-way outgoing trunk, and it should never
an incoming call-setup request ("sup" event). As such if "bl"
requested as an event, then "sup" is suppressed as a
event
Busy tone (bz ; - + TO; BL,DT,MD,MS): Refer to ITU E.180.
definition of the tone is defined by the national characteristics
may be established via provisioning. Station Busy is defined in GR
506-CORE - LSSGR, SIGNALING, Section 17.2.6. as a combination of
AC tones with frequencies of 480 and 620 Hertz and levels of -24
each, to give a combined level of -21 dBm. The cadence for
Busy Tone is 0.5 seconds on followed by 0.5 seconds off, repeating
Caller Id (ci(time, number, name); x + -; DO): See TR-NWT-001188,
GR-30-CORE, and TR-NWT-000031. Each of the three fields
optional, however each of the commas will always be included
The time parameter is coded as "MM/DD/HH/MM", where MM is a two
digit value for Month between 01 and 12, DD is a two-digit
for Day between 1 and 31, and Hour and Minute are two-digit
coded according to military local time, e.g., 00 is midnight, 01
is 1 a.m., and 13 is 1 p.m
The number parameter is coded as an ASCII character string
decimal digits that identify the calling line number.
spaces are permitted if the string is quoted, however
will be ignored
The name parameter is coded as a string of ASCII characters
identify the calling line name. White spaces are permitted if
string is quoted
Foster Informational [Page 14]
RFC 3064 MGCP CAS Packages February 2001
A "P" in the number or name field is used to indicate a
number or name, and an "O" is used to indicate an unavailable
or name. The following example illustrates the use of the caller-
event
O: ci(10/14/17/26, "555 1212", somename
Continue Wink (cwk ; - + BR; MD): This signal is only applicable
the "md" package. It provides an indication that digits sent
been accepted, and further digits must be sent in order to
the call. For example, when using FGD EAIN signaling, this
correspond to sending a wink after the country access code had
received to indicate readiness to receive identification and
fields
Dial-tone (dl ; - + TO; BL,DT): Refer to ITU E.180. The
of the tone is defined by the national characteristics and may
established via provisioning. In GR-506-CORE - LSSGR, SIGNALING
Section 17.2.1, sial Tone is defined as a combination of
continuous AC tones with frequencies of 350 and 440 Hertz and
of -13dBm each to give a combined level of -10 dBm. It is
an error to try and play dial-tone on a phone that is on hook and
error should consequently be returned when such attempts are
(error code 402 - phone on hook).
Information Digits (inf(); x + TO; MS,MD): On an
call ("md" package only) it is used as a signal to out-pulse
address information when doing overlapped sending
On an incoming call it is used as an event to indicate that an
digit string has been received. In this case, are
of the digits accumulated up to and including the digit
ST, ST', ST'', ST'''. Multiple sequences of digits ending with
of the ST digits may be passed in a single "inf" event. (Note
K0 is the same as KP, K1 is sometimes referred to as KP' etc
Similarly S0 is the same as ST, S1 is the same as ST' and so on
The value of is a comma separated list of MF digits
MF1, MF2, ...,
where each of MFi will be one of the following MF digit symbols
Foster Informational [Page 15]
RFC 3064 MGCP CAS Packages February 2001
Table 11 MF Digit
-------------------------
| Symbol |MF digit |
| 0 | MF 0 |
| 1 | MF 1 |
| 2 | MF 2 |
| 3 | MF 3 |
| 4 | MF 4 |
| 5 | MF 5 |
| 6 | MF 6 |
| 7 | MF 7 |
| 8 | MF 8 |
| 9 | MF 9 |
| K0 | MF K0 or KP |
| K1 | MF K1 |
| K2 | MF K2 |
| S0 | MF S0 or ST |
| S1 | MF S1 or ST' |
| S2 | MF S2 or ST'' |
| S3 | MF S3 or ST'''|
--------------------------
Thus, an example signal or event might look like
inf(k0, 5,5,5,1,2,3,4, s0)
An example where the inter-digit timer expired after the 5,5,5
appear as follows
inf(k0, 5,5,5)
Operation Complete (oc ; x + -; all): The operation complete event
generated when the gateway was asked to apply one or several
of type TO on the endpoint, and one or more of those
completed without being stopped by the detection of a requested
persistent event such as setup. The completion report may carry as
parameter the name of the signal that came to the end of its
time, as in
O: ms/oc(ms/sup
O: bl/oc(bl/rg
When the operation complete event is requested, it cannot
parameterized with any event parameters
Foster Informational [Page 16]
RFC 3064 MGCP CAS Packages February 2001
Note that when requested at the same a signal for "sup" (out-
- a TO event), the operation complete event will indicate when out
pulsing is complete
Operation failure (of; x + -; all): In general, the
failure event may be generated when the endpoint was asked to
one or several signals of type TO on the endpoint, and one or more
those signals failed prior to timing out. The completion report
carry as a parameter the name of the signal that failed, as in
O: ms/of(ms/sup
O: bl/of(bl/rg
When the operation failure event is requested, it cannot
parameterized with any event parameters
Operator ringback (orbk; x + -; MO): The description of the
MF CAS signaling that results in this event is describe in
appendix of TR-NPL-000258 [3]. In brief, it is normally a wink-
signal which may or may not be followed by an MF tone. This
will be generated when the operator service requests that the
party be alerted ("mo" package only).
Reverse make busy (rbz; P + -; MO): This event corresponds to
"blocking" (off-hook) generated by the other end of the one-
operator services trunk ("mo" package). It has the same semantics
of the "bl" event in other packages
Operator recall (rcl; - + BR; MO): This signal may be applied
invoke operator recall, e.g., due to customer hook-flash to bring
operator back
Release call (rel; P,S + BR; BL,DT,MD,MO,MS,DO): A "rel" signal
by the Call Agent to the Media Gateway is a request to release all
the resources associated with the telephony leg of the call.
may also result in an off-hook signal being sent when appropriate
As a result of an "rel" signal, the gateway will respond with
"rcl" event, whenever the resources have been released.
resources associated with the telephony leg of the call does
affect existing connections (network legs). It's up to the
Agent to send the appropriate delete connection commands in order
release any network connections to that endpoint
Foster Informational [Page 17]
RFC 3064 MGCP CAS Packages February 2001
In the case of the FXS ("BL") package, the "rel" signal is used
provide a tip-ground release for ground-start trunks. In the case
loop-start trunks, requesting to play this signal has no effect
The Media Gateway generates a "release call" event whenever a call
released as a result of an on-hook event from an originating end of
call (normal release) or due to abnormal event that resulted
releasing the call. The event may be parameterized with one of
following cause codes indicating the reason for the release
Table 12 Release Reason
-----------------------------------------------------------------
|Cause Code |Reason |
|-----------------------------------------------------------------
| 0 |Normal release |
| 44 |Requested channel/circuit not available |
| |(glare or incoming seizure detected during call |
| | setup) |
| 111 |Protocol/signaling error, unspecified (e.g. timeout) |
-----------------------------------------------------------------
Note that a "rel" event with reason code "0" indicating
release (due to an incoming on-hook) will only be "notified" by
gateway where a call origination occurred. This behavior follows
rule that when an originator releases the call, all resources may
released. The corresponding event for on-hook on the terminating
of a call is the "sus" event which only indicates hook-status
does not result in any resources being released. It is always up
the Call Agent to release the call (by sending the "rel" signal)
the terminating end of a call
For FXO ground-start case ("DO" package), the Media Gateway
a "release call" event whenever a call is released as a result of
tip-ground release event from the far end
Resume call (res ; P + BR; DT,MD,MS,MO): This indicates that
called party resumed the call, i.e., the party went off-hook after
previous suspend ("sus") but before the originating switch
("rel") the trunk. The "sus" and "res" events/signals are used
propagate on-hook and off-hook events without releasing the
associated with the call. In all but the operator services
("MO" package), these events would normally be propagated from
terminating to the originating end (i.e., requested as events
the terminating end of the call and sent to the gateway as signals
a gateway on the originating side of the call).
Foster Informational [Page 18]
RFC 3064 MGCP CAS Packages February 2001
However, it is up to the Call Agent to decide whether it wants to
"suspend"/"resume" processing. If it doesn't, when it receives
"sup" event from the terminating end of the call it can simply
ahead and tear down the call immediately (send "rel" and
connections to the endpoints on gateways at both originating
terminating end of the call).
In the case of operator services and 911, "sus" and "res" are used
pass off-hook and on-hook signals to the operator without
any of the resources associated with the call
Ringing (rg; P,S + TO; BL,DO): This signal is used for outgoing
trunks ("bl" package). See GR-506-CORE - LSSGR: SIGNALING,
14. The provisioning process may define the ringing cadence. It
considered an error to try and ring if the trunk indicates off
and an error should consequently be returned when such attempts
made (error code 401 - phone off hook).
In the case of the "DO" package, "rg" is defined as an event used
indicate detection of ringing
Release complete (rlc;P,S + BR; DO,DT,MD,MO,MS): The endpoint
Call Agent use the release complete event/signal to confirm the
has been released and the trunk is available for another call.
FXO ground-start ("DO" package), this represents the release of
tip-ground event from the PBX after the gateway goes on-hook
Reorder tone (ro; - + TO; BL,DT,MD,MS): Reorder tone is a
of two AC tones with frequencies of 480 and 620 Hertz and levels
-24 dBm each, to give a combined level of -21 dBm. The cadence
reorder tone is 0.25 seconds on followed by 0.25 seconds off
repeating continuously. See GR-506-CORE - LSSGR: SIGNALING,
17.2.7.
Ring back tone (rt; - + TO; BL,DT,MD,MS): Audible Ring Tone is
combination of two AC tones with frequencies of 440 and 480 Hertz
levels of -19 dBm each, to give a combined level of -16 dBm. In
US the cadence for Audible Ring Tone is defined to be 2 seconds
followed by 4 seconds off. The definition of the tone is defined
the national characteristics of the Ring-back Tone, and MAY
established via provisioning. See GR-506-CORE - LSSGR: SIGNALING
Section 17.2.5.
Call Setup (sup ; P,S + TO; DO,DT,MD,MS,MO): The event/signal is
both for outgoing and incoming call setups. Each will be
separately in the following
Foster Informational [Page 19]
RFC 3064 MGCP CAS Packages February 2001
Outgoing call setup
On an outgoing trunk, the "sup" signal is used to seize a trunk
out-pulse digits. The "sup" signal is parameterized with up to
parameters sup(, , , ), depending on the package
The order of these parameters does not matter. The following
indicates which ones are mandatory ("M"), optional ("O") or
("F") for the various packages
Table 13 "sup" parameters
------------------------------------
| Parameter | MS | DT | MO | MD | DO |
|------------------------------------|
| | F | F | F | M | F |
| | F | F | F | O | F |
| | F | F | M | M | F |
| | M | M | M | O | M |
------------------------------------
The parameter is of the format ct() where
indicates the CAS signaling type and can have one of two values "nda
(North American Direct Access) for EANA and "nta" (North
Tandem Access) for EAIN. The reason this parameter is needed in
case of trunks that handle the "MD" packages is because the
trunk can be used for both. The field contains
destination number and when present will be on the
addr(dig1, dig2, ..., dign
The field contains the identification of the caller and
present will be of the form
id(dig1, dig2, ..., dign
The field contains the country address information and
present will be of the form
ca(dig1, dig2, ..., dign
When present, the field contains the destination number
will be of the
addr(dig1, dig2, ..., dign
where digi is an MF symbol as defined in table 11 in the case
"MS", "MO", and "MD" packages and digi is a DTMF symbol (0-9,
*,#,A,B,C,D) in the case of the "DT" and "DO" packages
Foster Informational [Page 20]
RFC 3064 MGCP CAS Packages February 2001
The following table shows some interactions between the Media
(MG) and the Switched Circuit Network (SCN) for single
outpulsing applications ("DT", "MS" and "DO" packages):
Table 14 SCN Sequencing during Call Setup (single stage outpulsing
------------------------------------------------------------------
|Interface Type |Setup | Interactions |
|------------------------------------------------------------------|
|wink start |sup(add()) |MG| off-hook -> |SCN
| | |MG| <- wink |SCN
| | |MG| -> |SCN
|------------------------------------------------------------------|
|Immediate Start|(sup(addr()) |MG| off-hook -> |SCN
| or FXO) | |MG| -> |SCN
------------------------------------------------------------------
Call setup signal example for this case (MF signaling):
sup(addr(s0,5,5,5,1,2,3,4,k0))
The "MO" and "MD" packages involve multi-stage signaling and
parameters. In the case of the "MD" package the following
shows some of the interactions
Table 15 SCN Sequencing during Call Setup (EANA and EAIN
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(), |MG| off-hook -> |SCN
| id()) |MG| <- wink |SCN
| |MG| -> |SCN
| |MG| -> |SCN
|------------------------------------------------------------------|
| sup(ct(nta), ca(), |MG| off-hook -> |SCN
| addr(), id()) |MG| <- wink |SCN
| |MG| -> |SCN
| |MG| <- wink |SCN
| |MG| -> |SCN
| |MG| -> |SCN
|------------------------------------------------------------------|
| sup(ct(nta), ca(), |MG| off-hook -> |SCN
| id()) |MG| <- wink |SCN
| |MG| -> |SCN
| |MG| <- wink |SCN
| |MG| -> |SCN
------------------------------------------------------------------
Foster Informational [Page 21]
RFC 3064 MGCP CAS Packages February 2001
The last example is an overlapped sending example where the
value would be sent later using the "inf" signal
An example setup
sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,0,5,5,5,1,2,3,4,s0))
In all of the above cases, the "ans" event is an indication of off
hook from the far end (the other end answered). However, in the
of the operator service signaling (OSS) protocol of Feature Group D -
shown in the following table, off-hook from the operator is part
the protocol (a request for the calling number) so that "ans" in
case does not indicate that the operator answered (only that off
hook/request for calling number was received).
Table 16 SCN Sequencing during Call Setup OSS Protocol ("MO" Package
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(), |MG| off-hook -> |SCN
| id()) |MG| <- wink |SCN
| |MG| <- off-hook |SCN
| |MG| -> |SCN
| |MG| -> |SCN
------------------------------------------------------------------
Incoming Call Setup: A "sup" event is used to indicate when
incoming call arrives (corresponding to the incoming off-hook event).
The event is provided without parameters
Suspend call (sus; P + BR; DT,MD,MS,MO): Suspend ("sus") is an on
hook event that is an indication that the called party went on-hook
An on-hook event will be "notified" to a Call Agent as a "sus"
for interfaces that use the "MS", "DT" and "MD" packages from
endpoint at a terminating end of a call (as compared to a "rel"
from the originating side). The "sus" event from the
endpoint gives the Call Agent the option of doing "suspend/resume
processing or to simply release the call
The "sus" signal may be used to send an on-hook to the
party without releasing the resources associated with the
leg of the call. The "rel" signal on the other hand would send
on-hook and release the resources associated with the call
Foster Informational [Page 22]
RFC 3064 MGCP CAS Packages February 2001
Because of this "sus" can be followed by "res" (off-hook) and
the call to resume, while "rel" cannot be followed by "res"
the call no longer exists
For E911 ("MO" package), the operator is normally in control
releasing the call so that, "sus" (on-hook), "res" (off-hook)
"rcl" (flash-hook) can be used to pass user hook events to
operator without releasing the call
Start Wink (swk; x + - MD,MO):. An Call Agent can optionally
the MG to notify it when the wink start signal occurs. Note
wink start ("swk") cannot be applied by the Call Agent as a signal
The occurrence of wink-start on an incoming trunk is a
action that does not require Call Agent involvement
3.0. Hook-State Signals and
3.1. Overview of
As mentioned in the introduction, a higher level view is taken
on-hook and off-hook events for many of the CAS packages to make
interface Q.931-like. This provides the advantage that
* Similar call flows result as when dealing with Q.931-
interfaces (e.g., PRI
* It's more evident (for ease in debug) when looking at message
to exactly what is going on without having to refer to
flows
This does require that media gateways maintain some state but this
a relatively small price to pay
One example of this is the "sup" signal which involves sending off
hook followed by digits as a high level signal. The "ans" event
also used to represent off-hook but from the terminating end at
point where the call is answered
3.2. Suspend/Resume
Other signals and events "sus" for suspend, "res" for resume
"rel" for release are based on the concept that one end (
originator) is in control of the call. If the controlling end
on-hook a "rel" is notified to the Call Agent, and results in a
call being released. However, if the non-controlling (terminating
end goes on-hook, a "sus" event occurs (instead of the "rel" event).
This gives the Call Agent the option of doing suspend/
processing
Foster Informational [Page 23]
RFC 3064 MGCP CAS Packages February 2001
If the Call Agent decides not to do suspend/resume processing, it
simply send "rel" and delete connection commands to the
after it receives "sus" from the non-controlling (terminating) end
the call
On the other hand, if it decides to do suspend/resume processing,
can start a timeout when it receives the "sus" event from the non
controlling (terminating) end of the call and continue the call if
receives a "res" (off-hook) event. It also has the option
propagating the "sus" and "res" as signals back to the
gateway and allow it an opportunity to release the call ("rel" event
or not. In any case the use of "sus" and "res" signals give
level of control over the "rel" signal which will not only send on
hook but also release the resources associated with the telephony
of the call
3.3. Control over Disconnect for E911
Note that for E911 (the "MO" package) is a special case in that
operator (terminating end) is always the controlling end. The "sus
and "res" signals are used to pass user hook state forward to
operator. The "rel" event is passed back as a notify to the
Agent when on-hook is received from the operator indicating that
Call should be released. If the "rel" is not received the
should continue to stay up
3.3. Release and Release
The "rel" signal/event generally means on-hook but more that that
also indicates "release of resources" for the telephony leg of
call. If a Call Agent sends a "rel" signal instead of "sus" it
requesting the call to be abandoned (i.e., "rel" cannot be
by "res").
The "rel" signal does not also imply that connections should
deleted so that to completely release the call including
would require a DLCX in addition to (or conjunction with) the
"rel".
In addition to being a signal, "rel" can also be an event
by either
* An on-hook from the controlling end of the call,
* Some abnormal event within the media gateway such that
telephony leg of the call can no longer be maintained
Foster Informational [Page 24]
RFC 3064 MGCP CAS Packages February 2001
In any case, "rel" (release) is generally followed by an "rlc
(release complete). The release complete signal/event indicates
the trunk resources are now completely released and available
another call. This is also an event state that can be audited
indicated by the "S" in the column for that event (allowing the
Agent to check to see if that trunk is released and available).
Examples of the use of "rel" and "rlc":
* Call Agent sends a "rel" to release a trunk, resulting in
outgoing off-hook being sent for that trunk. When the
gateway receives the on-hook from the other end, it returns
"rlc" event indicating that the trunk is released and available
* The media gateway receives a on-hook from the trunk at
controlling end of the call, resulting in a "rel" event being
to the Call Agent. The Call Agent then sends an "rlc" to
media gateway, resulting in on-hook being sent in the
direction
* An "rel" event is sent to the Call Agent in the event of
abnormal condition in which the media gateway is unable to
the telephony leg of the call (e.g., glare condition). The
Agent sends an "rlc" to the gateway to complete the release of
call. (note that "rlc may not correspond to on-hook but
generally sent anyway in response to a "rel".)
* The Call Agent can send a "rel" (instead of "sus") signal to
controlling (originating) end of the call to abandon the call
The gateway will return with "rlc" when an off-hook has
received from the other end and all the resources have
released
* A "rel" can be sent on one-way incoming trunk to release a
("bl") sent earlier
The "BL" (FXS) package is a simple line package, so does not
these events (uses "hd", "hf", and "hu" as the only hook
events).
The "DO" (FXO) package, however, does have "rel" and "rlc" because
the ground-start case there is the ability to "release" the call
result of a tip-ground release. The signal "rel" is used if the
releases the call first (followed by S: hu from the call Agent
complete the release). Alternatively, the Call Agent can send the S
hu to initiate the release - followed by an "rlc" event from
media gateway to Call Agent when the PBX does the tip ground release
Although the loop-start trunks would not normally have this
(only applies to ground-start), the media gateway should emulate
behavior in the case of loop-start in order to allow the Call Agent
common interface
Foster Informational [Page 25]
RFC 3064 MGCP CAS Packages February 2001
3.4. Blocking CAS
In addition to the above signals and events, there is the "bl
signal/event which is used for blocking one-way trunks (does not
for two way trunks) by providing a continuous off-hook
3.5. Summary of Hook-State
The following summarizes the use of the various events that
off-hook and on-hook from call establishment to tear-down.
applies mainly to "MS", "DT", "MD" and to a lesser extent the "DO
package
* The "sup" event represents off-hook origination
* The "sup" signal with parameters provides off-hook with
outpulsing on the terminating side
* Once outpulsing is completed, an "ans" event indicates off-
from the termination side (the called party has answered).
* The call agent can then send an "ans" signal (off-hook) to
originating end to indicate to the caller that the called
has answered
* The Call Agent can send a "rel" to either end at any time to
down the call (e.g., to abort the call).
* The media gateway can send "rel" to indicate abnormal
of the call (with a reason as a parameter).
* However, under normal operation once a call is established,
Call Agent can expect a "sus" (suspend) event from the
end to indicate that the caller went on-hook and a "res" if
called party goes off-hook again before the Call Agent tears
the call. The Call Agent can send these same signals to
originating end to indicate off-hook and on-hook to the
party without tearing down the call
* During normal operation, once the call is established, on-
from the calling party (origination side) would result in a "rel
signal. The Call Agent would then normally send the "rel"
to the terminating end to terminate the call. "rel is
followed by "rlc" (e.g., media gateway indicates calling party on
hook with "rel" and the Call Agent responds with "rlc",
sends on on-hook back to the calling party to indicated
complete
The "MO" package is a bit different in that normally only
terminating side (the operator) can release the call ("rel" event).
The "sus" and "res" are forward signals to the operator
user hook-status
Foster Informational [Page 26]
RFC 3064 MGCP CAS Packages February 2001
4.0. Glare
4.1. Glare on MF Bi-directional Wink-start
Gateways may have a configurable glare bit on a per-DS0 basis
can be set to indicate whether the gateway is the controlling
non-controlling "switch". However, in general, PBXs are either pre
configured or can be configured to behave as non-
switches. In this case if they see an off-hook that
allowable wink length, they will attach a receiver, go on-hook,
await digits for a new call. Meanwhile the PBX will retry
original call on another trunk
If the gateway behaves like a controlling switch, when glare
detected, the gateway will wait for up to some timeout value (
value of 4 seconds) until the incoming off-hook changes to an on-
state at which time it will start out-pulsing in the normal manner
If the timeout occurs before the state change to on-hook occurs,
gateway will send a release event to the Call Agent (a "rel(44)"
event - cause code indicating glare).
When "rel(44)" is sent by the gateway, that is an indication to
Call Agent that the call is in the process of being released and
the Call Agent should give up on that trunk. However, the
may not actually want to send the on-hook at that time in order
avoid the possibility that the other end takes the on-hook as a wink
Instead, it may start a second timer and wait some longer period
time (e.g., 16 seconds or so) before releasing the trunk. If
receives an on-hook prior the timeout, it completes the release
going on-hook. If, on the other hand, the timer expires before
other end goes on-hook, it will simply go on-hook and wait for
other end to go on-hook. In any case, once both ends have
to the on-hook state, an "rlc" event is sent to the Call Agent
4.2. Glare Handling - Basic PBX
In order to reduce the chances of glare, the gateway should try
ringing pre-trip test prior to sending ringing on a basic
start trunk. If glare is detected on an outgoing seizure of a
PBX trunk, the request for ringing should be "Nacked" (error code 401
- phone off-hook) to the Call Agent
Foster Informational [Page 27]
RFC 3064 MGCP CAS Packages February 2001
5.0. Example Call
5.1. PBX to PBX ("MS", "DT, and "BL" packages).
The following call flows involve a single Call Agent that
both sides of the call (i.e., the inter-Call-Agent signaling
ignored). The components involved in the call are
* The Call Agent (CA
* The originating Media Gateway (GW-o)
* The terminating Media Gateway (GW-t
5.1.1. Call Setup
The following describes some PBX to PBX call. The table gives
overview of the initial part of the call flow with details to follow
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[seizure] -> |
| A2 | <- Ack |
| A3 | <- RQNT[request digits] |
| A4 | Ack -> |
| A5 | NTFY[digits] -> |
| A6 | <- Ack |
| B1 | <- CRCX [M:recvonly, LCO] |
| B2 | Ack[SDP1] -> |
| B3 | CRCX [M:sendrecv, LCO, SDP1] -> |
| B4 | <- Ack [SDP2] |
| B5 | <- MDCX [recvonly,SDP2] |
| B6 | Ack -> |
---------------------------------------------------------------------
Step A1 PBX seizure results in a notify to the Call
indicating the start of a call setup
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789
O: ms/sup (or dt/sup
Foster Informational [Page 28]
RFC 3064 MGCP CAS Packages February 2001
In the case of the "BL" package (basic PBX) the interface
like a simplified line interface with the standard "hd" event
off-hook
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789
O: bl/
Another alternative would have been to use an embedded request in
RQNT that resulted in this notify and combine that request with
A3. Example - "ms" package
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789
R: ms/sup(E(R(ms/inf, ms/rel))
Step 3 could also be eliminated by the use of "loop" mode e.g.:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789
Q:
R: ms/sup, ms/inf, ms/
This would result in both notifies occurring without requiring
RQNT in step A3.
Step A2 The Call Agent sends an Ack
200 3001
Step A3 The Call Agent requests that digits be collected.
approach used here depends on the type of PBX interface. For an
interface the Call Agent requests that information digits
collected as follows
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B
R: ms/inf, ms/
The Call Agent also asks to be told if the trunk gets
for some reason ("rel" event) in the process of call
(release event may be due to some signaling error for example).
For DTMF trunks (wink-start, immediate start and Basic PBX),
request is based on a digit map so looks a bit different
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B
R: d/[0-9*#T](D), dt/rel (bl/hd in the case of Basic PBX
Foster Informational [Page 29]
RFC 3064 MGCP CAS Packages February 2001
D: (xxxxxxx | x.[T#])
S: dt/
Note: the request to signal dial-tone may or may not be
depending on PBX interface requirement - bl/dl required
Basic PBX; dt/dl for some Immediate Start interfaces
Step A4 The gateway responds with an ack
200 2001
Step A5 Once the digits are collected the gateway notifies the
agent. In the case of an MF interface, the resulting notify
look like the
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B
O: ms/inf(k0,5,5,5,1,2,3,4,s0)
In the case of a DTMF interface (including Basic PBX), it
look like the following
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B
O: d/5,d/5,d/5,d/1,d/2,d/3,d/4
Step A6 The Call Agent responds with an ack
200 3002
Step B1 The Call Agent now requests that a receive-only
be made
CRCX 2002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
L: a:PCMU,s:off,e:
M:
X: 0123456789B
R: ms/rel (or dt/rel or bl/hu).
Step B2 The Gateway acks with a connection ID and provides the
information
200 2002
I: 23474
Foster Informational [Page 30]
RFC 3064 MGCP CAS Packages February 2001
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m= audio 3456 RTP/AVP 0
Step B3 The Call Agent passes this SDP information to
terminating gateway (GW-t) as part of the connection request
CRCX 4001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
C: A7453949499
X: 45375840
L: a:PCMU,s:off,e:
M:
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
Note that the call setup on the terminating trunk can be done
this CRCX, although in this call flow - it is shown later (step C1).
Step B4 The terminating gateway, responds with an ack and its
information
200 4001
I: 34738
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
Step B5 Call Agent sends a modify connection request
connection mode receive-only to the origination gateway and
the SDP information with the selected profile from the
gateway
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738
M:
Foster Informational [Page 31]
RFC 3064 MGCP CAS Packages February 2001
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
Step B6 The Gateway Acks the modify connection
200 2003
The following table shows the remainder of the call flow to set
the call except for Basic PBX (Basic PBX shown in) with details
follow
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| C1 | RQNT [S: ms/sup, R: ms/oc, ms/rel, ms/ans] ->|
| C2 | <- Ack |
| C3 | <- NTFY [O:ms/oc(ms/sup)]|
| C4 | Ack -> |
| C5 | <- NTFY [O: ms/ans] |
| C6 | Ack -> |
| C7 | <- MDCX [M:sendrecv, S: ms/ans, R: ms/rel] |
| C8 | Ack -> |
| C9 | RQNT[R: ms/sus] -> |
| C10 | <- Ack |
---------------------------------------------------------------------
Step C1 The Call Agent does a setup request to the
gateway The setup request for an MF PBX interface (wink start
immediate start) will be the following
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q:
S: ms/sup(addr(ko,5,5,5,1,2,3,4,s0))
R: ms/oc, ms/rel, ms/
Note that the result of the "sup" signal is the
sequence on the interface to the PBX
* off-hook ->
* wink -> PBX (for wink-start trunks; for immediate start
part of the sequence does is not included
* Digits sent to
Foster Informational [Page 32]
RFC 3064 MGCP CAS Packages February 2001
For DTMF PBX interface (except Basic PBX), the only difference
that the MF start and end delimiters (k0 and s0) are
included
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q:
S: dt/sup(addr(5,5,5,1,2,3,4))
R: dt/oc, dt/rel, dt/
Basic PBX requires ringing and ring-back instead i.e.:
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q:
S: bl/rg,bl/rt@34738
R: bl/oc,bl/
In this case ringback will come from the gateway and will
immediately with the signal request for rt@connectionID. It
end as soon as an event occurs (off-hook representing
event) In the case of other PBX's, the ringback tone comes
the PBX so does not have to be generated by the gateway
Note that these requests could be done as easily at the same
as the connection request (B3) saving some post-dial delay time
Step C2 The gateway responds with an ack
200 4002
Step C3 Except for the basic PBX, case (where digits are
outpulsed) when the digits have completed being sent out, the
will notify the fact by indicate that the operation is complete
NTFY 1001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
O: ms/oc(ms/sup) (or dt/oc(dt/sup))
Step C4 The Call Agent acks the
200 1001
In the case of the BL package, steps C3 and C4 will not exist
Foster Informational [Page 33]
RFC 3064 MGCP CAS Packages February 2001
Step C5 When an answer is obtained from the other end (off-
from the PBX), the gateway sends a notify to indicate
NTFY 1002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
O: ms/ans (or dt/ans or bl/hd
Step C6 The Call Agent
200 1002
Step C7 The Call Agent now sends a request to make the
full duplex and indicates that the other end has answered the phone
MDCX 2004 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
X: 45375842
I: 34738
M:
S: ms/ans ( or dt/ans but S: not included in the case where
originating gateway uses the BL package
Step C8 The Gateway acks the
200 2004
Step C9 The Call Agent sends a notification request to be
when the trunk to be released
RQNT 4003 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
R: ms/rel,ms/sus (or R: dt/rel,dt/sus or R: bl/hu
Step C10 The gateway acks the
200 4003
The call is now setup
5.1.2. Call Tear-
Two cases are included here, one where the origination end
the release (section 5.1.2.1) and one where the termination
initiates the release (section 5.1.2.2).
Foster Informational [Page 34]
RFC 3064 MGCP CAS Packages February 2001
5.1.2.1. Origination End Initiates the
The following call flow shows an example where the origination
initiates the release for the "MS" package (similar for "DT
Package).
--------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|-------------------------------------------------------------------- |
| A1 | NTFY[O: ms/rel] -> |
| A2 | <- Ack |
| A3 | RQNT [S: ms/rel, R: ms/rlc] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: ms/rlc] |
| A6 | Ack -> |
| A7 | <- DLCX [S: ms/rlc, R: ms/sup] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: ms/sup]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
The same call flow for the "BL" package is shown
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O: bl/hu] -> |
| A2 | <- Ack |
| A3 | RQNT [S: bl/dl, R: bl/hu] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: bl/hu] |
| A6 | Ack -> |
| A7 | <- DLCX [R: bl/hd] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: bl/hd]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
Step A1 The originating user goes on-hook resulting in a
from the gateway to indicate that the trunk is being released (
indicating normal release
NTFY 3005 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 45375842
O: ms/rel(0) (or dt/rel(0) or bl/hu
Foster Informational [Page 35]
RFC 3064 MGCP CAS Packages February 2001
Step A2 The Call Agent Acks the
200 3005
Step A3 The Call Agent sends a request to release the trunk. (
all but Basic PBX.)
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: ms/rel (or dt/rel
R: ms/rlc (or dt/rlc
For the Basic PBX ("BL" package), dial-tone is
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: bl/
R: bl/
Step A4 The Gateways acks the
200 4004
Step A5 The other end releases the call by going on-hook and
Notify is sent to the Call Agent to indicate that release
complete
NTFY 1004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
O: ms/rlc (or dt/rlc
In the case of Basic PBX, this is
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375843
O: bl/
Step A6 The Call Agent returns an
200 1004
Foster Informational [Page 36]
RFC 3064 MGCP CAS Packages February 2001
Step A7 The Call Agent sends a delete connection to the
gateway with a request to do a release complete (which results
sending on-hook to the PBX).
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738
S: ms/rlc (or dt/rlc
R: ms/sup (or dt/sup
Or in the case of Basic PBX ("BL" package):
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738
R: bl/
Step A8 The Gateway Acks and provides performance information
250 4005
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
Step A9 The Call Agent sends a DLCX to the terminating gateway
DLCX 2004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 0123456789B
I: 23474
R: ms/sup (or dt/sup or bl/hd
Step A10 The gateway acks with performance
250 2004
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
Foster Informational [Page 37]
RFC 3064 MGCP CAS Packages February 2001
5.1.2.2. 