GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3064

Network Working Group B. Foster Request for Comments: 3064 Cisco Systems Category: Informational February 2001

                         MGCP CAS Packages

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

 This document contains a collection of media gateway Channel
 Associated Signaling (CAS) packages for R1 CAS, North American CAS,
 CAS PBX interconnect as well as basic FXO support.  Included are six
 packages.  The "MS" package covers MF single stage dialing trunks.
 This includes wink start and immediate start PBX DID/DOD trunks as
 well as basic R1 and Feature Group D (FGD) Terminating protocol [3].
 The "DT "package covers immediate start and basic DTMF and dial-pulse
 trunks and the "BL" package covers the interface to a basic PBX
 (digital or FXS interface).  In addition to the Terminating protocol,
 there are three other FGD protocols described in [3].  These include
 EAIN and EANA which is covered by the enclosed "MD" package and the
 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 document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC-2119.

IESG Note:

 This document is being published for the information of the
 community.  It describes a protocol that is currently being deployed
 in a number of products.  Implementers should be aware of
 developments in the IETF Megaco Working Group and ITU SG16 who are
 currently working on a potential successor to this protocol.

Foster Informational [Page 1] RFC 3064 MGCP CAS Packages February 2001

Table of Contents

 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.Introduction

1.1. Functional Partitioning

 There are a number of different possible approaches for partitioning
 the functional responsibility between the Call Agent and the Media
 Gateway:
  • The Call Agent takes all of the responsibility for the CAS state

machine giving the media gateway detailed commands

  • The media gateway contains the CAS state machine and provides an

abstract interface to the Call Agent

 Timing requirements of CAS protocols often involve reacting within
 time intervals measured in tens of milliseconds which makes direct
 control of timing impossible.  The approach used here is to allow the
 media gateway to handle low level CAS protocol and timing details
 where at all possible and have the Call Agent involved only whenever
 higher level processing is required.
 Taking this approach, the ideal situation would be to allow the Call
 Agent to treat as many CAS protocols in a similar way, leaving the
 details to the media gateway.  Example: for an incoming MF trunk that
 involves a single incoming digit string, the Call Agent should not
 care whether this is a wink start trunk or an immediate start trunk
 (media gateway should not have to provide the wink-start signal).
 Some goals in partitioning responsibility between the media gateway
 and media gateway:
  • Minimize the number of interactions between the Call Agent and the

media gateway.

  • The media gateway should not have to do digit analysis (e.g., to

determine that the incoming digits contain carrier access

    information).  This is a Call Agent's responsibility.
  • Provide some reasonable level of abstraction for the Call Agent so

that it can reuse call flows when possible (e.g., Call Agent

    should not have to differentiate between wink start and immediate
    start interfaces when only one digit string is involved).
  • The media gateway should take care of the CAS protocol (and

timeouts) where possible with the Call Agent taking over

    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 of
 embedded notifications, signals and events were defined that had the
 specific semantics required.  There are two reasons for this:
 a) It allows an abstract interface for the Call Agent so that for
 example, the same incoming call-setup event can be used in the case
 of MF wink start and MF immediate start trunks, presenting a common
 interface to the Call Agent even though the semantics at the CAS
 state-machine level are slightly different (i.e., in the MF wink
 start case, a wink-start signal is provided reflexively as a result
 of an incoming seizure, where as in the immediate start case, this is
 not required).
 b) Potential events that might trigger an embedded notification
 (e.g., the incoming seizure mentioned above) typically needed to be
 visible to the Call Agent for billing anyway.
 This does not say that embedded notifications cannot be used.  It
 simply does not necessitate their use.
 Out-pulsing Approach: In order to provide the semantics for
 outpulsing, special higher level signals (e.g., "sup" for call set-up
 and "inf" for information) are included that contain the necessary
 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 interface
 Q.931-like.  This provides the advantage that:
  • Similar call flows result when dealing with Q.931-based interfaces

(e.g., PRI)

  • It's more evident (for ease in debug) when looking at message as

to exactly what is going on without having to refer to previous

    events

1.2. CAS Trunk Types

 The following describes the types of trunks supported by the various
 packages.  Configuration of the specific trunk type (e.g., wink start
 versus immediate start) is done within the Media Gateway (MG) via
 provisioning facilities outside the scope of MGCP.  The Call Agent's
 responsibility is to support the particular package (i.e., in general
 the Call Agent does not have to differentiate between wink start and
 immediate start, since those differences are taken care of by the
 MG).  However, the Call Agent needs to know which trunks are
 incoming, outgoing or bi-directional.

Foster Informational [Page 4] RFC 3064 MGCP CAS Packages February 2001

1.2.1. "MS" Package

 The "MS" package is used for PBX DID/DOD trunks as indicated in the
 following table.  It is also used for incoming or outgoing MF wink
 start trunks (R1 and FGD Terminating protocol [6]).
         Table 1 MF PBX Trunks
  1. ————————————————-

| Trunk Type | Direction (w.r.t. the gateway) |

  1. ————————————————-

|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" Package

 DTMF and dial-pulse (DP) trunks (except basic PBX) are covered by the
 "DT" package along with the DTMF "D" package:
      Table 2 DTMF and DP Wink Start and Immediate Start Trunks
  1. ————————————————-

| Trunk Type | Direction (w.r.t. the gateway) |

  1. ————————————————-

|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" Package

 DTMF and dial-pulse (DP) basic PBX trunks are covered by the "BL"
 package - along with the DTMF "D" package (essentially this is like a
 "basic line with no features") - either digital or FXS trunk
 interface:
        Table 3 Basic FXS Interface
  1. ————————————-

| 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" Package

 The "DO" package is used for analog FXO loop-start and ground-start
 analog trunks as indicated in the following table.
         Table 4 FXO analog PBX Trunks
  1. ————————————-

| Trunk Type | Direction |

      |               | (w.r.t. the gateway) |
       --------------------------------------
      |FXO, loop-start|Bi-directional        |
      |FXO, ground-   |Bi-directional        |
      |     start     |                      |
       --------------------------------------

1.2.5. "MD" Package

 The MD package provides support for North American MF Feature Group D
 EANA and EAIN [3], allowing the Media Gateway to be at either the end
 office, the carrier or the tandem side of the circuit.  The CAS
 Signaling Type column of the following tables is intended to indicate
 signaling differences that are of common interest to both the Call
 Agent and Media Gateway.  Configuration information that is only of
 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 Supported
  1. ————————————————-

| Trunk Type | Direction (w.r.t. the gateway) |

  1. ————————————————-

|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 trunk
 on a call-by-call basis.

1.2.6. "MO" Package

 The "MO" package is used for FGD Operator Services Signaling,
 outgoing trunks only.  Feature Group C can also be supported by the
 same interface.

2.0. Event Packages

 This section defines the event packages.  The terms "signal" and
 "event" are used to differentiate a command from a Call Agent to a
 Media Gateway ("signal") from an "event" that  is detected by the
 Media Gateway and then is "Notified" to the Call Agent.
 Each package definition includes a package name, plus the event name
 codes and the definitions for each of the events in the package.  In
 the tables of events/signals for each package, there are five
 columns:
  • Code The package unique event code used for the

event/signal.

  • Description A short description of the event/signal.
  • Event An "x" appears in this column if the event can be

Requested by the Call Agent. Alternatively, one or

                   more of the following symbols may appear:
  1. "P" indicating that the event is persistent,
  1. "S" indicating that the event is an event-state that may be

audited,

Foster Informational [Page 7] RFC 3064 MGCP CAS Packages February 2001

  1. "C" indicating that the event/signal may be detected/applied

on a connection. If "C" is associated with an event, this

            refers to an event that can occur on the media stream.
            However, "C" may also be associated with a signal (in the
            signal column), the signal can be requested to sent over a
            connection.
 Note that the intent of being able to audit state ("S") in an event
 in the following packages is to answer one of the two questions:
    1. Has a call been initiated on this line/trunk? For example in
    the packages that follow, call setup initiation is indicated by
    either a "sup" event or an "hd" (FXS - "BL" packages) or in the
    case of the "DO" package below (FXO), by the "rg" event so that
    those events have an "S" in the event column indicating that they
    are auditable.
    2. The other question of interest is to know whether the telephony
    leg of the call is in the idle state so that a new call can be
    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 event

