GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5244

Network Working Group H. Schulzrinne Request for Comments: 5244 Columbia U. Updates: 4733 T. Taylor Category: Standards Track Nortel

                                                             June 2008
   Definition of Events for Channel-Oriented Telephony Signalling

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

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 Section 3.14 of RFC 2833.  As
 documented in Appendix A of RFC 4733, some of the RFC 2833 events
 have been deprecated because their specification was ambiguous,
 erroneous, or redundant.  In fact, the degree of change from Section
 3.14 of RFC 2833 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.  This document expands and
 improves the coverage of signalling systems compared to RFC 2833.

Schulzrinne & Taylor Standards Track [Page 1] RFC 5244 Channel-Oriented Signalling Events June 2008

Table of Contents

 1. Introduction ....................................................2
    1.1. Overview ...................................................2
    1.2. Terminology ................................................3
 2. Event Definitions ...............................................4
    2.1. Signalling System No. 5 ....................................6
         2.1.1. Signalling System No. 5 Line Signals ................6
         2.1.2. Signalling System No. 5 Register Signals ............7
    2.2. Signalling System R1 and North American MF .................8
         2.2.1. Signalling System R1 Line Signals ...................8
         2.2.2. Signalling System R1 Register Signals ...............8
    2.3. Signalling System R2 ......................................10
         2.3.1. Signalling System R2 Line Signals ..................10
         2.3.2. Signalling System R2 Register Signals ..............10
    2.4. ABCD Transitional Signalling for Digital Trunks ...........12
    2.5. Continuity Tones ..........................................14
    2.6. Trunk Unavailable Event ...................................14
    2.7. Metering Pulse Event ......................................15
 3. Congestion Considerations ......................................15
 4. Security Considerations ........................................16
 5. IANA Considerations ............................................17
 6. Acknowledgements ...............................................20
 7. References .....................................................20
    7.1. Normative References ......................................20
    7.2. Informative References ....................................21

1. Introduction

1.1. 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 signalled 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

Schulzrinne & Taylor Standards Track [Page 2] RFC 5244 Channel-Oriented Signalling Events June 2008

 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 that 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 implemented signal in Table 1.
 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.

1.2. 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:
 KP     Key Pulse
 MF     Multi-frequency
 PSTN   Public Switched (circuit) Telephone Network
 RTP    Real-time Transport Protocol [2]
 ST     Start

Schulzrinne & Taylor Standards Track [Page 3] RFC 5244 Channel-Oriented Signalling Events June 2008

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 some 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 Section 3.14 of RFC 2833 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.  This document expands and improves the coverage
 of signalling systems compared to 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 Standards Track [Page 4] RFC 5244 Channel-Oriented Signalling Events June 2008

 +---------------------+------------+-------------+--------+---------+
 | 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 Standards Track [Page 5] RFC 5244 Channel-Oriented Signalling Events June 2008

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 Standards Track [Page 6] RFC 5244 Channel-Oriented Signalling Events June 2008

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 the 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 Standards Track [Page 7] RFC 5244 Channel-Oriented Signalling Events June 2008

 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 it 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 as "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 analog
 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 the
 presence of a 2600 Hz signal in the indicated direction and A=1 to
 the 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

Schulzrinne & Taylor Standards Track [Page 8] RFC 5244 Channel-Oriented Signalling Events June 2008

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

Schulzrinne & Taylor Standards Track [Page 9] RFC 5244 Channel-Oriented Signalling Events June 2008

 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.

2.3. Signalling System R2

 The 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 multi-
 frequency, 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

Schulzrinne & Taylor Standards Track [Page 10] RFC 5244 Channel-Oriented Signalling Events June 2008

 (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
 (two out of five frequencies) 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 that 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.
 Note that a naive strategy for onward relay of R2 inter-register
 signals may result in unacceptably long call setup times and timeouts
 when the call passes through several exchanges as well as a gateway
 before terminating.  Several strategies are available for speeding up
 the transfer of signalling information across a given relay point.
 In the worst case, the relay point has to act as an exchange,
 terminating the signalling on one side and reoriginating the call on
 the other.

Schulzrinne & Taylor Standards Track [Page 11] RFC 5244 Channel-Oriented Signalling Events June 2008

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

Schulzrinne & Taylor Standards Track [Page 12] RFC 5244 Channel-Oriented Signalling Events June 2008

 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 Conference of European Postal and Telecommunications (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.
 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;

Schulzrinne & Taylor Standards Track [Page 13] RFC 5244 Channel-Oriented Signalling Events June 2008

 Finally, if only the A bit is used,
 o  A = 0 maps to event code 206;
 o  A = 1 maps to event code 207;
    Separate event codes are assigned to A-bit 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 the continuity check passes if
 the sending switch can detect the tone on the return path.  Clause 8
 of Q.724 describes the procedure for two-wire trunk circuits.  The
 two-wire procedure involves two tones: a 2000 Hz tone sent in the
 forward direction and a 1780 +/- 20 Hz tone sent in response.
 Note that implementations often send a slightly different check-tone,
 e.g., 2010 Hz, because of undesirable aliasing properties of 2000 Hz.
 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

Schulzrinne & Taylor Standards Track [Page 14] RFC 5244 Channel-Oriented Signalling Events June 2008

 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.

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

Schulzrinne & Taylor Standards Track [Page 15] RFC 5244 Channel-Oriented Signalling Events June 2008

 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.

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.
 These attacks can be prevented by the use of appropriate
 confidentiality, authentication, or integrity protection.  If
 confidentiality, authentication, or integrity protection are needed,
 then Secure Real-time Transport Protocol (SRTP) [3] SHOULD be used
 with automated key management.
 Additional security considerations are described in RFC 4733 [4].

Schulzrinne & Taylor Standards Track [Page 16] RFC 5244 Channel-Oriented Signalling Events June 2008

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

Schulzrinne & Taylor Standards Track [Page 17] RFC 5244 Channel-Oriented Signalling Events June 2008

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

Schulzrinne & Taylor Standards Track [Page 18] RFC 5244 Channel-Oriented Signalling Events June 2008

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

Schulzrinne & Taylor Standards Track [Page 19] RFC 5244 Channel-Oriented Signalling Events June 2008

 |            |                                         |           |
 |        209 | AB bit signalling state '01'            | [RFC5244] |
 |            |                                         |           |
 |        210 | AB bit signalling state '10'            | [RFC5244] |
 |            |                                         |           |
 |        211 | AB bit signalling state '11'            | [RFC5244] |
 +------------+-----------------------------------------+-----------+
         Table 6: Channel-Oriented Signalling Events in the
                  Audio/Telephone-Event Event Code Registry

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.

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.

Schulzrinne & Taylor Standards Track [Page 20] RFC 5244 Channel-Oriented Signalling Events June 2008

 [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
       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 Standards Track [Page 21] RFC 5244 Channel-Oriented Signalling Events June 2008

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 Standards Track [Page 22] RFC 5244 Channel-Oriented Signalling Events June 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 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.

Schulzrinne & Taylor Standards Track [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5244.txt · Last modified: 2008/06/16 17:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki