draft-ietf-avt-tones-04.txt   draft-ietf-avt-tones-05.txt 
Internet Engineering Task Force AVT WG Internet Engineering Task Force AVT WG
Internet Draft Schulzrinne/Petrack Internet Draft Schulzrinne/Petrack
draft-ietf-avt-tones-04.txt Columbia U./MetaTel draft-ietf-avt-tones-05.txt Columbia U./MetaTel
December 9, 1999 December 20, 1999
Expires: May 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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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 for country-specific subscriber line tones (Section 3.13) and; o country-specific subscriber line tones (Section 3.13) and;
o for 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
If it uses some other, out-of-band mechanism for signaling line with the exception of "flash". If it uses some other, out-of-band
conditions, it does not have to implement the other events. mechanism for signaling line conditions, it does not have to
implement the other events.
In some cases, an implementation may simply ignore certain events, In some cases, an implementation may simply ignore certain events,
such as fax tones, that do not make sense in a particular such as fax tones, that do not make sense in a particular
environment. 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
inability to understand a particular event or range of events. inability to understand a particular event or range of events.
Depending on the available user interfaces, an implementation MAY Depending on the available user interfaces, an implementation MAY
render all tones in Table 5 the same or, preferably, use the tones render all tones in Table 5 the same or, preferably, use the tones
conveyed by the concurrent "tone" payload or other RTP audio payload. conveyed by the concurrent "tone" payload or other RTP audio payload.
skipping to change at page 9, line 44 skipping to change at page 9, line 44
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
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number | |V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 28 | | 2 |0|0| 0 |0| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | | timestamp |
| 11200 | | 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
skipping to change at page 10, line 30 skipping to change at page 10, line 35
| digit |E R| volume | duration | | digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 | | 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration | | digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 | | 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E 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 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
hyphen (dash), where the second number is larger than the first. No hyphen (dash), where the second number is larger than the first. No
whitespace is allowed between numbers or hyphens. The list does not whitespace is allowed between numbers or hyphens. The list does not
have to be sorted. have to be sorted.
For example, if the payload format uses the payload type number 100, For example, if the payload format uses the payload type number 100,
and the implementation can handle the common DTMF tones (events 0 and the implementation can handle the DTMF tones (events 0 through
through 11) and the dial and ringing tones, it would include the 15) and the dial and ringing tones, it would include the following
following description in its SDP message: description in its SDP message:
a=fmtp:100 0-11,66,70 a=fmtp:100 0-15,66,70
Since all implementations MUST be able to receive events 0 through
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 Tables 1 summarizes the DTMF-related named events within the
telephone-event payload format. telephone-event payload format.
skipping to change at page 13, line 46 skipping to change at page 14, line 7
V.21: V.21 describes a 300 b/s full-duplex modem that employs V.21: V.21 describes a 300 b/s full-duplex modem that employs
frequency shift keying (FSK). It is used by Group 3 fax frequency shift keying (FSK). It is used by Group 3 fax
machines to exchange T.30 information. The calling machines to exchange T.30 information. The calling
transmits on channel 1 and receives on channel 2; the transmits on channel 1 and receives on channel 2; the
answering modem transmits on channel 2 and receives on answering modem transmits on channel 2 and receives on
channel 1. Each bit value has a distinct tone, so that V.21 channel 1. Each bit value has a distinct tone, so that V.21
signaling comprises a total of four distinct tones. signaling comprises a total of four distinct tones.
In summary, procedures in Table 2 are used. In summary, procedures in Table 2 are used.
3.12 Line Events
Table 4 summarizes the events and tones that can appear on a
subscriber line.
Procedure indications Procedure indications
________________________________________________________ ________________________________________________________
V.25 and V.8 ANS, ANS, ... V.25 and V.8 ANS, ANS, ...
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam, ANSam, ... V.8 ANSam, ANSam, ...
V.8, echo canceller disabled ANSam, /ANSam, ANSam, ... V.8, echo canceller disabled ANSam, /ANSam, ANSam, ...
Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations
Event____________________encoding_(decimal) Event____________________encoding_(decimal)
skipping to change at page 14, line 34 skipping to change at page 14, line 36
CRd 41 CRd 41
CRe 42 CRe 42
ESi 43 ESi 43
ESr 44 ESr 44
MRd 45 MRd 45
MRe 46 MRe 46
CT 47 CT 47
Table 3: Data and fax named 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.
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
skipping to change at page 16, line 6 skipping to change at page 16, line 15
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.
Off-hook warning tone: The caller has left the instrument off- Off-hook warning tone: The caller has left the instrument off-
hook for an extended period of time. activated. hook for an extended period of time.
The following tones can be heard be 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. (Use by law enforcement authorities is optional.) 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 in-band FSK data transmission. A CPE alerting arriving in-band FSK data transmission. A CPE alerting
signal is a combined 2130 and 2750 Hz tone, both with signal is a combined 2130 and 2750 Hz tone, both with
tolerances of 0.5% and a duration of 80 to. 80 ms. The CPE tolerances of 0.5% and a duration of 80 to. 80 ms. The CPE
alerting signal is used with ADSI services and Call Waiting alerting signal is 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).
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.
3.14 Trunk Events 3.14 Trunk Events
Table 6 summarizes the events and tones that can appear on a trunk.
Note that trunk can also carry line events (Section 3.12), as MF
signaling does not include backward signals [15].
ABCD transitional: 4-bit signaling used by digital trunks. For
N-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
Event encoding (decimal) Event encoding (decimal)
_____________________________________________ _____________________________________________
Off Hook 64 Off Hook 64
On Hook 65 On Hook 65
Dial tone 66 Dial tone 66
PABX internal dial tone 67 PABX internal dial tone 67
Special dial tone 68 Special dial tone 68
Second dial tone 69 Second dial tone 69
Ringing tone 70 Ringing tone 70
Special ringing tone 71 Special ringing tone 71
skipping to change at page 17, line 35 skipping to change at page 17, line 35
Warning tone 83 Warning tone 83
Intrusion tone 84 Intrusion tone 84
Calling card service tone 85 Calling card service tone 85
Payphone recognition tone 86 Payphone recognition tone 86
CPE alerting signal (CAS) 87 CPE alerting signal (CAS) 87
Off-hook warning tone 88 Off-hook warning tone 88
Ring 89 Ring 89
Table 4: E.182 line events Table 4: E.182 line events
Table 6 summarizes the events and tones that can appear on a trunk.
Note that trunk can also carry line events (Section 3.12), as MF
signaling does not include backward signals [15].
ABCD transitional: 4-bit signaling used by digital trunks. For
N-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 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-
redundancy mechanism, similar to the one specified in ITU-T
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
5 ms. If another transition occurs during this time, then
this continues. After a period of no change, the ABCD
information is sent every 5 seconds.
Event encoding (decimal) Event encoding (decimal)
___________________________________________________ ___________________________________________________
Acceptance tone 96 Acceptance tone 96
Confirmation tone 97 Confirmation tone 97
Dial tone, recall 98 Dial tone, recall 98
End of three party service tone 99 End of three party service tone 99
Facilities tone 100 Facilities tone 100
Line lockout tone 101 Line lockout tone 101
Number unobtainable tone 102 Number unobtainable tone 102
Offering tone 103 Offering tone 103
skipping to change at page 18, line 27 skipping to change at page 18, line 27
Queue tone 106 Queue tone 106
Refusal tone 107 Refusal tone 107
Route tone 108 Route tone 108
Valid tone 109 Valid tone 109
Waiting tone 110 Waiting tone 110
Warning tone (end of period) 111 Warning tone (end of period) 111
Warning Tone (PIP tone) 112 Warning Tone (PIP tone) 112
Table 5: Country-specific Line events Table 5: Country-specific Line events
Since this information is a state rather than a changing
signal, implementations SHOULD use the following triple-
redundancy mechanism, similar to the one specified in ITU-T
Rec. I.366.2 [16], Annex L. At the time of a transition,
the same ABCD information is sent 3 times at an interval of
5 ms. If another transition occurs during this time, then
this continues. After a period of no change, the ABCD
information is sent every 5 seconds.
Wink: A brief transition, typically 120-290 ms, from on-hook 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).
Return seizure: Seizure by answering exchange, in response to Seizure: Seizure by answering exchange, in response to outgoing
outgoing seizure. [NOTE: Not clear why the difference here, seizure.
but not for Unseize. Should probably be just Seizure.]
Unseize circuit: Transition of circuit from off-hook to on-hook Unseize circuit: Transition of circuit from off-hook to on-hook
at the end of a call. 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 (seized) to on-hook (unseized) and back to off-hook hook (seized) to on-hook (unseized) and back to off-hook
(seized). Used in operator services trunks.
Continuity tone send: A tone of 2010 Hz.
Continuity tone detect: A tone of 2010 Hz.
Continuity test send: A tone of 1780 Hz is sent by the calling
exchange. If received by the called exchange, it returns a
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
Wink off 161 Wink off 161
Incoming seizure 162 Incoming seizure 162
Return seizure 163 Seizure 163
Unseize circuit 164 Unseize circuit 164
Continuity test 165 Continuity test 165
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
(seized). Used in operator services trunks.
Continuity tone send: 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
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
skipping to change at page 20, line 45 skipping to change at page 21, line 4
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 4.3 Use of RTP Header Fields
Timestamp: The RTP timestamp reflects the measurement point for Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section the current packet. The event duration described in Section
3.5 extends forwards from that time. 3.5 extends forwards from that time.
4.4 Payload Format 4.4 Payload Format
Based on the characteristics described above, this document defines
an RTP payload format called "tone" that can represent tones
consisting of one or more frequencies. (The corresponding MIME type
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
the interpretation of the frequency, just the durations.
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
V.25 CT 1300 0.5 2.0 V.25 CT 1300 0.5 2.0
CED 2100 3.3 -- CED 2100 3.3 --
ANS 2100 3.3 -- ANS 2100 3.3 --
ANSam 2100*15 3.3 -- ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.033 V.21 "0" bit, ch. 1 1180 0.033
V.21 "1" bit, ch. 1 980 0.033 V.21 "1" bit, ch. 1 980 0.033
V.21 "0" bit, ch. 2 1850 0.033 V.21 "0" bit, ch. 2 1850 0.033
skipping to change at page 21, line 29 skipping to change at page 21, line 28
ITU ringing tone 425 0.67--1.5 3--5 ITU ringing tone 425 0.67--1.5 3--5
U.S._ringing_tone_______440+480________2.0_________4.0 U.S._ringing_tone_______440+480________2.0_________4.0
ITU busy tone 425 ITU busy tone 425
U.S. busy tone 480+620 0.5 0.5 U.S. busy tone 480+620 0.5 0.5
______________________________________________________ ______________________________________________________
ITU congestion tone 425 ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25 U.S. congestion tone 480+620 0.25 0.25
Table 7: Examples of telephony tones Table 7: Examples of telephony tones
Based on the characteristics described above, this document defines
an RTP payload format called "tone" that can represent tones
consisting of one or more frequencies. (The corresponding MIME type
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
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. 2. It is shown in Fig. 3.
The payload contains the following fields: The payload contains the following fields:
modulation: The modulation frequency, in Hz. The field is a 9- modulation: The modulation frequency, in Hz. The field is a 9-
bit unsigned integer, allowing modulation frequencies up to bit unsigned integer, allowing modulation frequencies up to
511 Hz. If there is no modulation, this field has a value 511 Hz. If there is no modulation, this field has a value
of zero. of zero.
T: If the "T" bit is set (one), the modulation frequency is to
be divided by three. Otherwise, the modulation frequency is
taken as is.
This bit allows frequencies accurate to 1/3 Hz, since
modulation frequencies such as 16 2/3 Hz are in
practical use.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration | | modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency | |R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency | |R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...... ......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency | |R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Payload format for tones Figure 3: Payload format for tones
T: If the "T" bit is set (one), the modulation frequency is to
be divided by three. Otherwise, the modulation frequency is
taken as is.
This bit allows frequencies accurate to 1/3 Hz, since
modulation frequencies such as 16 2/3 Hz are in
practical use.
volume: The power level of the tone, expressed in dBm0 after volume: The power level of the tone, expressed in dBm0 after
dropping the sign, with range from 0 to -63 dBm0. (Note: A dropping the sign, with range from 0 to -63 dBm0. (Note: A
preferred level range for digital tone generators is -8 preferred level range for digital tone generators is -8
dBm0 to -3 dBm0.) dBm0 to -3 dBm0.)
duration: The duration of the tone, measured in timestamp units. duration: The duration of the tone, measured in timestamp units.
The tone begins at the instant identified by the RTP The tone begins at the instant identified by the RTP
timestamp and lasts for the duration value. timestamp and lasts for the duration value.
skipping to change at page 23, line 9 skipping to change at page 23, line 18
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. 3 shows an payload using the method specified in RFC 2198. Fig. 4 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" payloads. 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,
skipping to change at page 23, line 41 skipping to change at page 23, line 50
MIME subtype name: telephone-event MIME subtype name: telephone-event
Required parameters: none. Required parameters: none.
Optional parameters: The "events" parameter lists the events Optional parameters: The "events" parameter lists the events
supported by the implementation. Events are listed as one supported by the implementation. Events are listed as one
or more comma-separated elements. Each element can either or more comma-separated elements. Each element can either
be a single integer or two integers separated by a hyphen. be a single integer or two integers separated by a hyphen.
No white space is allowed in the argument. The integers No white space is allowed in the argument. The integers
designate the event numbers supported by the designate the event numbers supported by the
implementation. implementation. All implementations MUST support events 0
The "rate" parameter describes the sampling rate, in Hertz.
The number is written as a floating point number or as an
integer. If omitted, the default value is 8000 Hz.
Encoding considerations: This type is only defined for transfer
via RTP [1].
Security considerations: See the "Security Considerations"
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 |
skipping to change at page 24, line 40 skipping to change at page 24, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 | |0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 | | modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 | |0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Combining tones and events in a single RTP packet Figure 4: Combining tones and events in a single RTP packet
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 number is written as a floating point number or as an
integer. If omitted, the default value is 8000 Hz.
Encoding considerations: This type is only defined for transfer
via RTP [1].
Security considerations: See the "Security Considerations"
(Section 7) section in this document. (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 occuring in
telephone systems over the Internet. telephone systems over the Internet.
skipping to change at page 26, line 20 skipping to change at page 26, line 29
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
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.
Additional security considerations are described in RFC 2198 [6].
8 IANA Considerations 8 IANA Considerations
This document defines two new RTP payload formats, named telephone- This document defines two new RTP payload formats, named telephone-
event and tone, and associated Internet media (MIME) types, event and tone, and associated Internet media (MIME) types,
audio/telephone-event and audio/tone. audio/telephone-event and audio/tone.
Within the audio/telephone-event type, additional events MUST be Within the audio/telephone-event type, additional events MUST be
registered with IANA. Registrations are subject to approval by the registered with IANA. Registrations are subject to approval by the
current chair of the IETF audio/video transport working group, or by current chair of the IETF audio/video transport working group, or by
an expert designated by the transport area director if the AVT group an expert designated by the transport area director if the AVT group
 End of changes. 

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