cannot be signaled on request by the Call Agent.

                   Otherwise, one of the following symbols is provided
                   to identify the type of signal:
  1. "OO" On/Off signal. The signal is turned on until commanded

by the Call Agent to turn it off, and vice versa.

  1. "TO" Timeout signal. The signal lasts for a given duration

unless it is superseded by a new signal or terminated on

             detection of an event.  Default time-out values are
             supplied.  A value of zero indicates that the time-out
             period is infinite.  The provisioning process may alter
             these default values.
      - "BR" Brief signal.  The signal has a short, known duration.
  • Additional info Provides additional information about the

event/signal, e.g., the default duration of TO signals.

 Unless otherwise stated, all of the events/signals are
 detected/applied on endpoints and audio generated by them is not
 forwarded on any connection the endpoint may have.  Audio generated
 by events/signals that are detected/applied on a connection will
 however be forwarded on the associated connection irrespective of the
 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 the
 "MS" package:
    Table 5 "MS" Package Events and Signals

———————————————————————

CodeDescription EventSignal 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 the
 "DT" package:
   Table 6 "DT" Package Events and Signals

———————————————————————

CodeDescription EventSignal 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 the
 "BL" package.  This package looks very much like a simplified line
 package:
        Table 7 "BL" Package Events and Signals

———————————————————————

CodeDescription EventSignal 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 -
relRelease - 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 the
 "DO" package:
   Table 8 "DO" Package Events and Signals

———————————————————————

CodeDescription EventSignal 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 the
 "MD" package.
  Table 9 "MD" Package Events and Signals

———————————————————————

CodeDescription EventSignal 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 the
 "MO" package.
  Table 10 "MO" Package Events and Signals

CodeDescription EventSignal Additional Info
———————————————————————
ans Call Answer !Note P -
oc Operation Complete x -
of Operation Fail x -
orbkOperator 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 received
     from the far end which simply indicates that the destination
     address was received properly and the calling number is in the
     process of being outpulsed.

2.7. Event and Signal Descriptions

 The following provides a list of the event and signal descriptions.
 The event/signal name appears in parenthesis followed by the
 corresponding Event + Signal attribute code plus a list of the
 packages in which the event/signal occurs.
 Call answer (ans; P + BR; DT,MD,MS,MO): Off-hook signal normally
 indicates that the call has been answered and that cut-through has
 been established.  The exception is the "MO" package where it simply
 indicates that off-hook was received and the calling number is in the
 process of being sent (i.e., there is no event available to indicate
 that the operator answered the call for operator services signaling).
 Acknowledgement Wink (awk; P + BR; MD): This event is only applicable
 to the "md" package.  It provides an indication that all digits have
 been received correctly.  In an outgoing trunk, the event is
 requested and when received indicates that the connecting switch

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 addressing
 information has been received.  If the Call Agent is providing a
 transit application for example, in which incoming and outgoing
 trunks are both EANA trunks, then after acknowledgement wink is
 received from the terminating trunk, it is passed to the originating
 side so that the originating side knows that addressing has passed to
 the destination switch.
 Call Block (bl; S + BR; DT,MS,MD): A steady off-hook signal applied
 to one-way incoming trunks to indicate that no further calls will be
 accepted.  When "bl" is used as a signal then the "rel" signal is
 used to release the blocking condition.
 A Call Agent should only request the "bl" event in a case where it
 knows that this is a one-way outgoing trunk, and it should never see
 an incoming call-setup request ("sup" event).  As such if "bl" is
 requested as an event, then "sup" is suppressed as a persistent
 event.
 Busy tone (bz ; - + TO; BL,DT,MD,MS): Refer to ITU E.180.  The
 definition of the tone is defined by the national characteristics and
 may be established via provisioning.  Station Busy is defined in GR-
 506-CORE - LSSGR, SIGNALING, Section 17.2.6. as a combination of two
 AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm
 each, to give a combined level of -21 dBm.  The cadence for Station
 Busy Tone is 0.5 seconds on followed by 0.5 seconds off, repeating.
 Caller Id (ci(time, number, name); x + -; DO): See TR-NWT-001188,
 GR-30-CORE, and TR-NWT-000031.  Each of the three fields are
 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 value
    for Day between 1 and 31, and Hour and Minute are two-digit values
    coded according to military local time, e.g., 00 is midnight, 01
    is 1 a.m., and 13 is 1 p.m.
    The number parameter is coded as an ASCII character string of
    decimal digits that identify the calling line number.  White
    spaces are permitted if the string is quoted, however they
    will be ignored.
    The name parameter is coded as a string of ASCII characters that
    identify the calling line name.  White spaces are permitted if the
    string is quoted.

