Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3660

Basic Media Gateway Control Protocol (MGCP) Packages

Pages: 64
Informational
Updates:  2705
Part 2 of 3 – Pages 16 to 42
First   Prev   Next

Top   ToC   RFC3660 - Page 16   prevText

2.3. Trunk Package

Package Name: T Version: 1 ---------------------------------------------------------------- | Symbol | Definition | R | S Duration | |----------------------------------------------------------------| | as | Answer Supervision | x | BR | | bl | Blocking | | BR | | bz | Busy | | TO 30 sec. | | co1 | Continuity Tone (go tone, | x | TO 3 sec. | | | or return tone) | | | | co2 | Continuity Test (go tone, | x | TO 3 sec. | | | or return tone in dual tone | | | | | procedures) | | | | ct(...) | Continuity Transponder | | OO | | lb | Loopback | | OO | | nm | New Milliwatt Tone | x | TO 3 sec | | mm | Newest Milliwatt Tone | x | TO 3 sec | | oc | Operation Complete | x | | | of | Operation Failure | x | | | om | Old Milliwatt Tone | x | TO 3 sec | | pst | Permanent Signal Tone | | TO infinite | | qt | Quiet Termination | | TO infinite | | ro | Reorder Tone | x | TO 30 sec. | | sit(#) | Special Information Tone | x | TO 2 sec. | | | | | (see notes) | | tl | Test Line | x | TO infinite | | tp(###) | Test Pattern | x | TO 3 sec | | zz | No Circuit | x | TO 2 sec | ---------------------------------------------------------------- New events added to this package from the previously unversioned package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp". Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals changed from OO to TO; "as" and "bl" changed from OO to BR.
Top   ToC   RFC3660 - Page 17
   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.

   The definition of the trunk package events are as follows:

   Answer Supervision (as):
      This event is used to indicate the occurrence answer supervision.
      In most cases, it is a result of a steady off-hook in response to
      a call request.  This event is included for backwards
      compatibility with the previous version of the package.  The
      preferred alternative is to use the "answer" event in the
      appropriate CAS packages [34] (Note: check the details on the use
      of "answer" in the particular CAS package; in most cases "answer"
      as an event is an indication of a steady off-hook regardless of
      whether or not it is an indication of answer supervision).  For
      details on when answer supervision is appropriate refer to [5].

   Blocking (bl):
      This event is used to indicate an incoming off-hook for the
      purposes of blocking a one-way trunk in CAS trunks.  This event is
      included for backwards compatibility with the previous version of
      the package.  The preferred alternative is the "block" event in
      the appropriate CAS packages [34].

   Busy Tone (bz):
      Refer to ITU-T E.180 [8].  In North America, station Busy 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 Station Busy Tone is 0.5 seconds on, followed by
      0.5 seconds off, then repeating.  See GR-506-CORE [7]- LSSGR:
      SIGNALING, Section 17.2.6.

   Continuity Tone (co1):
      A tone at 2010 Hz (see section 3.1.1.3 of [2]).  When generated as
      a signal, the frequency of the tone must be within + or - 8 Hz,
      while the frequency of the tone corresponding to the event must be
      within + or - 30 Hz.

   Continuity Test (co2):
      A tone at 1780 Hz (see section 3.1.1.3 of [2]).  When generated as
      a signal, the frequency of the tone must be within + or - 20 Hz,
      while the frequency of the tone corresponding to the event must be
      within + or - 30 Hz.

      In continuity testing the tone corresponding to the signal at the
      originating gateway is referred to as the "go" tone, and the tone
Top   ToC   RFC3660 - Page 18
      corresponding to the event at that same gateway is referred to as
      the "return" or "check" tone.

      Note that generation and notification of continuity tones are done
      as per continuity test requirements as defined in ITU-T Q.724 [3],
      as well as by Bellcore GR-317-CORE [2] specifications, i.e., the
      semantics of notification of the return tone is more than that the
      tone was received, but is an indication that the test has passed.
      Details are provided in the following paragraphs.

      The continuity tones represented by co1 and co2 are used when the
      Call Agent wants to initiate a continuity test.  There are two
      types of tests, single tone and dual tone; In the case of the dual
      tone, either tone can be sent and the opposite received depending
      on the trunk interconnections (4-wire or 2-wire) as indicated
      below:

         Originating                               Terminating
         ============                              ===========

            4w   -------------- 1780 Hz ----------->  2w
                 <------------- 2010 Hz ------------  (transponder)

            2w   -------------- 2010 Hz ----------->  2w/4w
                 <------------- 1780 Hz ------------  (transponder)

            4w   -------------- 2010 Hz ----------->  4w
                 <------------- 2010 Hz ------------  (loopback)

      The Call agent is expected to know, through provisioning
      information, which test should be applied to a given endpoint.  As
      an example, for a 4-wire to 2-wire connection, the Call Agent
      might send a request like the following to an originating gateway:

         RQNT 1234 ds/ds1-1/17@tgw2.example.net
         X: AB123FE0
         S: t/co1
         R: t/co2,t/oc,t/of

      On a terminating side of a trunk, the call agent may request a
      continuity test connection (connection mode "conttest") to the
      terminating gateway as follows:

         CRCX 3001 ds/ds1-2/4@tgw34.example.net
         C: 3748ABC364
         M: conttest
Top   ToC   RFC3660 - Page 19
      Alternatively, rather than using a connection mode, the "T/ct"
      signal can be used (see description of this signal further below):

         RQNT 3001 ds/ds1-2/4@tgw34.example.net
         X: 1233472
         S: t/ct(in=co1,out=co2,+)

      The originating gateway would send the requested "go" tone, and
      would look for the appropriate "return tone".  Once the return
      tone is received, the originating gateway removes the go tone and
      checks to see that the return tone has been removed within the
      specified performance limits (i.e., GR-246-CORE, T1.113.4, Annex B
      [23]).  When it detects that the test is successful, the gateway
      will send a notification of the return tone event (Note that
      notification of the return tone event therefore must not be sent
      prior to detection of the removal of the return tone).

      The "T/co1" and "T/co2" signals are TO signals so that an
      operation complete event will occur when the signal times out.  If
      a timeout value other than the default is desired, the "to"
      parameter may be used (e.g., "S: T/co1(to=2000)").

      If the gateway detects the failure of the continuity test prior to
      the timeout, an operation failure event will be generated.
      Otherwise, the failure of the continuity test is determined by the
      failure to receive the return tone event before the timeout occurs
      (operation complete event).  As with TO signals in general,
      operation complete and operation fail events are parameterized
      with the name of the signal.

      In the example above where the go tone is "co1" and the return
      tone is "co2":

         *  A notification of the "co2" event indicates success (i.e.,
            "O: t/co2").

         *  A notification of the operation failure event indicates
            failure prior to timeout (i.e., "O: t/of(t/co1)").

         *  A notification of the operation complete event indicates
            that the return tone was not received properly prior to the
            occurrence of the timeout (i.e., "O: t/oc(t/co2)").

      On a terminating end of a trunk, either a "loopback" connection
      (single tone test) or "conttest" connection (dual tone test) is
      made (or alternatively the "T/lb" or "T/ct" signals are
      requested).  It is up to the termination end to make sure that the
      return tone is removed as soon as the go tone disappears.  The
Top   ToC   RFC3660 - Page 20
      Call Agent requests the removal of "contest" or "loopback"
      connections (or "T/lb" or "T/ct" signals) at a termination end
      when the results of the continuity test are obtained.

      When "conttest" is used, the endpoint is provisioned as to which
      transponder test is being performed (2010 Hz received and 1780 Hz
      sent or vice versa).  In the case of the corresponding "T/ct"
      signal, the Call Agent can specify which tone is received and sent
      as parameters.

      Note that continuity tones in the trunk package are only ever sent
      to the telephony endpoint.  For network-based continuity, there
      are continuity tones available in the RTP ("R") package.  Although
      a transponder (dual tone) test can be done, a single tone test is
      generally sufficient in the case of continuity testing across an
      IP network.

   Continuity Transponder(ct(in=<tone-in>,out=<tone-out>, <+ or ->)):
      This signal is used to provide transponder functionality
      independent of the connection mode, i.e., this is an alternative
      way to provide the same functionality as the "conttest" connection
      mode.  The parameters can be provided in any order.  The <tone-in>
      and <tone-out> parameters can have values "co1" or "co2",
      corresponding to the 2010 Hz and 1780 Hz tones associated with
      those symbols.  If one of the tones is "co1", then the other must
      be "co2" and vice versa (i.e., <tone-in> and <tone-out> must have
      different values; if loopback is required, then the "lb" signal in
      this package or "loopback" connection mode should be used).

      On detecting <tone-in>, <tone-out> will be generated in return.
      The tone corresponding to <tone-out> will continue to be generated
      until either:

         *  The signal is explicitly turned off (e.g., "S: t/ct(-)") or

         *  Removal of the <tone-in> tone is detected.

      Note that while the signal is active (regardless of whether a tone
      is active or not), media from the endpoint will not be forwarded
      to or from the packet network (i.e., the continuity transponder
      signal must be explicitly turned off by the Call Agent in order to
      resume passing media between the packet network and the endpoint).

   Loopback (lb):
      This signal is used to provide loopback functionality independent
      of the connection mode, i.e., this is an alternative way to
      provide the same functionality as "loopback" connection mode.
Top   ToC   RFC3660 - Page 21
      Note that while the loop-back signal is active (regardless of
      whether a tone is active or not), media from the endpoint will not
      be forwarded to or from the packet network (i.e., the loopback
      signal must be explicitly turned off by the Call Agent in order to
      resume passing media between the packet network and the endpoint).

   New Milliwatt Tone (nm):
      1004 Hz tone - refer to [4] and section 8.2.5 of [5].

   Newest Milliwatt Tone (mm):
      1013.8 Hz - refer to [4].

   Operation Complete (oc):
      This is the standard definition of operation complete [1].

   Operation Failure (of):
      This is the standard definition of operation failure [1].

   Old Milliwatt Tone (om):
      1000 Hz tone - refer to [4] and section 8.2.5 of [5].

   Permanent Signal Tone (pst):
      In North America, this tone is applied to a busy line
      verify/operator interrupt under specific circumstances as
      described in [17].

   Quiet Termination (qt):
      Quiet Termination is used in a 102 trunk test.  Reference section
      6.20.5 [5] as well as [4].

   Reorder Tone(ro):
      This maps to congestion tone in the ITU-T E.182 specification.  In
      North America, 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 (until time-out).  See GR-506-CORE [7], Section
      17.2.7.

   Special Information Tone(sit(#)):
      As described in ITU-T E.180 [8], the special information tone
      consists of a tone period in which 3 tones are produced followed
      by a silent period of 1 second (total TO period of approximately 2
      seconds).  When used as a signal, it MUST be parameterized with a
      parameter value from 1 to 7, with the following meaning as defined
      in SR-2275, section 6.21.2 of [5].
Top   ToC   RFC3660 - Page 22
             -------------------------------------------
            | sit(1) | RO' | reorder SIT, intra-LATA    |
            | sit(2) | RO" | reorder SIT, inter-LATA    |
            | sit(3) | NC' | no circuit SIT, intra-LATA |
            | sit(4) | NC" | no circuit SIT, inter-LATA |
            | sit(5) | IC  | intercept SIT              |
            | sit(6) | VC  | vacant code SIT            |
            | sit(7) | IO  | ineffective other SIT      |
             -------------------------------------------

      When requested as an event, the event MUST be parameterized with a
      decimal number from 1 to 7 to indicate which tone the gateway is
      required to detect.  The resulting notification also includes the
      parameter.  Other countries may have one or more special
      information tones with country specific definitions (refer to
      ITU-T E.180 supp. 2 [9]).  In this case, special information tone
      1 as defined in [9] is sit(1), special information tone 2 is
      sit(2) etc.

      As an example, the Call Agent might make a request such as:

          RQNT 1234 ds/ds1-1/17@tgw2.example.net
          X: AB123FE0
          R: t/sit(N)(2)

      If the tone is detected, the resulting notification might appear
      as follows:

          NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
          X: AB123FE0
          O: t/sit(2)

   Test Line (tl):
      105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10
      dBm0).  Refer to section 8.2.5 of [5].

   Test Pattern (tp(###)):
      The tp(###) signal inserts the pattern ### continuously into the
      channel until the timeout period expires.  The parameter is
      provided as a decimal number from 0 to 255.  If the parameter is
      omitted, the default value is decimal 95.

      In RequestedEvents, the parameter MAY be supplied to indicate what
      pattern the Call Agent wishes the gateway to detect.  If the
      parameter is omitted, the value 95 is assumed.  The pattern MUST
      be returned in the ObservedEvent (even if the parameter was not
      requested).
Top   ToC   RFC3660 - Page 23
      A typical use for the test pattern signal is for the test line 108
      (digital loopback) test (refer to section 8.2.5 of [5]).  At the
      termination side of a trunk, the Call Agent would request a
      connection in "loopback" mode, which would do a digital loopback.
      On the origination side of the trunk, the Call Agent would request
      that the test pattern be injected into the digital channel, and
      would check to see that the pattern was returned within the
      timeout period.  As an example, the Call Agent would make the
      following request on the origination side:

         RQNT 1234 ds/ds1-1/17@tgw2.example.net
         X: AB123FE0
         S: t/tp
         R: t/tp, t/oc, t/of

      In this case the Call Agent will either receive:

         *  An ObservedEvent indicating that the test has passed (i.e.,
            "O:t/op(95)") or

         *  An ObservedEvent indicating that the timeout occurred before
            the pattern was received (i.e., "O:t/oc(t/tp)"), indicating
            that the test failed.  Of course an operation failure would
            indicate failure as well.

   No Circuit (zz):
      This is an alias for Special Information Tone 2, i.e., "sit(2)".
Top   ToC   RFC3660 - Page 24

2.4. Line Package

Package Name: L Version: 1 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |adsi(string) | ADSI Display | | BR | |aw | Answer Tone | x | OO | |bz | Busy Tone | | TO 30 sec. | |ci(ti,nu,na) | Caller-id | | BR | |dl | Dial Tone | | TO 16 sec. | |e | Error Tone | x | TO 2 sec. | |hd | Off-hook Transition | S | | |hf | Flash-hook | x | | |ht | On Hold Tone | | OO | |hu | On-hook Transition | S | | |lsa | Line Side Answer Sup. | | OO | |mwi | Message Waiting ind. | | TO 16 sec. | |nbz | Network busy | x | TO infinite | |oc | Operation Complete | x | | |of | Operation Failure | x | | |osi | Network Disconnect | | TO 900 ms | |ot | Off-hook Warning Tone | | TO infinite | |p | Prompt Tone | x | BR | |rg | Ringing | | TO 180 sec. | |r0, r1, r2, | Distinctive Ringing | | TO 180 sec. | |r3, r4, r5, | | | | |r6 or r7 | | | | |ro | Reorder Tone | | TO 30 sec. | |rs | Ringsplash | | BR | |s(###) | Distinctive Tone Pattern | x | BR | |sit(#) | Special Information Tone | | TO 2 sec. | | | | | (see notes) | |sl | Stutter Dial Tone | | TO 16 sec. | |v | Alerting Tone | | OO | |vmwi | Visual Message | | OO | | | Waiting Indicator | | | |wt | Call Waiting Tone | | TO 12 sec | |wt1, wt2, | Alternative Call | | TO 12 sec | |wt3, wt4 | Waiting Tones | | (see notes) | |y | Recorder Warning Tone | | TO infinite | |z | Calling Card Service Tone| | BR | ---------------------------------------------------------------- New events added to this package from the previously unversioned package: "ht", "osi", and "lsa".
Top   ToC   RFC3660 - Page 25
   Changes in event types: signals "y", "z", changed from OO to TO and
   BR respectively.  Ringing tones were extended to allow for a ring
   repetition signal parameter.

   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.

   The description of events and signals in the line package are as
   follows:

   ADSI Display (adsi):
      This signal is included here to maintain compatibility with the
      previous version of this package.  The signal is not well-defined
      and its use is discouraged.

   Answer Tone (aw):
      This event is included here to maintain compatibility with the
      previous version of this package.  The event is not well-defined
      and its use is discouraged.

   Busy Tone (bz):
      Refer to ITU-T E.180 [8].  In North America, station Busy 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 Station Busy Tone is 0.5 seconds on followed by
      0.5 seconds off, repeating.  See GR-506-CORE [7], Section 17.2.6.
      It is considered an error to try and play busy tone on a phone
      that is on-hook and an error MUST consequently be returned when
      such attempts are made (error code 402 - phone on-hook).

   Caller-id (ci(time, number, name)):
      See GR-1188 [24], GR-30-CORE [14], and GR-31 [25].  For backwards
      compatibility, each of the three fields are optional, but each of
      the commas will always be included.  In accordance with the
      general MGCP grammar, it is RECOMMENDED to always include all
      three fields - an empty quoted string can then be used in lieu of
      omitting a parameter:

      The time parameter is coded as "MM/DD/HH/MM", where MM is a two-
      digit decimal value for a Month between 01 and 12, DD is a two-
      digit value for a Day between 01 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.  (Note: two digits
      MUST always be provided for each of the values of month, day,
      hour, minutes e.g., the month of January is indicated by the two
      digits "01" rather than just "1").
Top   ToC   RFC3660 - Page 26
      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, but they will be
      ignored.  If a quoted-string is provided, the string itself is
      UTF-8 encoded (RFC 2279) as usual for signal parameters.

      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.  If a quoted-string is provided, the string
      itself is UTF-8 encoded (RFC 2279).

      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.  Other letters MAY be used to provide additional
      clarification as per provider or vendor specifications.

      The following example illustrates the use of the caller-id signal:

         S: l/ci(09/14/17/26, "555 1212", "John Doe")

      An example indicating that the name and number are private:

         S: l/ci(09/14/17/26,P,P)

   Dial Tone (dl):
      Refer to the ITU-T E.180 [8] specification.  In North America,
      dial tone is 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.  See GR-506-CORE [7] - LSSGR:
      SIGNALING, Section 17.2.1.  It is considered an error to try and
      play dial-tone on a phone that is on-hook and an error MUST
      consequently be returned when such attempts are made (error code
      402 - phone on-hook).

   Error Tone (e):
      This tone is maintained for backwards compatibility.  The tone is
      not well defined and its use is discouraged.

   Off-hook Transition (hd):
      See GR-506-CORE [7], Section 12.  It is considered an error to try
      and request off-hook on a phone that is off-hook and an error MUST
      consequently be returned when such attempts are made (error code
      401 - phone off-hook).
Top   ToC   RFC3660 - Page 27
   Flash Hook (hf):
      See GR-506-CORE [7], Section 12.  It is considered an error to try
      and request flash hook on a phone that is on-hook and an error
      MUST consequently be returned when such attempts are made (error
      code 402 - phone on-hook).

   Tone On Hold (ht):
      A tone used to reassure a calling subscriber who has been placed
      on "hold".  Refer to ITU-T E.182 [10].

   On-hook Transition (hu):
      See GR-506-CORE [7], Section 12.  The timing for the on-hook
      signal is for flash response enabled, unless provisioned
      otherwise.  It is considered an error to try and request flash
      hook on a phone that is on-hook and an error MUST consequently be
      returned when such attempts are made (error code 402 - phone on-
      hook).

   Line Side Answer Supervision (lsa):
      This provides Reverse Loop Current Feed (RLCF) on the line (refer
      to GR-506-CORE [7]) and is a way of indicating that the called
      party has answered for some line-side equipment.

   Message Waiting Indicator (mwi):
      Message Waiting indicator tone uses the same frequencies and
      levels as dial tone (350 and 440 Hertz at -13dBm each), but with a
      cadence of 0.1 second on, 0.1 second off, repeated 10 times,
      followed by steady application of dial tone.  See GR-506-CORE [7],
      Section 17.2.3.  It is considered an error to try and play
      message-waiting indicator on a phone that is on-hook and an error
      MUST consequently be returned when such attempts are made (error
      code 402 - phone on-hook).

   Network Busy (nbz):
      This is included here to maintain compatibility with the previous
      version of this package.  The "nbz" signal is an alias for re-
      order tone signal("ro").  Future Call Agent implementations that
      require a network busy signal should use the "ro" signal.  It is
      also recommended that future Call Agents not request to be
      notified of the "nbz" event (a network busy event is generally not
      required in a line package; hence, "ro" is only a signal, not an
      event).

   Operation Complete (oc):
      This is the standard definition of operation complete [1].

   Operation Failure (of):
      This is the standard definition of operation failure [1].
Top   ToC   RFC3660 - Page 28
   Network Disconnect (osi):
      Network Disconnect indicates that the far-end party has
      disconnected.  The signal that is sent on the line is provisioned
      in the media gateway since it may vary from country to country.
      In North America, this signal is an open switch interval which
      results in a Loop Current Feed Open Signal (LCFO) being applied to
      the line (refer to GR-506-CORE [7], see also See GR-505-CORE [6],
      Section 4.5.2.1).  The default time-out value for this signal is
      900 ms.

   Off-hook Warning Tone (ot):
      Off-hook warning tone, also known as receiver Off-Hook Tone (ROH
      Tone).  This is the irritating noise a telephone makes when it is
      not hung up correctly.  In North America, ROH Tone is generated by
      combining four tones at frequencies of 1400 Hertz, 2060 Hertz,
      2450 Hertz and 2600 Hertz, at a cadence of 0.1 second on, 0.1
      second off, then repeating.  GR-506-CORE [7], Section 17.2.8
      contains details about required power levels.  It is considered an
      error to try and play off-hook warning tone on a phone that is
      on-hook, and an error MUST consequently be returned when such
      attempts are made (error code 402 - phone on-hook).

   Prompt Tone (p):
      The definition of the prompt tone and its use may be found in
      requirement GR-220 [20].  The tone in GR-220 (requirement "R3-170"
      or GR-220) is a 300 ms burst of a 400 Hz tone.

   Ringing (rg):
      See GR-506-CORE [7], Section 14.  The provisioning process may
      define the ringing cadence.  The ringing signal may be
      parameterized with the signal parameter "rep" which specifies the
      maximum number of ringing cycles (repetitions) to apply.  The
      value for "rep" is specified in decimal and can have any value
      from 1 to 255.  The following will apply the ringing signal for up
      to 6 ringing cycles:

         S: l/rg(rep=6)

      If the "rep" parameter is specified, the signal times-out when the
      number of repetitions are completed (i.e., an operation complete
      event can be requested and will occur at the end of the
      timeout/number of rings).

      If the "rep" parameter is supplied, then any timeout ("to") value
      that is included will be ignored, i.e.:

         S: l/rg(rep=6,to=12000)
Top   ToC   RFC3660 - Page 29
      will be treated the same as the previous example where the
      parameter "to=12000" was not included.  Of course, if the "to"
      parameter is included without the "rep", it will be acted upon
      i.e.:

         S: l/rg(to=12000)

      will ring for 12 seconds.

      It is considered an error to try and ring a phone that is off-hook
      and an error MUST consequently be returned when such attempts are
      made (error code 401 - phone off-hook).

   Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7):
      See GR-506-CORE [7], Section 14.  Default values for r1 to r5 are
      as defined for distinctive ringing pattern 1 to 5 in GR-506-CORE
      [7].  The default values for r0, r6 and r7 are normal ringing
      (i.e., the same cadence "rg").  The provisioning process may
      define the ringing cadence for each of these signals.  The
      distinctive ringing signals may be parameterized with the signal
      parameter "rep" which specifies the maximum number of ringing
      cycles (repetitions) to apply.  The value for "rep" is specified
      in decimal and can have any value from 1 to 255.

      The following will apply the ringing signal for up to 6 ringing
      cycles:

         S: l/r1(rep=6)

      If the "rep" parameter is specified, the signal times-out when the
      number of repetitions are completed (i.e., an operation complete
      event can be requested and will occur at the end of the
      timeout/number of rings)

      If the "rep" parameter is supplied, then any timeout ("to") value
      that is included will be ignored, i.e.:

         S: l/r1(rep=6,to=12000)

      will be treated the same as the previous example where the
      parameter "to=12000" was not included.  Of course, if the "to"
      parameter is included without the "rep", it will be acted upon
      i.e.:

         S: l/r1(to=12000)

      will ring for 12 seconds.
Top   ToC   RFC3660 - Page 30
      It is considered an error to try and ring a phone that is off-hook
      and an error MUST consequently be returned when such attempts are
      made (error code 401 - phone off-hook).

   Reorder Tone (ro):
      This maps to congestion tone in the ITU-T E.182 [10]
      specification.  In North America, 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.

   Ringsplash (rs):
      Also known as "Reminder ring", this tone is a burst of ringing
      that may be applied to the physical forwarding line (when idle) to
      indicate that a call has been forwarded and to remind the user
      that a Call Forward sub-feature is active.  In the US, it is
      defined to be a 0.5(-0,+0.1) second burst of power ringing (see
      [11]).

   Distinctive Tone Pattern (s(###)):
      This is used to signal or detect a tone pattern defined by the
      parameter where the parameter may have a value from 0 to 999.
      When specified as an event, the parameter MUST be included.  The
      parameter will also be included when the event is reported.  This
      event (the definition of tones associated with each parameter
      value) requires special provisioning in the Call Agent and gateway
      to insure interoperability.  This signal is included here to
      maintain compatibility with the previous version of this package.

   Special Information Tone(sit(#)):
      As described in ITU-T E.180 [8], the special information tone
      consists of a tone period in which 3 tones are produced, followed
      by a silent period of 1 second (total TO period of approximately 2
      seconds).  It MAY be parameterized with a parameter value from 1
      to 7, with the following meaning as defined in SR-2275, section
      6.21.2 [5]:

             -------------------------------------------
            | sit(1) | RO' | reorder SIT, intra-LATA    |
            | sit(2) | RO" | reorder SIT, inter-LATA    |
            | sit(3) | NC' | no circuit SIT, intra-LATA |
            | sit(4) | NC" | no circuit SIT, inter-LATA |
            | sit(5) | IC  | intercept SIT              |
            | sit(6) | VC  | vacant code SIT            |
            | sit(7) | IO  | ineffective other SIT      |
             -------------------------------------------
Top   ToC   RFC3660 - Page 31
      If the parameter is left out, the NC' SIT tone that corresponds to
      the signal "L/sit(3)" is assumed.

      Other countries may have one or more special information tones
      with country specific definitions (refer to ITU-T E.180 supp. 2
      [9]).  In this case, special information tone 1 as defined in [9]
      is sit(1), special information tone 2 is sit(2) etc.

   Stutter Dial Tone (sl):
      Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE [7]
      and "special dial tone" in ITU-T E.182 [10]) is used to confirm
      some action and request additional input from the user.  An
      example application is to cancel call-waiting, prior to entering a
      destination address.

      The stutter dial tone signal may be parameterized with the signal
      parameter "del", which will specify a delay in milliseconds to
      apply between the confirmation tone and the dial tone.  The
      parameter can have any value from 0 to 10000 ms, rounded to the
      nearest non-zero value divisible by 100 (i.e., tenth of a second).
      The following will apply stutter dial tone with a delay of 1.5
      seconds between the confirmation tone and the dial tone:

         S: l/sl(del=1500)

      It is considered an error to try and play stutter dial tone on a
      phone that is on-hook and an error MUST consequently be returned
      when such attempts are made (error code 402 - phone on-hook).

   Alerting Tone (v):
      A 440 Hz Tone of a 2 second duration, followed by a 1/2 second of
      tone every 10 seconds.  This event is included for backwards
      compatibility with the previous version of the package.

   Visual Message Waiting Indicator (vmwi):
      The transmission of the VMWI messages will conform to the
      requirements in [13] and the CPE guidelines in [12].  Refer also
      to section 6.6 of GR-30-CORE [14].  VMWI messages will only be
      sent from the gateway to the attached equipment when the line is
      idle.  If new messages arrive while the line is busy, the VMWI
      indicator message will be delayed until the line goes back to the
      idle state.  After the gateway restarts, the state of the signal
      will be "off", and hence the Call Agent MUST refresh the CPE's
      visual indicator if it is supposed to be "on".
Top   ToC   RFC3660 - Page 32
   Alternative Call Waiting Tones (wt, wt1, .., wt4):
      Refer to ITU-T E.180 [8].  For North American tone definitions,
      refer to GR-506-CORE [7], Section 14.2.  "wt" and "wt1" are both
      aliases for the default Call Waiting tone, which in North America,
      is a 440-Hz tone applied for 300 plus or minus 50 ms.  The tone is
      then repeated once after 10 seconds.

      These signals are timeout signals with a default timeout value of
      12 seconds, which allows the tone to be played twice with a single
      request (refer to GR-571-CORE [16]).  However, there are cases
      (Requirement R3-73 of GR-575-CORE [18]), in which only a single
      tone is required.  In that case, the Call Agent may make the
      request with a shorter timeout period to eliminate the second tone
      (e.g., "S: wt(to=2000)" - which stops the signal after 2 seconds
      so that the second tone will not occur).

      Signals wt2, wt3 and wt4 are alternates that are used for
      distinctive call-waiting tone patterns (refer to GR-506-CORE,
      Section 14.2 [7].  It is considered an error to try and apply
      call-waiting tone on a phone that is on-hook and an error MUST
      consequently be returned when such attempts are made (error code
      402 - phone on-hook).

   Recorder Warning Tone(y):
      Refer to ITU-T E.180 [8] - also Bellcore document SR-2275 [5]
      section 6.20.  When recording equipment is used, this tone is
      connected to the line to inform the distant party that the
      conversation is being recorded  - typical value used is a 1400 Hz
      Tone of a 0.5 second duration every 15 seconds.

   Calling Card Service Tone(z):
      This tone is used to inform the customer that credit card
      information must be keyed in.  Typically, it consists of 60 ms of
      941 + 1477 Hz (the DTMF #digit) and 940 ms of 350 + 440 Hz (dial
      tone), decaying exponentially with a time constant of 200 ms.
      Refer to Bellcore document SR-2275 [5], section 6.20.
Top   ToC   RFC3660 - Page 33

2.5. Handset Emulation Package

Package Name: H Version: 1 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |adsi(string) | ADSI Display | x | BR | |aw | Answer Tone | x | OO | |bz | Busy Tone | x | TO 30 sec. | |ci(ti,nu,na) | Caller-id | x | BR | |dl | Dial Tone | x | TO 16 sec. | |e | Error Tone | x | TO 2 sec. | |hd | Off-hook Transition | S | BR | |hu | On-hook Transition | S | BR | |hf | Flash Hook | x | BR | |ht | Tone On Hold | x | OO | |lsa | Line Side Answer Sup. | x | OO | |mwi | Message Waiting Ind. | x | TO 16 sec. | |nbz | Network Busy | x | TO infinite | |oc | Operation Complete | x | | |ot | Off-hook Warning Tone | x | TO infinite | |of | Operation Failure | x | | |osi | Network Disconnect | x | TO 900 ms | |p | Prompt Tone | x | BR | |rg | Ringing | x | TO 180 sec. | |r0, r1, r2, | Distinctive Ringing | x | TO 180 sec. | |r3, r4, r5, | | | | |r6 or r7 | | | | |ro | Reorder Tone | x | TO 30 sec. | |rs | Ringsplash | x | BR | |s(###) | Distinctive Tone Pattern | x | BR | |sit(#) | Sit Tone | x | TO 2 sec. | |sl | Stutter Dial Tone | x | TO 16 sec. | |v | Alerting Tone | x | OO | |vmwi | Vis. Message Waiting Ind.| x | OO | |wt | Call Waiting tone | x | TO 12 sec. | |wt1, wt2, | Alternative Call | x | TO 12 sec | |wt3, wt4 | Waiting Tones | | (see notes) | |y | Recorder Warning Tone | x | TO infinite | |z | Calling Card Serv. Tone | x | BR | ---------------------------------------------------------------- The handset emulation package is similar to the line package except that events such as "off-hook" can be signaled as well as detected.
Top   ToC   RFC3660 - Page 34
   Changes from the original package - are the same changes as were made
   for the line package, plus "hu" and "hd" signal types were changed
   from OO to BR.

   Event definitions are the same as for the line package with the
   following exceptions:

   ASDI:
      When requested as an event by the Call Agent, the event is not
      parameterized.  However, the parameter is included when the event
      is reported.

   Caller-id:
      When requested as an event by the Call Agent, the event MUST not
      be parameterized.  However, parameters are included when the event
      is reported i.e.:

         O: l/ci(09/14/17/26,"555 1212","John Doe")

   Line Side Answer Supervision:
      When requested as an event by the Call Agent, it indicates when
      the reverse loop current feed (RLCF) was turned on and off.  The
      event is not parameterized when it is requested.  However, a
      parameter is included when it is reported i.e.:

         O: l/lsa(+) to indicate RLCF was turned on
         O: l/lsa(-) to indicate RLCF was turned off

   Ringing (rg):
      When requested as an event, the Call Agent may optionally include
      the rep parameter indicating a request to report after some number
      of rings e.g.:

         RQNT 1234 aaln/1@rgw2.example.net
         X: AB123FE0
         R: h/rg(N)(rep=3)

      The resulting notification after the number of rings is detected
      includes the parameter again:

         NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: AB123FE0
         O: h/rg(rep=3)

      If the parameter is not included in the request, it is also not
      included in the report.  In that case, the event is reported as
      soon as ringing is detected.
Top   ToC   RFC3660 - Page 35
   Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7):
      As with the "rg" event, if the "rep" parameter is included when
      one of these is requested as an event, it is also reported.  If it
      is not requested with the parameter, then the parameter is also
      not included in the report.  In that case, the event is reported
      as soon as ringing with the requested cadence is detected.

   Stutter Dial Tone (sl):
      Stutter Dial Tone MUST not be parameterized when requested as an
      event.  However, the "del" parameter is reported.

         RQNT 1234 aaln/1@rgw2.example.net
         X: AB123FE0
         R: h/sl

      The resulting notification indicates the delay between the
      confirmation tone and the dial tone:

         NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: AB123FE0
         O: h/sl(del=1500)

      As with the signal, the report indicates the delay rounded to the
      nearest 100 ms.

   Visual Message Waiting:
      When requested as an event by the Call Agent, it indicates when
      the visual message waiting indicator was turned on and off.  The
      event is not parameterized when it is requested.  However, a
      parameter is included when it is reported i.e.:

         O: l/vmwi(+) to indicate message waiting turned on
         O: l/vmwi(-) to indicate message waiting turned off

   Note that:

      *  All TO signals in the handset package can include a "to"
         parameter when requested as a signal.

      *  However, requests to be notified about these events MUST NOT
         include the "to" parameter, i.e., the "to" parameter is not
         valid in RequestedEvents.
Top   ToC   RFC3660 - Page 36

2.6. Supplementary Services Tone Package

Package Name: SST Version: 0 --------------------------------------------------------------- |Symbol | Definition | R | S Duration | |---------------------------------------------------------------| |cd | Conference Depart | | BR | |cj | Conference Join | | BR | |cm | Comfort Tone | | TO infinite | |cw | Caller Waiting Tone | | TO 30 sec. | |ht | On Hold Tone | | OO | |ni | Negative Indication | | TO infinite | |nu | Number Unobtainable | | TO infinite | |oc | Operation Complete | x | | |of | Operation Failure | x | | |pr | Pay Phone Recognition | | BR | |pt | Pay Tone | | BR | ---------------------------------------------------------------- Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details. The events in this package are defined as follows: Conference Depart(cd): Tone used to indicate that a participant has left a conference call. The tone characteristics are left to the specific gateway implementation. Conference Join (cj): Tone used to indicate that a party has joined a conference call. The tone characteristics are left to the specific gateway implementation. Comfort Tone (cm): Comfort Tone is used to indicate that the call is being processed and that the caller should wait. Refer to ITU-T E.182 [10]. Caller Waiting Tone (cw): Not to be confused with a call-waiting tone, this is a tone advising a caller that a called station, though busy, has a call waiting service active. Refer to ITU-T E.182 [10].
Top   ToC   RFC3660 - Page 37
   Tone on-hold (ht):
      A tone used to reassure a calling subscriber who has been placed
      on "hold".  Refer to ITU-T E.182 [10].

   Negative Indication (ni):
      A tone advising a subscriber that the request for service cannot
      be accepted.  Refer to ITU-T E.182 [10].  For North America, this
      maps to the re-order tone (see GR-506-CORE [7], Section 17.2.7).

   Number Unobtainable Tone (nu):
      Refer to ITU-T E.180, supplement 2 [9].  This is also referred to
      as "vacant tone" and maps to a "re-order tone" in North America
      (see GR-506-CORE [7], Section 17.2.7).

   Operation Complete (oc):
      The standard definition of operation complete [1].

   Operation Failure (of):
      The standard definition of operation failure [1].

   Pay Phone Recognition (pr):
      A tone advising an operator that the endpoint is identified as a
      payphone.  Refer to ITU-T E.182 [10].

   Pay Tone (pt):
      A tone indicating that payment is required.  Refer to ITU-T E.182
      [10].

2.7. Digit Map Extension

Package Name: dm1 ("dm" followed by the number "1") Version: 0 Extension Digit Map Letters: P This package defines an Extension Digit Map Letter that is used to override the shortest possible match behavior for a given entry in a digit map (see [1]). The letter "P" (for partial match override), at the end of a digit map entry, instructs the gateway to only consider that entry a match if the current dial string does not partially match another entry. For example, given the digit map ([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP) and a current dial string of "1234567", we would not consider this a match (as the rules in [1] would otherwise imply); however a current dial string of "411" would be considered a match as usual. A current dial string of "8234" would be considered a match since there is no other partial match.
Top   ToC   RFC3660 - Page 38
   Note that the digit map letter "P" is not an event, but simply a
   syntactic and semantic digit map extension.  Thus, the "P" is not
   included in the list of requested or observed events.

   Support for this package is strongly RECOMMENDED.

2.8. Signal List Package

Package Name: SL Version: 0 --------------------------------------------------------- | Symbol | Definition | R | S Duration | |---------------------------------------------------------| | oc | Operation Complete | x | | | of | Operation Failure | x | | | s(list) | Signal List | | TO variable | --------------------------------------------------------- Operation Complete (oc): This is the standard definition of operation complete from [1]. Operation Failure (of): This is the standard definition of operation failure from [1]. Signal List(s(<list>)): The <list> contains a comma-separated list of signals to be played out. Each of the signals in <list> MUST be either of type BR or type TO. Semantically, the signal list is still treated as a single parameterized signal of type Time-Out though. The signals in the list are played to completion one after the other in the left to right order specified. The package for each signal in the list must be specified. For example, to play out the DTMF digits 123456: S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6) This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being played out in order. It is illegal to include an OO signal as one of the signals in the list or to request recursive definitions (signal lists within signal lists). If this or any other unsupported signal is included, error code 538 (event/signal parameter error) MUST be returned by the gateway.
Top   ToC   RFC3660 - Page 39
      Note that as the gateway plays the ordered list of signals, if it
      encounters a TO signal with an infinite timeout, it will continue
      to play that signal until the Signal List signal is stopped (i.e.,
      other signals later in the list will never be played).

      If the operation complete ("oc") event is requested, it will be
      detected once, when the last signal in the list has been played
      out (regardless of whether there are any TO signals in the list).
      The operation complete event will only report the signal list name
      itself, i.e., without the parameters supplied as in:

         O:   sl/oc(sl/s)

      Should any of the signals in the signal list result in an error,
      an operation failure event for the Signal List signal MUST be
      generated.  Only the signal list name will be included, thus it is
      not possible to determine which of the signals in the signal list
      actually failed.

      Note that if an event occurs while the "SL/S" signal is playing,
      the "SL/S" signal is stopped in the following manner:

         *  If the signal in the list that was playing at the time the
            event occurred is of type BR, then the BR signal will be
            played to completion and no other signals in the list will
            be played.

         *  If the signal in the list that was playing at the time the
            event occurred is of type TO, then the TO signal will stop
            immediately and no other signals in the list will be played.

2.9. Media Format Parameter Package

Package Name: FM Version: 0 This package provides support for the media format parameter Local Connection Option (LCO). The media format parameter LCO is similar to the "fmtp" attribute in SDP [15] and is applicable to all of the same media formats that the corresponding SDP fmtp attribute could be used with (i.e., media format parameters for any media format MIME type). The media format parameter is encoded as the keyword "fmtp" or "o-fmtp", followed by a colon and a quoted string beginning with the media format name (MIME subtype only) followed by a space, followed by the media format parameters associated with that media format. For simplicity, we will use the terms "codec" and "media
Top   ToC   RFC3660 - Page 40
   format" interchangeably in the following.  Multiple formats may be
   indicated by either repeating the "fmtp" local connection option
   multiple times, such as:

      L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY"

   or alternatively by having a single "fmtp" keyword followed by a
   colon, and a semi-colon separated list of quoted strings for each
   media format parameter, as in:

      L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY"

   The two formats may be mixed.

   If it is possible for the same codec to be requested with and without
   the special "fmtp" format, the following could result:

      L:a:codec1;codec1, fmtp:"codec1 formatX"

   However, it would not be clear if the fmtp parameter was to be
   applied to the first or the second occurrence of the codec.  The
   problem with that is, that codec ordering is important (i.e., codecs
   are listed in preferred order), and the above syntax does not provide
   a way to indicate if "formatX" is preferred (i.e., associated with
   the first "codec1") or not (i.e., associated with the second
   "codec1").  In order to resolve this dilemma, when the same codec is
   requested with multiple formats, the codec name in the "fmtp" format
   string is followed by a colon and an <order>, where <order> is a
   number from one to N for N occurrences of the same codec in the codec
   list i.e.:

      L:a:codec1;codec1, fmtp:"codec1:2 formatX"

   indicates that "formatX" is associated with the second instance of
   "codec1" in the "a:codec1;codec1" list.  If an invalid instance
   number is supplied (e.g., instance 3 where there are only two
   instances), then error code 524 - inconsistency in local connection
   options will be returned.

   Pre-pending "fmtp" with the string "o-" (i.e., "o-fmtp") indicates
   that the format is optional.  In that case, the gateway may decide
   not to use the fmtp parameter specified, or only use it in part.

   If the "fmtp" in an LCO is not optional (i.e., does not have "o-" in
   front of it), and the LCO value is either not recognized or not
   supported, then the associated codec is considered "not supported".
Top   ToC   RFC3660 - Page 41
   When auditing capabilities, the "fmtp" local connection option MUST
   be returned with a semi-colon separated list of supported formats
   and/or multiple independent "fmtp" parameters as in:

      A: a:telephone-event, fmtp:"telephone-event 0-15,32-35",...

      A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",...

   One example uses the media format parameter LCO in conjunction with
   the media format "telephone-event", as defined in RFC 2833 [33].  If
   the media format "telephone-event" is used without the "fmtp" media
   format parameter, the DTMF digits (telephone events 0-15 from RFC
   2833 [33]) are assumed - such practice is however discouraged.  On
   the other hand, the media format parameter LCO MAY be used to specify
   the exact set of events that are being requested via RFC 2833 [33].
   Example:

      L: a:PCMU;telephone-event,fmtp:"telephone-event 16"

   indicates that if telephone events are supported at all, then this
   request is specifically for event 16.

   In another case, the Call Agent may indicate that some format
   parameters are "required", while others are optional.  In the example
   below, telephone events 0-15 are a "must", while telephone events 16,
   70 and 71 are optional.

      L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71",
      fmtp:"telephone-event 0-15"

   If the gateway cannot support telephone events 0-15, it MUST NOT
   include the "telephone-event" media format in the SDP in its
   response.  On the other hand, if it can support those telephone
   events, it SHOULD indicate support for those events, as well as any
   of the events 16, 70 and 71 that it supports.

   If a request is made to audit the capabilities of an endpoint, and
   the endpoint supports the "telephone event" media format with events
   "0-16", then the audit would include the following:

      A: a:telephone-event, fmtp: "telephone-event 0-16"

   Another example is the use of redundancy with RFC 2198 [32].  Again,
   the format of the fmtp string is similar to that used in the SDP
   except that the literal string ("red" in this case) is used rather
   than the payload type:

      L: a:G729;pcmu;red,fmtp:"red pcmu/g729"
Top   ToC   RFC3660 - Page 42
   The corresponding media description in the SDP as part of the
   connection request acknowledgment might look like:

      m=audio 12345 RTP/AVP 98 18 0
      a=rtpmap:98 red/8000/1
      a=fmtp:98 0/18

   If we combine both telephone events and redundancy, an example local
   connection option might look as follows (carriage return added for
   formatting reasons here):

      L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729",
                                         fmtp: "telephone-event 16"

   Note that we again specify the literal string for the encoding method
   rather than its payload type.  This is a general principle that
   should be used with this LocalConnectionOption.

   The corresponding SDP might appear as follows:

      m=audio 12345 RTP/AVP 97 98 18 0
      a=rtpmap:97 red/8000/1
      a=fmtp:97 0/18
      a=rtpmap:98 telephone event
      a=fmtp:98 16

   Note that the fmtp LCO may be used in any situation where the
   corresponding SDP attribute may be used.  An example of a local
   connection option that involves a media type other than audio and a
   "foobar" fmtp parameter:

      L: a:image/tiff, fmtp:"tiff foobar"

   Note that normally local connection options that are associated with
   a package should have the package prefix included as per the package
   extension rules in [1].  The "fmtp" and "o-fmtp" LCO in the "FM"
   package are an exception.  The package prefix is not included in the
   case of the "fmtp" and "o-fmtp" local connection options because they
   were created before the extension rules in [1] were defined.

   These two LocalConnectionOptions have been registered with IANA.