idnits 2.17.1 draft-ietf-avt-tones-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 123: '...g events via RTP SHOULD send both name...' RFC 2119 keyword, line 128: '...one representation, it SHOULD send the...' RFC 2119 keyword, line 150: '... and SHOULD use the same sequence nu...' RFC 2119 keyword, line 164: '... A source MAY send events and coded ...' RFC 2119 keyword, line 166: '... stream, or it MAY block outgoing au...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 379 has weird spacing: '... Event encod...' == Line 784 has weird spacing: '...equency on pe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 1999) is 9066 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 961 looks like a reference -- Missing reference section? '2' on line 965 looks like a reference -- Missing reference section? '3' on line 970 looks like a reference -- Missing reference section? '4' on line 974 looks like a reference -- Missing reference section? '5' on line 978 looks like a reference -- Missing reference section? '6' on line 982 looks like a reference -- Missing reference section? '7' on line 987 looks like a reference -- Missing reference section? '8' on line 994 looks like a reference -- Missing reference section? '9' on line 999 looks like a reference -- Missing reference section? '10' on line 1003 looks like a reference -- Missing reference section? '11' on line 1009 looks like a reference -- Missing reference section? '12' on line 1017 looks like a reference -- Missing reference section? '13' on line 1022 looks like a reference -- Missing reference section? '14' on line 1026 looks like a reference -- Missing reference section? '15' on line 1031 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 Internet Draft Schulzrinne/Petrack 3 draft-ietf-avt-tones-00.txt Columbia U./MetaTel 4 June 25, 1999 5 Expires: December, 1999 7 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 29 Abstract 31 This memo describes how to carry dual-tone multifrequency (DTMF) 32 signaling, other tone signals and telephony events in RTP packets. 34 1 Introduction 36 This memo defines a payload type for carrying dual-tone 37 multifrequency (DTMF) digits and other line and trunk signals in RTP 38 [1] packets. A separate RTP payload type is desirable since low-rate 39 voice codecs cannot be guaranteed to reproduce these tone signals 40 accurately enough for automatic recognition. Defining a separate 41 payload type also permits higher redundancy while maintaining a low 42 bit rate. 44 The payload types described here may be useful in at least two 45 applications: DTMF handling for gateways and end sytems, as well as 46 "RTP trunks". In the first application, the Internet telephony 47 gateway detects DTMF on the incoming circuits and sends the RTP 48 payload described here instead of regular audio packets. The gateway 49 likely has the necessary digital signal processors and algorithms, as 50 it often needs to detect DTMF, e.g., for two-stage dialing. Having 51 the gateway detect tones relieves the receiving Internet end system 52 from having to do this work and also avoids that low bit-rate codecs 53 like G.723.1 render DTMF tones unintelligible. Similarly, an Internet 54 end system such as an "Internet phone" can emulate DTMF functionality 55 without concerning itself with generating precise tone pairs. 57 In the "RTP trunk" application, RTP is used to replace a normal 58 circuit-switched trunk between two nodes. This is particularly of 59 interest in a telephone network that is still mostly circuit- 60 switched. In this case, each end of the RTP trunk encodes audio 61 channels into the appropriate encoding, such as G.723.1 or G.729. 62 However, this encoding process destroys in-band signaling information 63 which is carried using the least-significant bit ("robbed bit 64 signaling") and may also interfere with in-band signaling tones, such 65 as the MF digit tones. In addition, tone properties such as the phase 66 reversals in the ANSam tone, will ot survive speech coding. Thus, the 67 gateway needs to remove the in-band signaling information from the 68 bit stream. It can now either carry it out-of-band in a signaling 69 transport mechanism yet to be defined, or it can use the mechanism 70 described in this memorandum. (If the two trunk end points are within 71 reach of the same media gateway controller, the media gateway 72 controller can also handle the signaling.) Carrying it in-band may 73 simplify the time synchronization between audio packets and the tone 74 or signal information. This is particularly relevant where duration 75 and timing matter, as in the carriage of DTMF signals. 77 A gateway has two options for handling DTMF digits and signals. 78 First, it can simply measure the frequency components of the voice 79 band signals and transmit this information to the RTP receiver. All 80 tone signals in use in the PSTN and meant for human consumption are 81 sequences of simple combinations of sine waves, either added or 82 modulated. (There is at least one tone, the ANSam tone [2] used for 83 indicating data transmission over voice lines, that makes use of 84 periodic phase reversals.) 86 As a second option, it can recognize the tones and translate them 87 into a name, such as ringing or busy tone. The receiver then produces 88 a tone signal or other indication appropriate to the signal. 89 Generally, since the recognition of signals often depends on their 90 on/off pattern or the sequence of several tones, this recognition can 91 take several seconds. On the other hand, the gateway may have access 92 to the actual signaling information that generates the tones and thus 93 can generate the RTP packet immediately, without the detour through 94 acoustic signals. 96 In the phone network, tones are generated at different places, 97 depending on the switching technology and the nature of the tone. 98 This determines, for example, whether a person making a call to a 99 foreign country hears her local tones she is familiar with or the 100 tones as used in the country called. 102 For analog lines, Dial tone is always generated by the local switch. 103 ISDN terminals may generate dial tone locally and then send a Q.931 104 SETUP message containing the dialed digits. If the terminal just 105 sends a SETUP message without any Called Party digits, then the 106 switch does digit collection, provided by the terminal as KEYPAD 107 messages, and provides dial tone over the B-channel. The terminal can 108 either use the audio signal on the B-channel or can use the Q.931 109 messages to trigger locally generated dial tone. 111 Ringing tone (also called ringback tone) is generated by the local 112 switch at the callee, with a one-way voice path opened up as soon as 113 the callee's phone rings. (This reduces the chance of clipping of the 114 called party's response just after answer. It also permits pre-answer 115 announcements or in-band call-progress-indications to reach the 116 caller before or in lieu of ringing tone.) Congestion tone and 117 special information tones can be generated by any of the switches 118 along the way, and may be generated by the caller's switch based on 119 ISUP messages received. Busy tone is generated by the caller's 120 switch, triggered by the appropriate ISUP message, for analog 121 instruments, or the ISDN terminal. 123 Gateways which send signalling events via RTP SHOULD send both named 124 signals (Section 2) and the tone representation (Section 4) as a 125 single RTP session, using the redundancy mechanism defined in Section 126 2.4. The receiver can then choose the appropriate rendering. 128 If a gateway cannot present a tone representation, it SHOULD send the 129 audio tones as regular RTP audio packets (e.g., as payload type 130 PCMU), in addition to the named signals. 132 2 RTP Payload Format for Named Telephone Events 134 2.1 Requirements 136 The DTMF payload type must be suitable for both gateway and end-to- 137 end scenarios. In the gateway scenario, a gateway connecting a packet 138 voice network to the PSTN recreates the DTMF tones and injects them 139 into the PSTN. Since DTMF digit recognition takes several tens of 140 milliseconds, the first few milliseconds of a digit will arrive as 141 regular audio packets. Thus, careful time and power (volume) 142 alignment is needed to avoid generating spurious digits. 144 For interactive voice response (IVR) systems directly connected to 145 the packet voice network, time alignment and volume levels are not 146 important, since the unit will not perform any signal analysis to 147 detect DTMF tones from the audio stream. 149 DTMF digits and named events are carried as part of the audio stream, 150 and SHOULD use the same sequence number and time-stamp base as the 151 regular audio channel to simplify recreation of analog audio at a 152 gateway. The default clock frequency is 8000 Hz, but the clock 153 frequency can be redefined when assigning the dynamic payload type. 155 This format achieves a higher redundancy even in the case of 156 sustained packet loss than the method proposed for the Voice over 157 Frame Relay Implementation Agreement [3]. 159 In circumstances where exact timing alignment between the audio 160 stream and the DTMF digits is not important and data is sent unicast, 161 such as the IVR example mentioned earlier, it may be preferable to 162 use a reliable control stream such as H.245. 164 A source MAY send events and coded audio packets for the same time 165 instants, using events as the redundant encoding for the audio 166 stream, or it MAY block outgoing audio while event tones are active 167 and only send named events as both the primary and redundant 168 encodings. 170 This payload definition is used by five different payload types: 172 dtmf for DTMF tones (Section 2.7); 174 fax for fax-related tones (Section 2.8); 176 line for standard subscriber line tones (Section 2.9); 178 linex for country-specific subscriber line tones (Section 3) and; 180 trunk for trunk events (Section 3.1). The payload format is 181 identical, but the payload types assigned MUST be different. 183 The separation into different payload types makes it easy 184 for end systems to declare their capabilities using session 185 description protocols such as SDP. If desired, end systems 186 can declare support of a subset of these payload types by 187 including a "fmtp" parameter listing the supported event 188 types. Details are for further study. 190 A compliant implementation MUST support the events listed in Table 1. 191 If it uses some other, out-of-band mechanism for signaling line 192 conditions, it does not have to implement the other payload types. 194 In some cases, an implementation may simply ignore certain events, 195 such as fax tones, that do not make sense in a particular 196 environment. Depending on the available user interfaces, an 197 implementation MAY render all tones in Table 5 the same or, 198 preferably, use the tones conveyed by the concurrent "tone" payload 199 or other RTP audio payload. Alternatively, it could provide a textual 200 representation. 202 Note that end systems that emulate telephones only need to support 203 the "dtmf" and "line" payload type. Systems that receive trunk 204 signaling need to implement the "dtmf", "fax", "line", and "trunk' 205 payload types, since MF trunks also carry most of the "line" signals. 206 Systems that do not support fax functionality do not need to render 207 fax-related events in the "fax" payload type. 209 The payload type distinguishes between a (line) DTMF 0 tone and a 210 (trunk) MF 0 tone. They payload type is signalled dynamically (for 211 example, within an SDP [4] or an H.245 message), or by some other 212 non-RTP means. 214 2.2 Use of RTP Header Fields 216 Timestamp: The RTP timestamp reflects the measurement point for the 217 current packet. The event duration described in Section 2.3 218 extends forwards [NOTE: was "backwards", but that's different 219 from all other payloads and disagrees with RFC 1889] from that 220 time. 222 2.3 Payload Format 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | event |R R| volume | duration | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 events: The DTMF digits and line events are encoded as shown in 231 Section 2.9; the trunk events are shown in Section 3.1. 233 volume: The power level of the digit, expressed in dBm0 after 234 dropping the sign, with range from 0 to -63 dBm0. The range of 235 valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 236 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger 237 values denote lower volume. This value is defined only for DTMF 238 digits. For other events, it is set to zero. 240 Note: Since the acceptable dip is 10 dB and the minimum detectable 241 loudness variation is 3 dB, this field could be compressed by at 242 least a bit by reducing resolution to 2 dB, if needed. 244 duration: Duration of this digit, in timestamp units. Thus, the digit 245 began at the instant identified by the RTP timestamp. 247 For a sampling rate of 8000 Hz, this field is sufficient to 248 express digit durations of upto approximately 8 seconds. 250 R: This field is reserved for future use. The sender MUST set it to 251 zero, the receiver MUST ignore it. 253 An audio source SHOULD start transmitting event packets as soon as it 254 recognizes an event and every 50 ms thereafter or the packet interval 255 for the audio codec used for this session, if known. (Precise spacing 256 between event packets is not necessary.) 258 Q.24 [5], Table A-1, indicates that all administrations 259 surveyed use a minimum signal duration of 40 ms, with 260 signaling velocity (tone and pause) of no less than 93 ms. 262 If a digit continues for more than one period, it should send a new 263 event packet with the RTP timestamp value corresponding to the 264 beginning of the digit and the duration of the digit increased 265 correspondingly. (The RTP sequence number is incremented by one for 266 each packet.) If there has been no new digit in the last interval, 267 the digit SHOULD be retransmitted three times (or until the next 268 event is recognized) to ensure some measure of reliability for the 269 last event. 271 DTMF digits and events are sent incrementally to avoid 272 having the receiver wait for the completion of the digit. 273 Since some tones are two seconds long, this would incur a 274 substantial delay. The transmitter does not know if digit 275 length is important and thus needs to transmit immediately 276 and incrementally. If the receiver application does not 277 care about digit length, the incremental transmission 278 mechanism avoids delay. Some applications, such as gateways 279 into the GSTN, care about both delays and digit duration. 281 2.4 Reliability 282 To achieve reliability even when the network loses packets, the audio 283 redundancy mechanism described in RFC 2198 [6] is used. The effective 284 data rate is r times 64 bits (32 bits for the redundancy header and 285 32 bits for the DTMF payload) every 50 ms or r times 1280 286 bits/second, where r is the number of redundant DTMF digits carried 287 in each packet. The value of r is an implementation trade-off, with a 288 value of 5 suggested. 290 The timestamp offset in this redundancy scheme has 14 bits, 291 so that it allows a single packet to "cover" 2.048 seconds 292 of DTMF digits at a sampling rate of 8000 Hz. Including the 293 starting time of previous digits allows precise 294 reconstruction of the tone sequence at a gateway. The 295 scheme is resilient to consecutive packet losses spanning 296 this interval of 2.048 seconds or r digits, whichever is 297 less. Note that for previous digits, only an average 298 loudness can be represented. 300 An encoder MAY treat the event payload as a highly-compressed version 301 of the current audio frame. In that mode, each RTP packet during a 302 DTMF tone would contain the current audio codec rendition (say, 303 G.723.1 or G.729) of this digit as well as the representation 304 described in Section 2.3, plus any previous digits as before. 306 This approach allows dumb gateways that do not understand 307 this format to function. See also the discussion in Section 308 1. 310 TBD: It may be possible 312 2.5 Example 314 A typical RTP packet, where the user is just dialing the last digit 315 of the DTMF sequence "911". The first digit was 200 ms long (1600 316 timestamp units) and started at time 0, the second digit lasted 250 317 ms (2000 timestamp units) and started at time 800 ms (6400 timestamp 318 units), the third digit was pressed at time 1.4 s (11,200 timestamp 319 units) and the packet shown was sent at 1.45 s (11,600 timestamp 320 units). The frame duration is 50 ms. To make the parts recognizable, 321 the figure below ignores byte alignment. Timestamp and sequence 322 number are assumed to have been zero at the beginning of the first 323 digit. In this example, the dynamic payload types 96 and 97 have been 324 assigned for the redundancy mechanism and the DTMF payload, 325 respectively. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |V=2|P|X| CC |M| PT | sequence number | 331 | 2 |0|0| 0 |0| 96 | 28 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | timestamp | 334 | 11200 | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | synchronization source (SSRC) identifier | 337 | 0x5234a8 | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |F| block PT | timestamp offset | block length | 340 |1| 97 | 11200 | 4 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |F| block PT | timestamp offset | block length | 343 |1| 97 | 4800 | 4 | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |F| Block PT | 346 |0| 97 | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | digit |R R| volume | duration | 349 | 9 |0 0| 7 | 1600 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | digit |R R| volume | duration | 352 | 1 |0 0| 10 | 2000 | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | digit |R R| volume | duration | 355 | 1 |0 0| 20 | 400 | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 2.6 Compact Reliability Scheme 360 A more compact representation could be achieved by measuring DTMF 361 tones in a different sampling rate from that of the surrounding audio 362 codec, e.g., as multiples of 1, 10, 40 or 50 ms. Each RTP payload 363 type should have a fixed sampling rate, so choosing a value that 364 depends on frame interval of the surrounding codec is not 365 recommended. For a sampling interval of 50 ms, the following payload 366 would "cover" 8 seconds of duration and offset: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | offset |R R R| digit |R R| volume | duration | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 2.7 DTMF Events 376 Tables 1 summarizes the events belonging to the DTMF payload type. It 377 uses the RTP encoding name "dtmf" and the MIME type "audio/dtmf". 379 Event encoding (decimal) 380 _________________________ 381 0--9 0--9 382 * 10 383 # 11 384 A--D 12--15 385 Flash 16 387 Table 1: DTMF events 389 2.8 Data Modem and Fax Events 391 Table 2.8 summarizes the events and tones that can appear on a 392 subscriber line serving a fax machine or modem. It uses the encoding 393 name "data" and the MIME type "audio/data". The tones are described 394 below, with additional detail in Table 7. 396 ANS: This 2100 +/- 15 Hz tone is used to disable echo suppression for 397 data transmission [7,8]. For fax machines, Recommendation T.30 398 [8] refers to this tone as called terminal identification (CED) 399 answer tone. 401 /ANS: This is the same signal as ANS, except that it reverses phase 402 at an interval of 450 +/- 25 ms. It disables both echo 403 cancellers and echo suppressors. (In the ITU Recommendation, 404 this signal is rendered as ANS with a bar on top.) 406 ANSam: The modified answer tone (ANSam) [2] is a sinewave signal at 407 2100 +/- 1 Hz with phase reversals at an interval of 450 +/- 25 408 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This 409 tone [9,7] is sent by modems [10] and faxes to disable echo 410 suppressors. 412 /ANSam: This is the same signal as ANSam, except that it reverses 413 phase at an interval of 450 +/- 25 ms. It disables both echo 414 cancellers and echo suppressors. (In the ITU Recommendation, 415 this signal is rendered as ANSam with a bar on top.) 417 CNG: After dialing the called fax machine's telephone number (and 418 before it answers), the calling Group III fax machine 419 (optionally) begins sending a CalliNG tone (CNG) consisting of 420 an interrupted tone of 1100 Hz. [8] 422 CRd: Capabilities Request (CRd) [11] is a dual-tone signal with tones 423 at tones at 1375 Hz and 2002 Hz for 400 ms for the initiating 424 side and 1529 Hz and 2225 Hz for the responding side, followed 425 by a single tone at 1900 Hz for 100 ms. "This signal requests 426 the remote station transition from telephony mode to an 427 information transfer mode and requests the transmission of a 428 capabilities list message by the remote station. In particular, 429 CRd is sent by the initiating station during the course of a 430 call, or by the calling station at call establishment in 431 response to a CRe or MRe." 433 CRe: Capabilities Request (CRe) [11] is a dual-tone signal with tones 434 at tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single 435 tone at 400 Hz for 100 ms. "This signal requests the remote 436 station transition from telephony mode to an information 437 transfer mode and requests the transmission of a capabilities 438 list message by the remote station. In particular, CRe is sent 439 by an automatic answering station at call establishment." 441 ESi: Escape Signal (ESi) [11] is a dual-tone signal with tones at 442 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 980 443 Hz for 100 ms. "This signal requests the remote station 444 transition from telephony mode to an information transfer mode. 445 signal ESi is sent by the initiating station." 447 ESr: Escape Signal (ESr) [11] is a dual-tone signal with tones at 448 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 449 1650 Hz for 100 ms. Same as ESi, but sent by the responding 450 station. 452 MRd: Mode Request (MRd) [11] is a dual-tone signals with tones at 453 1375 Hz and 2002 Hz for 400 ms for the initiating side and 1529 454 Hz and 2225 Hz for the responding side, followed by a single 455 tone at 1150 Hz for 100 ms. "This signal requests the remote 456 station transition from telephony mode to an information 457 transfer mode and requests the transmission of a mode select 458 message by the remote station. In particular, signal MRd is sent 459 by the initiating station during the course of a call, or by the 460 calling station at call establishment in response to an MRe." 461 [11] 463 MRe: Mode Request (MRe) [11] is a dual-tone signal with tones at 1375 464 Hz and 2002 Hz for 400 ms, followed by a single tone at 650 Hz 465 for 100 ms. "This signal requests the remote station transition 466 from telephony mode to an information transfer mode and requests 467 the transmission of a mode select message by the remote station. 468 In particular, signal MRe is sent by an automatic answering 469 station at call establishment." [11] 471 V.21: V.21 describes a 300 b/s full-duplex modem that employs 472 frequency shift keying (FSK). It is now used by Group 3 fax 473 machines to exchange T.30 information. The calling transmits on 474 channel 1 and receives on channel 2; the answering modem 475 transmits on channel 2 and receives on channel 1. Each bit value 476 has a distinct tone, so that V.21 signaling comprises a total of 477 four distinct tones. 479 In summary, procedures in Table 2 are used. 481 Procedure indications 482 ________________________________________________________ 483 V.25 and V.8 ANS, ANS, ... 484 V.25, echo canceller disabled ANS, /ANS, ANS, /ANS 485 V.8 ANSam, ANSam, ... 486 V.8, echo canceller disabled ANSam, /ANSam, ANSam, ... 488 Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations 490 Event____________________encoding_(decimal) 491 Answer tone (ANS) 1 492 ANSam 2 493 Calling tone (CNG) 3 494 V.21 channel 1, "0" bit 4 495 V.21 channel 1, "1" bit 5 496 V.21 channel 2, "0" bit 6 497 V.21 channel 2, "1" bit 7 499 Table 3: Data and fax events 501 2.9 Line Events 503 Table 4 summarizes the events and tones that can appear on a 504 subscriber line. It uses the encoding name "line" and the MIME type 505 "audio/line". 507 ITU Recommendation E.182 [12] defines when certain tones should be 508 used. It defines the following standard tones that are heard by the 509 caller: 511 Dial tone: The exchange is ready to receive address information. 513 PABX internal dial tone: The PABX is ready to receive address 514 information. 516 Special dial tone: Same as dial tone, but the caller's line is 517 subject to a specific condition, such as call diversion or a 518 voice mail is available (e.g., "stutter dial tone"). 520 Second dial tone: The network has accepted the address information, 521 but additional information is required. 523 Ringing tone: The call has been placed to the callee and a calling 524 signal (ringing) is being transmitted to the callee. 526 Special ringing tone: A special service, such as call forwarding or 527 call waiting, is active at the called number. 529 Busy tone: The called telephone number is busy. 531 Congestion tone: Facilities necessary for the call are temporarily 532 unavailable. 534 Calling card service tone: The calling card service tone consists of 535 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'), 536 followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone), 537 decaying exponentially with a time constant of 200 ms. 539 Special information tone: The callee cannot be reached, but the 540 reason is neither "busy" nor "congestion". This tone should be 541 used before all call failure announcements, for the benefit of 542 automatic equipment. 544 Comfort tone: The call is being processed. This tone may be used 545 during long post-dial delays, e.g., in international 546 connections. 548 Hold tone: The caller has been placed on hold. Replaced by 549 Greensleeves 551 Record tone: The caller has been connected to an automatic answering 552 device and is requested to begin speaking. 554 Caller waiting tone: The called station is busy, but has call waiting 555 service. 557 Pay tone: The caller, at a payphone, is reminded to deposit 558 additional coins. 560 Positive indication tone: The supplementary service has been 561 activated. 563 Negative indication tone: The supplementary service could not be 565 Off-hook warning tone: The caller has left the instrument off-hook 566 for an extended period of time. activated. 568 The following tones can be heard be either calling or called party 569 during a conversation: 571 Call waiting tone: Another party wants to reach the subscriber. 573 Warning tone: The call is being recorded. This tone is not required 574 in all jurisdictions. 576 Intrusion tone: The call is being monitored, e.g., by an operator. 577 (Use by law enforcement authorities is optional.) 579 CPE alerting signal (CAS): A tone used to alert a device to an 580 arriving in-band FSK data transmission. A CAS is a combined 2130 581 and 2750 Hz tone, both with tolerances of 0.5% and a duration of 582 80 to 80 ms. CAS is used with ADSI services and Call Waiting ID 583 services, see Bellcore GR-30-CORE, Issue 2, December 1998, 584 Section 2.5.2. 586 The following tones are heard by operators: 588 Payphone recognition tone: The person making the call or being called 589 is using a payphone (and thus it is ill-advised to allow collect 590 calls to such a person). 592 3 Extended Line Events 594 Table 5 summarizes country-specific events and tones that can appear 595 on a subscriber line. It uses the encoding name "linex" and the MIME 596 type "audio/linex". 598 3.1 Trunk Events 600 Table 6 summarizes the events and tones that can appear on a trunk. 602 Event encoding (decimal) 603 _____________________________________________ 604 Off Hook 0 605 On Hook 1 606 Dial tone 2 607 PABX internal dial tone 3 608 Special dial tone 4 609 Second dial tone 5 610 Ringing tone 6 611 Special ringing tone 7 612 Busy tone 8 613 Congestion tone 9 614 Special information tone 10 615 Comfort tone 11 616 Hold tone 12 617 Record tone 13 618 Caller waiting tone 14 619 Call waiting tone 15 620 Pay tone 16 621 Positive indication tone 17 622 Negative indication tone 18 623 Warning tone 19 624 Intrusion tone 20 625 Calling card service tone 21 626 Payphone recognition tone 22 627 CPE alerting signal (CAS) 23 628 Off-hook warning tone 24 630 Table 4: E.182 line events 632 It uses the encoding name "TRUNK" and the MIME type "audio/trunk". 633 Note that trunk can also carry line events, as MF signaling does not 634 include backward signals [13]. 636 [NOTE: the list below, below wink, does not agree with the MF 637 description in van Bosse, p. 74.] 639 Wink: A brief transition, typically 120-290 ms, from on-hook 640 (unseized) to off-hook (seized) and back to onhook, used by the 641 incoming exchange to signal that the call address signaling can 642 proceed. 644 Incoming seizure: Incoming indication of call attempt (off-hook). 646 Return seizure: Seizure by answering exchange, in response to 647 outgoing seizure. [NOTE: Not clear why the difference here, but 648 Event encoding (decimal) 649 ___________________________________________________ 650 Acceptance tone 0 651 Confirmation tone 1 652 Dial tone, recall 2 653 End of three party service tone 3 654 Facilities tone 4 655 Line lockout tone 5 656 Number unobtainable tone 6 657 Offering tone 7 658 Permanent signal tone 8 659 Preemption tone 9 660 Queue tone 10 661 Refusal tone 11 662 Route tone 12 663 Valid tone 13 664 Waiting tone 14 665 Warning tone (end of period) 15 666 Warning Tone (PIP tone) 16 668 Table 5: Country-specific Line events 670 not for Unseize. Should probably be just Seizure.] 672 Unseize circuit: Transition of circuit from off-hook to on-hook at 673 the end of a call. 675 Wink off: A brief transition, typically 100-350 ms, from off-hook 676 (seized) to on-hook (unseized) and back to off-hook (seized). 677 Used in operator services trunks. [CHECK!] 679 Continuity tone send: A tone of 2010 Hz. 681 Continuity tone detect: A tone of 2010 Hz. 683 Continuity test send: A tone of 1780 Hz is sent by the calling 684 exchange. If received by the called exchange, it returns a 685 "continuity verified" tone. 687 Continuity verified: A tone of 2010 Hz. This is a response tone, used 688 in dual-tone procedures. 690 Line test: 105 [EXPLAIN!] test line progress tones (2225 Hz at -10 691 dbm0). 693 4 RTP Payload Format for Telephony Tones 694 Event encoding (decimal) 695 __________________________________________________ 696 MF 0... 9 0... 9 697 MF K0 or KP (start-of-pulsing) 10 698 MF K1 11 699 MF K2 12 700 MF S0 to ST (end-of-pulsing) 13 701 MF S1... S3 14... 16 702 Wink 17 703 Wink off 18 704 Incoming seizure 19 705 Return seizure 20 706 Unseize circuit 21 707 Continuity test 22 708 Default continuity tone 23 709 Continuity tone (single tone) 24 710 Continuity test send 25 711 Continuity verified 26 712 Loopback 27 713 Old milliwatt tone (1000 Hz) 28 714 New milliwatt tone (1004 Hz) 29 716 Table 6: Trunk events 718 4.1 Requirements 720 As an alternative to describing tones and events by name, it is 721 sometimes preferable to describe them by their acoustic properties. 722 In particular, recognition is faster than for naming signals. 724 There is no single international standard for telephone tones such as 725 dial tone, ringing (ringback), busy, congestion ("fast-busy"), 726 special announcement tones or some of the other special tones, such 727 as payphone recognition, call waiting or record tone. However, across 728 all countries, these tones share a number of characteristics [14]: 730 o Tones consist of either a single tone, the addition of two or 731 three tones or the modulation of two tones. (Almost all tones 732 use two frequencies; only the Hungarian "special dial tone" 733 has three.) Tones that are mixed have the same amplitude and 734 do not decay. 736 o Tones for telephony events are in the range of 25 (ringing 737 tone in Angola) to 1800 Hz. CED is the highest used tone at 738 2100 Hz. The telephone frequency range is limited to 3,400 Hz. 740 o Modulation frequencies range between 15 (ANSam tone) to 480 Hz 741 (Jamaica). Non-integer frequencies are used only for 742 frequencies of 16 2/3 and 33 1/3 Hz. (These fractional 743 frequencies appear to be derived from older AC power grid 744 frequencies.) 746 o Tones that are not continuous have durations of less than four 747 seconds. 749 o ITU Recommendation E.180 [15] notes that different telephone 750 companies proscribe a tone accuracy of between 0.5 and 1.5%. 751 The Recommendation suggests a frequency tolerance of 1%. 753 4.2 Examples of Common Telephone Tone Signals 755 As an aid to the implementor, Table 7 summarizes some common tones. 756 The rows labeled "ITU ..." refer to the general recommendation of 757 Recommendation E.180 [15]. Note that there are no specific guidelines 758 for these tones. In the table, the symbol "+" indicates addition of 759 the tones, without modulation, while "*" indicates amplitude 760 modulation. [ADD ADDITIONAL COUNTRIES, IF DESIRED.] The meaning of 761 some of the tones is described in Section 2.9 or Section 2.8 (for 762 V.21). 764 4.3 Use of RTP Header Fields 766 Timestamp: The RTP timestamp reflects the measurement point for the 767 current packet. The event duration described in Section 2.3 768 extends forwards [NOTE: was "backwards", but that's different 769 from all other payloads and disagrees with RFC 1889] from that 770 time. 772 4.4 Payload Format 774 Based on the characteristics described above, the payload format is 775 shown in Fig. 1. 777 Figure 1: Payload format for tones 779 The payload contains the following fields: 781 modulation: The modulation frequency, in Hz. The field is a 9-bit 782 unsigned integer, allowing modulation frequencies up to 511 Hz. 784 Tone name frequency on period off period 785 ______________________________________________________ 786 CNG 1100 0.5 3.0 787 CED 2100 3.3 -- 788 ANS 2100 3.3 -- 789 ANSam 2100*15 3.3 -- 790 V.21 "0" bit, ch. 1 1180 0.033 791 V.21 "1" bit, ch. 1 980 0.033 792 V.21 "0" bit, ch. 2 1850 0.033 793 V.21_"1"_bit,_ch._2________1650______0.033____________ 794 ITU dial tone 425 -- -- 795 U.S. dial tone 350+440 -- -- 796 ______________________________________________________ 797 ITU ringing tone 425 0.67--1.5 3--5 798 U.S._ringing_tone_______440+480________2.0_________4.0 799 ITU busy tone 425 800 U.S. busy tone 480+620 0.5 0.5 801 ______________________________________________________ 802 ITU congestion tone 425 803 U.S. congestion tone 480+620 0.25 0.25 805 Table 7: Examples of telephony tones 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | modulation |T| volume | duration | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 |R R R R| frequency |R R R R| frequency | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 |R R R R| frequency |R R R R| frequency | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 |R R R R| frequency |R R R R| frequency | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 If there is no modulation, this field has a value of zero. 823 T: If the "T" bit is set (one), the modulation frequency is to be 824 divided by three. Otherwise, the modulation frequency is taken 825 as is. 827 volume: The power level of the digit, expressed in dBm0 after 828 dropping the sign, with range from 0 to -63 dBm0. (Note: A 829 preferred level range for digital tone generators is -8 dBm0 to 830 -3 dBm0.) 832 duration: The duration of the tone, measured in timestamp units. The 833 tone begins at the instant identified by the RTP timestamp and 834 lasts for the duration value. 836 The definition of duration corresponds to that for sample- 837 based codecs, where the timestamp represents the sampling 838 point for the first sample. 840 frequency: The frequencies of the tones to be added, measured in Hz 841 and represented as a 12-bit unsigned integer. The field size is 842 sufficient to represent frequencies up to 4095 Hz, which exceeds 843 the range of telephone systems. A value of zero indicates 844 silence. 846 R: This field is reserved for future use. The sender MUST set it to 847 zero, the receiver MUST ignore it. 849 The RTP payload type is designated as "TONE", the MIME type as 850 "audio/tone". The default timestamp rate is 8,000 Hz, but other rates 851 may be used. Note that the timestamp rate does not affect the 852 interpretation of the frequency, just the durations. 854 4.5 Reliability 856 Same as Section 2.4. 858 5 Combining Tones and Named Signals 860 The payload formats in Sections 2 and 4 can be combined into a single 861 payload, as shown in the example depicted in Fig. 2. In the example, 862 the RTP packet combines two TONE and one LINE payload. The payload 863 types are chosen arbitrarily as 97 and 98, respectively, with a 864 sample rate of 8000 Hz. Here, the redundancy format has the dynamic 865 payload type 96. 867 The packet represents a snapshot of U.S. ringing tone, 1.5 seconds 868 (12,000 timestamp units) into the second "on" part of the 2.0/4.0 869 second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) 870 into the ring cycle. The 440 + 480 Hz tone of this second cadence 871 started at RTP timestamp 48,000. Four seconds of silence preceded it, 872 but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds 873 (16383 timestamp units) can be represented. Even though the tone 874 sequence is not complete, the sender was able to determine that this 875 is indeed ringback, and thus includes the corresponding LINE event. 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 |V=2|P|X| CC |M| PT | sequence number | 881 | 2 |0|0| 0 |0| 96 | 31 | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | timestamp | 884 | 48000 | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | synchronization source (SSRC) identifier | 887 | 0x5234a8 | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |F| block PT | timestamp offset | block length | 890 |1| 98 | 16383 | 4 | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 |F| block PT | timestamp offset | block length | 893 |1| 97 | 16383 | 8 | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |F| Block PT | 896 |0| 97 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | event=ring |0|0| volume=0 | duration=28383 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | modulation=0 |0| volume=63 | duration=16383 | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 |0 0 0 0| frequency=0 |0 0 0 0| frequency=0 | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | modulation=0 |0| volume=5 | duration=12000 | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 |0 0 0 0| frequency=440 |0 0 0 0| frequency=480 | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Figure 2: Combining tones and events in a single RTP packet 915 6 History 917 o This draft combines draft-ietf-avt-dtmf-00 and draft-ietf- 918 avt-telephone-tones-01. 920 o From draft draft-ietf-avt-dtmf-00, the interval was changed to 921 be uniform at 50 ms, since audio frame interval may change 922 based on codec. 924 o From draft-ietf-avt-telephone-tones-01, a generic tone 925 representation was added. 927 7 IANA Considerations 929 This document defines three new RTP payload names and associated MIME 930 Types, TONE (audio/tone), LINE (audio/line) and TRUNK (audio/trunk). 931 Within the TRUNK and LINE RTP payload types, additional entries for 932 events MUST be registered with IANA. Before registration, IANA should 933 consult the current chair of the AVT working group or its successor 934 to avoid duplication of definitions. 936 8 Acknowledgements 938 The suggestions of the Megaco working group are gratefully 939 acknowledged. Detailed advice and comments were provided by Fred 940 Burg, Fatih Erdin, Mike Fox, Terry Lyons, and Steve Magnell. 942 9 Authors 944 Henning Schulzrinne 945 Dept. of Computer Science 946 Columbia University 947 1214 Amsterdam Avenue 948 New York, NY 10027 949 USA 950 electronic mail: schulzrinne@cs.columbia.edu 952 Scott Petrack 953 MetaTel 954 284 North Avenue 955 Weston, MA 02493 956 USA 957 electronic mail: scott.petrack@metatel.com 959 10 Bibliography 961 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 962 transport protocol for real-time applications," Request for Comments 963 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 965 [2] International Telecommunication Union, "Procedures for starting 966 sessions of data transmission over the public switched telephone 967 network," Recommendation V.8, Telecommunication Standardization 968 Sector of ITU, Geneva, Switzerland, Feb. 1998. 970 [3] R. Kocen and T. Hatala, "Voice over frame relay implementation 971 agreement," Implementation Agreement FRF.11, Frame Relay Forum, 972 Foster City, California, Jan. 1997. 974 [4] M. Handley and V. Jacobson, "SDP: session description protocol," 975 Request for Comments (Proposed Standard) 2327, Internet Engineering 976 Task Force, Apr. 1998. 978 [5] International Telecommunication Union, "Multifrequency push- 979 button signal reception," Recommendation Q.24, Telecommunication 980 Standardization Sector of ITU, Geneva, Switzerland, 1988. 982 [6] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. C. 983 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP payload for 984 redundant audio data," Request for Comments (Proposed Standard) 2198, 985 Internet Engineering Task Force, Sept. 1997. 987 [7] International Telecommunication Union, "Automatic answering 988 equipment and general procedures for automatic calling equipment on 989 the general switched telephone network including procedures for 990 disabling of echo control devices for both manually and automatically 991 established calls," Recommendation V.25, Telecommunication 992 Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996. 994 [8] International Telecommunication Union, "Procedures for document 995 facsimile transmission in the general switched telephone network," 996 Recommendation T.30, Telecommunication Standardization Sector of ITU, 997 Geneva, Switzerland, July 1996. 999 [9] International Telecommunication Union, "Echo cancellers," 1000 Recommendation G.165, Telecommunication Standardization Sector of 1001 ITU, Geneva, Switzerland, Mar. 1993. 1003 [10] International Telecommunication Union, "A modem operating at 1004 data signalling rates of up to 33 600 bit/s for use on the general 1005 switched telephone network and on leased point-to-point 2-wire 1006 telephone-type circuits," Recommendation V.34, Telecommunication 1007 Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. 1009 [11] International Telecommunication Union, "Procedures for the 1010 identification and selection of common modes of operation between 1011 data circuit-terminating equipments (dces) and between data terminal 1012 equipments (dtes) over the public switched telephone network and on 1013 leased point-to-point telephone-type circuits," Recommendation 1014 V.8bis, Telecommunication Standardization Sector of ITU, Geneva, 1015 Switzerland, Sept. 1998. 1017 [12] International Telecommunication Union, "Application of tones and 1018 recorded announcements in telephone services," Recommendation E.182, 1019 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1020 Mar. 1998. 1022 [13] J. G. van Bosse, Signaling in Telecommunications Networks 1023 Telecommunications and Signal Processing, New York, New York: Wiley, 1024 1998. 1026 [14] International Telecommunication Union, "Various tones used in 1027 national networks," Recommendation Supplement 2 to Recommendation 1028 E.180, Telecommunication Standardization Sector of ITU, Geneva, 1029 Switzerland, Jan. 1994. 1031 [15] International Telecommunication Union, "Technical 1032 characteristics of tones for telephone service," Recommendation 1033 Supplement 2 to Recommendation E.180, Telecommunication 1034 Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.