Foster Informational [Page 14] RFC 3064 MGCP CAS Packages February 2001

 A "P" in the number or name field is used to indicate a private
 number or name, and an "O" is used to indicate an unavailable number
 or name.  The following example illustrates the use of the caller-id
 event:
    O: ci(10/14/17/26, "555 1212", somename)
 Continue Wink (cwk ; - + BR; MD): This signal is only applicable to
 the "md" package.  It provides an indication that digits sent have
 been accepted, and further digits must be sent in order to process
 the call.  For example, when using FGD EAIN signaling, this would
 correspond to sending a wink after the country access code had been
 received to indicate readiness to receive identification and address
 fields.
 Dial-tone (dl ; - + TO; BL,DT): Refer to ITU E.180.  The definition
 of the tone is defined by the national characteristics and may be
 established via provisioning.  In GR-506-CORE - LSSGR, SIGNALING,
 Section 17.2.1, sial Tone is defined as a combination of two
 continuous AC tones with frequencies of 350 and 440 Hertz and levels
 of -13dBm each to give a combined level of -10 dBm.  It is considered
 an error to try and play dial-tone on a phone that is on hook and an
 error should consequently be returned when such attempts are made
 (error code 402 - phone on hook).
 Information Digits (inf(<inf-digits>); x + TO; MS,MD): On an outgoing
 call ("md" package only) it is used as a signal to out-pulse the
 address information when doing overlapped sending.
 On an incoming call it is used as an event to indicate that an MF
 digit string has been received.  In this case, <inf-digits> are all
 of the digits accumulated up to and including the digit delimiters
 ST, ST', ST'', ST'''.  Multiple sequences of digits ending with one
 of the ST digits may be passed in a single "inf" event.  (Note that
 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 <inf-digits> is a comma separated list of MF digits:
 MF1, MF2, ..., MFn
 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 Symbols
  1. ————————

| 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 would
 appear as follows:
    inf(k0, 5,5,5)
 Operation Complete (oc ; x + -; all): The operation complete event is
 generated when the gateway was asked to apply one or several signals
 of type TO on the endpoint, and one or more of those signals
 completed without being stopped by the detection of a requested or
 persistent event such as setup.  The completion report may carry as a
 parameter the name of the signal that came to the end of its live
 time, as in:
    O: ms/oc(ms/sup)
 or
    O: bl/oc(bl/rg)
 When the operation complete event is requested, it cannot be
 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-pulsing
 - a TO event), the operation complete event will indicate when out-
 pulsing is complete.
 Operation failure (of; x + -; all):  In general, the operation
 failure event may be generated when the endpoint was asked to apply
 one or several signals of type TO on the endpoint, and one or more of
 those signals failed prior to timing out.  The completion report may
 carry as a parameter the name of the signal that failed, as in:
     O: ms/of(ms/sup)
 or
     O: bl/of(bl/rg)
 When the operation failure event is requested, it cannot be
 parameterized with any event parameters.
 Operator ringback (orbk; x + -; MO): The description of the signaling
 MF CAS signaling that results in this event is describe in the
 appendix of TR-NPL-000258 [3].  In brief, it is normally a wink-on
 signal which may or may not be followed by an MF tone.  This event
 will be generated when the operator service requests that the calling
 party be alerted ("mo" package only).
 Reverse make busy (rbz; P + -; MO): This event corresponds to a
 "blocking" (off-hook) generated by the other end of the one-way
 operator services trunk ("mo" package).  It has the same semantics as
 of the "bl" event in other packages.
 Operator recall (rcl; - + BR; MO): This signal may be applied to
 invoke operator recall, e.g., due to customer hook-flash to bring the
 operator back.
 Release call (rel; P,S + BR; BL,DT,MD,MO,MS,DO): A "rel" signal sent
 by the Call Agent to the Media Gateway is a request to release all of
 the resources associated with the telephony leg of the call.  This
 may also result in an off-hook signal being sent when appropriate.
 As a result of an "rel" signal, the gateway will respond with an
 "rcl" event, whenever the resources have been released.  Releasing
 resources associated with the telephony leg of the call does not
 affect existing connections (network legs).  It's up to the Call
 Agent to send the appropriate delete connection commands in order to
 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 to
 provide a tip-ground release for ground-start trunks.  In the case of
 loop-start trunks, requesting to play this signal has no effect.
 The Media Gateway generates a "release call" event whenever a call is
 released as a result of an on-hook event from an originating end of a
 call (normal release) or due to abnormal event that resulted in
 releasing the call.  The event may be parameterized with one of the
 following cause codes indicating the reason for the release:
            Table 12 Release Reason Codes
    -----------------------------------------------------------------
   |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 normal
 release (due to an incoming on-hook) will only be "notified" by a
 gateway where a call origination occurred.  This behavior follows the
 rule that when an originator releases the call, all resources may be
 released.  The corresponding event for on-hook on the terminating end
 of a call is the "sus" event which only indicates hook-status and
 does not result in any resources being released.  It is always up to
 the Call Agent to release the call (by sending the "rel" signal) for
 the terminating end of a call.
 For FXO ground-start case ("DO" package), the Media Gateway generates
 a "release call" event whenever a call is released as a result of a
 tip-ground release event from the far end.
 Resume call (res ; P + BR; DT,MD,MS,MO): This indicates that the
 called party resumed the call, i.e., the party went off-hook after a
 previous suspend ("sus") but before the originating switch released
 ("rel") the trunk.  The "sus" and "res" events/signals are used to
 propagate on-hook and off-hook events without releasing the resources
 associated with the call.  In all but the operator services case
 ("MO" package), these events would normally be propagated from the
 terminating to the originating end (i.e., requested as events from
 the terminating end of the call and sent to the gateway as signals to
 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 do
 "suspend"/"resume" processing.  If it doesn't, when it receives a
 "sup" event from the terminating end of the call it can simply go
 ahead and tear down the call immediately (send "rel" and delete
 connections to the endpoints on gateways at both originating and
 terminating end of the call).
 In the case of operator services and 911, "sus" and "res" are used to
 pass off-hook and on-hook signals to the operator without releasing
 any of the resources associated with the call.
 Ringing (rg; P,S + TO; BL,DO): This signal is used for outgoing basic
 trunks ("bl" package).  See GR-506-CORE - LSSGR: SIGNALING, Section
 14.  The provisioning process may define the ringing cadence.  It is
 considered an error to try and ring if the trunk indicates off hook
 and an error should consequently be returned when such attempts are
 made (error code 401 - phone off hook).
 In the case of the "DO" package, "rg" is defined as an event used to
 indicate detection of ringing.
 Release complete (rlc;P,S + BR; DO,DT,MD,MO,MS): The endpoint and
 Call Agent use the release complete event/signal to confirm the call
 has been released and the trunk is available for another call.  For
 FXO ground-start ("DO" package), this represents the release of the
 tip-ground event from the PBX after the gateway goes on-hook.
 Reorder tone (ro; - + TO; BL,DT,MD,MS): Reorder tone is a combination
 of two AC tones with frequencies of  480 and 620 Hertz and levels of
 -24 dBm each, to give a combined level of -21 dBm.  The cadence for
 reorder tone is 0.25 seconds on followed by 0.25 seconds off,
 repeating continuously.  See GR-506-CORE - LSSGR: SIGNALING, Section
 17.2.7.
 Ring back tone (rt; - + TO; BL,DT,MD,MS): Audible Ring Tone is a
 combination of two AC tones with frequencies of 440 and 480 Hertz and
 levels of -19 dBm each, to give a combined level of -16 dBm.  In the
 US the  cadence for Audible Ring Tone is defined to be 2 seconds on
 followed by 4 seconds off.  The definition of the tone is defined by
 the national characteristics of the Ring-back Tone, and MAY be
 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 used
 both for outgoing and incoming call setups.  Each will be described
 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 and
 out-pulse digits.  The "sup" signal is parameterized with up to four
 parameters sup(<ct>, <ca>, <id>, <addr>), depending on the package.
 The order of these parameters does not matter.  The following table
 indicates which ones are mandatory ("M"), optional ("O") or forbidden
 ("F") for the various packages.
             Table 13 "sup" parameters.
  1. ———————————–

| Parameter | MS | DT | MO | MD | DO |

            |------------------------------------|
            |    <ct>   |  F |  F |  F |  M |  F |
            |    <ca>   |  F |  F |  F |  O |  F |
            |    <id>   |  F |  F |  M |  M |  F |
            |   <addr>  |  M |  M |  M |  O |  M |
             ------------------------------------
 The <ct> parameter is of the format ct(<ct-value>) where <ct-value>
 indicates the CAS signaling type and can have one of two values "nda"
 (North American Direct Access) for EANA and "nta" (North American
 Tandem Access) for EAIN.  The reason this parameter is needed in the
 case of trunks that handle the "MD" packages is because the same
 trunk can be used for both.  The <addr> field contains the
 destination number and when present will be on the form
       addr(dig1, dig2, ..., dign)
 The <id> field contains the identification of the caller and when
 present will be of the form:
      id(dig1, dig2, ..., dign)
 The <ca> field  contains the country address information and when
 present will be of the form:
      ca(dig1, dig2, ..., dign)
 When present, the <addr> field contains the destination number and
 will be of the form
     addr(dig1, dig2, ..., dign)
 where digi is an MF symbol as defined in table 11 in the case of
 "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 Gateway
 (MG) and the Switched Circuit Network (SCN) for single stage
 outpulsing applications ("DT", "MS" and "DO" packages):
  Table 14 SCN Sequencing during Call Setup (single stage outpulsing)
  1. —————————————————————–

|Interface Type |Setup | Interactions |

 |------------------------------------------------------------------|
 |wink start     |sup(add(<addrvalue>))     |MG|  off-hook ->   |SCN|
 |               |                          |MG|  <- wink       |SCN|
 |               |                          |MG| <addrvalue> -> |SCN|
 |------------------------------------------------------------------|
 |Immediate Start|(sup(addr(<addrvalue>))   |MG|  off-hook ->   |SCN|
 | or FXO)       |                          |MG| <addrvalue> -> |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 multiple
 parameters.  In the case of the "MD" package the following table
 shows some of the interactions:
    Table 15 SCN Sequencing during Call Setup (EANA and EAIN)
  1. —————————————————————–

|Setup | Interactions |

 |------------------------------------------------------------------|
 | sup(ct(nda),addr(<addrvalue>),           |MG|  off-hook ->   |SCN|
 | id(<idvalue>))                           |MG|  <- wink       |SCN|
 |                                          |MG|  <idvalue> ->  |SCN|
 |                                          |MG| <addrvalue> -> |SCN|
 |------------------------------------------------------------------|
 | sup(ct(nta), ca(<cavalue>),              |MG|  off-hook ->   |SCN|
 | addr(<addrvalue>), id(<idvalue>))        |MG|  <- wink       |SCN|
 |                                          |MG|  <cavalue> ->  |SCN|
 |                                          |MG|  <- wink       |SCN|
 |                                          |MG|  <idvalue> ->  |SCN|
 |                                          |MG| <addrvalue> -> |SCN|
 |------------------------------------------------------------------|
 | sup(ct(nta), ca(<cavalue>),              |MG|  off-hook ->   |SCN|
 |    id(<idvalue>))                        |MG|  <- wink       |SCN|
 |                                          |MG|  <cavalue> ->  |SCN|
 |                                          |MG|  <- wink       |SCN|
 |                                          |MG|  <idvalue> ->  |SCN|
  ------------------------------------------------------------------

Foster Informational [Page 21] RFC 3064 MGCP CAS Packages February 2001

 The last example is an overlapped sending example where the address
 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 case
 of the operator service signaling (OSS) protocol of Feature Group D -
 shown in the following table, off-hook from the operator is part of
 the protocol (a request for the calling number) so that "ans" in this
 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)
  1. —————————————————————–

