draft-ietf-avt-tones-00.txt   draft-ietf-avt-tones-01.txt 
Internet Engineering Task Force AVT WG Internet Engineering Task Force AVT WG
Internet Draft Schulzrinne/Petrack Internet Draft Schulzrinne/Petrack
draft-ietf-avt-tones-00.txt Columbia U./MetaTel draft-ietf-avt-tones-01.txt Columbia U./MetaTel
June 25, 1999 September 26, 1999
Expires: December, 1999 Expires: February 2000
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 29 skipping to change at page 1, line 29
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
Abstract Abstract
This memo describes how to carry dual-tone multifrequency (DTMF) This memo describes how to carry dual-tone multifrequency (DTMF)
signaling, other tone signals and telephony events in RTP packets. signaling, other tone signals and telephony events in RTP packets.
1 Introduction 1 Introduction
This memo defines a payload type for carrying dual-tone This memo defines two payload types, one for carrying dual-tone
multifrequency (DTMF) digits and other line and trunk signals in RTP multifrequency (DTMF) digits, other line and trunk signals and a
[1] packets. A separate RTP payload type is desirable since low-rate second one for general multi-frequency tones in RTP [1] packets.
voice codecs cannot be guaranteed to reproduce these tone signals Separate RTP payload types are desirable since low-rate voice codecs
accurately enough for automatic recognition. Defining a separate cannot be guaranteed to reproduce these tone signals accurately
payload type also permits higher redundancy while maintaining a low enough for automatic recognition. Defining a separate payload type
bit rate. also permits higher redundancy while maintaining a low bit rate.
The payload types described here may be useful in at least two The payload types described here may be useful in at least three
applications: DTMF handling for gateways and end sytems, as well as applications: DTMF handling for gateways and end sytems, as well as
"RTP trunks". In the first application, the Internet telephony "RTP trunks". In the first application, the Internet telephony
gateway detects DTMF on the incoming circuits and sends the RTP gateway detects DTMF on the incoming circuits and sends the RTP
payload described here instead of regular audio packets. The gateway payload described here instead of regular audio packets. The gateway
likely has the necessary digital signal processors and algorithms, as likely has the necessary digital signal processors and algorithms, as
it often needs to detect DTMF, e.g., for two-stage dialing. Having it often needs to detect DTMF, e.g., for two-stage dialing. Having
the gateway detect tones relieves the receiving Internet end system the gateway detect tones relieves the receiving Internet end system
from having to do this work and also avoids that low bit-rate codecs from having to do this work and also avoids that low bit-rate codecs
like G.723.1 render DTMF tones unintelligible. Similarly, an Internet like G.723.1 render DTMF tones unintelligible. Secondly, an Internet
end system such as an "Internet phone" can emulate DTMF functionality end system such as an "Internet phone" can emulate DTMF functionality
without concerning itself with generating precise tone pairs. without concerning itself with generating precise tone pairs and
without imposing the burden of tone recognition on the receiver.
In the "RTP trunk" application, RTP is used to replace a normal In the "RTP trunk" application, RTP is used to replace a normal
circuit-switched trunk between two nodes. This is particularly of circuit-switched trunk between two nodes. This is particularly of
interest in a telephone network that is still mostly circuit- interest in a telephone network that is still mostly circuit-
switched. In this case, each end of the RTP trunk encodes audio switched. In this case, each end of the RTP trunk encodes audio
channels into the appropriate encoding, such as G.723.1 or G.729. channels into the appropriate encoding, such as G.723.1 or G.729.
However, this encoding process destroys in-band signaling information However, this encoding process destroys in-band signaling information
which is carried using the least-significant bit ("robbed bit which is carried using the least-significant bit ("robbed bit
signaling") and may also interfere with in-band signaling tones, such signaling") and may also interfere with in-band signaling tones, such
as the MF digit tones. In addition, tone properties such as the phase as the MF digit tones. In addition, tone properties such as the phase
reversals in the ANSam tone, will ot survive speech coding. Thus, the reversals in the ANSam tone, will not survive speech coding. Thus,
gateway needs to remove the in-band signaling information from the the gateway needs to remove the in-band signaling information from
bit stream. It can now either carry it out-of-band in a signaling the bit stream. It can now either carry it out-of-band in a signaling
transport mechanism yet to be defined, or it can use the mechanism transport mechanism yet to be defined, or it can use the mechanism
described in this memorandum. (If the two trunk end points are within described in this memorandum. (If the two trunk end points are within
reach of the same media gateway controller, the media gateway reach of the same media gateway controller, the media gateway
controller can also handle the signaling.) Carrying it in-band may controller can also handle the signaling.) Carrying it in-band may
simplify the time synchronization between audio packets and the tone simplify the time synchronization between audio packets and the tone
or signal information. This is particularly relevant where duration or signal information. This is particularly relevant where duration
and timing matter, as in the carriage of DTMF signals. and timing matter, as in the carriage of DTMF signals.
A gateway has two options for handling DTMF digits and signals. 2 Events vs. Tones
First, it can simply measure the frequency components of the voice
band signals and transmit this information to the RTP receiver. All A gateway has two options for handling DTMF digits and events. First,
tone signals in use in the PSTN and meant for human consumption are it can simply measure the frequency components of the voice band
sequences of simple combinations of sine waves, either added or signals and transmit this information to the RTP receiver (Section
4). In this mode, the gateway makes no attempt to discern the meaning
of the tones, but simply distinguishes tones from speech signals.
All tone signals in use in the PSTN and meant for human consumption
are sequences of simple combinations of sine waves, either added or
modulated. (There is at least one tone, the ANSam tone [2] used for modulated. (There is at least one tone, the ANSam tone [2] used for
indicating data transmission over voice lines, that makes use of indicating data transmission over voice lines, that makes use of
periodic phase reversals.) periodic phase reversals.)
As a second option, it can recognize the tones and translate them As a second option, a gateway can recognize the tones and translate
into a name, such as ringing or busy tone. The receiver then produces them into a name, such as ringing or busy tone. The receiver then
a tone signal or other indication appropriate to the signal. produces a tone signal or other indication appropriate to the signal.
Generally, since the recognition of signals often depends on their Generally, since the recognition of signals often depends on their
on/off pattern or the sequence of several tones, this recognition can on/off pattern or the sequence of several tones, this recognition can
take several seconds. On the other hand, the gateway may have access take several seconds. On the other hand, the gateway may have access
to the actual signaling information that generates the tones and thus to the actual signaling information that generates the tones and thus
can generate the RTP packet immediately, without the detour through can generate the RTP packet immediately, without the detour through
acoustic signals. acoustic signals.
In the phone network, tones are generated at different places, In the phone network, tones are generated at different places,
depending on the switching technology and the nature of the tone. depending on the switching technology and the nature of the tone.
This determines, for example, whether a person making a call to a This determines, for example, whether a person making a call to a
foreign country hears her local tones she is familiar with or the foreign country hears her local tones she is familiar with or the
tones as used in the country called. tones as used in the country called.
For analog lines, Dial tone is always generated by the local switch. For analog lines, dial tone is always generated by the local switch.
ISDN terminals may generate dial tone locally and then send a Q.931 ISDN terminals may generate dial tone locally and then send a Q.931
SETUP message containing the dialed digits. If the terminal just SETUP message containing the dialed digits. If the terminal just
sends a SETUP message without any Called Party digits, then the sends a SETUP message without any Called Party digits, then the
switch does digit collection, provided by the terminal as KEYPAD switch does digit collection, provided by the terminal as KEYPAD
messages, and provides dial tone over the B-channel. The terminal can messages, and provides dial tone over the B-channel. The terminal can
either use the audio signal on the B-channel or can use the Q.931 either use the audio signal on the B-channel or can use the Q.931
messages to trigger locally generated dial tone. messages to trigger locally generated dial tone.
Ringing tone (also called ringback tone) is generated by the local Ringing tone (also called ringback tone) is generated by the local
switch at the callee, with a one-way voice path opened up as soon as switch at the callee, with a one-way voice path opened up as soon as
skipping to change at page 3, line 31 skipping to change at page 3, line 37
called party's response just after answer. It also permits pre-answer called party's response just after answer. It also permits pre-answer
announcements or in-band call-progress-indications to reach the announcements or in-band call-progress-indications to reach the
caller before or in lieu of ringing tone.) Congestion tone and caller before or in lieu of ringing tone.) Congestion tone and
special information tones can be generated by any of the switches special information tones can be generated by any of the switches
along the way, and may be generated by the caller's switch based on along the way, and may be generated by the caller's switch based on
ISUP messages received. Busy tone is generated by the caller's ISUP messages received. Busy tone is generated by the caller's
switch, triggered by the appropriate ISUP message, for analog switch, triggered by the appropriate ISUP message, for analog
instruments, or the ISDN terminal. instruments, or the ISDN terminal.
Gateways which send signalling events via RTP SHOULD send both named Gateways which send signalling events via RTP SHOULD send both named
signals (Section 2) and the tone representation (Section 4) as a signals (Section 3) and the tone representation (Section 4) as a
single RTP session, using the redundancy mechanism defined in Section single RTP session, using the redundancy mechanism defined in Section
2.4. The receiver can then choose the appropriate rendering. 3.7 to interleave the two representations. The receiver can then
choose the appropriate rendering.
If a gateway cannot present a tone representation, it SHOULD send the If a gateway cannot present a tone representation, it SHOULD send the
audio tones as regular RTP audio packets (e.g., as payload type audio tones as regular RTP audio packets (e.g., as payload type
PCMU), in addition to the named signals. PCMU), in addition to the named signals.
2 RTP Payload Format for Named Telephone Events 3 RTP Payload Format for Named Telephone Events
2.1 Requirements 3.1 Introduction
The DTMF payload type must be suitable for both gateway and end-to- The payload type for named telephone events described below is
end scenarios. In the gateway scenario, a gateway connecting a packet suitable for both gateway and end-to-end scenarios. In the gateway
voice network to the PSTN recreates the DTMF tones and injects them scenario, an Internet telephony gateway connecting a packet voice
into the PSTN. Since DTMF digit recognition takes several tens of network to the PSTN recreates the DTMF tones or other telephony
milliseconds, the first few milliseconds of a digit will arrive as events and injects them into the PSTN. Since, for example, DTMF digit
regular audio packets. Thus, careful time and power (volume) recognition takes several tens of milliseconds, the first few
alignment is needed to avoid generating spurious digits. milliseconds of a digit will arrive as regular audio packets. Thus,
careful time and power (volume) alignment between the audio samples
and the events is needed to avoid generating spurious digits at the
receiver.
For interactive voice response (IVR) systems directly connected to DTMF digits and named telephone events are carried as part of the
the packet voice network, time alignment and volume levels are not audio stream, and SHOULD use the same sequence number and time-stamp
important, since the unit will not perform any signal analysis to base as the regular audio channel to simplify the generation of audio
detect DTMF tones from the audio stream. waveforms at a gateway. The default clock frequency is 8,000 Hz, but
the clock frequency can be redefined when assigning the dynamic
payload type.
DTMF digits and named events are carried as part of the audio stream, The payload format described here achieves a higher redundancy even
and SHOULD use the same sequence number and time-stamp base as the in the case of sustained packet loss than the method proposed for the
regular audio channel to simplify recreation of analog audio at a Voice over Frame Relay Implementation Agreement [3].
gateway. The default clock frequency is 8000 Hz, but the clock
frequency can be redefined when assigning the dynamic payload type.
This format achieves a higher redundancy even in the case of If an end system is directly connected to the Internet and does not
sustained packet loss than the method proposed for the Voice over need to generate tone signals again, time alignment and power levels
Frame Relay Implementation Agreement [3]. are not relevant. These systems rely on PSTN gateways or Internet end
systems to generate DTMF events and do not perform their own audio
waveform analysis. An example of such a system is an Internet
interactive voice-response (IVR) system.
In circumstances where exact timing alignment between the audio In circumstances where exact timing alignment between the audio
stream and the DTMF digits is not important and data is sent unicast, stream and the DTMF digits or other events is not important and data
such as the IVR example mentioned earlier, it may be preferable to is sent unicast, such as the IVR example mentioned earlier, it may be
use a reliable control stream such as H.245. preferable to use a reliable control protocol rather than RTP
packets. In those circumstances, this payload format would not be
used.
3.2 Simultaneous Generation of Audio and Events
A source MAY send events and coded audio packets for the same time A source MAY send events and coded audio packets for the same time
instants, using events as the redundant encoding for the audio instants, using events as the redundant encoding for the audio
stream, or it MAY block outgoing audio while event tones are active stream, or it MAY block outgoing audio while event tones are active
and only send named events as both the primary and redundant and only send named events as both the primary and redundant
encodings. encodings.
This payload definition is used by five different payload types: Note that a period covered by an encoded tone may overlap in time
with a period of audio encoded by other means. This is likely to
occur at the onset of a tone and is necessary to avoid possible
errors in the interpretation of the reproduced tone at the remote
end. Implementations supporting this payload type must be prepared
to handle the overlap.
dtmf for DTMF tones (Section 2.7); 3.3 Event Types
fax for fax-related tones (Section 2.8); This payload definition is used for five different types of signals:
line for standard subscriber line tones (Section 2.9); o DTMF tones (Section 3.10);
linex for country-specific subscriber line tones (Section 3) and; o fax-related tones (Section 3.11);
trunk for trunk events (Section 3.1). The payload format is o standard subscriber line tones (Section 3.12);
identical, but the payload types assigned MUST be different.
The separation into different payload types makes it easy o for country-specific subscriber line tones (Section 3.13) and;
for end systems to declare their capabilities using session
description protocols such as SDP. If desired, end systems o for trunk events (Section 3.14).
can declare support of a subset of these payload types by
including a "fmtp" parameter listing the supported event
types. Details are for further study.
A compliant implementation MUST support the events listed in Table 1. A compliant implementation MUST support the events listed in Table 1.
If it uses some other, out-of-band mechanism for signaling line If it uses some other, out-of-band mechanism for signaling line
conditions, it does not have to implement the other payload types. conditions, it does not have to implement the other events.
In some cases, an implementation may simply ignore certain events, In some cases, an implementation may simply ignore certain events,
such as fax tones, that do not make sense in a particular such as fax tones, that do not make sense in a particular
environment. Depending on the available user interfaces, an environment. Section 3.9 specifies how an implementation can use the
implementation MAY render all tones in Table 5 the same or, SDP "fmtp" parameter within an SDP description to indicate its
preferably, use the tones conveyed by the concurrent "tone" payload inability to understand a particular event or range of events.
or other RTP audio payload. Alternatively, it could provide a textual
representation. Depending on the available user interfaces, an implementation MAY
render all tones in Table 5 the same or, preferably, use the tones
conveyed by the concurrent "tone" payload or other RTP audio payload.
Alternatively, it could provide a textual representation.
Note that end systems that emulate telephones only need to support Note that end systems that emulate telephones only need to support
the "dtmf" and "line" payload type. Systems that receive trunk the events described in Sections 3.10 and 3.12, while systems that
signaling need to implement the "dtmf", "fax", "line", and "trunk' receive trunk signaling need to implement those in Sections 3.10,
payload types, since MF trunks also carry most of the "line" signals. 3.11, 3.12 and 3.14, since MF trunks also carry most of the "line"
Systems that do not support fax functionality do not need to render signals. Systems that do not support fax or modem functionality do
fax-related events in the "fax" payload type. not need to render fax-related events described in Section 3.11.
The RTP payload type is designated as "telephone-event", the MIME
type as "audio/telephone-event". The default timestamp rate is 8,000
Hz, but other rates may be defined. In accordance with current
practice, this payload type does not have a static payload type
number, but uses a RTP payload type number established dynamically
and out-of-band.
The payload type distinguishes between a (line) DTMF 0 tone and a The payload type distinguishes between a (line) DTMF 0 tone and a
(trunk) MF 0 tone. They payload type is signalled dynamically (for (trunk) MF 0 tone. They payload type is signalled dynamically (for
example, within an SDP [4] or an H.245 message), or by some other example, within an SDP [4] or an H.245 message), or by some other
non-RTP means. non-RTP means.
2.2 Use of RTP Header Fields 3.4 Use of RTP Header Fields
Timestamp: The RTP timestamp reflects the measurement point for the Timestamp: The RTP timestamp reflects the measurement point for
current packet. The event duration described in Section 2.3 the current packet. The event duration described in Section
extends forwards [NOTE: was "backwards", but that's different 3.5 extends forwards from that time.
from all other payloads and disagrees with RFC 1889] from that
time.
2.3 Payload Format Marker bit: The RTP marker bit indicates the beginning of a new
event.
3.5 Payload Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |R R| volume | duration | | event |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
events: The DTMF digits and line events are encoded as shown in events: The events are encoded as shown in Sections 3.10 through
Section 2.9; the trunk events are shown in Section 3.1. 3.14.
volume: The power level of the digit, expressed in dBm0 after volume: For DTMF digits, this field describes the power level of
dropping the sign, with range from 0 to -63 dBm0. The range of the tone, expressed in dBm0 after dropping the sign. Power
valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 levels range from 0 to -63 dBm0. The range of valid DTMF is
dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must
values denote lower volume. This value is defined only for DTMF be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger
digits. For other events, it is set to zero. values denote lower volume. This value is defined only for
DTMF digits. For other events, it is set to zero by the
sender and is ignored by the receiver.
Note: Since the acceptable dip is 10 dB and the minimum detectable Note: Since the acceptable dip is 10 dB and the minimum
loudness variation is 3 dB, this field could be compressed by at detectable loudness variation is 3 dB, this field could be
least a bit by reducing resolution to 2 dB, if needed. compressed by at least a bit by reducing resolution to 2
dB, if needed.
duration: Duration of this digit, in timestamp units. Thus, the digit duration: Duration of this digit, in timestamp units. Thus, the
began at the instant identified by the RTP timestamp. event began at the instant identified by the RTP timestamp
and has so far lasted as long as indicated by this
parameter. The event may or may not have ended.
For a sampling rate of 8000 Hz, this field is sufficient to For a sampling rate of 8000 Hz, this field is
express digit durations of upto approximately 8 seconds. sufficient to express event durations of up to
approximately 8 seconds.
R: This field is reserved for future use. The sender MUST set it to E: If set to a value of one, the "end" bit indicates that this
zero, the receiver MUST ignore it. packet contains the end of the event. Thus, the duration
parameter above measures the complete duration of the
event.
Receiver implementations can use at least two
different algorithms to create tones. In the first,
the receiver simply places a tone of the given
duration in the audio playout buffer at the location
indicated by the timestamp. As additional packets are
received that extend the tone, the waveform in the
playout buffer is adjusted accordingly. Thus, if a
packet in a tone lasting longer than the packet
interarrival time gets lost and the playout delay is
short, a gap in the tone may occur. Alternatively, the
receiver can start a tone and play it until it
receives a packet with the "E" bit set or the next
tone, distinguished by a different timestamp value.
This is more robust against packet loss, but may
extend the tone if all retransmissions of the last
packet in an event are lost.
R: This field is reserved for future use. The sender MUST set it
to zero, the receiver MUST ignore it.
3.6 Sending Event Packets
An audio source SHOULD start transmitting event packets as soon as it An audio source SHOULD start transmitting event packets as soon as it
recognizes an event and every 50 ms thereafter or the packet interval recognizes an event and every 50 ms thereafter or the packet interval
for the audio codec used for this session, if known. (Precise spacing for the audio codec used for this session, if known. (Precise spacing
between event packets is not necessary.) between event packets is not necessary.)
Q.24 [5], Table A-1, indicates that all administrations Q.24 [5], Table A-1, indicates that all administrations
surveyed use a minimum signal duration of 40 ms, with surveyed use a minimum signal duration of 40 ms, with
signaling velocity (tone and pause) of no less than 93 ms. signaling velocity (tone and pause) of no less than 93 ms.
If a digit continues for more than one period, it should send a new If an event continues for more than one period, the source generating
event packet with the RTP timestamp value corresponding to the the events should send a new event packet with the RTP timestamp
beginning of the digit and the duration of the digit increased value corresponding to the beginning of the event and the duration of
correspondingly. (The RTP sequence number is incremented by one for the event increased correspondingly. (The RTP sequence number is
each packet.) If there has been no new digit in the last interval, incremented by one for each packet.) If there has been no new event
the digit SHOULD be retransmitted three times (or until the next in the last interval, the event SHOULD be retransmitted three times
event is recognized) to ensure some measure of reliability for the or until the next event is recognized. This ensures that the duration
last event. of the event can be recognized correctly even if the last packet for
an event is lost.
DTMF digits and events are sent incrementally to avoid DTMF digits and events are sent incrementally to avoid
having the receiver wait for the completion of the digit. having the receiver wait for the completion of the event.
Since some tones are two seconds long, this would incur a Since some tones are two seconds long, this would incur a
substantial delay. The transmitter does not know if digit substantial delay. The transmitter does not know if event
length is important and thus needs to transmit immediately length is important and thus needs to transmit immediately
and incrementally. If the receiver application does not and incrementally. If the receiver application does not
care about digit length, the incremental transmission care about event length, the incremental transmission
mechanism avoids delay. Some applications, such as gateways mechanism avoids delay. Some applications, such as gateways
into the GSTN, care about both delays and digit duration. into the PSTN, care about both delays and event duration.
2.4 Reliability 3.7 Reliability
To achieve reliability even when the network loses packets, the audio
redundancy mechanism described in RFC 2198 [6] is used. The effective During an event, the RTP event payload type provides incremental
data rate is r times 64 bits (32 bits for the redundancy header and updates on the event. The error resiliency depends on the playout
32 bits for the DTMF payload) every 50 ms or r times 1280 delay at the receiver. For example, for a playout delay of 120 ms and
bits/second, where r is the number of redundant DTMF digits carried a packet gap of 50 ms, two packets in a row can get lost without
in each packet. The value of r is an implementation trade-off, with a causing a gap in the tones generated at the receiver.
value of 5 suggested.
The audio redundancy mechanism described in RFC 2198 [6] MAY be used
to recover from packet loss across events. The effective data rate is
r times 64 bits (32 bits for the redundancy header and 32 bits for
the DTMF payload) every 50 ms or r times 1280 bits/second, where r is
the number of redundant events carried in each packet. The value of r
is an implementation trade-off, with a value of 5 suggested.
The timestamp offset in this redundancy scheme has 14 bits, The timestamp offset in this redundancy scheme has 14 bits,
so that it allows a single packet to "cover" 2.048 seconds so that it allows a single packet to "cover" 2.048 seconds
of DTMF digits at a sampling rate of 8000 Hz. Including the of telephone events at a sampling rate of 8000 Hz.
starting time of previous digits allows precise Including the starting time of previous events allows
reconstruction of the tone sequence at a gateway. The precise reconstruction of the tone sequence at a gateway.
scheme is resilient to consecutive packet losses spanning The scheme is resilient to consecutive packet losses
this interval of 2.048 seconds or r digits, whichever is spanning this interval of 2.048 seconds or r digits,
less. Note that for previous digits, only an average whichever is less. Note that for previous digits, only an
loudness can be represented. average loudness can be represented.
An encoder MAY treat the event payload as a highly-compressed version An encoder MAY treat the event payload as a highly-compressed version
of the current audio frame. In that mode, each RTP packet during a of the current audio frame. In that mode, each RTP packet during a
DTMF tone would contain the current audio codec rendition (say, DTMF tone would contain the current audio codec rendition (say,
G.723.1 or G.729) of this digit as well as the representation G.723.1 or G.729) of this digit as well as the representation
described in Section 2.3, plus any previous digits as before. described in Section 3.5, plus any previous digits as before.
This approach allows dumb gateways that do not understand This approach allows dumb gateways that do not understand
this format to function. See also the discussion in Section this format to function. See also the discussion in Section
1. 1.
TBD: It may be possible 3.8 Example
2.5 Example
A typical RTP packet, where the user is just dialing the last digit A typical RTP packet, where the user is just dialing the last digit
of the DTMF sequence "911". The first digit was 200 ms long (1600 of the DTMF sequence "911". The first digit was 200 ms long (1600
timestamp units) and started at time 0, the second digit lasted 250 timestamp units) and started at time 0, the second digit lasted 250
ms (2000 timestamp units) and started at time 800 ms (6400 timestamp ms (2000 timestamp units) and started at time 800 ms (6400 timestamp
units), the third digit was pressed at time 1.4 s (11,200 timestamp units), the third digit was pressed at time 1.4 s (11,200 timestamp
units) and the packet shown was sent at 1.45 s (11,600 timestamp units) and the packet shown was sent at 1.45 s (11,600 timestamp
units). The frame duration is 50 ms. To make the parts recognizable, units). The frame duration is 50 ms. To make the parts recognizable,
the figure below ignores byte alignment. Timestamp and sequence the figure below ignores byte alignment. Timestamp and sequence
number are assumed to have been zero at the beginning of the first number are assumed to have been zero at the beginning of the first
digit. In this example, the dynamic payload types 96 and 97 have been digit. In this example, the dynamic payload types 96 and 97 have been
assigned for the redundancy mechanism and the DTMF payload, assigned for the redundancy mechanism and the telephone event
respectively. payload, respectively.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number | |V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 28 | | 2 |0|0| 0 |0| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | | timestamp |
| 11200 | | 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 36 skipping to change at page 9, line 48
| digit |R R| volume | duration | | digit |R R| volume | duration |
| 9 |0 0| 7 | 1600 | | 9 |0 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |R R| volume | duration | | digit |R R| volume | duration |
| 1 |0 0| 10 | 2000 | | 1 |0 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |R R| volume | duration | | digit |R R| volume | duration |
| 1 |0 0| 20 | 400 | | 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.6 Compact Reliability Scheme 3.9 Indication of Receiver Capabilities using SDP
Receivers MAY indicate which named events they can handle, for
example, by using the Session Description Protocol (RFC 2327 [4]).
The payload types use the following fmtp format to list the event
values that they can receive:
A more compact representation could be achieved by measuring DTMF a=fmtp:<format> <list of values>
tones in a different sampling rate from that of the surrounding audio
codec, e.g., as multiples of 1, 10, 40 or 50 ms. Each RTP payload
type should have a fixed sampling rate, so choosing a value that
depends on frame interval of the surrounding codec is not
recommended. For a sampling interval of 50 ms, the following payload
would "cover" 8 seconds of duration and offset:
0 1 2 3 The list of values consists of comma-separated elements, which can be
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 either a single decimal number or two decimal numbers separated by a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ hyphen (dash), where the second number is larger than the first. No
| offset |R R R| digit |R R| volume | duration | whitespace is allowed between numbers or hyphens. The list does not
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ have to be sorted.
2.7 DTMF Events For example, if the data "codec" (Section 3.11) has been assigned the
payload type number 100 and the implementation can handle the common
DTMF tones as well as dial and PBX dial tones.
Tables 1 summarizes the events belonging to the DTMF payload type. It a=fmtp:100 0-11,66,67
uses the RTP encoding name "dtmf" and the MIME type "audio/dtmf".
The corresponding MIME parameter is "events", so that the following
sample media type definition corresponds to the SDP example above:
audio/telephony-events;events="0-11,66,67"
3.10 DTMF Events
Tables 1 summarizes the events belonging to the DTMF payload type.
3.11 Data Modem and Fax Events
Table 3.11 summarizes the events and tones that can appear on a
subscriber line serving a fax machine or modem. The tones are
described below, with additional detail in Table 7.
ANS: This 2100 +/- 15 Hz tone is used to disable echo
suppression for data transmission [7,8]. For fax machines,
Recommendation T.30 [8] refers to this tone as called
terminal identification (CED) answer tone.
Event encoding (decimal) Event encoding (decimal)
_________________________ _________________________
0--9 0--9 0--9 0--9
* 10 * 10
# 11 # 11
A--D 12--15 A--D 12--15
Flash 16 Flash 16
Table 1: DTMF events Table 1: DTMF events
2.8 Data Modem and Fax Events /ANS: This is the same signal as ANS, except that it reverses
phase at an interval of 450 +/- 25 ms. It disables both
Table 2.8 summarizes the events and tones that can appear on a echo cancellers and echo suppressors. (In the ITU
subscriber line serving a fax machine or modem. It uses the encoding Recommendation, this signal is rendered as ANS with a bar
name "data" and the MIME type "audio/data". The tones are described on top.)
below, with additional detail in Table 7.
ANS: This 2100 +/- 15 Hz tone is used to disable echo suppression for ANSam: The modified answer tone (ANSam) [2] is a sinewave signal
data transmission [7,8]. For fax machines, Recommendation T.30 at 2100 +/- 1 Hz with phase reversals at an interval of 450
[8] refers to this tone as called terminal identification (CED) +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1
answer tone. Hz. This tone [9,7] is sent by modems [10] and faxes to
disable echo suppressors.
/ANS: This is the same signal as ANS, except that it reverses phase /ANSam: This is the same signal as ANSam, except that it
at an interval of 450 +/- 25 ms. It disables both echo reverses phase at an interval of 450 +/- 25 ms. It disables
cancellers and echo suppressors. (In the ITU Recommendation, both echo cancellers and echo suppressors. (In the ITU
this signal is rendered as ANS with a bar on top.) Recommendation, this signal is rendered as ANSam with a bar
on top.)
ANSam: The modified answer tone (ANSam) [2] is a sinewave signal at CNG: After dialing the called fax machine's telephone number
2100 +/- 1 Hz with phase reversals at an interval of 450 +/- 25 (and before it answers), the calling Group III fax machine
ms, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This (optionally) begins sending a CalliNG tone (CNG) consisting
tone [9,7] is sent by modems [10] and faxes to disable echo of an interrupted tone of 1100 Hz. [8]
suppressors.
/ANSam: This is the same signal as ANSam, except that it reverses CRd: Capabilities Request (CRd) [11] is a dual-tone signal with
phase at an interval of 450 +/- 25 ms. It disables both echo tones at tones at 1375 Hz and 2002 Hz for 400 ms for the
cancellers and echo suppressors. (In the ITU Recommendation, initiating side and 1529 Hz and 2225 Hz for the responding
this signal is rendered as ANSam with a bar on top.) side, followed by a single tone at 1900 Hz for 100 ms.
CNG: After dialing the called fax machine's telephone number (and "This signal requests the remote station transition from
before it answers), the calling Group III fax machine telephony mode to an information transfer mode and requests
(optionally) begins sending a CalliNG tone (CNG) consisting of the transmission of a capabilities list message by the
an interrupted tone of 1100 Hz. [8] remote station. In particular, CRd is sent by the
initiating station during the course of a call, or by the
calling station at call establishment in response to a CRe
or MRe."
CRd: Capabilities Request (CRd) [11] is a dual-tone signal with tones CRe: Capabilities Request (CRe) [11] is a dual-tone signal with
at tones at 1375 Hz and 2002 Hz for 400 ms for the initiating tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed
side and 1529 Hz and 2225 Hz for the responding side, followed by a single tone at 400 Hz for 100 ms. "This signal
by a single tone at 1900 Hz for 100 ms. "This signal requests requests the remote station transition from telephony mode
the remote station transition from telephony mode to an to an information transfer mode and requests the
information transfer mode and requests the transmission of a transmission of a capabilities list message by the remote
capabilities list message by the remote station. In particular, station. In particular, CRe is sent by an automatic
CRd is sent by the initiating station during the course of a answering station at call establishment."
call, or by the calling station at call establishment in
response to a CRe or MRe."
CRe: Capabilities Request (CRe) [11] is a dual-tone signal with tones ESi: Escape Signal (ESi) [11] is a dual-tone signal with tones
at tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single at 1375 Hz and 2002 Hz for 400 ms, followed by a single
tone at 400 Hz for 100 ms. "This signal requests the remote tone at 980 Hz for 100 ms. "This signal requests the remote
station transition from telephony mode to an information station transition from telephony mode to an information
transfer mode and requests the transmission of a capabilities transfer mode. signal ESi is sent by the initiating
list message by the remote station. In particular, CRe is sent station."
by an automatic answering station at call establishment."
ESi: Escape Signal (ESi) [11] is a dual-tone signal with tones at ESr: Escape Signal (ESr) [11] is a dual-tone signal with tones
1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 980 at 1529 Hz and 2225 Hz for 400 ms, followed by a single
Hz for 100 ms. "This signal requests the remote station tone at 1650 Hz for 100 ms. Same as ESi, but sent by the
transition from telephony mode to an information transfer mode. responding station.
signal ESi is sent by the initiating station."
ESr: Escape Signal (ESr) [11] is a dual-tone signal with tones at MRd: Mode Request (MRd) [11] is a dual-tone signals with tones
1529 Hz and 2225 Hz for 400 ms, followed by a single tone at at 1375 Hz and 2002 Hz for 400 ms for the initiating side
1650 Hz for 100 ms. Same as ESi, but sent by the responding and 1529 Hz and 2225 Hz for the responding side, followed
station. by a single tone at 1150 Hz for 100 ms. "This signal
requests the remote station transition from telephony mode
to an information transfer mode and requests the
transmission of a mode select message by the remote
station. In particular, signal MRd is sent by the
initiating station during the course of a call, or by the
calling station at call establishment in response to an
MRe." [11]
MRd: Mode Request (MRd) [11] is a dual-tone signals with tones at MRe: Mode Request (MRe) [11] is a dual-tone signal with tones at
1375 Hz and 2002 Hz for 400 ms for the initiating side and 1529 1375 Hz and 2002 Hz for 400 ms, followed by a single tone
Hz and 2225 Hz for the responding side, followed by a single at 650 Hz for 100 ms. "This signal requests the remote
tone at 1150 Hz for 100 ms. "This signal requests the remote
station transition from telephony mode to an information station transition from telephony mode to an information
transfer mode and requests the transmission of a mode select transfer mode and requests the transmission of a mode
message by the remote station. In particular, signal MRd is sent select message by the remote station. In particular, signal
by the initiating station during the course of a call, or by the MRe is sent by an automatic answering station at call
calling station at call establishment in response to an MRe." establishment." [11]
[11]
MRe: Mode Request (MRe) [11] is a dual-tone signal with tones at 1375
Hz and 2002 Hz for 400 ms, followed by a single tone at 650 Hz
for 100 ms. "This signal requests the remote station transition
from telephony mode to an information transfer mode and requests
the transmission of a mode select message by the remote station.
In particular, signal MRe is sent by an automatic answering
station at call establishment." [11]
V.21: V.21 describes a 300 b/s full-duplex modem that employs V.21: V.21 describes a 300 b/s full-duplex modem that employs
frequency shift keying (FSK). It is now used by Group 3 fax frequency shift keying (FSK). It is now used by Group 3 fax
machines to exchange T.30 information. The calling transmits on machines to exchange T.30 information. The calling
channel 1 and receives on channel 2; the answering modem transmits on channel 1 and receives on channel 2; the
transmits on channel 2 and receives on channel 1. Each bit value answering modem transmits on channel 2 and receives on
has a distinct tone, so that V.21 signaling comprises a total of channel 1. Each bit value has a distinct tone, so that V.21
four distinct tones. signaling comprises a total of four distinct tones.
In summary, procedures in Table 2 are used. In summary, procedures in Table 2 are used.
Procedure indications Procedure indications
________________________________________________________ ________________________________________________________
V.25 and V.8 ANS, ANS, ... V.25 and V.8 ANS, ANS, ...
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam, ANSam, ... V.8 ANSam, ANSam, ...
V.8, echo canceller disabled ANSam, /ANSam, ANSam, ... V.8, echo canceller disabled ANSam, /ANSam, ANSam, ...
Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations
Event____________________encoding_(decimal) Event____________________encoding_(decimal)
Answer tone (ANS) 1 Answer tone (ANS) 32
ANSam 2 /ANS 33
Calling tone (CNG) 3 ANSam 34
V.21 channel 1, "0" bit 4 /ANSam 35
V.21 channel 1, "1" bit 5 Calling tone (CNG) 36
V.21 channel 2, "0" bit 6 V.21 channel 1, "0" bit 37
V.21 channel 2, "1" bit 7 V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40
CRd 41
CRe 42
ESi 43
ESr 44
MRd 45
MRe 46
Table 3: Data and fax events Table 3: Data and fax events
2.9 Line Events 3.12 Line Events
Table 4 summarizes the events and tones that can appear on a Table 4 summarizes the events and tones that can appear on a
subscriber line. It uses the encoding name "line" and the MIME type subscriber line.
"audio/line".
ITU Recommendation E.182 [12] defines when certain tones should be ITU Recommendation E.182 [12] defines when certain tones should be
used. It defines the following standard tones that are heard by the used. It defines the following standard tones that are heard by the
caller: caller:
Dial tone: The exchange is ready to receive address information. Dial tone: The exchange is ready to receive address information.
PABX internal dial tone: The PABX is ready to receive address PABX internal dial tone: The PABX is ready to receive address
information. information.
Special dial tone: Same as dial tone, but the caller's line is Special dial tone: Same as dial tone, but the caller's line is
subject to a specific condition, such as call diversion or a subject to a specific condition, such as call diversion or
voice mail is available (e.g., "stutter dial tone"). a voice mail is available (e.g., "stutter dial tone").
Second dial tone: The network has accepted the address information, Second dial tone: The network has accepted the address
but additional information is required. information, but additional information is required.
Ringing tone: The call has been placed to the callee and a calling Ringing tone: The call has been placed to the callee and a
signal (ringing) is being transmitted to the callee. calling signal (ringing) is being transmitted to the
callee.
Special ringing tone: A special service, such as call forwarding or Special ringing tone: A special service, such as call forwarding
call waiting, is active at the called number. or call waiting, is active at the called number.
Busy tone: The called telephone number is busy. Busy tone: The called telephone number is busy.
Congestion tone: Facilities necessary for the call are temporarily Congestion tone: Facilities necessary for the call are
unavailable. temporarily unavailable.
Calling card service tone: The calling card service tone consists of Calling card service tone: The calling card service tone
60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'), consists of 60 ms of the sum of 941 Hz and 1477 Hz tones
followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone), (DTMF '#'), followed by 940 ms of 350 Hz and 440 Hz (U.S.
decaying exponentially with a time constant of 200 ms. dial tone), decaying exponentially with a time constant of
200 ms.
Special information tone: The callee cannot be reached, but the Special information tone: The callee cannot be reached, but the
reason is neither "busy" nor "congestion". This tone should be reason is neither "busy" nor "congestion". This tone should
used before all call failure announcements, for the benefit of be used before all call failure announcements, for the
automatic equipment. benefit of automatic equipment.
Comfort tone: The call is being processed. This tone may be used Comfort tone: The call is being processed. This tone may be used
during long post-dial delays, e.g., in international during long post-dial delays, e.g., in international
connections. connections.
Hold tone: The caller has been placed on hold. Replaced by Hold tone: The caller has been placed on hold. Replaced by
Greensleeves Greensleeves
Record tone: The caller has been connected to an automatic answering Record tone: The caller has been connected to an automatic
device and is requested to begin speaking. answering device and is requested to begin speaking.
Caller waiting tone: The called station is busy, but has call waiting Caller waiting tone: The called station is busy, but has call
service. waiting service.
Pay tone: The caller, at a payphone, is reminded to deposit Pay tone: The caller, at a payphone, is reminded to deposit
additional coins. additional coins.
Positive indication tone: The supplementary service has been Positive indication tone: The supplementary service has been
activated. activated.
Negative indication tone: The supplementary service could not be Negative indication tone: The supplementary service could not be
Off-hook warning tone: The caller has left the instrument off-hook Off-hook warning tone: The caller has left the instrument off-
for an extended period of time. activated. hook for an extended period of time. activated.
The following tones can be heard be either calling or called party The following tones can be heard be either calling or called party
during a conversation: during a conversation:
Call waiting tone: Another party wants to reach the subscriber. Call waiting tone: Another party wants to reach the subscriber.
Warning tone: The call is being recorded. This tone is not required Warning tone: The call is being recorded. This tone is not
in all jurisdictions. required in all jurisdictions.
Intrusion tone: The call is being monitored, e.g., by an operator. Intrusion tone: The call is being monitored, e.g., by an
(Use by law enforcement authorities is optional.) operator. (Use by law enforcement authorities is optional.)
CPE alerting signal (CAS): A tone used to alert a device to an CPE alerting signal (CAS): A tone used to alert a device to an
arriving in-band FSK data transmission. A CAS is a combined 2130 arriving in-band FSK data transmission. A CAS is a combined
and 2750 Hz tone, both with tolerances of 0.5% and a duration of 2130 and 2750 Hz tone, both with tolerances of 0.5% and a
80 to 80 ms. CAS is used with ADSI services and Call Waiting ID duration of 80 to 80 ms. CAS is used with ADSI services and
services, see Bellcore GR-30-CORE, Issue 2, December 1998, Call Waiting ID services, see Bellcore GR-30-CORE, Issue 2,
Section 2.5.2. December 1998, Section 2.5.2.
The following tones are heard by operators: The following tones are heard by operators:
Payphone recognition tone: The person making the call or being called Payphone recognition tone: The person making the call or being
is using a payphone (and thus it is ill-advised to allow collect called is using a payphone (and thus it is ill-advised to
calls to such a person). allow collect calls to such a person).
3 Extended Line Events 3.13 Extended Line Events
Table 5 summarizes country-specific events and tones that can appear Table 5 summarizes country-specific events and tones that can appear
on a subscriber line. It uses the encoding name "linex" and the MIME on a subscriber line.
type "audio/linex".
3.1 Trunk Events 3.14 Trunk Events
Table 6 summarizes the events and tones that can appear on a trunk. Table 6 summarizes the events and tones that can appear on a trunk.
Note that trunk can also carry line events (Section 3.12), as MF
signaling does not include backward signals [13].
[NOTE: the list below, below wink, does not agree with the MF
description in van Bosse, p. 74.]
Event encoding (decimal) Event encoding (decimal)
_____________________________________________ _____________________________________________
Off Hook 0 Off Hook 64
On Hook 1 On Hook 65
Dial tone 2 Dial tone 66
PABX internal dial tone 3 PABX internal dial tone 67
Special dial tone 4 Special dial tone 68
Second dial tone 5 Second dial tone 69
Ringing tone 6 Ringing tone 70
Special ringing tone 7 Special ringing tone 71
Busy tone 8 Busy tone 72
Congestion tone 9 Congestion tone 73
Special information tone 10 Special information tone 74
Comfort tone 11 Comfort tone 75
Hold tone 12 Hold tone 76
Record tone 13 Record tone 77
Caller waiting tone 14 Caller waiting tone 78
Call waiting tone 15 Call waiting tone 79
Pay tone 16 Pay tone 80
Positive indication tone 17 Positive indication tone 81
Negative indication tone 18 Negative indication tone 82
Warning tone 19 Warning tone 83
Intrusion tone 20 Intrusion tone 84
Calling card service tone 21 Calling card service tone 85
Payphone recognition tone 22 Payphone recognition tone 86
CPE alerting signal (CAS) 23 CPE alerting signal (CAS) 87
Off-hook warning tone 24 Off-hook warning tone 88
Table 4: E.182 line events Table 4: E.182 line events
It uses the encoding name "TRUNK" and the MIME type "audio/trunk". ABCD transitional: 4-bit signaling used by digital trunks. For
Note that trunk can also carry line events, as MF signaling does not N-state signaling, the first N values are used.
include backward signals [13].
[NOTE: the list below, below wink, does not agree with the MF The T1 ESF (extended super frame format) allows 2, 4, and
description in van Bosse, p. 74.] 16 state signalling bit options. These signalling bits are
named A, B, C, and D. Signalling information is sent as
robbed bits in frames 6, 12, 18, and 24 when using ESF T1
framing. 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.
Since this 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 [14], Annex L. At the time of a transition,
Event encoding (decimal)
___________________________________________________
Acceptance tone 96
Confirmation tone 97
Dial tone, recall 98
End of three party service tone 99
Facilities tone 100
Line lockout tone 101
Number unobtainable tone 102
Offering tone 103
Permanent signal tone 104
Preemption tone 105
Queue tone 106
Refusal tone 107
Route tone 108
Valid tone 109
Waiting tone 110
Warning tone (end of period) 111
Warning Tone (PIP tone) 112
Table 5: Country-specific Line events
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.
Wink: A brief transition, typically 120-290 ms, from on-hook Wink: A brief transition, typically 120-290 ms, from on-hook
(unseized) to off-hook (seized) and back to onhook, used by the (unseized) to off-hook (seized) and back to onhook, used by
incoming exchange to signal that the call address signaling can the incoming exchange to signal that the call address
proceed. signaling can proceed.
Incoming seizure: Incoming indication of call attempt (off-hook). Incoming seizure: Incoming indication of call attempt (off-
hook).
Return seizure: Seizure by answering exchange, in response to Return seizure: Seizure by answering exchange, in response to
outgoing seizure. [NOTE: Not clear why the difference here, but outgoing seizure. [NOTE: Not clear why the difference here,
Event encoding (decimal) but not for Unseize. Should probably be just Seizure.]
___________________________________________________
Acceptance tone 0
Confirmation tone 1
Dial tone, recall 2
End of three party service tone 3
Facilities tone 4
Line lockout tone 5
Number unobtainable tone 6
Offering tone 7
Permanent signal tone 8
Preemption tone 9
Queue tone 10
Refusal tone 11
Route tone 12
Valid tone 13
Waiting tone 14
Warning tone (end of period) 15
Warning Tone (PIP tone) 16
Table 5: Country-specific Line events Unseize circuit: Transition of circuit from off-hook to on-hook
at the end of a call.
not for Unseize. Should probably be just Seizure.] Wink off: A brief transition, typically 100-350 ms, from off-
hook (seized) to on-hook (unseized) and back to off-hook
(seized). Used in operator services trunks.
Unseize circuit: Transition of circuit from off-hook to on-hook at Event encoding (decimal)
the end of a call. __________________________________________________
MF 0... 9 128... 137
MF K0 or KP (start-of-pulsing) 138
MF K1 139
MF K2 140
MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142... 143
ABCD signaling (see below) 144... 159
Wink 160
Wink off 161
Incoming seizure 162
Return seizure 163
Unseize circuit 164
Continuity test 165
Default continuity tone 166
Continuity tone (single tone) 167
Continuity test send 168
Continuity verified 170
Loopback 171
Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173
Wink off: A brief transition, typically 100-350 ms, from off-hook Table 6: Trunk events
(seized) to on-hook (unseized) and back to off-hook (seized).
Used in operator services trunks. [CHECK!]
Continuity tone send: A tone of 2010 Hz. Continuity tone send: A tone of 2010 Hz.
Continuity tone detect: A tone of 2010 Hz. Continuity tone detect: A tone of 2010 Hz.
Continuity test send: A tone of 1780 Hz is sent by the calling Continuity test send: A tone of 1780 Hz is sent by the calling
exchange. If received by the called exchange, it returns a exchange. If received by the called exchange, it returns a
"continuity verified" tone. "continuity verified" tone.
Continuity verified: A tone of 2010 Hz. This is a response tone, used Continuity verified: A tone of 2010 Hz. This is a response tone,
in dual-tone procedures. used in dual-tone procedures.
Line test: 105 [EXPLAIN!] test line progress tones (2225 Hz at -10
dbm0).
4 RTP Payload Format for Telephony Tones 4 RTP Payload Format for Telephony Tones
Event encoding (decimal)
__________________________________________________
MF 0... 9 0... 9
MF K0 or KP (start-of-pulsing) 10
MF K1 11
MF K2 12
MF S0 to ST (end-of-pulsing) 13
MF S1... S3 14... 16
Wink 17
Wink off 18
Incoming seizure 19
Return seizure 20
Unseize circuit 21
Continuity test 22
Default continuity tone 23
Continuity tone (single tone) 24
Continuity test send 25
Continuity verified 26
Loopback 27
Old milliwatt tone (1000 Hz) 28
New milliwatt tone (1004 Hz) 29
Table 6: Trunk events 4.1 Introduction
4.1 Requirements
As an alternative to describing tones and events by name, it is As an alternative to describing tones and events by name, as
sometimes preferable to describe them by their acoustic properties. described in Section 3, it is sometimes preferable to describe them
In particular, recognition is faster than for naming signals. by their waveform properties. In particular, recognition is faster
than for naming signals since it does not depend on recognizing
durations or pauses.
There is no single international standard for telephone tones such as There is no single international standard for telephone tones such as
dial tone, ringing (ringback), busy, congestion ("fast-busy"), dial tone, ringing (ringback), busy, congestion ("fast-busy"),
special announcement tones or some of the other special tones, such special announcement tones or some of the other special tones, such
as payphone recognition, call waiting or record tone. However, across as payphone recognition, call waiting or record tone. However, across
all countries, these tones share a number of characteristics [14]: all countries, these tones share a number of characteristics [15]:
o Tones consist of either a single tone, the addition of two or o Tones consist of either a single tone, the addition of two or
three tones or the modulation of two tones. (Almost all tones three tones or the modulation of two tones. (Almost all tones
use two frequencies; only the Hungarian "special dial tone" use two frequencies; only the Hungarian "special dial tone"
has three.) Tones that are mixed have the same amplitude and has three.) Tones that are mixed have the same amplitude and
do not decay. do not decay.
o Tones for telephony events are in the range of 25 (ringing o Tones for telephony events are in the range of 25 (ringing
tone in Angola) to 1800 Hz. CED is the highest used tone at tone in Angola) to 1800 Hz. CED is the highest used tone at
2100 Hz. The telephone frequency range is limited to 3,400 Hz. 2100 Hz. The telephone frequency range is limited to 3,400 Hz.
o Modulation frequencies range between 15 (ANSam tone) to 480 Hz o Modulation frequencies range between 15 (ANSam tone) to 480 Hz
(Jamaica). Non-integer frequencies are used only for (Jamaica). Non-integer frequencies are used only for
frequencies of 16 2/3 and 33 1/3 Hz. (These fractional frequencies of 16 2/3 and 33 1/3 Hz. (These fractional
frequencies appear to be derived from older AC power grid frequencies appear to be derived from older AC power grid
frequencies.) frequencies.)
o Tones that are not continuous have durations of less than four o Tones that are not continuous have durations of less than four
seconds. seconds.
o ITU Recommendation E.180 [15] notes that different telephone o ITU Recommendation E.180 [16] notes that different telephone
companies proscribe a tone accuracy of between 0.5 and 1.5%. companies proscribe a tone accuracy of between 0.5 and 1.5%.
The Recommendation suggests a frequency tolerance of 1%. The Recommendation suggests a frequency tolerance of 1%.
4.2 Examples of Common Telephone Tone Signals 4.2 Examples of Common Telephone Tone Signals
As an aid to the implementor, Table 7 summarizes some common tones. As an aid to the implementor, Table 7 summarizes some common tones.
The rows labeled "ITU ..." refer to the general recommendation of The rows labeled "ITU ..." refer to the general recommendation of
Recommendation E.180 [15]. Note that there are no specific guidelines Recommendation E.180 [16]. Note that there are no specific guidelines
for these tones. In the table, the symbol "+" indicates addition of for these tones. In the table, the symbol "+" indicates addition of
the tones, without modulation, while "*" indicates amplitude the tones, without modulation, while "*" indicates amplitude
modulation. [ADD ADDITIONAL COUNTRIES, IF DESIRED.] The meaning of modulation. The meaning of some of the tones is described in Section
some of the tones is described in Section 2.9 or Section 2.8 (for 3.12 or Section 3.11 (for V.21).
V.21).
4.3 Use of RTP Header Fields 4.3 Use of RTP Header Fields
Timestamp: The RTP timestamp reflects the measurement point for the Timestamp: The RTP timestamp reflects the measurement point for
current packet. The event duration described in Section 2.3 the current packet. The event duration described in Section
extends forwards [NOTE: was "backwards", but that's different 3.5 extends forwards [NOTE: was "backwards", but that's
from all other payloads and disagrees with RFC 1889] from that different from all other payloads and disagrees with RFC
time. 1889] from that time.
4.4 Payload Format
Based on the characteristics described above, the payload format is
shown in Fig. 1.
Figure 1: Payload format for tones
The payload contains the following fields:
modulation: The modulation frequency, in Hz. The field is a 9-bit
unsigned integer, allowing modulation frequencies up to 511 Hz.
Tone name frequency on period off period Tone name frequency on period off period
______________________________________________________ ______________________________________________________
CNG 1100 0.5 3.0 CNG 1100 0.5 3.0
CED 2100 3.3 -- CED 2100 3.3 --
ANS 2100 3.3 -- ANS 2100 3.3 --
ANSam 2100*15 3.3 -- ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.033 V.21 "0" bit, ch. 1 1180 0.033
V.21 "1" bit, ch. 1 980 0.033 V.21 "1" bit, ch. 1 980 0.033
V.21 "0" bit, ch. 2 1850 0.033 V.21 "0" bit, ch. 2 1850 0.033
skipping to change at page 18, line 28 skipping to change at page 20, line 28
ITU ringing tone 425 0.67--1.5 3--5 ITU ringing tone 425 0.67--1.5 3--5
U.S._ringing_tone_______440+480________2.0_________4.0 U.S._ringing_tone_______440+480________2.0_________4.0
ITU busy tone 425 ITU busy tone 425
U.S. busy tone 480+620 0.5 0.5 U.S. busy tone 480+620 0.5 0.5
______________________________________________________ ______________________________________________________
ITU congestion tone 425 ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25 U.S. congestion tone 480+620 0.25 0.25
Table 7: Examples of telephony tones Table 7: Examples of telephony tones
4.4 Payload Format
Based on the characteristics described above, this document defines
an RTP payload format called "tone". (The corresponding MIME type is
"audio/telephone-event".) The default timestamp rate is 8,000 Hz, but
other rates may be defined. Note that the timestamp rate does not
affect the interpretation of the frequency, just the durations.
In accordance with current practice, this payload type does not have
a static payload type number, but uses a RTP payload type number
established dynamically and out-of-band.
It is shown in Fig. 1.
Figure 1: Payload format for tones
The payload contains the following fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration | | modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency | |R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency | |R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency | |R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If there is no modulation, this field has a value of zero. modulation: The modulation frequency, in Hz. The field is a 9-
bit unsigned integer, allowing modulation frequencies up to
511 Hz. If there is no modulation, this field has a value
of zero.
T: If the "T" bit is set (one), the modulation frequency is to be T: If the "T" bit is set (one), the modulation frequency is to
divided by three. Otherwise, the modulation frequency is taken be divided by three. Otherwise, the modulation frequency is
as is. taken as is.
volume: The power level of the digit, expressed in dBm0 after volume: The power level of the digit, expressed in dBm0 after
dropping the sign, with range from 0 to -63 dBm0. (Note: A dropping the sign, with range from 0 to -63 dBm0. (Note: A
preferred level range for digital tone generators is -8 dBm0 to preferred level range for digital tone generators is -8
-3 dBm0.) dBm0 to -3 dBm0.)
duration: The duration of the tone, measured in timestamp units. The
tone begins at the instant identified by the RTP timestamp and
lasts for the duration value.
The definition of duration corresponds to that for sample- duration: The duration of the tone, measured in timestamp units.
based codecs, where the timestamp represents the sampling The tone begins at the instant identified by the RTP
point for the first sample. timestamp and lasts for the duration value.
frequency: The frequencies of the tones to be added, measured in Hz The definition of duration corresponds to that for
and represented as a 12-bit unsigned integer. The field size is sample-based codecs, where the timestamp represents
sufficient to represent frequencies up to 4095 Hz, which exceeds the sampling point for the first sample.
the range of telephone systems. A value of zero indicates
silence.
R: This field is reserved for future use. The sender MUST set it to frequency: The frequencies of the tones to be added, measured in
zero, the receiver MUST ignore it. Hz and represented as a 12-bit unsigned integer. The field
size is sufficient to represent frequencies up to 4095 Hz,
which exceeds the range of telephone systems. A value of
zero indicates silence.
The RTP payload type is designated as "TONE", the MIME type as R: This field is reserved for future use. The sender MUST set it
"audio/tone". The default timestamp rate is 8,000 Hz, but other rates to zero, the receiver MUST ignore it.
may be used. Note that the timestamp rate does not affect the
interpretation of the frequency, just the durations.
4.5 Reliability 4.5 Reliability
This payload type uses the reliability mechanism described in Section
3.7.
Same as Section 2.4. 5 Combining Tones and Named Events
5 Combining Tones and Named Signals
The payload formats in Sections 2 and 4 can be combined into a single The payload formats in Sections 3 and 4 can be combined into a single
payload, as shown in the example depicted in Fig. 2. In the example, payload, as shown in the example depicted in Fig. 2. In the example,
the RTP packet combines two TONE and one LINE payload. The payload the RTP packet combines two "tone" and one "telephone-event" payload.
types are chosen arbitrarily as 97 and 98, respectively, with a The payload types are chosen arbitrarily as 97 and 98, respectively,
sample rate of 8000 Hz. Here, the redundancy format has the dynamic with a sample rate of 8000 Hz. Here, the redundancy format has the
payload type 96. dynamic payload type 96.
The packet represents a snapshot of U.S. ringing tone, 1.5 seconds The packet represents a snapshot of U.S. ringing tone, 1.5 seconds
(12,000 timestamp units) into the second "on" part of the 2.0/4.0 (12,000 timestamp units) into the second "on" part of the 2.0/4.0
second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units)
into the ring cycle. The 440 + 480 Hz tone of this second cadence into the ring cycle. The 440 + 480 Hz tone of this second cadence
started at RTP timestamp 48,000. Four seconds of silence preceded it, started at RTP timestamp 48,000. Four seconds of silence preceded it,
but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds
(16383 timestamp units) can be represented. Even though the tone (16383 timestamp units) can be represented. Even though the tone
sequence is not complete, the sender was able to determine that this sequence is not complete, the sender was able to determine that this
is indeed ringback, and thus includes the corresponding LINE event. is indeed ringback, and thus includes the corresponding named event.
Figure 2: Combining tones and events in a single RTP packet
6 IANA Considerations
This document defines two new RTP payload types, named telephone-
event and tone, and associated Internet media (MIME) types,
audio/telephone-event and audio/tone.
Within the audio/telephone-event type, additional events MUST be
registered with IANA. Before registration, IANA should consult the
current chair of the AVT working group or its successor to avoid
duplication of definitions.
7 Acknowledgements
The suggestions of the Megaco working group are gratefully
acknowledged. Detailed advice and comments were provided by Fred
Burg, Fatih Erdin, Mike Fox, Terry Lyons, and Steve Magnell.
8 Authors
Henning Schulzrinne
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number | |V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 | | 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | | timestamp |
| 48000 | | 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
skipping to change at page 20, line 41 skipping to change at page 23, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 | |0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 | | modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 | |0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Combining tones and events in a single RTP packet
6 History
o This draft combines draft-ietf-avt-dtmf-00 and draft-ietf-
avt-telephone-tones-01.
o From draft draft-ietf-avt-dtmf-00, the interval was changed to
be uniform at 50 ms, since audio frame interval may change
based on codec.
o From draft-ietf-avt-telephone-tones-01, a generic tone
representation was added.
7 IANA Considerations
This document defines three new RTP payload names and associated MIME
Types, TONE (audio/tone), LINE (audio/line) and TRUNK (audio/trunk).
Within the TRUNK and LINE RTP payload types, additional entries for
events MUST be registered with IANA. Before registration, IANA should
consult the current chair of the AVT working group or its successor
to avoid duplication of definitions.
8 Acknowledgements
The suggestions of the Megaco working group are gratefully
acknowledged. Detailed advice and comments were provided by Fred
Burg, Fatih Erdin, Mike Fox, Terry Lyons, and Steve Magnell.
9 Authors
Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
Scott Petrack Scott Petrack
MetaTel MetaTel
284 North Avenue 45 Rumford Avenue
Weston, MA 02493 Waltham, MA 02453
USA USA
electronic mail: scott.petrack@metatel.com electronic mail: scott.petrack@metatel.com
10 Bibliography 9 Bibliography
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments transport protocol for real-time applications," Request for Comments
(Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.
[2] International Telecommunication Union, "Procedures for starting [2] International Telecommunication Union, "Procedures for starting
sessions of data transmission over the public switched telephone sessions of data transmission over the public switched telephone
network," Recommendation V.8, Telecommunication Standardization network," Recommendation V.8, Telecommunication Standardization
Sector of ITU, Geneva, Switzerland, Feb. 1998. Sector of ITU, Geneva, Switzerland, Feb. 1998.
skipping to change at page 23, line 14 skipping to change at page 25, line 26
[12] International Telecommunication Union, "Application of tones and [12] International Telecommunication Union, "Application of tones and
recorded announcements in telephone services," Recommendation E.182, recorded announcements in telephone services," Recommendation E.182,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
Mar. 1998. Mar. 1998.
[13] J. G. van Bosse, Signaling in Telecommunications Networks [13] J. G. van Bosse, Signaling in Telecommunications Networks
Telecommunications and Signal Processing, New York, New York: Wiley, Telecommunications and Signal Processing, New York, New York: Wiley,
1998. 1998.
[14] International Telecommunication Union, "Various tones used in [14] International Telecommunication Union, "AAL type 2 service
specific convergence sublayer for trunking," Recommendation I.366.2,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
Feb. 1999.
[15] International Telecommunication Union, "Various tones used in
national networks," Recommendation Supplement 2 to Recommendation national networks," Recommendation Supplement 2 to Recommendation
E.180, Telecommunication Standardization Sector of ITU, Geneva, E.180, Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Jan. 1994. Switzerland, Jan. 1994.
[15] International Telecommunication Union, "Technical [16] International Telecommunication Union, "Technical
characteristics of tones for telephone service," Recommendation characteristics of tones for telephone service," Recommendation
Supplement 2 to Recommendation E.180, Telecommunication Supplement 2 to Recommendation E.180, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994. Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/