draft-ietf-avt-tones-06.txt   rfc2833.txt 
Internet Engineering Task Force AVT WG
Internet Draft Schulzrinne/Petrack
draft-ietf-avt-tones-06.txt Columbia U./MetaTel
January 14, 2000
Expires: May 2000
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Network Working Group H. Schulzrinne
Request for Comments: 2833 Columbia University
STATUS OF THIS MEMO Category: Standards Track S. Petrack
MetaTel
May 2000
This document is an Internet-Draft and is in full conformance with RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress". Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
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 formats, one for carrying dual-tone This memo defines two payload formats, one for carrying dual-tone
multifrequency (DTMF) digits, other line and trunk signals (Section multifrequency (DTMF) digits, other line and trunk signals (Section
3), and a second one for general multi-frequency tones in RTP [1] 3), and a second one for general multi-frequency tones in RTP [1]
packets (Section 4). Separate RTP payload formats are desirable since packets (Section 4). Separate RTP payload formats are desirable since
low-rate voice codecs cannot be guaranteed to reproduce these tone low-rate voice codecs cannot be guaranteed to reproduce these tone
signals accurately enough for automatic recognition. Defining signals accurately enough for automatic recognition. Defining
separate payload formats also permits higher redundancy while separate payload formats also permits higher redundancy while
maintaining a low bit rate. maintaining a low bit rate.
The payload formats 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 systems, 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
without concerning itself with generating precise tone pairs and without concerning itself with generating precise tone pairs and
skipping to change at page 3, line 44 skipping to change at page 3, line 39
the callee's phone rings. (This reduces the chance of clipping the the callee's phone rings. (This reduces the chance of clipping 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 a ringing tone.) Congestion tone and caller before or in lieu of a 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 MAY send both named Gateways which send signaling 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. It is generally a good 3.7 to interleave the two representations. It is generally a good
idea to send both, since it allows the receiver to choose the idea to send both, since it allows the receiver to choose the
appropriate rendering. 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 format 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.
skipping to change at page 5, line 22 skipping to change at page 5, line 20
to handle the overlap. It is RECOMMENDED that gateways only render to handle the overlap. It is RECOMMENDED that gateways only render
the encoded tone since the audio may contain spurious tones the encoded tone since the audio may contain spurious tones
introduced by the audio compression algorithm. However, it is introduced by the audio compression algorithm. However, it is
anticipated that these extra tones in general should not interfere anticipated that these extra tones in general should not interfere
with recognition at the far end. with recognition at the far end.
3.3 Event Types 3.3 Event Types
This payload format 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 country-specific subscriber line tones (Section 3.13) and; o country-specific subscriber line tones (Section 3.13) and;
o trunk events (Section 3.14). o trunk events (Section 3.14).
A compliant implementation MUST support the events listed in Table 1 A compliant implementation MUST support the events listed in Table 1
with the exception of "flash". If it uses some other, out-of-band with the exception of "flash". If it uses some other, out-of-band
mechanism for signaling line conditions, it does not have to mechanism for signaling line conditions, it does not have to
implement the other events. 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. Section 3.9 specifies how an implementation can use the environment. Section 3.9 specifies how an implementation can use the
SDP "fmtp" parameter within an SDP description to indicate its SDP "fmtp" parameter within an SDP description to indicate its
skipping to change at page 6, line 16 skipping to change at page 6, line 14
The RTP payload format 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 8000 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 format 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.
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. The receiver 3.5 extends forwards from that time. The receiver calculates
calculates jitter for RTCP receiver reports based on all jitter for RTCP receiver reports based on all packets with a
packets with a given timestamp. Note: The jitter value given timestamp. Note: The jitter value should primarily be
should primarily be used as a means for comparing the used as a means for comparing the reception quality between
reception quality between two users or two time-periods, two users or two time-periods, not as an absolute measure.
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. 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 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 and other events representable as tones, volume: For DTMF digits and other events representable as tones,
this field describes the power level of the tone, expressed this field describes the power level of the tone, expressed
in dBm0 after dropping the sign. Power levels range from 0 in dBm0 after dropping the sign. Power levels range from 0 to
to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must
(must accept); lower than -55 dBm0 must be rejected (TR- accept); lower than -55 dBm0 must be rejected (TR-TSY-000181,
TSY-000181, ITU-T Q.24A). Thus, larger values denote lower ITU-T Q.24A). Thus, larger values denote lower volume. This
volume. This value is defined only for DTMF digits. For value is defined only for DTMF digits. For other events, it
other events, it is set to zero by the sender and is is set to zero by the sender and is ignored by the receiver.
ignored by the receiver.
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.
parameter. The event may or may not have ended. 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
sufficient to express event durations of up 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 delay setting the end bit until retransmitting A sender MAY delay setting the end bit until retransmitting
the last packet for a tone, rather than on its first the last packet for a tone, rather than on its first
transmission. This avoids having to wait to detect whether transmission. This avoids having to wait to detect whether
the tone has indeed ended. the tone has indeed ended.
Receiver implementations MAY use different algorithms to Receiver implementations MAY use different algorithms to
create tones, including the two described here. In the create tones, including the two described here. In the first,
first, the receiver simply places a tone of the given the receiver simply places a tone of the given duration in
duration in the audio playout buffer at the location the audio playout buffer at the location indicated by the
indicated by the timestamp. As additional packets are timestamp. As additional packets are received that extend the
received that extend the same tone, the waveform in the same tone, the waveform in the playout buffer is extended
playout buffer is extended accordingly. (Care has to be accordingly. (Care has to be taken if audio is mixed, i.e.,
taken if audio is mixed, i.e., summed, in the playout summed, in the playout buffer rather than simply copied.)
buffer rather than simply copied.) Thus, if a packet in a Thus, if a packet in a tone lasting longer than the packet
tone lasting longer than the packet interarrival time gets interarrival time gets lost and the playout delay is short, a
lost and the playout delay is short, a gap in the tone may gap in the tone may occur. Alternatively, the receiver can
occur. Alternatively, the receiver can start a tone and start a tone and play it until it receives a packet with the
play it until it receives a packet with the "E" bit set, "E" bit set, the next tone, distinguished by a different
the next tone, distinguished by a different timestamp value timestamp value or a given time period elapses. This is more
or a given time period elapses. This is more robust against robust against packet loss, but may extend the tone if all
packet loss, but may extend the tone if all retransmissions retransmissions of the last packet in an event are lost.
of the last packet in an event are lost. Limiting the time Limiting the time period of extending the tone is necessary
period of extending the tone is necessary to avoid that a to avoid that a tone "gets stuck". Regardless of the
tone "gets stuck". Regardless of the algorithm used, the algorithm used, the tone SHOULD NOT be extended by more than
tone SHOULD NOT be extended by more than three packet three packet interarrival times. A slight extension of tone
interarrival times. A slight extension of tone durations durations and shortening of pauses is generally harmless.
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. (The sender does for the audio codec used for this session, if known. (The sender does
not need to maintain precise time intervals between event packets in not need to maintain precise time intervals between event packets in
order to maintain precise inter-event times, since the timing order to maintain precise inter-event times, since the timing
information is contained in the timestamp.) 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
surveyed use a minimum signal duration of 40 ms, with use a minimum signal duration of 40 ms, with signaling velocity
signaling velocity (tone and pause) of no less than 93 ms. (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
in the last interval, the event SHOULD be retransmitted three times in the last interval, the event SHOULD be retransmitted three times
or until the next event is recognized. This ensures that the duration or until the next event is recognized. This ensures that the duration
of the event can be recognized correctly even if the last packet for of the event can be recognized correctly even if the last packet for
an event is lost. an event is lost.
DTMF digits and events are sent incrementally to avoid DTMF digits and events are sent incrementally to avoid having the
having the receiver wait for the completion of the event. receiver wait for the completion of the event. Since some tones
Since some tones are two seconds long, this would incur a are two seconds long, this would incur a substantial delay. The
substantial delay. The transmitter does not know if event transmitter does not know if event length is important and thus
length is important and thus needs to transmit immediately needs to transmit immediately and incrementally. If the receiver
and incrementally. If the receiver application does not application does not care about event length, the incremental
care about event length, the incremental transmission transmission mechanism avoids delay. Some applications, such as
mechanism avoids delay. Some applications, such as gateways 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 format 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 telephone-event payload) every 50 ms or r times 1280 bits/second, the telephone-event payload) every 50 ms or r times 1280 bits/second,
where r is the number of redundant events carried in each packet. The 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 value of r is an implementation trade-off, with a value of 5
suggested. suggested.
The timestamp offset in this redundancy scheme has 14 bits, The timestamp offset in this redundancy scheme has 14 bits, so
so that it allows a single packet to "cover" 2.048 seconds that it allows a single packet to "cover" 2.048 seconds of
of telephone events at a sampling rate of 8000 Hz. telephone events at a sampling rate of 8000 Hz. Including the
Including the starting time of previous events allows starting time of previous events allows precise reconstruction of
precise reconstruction of the tone sequence at a gateway. the tone sequence at a gateway. The scheme is resilient to
The scheme is resilient to consecutive packet losses consecutive packet losses spanning this interval of 2.048 seconds
spanning this interval of 2.048 seconds or r digits, or r digits, whichever is less. Note that for previous digits,
whichever is less. Note that for previous digits, only an 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 an of the current audio frame. In that mode, each RTP packet during an
event would contain the current audio codec rendition (say, G.723.1 event would contain the current audio codec rendition (say, G.723.1
or G.729) of this digit as well as the representation described in or G.729) of this digit as well as the representation described in
Section 3.5, plus any previous events seen earlier. 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
this format to function. See also the discussion in Section 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
assigned for the redundancy mechanism and the telephone event assigned for the redundancy mechanism and the telephone event
payload, respectively. payload, respectively.
3.9 Indication of Receiver Capabilities using SDP 3.9 Indication of Receiver Capabilities using SDP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example RTP packet after dialing "911" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example RTP packet after dialing "911"
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 [7]). example, by using the Session Description Protocol (RFC 2327 [7]).
The payload formats 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
skipping to change at page 11, line 26 skipping to change at page 11, line 22
Since all implementations MUST be able to receive events 0 through Since all implementations MUST be able to receive events 0 through
15, listing these events in the a=fmtp line is OPTIONAL. 15, listing these events in the a=fmtp line is OPTIONAL.
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/telephone-event;events="0-11,66,67";rate="8000" audio/telephone-event;events="0-11,66,67";rate="8000"
3.10 DTMF Events 3.10 DTMF Events
Tables 1 summarizes the DTMF-related named events within the Table 1 summarizes the DTMF-related named events within the
telephone-event payload format. telephone-event payload format.
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 named events Table 1: DTMF named events
3.11 Data Modem and Fax Events 3.11 Data Modem and Fax Events
Table 3.11 summarizes the events and tones that can appear on a Table 3.11 summarizes the events and tones that can appear on a
subscriber line serving a fax machine or modem. The tones are subscriber line serving a fax machine or modem. The tones are
described below, with additional detail in Table 7. described below, with additional detail in Table 7.
ANS: This 2100 +/- 15 Hz tone is used to disable echo ANS: This 2100 +/- 15 Hz tone is used to disable echo
suppression for data transmission [8,9]. For fax machines, suppression for data transmission [8,9]. For fax machines,
Recommendation T.30 [9] refers to this tone as called Recommendation T.30 [9] refers to this tone as called
terminal identification (CED) answer tone. 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 V.25 [8], this signal is rendered as ANS Recommendation V.25 [8], this signal is rendered as ANS
with a bar on top.) with a bar on top.)
ANSam: The modified answer tone (ANSam) [3] is a sinewave signal ANSam: The modified answer tone (ANSam) [3] is a sinewave signal
at 2100 +/- 1 Hz without phase reversals, amplitude- at 2100 +/- 1 Hz without phase reversals, amplitude-modulated
modulated by a sinewave at 15 +/- 0.1 Hz. This tone is sent by a sinewave at 15 +/- 0.1 Hz. This tone is sent by modems
by modems if network echo canceller disabling is not if network echo canceller disabling is not required.
required.
/ANSam: The modified answer tone with phase reversals (ANSam) /ANSam: The modified answer tone with phase reversals (ANSam) [3]
[3] is a sinewave signal at 2100 +/- 1 Hz with phase is a sinewave signal at 2100 +/- 1 Hz with phase reversals at
reversals at intervals of 450 +/- 25 ms, amplitude- intervals of 450 +/- 25 ms, amplitude-modulated by a sinewave
modulated by a sinewave at 15 +/- 0.1 Hz. This tone [10,8] at 15 +/- 0.1 Hz. This tone [10,8] is sent by modems [11] and
is sent by modems [11] and faxes to disable echo faxes to disable echo suppressors.
suppressors.
CNG: After dialing the called fax machine's telephone number CNG: After dialing the called fax machine's telephone number (and
(and before it answers), the calling Group III fax machine 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. [9] of an interrupted tone of 1100 Hz. [9]
CRd: Capabilities Request (CRd) [12] is a dual-tone signal with CRdi: Capabilities Request (CRd), initiating side, [12] is a
tones at tones at 1375 Hz and 2002 Hz for 400 ms for the dual-tone signal with tones at 1375 Hz and 2002 Hz for 400
initiating side and 1529 Hz and 2225 Hz for the responding ms, followed by a single tone at 1900 Hz for 100 ms. "This
side, followed by a single tone at 1900 Hz for 100 ms. signal requests the remote station transition from telephony
"This signal requests the remote station transition from mode to an information transfer mode and requests the
telephony mode to an information transfer mode and requests transmission of a capabilities list message by the remote
the transmission of a capabilities list message by the station. In particular, CRdi is sent by the initiating
remote station. In particular, CRd is sent by the station during the course of a call, or by the calling
initiating station during the course of a call, or by the station at call establishment in response to a CRe or MRe."
calling station at call establishment in response to a CRe
or MRe."
CRe: Capabilities Request (CRe) [12] is a dual-tone signal with CRdr: CRdr is the response tone to CRdi (see above). It consists
tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed of a dual-tone signal with tones at 1529 Hz and 2225 Hz for
by a single tone at 400 Hz for 100 ms. "This signal 400 ms, followed by a single tone at 1900 Hz for 100 ms.
requests the remote station transition from telephony mode
to an information transfer mode and requests the
transmission of a capabilities list message by the remote
station. In particular, CRe is sent by an automatic
answering station at call establishment."
CT: "The calling tone [8] consists of a series of interrupted CRe: Capabilities Request (CRe) [12] is a dual-tone signal with
bursts of binary 1 signal or 1300 Hz, on for a duration of tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed by
not less than 0.5 s and not more than 0.7 s and off for a a single tone at 400 Hz for 100 ms. "This signal requests the
duration of not less than 1.5 s and not more than 2.0 s." remote station transition from telephony mode to an
Modems not starting with the V.8 call initiation tone often information transfer mode and requests the transmission of a
use this tone. capabilities list message by the remote station. In
particular, CRe is sent by an automatic answering station at
call establishment."
ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones CT: "The calling tone [8] consists of a series of interrupted
at 1375 Hz and 2002 Hz for 400 ms, followed by a single bursts of binary 1 signal or 1300 Hz, on for a duration of
tone at 980 Hz for 100 ms. "This signal requests the remote not less than 0.5 s and not more than 0.7 s and off for a
station transition from telephony mode to an information duration of not less than 1.5 s and not more than 2.0 s."
transfer mode. signal ESi is sent by the initiating Modems not starting with the V.8 call initiation tone often
station." use this tone.
ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones at
at 1529 Hz and 2225 Hz for 400 ms, followed by a single 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at
tone at 1650 Hz for 100 ms. Same as ESi, but sent by the 980 Hz for 100 ms. "This signal requests the remote station
responding station. transition from telephony mode to an information transfer
mode. signal ESi is sent by the initiating station."
MRd: Mode Request (MRd) [12] is a dual-tone signals with tones ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones at
at 1375 Hz and 2002 Hz for 400 ms for the initiating side 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at
and 1529 Hz and 2225 Hz for the responding side, followed 1650 Hz for 100 ms. Same as ESi, but sent by the responding
by a single tone at 1150 Hz for 100 ms. "This signal station.
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." [12]
MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at MRdi: Mode Request (MRd), initiating side, [12] is a dual-tone
1375 Hz and 2002 Hz for 400 ms, followed by a single tone signal with tones at 1375 Hz and 2002 Hz for 400 ms followed
at 650 Hz for 100 ms. "This signal requests the remote by a single tone at 1150 Hz for 100 ms. "This signal requests
station transition from telephony mode to an information the remote station transition from telephony mode to an
transfer mode and requests the transmission of a mode information transfer mode and requests the transmission of a
select message by the remote station. In particular, signal mode select message by the remote station. In particular,
MRe is sent by an automatic answering station at call signal MRd is sent by the initiating station during the
establishment." [12] course of a call, or by the calling station at call
establishment in response to an MRe." [12]
V.21: V.21 describes a 300 b/s full-duplex modem that employs MRdr: MRdr is the response tone to MRdi (see above). It consists
frequency shift keying (FSK). It is used by Group 3 fax of a dual-tone signal with tones at 1529 Hz and 2225 Hz for
machines to exchange T.30 information. The calling 400 ms, followed by a single tone at 1150 Hz for 100 ms.
transmits on channel 1 and receives on channel 2; the
answering modem transmits on channel 2 and receives on MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at
channel 1. Each bit value has a distinct tone, so that V.21 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at
signaling comprises a total of four distinct tones. 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." [12]
V.21: V.21 describes a 300 b/s full-duplex modem that employs
frequency shift keying (FSK). It is used by Group 3 fax
machines to exchange T.30 information. The calling transmits
on channel 1 and receives on channel 2; the answering modem
transmits on channel 2 and receives on channel 1. Each bit
value has a distinct tone, so that V.21 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 V.25 and V.8 ANS
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam V.8 ANSam
V.8, echo canceller disabled /ANSam V.8, echo canceller disabled /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) 32 ___________________________________________________
/ANS 33 Answer tone (ANS) 32
ANSam 34 /ANS 33
/ANSam 35 ANSam 34
Calling tone (CNG) 36 /ANSam 35
V.21 channel 1, "0" bit 37 Calling tone (CNG) 36
V.21 channel 1, "1" bit 38 V.21 channel 1, "0" bit 37
V.21 channel 2, "0" bit 39 V.21 channel 1, "1" bit 38
V.21 channel 2, "1" bit 40 V.21 channel 2, "0" bit 39
CRd 41 V.21 channel 2, "1" bit 40
CRe 42 CRdi 41
ESi 43 CRdr 42
ESr 44 CRe 43
MRd 45 ESi 44
MRe 46 ESr 45
CT 47 MRdi 46
MRdr 47
MRe 48
CT 49
Table 3: Data and fax named events Table 3: Data and fax named events
3.12 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. subscriber line.
ITU Recommendation E.182 [13] defines when certain tones should be ITU Recommendation E.182 [13] 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 a
a voice mail is available (e.g., "stutter dial tone"). voice mail is available (e.g., "stutter dial tone").
Second dial tone: The network has accepted the address Second dial tone: The network has accepted the address
information, but additional information is required. information, but additional information is required.
Ring: This named signal event causes the recipient to generate Ring: This named signal event causes the recipient to generate an
an alerting signal ("ring"). The actual tone or other alerting signal ("ring"). The actual tone or other indication
indication used to render this named event is left up to used to render this named event is left up to the receiver.
the receiver. (This differs from the ringing tone, below, (This differs from the ringing tone, below, heard by the
heard by the caller caller
Ringing tone: The call has been placed to the callee and a Ringing tone: The call has been placed to the callee and a calling
calling signal (ringing) is being transmitted to the signal (ringing) is being transmitted to the callee. This
callee. This tone is also called "ringback". tone is also called "ringback".
Special ringing tone: A special service, such as call forwarding Special ringing tone: A special service, such as call forwarding
or 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 Congestion tone: Facilities necessary for the call are temporarily
temporarily unavailable. unavailable.
Calling card service tone: The calling card service tone Calling card service tone: The calling card service tone consists
consists of 60 ms of the sum of 941 Hz and 1477 Hz tones of 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'),
(DTMF '#'), followed by 940 ms of 350 Hz and 440 Hz (U.S. followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone),
dial tone), decaying exponentially with a time constant of decaying exponentially with a time constant of 200 ms.
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 reason is neither "busy" nor "congestion". This tone should
be used before all call failure announcements, for the be used before all call failure announcements, for the
benefit of 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. Hold tone: The caller has been placed on hold.
Record tone: The caller has been connected to an automatic Record tone: The caller has been connected to an automatic
answering 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 Caller waiting tone: The called station is busy, but has call
waiting 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
activated. activated.
Off-hook warning tone: The caller has left the instrument off- Off-hook warning tone: The caller has left the instrument off-hook
hook for an extended period of time. for an extended period of time.
The following tones can be heard by either calling or called party The following tones can be heard by 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 Warning tone: The call is being recorded. This tone is not
required in all jurisdictions. required in all jurisdictions.
Intrusion tone: The call is being monitored, e.g., by an Intrusion tone: The call is being monitored, e.g., by an operator.
operator.
CPE alerting signal: A tone used to alert a device to an CPE alerting signal: A tone used to alert a device to an arriving
arriving in-band FSK data transmission. A CPE alerting in-band FSK data transmission. A CPE alerting signal is a
signal is a combined 2130 and 2750 Hz tone, both with combined 2130 and 2750 Hz tone, both with tolerances of 0.5%
tolerances of 0.5% and a duration of 80 to. 80 ms. The CPE and a duration of 80 to. 80 ms. The CPE alerting signal is
alerting signal is used with ADSI services and Call Waiting used with ADSI services and Call Waiting ID services [14].
ID services [14].
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).
Event encoding (decimal)
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89
Table 4: E.182 line events
3.13 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. on a subscriber line.
Event encoding (decimal)
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89
Table 4: E.182 line events
3.14 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 Note that trunk can also carry line events (Section 3.12), as MF
signaling does not include backward signals [15]. signaling does not include backward signals [15].
ABCD transitional: 4-bit signaling used by digital trunks. For ABCD transitional: 4-bit signaling used by digital trunks. For N-
N-state signaling, the first N values are used. state signaling, the first N values are used.
The T1 ESF (extended super frame format) allows 2, 4, and
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
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
Permanent signal tone 104 Permanent signal tone 104
Preemption tone 105 Preemption tone 105
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
carried in timeslot 16, and two channels of 16-state (ABCD) The T1 ESF (extended super frame format) allows 2, 4, and 16
signalling are sent per frame. state signaling bit options. These signaling bits are named
A, B, C, and D. Signaling 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 signaling with A and B
bits. On the CEPT E1 frame, all signaling is carried in
timeslot 16, and two channels of 16-state (ABCD) signaling
are sent per frame.
Since this information is a state rather than a changing Since this information is a state rather than a changing
signal, implementations SHOULD use the following triple- signal, implementations SHOULD use the following triple-
redundancy mechanism, similar to the one specified in ITU-T redundancy mechanism, similar to the one specified in ITU-T
Rec. I.366.2 [16], Annex L. At the time of a transition, Rec. I.366.2 [16], Annex L. At the time of a transition, the
the same ABCD information is sent 3 times at an interval of same ABCD information is sent 3 times at an interval of 5 ms.
5 ms. If another transition occurs during this time, then If another transition occurs during this time, then this
this continues. After a period of no change, the ABCD continues. After a period of no change, the ABCD information
information is sent every 5 seconds. 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 (unseized) to off-hook (seized) and back to onhook, used by
the incoming exchange to signal that the call address the incoming exchange to signal that the call address
signaling can proceed. signaling can proceed.
Incoming seizure: Incoming indication of call attempt (off- Incoming seizure: Incoming indication of call attempt (off-hook).
hook).
Seizure: Seizure by answering exchange, in response to outgoing Event encoding (decimal)
seizure. __________________________________________________
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
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
Unseize circuit: Transition of circuit from off-hook to on-hook Table 6: Trunk events
at the end of a call.
Event encoding (decimal) Seizure: Seizure by answering exchange, in response to outgoing
__________________________________________________ seizure.
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
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
Table 6: Trunk events 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- Wink off: A brief transition, typically 100-350 ms, from off-hook
hook (seized) to on-hook (unseized) and back to off-hook (seized) to on-hook (unseized) and back to off-hook (seized).
(seized). Used in operator services trunks. 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.
4 RTP Payload Format for Telephony Tones 4 RTP Payload Format for Telephony Tones
4.1 Introduction 4.1 Introduction
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 [17]: all countries, these tones share a number of characteristics [17]:
o Telephony tones consist of either a single tone, the addition o Telephony tones consist of either a single tone, the addition
of two or three tones or the modulation of two tones. (Almost of two or three tones or the modulation of two tones. (Almost
all tones use two frequencies; only the Hungarian "special all tones use two frequencies; only the Hungarian "special dial
dial tone" has three.) Tones that are mixed have the same tone" has three.) Tones that are mixed have the same amplitude
amplitude and do not decay. 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
tone in Angola) to 1800 Hz. CED is the highest used tone at in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz.
2100 Hz. The telephone frequency range is limited to 3,400 Hz. The telephone frequency range is limited to 3,400 Hz. (The
(The piano has a range from 27.5 to 4186 Hz.) piano has a range from 27.5 to 4186 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 [18] notes that different telephone o ITU Recommendation E.180 [18] notes that different telephone
companies require a tone accuracy of between 0.5 and 1.5%. companies require a tone accuracy of between 0.5 and 1.5%. The
The Recommendation suggests a frequency tolerance of 1%. 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 [18]. Note that there are no specific guidelines Recommendation E.180 [18]. 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 Tone name frequency on period off period
______________________________________________________
Timestamp: The RTP timestamp reflects the measurement point for CNG 1100 0.5 3.0
the current packet. The event duration described in Section V.25 CT 1300 0.5 2.0
CED 2100 3.3 --
ANS 2100 3.3 --
ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.00333
V.21 "1" bit, ch. 1 980 0.00333
V.21 "0" bit, ch. 2 1850 0.00333
V.21 "1" bit, ch. 2 1650 0.00333
ITU dial tone 425 -- --
U.S. dial tone 350+440 -- --
______________________________________________________
ITU ringing tone 425 0.67--1.5 3--5
U.S. ringing tone 440+480 2.0 4.0
ITU busy tone 425
U.S. busy tone 480+620 0.5 0.5
______________________________________________________
ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25
Tone name frequency on period off period Table 7: Examples of telephony tones
______________________________________________________
CNG 1100 0.5 3.0
V.25 CT 1300 0.5 2.0
CED 2100 3.3 --
ANS 2100 3.3 --
ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.033
V.21 "1" bit, ch. 1 980 0.033
V.21 "0" bit, ch. 2 1850 0.033
V.21_"1"_bit,_ch._2________1650______0.033____________
ITU dial tone 425 -- --
U.S. dial tone 350+440 -- --
______________________________________________________
ITU ringing tone 425 0.67--1.5 3--5
U.S._ringing_tone_______440+480________2.0_________4.0
ITU busy tone 425
U.S. busy tone 480+620 0.5 0.5
______________________________________________________
ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25
Table 7: Examples of telephony tones 4.3 Use of RTP Header Fields
3.5 extends forwards from that time. 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" that can represent tones an RTP payload format called "tone" that can represent tones
consisting of one or more frequencies. (The corresponding MIME type consisting of one or more frequencies. (The corresponding MIME type
is "audio/tone".) The default timestamp rate is 8,000 Hz, but other is "audio/tone".) The default timestamp rate is 8,000 Hz, but other
rates may be defined. Note that the timestamp rate does not affect rates may be defined. Note that the timestamp rate does not affect
the interpretation of the frequency, just the durations. the interpretation of the frequency, just the durations.
In accordance with current practice, this payload format does not In accordance with current practice, this payload format does not
have 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. 3. It is shown in Fig. 3.
The payload contains the following fields: 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
modulation: The modulation frequency, in Hz. The field is a 9- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
bit unsigned integer, allowing modulation frequencies up to | modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
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 |R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Payload format for tones
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Payload format for tones The payload contains the following fields:
511 Hz. If there is no modulation, this field has a value modulation: The modulation frequency, in Hz. The field is a 9-bit
of zero. 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 T: If the "T" bit is set (one), the modulation frequency is to be
be divided by three. Otherwise, the modulation frequency is divided by three. Otherwise, the modulation frequency is
taken as is. taken as is.
This bit allows frequencies accurate to 1/3 Hz, since This bit allows frequencies accurate to 1/3 Hz, since
modulation frequencies such as 16 2/3 Hz are in modulation frequencies such as 16 2/3 Hz are in practical
practical use. use.
volume: The power level of the tone, expressed in dBm0 after 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
dBm0 to -3 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-
sample-based codecs, where the timestamp represents based codecs, where the timestamp represents the sampling
the sampling point for the first sample. 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
zero indicates silence. A single tone can contain any indicates silence. A single tone can contain any number of
number of frequencies. 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 format uses the reliability mechanism described in This payload format uses the reliability mechanism described in
Section 3.7. 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 using the method specified in RFC 2198. Fig. 4 shows an payload using the method specified in RFC 2198. Fig. 4 shows an
skipping to change at page 23, line 41 skipping to change at page 23, line 39
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.
6 MIME Registration 6 MIME Registration
6.1 audio/telephone-event 6.1 audio/telephone-event
MIME media type name: audio MIME media type name: audio
MIME subtype name: telephone-event
Required parameters: none. MIME subtype name: telephone-event
Optional parameters: The "events" parameter lists the events Required parameters: none.
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.
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 |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length | |F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 | |1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT | |F| Block PT |
|0| 97 | |0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 | | event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 | | modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 4: Combining tones and events in a single RTP packet Figure 4: Combining tones and events in a single RTP packet
No white space is allowed in the argument. The integers Optional parameters: The "events" parameter lists the events
designate the event numbers supported by the supported by the implementation. Events are listed as one or
implementation. All implementations MUST support events 0 more comma-separated elements. Each element can either be a
through 15, so that the parameter can be omitted if the single integer or two integers separated by a hyphen. No
implementation only supports these events. white space is allowed in the argument. The integers
designate the event numbers supported by the implementation.
All implementations MUST support events 0 through 15, so that
the parameter can be omitted if the implementation only
supports these events.
The "rate" parameter describes the sampling rate, in Hertz. The "rate" parameter describes the sampling rate, in Hertz.
The number is written as a floating point number or as an The number is written as a floating point number or as an
integer. If omitted, the default value is 8000 Hz. integer. If omitted, the default value is 8000 Hz.
Encoding considerations: This type is only defined for transfer Encoding considerations: This type is only defined for transfer
via RTP [1]. via RTP [1].
Security considerations: See the "Security Considerations" Security considerations: See the "Security Considerations"
(Section 7) section in this document. (Section 7) section in this document.
Interoperability considerations: none Interoperability considerations: none
Published specification: This document. Published specification: This document.
Applications which use this media: The telephone-event audio Applications which use this media: The telephone-event audio
subtype supports the transport of events occuring in subtype supports the transport of events occurring in
telephone systems over the Internet. telephone systems over the Internet.
Additional information: Additional information:
1. Magic number(s): N/A 1. Magic number(s): N/A
2. File extension(s): N/A 2. File extension(s): N/A
3. Macintosh file type code: N/A 3. Macintosh file type code: N/A
6.2 audio/tone 6.2 audio/tone
MIME media type name: audio MIME media type name: audio
MIME subtype name: tone MIME subtype name: tone
Required parameters: none Required parameters: none
Optional parameters: The "rate" parameter describes the sampling Optional parameters: The "rate" parameter describes the sampling
rate, in Hertz. The number is written as a floating point rate, in Hertz. The number is written as a floating point
number or as an integer. If omitted, the default value is number or as an integer. If omitted, the default value is
8000 Hz. 8000 Hz.
Encoding considerations: This type is only defined for transfer Encoding considerations: This type is only defined for transfer
via RTP [1]. via RTP [1].
Security considerations: See the "Security Considerations" Security considerations: See the "Security Considerations"
(Section 7) section in this document. (Section 7) section in this document.
Interoperability considerations: none Interoperability considerations: none
Published specification: This document. Published specification: This document.
Applications which use this media: The tone audio subtype Applications which use this media: The tone audio subtype supports
supports the transport of pure composite tones, for example the transport of pure composite tones, for example those
those commonly used in the current telephone system to commonly used in the current telephone system to signal call
signal call progress. progress.
Additional information: Additional information:
1. Magic number(s): N/A 1. Magic number(s): N/A
2. File extension(s): N/A 2. File extension(s): N/A
3. Macintosh file type code: N/A 3. Macintosh file type code: N/A
7 Security Considerations 7 Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification (RFC 1889 [1]), and any appropriate RTP profile (for specification (RFC 1889 [1]), and any appropriate RTP profile (for
example RFC 1890 [19]).This implies that confidentiality of the media example RFC 1890 [19]).This implies that confidentiality of the media
streams is achieved by encryption. Because the data compression used streams is achieved by encryption. Because the data compression used
with this payload format is applied end-to-end, encryption may be with this payload format is applied end-to-end, encryption may be
performed after compression so there is no conflict between the two performed after compression so there is no conflict between the two
skipping to change at page 27, line 13 skipping to change at page 27, line 16
equivalent standards document produced by another standardization equivalent standards document produced by another standardization
body, such as ITU-T. body, such as ITU-T.
9 Acknowledgements 9 Acknowledgements
The suggestions of the Megaco working group are gratefully The suggestions of the Megaco working group are gratefully
acknowledged. Detailed advice and comments were provided by Fred acknowledged. Detailed advice and comments were provided by Fred
Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar
Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins. Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins.
10 Authors 10 Authors' Addresses
Henning Schulzrinne 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
EMail: 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
EMail: scott.petrack@metatel.com
11 Bibliography 11 Bibliography
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
transport protocol for real-time applications," Request for Comments "RTP: A Transport Protocol for Real-Time Applications", RFC
(Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 1889, January 1996.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
levels," Request for Comments (Best Current Practice) 2119, Internet Levels", BCP 14, RFC 2119, March 1997.
Engineering Task Force, Mar. 1997.
[3] International Telecommunication Union, "Procedures for starting [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.
[4] 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.
[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] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP payload for Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload
redundant audio data," Request for Comments (Proposed Standard) 2198, for Redundant Audio Data", RFC 2198, September 1997.
Internet Engineering Task Force, Sept. 1997.
[7] M. Handley and V. Jacobson, "SDP: session description protocol," [7] Handley M. and V. Jacobson, "SDP: Session Description Protocol",
Request for Comments (Proposed Standard) 2327, Internet Engineering RFC 2327, April 1998.
Task Force, Apr. 1998.
[8] International Telecommunication Union, "Automatic answering [8] International Telecommunication Union, "Automatic answering
equipment and general procedures for automatic calling equipment on equipment and general procedures for automatic calling equipment
the general switched telephone network including procedures for on the general switched telephone network including procedures
disabling of echo control devices for both manually and automatically for disabling of echo control devices for both manually and
established calls," Recommendation V.25, Telecommunication automatically established calls," Recommendation V.25,
Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996. Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Oct. 1996.
[9] 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
Recommendation T.30, Telecommunication Standardization Sector of ITU, network," Recommendation T.30, Telecommunication Standardization
Geneva, Switzerland, July 1996. Sector of ITU, Geneva, Switzerland, July 1996.
[10] International Telecommunication Union, "Echo cancellers," [10] International Telecommunication Union, "Echo cancellers,"
Recommendation G.165, Telecommunication Standardization Sector of Recommendation G.165, Telecommunication Standardization Sector
ITU, Geneva, Switzerland, Mar. 1993. of ITU, Geneva, Switzerland, Mar. 1993.
[11] 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 signaling rates of up to 33 600 bit/s for use on the
switched telephone network and on leased point-to-point 2-wire general switched telephone network and on leased point-to-point
telephone-type circuits," Recommendation V.34, Telecommunication 2-wire telephone-type circuits," Recommendation V.34,
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Feb. 1998.
[12] 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
data circuit-terminating equipments (dces) and between data terminal between data circuit-terminating equipments (DCEs) and between
equipments (dtes) over the public switched telephone network and on data terminal equipments (DTEs) over the public switched
leased point-to-point telephone-type circuits," Recommendation telephone network and on leased point-to-point telephone-type
V.8bis, Telecommunication Standardization Sector of ITU, Geneva, circuits," Recommendation V.8bis, Telecommunication
Switzerland, Sept. 1998. Standardization Sector of ITU, Geneva, Switzerland, Sept. 1998.
[13] 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
Telecommunication Standardization Sector of ITU, Geneva, Switzerland, E.182, Telecommunication Standardization Sector of ITU, Geneva,
Mar. 1998. Switzerland, Mar. 1998.
[14] Bellcore, "Functional criteria for digital loop carrier [14] Bellcore, "Functional criteria for digital loop carrier
systems," Technical Requirement TR-NWT-000057, Telcordia (formerly systems," Technical Requirement TR-NWT-000057, Telcordia
Bellcore), Morristown, New Jersey, Jan. 1993. (formerly Bellcore), Morristown, New Jersey, Jan. 1993.
[15] J. G. van Bosse, Signaling in Telecommunications Networks [15] 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:
1998. Wiley, 1998.
[16] International Telecommunication Union, "AAL type 2 service [16] International Telecommunication Union, "AAL type 2 service
specific convergence sublayer for trunking," Recommendation I.366.2, specific convergence sublayer for trunking," Recommendation
Telecommunication Standardization Sector of ITU, Geneva, Switzerland, I.366.2, Telecommunication Standardization Sector of ITU,
Feb. 1999. Geneva, Switzerland, Feb. 1999.
[17] International Telecommunication Union, "Various tones used in [17] International Telecommunication Union, "Various tones used in
national networks," Recommendation Supplement 2 to Recommendation national networks," Recommendation Supplement 2 to
E.180, Telecommunication Standardization Sector of ITU, Geneva, Recommendation E.180, Telecommunication Standardization Sector
Switzerland, Jan. 1994. of ITU, Geneva, Switzerland, Jan. 1994.
[18] International Telecommunication Union, "Technical [18] 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.
[19] H. Schulzrinne, "RTP profile for audio and video conferences [19] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with minimal control," Request for Comments (Proposed Standard) 1890, with Minimal Control", RFC 1890, January 1996.
Internet Engineering Task Force, Jan. 1996.
12 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 167 change blocks. 
680 lines changed or deleted 661 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/