|Setup | Interactions |

 |------------------------------------------------------------------|
 | sup(ct(nda),addr(<addrvalue>),           |MG|  off-hook ->   |SCN|
 | id(<idvalue>))                           |MG|  <- wink       |SCN|
 |                                          |MG| <- off-hook    |SCN|
 |                                          |MG| <addrvalue> -> |SCN|
 |                                          |MG|  <idvalue> ->  |SCN|
  ------------------------------------------------------------------
 Incoming Call Setup: A "sup" event is used to indicate when an
 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" event
 for interfaces that use the "MS", "DT" and "MD" packages from an
 endpoint at a terminating end of a call (as compared to a "rel" event
 from the originating side).  The "sus" event from the terminating
 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 originating
 party without releasing the resources associated with the telephony
 leg of the call.  The "rel" signal on the other hand would send an
 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 allow
 the call to resume, while "rel" cannot be followed by "res" because
 the call no longer exists.
 For E911 ("MO" package), the operator is normally in control of
 releasing the call so that, "sus" (on-hook), "res" (off-hook) and
 "rcl" (flash-hook) can be used to pass user hook events to the
 operator without releasing the call.
 Start Wink (swk; x + - MD,MO):.  An Call Agent can optionally request
 the MG to notify it when the wink start signal occurs.  Note that
 wink start ("swk") cannot be applied by the Call Agent as a signal.
 The occurrence of wink-start on an incoming trunk is a reflexive
 action that does not require Call Agent involvement.

3.0. Hook-State Signals and Events

3.1. Overview of Approach

 As mentioned in the introduction, a higher level view is taken for
 on-hook and off-hook events for many of the CAS packages to make the
 interface Q.931-like.  This provides the advantage that:
  • Similar call flows result as when dealing with Q.931-based

interfaces (e.g., PRI)

  • It's more evident (for ease in debug) when looking at message as

to exactly what is going on without having to refer to previous

    flows.
 This does require that media gateways maintain some state but this is
 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 is
 also used to represent off-hook but from the terminating end at the
 point where the call is answered.

3.2. Suspend/Resume Processing

 Other signals and events "sus" for suspend, "res" for resume and
 "rel" for release are based on the concept that one end (the
 originator) is in control of the call.  If the controlling end goes
 on-hook a "rel" is notified to the Call Agent, and results in a the
 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/resume
 processing.

Foster Informational [Page 23] RFC 3064 MGCP CAS Packages February 2001

 If the Call Agent decides not to do suspend/resume processing, it can
 simply send "rel" and delete connection commands to the endpoints
 after it receives "sus" from the non-controlling (terminating) end of
 the call.
 On the other hand, if it decides to do suspend/resume processing, it
 can start a timeout when it receives the "sus" event from the non-
 controlling (terminating) end of the call and continue the call if it
 receives a "res" (off-hook) event.  It also has the option of
 propagating the "sus" and "res" as signals back to the ingress
 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 another
 level of control over the "rel" signal which will not only send on-
 hook but also release the resources associated with the telephony leg
 of the call.

3.3. Control over Disconnect for E911

 Note that for E911 (the "MO" package) is a special case in that the
 operator (terminating end) is always the controlling end.  The "sus"
 and "res" signals are used to pass user hook state forward to the
 operator.  The "rel" event is passed back as a notify to the Call
 Agent when on-hook is received from the operator indicating that the
 Call should be released.  If the "rel" is not received the call
 should continue to stay up.

