[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 5244

Audio/Video Transport (avt)                               H. Schulzrinne
Internet-Draft                                               Columbia U.
Updates: 4733 (if approved)                                    T. Taylor
Expires: December 9, 2007                                         Nortel
                                                            June 7, 2007


     Definition of Events For Channel-Oriented Telephony Signalling
                    draft-ietf-avt-rfc2833biscas-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 9, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Schulzrinne & Taylor    Expires December 9, 2007                [Page 1]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


Abstract

   This memo updates RFC 4733 to add event codes for telephony signals
   used for channel-associated signalling when carried in the telephony
   event RTP payload.  It supersedes and adds to the original assignment
   of event codes for this purpose in RFC 2833 section 3.14.  As
   documented in Appendix A of RFC 4733, certain of the RFC 2833 events
   have been deprecated, because their specification was ambiguous,
   erroneous or redundant.  In fact, the degree of change from RFC 2833
   section 3.14 is such that implementations of the present document
   will be fully backward compatible with RFC 2833 implementations only
   in the case of full ABCD-bit signalling.  The positive benefits of
   the present document are an expanded coverage of signalling systems
   and a more carefully specified and documented coverage of signalling
   systems covered by RFC 2833.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Event Definitions  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Signalling System No. 5  . . . . . . . . . . . . . . . . .  7
       2.1.1.  Signalling System No. 5 Line Signals . . . . . . . . .  7
       2.1.2.  Signalling System No. 5 Register Signals . . . . . . .  8
     2.2.  Signalling System R1 and North American MF . . . . . . . .  9
       2.2.1.  Signalling System R1 Line Signals  . . . . . . . . . .  9
       2.2.2.  Signalling System R1 Register Signals  . . . . . . . .  9
     2.3.  Signalling System R2 . . . . . . . . . . . . . . . . . . . 11
       2.3.1.  Signalling System R2 Line Signals  . . . . . . . . . . 11
       2.3.2.  Signalling System R2 Register Signals  . . . . . . . . 11
     2.4.  ABCD Transitional signalling For Digital Trunks  . . . . . 13
     2.5.  Continuity Tones . . . . . . . . . . . . . . . . . . . . . 14
     2.6.  Trunk Unavailable Event  . . . . . . . . . . . . . . . . . 15
     2.7.  Metering Pulse Event . . . . . . . . . . . . . . . . . . . 15
   3.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 16
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26






Schulzrinne & Taylor    Expires December 9, 2007                [Page 2]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


1.  Introduction

1.1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.

   In addition to the abbreviations defined below for specific events,
   this document uses the following abbreviations:

   MF     Multi-frequency

   PSTN   Public Switched (circuit) Telephone Network

   RTP    Real-time Transport Protocol [2]

1.2.  Overview

   This document extends the set of telephony events defined within the
   framework of RFC 4733 [4] to include signalling events that can
   appear on a circuit in the telephone network.  Most of these events
   correspond to signals within one of several channel-associated
   signalling systems still in use in the PSTN.

   Trunks (or circuits) in the PSTN are the media paths between
   telephone switches.  A succession of protocols have been developed
   using tones and electrical conditions on individual trunks to set up
   telephone calls using them.  The events defined in this document
   support an application where such PSTN signalling is carried between
   two gateways without being interworked to signalling in the IP
   network: the "RTP trunk" application.

   In the "RTP trunk" application, RTP is used to replace a normal
   circuit-switched trunk between two nodes.  This is particularly of
   interest in a telephone network that is still mostly circuit-
   switched.  In this case, each end of the RTP trunk encodes audio
   channels into the appropriate encoding, such as G.723.1 [13] or G.729
   [14].  However, this encoding process destroys in-band signalling
   information which is carried using the least-significant bit ("robbed
   bit signalling") and may also interfere with in-band signalling
   tones, such as the MF (multi-frequency) digit tones.

   In a typical application, the gateways may exchange roles from one
   call to the next: they must be capable of either sending or receiving
   each signal in the table.




Schulzrinne & Taylor    Expires December 9, 2007                [Page 3]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   This document defines events related to four different signalling
   systems.  Three of these are based on the exchange of multi-frequency
   tones.  The fourth operates on digital trunks only, and makes use of
   low-order bits stolen from the encoded media.  In addition, this
   document defines tone events for supporting tasks such as continuity
   testing of the media path.

      Implementors are warned that the descriptions of signalling
      systems given below are incomplete.  They are provided to give
      context to the related event definitions, but omit many details
      important to implementation.








































Schulzrinne & Taylor    Expires December 9, 2007                [Page 4]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


2.  Event Definitions

   Table 1 lists all of the events defined in this document.  As
   indicated in Table 8 (Appendix A) of RFC 4733 [4], use of certain of
   the RFC 2833 [11] event codes has been deprecated, because their
   specification was ambiguous, erroneous or redundant.  In fact, the
   degree of change from RFC 2833 section 3.14 is such that
   implementations of the present document will be fully backward
   compatible with RFC 2833 implementations only in the case of full
   ABCD-bit signalling.  The positive benefits of the present document
   are an expanded coverage of signalling systems and a more carefully
   specified and documented coverage of the signalling systems included
   in RFC 2833.

   Note that the IANA registry for telephony event codes was set up by
   RFC 4733, not by RFC 2833.  Thus event code assignments originally
   made in RFC 2833 appear in the registry only if reaffirmed in RFC
   4733 or an update to RFC 4733 such as the present document.

































Schulzrinne & Taylor    Expires December 9, 2007                [Page 5]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   +---------------------+------------+-------------+--------+---------+
   | Event               |  Frequency |  Event Code | Event  | Volume? |
   |                     |    (Hz)    |             | Type   |         |
   +---------------------+------------+-------------+--------+---------+
   | MF 0...9            |  (Table 2) |  128...137  | tone   | yes     |
   |                     |            |             |        |         |
   | MF Code 11 (SS No.  |  700+1700  |     123     | tone   | yes     |
   | 5) or KP3P/ST3P     |            |             |        |         |
   | (R1)                |            |             |        |         |
   |                     |            |             |        |         |
   | MF KP (SS No. 5) or |  1100+1700 |     124     | tone   | yes     |
   | KP1 (R1)            |            |             |        |         |
   |                     |            |             |        |         |
   | MF KP2 (SS No. 5)   |  1300+1700 |     125     | tone   | yes     |
   | or KP2P/ST2P (R1)   |            |             |        |         |
   |                     |            |             |        |         |
   | MF ST (SS No. 5 and |  1500+1700 |     126     | tone   | yes     |
   | R1)                 |            |             |        |         |
   |                     |            |             |        |         |
   | MF Code 12 (SS No.  |  900+1700  |     127     | tone   | yes     |
   | 5) or KP'/STP (R1)  |            |             |        |         |
   |                     |            |             |        |         |
   | ABCD signalling     |     N/A    |  144...159  | state  | no      |
   |                     |            |             |        |         |
   | AB signalling (C, D |     N/A    |  208...211  | state  | no      |
   | unused)             |            |             |        |         |
   |                     |            |             |        |         |
   | A bit signalling    |     N/A    |  206...207  | state  | no      |
   | (B, C, D unused)    |            |             |        |         |
   |                     |            |             |        |         |
   | Continuity          |    2000    |     121     | tone   | yes     |
   | check-tone          |            |             |        |         |
   |                     |            |             |        |         |
   | Continuity          |    1780    |     122     | tone   | yes     |
   | verify-tone         |            |             |        |         |
   |                     |            |             |        |         |
   | Metering pulse      |     N/A    |     174     | other  | no      |
   |                     |            |             |        |         |
   | Trunk unavailable   |     N/A    |     175     | other  | no      |
   |                     |            |             |        |         |
   | MFC Forward 1...15  |  (Table 4) |  176...190  | tone   | yes     |
   |                     |            |             |        |         |
   | MFC Backward 1...15 |  (Table 5) |  191...205  | tone   | yes     |
   +---------------------+------------+-------------+--------+---------+

                     Table 1: Trunk signalling events





Schulzrinne & Taylor    Expires December 9, 2007                [Page 6]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


2.1.  Signalling System No. 5

   Signalling System No. 5 (SS No. 5) is defined in ITU-T
   Recommendations Q.140 through Q.180 [5].  It has two systems of
   signals: "line" signalling, to acquire and release the trunk, and
   "register" signalling, to pass digits forward from one switch to the
   next.

2.1.1.  Signalling System No. 5 Line Signals

   No. 5 line signalling uses tones at two frequencies: 2400 and 2600
   Hz.  The tones are used singly for most signals, but together for the
   Clear-forward and Release-guard.  (This reduces the chance of an
   accidental call release due to carried media content duplicating one
   of the frequencies.)  The specific signal indicated by a tone depends
   on the stage of call set-up at which it is applied.

   No events are defined in support of No. 5 line signalling.  However,
   implementations MAY use the AB bit events described in Section 2.4
   and shown in Table 1 to propagate SS No. 5 line signals.  If they do
   so, they MUST use the following mappings.  These mappings are based
   on an underlying mapping equating A=0 to presence of 2400 Hz signal
   and B=0 to presence of 2600 Hz signal in the indicated direction.

   o  both 2400 and 2600 Hz present: event code 208;

   o  2400 Hz present: event code 210;

   o  2600 Hz present: event code 209;

   o  neither signal present: event code 211.

   The initial event report for each signal SHOULD be generated as soon
   as the signal is recognized, and in any case no later than the time
   of recognition as indicated in ITU-T Recommendation Q.141, Table 1
   (i.e. 40 ms for "seizing" and "proceed-to-send", 125 ms for all other
   signals).  The packetization interval following the initial report
   SHOULD be chosen with considerations of reliable transmission given
   first priority.  Note that the receiver must supply its own volume
   values for converting these events back to tones.  Moreover, the
   receiver MAY extend the playout of "seizing" until it has received
   the first report of a KP event (see below), so that it has better
   control of the interval between ending of the seizing signal and
   start of KP playout.

      The KP has to be sent beginning 80 +/- 20 ms after the SS No. 5
      "seizing" signal has stopped.




Schulzrinne & Taylor    Expires December 9, 2007                [Page 7]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


2.1.2.  Signalling System No. 5 Register Signals

   No. 5 register signalling uses pairs of tones to convey digits and
   signals framing them.  The tone combinations and corresponding
   signals are shown in the Table 2.  All signals except KP1 and KP2 are
   sent for a duration of 55 ms.  KP1 and KP2 are sent for a duration of
   100 ms.  Inter-signal pauses are always 55 ms.

                                 Upper Frequency (Hz)

   +-----------------+---------+---------+---------+---------+---------+
   | Lower Frequency |     900 |    1100 |    1300 |    1500 |    1700 |
   |            (Hz) |         |         |         |         |         |
   +-----------------+---------+---------+---------+---------+---------+
   |             700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | Code 11 |
   |                 |         |         |         |         |         |
   |             900 |         | Digit 3 | Digit 5 | Digit 8 | Code 12 |
   |                 |         |         |         |         |         |
   |            1100 |         |         | Digit 6 | Digit 9 |     KP1 |
   |                 |         |         |         |         |         |
   |            1300 |         |         |         | Digit 0 |     KP2 |
   |                 |         |         |         |         |         |
   |            1500 |         |         |         |         |      ST |
   +-----------------+---------+---------+---------+---------+---------+

                    Table 2: SS No. 5 Register Signals

   The KP signals are used to indicate start of digit signalling.  KP1
   indicates a call expected to terminate in a national network served
   by the switch to which the signalling is being sent.  KP2 indicates a
   call that is expected to transit through the switch to which the
   signalling is being sent, to another international exchange.  The end
   of digit signalling is indicated by the ST signal.  Code 11 or Code
   12 following a country code (and possibly another digit) indicates a
   call to be directed to an operator position in the destination
   country.  A Code 12 may be followed by other digits indicating a
   particular operator to whom the call is to be directed.

   Implementations using the telephone-events payload to carry SS No. 5
   register signalling MUST use the following events from Table 1 to
   convey the register signals shown in Table 2:

   o  event code 128 to convey Digit 0

   o  event codes 129-137 to convey Digits 1 through 9 respectively

   o  event code 123 to convey Code 11




Schulzrinne & Taylor    Expires December 9, 2007                [Page 8]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   o  event code 124 to convey KP1

   o  event code 125 to convey KP2

   o  event code 126 to convey ST

   o  event code 127 to convey Code 12.

   The sending implementation SHOULD send an initial event report for
   the KP signals as soon as they are recognized, and MUST send an event
   report for all of these signals as soon as they have completed.

2.2.  Signalling System R1 and North American MF

   Signalling System R1 is mainly used in North America, as is the more
   common variant designated simply "MF".  R1 is defined in ITU-T
   Recommendations Q.310-Q.332 [6], while MF is defined in [9].

   Like SS No. 5, R1/MF has both line and register signals.  The line
   signals (not counting Busy and Reorder) are implemented on analogue
   trunks through the application of a 2600 Hz tone, and on digital
   trunks by using ABCD signalling.  Interpretation of the line signals
   is state-dependent (as with SS No. 5).

2.2.1.  Signalling System R1 Line Signals

   In accordance with Table 1/Q.311, implementations MAY use the A bit
   events described in Section 2.4 and shown in Table 1 to propagate R1
   line signals.  If they do so, they MUST use the following mappings.
   These mappings are based on an underlying mapping equating A=0 to
   presence of 2600 Hz signal in the indicated direction and A=1 to
   absence of that signal.

   o  2600 Hz present: event code 206;

   o  no signal present: event code 207.

2.2.2.  Signalling System R1 Register Signals

   R1 has a signal capacity of 15 codes for forward inter-register
   signals but no backward inter-register signals.  Each code or digit
   is transmitted by a tone pair from a set of 6 frequencies.  The R1
   register signals consist of KP, ST, and the digits "0" through "9".
   The frequencies allotted to the signals are shown in Table 3.  Note
   that these frequencies are the same as those allotted to the
   similarly-named SS No. 5 register signals, except that KP uses the
   frequency combination corresponding to KP1 in SS No. 5.  Table 3 also
   shows additional signals used in North American practice: KP', KP2P,



Schulzrinne & Taylor    Expires December 9, 2007                [Page 9]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   KP3P, STP or ST', ST2P, and ST3P [9].

                                 Upper Frequency (Hz)

   +------------+---------+---------+---------+---------+--------------+
   |      Lower |     900 |    1100 |    1300 |    1500 |         1700 |
   |  Frequency |         |         |         |         |              |
   |       (Hz) |         |         |         |         |              |
   +------------+---------+---------+---------+---------+--------------+
   |        700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | KP3P or ST3P |
   |            |         |         |         |         |              |
   |        900 |         | Digit 3 | Digit 5 | Digit 8 |   KP' or STP |
   |            |         |         |         |         |              |
   |       1100 |         |         | Digit 6 | Digit 9 |           KP |
   |            |         |         |         |         |              |
   |       1300 |         |         |         | Digit 0 | KP2P or ST2P |
   |            |         |         |         |         |              |
   |       1500 |         |         |         |         |           ST |
   +------------+---------+---------+---------+---------+--------------+

                      Table 3: R1/MF Register Signals

   Implementations using the telephone-events payload to carry North
   American R1 register signalling MUST use the following events from
   Table 1 to convey the register signals shown in Table 3:

   o  event code 128 to convey Digit 0;

   o  event codes 129-137 to convey Digits 1 through 9 respectively;

   o  event code 123 to convey KP3P or ST3P.

   o  event code 124 to convey KP;

   o  event code 125 to convey KP2P or ST2P;

   o  event code 126 to convey ST;

   o  event code 127 to convey KP' or STP;

      As with the original telephony signals, the receiver interprets
      codes 123, 125, and 127 as KPx or STx signals based on their
      position in the signalling sequence.

   Unlike SS No. 5, R1 allows a large tolerance for the time of onset of
   register signalling following the recognition of start-dialling line
   signal.  This means that sending implementations MAY wait to send a
   KP event report until the KP has completed.



Schulzrinne & Taylor    Expires December 9, 2007               [Page 10]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


2.3.  Signalling System R2

   International Signalling System R2 is described in ITU-T
   Recommendations Q.400-Q.490 [7], but there are many national
   variants.  R2 line signals are continuous, out-of-band, link by link,
   and channel associated.  R2 (inter)register signals are
   multifrequency, compelled, in-band, end to end, and also channel
   associated.

2.3.1.  Signalling System R2 Line Signals

   R2 line signals may be analog, one-bit digital using the A bit in the
   16th channel, or digital using both A and B bits.  Implementations
   MAY use the A bit or AB bit events described in Section 2.4 and shown
   in Table 1 to propagate these signals.  If they do so, they MUST use
   the following mappings.

   1.  For the analog R2 line signals shown in Table 1 of ITU-T
       Recommendation Q.411, implementations MUST map as follows.  This
       mapping is based on an underlying mapping of A bit = 0 when tone
       is present.

       *  event code 206 (Table 1) is used to indicate the Q.411
          "tone-on" condition

       *  event code 207 (Table 1), is used to indicate the Q.411 "tone-
          off" condition.

   2.  The digital R2 line signals as described by ITU-T Recommendation
       Q.421 are carried in two bits, A and B. The mapping between A and
       B bit values and event codes SHALL be the same in both directions
       and SHALL follow the principles for A and B bit mapping specified
       in Section 2.4.

2.3.2.  Signalling System R2 Register Signals

   In R2 signalling, the signalling sequence is initiated from the
   outgoing exchange by sending a line "seizing" signal.  After the line
   "seizing" signal (and "seizing acknowledgment" signal in R2D), the
   signalling sequence continues using MF register signals.  ITU-T
   Recommendation Q.441 classifies the forward MF register signals
   (upper frequencies) into Groups I and II, the backward MF register
   signals (lower frequencies) into Groups A and B. These groups are
   significant with respect both to what sort of information they convey
   and where they can occur in the signalling sequence.

   The tones used in R2 register signalling are combinations of two out
   of six frequencies.  National versions may be reduced to 10 signals



Schulzrinne & Taylor    Expires December 9, 2007               [Page 11]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   (two out of five fgrequencies), or 6 signals (two out of four
   frequencies).

   R2 register signalling is a compelled tone signalling protocol,
   meaning that one tone is played until an "acknowledgment or directive
   for the next tone" is received which indicates that the original tone
   should cease.  A R2 forward register signal is acknowledged by a
   backward signal.  A backward signal is acknowledged by the end of the
   forward signal.  In exceptional circumstances specified in ITU-T Rec.
   Q.442 the downstream entity may send backward signals autonomously
   rather than in response to specific forward signals.

   In R2 signalling, the signalling sequence is initiated from the
   outgoing exchange by sending a forward Group I signal.  The first
   forward signal is typically the first digit of the called number.
   The incoming exchange typically replies with a backward Group A-1
   indicating to the outgoing exchange to send the next digit of the
   called number.

   The tones have meaning; however, the meaning varies depending on
   where the tone occurs in the signalling.  The meaning may also depend
   on the country.  Thus, to avoid an unmanageable number of events,
   this document simply provides means to indicate the 15 forward and 15
   backward MF R2 tones (i.e., using event codes 176-190 and 191-205
   respectively as shown in Table 1).  The frequency pairs for these
   tones are shown in Table 4 and Table 5.

                                 Upper Frequency (Hz)

    +----------------------+-------+-------+-------+--------+--------+
    | Lower Frequency (Hz) | 1500  | 1620  | 1740  | 1860   | 1980   |
    +----------------------+-------+-------+-------+--------+--------+
    | 1380                 | Fwd 1 | Fwd 2 | Fwd 4 | Fwd 7  | Fwd 11 |
    |                      |       |       |       |        |        |
    | 1500                 |       | Fwd 3 | Fwd 5 | Fwd 8  | Fwd 12 |
    |                      |       |       |       |        |        |
    | 1620                 |       |       | Fwd 6 | Fwd 9  | Fwd 13 |
    |                      |       |       |       |        |        |
    | 1740                 |       |       |       | Fwd 10 | Fwd 14 |
    |                      |       |       |       |        |        |
    | 1860                 |       |       |       |        | Fwd 15 |
    +----------------------+-------+-------+-------+--------+--------+

                   Table 4: R2 Forward Register Signals







Schulzrinne & Taylor    Expires December 9, 2007               [Page 12]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


                                 Upper Frequency (Hz)

   +-----------------+---------+---------+---------+---------+---------+
   | Lower Frequency | 1140    | 1020    | 900     | 780     | 660     |
   | (Hz)            |         |         |         |         |         |
   +-----------------+---------+---------+---------+---------+---------+
   | 1020            | Bkwd 1  |         |         |         |         |
   |                 |         |         |         |         |         |
   | 900             | Bkwd 2  | Bkwd 3  |         |         |         |
   |                 |         |         |         |         |         |
   | 780             | Bkwd 4  | Bkwd 5  | Bkwd 6  |         |         |
   |                 |         |         |         |         |         |
   | 660             | Bkwd 7  | Bkwd 8  | Bkwd 9  | Bkwd 10 |         |
   |                 |         |         |         |         |         |
   | 540             | Bkwd 11 | Bkwd 12 | Bkwd 13 | Bkwd 14 | Bkwd 15 |
   +-----------------+---------+---------+---------+---------+---------+

                   Table 5: R2 Backward Register Signals

2.4.  ABCD Transitional signalling For Digital Trunks

   ABCD is a 4-bit signalling system used by digital trunks, where A, B,
   C, and D are the designations of the individual bits.  Signalling may
   be 16-state (all four bits used), 4-state (A and B bits used) or
   2-state (A-bit only used).  ABCD signalling events are all mutually
   exclusive states.  The most recent state transition determines the
   current state.

   When using Extended Super Frame (ESF) T1 framing, signalling
   information is sent as robbed bits in frames 6, 12, 18, and 24.  A D4
   superframe only transmits 4-state signalling with A and B bits.  On
   the CEPT E1 frame, all signalling is carried in timeslot 16, and two
   channels of 16-state (ABCD) signalling are sent per frame.  ITU-T
   Recommendation G.704 [10] gives the details of ABCD bit placement
   within the various framing arrangements.

   The meaning of ABCD signals varies with the application.  One example
   of a specification of ABCD signalling codes is T1.403.02 [16], which
   reflects North American practice for "loop" signalling as opposed to
   the trunk signalling discussed in previous sections.

   Since ABCD information is a state rather than a changing signal,
   implementations SHOULD use the following triple-redundancy mechanism,
   similar to the one specified in ITU-T Rec. I.366.2 [15], Annex L.  At
   the time of a transition, the same ABCD information is sent 3 times
   at an interval of 5 ms.  If another transition occurs during this
   time, then this continues.  After a period of no change, the ABCD
   information is sent every 5 seconds.



Schulzrinne & Taylor    Expires December 9, 2007               [Page 13]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   As shown in Table 1, the 16 possible states are represented by event
   codes 144 to 159 respectively.  Implementations using these event
   codes MUST map them to and from the ABCD information based on the
   following principles:

   1.  State numbers are derived from the used subset of ABCD bits by
       treating them as a single binary number, where the A bit is the
       high-order bit.

   2.  State numbers map to event codes by order of increasing value
       (i.e., state number 0 maps to event code 144, ..., state number
       15 maps to event code 159).

   If only the A and B bits are being used, then the mapping to event
   codes shall be as follows:

   o  A=0, B=0 maps to event code 208;

   o  A=0, B=1 maps to event code 209;

   o  A=1, B=0 maps to event code 210;

   o  A=1, B=1 maps to event code 211;

   Finally, if only the A bit is used,

   o  A = 0 maps to event code 206;

   o  A = 0 maps to event code 207;

      Separate event codes are assigned to A and AB bit signalling
      because, as indicated in Rec. G.704 [10], when the B, C, and D
      bits are unused their default values differ between transmission
      systems.  By specifying codes for only the used bits, this memo
      allows the receiving gateway to fill in the remaining bits
      according to local configuration.

2.5.  Continuity Tones

   Continuity tones are used for testing circuit continuity during call
   setup.  Two basic procedures are used.  In international practice,
   clause 7 of ITU- T Recommendation Q.724 [8] describes a procedure
   applicable to four-wire trunk circuits, where a single 2000 +/- 20 Hz
   check-tone is transmitted from the initiating telephone switch.  The
   remote switch sets up a loopback, and continuity check passes if the
   sending switch can detect the tone on the return path.  Q.724 clause
   8 describes the procedure for two-wire trunk circuits.  The two-wire
   procedure involves two tones: a 2000 Hz tone sent in the forward



Schulzrinne & Taylor    Expires December 9, 2007               [Page 14]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   direction, and a 1780 +/- 20 Hz tone sent in response.

   If implementations use the telephone-events payload type to propagate
   continuity check-tones, they MUST map these tones to event codes as
   follows:

   o  For four-wire continuity testing, the 2000 Hz check-tone is mapped
      to event code 121.

   o  For two-wire continuity testing, the initial 2000 Hz check-tone Hz
      tone is mapped to event code 121.  The 1780 Hz continuity verify
      tone is mapped to event code 122.

2.6.  Trunk Unavailable Event

   This event indicates that the trunk is unavailable for service.  The
   length of the downtime is indicated in the duration field.  The
   duration field is set to a value that allows adequate granularity in
   describing downtime.  A value of 1 second is RECOMMENDED.  When the
   trunk becomes unavailable, this event is sent with the same timestamp
   three times at an interval of 20 ms.  If the trunk persists in the
   unavailable state at the end of the indicated duration, then the
   event is retransmitted, preferably with the same redundancy scheme.

   Unavailability of the trunk might result from a failure or an
   administrative action.  This event is used in a stateless manner to
   synchronize trunk unavailability between equipment connected through
   provisioned RTP trunks.  It avoids the unnecessary consumption of
   bandwidth in sending a continuous stream of RTP packets with a fixed
   payload for the duration of the downtime, as would be required in
   certain E1-based applications.  In T1-based applications, trunk
   conditioning via the ABCD transitional events can be used instead.

2.7.  Metering Pulse Event

   The metering pulse event may be used to transmit meter pulsing for
   billing purposes.  For background information, one possible reference
   is http://www.seg.co.uk/telecomm/automat3.htm.  Since the metering
   pulse is a discrete event, each metering pulse event report MUST have
   both the 'M' and 'E' bits set.  Meter pulsing is normally transmitted
   by out-of-band means while conversation is in progress.  Senders MUST
   therefore be prepared to transmit both the telephone-event and audio
   payload types simultaneously.  Metering pulse events MUST be
   retransmitted as recommended in section 2.5.1.4 of RFC 4733 [4].  It
   is RECOMMENDED that the retransmission interval be the lesser of 50
   ms and the pulsing rate, but no less than audio packetization rate.





Schulzrinne & Taylor    Expires December 9, 2007               [Page 15]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


3.  Congestion Considerations

   The ability to adapt to congestion varies with the signalling system
   being used and also differs between line and register signals.

   With the specific exception of register signalling for S.S. No. 5 and
   R1/MF, the signals desribed in this document are fairly tolerant of
   lengthened durations should these be necessary.  Thus in congested
   conditions, the sender may adapt by lengthening the reporting
   interval for the tones concerned.  At the receiving end, if a tone is
   being played out and an under-run occurs due to delayed or lost
   packets, it is best to continue playing the tone until the next
   packet arrives.  Interrupting a tone prematurely, with or without
   resumption, can cause the call setup attempt to fail, whereas
   extended playout just increases the call setup time.

   Register signalling for S.S. No. 5 and R1/MF is subject to time
   constraints.  Both the tone signals and the silent periods between
   them have specified durations and tolerances of the order of 5 to 10
   ms.  The durations of the individual tones are of the order of two to
   three packetization intervals (55/68 ms, with the initial KP lasting
   100 ms).  The critical requirement for transmission of the telephony-
   event payload is that the receiver knows which signal to play out at
   a given moment.  It is less important that the receiver receive
   timely notification of the end of each tone.  Rather, it should play
   out the sequence with the durations specified by the signalling
   standard instead of the actual durations reported.

   These considerations suggest that as soon as a register signal has
   been reliably identified, the sender should emit a report of that
   tone.  It should then provide an update within 5 ms for reliability,
   and no more updates until reporting the end of the tone.

   Increasing the playout buffer at the receiver during register
   signalling will increase reliability.  This has to be weighed against
   the implied increase in call setup time.















Schulzrinne & Taylor    Expires December 9, 2007               [Page 16]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


4.  Security Considerations

   The events for which event codes are provided in this document relate
   directly to the setup, billing, and takedown of telephone calls.  As
   such, they are subject, using the terminology of RFC 3552 [12], to
   threats to both communications and system security.  The attacks of
   concern are:

   o  confidentiality violations (monitoring of calling and called
      numbers);

   o  establishment of unauthorized telephone connections through
      message insertion;

   o  hijacking of telephone connections through message insertion or
      man-in-the-middle modification of messages;

   o  denial of service to individual telephone calls through message
      insertion, modification, deletion, or delay.

   To prevent these attacks, the transmission of the telephony
   signalling events described in this memo MUST be given
   confidentiality protection.  Message authentication and the
   protection of message integrity MUST also be provided.  These address
   the threats posed by message insertion and modification.  With these
   measures in place, RTP sequence numbers and the redundancy provided
   by the RFC 4733 procedures for transmission of events add protection
   against and some resiliency in the face of message deletion.

   The Secure Real-time Transport Protocol (SRTP) [3] meets the
   requirements for protection of confidentiality, message integrity,
   and message authentication described above.  It SHOULD therefore be
   used to protect media streams containing the events described in this
   document.

      Note that the appropriate method of key distribution for SRTP may
      vary with the specific application.

      In some deployments it may be preferable to use other means to
      provide protection equivalent to that provided by SRTP.

   Additional security considerations are described in RFC 4733 [4].









Schulzrinne & Taylor    Expires December 9, 2007               [Page 17]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


5.  IANA Considerations

   This document defines the event codes shown in Table 6.  These events
   are additions to the telephone-event registry established by RFC 4733
   [4].  The reference for all of them is the present document.

   +------------+-----------------------------------------+-----------+
   | Event Code | Event Name                              | Reference |
   +------------+-----------------------------------------+-----------+
   |        121 | Continuity check-tone                   | [RFCxxxx] |
   |            |                                         |           |
   |        122 | Continuity verify-tone                  | [RFCxxxx] |
   |            |                                         |           |
   |        123 | MF Code 11 (SS No. 5) or KP3P/ST3P (R1) | [RFCxxxx] |
   |            |                                         |           |
   |        124 | MF KP (SS No. 5) or KP1 (R1)            | [RFCxxxx] |
   |            |                                         |           |
   |        125 | MF KP2 (SS No. 5) or KP2P/ST2P (R1)     | [RFCxxxx] |
   |            |                                         |           |
   |        126 | MF ST (SS No. 5 and R1)                 | [RFCxxxx] |
   |            |                                         |           |
   |        127 | MF Code 12 (SS No. 5) or KP'/STP (R1)   | [RFCxxxx] |
   |            |                                         |           |
   |        128 | SS No. 5 or R1 digit "0"                | [RFCxxxx] |
   |            |                                         |           |
   |        129 | SS No. 5 or R1 digit "1"                | [RFCxxxx] |
   |            |                                         |           |
   |        130 | SS No. 5 or R1 digit "2"                | [RFCxxxx] |
   |            |                                         |           |
   |        131 | SS No. 5 or R1 digit "3"                | [RFCxxxx] |
   |            |                                         |           |
   |        132 | SS No. 5 or R1 digit "4"                | [RFCxxxx] |
   |            |                                         |           |
   |        133 | SS No. 5 or R1 digit "5"                | [RFCxxxx] |
   |            |                                         |           |
   |        134 | SS No. 5 or R1 digit "6"                | [RFCxxxx] |
   |            |                                         |           |
   |        135 | SS No. 5 or R1 digit "7"                | [RFCxxxx] |
   |            |                                         |           |
   |        136 | SS No. 5 or R1 digit "8"                | [RFCxxxx] |
   |            |                                         |           |
   |        137 | SS No. 5 or R1 digit "9"                | [RFCxxxx] |
   |            |                                         |           |
   |        144 | ABCD signalling state '0000'            | [RFCxxxx] |
   |            |                                         |           |
   |        145 | ABCD signalling state '0001'            | [RFCxxxx] |
   |            |                                         |           |
   |        146 | ABCD signalling state '0010'            | [RFCxxxx] |



Schulzrinne & Taylor    Expires December 9, 2007               [Page 18]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   |        147 | ABCD signalling state '0011'            | [RFCxxxx] |
   |            |                                         |           |
   |        148 | ABCD signalling state '0100'            | [RFCxxxx] |
   |            |                                         |           |
   |        149 | ABCD signalling state '0101'            | [RFCxxxx] |
   |            |                                         |           |
   |        150 | ABCD signalling state '0110'            | [RFCxxxx] |
   |            |                                         |           |
   |        151 | ABCD signalling state '0111'            | [RFCxxxx] |
   |            |                                         |           |
   |        152 | ABCD signalling state '1000'            | [RFCxxxx] |
   |            |                                         |           |
   |        153 | ABCD signalling state '1001'            | [RFCxxxx] |
   |            |                                         |           |
   |        154 | ABCD signalling state '1010'            | [RFCxxxx] |
   |            |                                         |           |
   |        155 | ABCD signalling state '1011'            | [RFCxxxx] |
   |            |                                         |           |
   |        156 | ABCD signalling state '1100'            | [RFCxxxx] |
   |            |                                         |           |
   |        157 | ABCD signalling state '1101'            | [RFCxxxx] |
   |            |                                         |           |
   |        158 | ABCD signalling state '1110'            | [RFCxxxx] |
   |            |                                         |           |
   |        159 | ABCD signalling state '1111'            | [RFCxxxx] |
   |            |                                         |           |
   |        174 | Metering pulse                          | [RFCxxxx] |
   |            |                                         |           |
   |        175 | Trunk unavailable                       | [RFCxxxx] |
   |            |                                         |           |
   |        176 | MFC forward signal 1                    | [RFCxxxx] |
   |            |                                         |           |
   |        177 | MFC forward signal 2                    | [RFCxxxx] |
   |            |                                         |           |
   |        178 | MFC forward signal 3                    | [RFCxxxx] |
   |            |                                         |           |
   |        179 | MFC forward signal 4                    | [RFCxxxx] |
   |            |                                         |           |
   |        180 | MFC forward signal 5                    | [RFCxxxx] |
   |            |                                         |           |
   |        181 | MFC forward signal 6                    | [RFCxxxx] |
   |            |                                         |           |
   |        182 | MFC forward signal 7                    | [RFCxxxx] |
   |            |                                         |           |
   |        183 | MFC forward signal 8                    | [RFCxxxx] |
   |            |                                         |           |
   |        184 | MFC forward signal 9                    | [RFCxxxx] |
   |            |                                         |           |



Schulzrinne & Taylor    Expires December 9, 2007               [Page 19]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   |        185 | MFC forward signal 10                   | [RFCxxxx] |
   |            |                                         |           |
   |        186 | MFC forward signal 11                   | [RFCxxxx] |
   |            |                                         |           |
   |        187 | MFC forward signal 12                   | [RFCxxxx] |
   |            |                                         |           |
   |        188 | MFC forward signal 13                   | [RFCxxxx] |
   |            |                                         |           |
   |        189 | MFC forward signal 14                   | [RFCxxxx] |
   |            |                                         |           |
   |        190 | MFC forward signal 15                   | [RFCxxxx] |
   |            |                                         |           |
   |        191 | MFC backward signal 1                   | [RFCxxxx] |
   |            |                                         |           |
   |        192 | MFC backward signal 2                   | [RFCxxxx] |
   |            |                                         |           |
   |        193 | MFC backward signal 3                   | [RFCxxxx] |
   |            |                                         |           |
   |        194 | MFC backward signal 4                   | [RFCxxxx] |
   |            |                                         |           |
   |        195 | MFC backward signal 5                   | [RFCxxxx] |
   |            |                                         |           |
   |        196 | MFC backward signal 6                   | [RFCxxxx] |
   |            |                                         |           |
   |        197 | MFC backward signal 7                   | [RFCxxxx] |
   |            |                                         |           |
   |        198 | MFC backward signal 8                   | [RFCxxxx] |
   |            |                                         |           |
   |        199 | MFC backward signal 9                   | [RFCxxxx] |
   |            |                                         |           |
   |        200 | MFC backward signal 10                  | [RFCxxxx] |
   |            |                                         |           |
   |        201 | MFC backward signal 11                  | [RFCxxxx] |
   |            |                                         |           |
   |        202 | MFC backward signal 12                  | [RFCxxxx] |
   |            |                                         |           |
   |        203 | MFC backward signal 13                  | [RFCxxxx] |
   |            |                                         |           |
   |        204 | MFC backward signal 14                  | [RFCxxxx] |
   |            |                                         |           |
   |        205 | MFC backward signal 15                  | [RFCxxxx] |
   |            |                                         |           |
   |        206 | A bit signalling state '0'              | [RFCxxxx] |
   |            |                                         |           |
   |        207 | A bit signalling state '1'              | [RFCxxxx] |
   |            |                                         |           |
   |        208 | AB bit signalling state '00'            | [RFCxxxx] |
   |            |                                         |           |



Schulzrinne & Taylor    Expires December 9, 2007               [Page 20]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


   |        209 | AB bit signalling state '01'            | [RFCxxxx] |
   |            |                                         |           |
   |        210 | AB bit signalling state '10'            | [RFCxxxx] |
   |            |                                         |           |
   |        211 | AB bit signalling state '11'            | [RFCxxxx] |
   +------------+-----------------------------------------+-----------+

   Table 6: Channel-oriented signalling events to be added to the audio/
                    telephone-event event code registry

      Note to RFC Editor: please replace "RFCxxxx" in the above table
      with the actual RFC number of this document.

      Note to IANA: because of an oversight, RFC 4733 did not indicate
      that event codes 144-159 and 206-211 were specifically reserved
      for this document.  Their assignment here is valid.



































Schulzrinne & Taylor    Expires December 9, 2007               [Page 21]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


6.  Acknowledgements

   The complete list of acknowledgements for contribution to the
   development and revision of RFC 2833 is contained in RFC 4733 [4].
   The Editor believes or is aware that the following people contributed
   specifically to the present document: Flemming Andreasen, Rex
   Coldren, Bill Foster, Alfred Hoenes, Rajesh Kumar, Aleksandar Lebl,
   Zarko Markov, Oren Peleg, Moshe Samoha, Adrian Soncodi, and Yaakov
   Stein.  Steve Norreys and Roni Even provided useful review comments.










































Schulzrinne & Taylor    Expires December 9, 2007               [Page 22]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


7.  References

7.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [3]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

   [4]   Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
         Telephony Tones, and Telephony Signals", RFC 4733,
         December 2006.

   [5]   International Telecommunication Union, "Specifications for
         signalling system no. 5", ITU-T Recommendation Q.140-Q.180,
         November 1988.

   [6]   International Telecommunication Union, "Specifications of
         Signalling System R1", ITU-T Recommendation Q.310-Q.332,
         November 1988.

   [7]   International Telecommunication Union, "Specifications of
         Signalling System R2", ITU-T Recommendation Q.400-Q.490,
         November 1988.

   [8]   International Telecommunication Union, "Telephone user part
         signalling procedures", ITU-T Recommendation Q.724,
         November 1988.

   [9]   Telcordia Technologies, "LSSGR: signalling for Analog
         Interfaces", Generic Requirement GR-506, June 1996.

   [10]  International Telecommunication Union, "Synchronous frame
         structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s
         hierarchical levels", ITU-T Recommendation G.704, October 1998.

7.2.  Informative References

   [11]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
         Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [12]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on



Schulzrinne & Taylor    Expires December 9, 2007               [Page 23]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


         Security Considerations", BCP 72, RFC 3552, July 2003.

   [13]  International Telecommunication Union, "Speech coders : Dual
         rate speech coder for multimedia communications transmitting at
         5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996.

   [14]  International Telecommunication Union, "Coding of speech at 8
         kbit/s using conjugate-structure algebraic-code-excited linear-
         prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.

   [15]  International Telecommunication Union, "AAL type 2 service
         specific convergence sublayer for trunking", ITU-T
         Recommendation I.366.2, February 1999.

   [16]  ANSI/T1, "Network and Customer Installation Interfaces -- DS1
         Robbed-Bit signalling State Definitions", American National
         Standard for Telecommunications T1.403.02-1999, May 1999.


































Schulzrinne & Taylor    Expires December 9, 2007               [Page 24]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


Authors' Addresses

   Henning Schulzrinne
   Columbia U.
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY  10027
   US

   Email: schulzrinne@cs.columbia.edu


   Tom Taylor
   Nortel
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   CA

   Email: tom.taylor@rogers.com































Schulzrinne & Taylor    Expires December 9, 2007               [Page 25]

Internet-Draft     Channel-Oriented Signalling Events          June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Schulzrinne & Taylor    Expires December 9, 2007               [Page 26]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/