rfc3064.txt

最新的RFC

   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.

    ---------------------------------------------------------------------
   | Steps |        GW-o        |         CA         |        GW-t       |
   |---------------------------------------------------------------------|
   |  A1   |       NTFY[seizure] ->                                      |
   |  A2   |                 <-  Ack                                     |
   |  A3   |                 <-  RQNT[request digits]                    |
   |  A4   |                 Ack ->                                      |
   |  A5   |       NTFY[digits]  ->                                      |
   |  A6   |                 <- A