3.3. Release and Release Complete

 The "rel" signal/event generally means on-hook but more that that it
 also indicates "release of resources" for the telephony leg of the
 call.  If a Call Agent sends a "rel" signal instead of "sus" it is
 requesting the call to be abandoned (i.e., "rel" cannot be followed
 by "res").
 The "rel" signal does not also imply that connections should be
 deleted so that to completely release the call including connections
 would require a DLCX in addition to (or conjunction with) the signal
 "rel".
 In addition to being a signal, "rel" can also be an event triggered
 by either:
  • An on-hook from the controlling end of the call, or
  • Some abnormal event within the media gateway such that the

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 that
 the trunk resources are now completely released and available for
 another call.  This is also an event state that can be audited as
 indicated by the "S" in the column for that event (allowing the Call
 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 an

outgoing off-hook being sent for that trunk. When the media

    gateway receives the on-hook from the other end, it returns an
    "rlc" event indicating that the trunk is released and available.
  * The media gateway receives a on-hook from the trunk at the
    controlling end of the call, resulting in a "rel" event being sent
    to the Call Agent.  The Call Agent then sends an "rlc" to the
    media gateway, resulting in on-hook being sent in the opposite
    direction.
  * An "rel" event is sent to the Call Agent in the event of some
    abnormal condition in which the media gateway is unable to sustain
    the telephony leg of the call (e.g., glare condition).  The Call
    Agent sends an "rlc" to the gateway to complete the release of the
    call. (note that "rlc may not correspond to on-hook but is
    generally sent anyway in response to a "rel".)
  * The Call Agent can send a "rel" (instead of "sus") signal to the
    controlling (originating) end of the call to abandon the call.
    The gateway will return with "rlc" when an off-hook has been
    received from the other end and all the resources have been
    released.
  * A "rel" can be sent on one-way incoming trunk to release a block
    ("bl") sent earlier.
 The "BL" (FXS) package is a simple line package, so does not have
 these events (uses "hd", "hf", and "hu" as the only hook state
 events).
 The "DO" (FXO) package, however, does have "rel" and "rlc" because in
 the ground-start case there is the ability to "release" the call as
 result of a tip-ground release.  The signal "rel" is used if the PBX
 releases the call first (followed by S: hu from the call Agent to
 complete the release).  Alternatively, the Call Agent can send the S:
 hu to initiate the release  - followed by an "rlc" event from the
 media gateway to Call Agent when the PBX does the tip ground release.
 Although the loop-start trunks would not normally have this behavior
 (only applies to ground-start), the media gateway should emulate the
 behavior in the case of loop-start in order to allow the Call Agent a
 common interface.

Foster Informational [Page 25] RFC 3064 MGCP CAS Packages February 2001

3.4. Blocking CAS Trunks

 In addition to the above signals and events, there is the "bl"
 signal/event which is used for blocking one-way trunks (does not work
 for two way trunks) by providing a continuous off-hook.

3.5. Summary of Hook-State Events

 The following summarizes the use of the various events that involve
 off-hook and on-hook from call establishment to tear-down.  This
 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 digit

outpulsing on the terminating side.

  • Once outpulsing is completed, an "ans" event indicates off-hook

from the termination side (the called party has answered).

  • The call agent can then send an "ans" signal (off-hook) to the

originating end to indicate to the caller that the called party

    has answered.
  * The Call Agent can send a "rel" to either end at any time to tear
    down the call (e.g., to abort the call).
  * The media gateway can send "rel" to indicate abnormal termination
    of the call (with a reason as a parameter).
  * However, under normal operation once a call is established, the
    Call Agent can expect a "sus" (suspend) event from the termination
    end to indicate that the caller went on-hook and a "res" if the
    called party goes off-hook again before the Call Agent tears down
    the call.  The Call Agent can send these same signals to the
    originating end to indicate off-hook and on-hook to the calling
    party without tearing down the call.
  * During normal operation, once the call is established, on-hook
    from the calling party (origination side) would result in a "rel"
    signal.  The Call Agent would then normally send the "rel" signal
    to the terminating end to terminate the call.  "rel is normally
    followed by "rlc" (e.g., media gateway indicates calling party on-
    hook with "rel" and the Call Agent responds with "rlc", which
    sends on on-hook back to the calling party to indicated release
    complete.
 The "MO" package is a bit different in that normally only the
 terminating side (the operator) can release the call ("rel" event).
 The "sus" and "res" are forward signals to the operator indicating
 user hook-status.

Foster Informational [Page 26] RFC 3064 MGCP CAS Packages February 2001

4.0. Glare Handling

4.1. Glare on MF Bi-directional Wink-start Trunks

 Gateways may have a configurable glare bit on a per-DS0 basis that
 can be set to indicate whether the gateway is the controlling or
 non-controlling "switch".  However, in general, PBXs are either pre-
 configured or can be configured to behave as non-controlling
 switches.  In this case if they see an off-hook that exceeds
 allowable wink length, they will attach a receiver, go on-hook, and
 await digits for a new call.  Meanwhile the PBX will retry its
 original call on another trunk.
 If the gateway behaves like a controlling switch, when glare is
 detected, the gateway will wait for up to some timeout value (default
 value of 4 seconds) until the incoming off-hook changes to an on-hook
 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, the
 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 the
 Call Agent that the call is in the process of being released and that
 the Call Agent should give up on that trunk.  However, the gateway
 may not actually want to send the on-hook at that time in order to
 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 of
 time (e.g., 16 seconds or so) before releasing the trunk.  If it
 receives an on-hook prior the timeout, it completes the release by
 going on-hook.  If, on the other hand, the timer expires before the
 other end goes on-hook, it will simply go on-hook and wait for the
 other end to go on-hook.  In any case, once both ends have returned
 to the on-hook state, an "rlc" event is sent to the Call Agent.

4.2. Glare Handling - Basic PBX Trunks

 In order to reduce the chances of glare, the gateway should try a
 ringing pre-trip test prior to sending ringing on a basic ground
 start trunk.  If glare is detected on an outgoing seizure of a basic
 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 Flows

5.1. PBX to PBX ("MS", "DT, and "BL" packages).

 The following call flows involve a single Call Agent that handles
 both sides of the call (i.e., the inter-Call-Agent signaling is
 ignored).  The components involved in the call are:
  • The Call Agent (CA)
  • The originating Media Gateway (GW-o) and
  • The terminating Media Gateway (GW-t)

5.1.1. Call Setup Flows

 The following describes some PBX to PBX call.  The table gives an
 overview of the initial part of the call flow with details to follow.
  1. ——————————————————————–

| 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 Agent
 indicating the start of a call setup:
       NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       X: 0123456789AF
       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 looks
     like a simplified line interface with the standard "hd" event for
     off-hook:
       NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       X: 0123456789AF
       O: bl/hd
 Another alternative would have been to use an embedded request in the
 RQNT that resulted in this notify and combine that request with step
 A3.  Example - "ms" package:
       RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       X: 0123456789AF
       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: 0123456789AF
       Q:loop
       R: ms/sup, ms/inf, ms/rel
 This would result in both notifies occurring without requiring the
 RQNT in step A3.
 Step A2   The Call Agent sends an Ack:
       200 3001 OK
 Step A3   The Call Agent requests that digits be collected.  The
 approach used here depends on the type of  PBX interface.  For an MF
 interface the Call Agent requests that information digits be
 collected as follows:
       RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       X: 0123456789B0
       R: ms/inf, ms/rel
     The Call Agent also asks to be told if the trunk gets released
     for some reason ("rel" event) in the process of call setup
     (release event may be due to some signaling error for example).
     For DTMF trunks (wink-start, immediate start and Basic PBX), the
     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: 0123456789B0
       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/dl
       Note: the request to signal dial-tone may or may not be here
       depending on PBX interface requirement - bl/dl  required for
       Basic PBX;  dt/dl for some Immediate Start interfaces.
 Step A4   The gateway responds with an ack:
       200 2001 OK
 Step A5   Once the digits are collected the gateway notifies the call
 agent.  In the case of an MF interface, the resulting notify will
 look like the following
       NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       X: 0123456789B0
       O: ms/inf(k0,5,5,5,1,2,3,4,s0)
     In the case of a DTMF interface (including Basic PBX), it will
     look like the following:
       NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       X: 0123456789B0
       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 OK
 Step B1   The Call Agent now requests that a receive-only connection
 be made.
       CRCX 2002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       C: A7453949499
       L: a:PCMU,s:off,e:on
       M: recvonly
       X: 0123456789B1
       R: ms/rel (or dt/rel or bl/hu).
 Step B2   The Gateway acks with a connection ID and provides the SDP
 information:
       200 2002 OK
       I: 23474FE

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 the
 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:on
       M: sendrecv
       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 with
 this CRCX, although in this call flow - it is shown later (step C1).
 Step B4   The terminating gateway, responds with an ack and its SDP
 information:
       200 4001 OK
       I: 34738A
       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 with
 connection mode receive-only to the origination gateway and includes
 the SDP information with the selected profile from the termination
 gateway.
       MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       C: A7453949499
       I: 34738A
       M: recvonly

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 request
       200 2003 OK
 The following table shows the remainder of the call flow to set up
 the call except for Basic PBX (Basic PBX shown in) with details to
 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 terminating
 gateway The setup request for an MF PBX interface (wink start or
 immediate start) will be the following:
       RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       X: 45375841
       Q: loop
       S: ms/sup(addr(ko,5,5,5,1,2,3,4,s0))
       R: ms/oc, ms/rel, ms/ans
     Note that the result of the "sup" signal is the following
     sequence on the interface to the PBX:
  • off-hook → PBX
  • wink → PBX (for wink-start trunks; for immediate start this

part of the sequence does is not included)

  • Digits sent to PBX

Foster Informational [Page 32] RFC 3064 MGCP CAS Packages February 2001

     For DTMF PBX interface (except Basic PBX), the only difference is
     that the MF start and end delimiters (k0 and s0) are not
     included:
       RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       X: 45375841
       Q: loop
       S: dt/sup(addr(5,5,5,1,2,3,4))
       R: dt/oc, dt/rel, dt/ans
     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: loop
       S: bl/rg,bl/rt@34738A
       R: bl/oc,bl/hd
     In this case ringback will come from the gateway and will start
     immediately with the signal request for rt@connectionID.  It will
     end as soon as an event occurs (off-hook representing answer
     event) In the case of other PBX's, the ringback tone comes from
     the PBX so does not have to be generated by the gateway.
     Note that these requests could be done as easily at the same time
     as the connection request (B3) saving some post-dial delay time.
 Step C2   The gateway responds with an ack:
         200 4002 OK
 Step C3   Except  for the basic PBX, case (where digits are not
 outpulsed) when the digits have completed being sent out, the gateway
 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 notify
       200 1001 OK
     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-hook
 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 acks
       200 1002 OK
 Step C7   The Call Agent now sends a request to make the connection
 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: 34738A
       M: sendrecv
       S: ms/ans ( or dt/ans but S: not included in the case where the
       originating gateway uses the BL package)
 Step C8   The Gateway acks the request
       200 2004 OK
 Step C9   The Call Agent sends a notification request to be told
 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 request
       200 4003 OK
     The call is now setup.

5.1.2. Call Tear-Down

 Two cases are included here, one where the origination end initiates
 the release (section 5.1.2.1) and one where the termination end
 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 Release

 The following call flow shows an example where the origination end
 initiates the release for the "MS" package (similar for "DT"
 Package).
  1. ——————————————————————-

| 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 below
  1. ——————————————————————–

| 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 Notify
 from the gateway to indicate that the trunk is being released (reason
 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 Notify
       200 3005 OK
 Step A3   The Call Agent sends a request to release the trunk.  (For
 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 played
       RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       X: 45375843
       S: bl/dl
       R: bl/hu
 Step A4   The Gateways acks the request
       200 4004 OK
 Step A5   The other end releases the call by going on-hook and a
 Notify is sent to the Call Agent to indicate that release is
 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/hu
 Step A6   The Call Agent returns an Ack
       200 1004 OK

Foster Informational [Page 36] RFC 3064 MGCP CAS Packages February 2001

 Step A7   The Call Agent sends a delete connection to the originating
 gateway with a request to do a release complete (which results in
 sending on-hook to the PBX).
       DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
       X: 45375844
       I: 34738A
       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: 34738A
       R: bl/hd
 Step A8   The Gateway  Acks and provides performance information.
       250 4005 OK
       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: 0123456789B3
       I: 23474FE
       R: ms/sup (or dt/sup or bl/hd)
 Step A10  The gateway acks with performance information
       250 2004 OK
       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. Termination End Initiates the Release

 The following call flow gives an example of the terminating end
 releasing a call for all but Basic PBX ("MS" package - "DT" package
 is similar).

Steps GW-o CA GW-t
———————————————————————
A1 ← NTFY[O: ms/sus]
A2 Ack →
A3 ← RQNT [S: ms/sus, R: ms/rel ]
A4 Ack →
A5 RQNT [R: ms/res] →
A6 ← Ack
A7 NTFY [O: ms/rel] →
A8 ← Ack
A9 DLCX [S: ms/rel, R: ms/rlc] →
A10 ← Ack [perf info]
A11 ← Notify [O: ms/rlc]
A12 Ack →
A13 ← DLCX [S: ms/rlc, R: ms/sup ]
A14 Ack [perf info] →

———————————————————————

 The following shows the same call flow but for Basic PBX.  There is
 no equivalent to steps A3-A6 and A11-A12 - so these are not included.

Steps GW-o CA GW-t
———————————————————————
A1 ← NTFY[O: bl/hu]
A2 Ack →
A7 NTFY [O: bl/hu] →
A8 ← Ack
A9 DLCX [R: bl/hd] →
A10 ← Ack [perf info]
A13 ← DLCX [bl/hd]
A14 Ack [perf info] →

———————————————————————

 Step A1   An on-hook is received from the PBX.  In the case of all
 but the "BL" package, this results in a notify with event "sus" for
 suspend.

Foster Informational [Page 38] RFC 3064 MGCP CAS Packages February 2001

 Step A2   The Call Agent returns an acknowledge
     The Call Agent starts a timer at this point (typically 10
     seconds).  If an off-hook is received from the PBX connected to
     GW-t before the origination side releases, the call is continued
     (this would appear as a "res" event  or "hd" in the case of Basic
     PBX interface).  If the origination side goes on-hook or the
     timer expires, then the call is torn down.
     Note that for Basic PBX (the "BL" package), steps A3 - A6 are
     missing (these steps do not exist for basic PBX).
 Step A3   A "sus" signal is sent to the originating side resulting in
 a on-hook being sent to the originating PBX.
 Step A4   GW-o acks the request.
 Step A5   The Call Agent sends a request to see off-hook  or resume
 ("res") events.
 Note: this depends on whether the Call Agent wants to do
 suspend/resume processing.  If not, the Call Agent may simply send
 "rel" along with DLCX to both ends.
 Step A6   GW-t acks the request.
 Step A7   An on-hook is received from the originating PBX resulting
 in a notify from GW-o with event "rel" ("hu" for Basic PBX
 interface).
 Step A8   The Call Agent "acks"
 Step A9   A delete connection is sent to the terminating gateway with
 signal "rel" which results in on-hook being sent to the terminating
 PBX (except for basic PBX - where there is no such signal)
 Step A10  GW-t acks the DLCX and provides performance information
     Steps A11 and A12  do not exist for the basic PBX case.
 Step A11  GW-t returns an "rlc" event
 Step A12  The Call Agent "acks" the notify
 Step A13  A delete connection is sent to the originating side (with
 signal "rlc" except in the case of the "BL" package).
 Step A14  GW-o returns an "ack" with performance information.

Foster Informational [Page 39] RFC 3064 MGCP CAS Packages February 2001

5.2. Example Call Flows - "DO" package

5.2.1. Call Setup Flows

 The following describes some PBX to PBX call.  The table gives an
 overview of the initial part of the call flow with details to follow.

Steps GW-o CA GW-t
———————————————————————
A1 NTFY[O: do/rg] →
A2 ← Ack
B1 ← CRCX [S: do/hd, R: do/rel, M:recvonly, LCO]
B2 Ack[SDP1] →
B3 CRCX [M:sendrecv, LCO, SDP1] →
B4 ← Ack [SDP2]
B5 ← MDCX [recvonly,SDP2]
B6 Ack →
C1 RQNT [S: do/sup, R: do/oc] →
C2 ← Ack
C3 ← NTFY [O:do/oc(do/sup)]
C4 Ack →
C5 ← MDCX [M:sendrecv, R: do/rel]
C6 Ack →
C7 RQNT[R: do/rel] →
C8 ← Ack

———————————————————————

 Step A1   PBX rings results in a notify to the Call Agent indicating
 the start of a call setup:
       NTFY 3001 aaln/0@gw-o.whatever.net MGCP 1.0
       X: 0123456789AF
       O: do/rg
 Step A2   The Call Agent sends an Ack:
 Step B1   The Call Agent now requests that a receive-only connection
 be made.
     If the endpoint is running FXO ground-start, the call would also
     request detection of disconnect supervision from the PBX (R:
     do/rel) and should send an off-hook (S: do/hd) in response to
     ringing.
 Step B2   The Gateway acks with a connection ID and provides the SDP
 information.

Foster Informational [Page 40] RFC 3064 MGCP CAS Packages February 2001

 Step B3   The Call Agent passes this SDP information to the
 terminating gateway (GW-t) as part of the connection request.
 Step B4   The terminating gateway, responds with an ack and its SDP
 information.
 Step B5   Call Agent sends a modify connection request with
 connection mode receive-only to the origination gateway and includes
 the SDP information with the selected profile from the termination
 gateway.
 Step B6   The Gateway Acks the modify connection request
 Step C1   The Call Agent does a setup request to the terminating
 gateway The setup request will be the following:
       RQNT 4002 aaln/0@gw-t.whatever.net MGCP 1.0
       X: 45375841
       S: do/sup(addr(5,5,5,1,2,3,4))
       R: do/oc
     Note that the result of the "sup" signal is the following
     sequence on the interface to the PBX:
  • off-hook → PBX
  • tip-ground ← PBX (for loop-start this step does not apply)
  • digits sent to PBX
 Step C2   The gateway responds with an ack:
       200 4002 OK
 Step C3   When the digits have been completely sent out, the gateway
 will notify the fact by indicate that the operation is complete.
       NTFY 1001 aaln/0@gw-t.whatever.net MGCP 1.0
       X: 45375841
       O: do/oc(do/sup)
 Step C4   The Call Agent acks the notify
       200 1001 OK

Foster Informational [Page 41] RFC 3064 MGCP CAS Packages February 2001

 Step C5   The Call Agent now sends a request to make the connection
 full duplex and indicates that the other end has answered the phone.
     If the endpoint is running FXO ground-start, the call would also
     requests detection of disconnect supervision from the PBX
     (R:do/rel)
 Step C6   The Gateway acks the request
 Step C7   If the endpoint is running FXO ground-start, the Call Agent
 sends a notification request to be told  when the trunk to be
 released (R: do/rel).  This step and step C8 are not needed if the
 endpoint is running FXO loop-start.
 Step C8   The gateway acks the request and the call is now setup.

5.2.2. Call Tear-Down

 If the endpoint is running FXO loop-start, the PBX cannot
 initiate call release.  In this case, call release is always
 initiated by the Media Gateway by going onhook.  Disconnect
 supervision from the PBX is provided only for FXO ground-start.
 However, it does not matter whether the origination end or the
 termination end initiates the release.  The call flows for either
 case are the same.  Therefore, only the case where the origination
 end initiates the release is illustrated in this section.

Steps GW-o CA GW-t
———————————————————————
A1 NTFY[O: do/rel] →
A2 ← Ack
A3 RQNT [S: do/hu, R: do/rlc] →
A4 ← Ack
A5 ← NTFY [O: do/rlc]
A6 Ack →
A7 ← DLCX [S: hu, R: rg]
A8 Ack [perf info] →
A9 DLCX [R: do/rg]→
A10 ← Ack [perf info]

———————————————————————

Foster Informational [Page 42] RFC 3064 MGCP CAS Packages February 2001

 Step A1   The originating PBX goes on-hook resulting in a Notify from
 the gateway to indicate that the trunk is being released (reason
 indicating normal release).
       NTFY 3005 aaln/0@gw-o.whatever.net MGCP 1.0
       X: 45375842
       O: do/rel(0)
 Step A2   The Call Agent Acks the Notify
       200 3005 OK
 Step A3   The Call Agent sends a request to release the trunk.
 Step A4   The Gateways acks the request
 Step A5   PBX at the terminating end releases the call by releasing
 tip-ground and a Notify is then sent to the Call Agent to indicate
 that release is complete.
     Note that there is no ground signal in case of loop-start.
     However, this NTFY message is still generated as soon as hu
     signal is applied.
 Step A6   The Call Agent returns an Ack
 Step A7   The Call Agent sends a delete connection to the originating
 gateway with a request to go onhook.
 Step A8   The Gateway  Acks and provides performance information.
 Step A9   The Call Agent sends a DLCX to the terminating gateway.
 Step A10  The gateway acks with performance information

Foster Informational [Page 43] RFC 3064 MGCP CAS Packages February 2001

5.3. Example Call Setup - "MD" Package

 The following describes Feature Group D call setup  using the "MD"
 package.  The table gives an overview of the initial part of the call
 flow with details to follow.

Steps GW-o CA GW-t
———————————————————————
A1 NTFY[O:md/sup] →
A2 ← Ack
A3 NTFY[O:md/inf(<id>)] →
A4 ← Ack
A5 NTFY[O:md/inf(<addr>)] →
A6 ← Ack
B1 ← CRCX [M:recvonly, LCO, R: md/rel]
B2 Ack[SDP1] →
B3 CRCX [M:sendrecv, LCO, SDP1] →
B4 ← Ack [SDP2]
B5 ← MDCX [recvonly,SDP2]
B6 Ack →

———————————————————————

 The assumption is that prior to the initial "notify", the Call Agent
 has sent a request to be informed of "sup" and "inf" events using
 quarantine handling "Q: loop".
 Step A1   Trunk seizure results in a notify to the Call Agent
 indicating the start of a call setup:
       NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/sup
 Step A2   The Call Agent sends an Ack.
 Step A3   Once the digits for the identification field are collected
 the gateway notifies the call agent:
       NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
 Step A4   The Call Agent responds with an ack.

Foster Informational [Page 44] RFC 3064 MGCP CAS Packages February 2001

 Step A5   When the digits are collected for the address field,
 another notify is sent:
       NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
 Step A6   The Call Agent "acks"
 Step B1   Create connection - receive only:
       CRCX 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       C: A3C47F21456789F1
       L: p:10, a:PCMU
       M: sendrecv
       X: 0123456789B1
       R: md/rel
 Step B2   The Gateway "acks" the request and provides connection ID
 and SDP information.
 Step B3   The Call Agent passes this SDP information to the
 terminating gateway (GW-t) as part of the connection request.
 Step B4   The terminating gateway, responds with an ack and its SDP
 information.
 Step B5   Call Agent sends a modify connection request with
 connection mode receive-only to the origination gateway and includes
 the SDP information with the selected profile from the termination
 gateway.
 Step B6   The Gateway Acks the modify connection request.

Foster Informational [Page 45] RFC 3064 MGCP CAS Packages February 2001

 In the case of EAIN signaling there is some additional information
 provided so that this initial part of the call setup looks slightly
 different:

Steps GW-o CA GW-t
———————————————————————
A1 NTFY[O:md/sup] →
A2 ← Ack
A3 NTFY[O:md/inf(<ca>)] →
A4 ← Ack
A5 ← RQNT[S:md/cwk, R:md/inf,md/rel]
A6 ← Ack
A7 NTFY[O:md/inf(<id>)] →
A8 ← Ack
A9 NTFY[O:md/inf(<addr>)] →
A10 ← Ack
B1 ← CRCX [M:recvonly, LCO, R: md/rel]
B2 Ack[SDP1] →
B3 CRCX [M:sendrecv, LCO, SDP1] →
B4 ← Ack [SDP2]
B5 ← MDCX [recvonly,SDP2]
B6 Ack →

———————————————————————

 The assumption is that prior to the initial "notify", the Call Agent
 has sent a request to be informed of "sup" and "inf" events using
 quarantine handling "Q: loop".
 Step A1   Trunk  seizure results in a notify to the Call Agent
 indicating the start of a call setup:
       NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/sup
 Step A2   The Call Agent sends an Ack
 Step A3   The initial digit string contains the country address
 field:
       NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/inf(k0,1,3,8,9,9,0,0,1,9,s0)
 Step A4   The Call Agent responds with an ack

Foster Informational [Page 46] RFC 3064 MGCP CAS Packages February 2001

 Step A5   The Call Agent does processing on the country address field
 and sends a request to initiate further input (sends a continue
 wink):
       RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0
       X: 0123456789B1
       Q: loop
       R: md/inf,md/rel
       S: md/cwk
 Step A6   The Gateway "acks" the request.
 Step A7   Once the digits for the identification field are collected
 the gateway notifies the call agent:
       NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
 Step A8   The Call Agent responds with an ack
 Step A9   When the digits are collected for the address field,
 another notify is sent:
       NTFY 3004 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
 Step A10  The Call Agent "acks"
 Step B1   Create connection - receive only:
       CRCX 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       C: A3C47F21456789F1
       L: p:10, a:PCMU
       M: sendrecv
       X: 0123456789B1
       R: md/rel
 Step B2   The Gateway "acks" the request and provides connection ID
 and SDP information
 Step B3   The Call Agent passes this SDP information to the
 terminating gateway (GW-t) as part of the connection request.
 Step B4   The terminating gateway, responds with an ack and its SDP
 information

Foster Informational [Page 47] RFC 3064 MGCP CAS Packages February 2001

 Step B5   Call Agent sends a modify connection request with
 connection mode receive-only to the origination gateway and includes
 the SDP information with the selected profile from the termination
 gateway.
 Step B6   The Gateway Acks the modify connection request
 The following table shows the remainder of the call flow to set up
 the call for FGD EANA.

Steps GW-o CA GW-t
———————————————————————
C1 RQNT [S:sup, R:md/swk,md/oc, md/rel,md/awk, md/ans] →
C2 ← Ack
C3 ← NTFY [O:md/swk)]
C4 Ack →
C5 ← NTFY [O:md/oc(md/sup)]
C6 Ack →
C7 ← NTFY [O:md/awk)]
C8 Ack →
C9 ← RQNT[S:md/awk]
C10 Ack →
C11 ← NTFY [O: md/ans]
C12 Ack →
C13 ← MDCX [M:sendrecv, S: md/ans, R: md/rel]
C14 Ack →
C15 RQNT [R: md/sus, md/rel] →
C16 ← Ack

———————————————————————

 Step C1   The Call Agent does a setup request to the terminating
 gateway The setup request for an MF EANA FGD interface will be the
 following:
       RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       X: 45375841
       Q: loop
       S:
       md/sup(ct(nda),addr(k0,5,5,5,5,2,2,1,2,3,4,s0),id(k0,0,5,5,5,1,
       2,3,4,s2))
       R: md/swk,md/oc,md/rel,md/awk,md/ans

Foster Informational [Page 48] RFC 3064 MGCP CAS Packages February 2001

     Note that the result of the "sup" signal is the following
     sequence on the interface to the PBX:
  • off-hook → SCN
  • wink ← SCN
  • caller ID digits sent to SCN
  • address digits sent to SCN
 Step C2   The gateway responds with an ack
 Step C3   "Notify" the CA that the start of signaling has occurred
 (incoming wink start has occurred) i.e.:
       NTFY 3000 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/swk
 Step C4   The Call Agent "acks".
 Step C5   "Notify" that out-pulsing is complete:
       NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/oc(md/sup)
 Step C6   The Call Agent "acks".
 Step C7   "Notify" that the acknowledgement wink has been received:
       NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/awk
 Step C8   The Call Agent "acks".
 Step C9   The acknowledge wink is passed to the originating gateway:
       RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       X: 45375842
       S: md/awk
       R: md/rel
 Step C10  GW-o "acks".

Foster Informational [Page 49] RFC 3064 MGCP CAS Packages February 2001

 Step C11  "Notify" off-hook event (the person at the other end has
 answered):
       NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B0
       O: md/ans
 Step C12  The Call Agent "acks".
 Step C13  The Call Agent now sends a request to make the connection
 full duplex and indicates that the other end has answered the phone
 (S: ans sent)
 Step C14  The Gateway acks the request
     In the case of FGD EAIN, there is an additional digits string
     (country address and/or carrier access code that has to be
     included so that step C1 looks like the following in a case where
     there is no overlapped sending:
       RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       X: 45375841
       Q: loop
       S:md/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),addr(ko,0,1,1,3,8,1,2,3,4,7,6,5,s0))
       R: md/swk,md/oc,md/rel,md/awk,md/ans
     If overlapped sending is done, only the country address and
     caller ID digit strings are sent out in step C1:
       RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       X: 45375841
       Q: loop
       S:md/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))
       R: md/swk,md/oc,md/rel,md/ans
     Then after these digits go out indicated by event "oc(sup)" in
     step C5, and as soon as the Call Agent has the address
     information, it sends it out using the "inf" signal:
       RQNT 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
       X: 0123456789B1
       Q: loop
       R: md/oc,md/rel,md/awk,md/ans
       S: md/inf(ko,0,1,1,3,8,1,2,3,4,7,6,5,s0)

