RFC 4733
RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
Pages: 49
Proposed Standard
→ Errata
Obsoletes: 2833
Updated by: 4734 5244
Proposed Standard
→ Errata
Obsoletes: 2833
Updated by: 4734 5244
Part 2 of 2 – Pages 23 to 49
3. Specification of Event Codes for DTMF Events
This document defines one class of named events: DTMF tones.3.1. DTMF Applications
DTMF signalling [10] is typically generated by a telephone set or possibly by a PBX (Private branch telephone exchange). DTMF digits may be consumed by entities such as gateways or application servers in the IP network, or by entities such as telephone switches or IVRs in the circuit switched network.
The DTMF events support two possible applications at the sending end:
1. The Internet telephony gateway detects DTMF on the incoming
circuits and sends the RTP payload described here instead of
regular audio packets. The gateway likely has the necessary
digital signal processors and algorithms, as it often needs to
detect DTMF, e.g., for two-stage dialing. Having the gateway
detect tones relieves the receiving Internet end system from
having to do this work and also avoids having low bit-rate codecs
like G.723.1 [20] render DTMF tones unintelligible.
2. An Internet end system such as an "Internet phone" can emulate
DTMF functionality without concerning itself with generating
precise tone pairs and without imposing the burden of tone
recognition on the receiver.
A similar distinction occurs at the receiving end.
1. In the gateway scenario, an Internet telephony gateway connecting
a packet voice network to the PSTN re-creates the DTMF tones or
other telephony events and injects them into the PSTN.
2. In the end system scenario, the DTMF events are consumed by the
receiving entity itself.
In the most common application, DTMF tones are sent in one direction
only, typically from the calling end. The consuming device is most
commonly an IVR. DTMF may alternate with voice from either end. In
most cases, the only constraint on tone duration is that it exceed a
minimum value. However, in some cases a long-duration tone (in
excess of 1-2 seconds) has special significance.
ITU-T Recommendation Q.24 [11], Table A-1, indicates that the
legacy switching equipment in the countries surveyed expects a
minimum recognizable signal duration of 40 ms, a minimum pause
between signals of 40 ms, and a maximum signalling rate of 8 to 10
digits per second depending on the country. Human-generated DTMF
signals, of course, are generally longer with larger pauses
between them.
DTMF tones may also be used for text telephony. This application is
documented in ITU-T Recommendation V.18 [27] Annex B. In this case,
DTMF is sent alternately from either end (half-duplex mode), with a
minimum 300-ms turn-around time. The only constraints on tone
durations in this application are that they and the pauses between
them must exceed specified minimum values. It is RECOMMENDED that a
gateway at the sending end be capable of detecting DTMF signals as
specified by V.18 Annex B (tones and pauses >=40 ms), but should send
event durations corresponding to those of a V.18 DTMF sender (tones >=70 ms, pauses >=50 ms). This may occasionally imply some degree of buffering of outgoing events, but if the source terminal conforms to V.18 Annex B, this should not get out of hand. Since minor increases in tone duration are harmless for all applications of DTMF, but unintended breaks in playout of a DTMF digit can confuse the receiving endpoint by creating the appearance of extra digits, receiving applications that are converting DTMF events back to tones SHOULD use the second playout algorithm rather than the first one in Section 2.5.2.2. This provides some robustness against packet loss or congestion.3.2. DTMF Events
Table 3 shows the DTMF-related event codes within the telephone-event payload format. The DTMF digits 0-9 and * and # are commonly supported. DTMF digits A through D are less frequently encountered, typically in special applications such as military networks. +-------+--------+------+---------+ | Event | Code | Type | Volume? | +-------+--------+------+---------+ | 0--9 | 0--9 | tone | yes | | * | 10 | tone | yes | | # | 11 | tone | yes | | A--D | 12--15 | tone | yes | +-------+--------+------+---------+ Table 3: DTMF Named Events3.3. Congestion Considerations
The key considerations for the delivery of DTMF events are reliability and avoidance of unintended breaks within the playout of a given tone. End-to-end round-trip delay is not a major consideration except in the special case where DTMF tones are being used for text telephony. Assuming that, as recommended in Section 3.1 above, the second playout algorithm of Section 2.5.2.2 is in use, a temporary increase in packetization interval to as much as 100 ms or double the normal interval, whichever is less, should be harmless.
4. RTP Payload Format for Telephony Tones
4.1. Introduction
As an alternative to describing tones and events by name, as described in Section 2, it is sometimes preferable to describe them by their waveform properties. In particular, recognition is faster than for naming signals since it does not depend on recognizing durations or pauses. There is no single international standard for telephone tones such as dial tone, ringing (ringback), busy, congestion ("fast-busy"), special announcement tones, or some of the other special tones, such as payphone recognition, call waiting or record tone. However, ITU-T Recommendation E.180 [18] notes that across all countries, these tones share a number of characteristics: o Telephony tones consist of either a single tone, the addition of two or three tones or the modulation of two tones. (Almost all tones use two frequencies; only the Hungarian "special dial tone" has three.) Tones that are mixed have the same amplitude and do not decay. o In-band tones for telephony events are in the range of 25 Hz (ringing tone in Angola) to 2600 Hz (the tone used for line signalling in SS No. 5 and R1). The in-band telephone frequency range is limited to 3400 Hz. R2 defines a 3825 Hz out-of-band tone for line signalling on analogue trunks. (The piano has a range from 27.5 to 4186 Hz.) o Modulation frequencies range between 15 (ANSam tone) to 480 Hz (Jamaica). Non-integer frequencies are used only for frequencies of 16 2/3 and 33 1/3 Hz. o Tones that are not continuous have durations of less than four seconds. o ITU Recommendation E.180 [18] notes that different telephone companies require a tone accuracy of between 0.5 and 1.5%. The Recommendation suggests a frequency tolerance of 1%.
4.2. Examples of Common Telephone Tone Signals
As an aid to the implementor, Table 4 summarizes some common tones. The rows labeled "ITU ..." refer to ITU-T Recommendation E.180 [18]. In these rows, the on and off durations are suggested ranges within which local standards would set specific values. The symbol "+" in the table indicates addition of the tones, without modulation, while "*" indicates amplitude modulation. +-------------------------+-------------------+----------+----------+ | Tone Name | Frequency | On Time | Off Time | | | | (s) | (s) | +-------------------------+-------------------+----------+----------+ | 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 bit | 980 or 1180 or | 0.00333 | -- | | | 1650 or 1850 | | | | ------------- | ---------- | -------- | -------- | | 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 | 0.1-0.6 | 0.1-0.7 | | U.S. busy tone | 480+620 | 0.5 | 0.5 | | ITU congestion tone | 425 | 0.1-0.6 | 0.1-0.7 | | U.S. congestion tone | 480+620 | 0.25 | 0.25 | +-------------------------+-------------------+----------+----------+ Table 4: Examples of Telephony Tones4.3. Use of RTP Header Fields
4.3.1. Timestamp
The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 4.3.3 begins at that time.4.3.2. Marker Bit
The tone payload type uses the marker bit to distinguish the first RTP packet reporting a given instance of a tone from succeeding packets for that tone. The marker bit SHOULD be set to 1 for the first packet, and to 0 for all succeeding packets relating to the same tone.
4.3.3. 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 media type is "audio/tone".) The default timestamp rate is 8000 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 have a static payload type number, but uses an RTP payload type number established dynamically and out-of-band. The payload format is shown in Figure 2. 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 |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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Payload Format for Tones The payload contains the following fields: modulation: The modulation frequency, in Hz. The field is a 9-bit unsigned integer, allowing modulation frequencies up to 511 Hz. If there is no modulation, this field has a value of zero. Note that the amplitude of modulation is not indicated in the payload and must be determined by out-of-band means. 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 dropping the
sign, with range from 0 to -63 dBm0. (Note: A preferred level
range for digital tone generators is -8 dBm0 to -3 dBm0.)
duration:
The duration of the tone, measured in timestamp units and
presented in network byte order. The tone begins at the instant
identified by the RTP timestamp and lasts for the duration value.
The value of zero is not permitted, and tones with such a duration
SHOULD be ignored.
The definition of duration corresponds to that for sample-based
codecs, where the timestamp represents the sampling point for the
first sample.
frequency:
The frequencies of the tones to be added, measured in Hz and
represented as a 12-bit unsigned integer. The field size is
sufficient to represent frequencies up to 4095 Hz, which exceeds
the range of telephone systems. A value of zero indicates
silence. A single tone can contain any number of frequencies. If
no frequencies are specified, the packet reports a period of
silence.
R:
This field is reserved for future use. The sender MUST set it to
zero, and the receiver MUST ignore it.
4.3.4. Optional Media Type Parameters
The "rate" parameter describes the sampling rate, in Hertz. The
number is written as an integer. If omitted, the default value is
8000 Hz.
4.4. Procedures
This section defines the procedures associated with the tone payload
type.
4.4.1. Sending Procedures
The sender MAY send an initial tones packet as soon as a tone is
recognized, or MAY wait until a pre-negotiated packetization period
has elapsed. The first RTP packet for a tone SHOULD have the marker
bit set to 1.
In the case of longer-duration tones, the sender SHOULD generate multiple RTP packets for the same tone instance. The RTP timestamp MUST be updated for each packet generated (in contrast, for instance, to the timestamp for packets carrying telephone events). Subsequent packets for the same tone SHOULD have the marker bit set to 0, and the RTP timestamp in each subsequent packet MUST equal the sum of the timestamp and the duration in the preceding packet. A final RTP packet MAY be generated as soon as the end of the tone is detected, without waiting for the latest packetization period to elapse. The telephone-event payload described in Section 2 is inherently redundant, in that later packets for the same event carry all of the earlier history of the event except for variations in volume. In contrast, each packet for the tone payload type stands alone; a lost packet means a gap in the information available at the receiving end. Thus, for increased reliability, the sender SHOULD combine new and old tone reports in the same RTP packet using RFC 2198 [2] audio redundancy.4.4.2. Receiving Procedures
Receiving implementations play out the tones as received, typically with a playout delay to allow for lost packets. When playing out successive tone reports for the same tone (marker bit is zero, the RTP timestamp is contiguous with that of the previous RTP packet, and payload content is identical), the receiving implementation SHOULD continue the tone without change or a break.4.4.3. Handling of Congestion
If the sender determines that packets are being lost due to congestion (e.g., through RTCP receiver reports), it SHOULD increase the packetization interval for initial and interim tone reports so as to reduce traffic volume to the receiver. The degree to which this is possible without causing damaging consequences at the receiving end depends both upon the playout delay used at that end and upon the specific application associated with the tones. Both the maximum packetization interval and maximum increase in packetization interval at any one time are therefore a matter of configuration or out-of- band negotiation.
5. Examples
Consider a DTMF dialling sequence, where the user dials the digits "911" and a sending gateway detects them. The first digit is 200 ms long (1600 timestamp units) and starts at time 0; the second digit lasts 250 ms (2000 timestamp units) and starts at time 880 ms (7040 timestamp units); the third digit is pressed at time 1.4 s (11,200 timestamp units) and lasts 220 ms (1760 timestamp units). The frame duration is 50 ms. Table 5 shows the complete sequence of events assuming that only the telephone-event payload type is being reported. For simplicity: the timestamp is assumed to begin at 0, the RTP sequence number at 1, and volume settings are omitted. +-------+-----------+------+--------+------+--------+--------+------+ | Time | Event | M | Time- | Seq | Event | Dura- | E | | (ms) | | bit | stamp | No | Code | tion | bit | +-------+-----------+------+--------+------+--------+--------+------+ | 0 | "9" | | | | | | | | | starts | | | | | | | | 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" | | | packet 1 | | | | | | | | | sent | | | | | | | | 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" | | | packet 2 | | | | | | | | | sent | | | | | | | | 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" | | | packet 3 | | | | | | | | | sent | | | | | | | | 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" | | | packet 4 | | | | | | | | | sent | | | | | | | | 200 | "9" ends | | | | | | | | 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" | | | packet 4 | | | | | | | | | first | | | | | | | | | retrans- | | | | | | | | | mission | | | | | | | | 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" | | | packet 4 | | | | | | | | | second | | | | | | | | | retrans- | | | | | | | | | mission | | | | | | | | 880 | First "1" | | | | | | | | | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 7 | 1 | 400 | "0" | | | packet 5 | | | | | | | | | sent | | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1130 | RTP | "0" | 7040 | 11 | 1 | 2000 | "0" | | | packet 9 | | | | | | | | | sent | | | | | | | | 1130 | First "1" | | | | | | | | | ends | | | | | | | | 1180 | RTP | "0" | 7040 | 12 | 1 | 2000 | "1" | | | packet 9 | | | | | | | | | first | | | | | | | | | retrans- | | | | | | | | | mission | | | | | | | | 1230 | RTP | "0" | 7040 | 13 | 1 | 2000 | "1" | | | packet 9 | | | | | | | | | second | | | | | | | | | retrans- | | | | | | | | | mission | | | | | | | | 1400 | Second | | | | | | | | | "1" | | | | | | | | | starts | | | | | | | | 1450 | RTP | "1" | 11200 | 14 | 1 | 400 | "0" | | | packet 10 | | | | | | | | | sent | | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1620 | Second | | | | | | | | | "1" ends | | | | | | | | 1650 | RTP | "0" | 11200 | 18 | 1 | 1760 | "1" | | | packet 14 | | | | | | | | | sent | | | | | | | | 1700 | RTP | "0" | 11200 | 19 | 1 | 1760 | "1" | | | packet 14 | | | | | | | | | first | | | | | | | | | retrans- | | | | | | | | | mission | | | | | | | | 1750 | RTP | "0" | 11200 | 20 | 1 | 1760 | "1" | | | packet 14 | | | | | | | | | second | | | | | | | | | retrans- | | | | | | | | | mission | | | | | | | +-------+-----------+------+--------+------+--------+--------+------+ Table 5: Example of Event Reporting
Table 6 shows the same sequence assuming that only the tone payload type is being reported. This looks somewhat different. For simplicity: the timestamp is assumed to begin at 0, the sequence number at 1. Volume, the T bit, and the modulation frequency are omitted. The latter two are always 0. +-------+-----------+-----+--------+------+--------+-------+--------+ | Time | Event | M | Time- | Seq | Dura- | Freq 1| Freq 2 | | (ms) | | bit | stamp | No | tion | (Hz) | (Hz) | +-------+-----------+-----+--------+------+--------+-------+--------+ | 0 | "9" | | | | | | | | | starts | | | | | | | | 50 | RTP | "1" | 0 | 1 | 400 | 852 | 1477 | | | packet 1 | | | | | | | | | sent | | | | | | | | 100 | RTP | "0" | 400 | 2 | 400 | 852 | 1477 | | | packet 2 | | | | | | | | | sent | | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 200 | RTP | "0" | 1200 | 4 | 400 | 852 | 1477 | | | packet 4 | | | | | | | | | sent | | | | | | | | 200 | "9" ends | | | | | | | | 880 | First "1" | | | | | | | | | starts | | | | | | | | 930 | RTP | "1" | 7040 | 5 | 400 | 697 | 1209 | | | packet 5 | | | | | | | | | sent | | | | | | | | 980 | RTP | "0" | 7440 | 6 | 400 | 697 | 1209 | | | packet 6 | | | | | | | | | sent | | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1130 | First "1" | | | | | | | | | ends | | | | | | | | 1400 | Second | | | | | | | | | "1" | | | | | | | | | starts | | | | | | | | 1450 | RTP | "1" | 11200 | 10 | 400 | 697 | 1209 | | | packet 10 | | | | | | | | | sent | | | | | | | | ... | ... | ... | ... | ... | ... | ... | ... | | 1620 | Second | | | | | | | | | "1" ends | | | | | | | | 1650 | RTP | "0" | 12800 | 14 | 160 | 697 | 1209 | | | packet 14 | | | | | | | | | sent | | | | | | | +-------+-----------+-----+--------+------+--------+-------+--------+ Table 6: Example of Tone Reporting
Now consider a combined payload, where the tone payload is the primary payload type and the event payload is treated as a redundant encoding (one level of redundancy). Because the primary payload is tones, the tone payload rules determine the setting of the RTP header fields. This means that the RTP timestamp always advances. As a corollary, the timestamp offset for the events payload in the RFC 2198 header increases by the same amount. One issue that has to be considered in a combined payload is how to handle retransmissions of final event reports. The tone payload specification does not recommend retransmissions of final packets, so it is unclear what to put in the primary payload fields of the combined packet. In the interests of simplicity, it is suggested that the retransmitted packets copy the fields relating to the primary payload (including the RTP timestamp) from the original packet. The same principle can be applied if the packet includes multiple levels of event payload redundancy. The figures below all illustrate "RTP packet 14" in the above tables. Figure 3 shows an event-only payload, corresponding to Table 5. Figure 4 shows a tone-only payload, corresponding to Table 6. Finally, Figure 5 shows a combined payload, with tones primary and events as a single redundant layer. Note that the combined payload has the RTP sequence numbers shown in Table 5, because the transmitted sequence includes the retransmitted packets. Figure 3 assumes that the following SDP specification was used. This session description provides for separate streams of G.729 [21] audio and events. Packets reported within the G.729 stream are not considered here. m=audio 12344 RTP/AVP 99 a=rtpmap:99 G729/8000 a=ptime:20 m=audio 12346 RTP/AVP 100 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 a=ptime:50
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| 100 | 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 11200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | | 0x5234a8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E R| volume | duration | | 1 |1 0| 20 | 1760 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Example RTP Packet for Event Payload Figure 4 assumes that an SDP specification similar to that of the previous case was used. m=audio 12344 RTP/AVP 99 a=rtpmap:99 G729/8000 a=ptime:20 m=audio 12346 RTP/AVP 101 a=rtpmap:101 tone/8000 a=ptime:50 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| 101 | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 12800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | | 0x5234a8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulation |T| volume | duration | | 0 |0| 20 | 160 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| frequency |R R R R| frequency | |0 0 0 0| 697 |0 0 0 0| 1209 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Example RTP Packet for Tone Payload
Figure 5, for the combined payload, assumes the following SDP session description: m=audio 12344 RTP/AVP 99 a=rtpmap:99 G729/8000 a=ptime:20 m=audio 12346 RTP/AVP 102 101 100 a=rtpmap:102 red/8000/1 a=fmtp:102 101/100 a=rtpmap:101 tone/8000 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 a=ptime:50 For ease of presentation, Figure 5 presents the actual payloads as if they began on 32-bit boundaries. In the actual packet, they follow immediately after the end of the RFC 2198 header, and thus are displaced one octet into successive words.
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| 102 | 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 12800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | | 0x5234a8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | |1| 100 | 1600 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | event payload begins ... / |0| 101 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Event payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E R| volume | duration | | 1 |1 0| 20 | 1760 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tone payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulation |T| volume | duration | | 0 |0| 20 | 160 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| frequency |R R R R| frequency | |0 0 0 0| 697 |0 0 0 0| 1209 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Example RTP Packet for Combined Tone and Event Payloads
6. Security Considerations
RTP packets using the payload formats defined in this specification are subject to the security considerations discussed in the RTP specification (RFC 3550 [5]), and any appropriate RTP profile (for example, RFC 3551 [13]). The RFC 3550 discussion focuses on requirements for confidentiality. Additional security considerations relating to implementation are described in RFC 2198 [2]. The telephone-event payload defined in this specification is highly compressed. A change in value of just one bit can result in a major change in meaning as decoded at the receiver. Thus, message integrity MUST be provided for the telephone-event payload type. To meet the need for protection both of confidentiality and integrity, compliant implementations SHOULD implement the Secure Real-time Transport Protocol (SRTP) [7]. Note that the appropriate method of key distribution for SRTP may vary with the specific application. In some deployments, it may be preferable to use other means to provide protection equivalent to that provided by SRTP. Provided that gateway design includes robust, low-overhead tone generation, this payload type does not exhibit any significant non- uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.7. IANA Considerations
This document updates the descriptions of two RTP payload formats, 'telephone-event' and 'tone', and associated Internet media types, audio/telephone-event and audio/tone. It also documents the event codes for DTMF tone events. Within the audio/telephone-event type, events MUST be registered with IANA. Registrations are subject to the policies "Specification Required" and "Expert Review" as defined in RFC 2434 [3]. The IETF- appointed expert must ensure that: a. the meaning and application of the proposed events are clearly documented; b. the events cannot be represented by existing event codes, possibly with some minor modification of event definitions;
c. the number of events is the minimum necessary to fulfill the
purpose of their application(s).
The expert is further responsible for providing guidance on the
allocation of event codes to the proposed events. Specifically, the
expert must indicate whether the event appears to be the same as one
defined in RFC 2833 but not specified in any new document. In this
case, the event code specified in RFC 2833 for that event SHOULD be
assigned to the proposed event. Otherwise, event codes MUST be
assigned from the set of available event codes listed below. If this
set is exhausted, the criterion for assignment from the reserved set
of event codes is to first assign those that appear to have the
lowest probability of being revived in their RFC 2833 meaning in a
new specification.
The documentation for each event MUST indicate whether the event is a
state, tone, or other type of event (e.g., an out-of-band electrical
event such as on-hook or an indication that will not itself be played
out as tones at the receiving end). For tone events, the
documentation MUST indicate whether the volume field is applicable or
must be set to 0.
In view of the tradeoffs between the different reliability mechanisms
discussed in Section 2.6, documentation of specific events SHOULD
include a discussion of the appropriate design decisions for the
applications of those events.
Legal event codes range from 0 to 255. The initial registry content
is shown in Table 7, and consists of the sixteen events defined in
Section 3 of this document. The remaining codes have the following
disposition:
o codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available
for assignment;
o codes 23-40, 49, and 52-63 are reserved for events defined in
[16];
o codes 121-137 and 174-205 are reserved for events defined in [17];
o codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved
in the first instance for specifications reviving the
corresponding RFC 2833 events, and in the second instance for
general assignment after all other codes have been assigned.
+------------+--------------------------------+-----------+ | Event Code | Event Name | Reference | +------------+--------------------------------+-----------+ | 0 | DTMF digit "0" | RFC 4733 | | 1 | DTMF digit "1" | RFC 4733 | | 2 | DTMF digit "2" | RFC 4733 | | 3 | DTMF digit "3" | RFC 4733 | | 4 | DTMF digit "4" | RFC 4733 | | 5 | DTMF digit "5" | RFC 4733 | | 6 | DTMF digit "6" | RFC 4733 | | 7 | DTMF digit "7" | RFC 4733 | | 8 | DTMF digit "8" | RFC 4733 | | 9 | DTMF digit "9" | RFC 4733 | | 10 | DTMF digit "*" | RFC 4733 | | 11 | DTMF digit "#" | RFC 4733 | | 12 | DTMF digit "A" | RFC 4733 | | 13 | DTMF digit "B" | RFC 4733 | | 14 | DTMF digit "C" | RFC 4733 | | 15 | DTMF digit "D" | RFC 4733 | +------------+--------------------------------+-----------+ Table 7: audio/telephone-event Event Code Registry7.1. Media Type Registrations
7.1.1. Registration of Media Type audio/telephone-event
This registration is done in accordance with [6] and [8]. Type name: audio Subtype name: telephone-event Required parameters: none. Optional parameters: The "events" parameter lists the events supported by the implementation. Events are listed as one or more comma-separated elements. Each element can be either a single integer providing the value of an event code or an integer followed by a hyphen and a larger integer, presenting a range of consecutive event code values. The list does not have to be sorted. No white space is allowed in the argument. The union of all of the individual event codes and event code ranges designates the complete set of event numbers supported by the implementation. If the "events" parameter is omitted, support for events 0-15 (the DTMF tones) is assumed.
The "rate" parameter describes the sampling rate, in Hertz. The
number is written as an integer. If omitted, the default value is
8000 Hz.
Encoding considerations:
In the terminology defined by [8] section 4.8, this type is framed
and binary.
Security considerations:
See Section 6, "Security Considerations", in this document.
Interoperability considerations: none.
Published specification: this document.
Applications which use this media:
The telephone-event audio subtype supports the transport of events
occurring in telephone systems over the Internet.
Additional information:
Magic number(s): N/A.
File extension(s): N/A.
Macintosh file type code(s): N/A.
Person & email address to contact for further information:
Tom Taylor, taylor@nortel.com.
IETF AVT Working Group.
Intended usage: COMMON.
Restrictions on usage:
This type is defined only for transfer via RTP [5].
Author: IETF Audio/Video Transport Working Group.
Change controller:
IETF Audio/Video Transport Working Group as delegated from the
IESG.
7.1.2. Registration of Media Type audio/tone
This registration is done in accordance with [6] and [8]. Type name: audio Subtype name: tone Required parameters: none Optional parameters: The "rate" parameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz. Encoding considerations: In the terminology defined by [8] section 4.8, this type is framed and binary. Security considerations: See Section 6, "Security Considerations", in this document. Interoperability considerations: none Published specification: this document. Applications which use this media: The tone audio subtype supports the transport of pure composite tones, for example, those commonly used in the current telephone system to signal call progress. Additional information: Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A. Person & email address to contact for further information: Tom Taylor, taylor@nortel.com. IETF AVT Working Group. Intended usage: COMMON.
Restrictions on usage:
This type is defined only for transfer via RTP [5].
Author: IETF Audio/Video Transport Working Group.
Change controller:
IETF Audio/Video Transport Working Group as delegated from the
IESG.
8. Acknowledgements
Scott Petrack was the original author of RFC 2833. Henning
Schulzrinne later loaned his expertise to complete the document, but
Scott must be credited with the energy behind the idea of a compact
encoding of tones over IP.
In RFC 2833, the suggestions of the Megaco working group were
acknowledged. Colin Perkins and Magnus Westerland, Chairs of the AVT
Working Group, provided helpful advice in the formation of the
present document. Over the years, detailed advice and comments for
RFC 2833, this document, or both were provided by Hisham Abdelhamid,
Flemming Andreasen, Fred Burg, Steve Casner, Dan Deliberato, Fatih
Erdin, Bill Foster, Mike Fox, Mehryar Garakani, Gunnar Hellstrom,
Rajesh Kumar, Terry Lyons, Steve Magnell, Zarko Markov, Tim
Melanchuk, Kai Miao, Satish Mundra, Kevin Noll, Vern Paxson, Oren
Peleg, Raghavendra Prabhu, Moshe Samoha, Todd Sherer, Adrian Soncodi,
Yaakov Stein, Mira Stevanovic, Alex Urquizo, and Herb Wildfeur.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC 2198, September 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [6] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. [7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [10] International Telecommunication Union, "Technical features of push-button telephone sets", ITU-T Recommendation Q.23, November 1988. [11] International Telecommunication Union, "Multifrequency push- button signal reception", ITU-T Recommendation Q.24, November 1988.9.2. Informative References
[12] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [14] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005. [15] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. [16] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006. [17] Schulzrinne, H. and T. Taylor, "Definition of Events For Channel-Oriented Telephony Signalling", Work In Progress , November 2005.
[18] International Telecommunication Union, "Technical characteristics of tones for the telephone service", ITU-T Recommendation E.180/Q.35, March 1998. [19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988. [20] International Telecommunication Union, "Speech coders : Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996. [21] International Telecommunication Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear- prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. [22] International Telecommunication Union, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1998. [23] International Telecommunication Union, "Procedures for real- time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003. [24] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network", ITU-T Recommendation V.8, November 2000. [25] International Telecommunication Union, "Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs", ITU-T Recommendation V.150.1, January 2003. [26] International Telecommunication Union, "Procedures for supporting Voice-Band Data over IP Networks", ITU-T Recommendation V.152, January 2005. [27] International Telecommunication Union, "Operational and interworking requirements for {DCEs operating in the text telephone mode", ITU-T Recommendation V.18, November 2000. See also Recommendation V.18 Amendment 1, Nov. 2002. [28] VOIP Troubleshooter LLC, "Indepth: Packet Loss Burstiness", 2005, <http://www.voiptroubleshooter.com/indepth/burstloss.html>.
Appendix A. Summary of Changes from RFC 2833
The memo has been significantly restructured, incorporating a large number of clarifications to the specification. With the exception of those items noted below, the changes to the memo are intended to be backwards-compatible clarifications. However, due to inconsistencies and unclear definitions in RFC 2833 [12] it is likely that some implementations interpreted that memo in ways that differ from this version. RFC 2833 required that all implementations be capable of receiving the DTMF events (event codes 0-15). Section 2.5.1.1 of the present document requires that a sender transmit only the events that the receiver is capable of receiving. In the absence of a knowledge of receiver capabilities, the sender SHOULD assume support of the DTMF events but of no other events. The sender SHOULD indicate what events it can send. Section 2.5.2.1 requires that a receiver signalling its capabilities using SDP MUST indicate which events it can receive. Non-zero values in the volume field of the payload were applicable only to DTMF tones in RFC 2833, and for other events the receiver was required to ignore them. The present memo requires that the definition of each event indicate whether the volume field is applicable to that event. The last paragraph of Section 2.5.2.2 indicates what a receiver may do if it receives volumes with zero values for events to which the volume field is applicable. Along with the RFC 2833 receiver rule, this ensures backward compatibility in both directions of transmission. Section 2.5.1.3 and Section 2.5.2.3 introduce a new procedure for reporting and playing out events whose duration exceeds the capacity of the payload duration field. This procedure may cause momentary confusion at an old (RFC 2833) receiver, because the timestamp is updated without setting the E bit of the preceding event report and without setting the M bit of the new one. Section 2.5.1.5 and Section 2.5.2.4 introduce a new procedure whereby a sequence of short-duration events may be packed into a single event report. If an old (RFC 2833) receiver receives such a report, it may discard the packet as invalid, since the packet holds more content than the receiver was expecting. In any event, the additional events in the packet will be lost.
Section 2.3.5 introduces the possibility of "state" events and defines procedures for setting the duration field for reports of such events. Section 2.5.1.2 defines special exemptions from the setting of the E bit for state events. Three more sections mention procedures related to these events. The Security Considerations section is updated to mention the requirement for protection of integrity. More importantly, it makes implementation of SRTP [7] mandatory for compliant implementations, without specifying a mandatory-to-implement method of key distribution. Finally, this document establishes an IANA registry for event codes and establishes criteria for their documentation. This document provides an initial population for the new registry, consisting solely of the sixteen DTMF events. Two companion documents [16] and [17] describe events related to modems, fax, and text telephony and to channel-associated telephony signalling, respectively. Some changes were made to the latter because of errors and redundancies in the RFC 2833 assignments. The remaining events defined in RFC 2833 are deprecated because they do not appear to have been implemented, but their codes have been conditionally reserved in case any of them is needed in the future. Table 8 indicates the disposition of the event codes in detail. Event codes not mentioned in this table were not allocated by RFC 2833 and continue to be unused. +-------------+---------------------------------------+-------------+ | Event Codes | RFC 2833 Description | Disposition | +-------------+---------------------------------------+-------------+ | 0-15 | DTMF digits | RFC 4733 | | 16 | Line flash (deprecated) | Reserved | | 23-31 | Unused | [16] | | 32-40 | Data and fax | [16] | | 41-48 | Data and fax (V.8bis, deprecated) | Reserved | | 52-63 | Unused | [16] | | 64-89 | E.182 line events (deprecated) | Reserved | | 96-112 | Country-specific line events | Reserved | | | (deprecated) | | | 121-127 | Unused | [17] | | 128-137 | Trunks: MF 0-9 | [17] | | 138-143 | Trunks: other MF (deprecated) | Reserved | | 144-159 | Trunks: ABCD signalling | [17] | | 160-168 | Trunks: various (deprecated) | Reserved | | 170-173 | Trunks: various (deprecated) | Reserved | | 174-205 | Unused | [17] | +-------------+---------------------------------------+-------------+ Table 8: Disposition of RFC 2833-defined Event Codes
Authors' Addresses
Henning Schulzrinne Columbia U. Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 US EMail: schulzrinne@cs.columbia.edu Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada EMail: taylor@nortel.com
Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.