rfc3064.txt

最新的RFC

   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.

               ------------------------------------
              | 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)

    ------------------------------------------------------------------
   |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)

    ------------------------------------------------------------------
   |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)

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