draft-ietf-avt-tones-02.txt   draft-ietf-avt-tones-03.txt 
Internet Engineering Task Force AVT WG Internet Engineering Task Force AVT WG
Internet Draft Schulzrinne/Petrack Internet Draft Schulzrinne/Petrack
ietf-avt-tones-02.txt Columbia U./MetaTel draft-ietf-avt-tones-03.txt Columbia U./MetaTel
October 22, 1999 November 28, 1999
Expires: February 2000 Expires: May 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".
To view the list Internet-Draft Shadow Directories, see The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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 MUST 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 [4]. 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
skipping to change at page 7, line 21 skipping to change at page 7, line 21
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. A sender MAY set the end bit only when event.
retransmitting the last packet for a tone. This avoids
having to wait to detect whether the tone has indeed ended.
Receiver implementations MAY use at different algorithms to A sender MAY delay setting the end bit until retransmitting
the last packet for a tone, rather than on its first
transmission. This avoids having to wait to detect whether
the tone has indeed ended.
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, 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 same tone, the waveform in the received that extend the same tone, the waveform in the
playout buffer is extended accordingly. (Care has to be playout buffer is extended accordingly. (Care has to be
taken if audio is mixed, i.e., summed, in the playout taken if audio is mixed, i.e., summed, in the playout
buffer rather than simply copied.) Thus, if a packet in a buffer rather than simply copied.) Thus, if a packet in a
tone lasting longer than the packet interarrival time gets tone lasting longer than the packet interarrival time gets
lost and the playout delay is short, a gap in the tone may lost and the playout delay is short, a gap in the tone may
skipping to change at page 10, line 12 skipping to change at page 10, line 15
| timestamp | | timestamp |
| 11200 | | 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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| 97 | 11200 | 4 | |1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length | |F| block PT | timestamp offset | block length |
|1| 97 | 4800 | 4 | |1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT | |F| Block PT |
|0| 97 | |0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |R R| volume | duration | | digit |E R| volume | duration |
| 9 |0 0| 7 | 1600 | | 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |R R| volume | duration | | digit |E R| volume | duration |
| 1 |0 0| 10 | 2000 | | 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |R R| volume | duration | | digit |E 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 [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:
skipping to change at page 11, line 14 skipping to change at page 11, line 16
a=fmtp:100 0-11,66,70 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/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 events belonging to the DTMF payload type. Tables 1 summarizes the DTMF-related named events within the
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 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
skipping to change at page 13, line 42 skipping to change at page 14, line 4
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
3.12 Line Events
Table 4 summarizes the events and tones that can appear on a
subscriber line.
Event encoding (decimal) 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 named events
3.12 Line Events
Table 4 summarizes the events and tones that can appear on a
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.
skipping to change at page 15, line 51 skipping to change at page 16, line 8
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. (Use by law enforcement authorities is optional.) operator. (Use by law enforcement authorities is optional.)
CPE alerting signal (CAS): A tone used to alert a device to an CPE alerting signal: A tone used to alert a device to an
arriving in-band FSK data transmission. A CAS is a combined arriving in-band FSK data transmission. A CPE alerting
2130 and 2750 Hz tone, both with tolerances of 0.5% and a signal is a combined 2130 and 2750 Hz tone, both with
duration of 80 to 80 ms. CAS is used with ADSI services and tolerances of 0.5% and a duration of 80 to. 80 ms. The CPE
Call Waiting ID services, see Bellcore GR-30-CORE, Issue 2, alerting signal is used with ADSI services and Call Waiting
December 1998, Section 2.5.2. 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) Event encoding (decimal)
_____________________________________________ _____________________________________________
Off Hook 64 Off Hook 64
skipping to change at page 17, line 31 skipping to change at page 17, line 36
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
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 [14]. signaling does not include backward signals [15].
[NOTE: the list below, below wink, does not agree with the MF
description in van Bosse, p. 74.]
ABCD transitional: 4-bit signaling used by digital trunks. For ABCD transitional: 4-bit signaling used by digital trunks. For
N-state signaling, the first N values are used. N-state signaling, the first N values are used.
The T1 ESF (extended super frame format) allows 2, 4, and The T1 ESF (extended super frame format) allows 2, 4, and
16 state signalling bit options. These signalling bits are 16 state signalling bit options. These signalling bits are
named A, B, C, and D. Signalling information is sent as named A, B, C, and D. Signalling information is sent as
robbed bits in frames 6, 12, 18, and 24 when using ESF T1 robbed bits in frames 6, 12, 18, and 24 when using ESF T1
framing. A D4 superframe only transmits 4-state signalling framing. A D4 superframe only transmits 4-state signalling
with A and B bits. On the CEPT E1 frame, all signalling is with A and B bits. On the CEPT E1 frame, all signalling is
carried in timeslot 16, and two channels of 16-state (ABCD) carried in timeslot 16, and two channels of 16-state (ABCD)
signalling are sent per frame. 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 29 skipping to change at page 18, line 30
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
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 redundancy mechanism, similar to the one specified in ITU-T
Rec. I.366.2 [15], Annex L. At the time of a transition, Rec. I.366.2 [16], Annex L. At the time of a transition,
the same ABCD information is sent 3 times at an interval of the same ABCD information is sent 3 times at an interval of
5 ms. If another transition occurs during this time, then 5 ms. If another transition occurs during this time, then
this continues. After a period of no change, the ABCD this continues. After a period of no change, the ABCD
information is sent every 5 seconds. information is sent every 5 seconds.
Wink: A brief transition, typically 120-290 ms, from on-hook Wink: A brief transition, typically 120-290 ms, from on-hook
(unseized) to off-hook (seized) and back to onhook, used by (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.
skipping to change at page 19, line 34 skipping to change at page 19, line 36
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 [16]: 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 tone" has three.) Tones that are mixed have the same dial tone" has three.) Tones that are mixed have the same
amplitude and 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 [17] 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 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 [17]. 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).
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 --
skipping to change at page 22, line 42 skipping to change at page 22, line 46
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. 3 shows an payload using the method specified in RFC 2198. Fig. 3 shows an
example. In that example, the RTP packet combines two "tone" and one example. In that example, the RTP packet combines two "tone" and one
"telephone-event" payload. The payload types are chosen arbitrarily "telephone-event" payloads. The payload types are chosen arbitrarily
as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the
redundancy format has 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.
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 |P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 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 MIME subtype name: telephone-event
Required parameters: none. Required parameters: none.
skipping to change at page 24, line 41 skipping to change at page 24, line 5
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 occuring in
telephone systems over the Internet. telephone systems over the Internet.
Additional information: Additional information:
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 |P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Combining tones and events in a single RTP packet
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
skipping to change at page 25, line 39 skipping to change at page 25, line 46
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 [18]).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
operations. operations.
This payload type does not exhibit any significant non-uniformity in This payload type does not exhibit any significant non-uniformity in
the receiver side computational complexity for packet processing to the receiver side computational complexity for packet processing to
cause a potential denial-of-service threat. cause a potential denial-of-service threat.
8 IANA Considerations 8 IANA Considerations
skipping to change at page 28, line 12 skipping to change at page 28, line 18
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.
[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 E.182,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
Mar. 1998. Mar. 1998.
[14] J. G. van Bosse, Signaling in Telecommunications Networks [14] Bellcore, "Functional criteria for digital loop carrier
systems," Technical Requirement TR-NWT-000057, Telcordia (formerly
Bellcore), Morristown, New Jersey, Jan. 1993.
[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: Wiley,
1998. 1998.
[15] 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 I.366.2,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
Feb. 1999. Feb. 1999.
[16] 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 Recommendation
E.180, Telecommunication Standardization Sector of ITU, Geneva, E.180, Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Jan. 1994. Switzerland, Jan. 1994.
[17] 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.
[18] H. Schulzrinne, "RTP profile for audio and video conferences [19] H. Schulzrinne, "RTP profile for audio and video conferences
with minimal control," Request for Comments (Proposed Standard) 1890, with minimal control," Request for Comments (Proposed Standard) 1890,
Internet Engineering Task Force, Jan. 1996. 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/