idnits 2.17.1 draft-ietf-avt-dtmf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 54: '...rt of the audio stream, and SHOULD use...' RFC 2119 keyword, line 69: '... A source MAY send coded DTMF and co...' RFC 2119 keyword, line 71: '... stream, or it MAY block outgoing au...' RFC 2119 keyword, line 114: '... future use. The sender MUST set it to...' RFC 2119 keyword, line 115: '... zero, the receiver MUST ignore it....' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 85 has weird spacing: '...F digit enc...' == Line 235 has weird spacing: '...o frame inter...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 18, 1998) is 9284 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 245 looks like a reference -- Missing reference section? '2' on line 249 looks like a reference -- Missing reference section? '3' on line 253 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force AVT WG 3 Internet Draft Schulzrinne 4 ietf-avt-dtmf-01.txt Columbia U. 5 November 18, 1998 6 Expires: May 15, 1999 8 RTP Payload for DTMF Digits 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 This memo describes how to carry dual-tone multifrequency 33 (DTMF) signaling and other tone signals in RTP packets. 35 1 Introduction 37 This memo defines a payload type for carrying dual-tone 38 multifrequency (DTMF) digits in RTP packets. A separate payload type 39 is desirable since low-rate voice codecs cannot be guaranteed to 40 accurately reproduce DTMF. Defining a separate payload type also 41 permits higher redundancy while maintaining a low bit rate. 43 The DTMF payload type must be suitable for both a gateway and end- 44 to-end scenario. In the gateway scenario, a gateway connecting a 45 packet voice network with the PSTN recreates the DTMF tones and 46 injects them into the PSTN. Since DTMF digit recognition takes 47 several tens of milliseconds, careful time and power (volume) 48 alignment is needed to avoid generating spurious digits. For 49 interactive voice response (IVR) systems directly connected to the 50 packet voice network, time alignment and volume levels are not 51 important, since the unit will not perform any signal analysis to 52 detect DTMF tones from the audio stream. 54 DTMF digits are carried as part of the audio stream, and SHOULD use 55 the same sequence number and time-stamp base as the regular audio 56 channel to simplify recreation of analog audio at a gateway. The 57 default clock frequency is 8000 Hz, but the clock frequency can be 58 redefined when assigning the dynamic payload type. 60 This format achieves a higher redundancy even in the case of 61 sustained packet loss than the method proposed for the Voice over 62 Frame Relay Implementation Agreement [1]. 64 In circumstances where exact timing alignment between the audio 65 stream and the DTMF digits is not important and data is sent unicast, 66 such as the IVR example mentioned earlier, it may be preferable to 67 use a reliable control stream such as H.245. 69 A source MAY send coded DTMF and coded audio packets for the same 70 time instants, using DTMF as the redundant encoding for the audio 71 stream, or it MAY block outgoing audio while DTMF tones are active 72 and only send DTMF digits as both the primary and redundant 73 encodings. 75 2 Payload Format 77 0 1 2 3 78 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 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 |R R R| digit |R R| volume | duration | 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 digit: The DTMF digits are encoded as follows: 85 DTMF digit encoding (decimal) 86 ________________________________ 87 0 0 88 1 1 89 2 2 90 9 9 91 * 10 92 # 11 93 A 12 94 B 13 95 C 14 96 D 15 97 Flash 16 99 volume: The power level of the digit, expressed in dBm0 after 100 dropping the sign, with range from 0 to -63 dBm0. The range of 101 valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 102 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger 103 values denote lower volume. 105 Note: since the acceptable dip is 10 dB and the minimum detectable 106 loudness variation is 3 dB, this field could be compressed by at 107 least a bit by reducing resolution to 2 dB, if needed. 109 duration: Duration of this digit, in timestamp units. 111 For a sampling rate of 8000 Hz, this field is sufficient to 112 express digit durations of upto approximately 8 seconds. 114 R: This field is reserved for future use. The sender MUST set it to 115 zero, the receiver MUST ignore it. 117 An audio source SHOULD start transmitting DTMF digit packets as soon 118 as it recognizes a DTMF digit and every 50 ms thereafter. (Precise 119 spacing between DTMF digit packets is not necessary.) 121 Q.24 [2], Table A-1, indicates that all administrations 122 surveyed use a minimum signal duration of 40 ms, with 123 signaling velocity (tone and pause) of no less than 93 ms. 125 If a digit continues for more than one period, it should send a new 126 DTMF packet with the RTP timestamp value corresponding to the 127 beginning of the digit and the duration of the digit increased 128 correspondingly. (The RTP sequence number is incremented by one for 129 each packet.) If there has been no new digit in the last interval, 130 the digit SHOULD be retransmitted three times (or until the next 131 digit is recognized) to ensure some measure of reliability for the 132 last digit. 134 DTMF digits are sent incrementally to avoid having the 135 receiver wait for the completion of the digit. Since some 136 tones are two seconds long, this would incur a substantial 137 delay. The transmitter does not know if digit length is 138 important and thus needs to transmit immediately and 139 incrementally. If the receiver application does not care 140 about digit length, the incremental transmission mechanism 141 avoids delay. Some applications, such as gateways into the 142 GSTN, care about both delays and digit duration. 144 3 Reliability 146 To achieve reliability even when the network loses packets, the audio 147 redundancy mechanism described in RFC 2198 [3] is used. The effective 148 data rate is r times 64 bits (32 bits for the redundancy header and 149 32 bits for the DTMF payload) every 50 ms or r times 1280 150 bits/second, where r is the number of redundant DTMF digits carried 151 in each packet. The value of r is an implementation trade-off, with a 152 value of 5 suggested. 154 The timestamp offset in this redundancy scheme has 14 bits, 155 so that it allows a single packet to "cover" 2.048 seconds 156 of DTMF digits at a sampling rate of 8000 Hz. Including the 157 starting time of previous digits allows precise 158 reconstruction of the tone sequence at a gateway. The 159 scheme is resilient to consecutive packet losses spanning 160 this interval of 2.048 seconds or r digits, whichever is 161 less. Note that for previous digits, only an average 162 loudness can be represented. 164 An encoder MAY treat the DTMF payload as a highly-compressed version 165 of the current audio frame. In that mode, each RTP packet during a 166 DTMF tone would contain the current audio codec rendition (say, 167 G.723.1 or G.729) of this digit as well as the representation 168 described in Section 2, plus any previous digits as before. 170 This approach allows dumb gateways that do not understand 171 this format to function. Other reasons? 173 3.1 Example 175 A typical RTP packet, where the user is just dialing the last digit 176 of the DTMF sequence "911". The first digit was 200 ms long and 177 started at time 0, the second digit lasted 250 ms and started at time 178 800 ms, the third digit was pressed at time 1.4 s and the packet 179 shown was sent at 1.45 s. The frame duration is 50 ms. To make the 180 parts recognizable, the figure below ignores byte alignment. 181 Timestamp and sequence number are assumed to have been zero at the 182 beginning of the first digit. In this example, the dynamic payload 183 types 96 and 97 have been assigned for the redundancy mechanism and 184 the DTMF payload, respectively. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |V=2|P|X| CC |M| PT | sequence number | 190 | 2 |0|0| 0 |0| 96 | 28 | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | timestamp | 193 | 12000 | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | synchronization source (SSRC) identifier | 196 | 0x5234a8 | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |F| block PT | timestamp offset | block length | 199 |1| 97 | 12000 | 4 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |F| block PT | timestamp offset | block length | 202 |1| 97 | 5600 | 4 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |F| Block PT | 205 |0| 97 | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |R R R| digit |R R| volume | duration | 208 |0 0 0| 9 |0 0| 7 | 1600 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 |R R R| digit |R R| volume | duration | 211 |0 0 0| 1 |0 0| 10 | 2000 | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |R R R| digit |R R| volume | duration | 214 |0 0 0| 1 |0 0| 20 | 400 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 4 Compact Reliability Scheme 219 A more compact representation could be achieved by measuring DTMF 220 tones in a different sampling rate from that of the surrounding audio 221 codec, e.g., as multiples of 1, 10, 40 or 50 ms. Each RTP payload 222 type should have a fixed sampling rate, so choosing a value that 223 depends on frame interval of the surrounding codec is not 224 recommended. For a sampling interval of 50 ms, the following payload 225 would "cover" 8 seconds of duration and offset: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | offset |R R R| digit |R R| volume | duration | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 5 Changes Since Version -00 235 o Uniform interval of 50 ms, since audio frame interval may 236 change based on codec. 238 6 Acknowledgements 240 The suggestions of the VoIP working group and Fred Burg are 241 gratefully acknowledged. 243 7 Bibliography 245 [1] R. Kocen and T. Hatala, "Voice over frame relay implementation 246 agreement," Implementation Agreement FRF.11, Frame Relay Forum, 247 Foster City, California, Jan. 1997. 249 [2] International Telecommunication Union, "Multifrequency push- 250 button signal reception," Recommendation Q.24, Telecommunication 251 Standardization Sector of ITU, Geneva, Switzerland, 1988. 253 [3] C. Perkins, I. Kouvelas, V. Hardman, M. Handley, and J. Bolot, 254 "RTP payload for redundant audio data," RFC 2198, Internet 255 Engineering Task Force, Sept. 1997.