Foster Informational [Page 50] RFC 3064 MGCP CAS Packages February 2001

     The Call Agent will then get a further "md/oc(md/sup)" event when
     these digits have gone out.
 Step C15  The Call Agent requests to be told of on-hook ("sus")
 events
         or abnormal release ("rel") events.
 Step C16  The gateway "acks" the request.

5.4. Example Call Setup - "MO" Package

 The following describes Feature Group D operator services signaling
 call setup (911 call) using the "MO" package.  The table gives an
 overview of the initial part of the call flow with details to follow.
 In this case GW-o is a residential gateway using the line package and
 GW-t connects to the E911 tandem.

Steps GW-o CA GW-t
———————————————————————
A1 NTFY[O:hd] →
A2 ← Ack
A3 ← RQNT S: dl, R: [0-9*#T](D)
A4 Ack →
A5 NTFY[O: 9,1,1] →
A6 ← Ack
B1 ← CRCX [M:recvonly, R: hu]
B2 Ack[SDP1] →
B3 CRCX [M:sendrecv, LCO, SDP1, S: mo/sup] →
B4 ← Ack [SDP2]
B5 ← NTFY [O: oc(sup)]
B6 Ack →
B5 ← MDCX [sendrecv,SDP2]
B6 Ack →

———————————————————————

Note: the originating side in this case is a line-side gateway.
 Step A1   The user goes off-hook:
       NTFY 3001 aaln/1@gw-o.whatever.net MGCP 1.0
       X: 0123456789AF
       O: l/hd
 Step A2   The Call Agent sends an Ack:
       200 3001 OK

Foster Informational [Page 51] RFC 3064 MGCP CAS Packages February 2001

 Step A3   The Call Agent sends dial-tone and requests that digits be
 collected:
       RQNT 2001 aaln/1@gw-o.whatever.net MGCP 1.0
       X: 0123456789B0
       S: l/dl
       R: d/[0-9#*T](D), hu
 Step A4   The gateway responds with an ack:
       200 2001 OK
 Step A5   Once the digits are collected the gateway notifies the Call
 Agent.  In this case, it is a 911 call
       NTFY 3002 aaln/1@gw-o.whatever.net MGCP 1.0
       X: 0123456789B0
       O: d/9,d/1,d/1
 Step A6   The Call Agent responds with an ack:
       200 3002 OK
 Step B1   The Call Agent now requests that a receive-only connection
 be made.
       CRCX 2002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       C: A7453949499
       L: a:PCMU,s:off,e:on
       M: recvonly
       X: 0123456789B1
       R: l/hu.
 Step B2   The Gateway acks with a connection ID and provides the SDP
 information:
       200 2002 OK
       I: 23474FE
       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

Foster Informational [Page 52] RFC 3064 MGCP CAS Packages February 2001

 Step B3   The Call Agent passes this SDP information to the
 terminating gateway (GW-t) as part of the connection request and does
 a call setup request at the same time:
       CRCX 4001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
       C: A7453949499
       X: 45375840
       L: a:PCMU,s:off,e:on
       M: sendrecv
       Q: loop
       R: oc, rel, orbk
       S: sup(addr(k0,9,1,1,s2),id(k0,0,8,3,4,5,6,7,8,s0))
       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
 As a result of this request, the following signaling interactions
 will occur between GW-t and the Switched Circuit Network (SCN - in
 this case, the E911 tandem):
  • Off-hook → SCN
  • Wink ← SCN
  • k0,9,1,1,s2 → SCN
  • Off-hook ← SCN
  • k0,0,8,3,4,5,6,7,8,s0
     Note that off-hook from the SCN is part of the protocol (a
     request for the caller ID) and does not provide an indication of
     whether the operator answered or not.
 Step B4   The terminating gateway, responds with an ack and its SDP
 information:
       200 4001 OK
       I: 34738A
       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

Foster Informational [Page 53] RFC 3064 MGCP CAS Packages February 2001

 Step B5   The Call Agent will get a further notify when outpulsing of
 all of the digits is complete.
       NTFY 3003 aaln/1@gw-o.whatever.net MGCP 1.0
       X: 45375840
       O: oc(sup)
 Step B6   The Call Agent returns an "ack"
       200 3003 OK
 Step B7   Call Agent sends a modify connection request with
 connection mode receive-only to the origination gateway and includes
 the SDP information with the selected profile from the termination
 gateway.
       MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
       C: A7453949499
       I: 34738A
       M: sendrecv
       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 B8   The Gateway Acks the modify connection request
       200 2003 OK
 The call is now established between the user and the operator.

Acknowledgements

 The source for some these packages are Flemming Andreasen, Wai-Tak
 Siu - Cisco Systems, and Don Stanwyck - IP Unity.  Special thanks to
 Joe Clark, Telcordia Technologies for his CAS interface expertise.
 Also thanks to all the reviewers for all their comments, including
 but not limited to the following people: Charles Eckel, Cisco
 Systems; Jerry Kamitses, Sonus Networks.

Foster Informational [Page 54] RFC 3064 MGCP CAS Packages February 2001

References

 [1] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
     "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
     October 1999.
 [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
     RFC 2327, April 1998.
 [3] Bellcore, Compatibility Information for Feature Group D Switched
     Access Service, TR-NPL-000258, Issue 1, October 1985.
 [4] Bellcore, Interoffice LATA Switching Systems Generic Requirements
     (LSSGR): Verification Connections (25-05-0903), TR-TSY-000531,
     Issue 2, July 1987.
 [5] Bellcore, LSSGR: Signaling for Analog Interfaces, GR-506-CORE,
     Issue 1, June 1996.
 [6] PacketCableTM PSTN Gateway Call Signaling Protocol Specification,
     Pkt-SP-TGCP-I01-991201

Author's Address

 Bill Foster
 170 West Tasman Dr
 San Jose, CA, 95134
 Phone: 408-527-8791
 EMail: bfoster@cisco.com

Foster Informational [Page 55] RFC 3064 MGCP CAS Packages February 2001

Full Copyright Statement

 Copyright (C) The Internet Society (2001).  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 assigns.
 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.

Foster Informational [Page 56]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3064.txt · Last modified: 2001/02/07 17:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki