Audio/Video Transport (avt) H. Schulzrinne
Internet-Draft Columbia U.
Expires: June 2, 2006 T. Taylor
Nortel
November 29, 2005
Definition of Events For Channel-Oriented Telephony Signalling
draft-ietf-avt-rfc2833biscas-01
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 June 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-12)
to add event codes for telephony signals used for channel-associated
signalling when carried in the telephony event RTP payload.
Schulzrinne & Taylor Expires June 2, 2006 [Page 1]
Internet-Draft Channel-Oriented Signalling Events November 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Event Definitions . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 13
2.6. Trunk Unavailable Event . . . . . . . . . . . . . . . . . 13
2.7. Metering Pulse Event . . . . . . . . . . . . . . . . . . . 14
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Schulzrinne & Taylor Expires June 2, 2006 [Page 2]
Internet-Draft Channel-Oriented Signalling Events November 2005
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 those defined 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 xxxx [3] 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 [10] or G.729
[11]. 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 June 2, 2006 [Page 3]
Internet-Draft Channel-Oriented Signalling Events November 2005
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 June 2, 2006 [Page 4]
Internet-Draft Channel-Oriented Signalling Events November 2005
2. Event Definitions
Table 1 lists all of the events defined in this document. These
events incorporate a considerable number of changes compared with the
corresponding set of events in RFC 2833 [9], but it would appear that
the changes have not affected any implementations.
+---------------------+------------+-------------+--------+---------+
| Event | Frequency | Event Code | Event | Volume? |
| | (Hz) | | Type | |
+---------------------+------------+-------------+--------+---------+
| MF 0...9 | (Table 2) | 128...137 | tone | yes |
| | | | | |
| MF Code 11 (SS No. | 700+1700 | 138 | tone | yes |
| 5) or KP3P/ST3P | | | | |
| (R1) | | | | |
| | | | | |
| MF KP (SS No. 5) or | 1100+1700 | 139 | tone | yes |
| KP1 (R1) | | | | |
| | | | | |
| MF KP2 (SS No. 5) | 1300+1700 | 140 | tone | yes |
| or KP2P/ST2P (R1) | | | | |
| | | | | |
| MF ST (SS No. 5 and | 1500+1700 | 141 | tone | yes |
| R1) | | | | |
| | | | | |
| MF Code 12 (SS No. | 900+1700 | 142 | tone | yes |
| 5) or KP'/STP (R1) | | | | |
| | | | | |
| ABCD signalling | N/A | 144...159 | state | no |
| | | | | |
| Continuity | 2000 | 167 | tone | yes |
| check-tone | | | | |
| | | | | |
| Continuity | 1780 | 168 | 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 June 2, 2006 [Page 5]
Internet-Draft Channel-Oriented Signalling Events November 2005
2.1. Signalling System No. 5
Signalling System No. 5 (SS No. 5) is defined in ITU-T
Recommendations Q.140 through Q.180 [4]. 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 ABCD 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 144;
o 2400 Hz present: event code 149;
o 2600 Hz present: event code 154;
o neither signal present: event code 159.
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 June 2, 2006 [Page 6]
Internet-Draft Channel-Oriented Signalling Events November 2005
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 138 to convey Code 11
Schulzrinne & Taylor Expires June 2, 2006 [Page 7]
Internet-Draft Channel-Oriented Signalling Events November 2005
o event code 139 to convey KP1
o event code 140 to convey KP2
o event code 141 to convey ST
o event code 142 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 [5], while MF is defined in [8].
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 ABCD
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 144;
o no signal present: event code 159.
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 June 2, 2006 [Page 8]
Internet-Draft Channel-Oriented Signalling Events November 2005
KP3P, STP or ST', ST2P, and ST3P [8].
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 138 to convey KP3P or ST3P.
o event code 139 to convey KP;
o event code 140 to convey KP2P or ST2P;
o event code 141 to convey ST;
o event code 142 to convey KP' or STP;
As with the original telephony signals, the receiver interprets
codes 138, 140, and 142 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 June 2, 2006 [Page 9]
Internet-Draft Channel-Oriented Signalling Events November 2005
2.3. Signalling System R2
International Signalling System R2 is described in ITU-T
Recommendations Q.400-Q.490 [6], 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 ABCD 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 144 (Table 1) is used to indicate the Q.411
"tone-on" condition
* event code 159 (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. Note that the mapping from line states to event
codes thus generated differs from the mappings generated for
analog signalling.
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 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 into
Groups I and II, the backward MF register signals 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.
Schulzrinne & Taylor Expires June 2, 2006 [Page 10]
Internet-Draft Channel-Oriented Signalling Events November 2005
R2 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. 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 June 2, 2006 [Page 11]
Internet-Draft Channel-Oriented Signalling Events November 2005
Upper Frequency (Hz)
+-----------------+---------+---------+---------+---------+---------+
| Lower Frequency | 1140 | 1020 | 900 | 780 | 660 |
| (Hz) | | | | | |
+-----------------+---------+---------+---------+---------+---------+
| 1020 | Bkwd 1 | | | | |
| | | | | | |
| 900 | Bkwd 2 | Fwd 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. For N-state
(N<=16) signalling, the first N values are 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.
The meaning of ABCD signals varies with the application. One example
of a specification of ABCD signalling codes is T1.403.02 [13], 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 [12], 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
Schulzrinne & Taylor Expires June 2, 2006 [Page 12]
Internet-Draft Channel-Oriented Signalling Events November 2005
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. Unused bits are populated by propagating values
from the used bits. Specifically, if only the A bit is used, its
value is propagated to the other three bits. If the A and B bits
are used, the value of the A bit is propagated to the C bit and
the value of the B bit is propasgated to the D bit. As examples:
if only A and B bits are used, A=0, B=1, then C and D are 0 and 1
respectively and the state number is 5 (binary 0101); if all four
bits are used and A=1, B=1, C=0, D=1, then the state number is 13
(binary 1101).
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).
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 [7] 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
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 167.
o For two-wire continuity testing, the initial 2000 Hz check-tone Hz
tone is mapped to event code 167. The 1780 Hz continuity verify
tone is mapped to event code 168.
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
Schulzrinne & Taylor Expires June 2, 2006 [Page 13]
Internet-Draft Channel-Oriented Signalling Events November 2005
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. 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 xxxx [3]. 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 June 2, 2006 [Page 14]
Internet-Draft Channel-Oriented Signalling Events November 2005
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 rather than 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 June 2, 2006 [Page 15]
Internet-Draft Channel-Oriented Signalling Events November 2005
4. Security Considerations
Because the events for which event codes are provided in this
document relate directly to the setup, billing, and takedown of
telephone calls, they may be used to commit toll fraud in the PSTN.
Thus PSTN gateways MUST authenticate the source of trunk signalling
event reports and ensure that the authenticated entity is authorized
to originate them.
Additional security considerations are described in RFC xxxx [3].
Schulzrinne & Taylor Expires June 2, 2006 [Page 16]
Internet-Draft Channel-Oriented Signalling Events November 2005
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 xxxx
[3]. The reference for all of them is the present document.
+---------+---------------------------------------------------------+
| Event | Event Name |
| Code | |
+---------+---------------------------------------------------------+
| 128 | SS No. 5 or R1 digit "0" |
| | |
| 129 | SS No. 5 or R1 digit "1" |
| | |
| 130 | SS No. 5 or R1 digit "2" |
| | |
| 131 | SS No. 5 or R1 digit "3" |
| | |
| 132 | SS No. 5 or R1 digit "4" |
| | |
| 133 | SS No. 5 or R1 digit "5" |
| | |
| 134 | SS No. 5 or R1 digit "6" |
| | |
| 135 | SS No. 5 or R1 digit "7" |
| | |
| 136 | SS No. 5 or R1 digit "8" |
| | |
| 137 | SS No. 5 or R1 digit "9" |
| | |
| 138 | MF Code 11 (SS No. 5) or KP3P/ST3P (R1) |
| | |
| 139 | MF KP (SS No. 5) or KP1 (R1) |
| | |
| 140 | MF KP2 (SS No. 5) or KP2P/ST2P (R1) |
| | |
| 141 | MF ST (SS No. 5 and R1) |
| | |
| 142 | MF Code 12 (SS No. 5) or KP'/STP (R1) |
| | |
| 144 | A bit signalling state '0' or AB state '00' or ABCD |
| | state '0000' |
| | |
| 145 | ABCD signalling state '0001' |
| | |
| 146 | ABCD signalling state '0010' |
| | |
| 147 | ABCD signalling state '0011' |
Schulzrinne & Taylor Expires June 2, 2006 [Page 17]
Internet-Draft Channel-Oriented Signalling Events November 2005
| 148 | ABCD signalling state '0100' |
| | |
| 149 | AB signalling state '01' or ABCD state '0101' |
| | |
| 150 | ABCD signalling state '0110' |
| | |
| 151 | ABCD signalling state '0111' |
| | |
| 152 | ABCD signalling state '1000' |
| | |
| 153 | ABCD signalling state '1001' |
| | |
| 154 | AB signalling state '10' or ABCD state '1010' |
| | |
| 155 | ABCD signalling state '1011' |
| | |
| 156 | ABCD signalling state '1100' |
| | |
| 157 | ABCD signalling state '1101' |
| | |
| 158 | ABCD signalling state '1110' |
| | |
| 159 | A bit signalling state '1' or AB state '11' or ABCD |
| | signalling state '1111' |
| | |
| 167 | Continuity check-tone |
| | |
| 168 | Continuity verify-tone |
| | |
| 174 | Metering pulse |
| | |
| 175 | Trunk unavailable |
| | |
| 176 | MFC forward signal 1 |
| | |
| 177 | MFC forward signal 2 |
| | |
| 178 | MFC forward signal 3 |
| | |
| 179 | MFC forward signal 4 |
| | |
| 180 | MFC forward signal 5 |
| | |
| 181 | MFC forward signal 6 |
| | |
| 182 | MFC forward signal 7 |
| | |
| 183 | MFC forward signal 8 |
Schulzrinne & Taylor Expires June 2, 2006 [Page 18]
Internet-Draft Channel-Oriented Signalling Events November 2005
| 184 | MFC forward signal 9 |
| | |
| 185 | MFC forward signal 10 |
| | |
| 186 | MFC forward signal 11 |
| | |
| 187 | MFC forward signal 12 |
| | |
| 188 | MFC forward signal 13 |
| | |
| 189 | MFC forward signal 14 |
| | |
| 190 | MFC forward signal 15 |
| | |
| 191 | MFC backward signal 1 |
| | |
| 192 | MFC backward signal 2 |
| | |
| 193 | MFC backward signal 3 |
| | |
| 194 | MFC backward signal 4 |
| | |
| 195 | MFC backward signal 5 |
| | |
| 196 | MFC backward signal 6 |
| | |
| 197 | MFC backward signal 7 |
| | |
| 198 | MFC backward signal 8 |
| | |
| 199 | MFC backward signal 9 |
| | |
| 200 | MFC backward signal 10 |
| | |
| 201 | MFC backward signal 11 |
| | |
| 202 | MFC backward signal 12 |
| | |
| 203 | MFC backward signal 13 |
| | |
| 204 | MFC backward signal 14 |
| | |
| 205 | MFC backward signal 15 |
+---------+---------------------------------------------------------+
Table 6: Channel-oriented signalling events to be added to the audio/
telephone-event event code registry
Schulzrinne & Taylor Expires June 2, 2006 [Page 19]
Internet-Draft Channel-Oriented Signalling Events November 2005
6. Acknowledgements
The complete list of acknowledgements for contribution to the
development and revision of RFC 2833 is contained in RFC xxxx [3].
The Editor believes that the following people contributed
specifically to the present document: Flemming Andreasen, Rex
Coldren, Bill Foster, Rajesh Kumar, Oren Peleg, Moshe Samoha, Adrian
Soncodi, and Yaakov Stein.
Schulzrinne & Taylor Expires June 2, 2006 [Page 20]
Internet-Draft Channel-Oriented Signalling Events November 2005
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, STD 0064, July 2003.
[3] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", Work in
progress: draft-ietf-avt-rfc2833bis-12.txt, November 2005.
[4] International Telecommunication Union, "Specifications for
signalling system no. 5", ITU-T Recommendation Q.140-Q.180,
November 1988.
[5] International Telecommunication Union, "Specifications of
Signalling System R1", ITU-T Recommendation Q.310-Q.332,
November 1988.
[6] International Telecommunication Union, "Specifications of
Signalling System R2", ITU-T Recommendation Q.400-Q.490,
November 1988.
[7] International Telecommunication Union, "Telephone user part
signalling procedures", ITU-T Recommendation Q.724,
November 1988.
[8] Telcordia Technologies, "LSSGR: signalling for Analog
Interfaces", Generic Requirement GR-506, June 1996.
7.2. Informative References
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[10] 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.
[11] 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.
[12] International Telecommunication Union, "AAL type 2 service
Schulzrinne & Taylor Expires June 2, 2006 [Page 21]
Internet-Draft Channel-Oriented Signalling Events November 2005
specific convergence sublayer for trunking", ITU-T
Recommendation I.366.2, February 1999.
[13] 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 June 2, 2006 [Page 22]
Internet-Draft Channel-Oriented Signalling Events November 2005
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: taylor@nortel.com
Schulzrinne & Taylor Expires June 2, 2006 [Page 23]
Internet-Draft Channel-Oriented Signalling Events November 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne & Taylor Expires June 2, 2006 [Page 24]
