draft-ietf-avt-tones-01.txt   draft-ietf-avt-tones-02.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-01.txt Columbia U./MetaTel ietf-avt-tones-02.txt Columbia U./MetaTel
September 26, 1999 October 22, 1999
Expires: February 2000 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 To view the list Internet-Draft Shadow Directories, see
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. 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 two payload types, one for carrying dual-tone This memo defines two payload formats, one for carrying dual-tone
multifrequency (DTMF) digits, other line and trunk signals and a multifrequency (DTMF) digits, other line and trunk signals (Section
second one for general multi-frequency tones in RTP [1] packets. 3), and a second one for general multi-frequency tones in RTP [1]
Separate RTP payload types are desirable since low-rate voice codecs packets (Section 4). Separate RTP payload formats are desirable since
cannot be guaranteed to reproduce these tone signals accurately low-rate voice codecs cannot be guaranteed to reproduce these tone
enough for automatic recognition. Defining a separate payload type signals accurately enough for automatic recognition. Defining a
also permits higher redundancy while maintaining a low bit rate. separate payload formats also permits higher redundancy while
maintaining a low bit rate.
The payload types described here may be useful in at least three The payload formats 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. Secondly, 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
skipping to change at page 2, line 33 skipping to change at page 2, line 34
the gateway needs to remove the in-band signaling information from the gateway needs to remove the in-band signaling information from
the 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.
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 [2] and
indicate requirement levels for compliant implementations.
2 Events vs. Tones 2 Events vs. Tones
A gateway has two options for handling DTMF digits and events. First, A gateway has two options for handling DTMF digits and events. First,
it can simply measure the frequency components of the voice band it can simply measure the frequency components of the voice band
signals and transmit this information to the RTP receiver (Section signals and transmit this information to the RTP receiver (Section
4). In this mode, the gateway makes no attempt to discern the meaning 4). In this mode, the gateway makes no attempt to discern the meaning
of the tones, but simply distinguishes tones from speech signals. of the tones, but simply distinguishes tones from speech signals.
All tone signals in use in the PSTN and meant for human consumption All tone signals in use in the PSTN and meant for human consumption
are sequences of simple combinations of sine waves, either added or 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 [3] 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, a gateway can recognize the tones and translate As a second option, a gateway can recognize the tones and translate
them into a name, such as ringing or busy tone. The receiver then them into a name, such as ringing or busy tone. The receiver then
produces 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
skipping to change at page 3, line 36 skipping to change at page 3, line 44
the callee's phone rings. (This reduces the chance of clipping of the the callee's phone rings. (This reduces the chance of clipping of the
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 MAY send both named
signals (Section 3) 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
3.7 to interleave the two representations. The receiver can then 3.7 to interleave the two representations. It is generally a good
choose the appropriate rendering. idea to send both, since it allows the receiver to 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 format
PCMU), in addition to the named signals. PCMU), in addition to the named signals.
3 RTP Payload Format for Named Telephone Events 3 RTP Payload Format for Named Telephone Events
3.1 Introduction 3.1 Introduction
The payload type for named telephone events described below is The payload format for named telephone events described below is
suitable for both gateway and end-to-end scenarios. In the gateway suitable for both gateway and end-to-end scenarios. In the gateway
scenario, an Internet telephony gateway connecting a packet voice scenario, an Internet telephony gateway connecting a packet voice
network to the PSTN recreates the DTMF tones or other telephony network to the PSTN recreates the DTMF tones or other telephony
events and injects them into the PSTN. Since, for example, DTMF digit events and injects them into the PSTN. Since, for example, DTMF digit
recognition takes several tens of milliseconds, the first few recognition takes several tens of milliseconds, the first few
milliseconds of a digit will arrive as regular audio packets. Thus, milliseconds of a digit will arrive as regular audio packets. Thus,
careful time and power (volume) alignment between the audio samples careful time and power (volume) alignment between the audio samples
and the events is needed to avoid generating spurious digits at the and the events is needed to avoid generating spurious digits at the
receiver. receiver.
DTMF digits and named telephone events are carried as part of the DTMF digits and named telephone events are carried as part of the
audio stream, and SHOULD use the same sequence number and time-stamp audio stream, and SHOULD use the same sequence number and time-stamp
base as the regular audio channel to simplify the generation of audio base as the regular audio channel to simplify the generation of audio
waveforms at a gateway. The default clock frequency is 8,000 Hz, but waveforms at a gateway. The default clock frequency is 8,000 Hz, but
the clock frequency can be redefined when assigning the dynamic the clock frequency can be redefined when assigning the dynamic
payload type. payload type.
The payload format described here achieves a higher redundancy even The payload format described here achieves a higher redundancy even
in the case of sustained packet loss than the method proposed for the in the case of sustained packet loss than the method proposed for the
Voice over Frame Relay Implementation Agreement [3]. Voice over Frame Relay Implementation Agreement [4].
If an end system is directly connected to the Internet and does not If an end system is directly connected to the Internet and does not
need to generate tone signals again, time alignment and power levels need to generate tone signals again, time alignment and power levels
are not relevant. These systems rely on PSTN gateways or Internet end are not relevant. These systems rely on PSTN gateways or Internet end
systems to generate DTMF events and do not perform their own audio systems to generate DTMF events and do not perform their own audio
waveform analysis. An example of such a system is an Internet waveform analysis. An example of such a system is an Internet
interactive voice-response (IVR) system. 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 or other events is not important and data stream and the DTMF digits or other events is not important and data
skipping to change at page 4, line 50 skipping to change at page 5, line 11
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.
Note that a period covered by an encoded tone may overlap in time 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 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 occur at the onset of a tone and is necessary to avoid possible
errors in the interpretation of the reproduced tone at the remote errors in the interpretation of the reproduced tone at the remote
end. Implementations supporting this payload type must be prepared end. Implementations supporting this payload format must be prepared
to handle the overlap. to handle the overlap. It is RECOMMENDED that gateways only render
the encoded tone since the audio may contain spurious tones
introduced by the audio compression algorithm. However, it is
anticipated that these extra tones in general should not interfere
with recognition at the far end.
3.3 Event Types 3.3 Event Types
This payload definition is used for five different types of signals: This payload format is used for five different types of signals:
o DTMF tones (Section 3.10); o DTMF tones (Section 3.10);
o fax-related tones (Section 3.11); o fax-related tones (Section 3.11);
o standard subscriber line tones (Section 3.12); o standard subscriber line tones (Section 3.12);
o for country-specific subscriber line tones (Section 3.13) and; o for country-specific subscriber line tones (Section 3.13) and;
o for trunk events (Section 3.14). o for trunk events (Section 3.14).
skipping to change at page 5, line 41 skipping to change at page 6, line 6
conveyed by the concurrent "tone" payload or other RTP audio payload. conveyed by the concurrent "tone" payload or other RTP audio payload.
Alternatively, it could provide a textual representation. 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 events described in Sections 3.10 and 3.12, while systems that the events described in Sections 3.10 and 3.12, while systems that
receive trunk signaling need to implement those in Sections 3.10, receive trunk signaling need to implement those in Sections 3.10,
3.11, 3.12 and 3.14, since MF trunks also carry most of the "line" 3.11, 3.12 and 3.14, since MF trunks also carry most of the "line"
signals. Systems that do not support fax or modem functionality do signals. Systems that do not support fax or modem functionality do
not need to render fax-related events described in Section 3.11. not need to render fax-related events described in Section 3.11.
The RTP payload type is designated as "telephone-event", the MIME The RTP payload format is designated as "telephone-event", the MIME
type as "audio/telephone-event". The default timestamp rate is 8,000 type as "audio/telephone-event". The default timestamp rate is 8000
Hz, but other rates may be defined. In accordance with current Hz, but other rates may be defined. In accordance with current
practice, this payload type does not have a static payload type practice, this payload format does not have a static payload type
number, but uses a RTP payload type number established dynamically number, but uses a RTP payload type number established dynamically
and out-of-band. and out-of-band.
The payload type distinguishes between a (line) DTMF 0 tone and a
(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
non-RTP means.
3.4 Use of RTP Header Fields 3.4 Use of RTP Header Fields
Timestamp: The RTP timestamp reflects the measurement point for Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section the current packet. The event duration described in Section
3.5 extends forwards from that time. 3.5 extends forwards from that time. The receiver
calculates jitter for RTCP receiver reports based on all
packets with a given timestamp. Note: The jitter value
should primarily be used as a means for comparing the
reception quality between two users or two time-periods,
not as an absolute measure.
Marker bit: The RTP marker bit indicates the beginning of a new Marker bit: The RTP marker bit indicates the beginning of a new
event. event.
3.5 Payload Format 3.5 Payload Format
The payload format is shown in Fig. 1.
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 |E|R| volume | duration | | event |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Payload Format for Named Events
events: The events are encoded as shown in Sections 3.10 through events: The events are encoded as shown in Sections 3.10 through
3.14. 3.14.
volume: For DTMF digits, this field describes the power level of volume: For DTMF digits and other events representable as tones,
the tone, expressed in dBm0 after dropping the sign. Power this field describes the power level of the tone, expressed
levels range from 0 to -63 dBm0. The range of valid DTMF is in dBm0 after dropping the sign. Power levels range from 0
from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0
be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger (must accept); lower than -55 dBm0 must be rejected (TR-
values denote lower volume. This value is defined only for TSY-000181, ITU-T Q.24A). Thus, larger values denote lower
DTMF digits. For other events, it is set to zero by the volume. This value is defined only for DTMF digits. For
sender and is ignored by the receiver. 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 loudness variation is 3 dB, this field could be
compressed by at least a bit by reducing resolution to 2
dB, if needed.
duration: Duration of this digit, in timestamp units. Thus, the duration: Duration of this digit, in timestamp units. Thus, the
event 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 and has so far lasted as long as indicated by this
parameter. The event may or may not have ended. parameter. The event may or may not have ended.
For a sampling rate of 8000 Hz, this field is For a sampling rate of 8000 Hz, this field is
sufficient to express event durations of up to sufficient to express event durations of up to
approximately 8 seconds. approximately 8 seconds.
E: If set to a value of one, the "end" bit indicates that this E: If set to a value of one, the "end" bit indicates that this
packet contains the end of the event. Thus, the duration packet contains the end of the event. Thus, the duration
parameter above measures the complete duration of the parameter above measures the complete duration of the
event. event. A sender MAY set the end bit only when
retransmitting the last packet for a tone. This avoids
having to wait to detect whether the tone has indeed ended.
Receiver implementations can use at least two Receiver implementations MAY use at different algorithms to
different algorithms to create tones. In the first, create tones, including the two described here. In the
the receiver simply places a tone of the given first, the receiver simply places a tone of the given
duration in the audio playout buffer at the location duration in the audio playout buffer at the location
indicated by the timestamp. As additional packets are indicated by the timestamp. As additional packets are
received that extend the tone, the waveform in the received that extend the same tone, the waveform in the
playout buffer is adjusted accordingly. Thus, if a playout buffer is extended accordingly. (Care has to be
packet in a tone lasting longer than the packet taken if audio is mixed, i.e., summed, in the playout
interarrival time gets lost and the playout delay is buffer rather than simply copied.) Thus, if a packet in a
short, a gap in the tone may occur. Alternatively, the tone lasting longer than the packet interarrival time gets
receiver can start a tone and play it until it lost and the playout delay is short, a gap in the tone may
receives a packet with the "E" bit set or the next occur. Alternatively, the receiver can start a tone and
tone, distinguished by a different timestamp value. play it until it receives a packet with the "E" bit set,
This is more robust against packet loss, but may the next tone, distinguished by a different timestamp value
extend the tone if all retransmissions of the last or a given time period elapses. This is more robust against
packet in an event are lost. packet loss, but may extend the tone if all retransmissions
of the last packet in an event are lost. Limiting the time
period of extending the tone is necessary to avoid that a
tone "gets stuck". Regardless of the algorithm used, the
tone SHOULD NOT be extended by more than three packet
interarrival times. A slight extension of tone durations
and shortening of pauses is generally harmless.
R: This field is reserved for future use. The sender MUST set it R: This field is reserved for future use. The sender MUST set it
to zero, the receiver MUST ignore it. to zero, the receiver MUST ignore it.
3.6 Sending Event Packets 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. (The sender does
between event packets is not necessary.) not need to maintain precise time intervals between event packets in
order to maintain precise inter-event times, since the timing
information is contained in the timestamp.)
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 an event continues for more than one period, the source generating If an event continues for more than one period, the source generating
the events should send a new event packet with the RTP timestamp the events should send a new event packet with the RTP timestamp
value corresponding to the beginning of the event and the duration of value corresponding to the beginning of the event and the duration of
the event increased correspondingly. (The RTP sequence number is the event increased correspondingly. (The RTP sequence number is
incremented by one for each packet.) If there has been no new event incremented by one for each packet.) If there has been no new event
skipping to change at page 8, line 15 skipping to change at page 8, line 40
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 event 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 event 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 PSTN, care about both delays and event duration. into the PSTN, care about both delays and event duration.
3.7 Reliability 3.7 Reliability
During an event, the RTP event payload type provides incremental During an event, the RTP event payload format provides incremental
updates on the event. The error resiliency depends on the playout updates on the event. The error resiliency depends on the playout
delay at the receiver. For example, for a playout delay of 120 ms and delay at the receiver. For example, for a playout delay of 120 ms and
a packet gap of 50 ms, two packets in a row can get lost without a packet gap of 50 ms, two packets in a row can get lost without
causing a gap in the tones generated at the receiver. causing a gap in the tones generated at the receiver.
The audio redundancy mechanism described in RFC 2198 [6] MAY be used The audio redundancy mechanism described in RFC 2198 [6] MAY be used
to recover from packet loss across events. The effective data rate is 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 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 telephone-event payload) every 50 ms or r times 1280 bits/second,
the number of redundant events carried in each packet. The value of r where r is the number of redundant events carried in each packet. The
is an implementation trade-off, with a value of 5 suggested. 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 telephone events at a sampling rate of 8000 Hz. of telephone events at a sampling rate of 8000 Hz.
Including the starting time of previous events allows Including the starting time of previous events allows
precise reconstruction of the tone sequence at a gateway. precise reconstruction of the tone sequence at a gateway.
The scheme is resilient to consecutive packet losses The scheme is resilient to consecutive packet losses
spanning this interval of 2.048 seconds or r digits, spanning this interval of 2.048 seconds or r digits,
whichever is less. Note that for previous digits, only an whichever is less. Note that for previous digits, only an
average 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 an
DTMF tone would contain the current audio codec rendition (say, even would contain the current audio codec rendition (say, G.723.1 or
G.723.1 or G.729) of this digit as well as the representation G.729) of this digit as well as the representation described in
described in Section 3.5, plus any previous digits as before. Section 3.5, plus any previous events seen earlier.
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.
3.8 Example 3.8 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
skipping to change at page 10, line 4 skipping to change at page 10, line 28
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.9 Indication of Receiver Capabilities using SDP 3.9 Indication of Receiver Capabilities using SDP
Receivers MAY indicate which named events they can handle, for Receivers MAY indicate which named events they can handle, for
example, by using the Session Description Protocol (RFC 2327 [4]). example, by using the Session Description Protocol (RFC 2327 [7]).
The payload types use the following fmtp format to list the event The payload formats use the following fmtp format to list the event
values that they can receive: values that they can receive:
a=fmtp:<format> <list of values> a=fmtp:<format> <list of values>
The list of values consists of comma-separated elements, which can be The list of values consists of comma-separated elements, which can be
either a single decimal number or two decimal numbers separated by a either a single decimal number or two decimal numbers separated by a
hyphen (dash), where the second number is larger than the first. No hyphen (dash), where the second number is larger than the first. No
whitespace is allowed between numbers or hyphens. The list does not whitespace is allowed between numbers or hyphens. The list does not
have to be sorted. have to be sorted.
For example, if the data "codec" (Section 3.11) has been assigned the For example, if the payload format uses the payload type number 100,
payload type number 100 and the implementation can handle the common and the implementation can handle the common DTMF tones (events 0
DTMF tones as well as dial and PBX dial tones. through 11) and the dial and ringing tones, it would include the
following description in its SDP message:
a=fmtp:100 0-11,66,67 a=fmtp:100 0-11,66,70
The corresponding MIME parameter is "events", so that the following The corresponding MIME parameter is "events", so that the following
sample media type definition corresponds to the SDP example above: sample media type definition corresponds to the SDP example above:
audio/telephony-events;events="0-11,66,67" audio/telephone-event;events="0-11,66,67";rate="8000"
3.10 DTMF Events 3.10 DTMF Events
Tables 1 summarizes the events belonging to the DTMF payload type. 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
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 [8,9]. For fax machines,
Recommendation T.30 [9] refers to this tone as called
terminal identification (CED) answer tone.
/ANS: This is the same signal as ANS, except that it reverses /ANS: This is the same signal as ANS, except that it reverses
phase at an interval of 450 +/- 25 ms. It disables both phase at an interval of 450 +/- 25 ms. It disables both
echo cancellers and echo suppressors. (In the ITU echo cancellers and echo suppressors. (In the ITU
Recommendation, this signal is rendered as ANS with a bar Recommendation, this signal is rendered as ANS with a bar
on top.) on top.)
ANSam: The modified answer tone (ANSam) [2] is a sinewave signal ANSam: The modified answer tone (ANSam) [3] is a sinewave signal
at 2100 +/- 1 Hz with phase reversals at an interval of 450 at 2100 +/- 1 Hz with phase reversals at an interval of 450
+/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1
Hz. This tone [9,7] is sent by modems [10] and faxes to Hz. This tone [10,8] is sent by modems [11] and faxes to
disable echo suppressors. disable echo suppressors.
/ANSam: This is the same signal as ANSam, except that it /ANSam: This is the same signal as ANSam, except that it
reverses phase at an interval of 450 +/- 25 ms. It disables reverses phase at an interval of 450 +/- 25 ms. It disables
both echo cancellers and echo suppressors. (In the ITU both echo cancellers and echo suppressors. (In the ITU
Recommendation, this signal is rendered as ANSam with a bar Recommendation, this signal is rendered as ANSam with a bar
on top.) on top.)
CNG: After dialing the called fax machine's telephone number CNG: After dialing the called fax machine's telephone number
(and before it answers), the calling Group III fax machine (and before it answers), the calling Group III fax machine
(optionally) begins sending a CalliNG tone (CNG) consisting (optionally) begins sending a CalliNG tone (CNG) consisting
of an interrupted tone of 1100 Hz. [8] of an interrupted tone of 1100 Hz. [9]
CRd: Capabilities Request (CRd) [11] is a dual-tone signal with CRd: Capabilities Request (CRd) [12] is a dual-tone signal with
tones at tones at 1375 Hz and 2002 Hz for 400 ms for the tones at tones at 1375 Hz and 2002 Hz for 400 ms for the
initiating side and 1529 Hz and 2225 Hz for the responding initiating side and 1529 Hz and 2225 Hz for the responding
side, followed by a single tone at 1900 Hz for 100 ms. side, followed by a single tone at 1900 Hz for 100 ms.
"This signal requests the remote station transition from "This signal requests the remote station transition from
telephony mode to an information transfer mode and requests telephony mode to an information transfer mode and requests
the transmission of a capabilities list message by the the transmission of a capabilities list message by the
remote station. In particular, CRd is sent by the remote station. In particular, CRd is sent by the
initiating station during the course of a call, or by the initiating station during the course of a call, or by the
calling station at call establishment in response to a CRe calling station at call establishment in response to a CRe
or MRe." or MRe."
CRe: Capabilities Request (CRe) [11] is a dual-tone signal with CRe: Capabilities Request (CRe) [12] is a dual-tone signal with
tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed
by a single tone at 400 Hz for 100 ms. "This signal by a single tone at 400 Hz for 100 ms. "This signal
requests the remote station transition from telephony mode requests the remote station transition from telephony mode
to an information transfer mode and requests the to an information transfer mode and requests the
transmission of a capabilities list message by the remote transmission of a capabilities list message by the remote
station. In particular, CRe is sent by an automatic station. In particular, CRe is sent by an automatic
answering station at call establishment." answering station at call establishment."
ESi: Escape Signal (ESi) [11] is a dual-tone signal with tones ESi: Escape Signal (ESi) [12] is a dual-tone signal with 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 980 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. signal ESi is sent by the initiating transfer mode. signal ESi is sent by the initiating
station." station."
ESr: Escape Signal (ESr) [11] is a dual-tone signal with tones ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones
at 1529 Hz and 2225 Hz for 400 ms, followed by a single at 1529 Hz and 2225 Hz for 400 ms, followed by a single
tone at 1650 Hz for 100 ms. Same as ESi, but sent by the tone at 1650 Hz for 100 ms. Same as ESi, but sent by the
responding station. responding station.
MRd: Mode Request (MRd) [11] is a dual-tone signals with tones MRd: Mode Request (MRd) [12] is a dual-tone signals with tones
at 1375 Hz and 2002 Hz for 400 ms for the initiating side at 1375 Hz and 2002 Hz for 400 ms for the initiating side
and 1529 Hz and 2225 Hz for the responding side, followed and 1529 Hz and 2225 Hz for the responding side, followed
by a single tone at 1150 Hz for 100 ms. "This signal by a single tone at 1150 Hz for 100 ms. "This signal
requests the remote station transition from telephony mode requests the remote station transition from telephony mode
to an information transfer mode and requests the to an information transfer mode and requests the
transmission of a mode select message by the remote transmission of a mode select message by the remote
station. In particular, signal MRd is sent by the station. In particular, signal MRd is sent by the
initiating station during the course of a call, or by the initiating station during the course of a call, or by the
calling station at call establishment in response to an calling station at call establishment in response to an
MRe." [11] MRe." [12]
MRe: Mode Request (MRe) [11] is a dual-tone signal with tones at MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at
1375 Hz and 2002 Hz for 400 ms, followed by a single tone 1375 Hz and 2002 Hz for 400 ms, followed by a single tone
at 650 Hz for 100 ms. "This signal requests the remote at 650 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 transfer mode and requests the transmission of a mode
select message by the remote station. In particular, signal select message by the remote station. In particular, signal
MRe is sent by an automatic answering station at call MRe is sent by an automatic answering station at call
establishment." [11] establishment." [12]
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 machines to exchange T.30 information. The calling
transmits on channel 1 and receives on channel 2; the transmits on channel 1 and receives on channel 2; the
answering modem transmits on channel 2 and receives on answering modem transmits on channel 2 and receives on
channel 1. Each bit value has a distinct tone, so that V.21 channel 1. Each bit value has a distinct tone, so that V.21
signaling comprises a total of 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) 3.12 Line Events
Table 4 summarizes the events and tones that can appear on a
subscriber line.
Event encoding (decimal)
___________________________________________
Answer tone (ANS) 32 Answer tone (ANS) 32
/ANS 33 /ANS 33
ANSam 34 ANSam 34
/ANSam 35 /ANSam 35
Calling tone (CNG) 36 Calling tone (CNG) 36
V.21 channel 1, "0" bit 37 V.21 channel 1, "0" bit 37
V.21 channel 1, "1" bit 38 V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39 V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40 V.21 channel 2, "1" bit 40
CRd 41 CRd 41
CRe 42 CRe 42
ESi 43 ESi 43
ESr 44 ESr 44
MRd 45 MRd 45
MRe 46 MRe 46
Table 3: Data and fax events Table 3: Data and fax events
3.12 Line Events ITU Recommendation E.182 [13] defines when certain tones should be
Table 4 summarizes the events and tones that can appear on a
subscriber line.
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 subject to a specific condition, such as call diversion or
skipping to change at page 15, line 37 skipping to change at page 16, line 15
duration of 80 to 80 ms. CAS is used with ADSI services and duration of 80 to 80 ms. CAS is used with ADSI services and
Call Waiting ID services, see Bellcore GR-30-CORE, Issue 2, Call Waiting ID services, see Bellcore GR-30-CORE, Issue 2,
December 1998, 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 Payphone recognition tone: The person making the call or being
called is using a payphone (and thus it is ill-advised to called is using a payphone (and thus it is ill-advised to
allow collect calls to such a person). allow collect calls to such a person).
3.13 Extended Line Events
Table 5 summarizes country-specific events and tones that can appear
on a subscriber line.
3.14 Trunk Events
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 64 Off Hook 64
On Hook 65 On Hook 65
Dial tone 66 Dial tone 66
PABX internal dial tone 67 PABX internal dial tone 67
Special dial tone 68 Special dial tone 68
Second dial tone 69 Second dial tone 69
Ringing tone 70 Ringing tone 70
Special ringing tone 71 Special ringing tone 71
skipping to change at page 16, line 34 skipping to change at page 16, line 45
Negative indication tone 82 Negative indication tone 82
Warning tone 83 Warning tone 83
Intrusion tone 84 Intrusion tone 84
Calling card service tone 85 Calling card service tone 85
Payphone recognition tone 86 Payphone recognition tone 86
CPE alerting signal (CAS) 87 CPE alerting signal (CAS) 87
Off-hook warning tone 88 Off-hook warning tone 88
Table 4: E.182 line events Table 4: E.182 line events
ABCD transitional: 4-bit signaling used by digital trunks. For 3.13 Extended Line Events
N-state signaling, the first N values are used.
The T1 ESF (extended super frame format) allows 2, 4, and Table 5 summarizes country-specific events and tones that can appear
16 state signalling bit options. These signalling bits are on a subscriber line.
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) Event encoding (decimal)
___________________________________________________ ___________________________________________________
Acceptance tone 96 Acceptance tone 96
Confirmation tone 97 Confirmation tone 97
Dial tone, recall 98 Dial tone, recall 98
End of three party service tone 99 End of three party service tone 99
Facilities tone 100 Facilities tone 100
Line lockout tone 101 Line lockout tone 101
Number unobtainable tone 102 Number unobtainable tone 102
Offering tone 103 Offering tone 103
skipping to change at page 17, line 26 skipping to change at page 17, line 27
Queue tone 106 Queue tone 106
Refusal tone 107 Refusal tone 107
Route tone 108 Route tone 108
Valid tone 109 Valid tone 109
Waiting tone 110 Waiting tone 110
Warning tone (end of period) 111 Warning tone (end of period) 111
Warning Tone (PIP tone) 112 Warning Tone (PIP tone) 112
Table 5: Country-specific Line events Table 5: Country-specific Line events
the same ABCD information is sent 3 times at an interval of 3.14 Trunk Events
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
(unseized) to off-hook (seized) and back to onhook, used by
the incoming exchange to signal that the call address
signaling can proceed.
Incoming seizure: Incoming indication of call attempt (off- Table 6 summarizes the events and tones that can appear on a trunk.
hook). Note that trunk can also carry line events (Section 3.12), as MF
signaling does not include backward signals [14].
Return seizure: Seizure by answering exchange, in response to [NOTE: the list below, below wink, does not agree with the MF
outgoing seizure. [NOTE: Not clear why the difference here, description in van Bosse, p. 74.]
but not for Unseize. Should probably be just Seizure.]
Unseize circuit: Transition of circuit from off-hook to on-hook ABCD transitional: 4-bit signaling used by digital trunks. For
at the end of a call. N-state signaling, the first N values are used.
Wink off: A brief transition, typically 100-350 ms, from off- The T1 ESF (extended super frame format) allows 2, 4, and
hook (seized) to on-hook (unseized) and back to off-hook 16 state signalling bit options. These signalling bits are
(seized). Used in operator services trunks. 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-
Event encoding (decimal) Event encoding (decimal)
__________________________________________________ __________________________________________________
MF 0... 9 128... 137 MF 0... 9 128... 137
MF K0 or KP (start-of-pulsing) 138 MF K0 or KP (start-of-pulsing) 138
MF K1 139 MF K1 139
MF K2 140 MF K2 140
MF S0 to ST (end-of-pulsing) 141 MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142... 143 MF S1... S3 142... 143
ABCD signaling (see below) 144... 159 ABCD signaling (see below) 144... 159
Wink 160 Wink 160
skipping to change at page 18, line 30 skipping to change at page 18, line 29
Default continuity tone 166 Default continuity tone 166
Continuity tone (single tone) 167 Continuity tone (single tone) 167
Continuity test send 168 Continuity test send 168
Continuity verified 170 Continuity verified 170
Loopback 171 Loopback 171
Old milliwatt tone (1000 Hz) 172 Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173 New milliwatt tone (1004 Hz) 173
Table 6: Trunk events Table 6: Trunk events
redundancy mechanism, similar to the one specified in ITU-T
Rec. I.366.2 [15], Annex L. At the time of a transition,
the same ABCD information is sent 3 times at an interval of
5 ms. If another transition occurs during this time, then
this continues. After a period of no change, the ABCD
information is sent every 5 seconds.
Wink: A brief transition, typically 120-290 ms, from on-hook
(unseized) to off-hook (seized) and back to onhook, used by
the incoming exchange to signal that the call address
signaling can proceed.
Incoming seizure: Incoming indication of call attempt (off-
hook).
Return seizure: Seizure by answering exchange, in response to
outgoing seizure. [NOTE: Not clear why the difference here,
but not for Unseize. Should probably be just Seizure.]
Unseize circuit: Transition of circuit from off-hook to on-hook
at the end of a call.
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.
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, Continuity verified: A tone of 2010 Hz. This is a response tone,
used in dual-tone procedures. used in dual-tone procedures.
skipping to change at page 19, line 9 skipping to change at page 19, line 34
As an alternative to describing tones and events by name, as As an alternative to describing tones and events by name, as
described in Section 3, it is sometimes preferable to describe them described in Section 3, it is sometimes preferable to describe them
by their waveform properties. In particular, recognition is faster by their waveform properties. In particular, recognition is faster
than for naming signals since it does not depend on recognizing than for naming signals since it does not depend on recognizing
durations or pauses. 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 [15]: all countries, these tones share a number of characteristics [16]:
o Tones consist of either a single tone, the addition of two or o Telephony tones consist of either a single tone, the addition
three tones or the modulation of two tones. (Almost all tones of two or three tones or the modulation of two tones. (Almost
use two frequencies; only the Hungarian "special dial tone" all tones use two frequencies; only the Hungarian "special
has three.) Tones that are mixed have the same amplitude and dial tone" has three.) Tones that are mixed have the same
do not decay. amplitude and 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 [16] notes that different telephone o ITU Recommendation E.180 [17] notes that different telephone
companies proscribe a tone accuracy of between 0.5 and 1.5%. companies require 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 [16]. Note that there are no specific guidelines Recommendation E.180 [17]. 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. The meaning of some of the tones is described in Section modulation. The meaning of some of the tones is described in Section
3.12 or Section 3.11 (for V.21). 3.12 or Section 3.11 (for V.21).
4.3 Use of RTP Header Fields
Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section
3.5 extends forwards [NOTE: was "backwards", but that's
different from all other payloads and disagrees with RFC
1889] from that time.
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
V.21_"1"_bit,_ch._2________1650______0.033____________ V.21_"1"_bit,_ch._2________1650______0.033____________
skipping to change at page 20, line 28 skipping to change at page 20, line 43
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.3 Use of RTP Header Fields
Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section
3.5 extends forwards from that time.
4.4 Payload Format 4.4 Payload Format
Based on the characteristics described above, this document defines Based on the characteristics described above, this document defines
an RTP payload format called "tone". (The corresponding MIME type is an RTP payload format called "tone" that can represent tones
"audio/telephone-event".) The default timestamp rate is 8,000 Hz, but consisting of one or more frequencies. (The corresponding MIME type
other rates may be defined. Note that the timestamp rate does not is "audio/tone".) The default timestamp rate is 8,000 Hz, but other
affect the interpretation of the frequency, just the durations. 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 In accordance with current practice, this payload format does not
a static payload type number, but uses a RTP payload type number have a static payload type number, but uses a RTP payload type number
established dynamically and out-of-band. established dynamically and out-of-band.
It is shown in Fig. 1. It is shown in Fig. 2.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Payload format for tones
The payload contains the following fields:
modulation: The modulation frequency, in Hz. The field is a 9- modulation: The modulation frequency, in Hz. The field is a 9-
bit unsigned integer, allowing modulation frequencies up to bit unsigned integer, allowing modulation frequencies up to
511 Hz. If there is no modulation, this field has a value 511 Hz. If there is no modulation, this field has a value
of zero. of zero.
T: If the "T" bit is set (one), the modulation frequency is to T: If the "T" bit is set (one), the modulation frequency is to
be divided by three. Otherwise, the modulation frequency is be divided by three. Otherwise, the modulation frequency is
taken as is. taken as is.
volume: The power level of the digit, expressed in dBm0 after This bit allows frequencies accurate to 1/3 Hz, since
modulation frequencies such as 16 2/3 Hz are in
practical use.
volume: The power level of the tone, 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 preferred level range for digital tone generators is -8
dBm0 to -3 dBm0.) dBm0 to -3 dBm0.)
duration: The duration of the tone, measured in timestamp units. duration: The duration of the tone, measured in timestamp units.
The tone begins at the instant identified by the RTP The tone begins at the instant identified by the RTP
timestamp and lasts for the duration value. timestamp and lasts for the duration value.
The definition of duration corresponds to that for The definition of duration corresponds to that for
sample-based codecs, where the timestamp represents sample-based codecs, where the timestamp represents
the sampling point for the first sample. the sampling point for the first sample.
frequency: The frequencies of the tones to be added, measured in frequency: The frequencies of the tones to be added, measured in
Hz and represented as a 12-bit unsigned integer. The field Hz and represented as a 12-bit unsigned integer. The field
size is sufficient to represent frequencies up to 4095 Hz, size is sufficient to represent frequencies up to 4095 Hz,
which exceeds the range of telephone systems. A value of which exceeds the range of telephone systems. A value of
zero indicates silence. zero indicates silence. A single tone can contain any
number of frequencies.
R: This field is reserved for future use. The sender MUST set it R: This field is reserved for future use. The sender MUST set it
to zero, the receiver MUST ignore it. to zero, the receiver MUST ignore it.
4.5 Reliability 4.5 Reliability
This payload type uses the reliability mechanism described in Section
3.7. This payload format uses the reliability mechanism described in
Section 3.7.
5 Combining Tones and Named Events 5 Combining Tones and Named Events
The payload formats in Sections 3 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 using the method specified in RFC 2198. Fig. 3 shows an
the RTP packet combines two "tone" and one "telephone-event" payload. example. In that example, the RTP packet combines two "tone" and one
The payload types are chosen arbitrarily as 97 and 98, respectively, "telephone-event" payload. The payload types are chosen arbitrarily
with a sample rate of 8000 Hz. Here, the redundancy format has the as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the
dynamic payload type 96. redundancy format has the 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 named 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 |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 |
| 0x5234a8 | | 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length | |F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 | |1| 98 | 16383 | 4 |
skipping to change at page 23, line 40 skipping to change at page 23, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 3: Combining tones and events in a single RTP packet
6 MIME Registration
6.1 audio/telephone-event
MIME media type name: audio
MIME subtype name: telephone-event
Required parameters: none.
Optional parameters: The "events" parameter lists the events
supported by the implementation. Events are listed as one
or more comma-separated elements. Each element can either
be a single integer or two integers separated by a hyphen.
No white space is allowed in the argument. The integers
designate the event numbers supported by the
implementation.
The "rate" parameter describes the sampling rate, in Hertz.
The number is written as a floating point number or as an
integer. If omitted, the default value is 8000 Hz.
Encoding considerations: This type is only defined for transfer
via RTP [1].
Security considerations: See the "Security Considerations"
(Section 7) section in this document.
Interoperability considerations: none
Published specification: This document.
Applications which use this media: The telephone-event audio
subtype supports the transport of events occuring in
telephone systems over the Internet.
Additional information:
1. Magic number(s): N/A
2. File extension(s): N/A
3. Macintosh file type code: N/A
6.2 audio/tone
MIME media type name: audio
MIME subtype name: tone
Required parameters: none
Optional parameters: The "rate" parameter describes the sampling
rate, in Hertz. The number is written as a floating point
number or as an integer. If omitted, the default value is
8000 Hz.
Encoding considerations: This type is only defined for transfer
via RTP [1].
Security considerations: See the "Security Considerations"
(Section 7) section in this document.
Interoperability considerations: none
Published specification: This document.
Applications which use this media: The tone audio subtype
supports the transport of pure composite tones, for example
those commonly used in the current telephone system to
signal call progress.
Additional information:
1. Magic number(s): N/A
2. File extension(s): N/A
3. Macintosh file type code: N/A
7 Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification (RFC 1889 [1]), and any appropriate RTP profile (for
example RFC 1890 [18]).This implies that confidentiality of the media
streams is achieved by encryption. Because the data compression used
with this payload format is applied end-to-end, encryption may be
performed after compression so there is no conflict between the two
operations.
This payload type does not exhibit any significant non-uniformity in
the receiver side computational complexity for packet processing to
cause a potential denial-of-service threat.
8 IANA Considerations
This document defines two new RTP payload formats, 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. Registrations are subject to approval by the
current chair of the IETF audio/video transport working group, or by
an expert designated by the transport area director if the AVT group
has closed.
The meaning of new events MUST be documented either as an RFC or an
equivalent standards document produced by another standardization
body, such as ITU-T.
9 Acknowledgements
The suggestions of the Megaco working group are gratefully
acknowledged. Detailed advice and comments were provided by Fred
Burg, Steve Casner, Fatih Erdin, Mike Fox, Terry Lyons, Colin Perkins
and Steve Magnell.
10 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
45 Rumford Avenue 45 Rumford Avenue
Waltham, MA 02453 Waltham, MA 02453
USA USA
electronic mail: scott.petrack@metatel.com electronic mail: scott.petrack@metatel.com
9 Bibliography 11 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] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, Mar. 1997.
[3] 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.
[3] R. Kocen and T. Hatala, "Voice over frame relay implementation [4] R. Kocen and T. Hatala, "Voice over frame relay implementation
agreement," Implementation Agreement FRF.11, Frame Relay Forum, agreement," Implementation Agreement FRF.11, Frame Relay Forum,
Foster City, California, Jan. 1997. Foster City, California, Jan. 1997.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments (Proposed Standard) 2327, Internet Engineering
Task Force, Apr. 1998.
[5] International Telecommunication Union, "Multifrequency push- [5] International Telecommunication Union, "Multifrequency push-
button signal reception," Recommendation Q.24, Telecommunication button signal reception," Recommendation Q.24, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 1988. Standardization Sector of ITU, Geneva, Switzerland, 1988.
[6] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. C. [6] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. C.
Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP payload for Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP payload for
redundant audio data," Request for Comments (Proposed Standard) 2198, redundant audio data," Request for Comments (Proposed Standard) 2198,
Internet Engineering Task Force, Sept. 1997. Internet Engineering Task Force, Sept. 1997.
[7] International Telecommunication Union, "Automatic answering [7] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments (Proposed Standard) 2327, Internet Engineering
Task Force, Apr. 1998.
[8] International Telecommunication Union, "Automatic answering
equipment and general procedures for automatic calling equipment on equipment and general procedures for automatic calling equipment on
the general switched telephone network including procedures for the general switched telephone network including procedures for
disabling of echo control devices for both manually and automatically disabling of echo control devices for both manually and automatically
established calls," Recommendation V.25, Telecommunication established calls," Recommendation V.25, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996. Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996.
[8] International Telecommunication Union, "Procedures for document [9] International Telecommunication Union, "Procedures for document
facsimile transmission in the general switched telephone network," facsimile transmission in the general switched telephone network,"
Recommendation T.30, Telecommunication Standardization Sector of ITU, Recommendation T.30, Telecommunication Standardization Sector of ITU,
Geneva, Switzerland, July 1996. Geneva, Switzerland, July 1996.
[9] International Telecommunication Union, "Echo cancellers," [10] International Telecommunication Union, "Echo cancellers,"
Recommendation G.165, Telecommunication Standardization Sector of Recommendation G.165, Telecommunication Standardization Sector of
ITU, Geneva, Switzerland, Mar. 1993. ITU, Geneva, Switzerland, Mar. 1993.
[10] International Telecommunication Union, "A modem operating at [11] International Telecommunication Union, "A modem operating at
data signalling rates of up to 33 600 bit/s for use on the general data signalling rates of up to 33 600 bit/s for use on the general
switched telephone network and on leased point-to-point 2-wire switched telephone network and on leased point-to-point 2-wire
telephone-type circuits," Recommendation V.34, Telecommunication telephone-type circuits," Recommendation V.34, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[11] International Telecommunication Union, "Procedures for the [12] International Telecommunication Union, "Procedures for the
identification and selection of common modes of operation between identification and selection of common modes of operation between
data circuit-terminating equipments (dces) and between data terminal data circuit-terminating equipments (dces) and between data terminal
equipments (dtes) over the public switched telephone network and on equipments (dtes) over the public switched telephone network and on
leased point-to-point telephone-type circuits," Recommendation leased point-to-point telephone-type circuits," Recommendation
V.8bis, Telecommunication Standardization Sector of ITU, Geneva, V.8bis, Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Sept. 1998. Switzerland, Sept. 1998.
[12] International Telecommunication Union, "Application of tones and [13] 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 [14] 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, "AAL type 2 service [15] International Telecommunication Union, "AAL type 2 service
specific convergence sublayer for trunking," Recommendation I.366.2, specific convergence sublayer for trunking," Recommendation I.366.2,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
Feb. 1999. Feb. 1999.
[15] International Telecommunication Union, "Various tones used in [16] 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.
[16] International Telecommunication Union, "Technical [17] 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.
[18] H. Schulzrinne, "RTP profile for audio and video conferences
with minimal control," Request for Comments (Proposed Standard) 1890,
Internet Engineering Task Force, Jan. 1996.
 End of changes. 

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