idnits 2.17.1 draft-ietf-avt-tones-01.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: ---------------------------------------------------------------------------- ** 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 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 130: '...g events via RTP SHOULD send both name...' RFC 2119 keyword, line 136: '...one representation, it SHOULD send the...' RFC 2119 keyword, line 156: '...udio stream, and SHOULD use the same s...' RFC 2119 keyword, line 182: '... A source MAY send events and coded ...' RFC 2119 keyword, line 184: '... stream, or it MAY block outgoing au...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 462 has weird spacing: '... Event encod...' == Line 878 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 (September 26, 1999) is 8950 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 1061 looks like a reference -- Missing reference section? '2' on line 1065 looks like a reference -- Missing reference section? '3' on line 1070 looks like a reference -- Missing reference section? '4' on line 1074 looks like a reference -- Missing reference section? '5' on line 1078 looks like a reference -- Missing reference section? '6' on line 1082 looks like a reference -- Missing reference section? '7' on line 1087 looks like a reference -- Missing reference section? '8' on line 1094 looks like a reference -- Missing reference section? '9' on line 1099 looks like a reference -- Missing reference section? '10' on line 1103 looks like a reference -- Missing reference section? '11' on line 1109 looks like a reference -- Missing reference section? '12' on line 1117 looks like a reference -- Missing reference section? '13' on line 1122 looks like a reference -- Missing reference section? '14' on line 1126 looks like a reference -- Missing reference section? '15' on line 1131 looks like a reference -- Missing reference section? '16' on line 1136 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 19 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-01.txt Columbia U./MetaTel 4 September 26, 1999 5 Expires: February 2000 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. 30 Abstract 32 This memo describes how to carry dual-tone multifrequency (DTMF) 33 signaling, other tone signals and telephony events in RTP packets. 35 1 Introduction 37 This memo defines two payload types, one for carrying dual-tone 38 multifrequency (DTMF) digits, other line and trunk signals and a 39 second one for general multi-frequency tones in RTP [1] packets. 40 Separate RTP payload types are desirable since low-rate voice codecs 41 cannot be guaranteed to reproduce these tone signals accurately 42 enough for automatic recognition. Defining a separate payload type 43 also permits higher redundancy while maintaining a low bit rate. 45 The payload types described here may be useful in at least three 46 applications: DTMF handling for gateways and end sytems, as well as 47 "RTP trunks". In the first application, the Internet telephony 48 gateway detects DTMF on the incoming circuits and sends the RTP 49 payload described here instead of regular audio packets. The gateway 50 likely has the necessary digital signal processors and algorithms, as 51 it often needs to detect DTMF, e.g., for two-stage dialing. Having 52 the gateway detect tones relieves the receiving Internet end system 53 from having to do this work and also avoids that low bit-rate codecs 54 like G.723.1 render DTMF tones unintelligible. Secondly, an Internet 55 end system such as an "Internet phone" can emulate DTMF functionality 56 without concerning itself with generating precise tone pairs and 57 without imposing the burden of tone recognition on the receiver. 59 In the "RTP trunk" application, RTP is used to replace a normal 60 circuit-switched trunk between two nodes. This is particularly of 61 interest in a telephone network that is still mostly circuit- 62 switched. In this case, each end of the RTP trunk encodes audio 63 channels into the appropriate encoding, such as G.723.1 or G.729. 64 However, this encoding process destroys in-band signaling information 65 which is carried using the least-significant bit ("robbed bit 66 signaling") and may also interfere with in-band signaling tones, such 67 as the MF digit tones. In addition, tone properties such as the phase 68 reversals in the ANSam tone, will not survive speech coding. Thus, 69 the gateway needs to remove the in-band signaling information from 70 the bit stream. It can now either carry it out-of-band in a signaling 71 transport mechanism yet to be defined, or it can use the mechanism 72 described in this memorandum. (If the two trunk end points are within 73 reach of the same media gateway controller, the media gateway 74 controller can also handle the signaling.) Carrying it in-band may 75 simplify the time synchronization between audio packets and the tone 76 or signal information. This is particularly relevant where duration 77 and timing matter, as in the carriage of DTMF signals. 79 2 Events vs. Tones 81 A gateway has two options for handling DTMF digits and events. First, 82 it can simply measure the frequency components of the voice band 83 signals and transmit this information to the RTP receiver (Section 84 4). In this mode, the gateway makes no attempt to discern the meaning 85 of the tones, but simply distinguishes tones from speech signals. 87 All tone signals in use in the PSTN and meant for human consumption 88 are sequences of simple combinations of sine waves, either added or 89 modulated. (There is at least one tone, the ANSam tone [2] used for 90 indicating data transmission over voice lines, that makes use of 91 periodic phase reversals.) 93 As a second option, a gateway can recognize the tones and translate 94 them into a name, such as ringing or busy tone. The receiver then 95 produces a tone signal or other indication appropriate to the signal. 96 Generally, since the recognition of signals often depends on their 97 on/off pattern or the sequence of several tones, this recognition can 98 take several seconds. On the other hand, the gateway may have access 99 to the actual signaling information that generates the tones and thus 100 can generate the RTP packet immediately, without the detour through 101 acoustic signals. 103 In the phone network, tones are generated at different places, 104 depending on the switching technology and the nature of the tone. 105 This determines, for example, whether a person making a call to a 106 foreign country hears her local tones she is familiar with or the 107 tones as used in the country called. 109 For analog lines, dial tone is always generated by the local switch. 110 ISDN terminals may generate dial tone locally and then send a Q.931 111 SETUP message containing the dialed digits. If the terminal just 112 sends a SETUP message without any Called Party digits, then the 113 switch does digit collection, provided by the terminal as KEYPAD 114 messages, and provides dial tone over the B-channel. The terminal can 115 either use the audio signal on the B-channel or can use the Q.931 116 messages to trigger locally generated dial tone. 118 Ringing tone (also called ringback tone) is generated by the local 119 switch at the callee, with a one-way voice path opened up as soon as 120 the callee's phone rings. (This reduces the chance of clipping of the 121 called party's response just after answer. It also permits pre-answer 122 announcements or in-band call-progress-indications to reach the 123 caller before or in lieu of ringing tone.) Congestion tone and 124 special information tones can be generated by any of the switches 125 along the way, and may be generated by the caller's switch based on 126 ISUP messages received. Busy tone is generated by the caller's 127 switch, triggered by the appropriate ISUP message, for analog 128 instruments, or the ISDN terminal. 130 Gateways which send signalling events via RTP SHOULD send both named 131 signals (Section 3) and the tone representation (Section 4) as a 132 single RTP session, using the redundancy mechanism defined in Section 133 3.7 to interleave the two representations. The receiver can then 134 choose the appropriate rendering. 136 If a gateway cannot present a tone representation, it SHOULD send the 137 audio tones as regular RTP audio packets (e.g., as payload type 138 PCMU), in addition to the named signals. 140 3 RTP Payload Format for Named Telephone Events 142 3.1 Introduction 144 The payload type for named telephone events described below is 145 suitable for both gateway and end-to-end scenarios. In the gateway 146 scenario, an Internet telephony gateway connecting a packet voice 147 network to the PSTN recreates the DTMF tones or other telephony 148 events and injects them into the PSTN. Since, for example, DTMF digit 149 recognition takes several tens of milliseconds, the first few 150 milliseconds of a digit will arrive as regular audio packets. Thus, 151 careful time and power (volume) alignment between the audio samples 152 and the events is needed to avoid generating spurious digits at the 153 receiver. 155 DTMF digits and named telephone events are carried as part of the 156 audio stream, and SHOULD use the same sequence number and time-stamp 157 base as the regular audio channel to simplify the generation of audio 158 waveforms at a gateway. The default clock frequency is 8,000 Hz, but 159 the clock frequency can be redefined when assigning the dynamic 160 payload type. 162 The payload format described here achieves a higher redundancy even 163 in the case of sustained packet loss than the method proposed for the 164 Voice over Frame Relay Implementation Agreement [3]. 166 If an end system is directly connected to the Internet and does not 167 need to generate tone signals again, time alignment and power levels 168 are not relevant. These systems rely on PSTN gateways or Internet end 169 systems to generate DTMF events and do not perform their own audio 170 waveform analysis. An example of such a system is an Internet 171 interactive voice-response (IVR) system. 173 In circumstances where exact timing alignment between the audio 174 stream and the DTMF digits or other events is not important and data 175 is sent unicast, such as the IVR example mentioned earlier, it may be 176 preferable to use a reliable control protocol rather than RTP 177 packets. In those circumstances, this payload format would not be 178 used. 180 3.2 Simultaneous Generation of Audio and Events 182 A source MAY send events and coded audio packets for the same time 183 instants, using events as the redundant encoding for the audio 184 stream, or it MAY block outgoing audio while event tones are active 185 and only send named events as both the primary and redundant 186 encodings. 188 Note that a period covered by an encoded tone may overlap in time 189 with a period of audio encoded by other means. This is likely to 190 occur at the onset of a tone and is necessary to avoid possible 191 errors in the interpretation of the reproduced tone at the remote 192 end. Implementations supporting this payload type must be prepared 193 to handle the overlap. 195 3.3 Event Types 197 This payload definition is used for five different types of signals: 199 o DTMF tones (Section 3.10); 201 o fax-related tones (Section 3.11); 203 o standard subscriber line tones (Section 3.12); 205 o for country-specific subscriber line tones (Section 3.13) and; 207 o for trunk events (Section 3.14). 209 A compliant implementation MUST support the events listed in Table 1. 210 If it uses some other, out-of-band mechanism for signaling line 211 conditions, it does not have to implement the other events. 213 In some cases, an implementation may simply ignore certain events, 214 such as fax tones, that do not make sense in a particular 215 environment. Section 3.9 specifies how an implementation can use the 216 SDP "fmtp" parameter within an SDP description to indicate its 217 inability to understand a particular event or range of events. 219 Depending on the available user interfaces, an implementation MAY 220 render all tones in Table 5 the same or, preferably, use the tones 221 conveyed by the concurrent "tone" payload or other RTP audio payload. 222 Alternatively, it could provide a textual representation. 224 Note that end systems that emulate telephones only need to support 225 the events described in Sections 3.10 and 3.12, while systems that 226 receive trunk signaling need to implement those in Sections 3.10, 227 3.11, 3.12 and 3.14, since MF trunks also carry most of the "line" 228 signals. Systems that do not support fax or modem functionality do 229 not need to render fax-related events described in Section 3.11. 231 The RTP payload type is designated as "telephone-event", the MIME 232 type as "audio/telephone-event". The default timestamp rate is 8,000 233 Hz, but other rates may be defined. In accordance with current 234 practice, this payload type does not have a static payload type 235 number, but uses a RTP payload type number established dynamically 236 and out-of-band. 238 The payload type distinguishes between a (line) DTMF 0 tone and a 239 (trunk) MF 0 tone. They payload type is signalled dynamically (for 240 example, within an SDP [4] or an H.245 message), or by some other 241 non-RTP means. 243 3.4 Use of RTP Header Fields 245 Timestamp: The RTP timestamp reflects the measurement point for 246 the current packet. The event duration described in Section 247 3.5 extends forwards from that time. 249 Marker bit: The RTP marker bit indicates the beginning of a new 250 event. 252 3.5 Payload Format 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | event |E|R| volume | duration | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 events: The events are encoded as shown in Sections 3.10 through 261 3.14. 263 volume: For DTMF digits, this field describes the power level of 264 the tone, expressed in dBm0 after dropping the sign. Power 265 levels range from 0 to -63 dBm0. The range of valid DTMF is 266 from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must 267 be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger 268 values denote lower volume. This value is defined only for 269 DTMF digits. For other events, it is set to zero by the 270 sender and is ignored by the receiver. 272 Note: Since the acceptable dip is 10 dB and the minimum 273 detectable loudness variation is 3 dB, this field could be 274 compressed by at least a bit by reducing resolution to 2 275 dB, if needed. 277 duration: Duration of this digit, in timestamp units. Thus, the 278 event began at the instant identified by the RTP timestamp 279 and has so far lasted as long as indicated by this 280 parameter. The event may or may not have ended. 282 For a sampling rate of 8000 Hz, this field is 283 sufficient to express event durations of up to 284 approximately 8 seconds. 286 E: If set to a value of one, the "end" bit indicates that this 287 packet contains the end of the event. Thus, the duration 288 parameter above measures the complete duration of the 289 event. 291 Receiver implementations can use at least two 292 different algorithms to create tones. In the first, 293 the receiver simply places a tone of the given 294 duration in the audio playout buffer at the location 295 indicated by the timestamp. As additional packets are 296 received that extend the tone, the waveform in the 297 playout buffer is adjusted accordingly. Thus, if a 298 packet in a tone lasting longer than the packet 299 interarrival time gets lost and the playout delay is 300 short, a gap in the tone may occur. Alternatively, the 301 receiver can start a tone and play it until it 302 receives a packet with the "E" bit set or the next 303 tone, distinguished by a different timestamp value. 304 This is more robust against packet loss, but may 305 extend the tone if all retransmissions of the last 306 packet in an event are lost. 308 R: This field is reserved for future use. The sender MUST set it 309 to zero, the receiver MUST ignore it. 311 3.6 Sending Event Packets 313 An audio source SHOULD start transmitting event packets as soon as it 314 recognizes an event and every 50 ms thereafter or the packet interval 315 for the audio codec used for this session, if known. (Precise spacing 316 between event packets is not necessary.) 318 Q.24 [5], Table A-1, indicates that all administrations 319 surveyed use a minimum signal duration of 40 ms, with 320 signaling velocity (tone and pause) of no less than 93 ms. 322 If an event continues for more than one period, the source generating 323 the events should send a new event packet with the RTP timestamp 324 value corresponding to the beginning of the event and the duration of 325 the event increased correspondingly. (The RTP sequence number is 326 incremented by one for each packet.) If there has been no new event 327 in the last interval, the event SHOULD be retransmitted three times 328 or until the next event is recognized. This ensures that the duration 329 of the event can be recognized correctly even if the last packet for 330 an event is lost. 332 DTMF digits and events are sent incrementally to avoid 333 having the receiver wait for the completion of the event. 334 Since some tones are two seconds long, this would incur a 335 substantial delay. The transmitter does not know if event 336 length is important and thus needs to transmit immediately 337 and incrementally. If the receiver application does not 338 care about event length, the incremental transmission 339 mechanism avoids delay. Some applications, such as gateways 340 into the PSTN, care about both delays and event duration. 342 3.7 Reliability 344 During an event, the RTP event payload type provides incremental 345 updates on the event. The error resiliency depends on the playout 346 delay at the receiver. For example, for a playout delay of 120 ms and 347 a packet gap of 50 ms, two packets in a row can get lost without 348 causing a gap in the tones generated at the receiver. 350 The audio redundancy mechanism described in RFC 2198 [6] MAY be used 351 to recover from packet loss across events. The effective data rate is 352 r times 64 bits (32 bits for the redundancy header and 32 bits for 353 the DTMF payload) every 50 ms or r times 1280 bits/second, where r is 354 the number of redundant events carried in each packet. The value of r 355 is an implementation trade-off, with a value of 5 suggested. 357 The timestamp offset in this redundancy scheme has 14 bits, 358 so that it allows a single packet to "cover" 2.048 seconds 359 of telephone events at a sampling rate of 8000 Hz. 360 Including the starting time of previous events allows 361 precise reconstruction of the tone sequence at a gateway. 362 The scheme is resilient to consecutive packet losses 363 spanning this interval of 2.048 seconds or r digits, 364 whichever is less. Note that for previous digits, only an 365 average loudness can be represented. 367 An encoder MAY treat the event payload as a highly-compressed version 368 of the current audio frame. In that mode, each RTP packet during a 369 DTMF tone would contain the current audio codec rendition (say, 370 G.723.1 or G.729) of this digit as well as the representation 371 described in Section 3.5, plus any previous digits as before. 373 This approach allows dumb gateways that do not understand 374 this format to function. See also the discussion in Section 375 1. 377 3.8 Example 378 A typical RTP packet, where the user is just dialing the last digit 379 of the DTMF sequence "911". The first digit was 200 ms long (1600 380 timestamp units) and started at time 0, the second digit lasted 250 381 ms (2000 timestamp units) and started at time 800 ms (6400 timestamp 382 units), the third digit was pressed at time 1.4 s (11,200 timestamp 383 units) and the packet shown was sent at 1.45 s (11,600 timestamp 384 units). The frame duration is 50 ms. To make the parts recognizable, 385 the figure below ignores byte alignment. Timestamp and sequence 386 number are assumed to have been zero at the beginning of the first 387 digit. In this example, the dynamic payload types 96 and 97 have been 388 assigned for the redundancy mechanism and the telephone event 389 payload, respectively. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |V=2|P|X| CC |M| PT | sequence number | 395 | 2 |0|0| 0 |0| 96 | 28 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | timestamp | 398 | 11200 | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | synchronization source (SSRC) identifier | 401 | 0x5234a8 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |F| block PT | timestamp offset | block length | 404 |1| 97 | 11200 | 4 | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |F| block PT | timestamp offset | block length | 407 |1| 97 | 4800 | 4 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |F| Block PT | 410 |0| 97 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | digit |R R| volume | duration | 413 | 9 |0 0| 7 | 1600 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | digit |R R| volume | duration | 416 | 1 |0 0| 10 | 2000 | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | digit |R R| volume | duration | 419 | 1 |0 0| 20 | 400 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 3.9 Indication of Receiver Capabilities using SDP 423 Receivers MAY indicate which named events they can handle, for 424 example, by using the Session Description Protocol (RFC 2327 [4]). 425 The payload types use the following fmtp format to list the event 426 values that they can receive: 428 a=fmtp: 430 The list of values consists of comma-separated elements, which can be 431 either a single decimal number or two decimal numbers separated by a 432 hyphen (dash), where the second number is larger than the first. No 433 whitespace is allowed between numbers or hyphens. The list does not 434 have to be sorted. 436 For example, if the data "codec" (Section 3.11) has been assigned the 437 payload type number 100 and the implementation can handle the common 438 DTMF tones as well as dial and PBX dial tones. 440 a=fmtp:100 0-11,66,67 442 The corresponding MIME parameter is "events", so that the following 443 sample media type definition corresponds to the SDP example above: 445 audio/telephony-events;events="0-11,66,67" 447 3.10 DTMF Events 449 Tables 1 summarizes the events belonging to the DTMF payload type. 451 3.11 Data Modem and Fax Events 453 Table 3.11 summarizes the events and tones that can appear on a 454 subscriber line serving a fax machine or modem. The tones are 455 described below, with additional detail in Table 7. 457 ANS: This 2100 +/- 15 Hz tone is used to disable echo 458 suppression for data transmission [7,8]. For fax machines, 459 Recommendation T.30 [8] refers to this tone as called 460 terminal identification (CED) answer tone. 462 Event encoding (decimal) 463 _________________________ 464 0--9 0--9 465 * 10 466 # 11 467 A--D 12--15 468 Flash 16 470 Table 1: DTMF events 472 /ANS: This is the same signal as ANS, except that it reverses 473 phase at an interval of 450 +/- 25 ms. It disables both 474 echo cancellers and echo suppressors. (In the ITU 475 Recommendation, this signal is rendered as ANS with a bar 476 on top.) 478 ANSam: The modified answer tone (ANSam) [2] is a sinewave signal 479 at 2100 +/- 1 Hz with phase reversals at an interval of 450 480 +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 481 Hz. This tone [9,7] is sent by modems [10] and faxes to 482 disable echo suppressors. 484 /ANSam: This is the same signal as ANSam, except that it 485 reverses phase at an interval of 450 +/- 25 ms. It disables 486 both echo cancellers and echo suppressors. (In the ITU 487 Recommendation, this signal is rendered as ANSam with a bar 488 on top.) 490 CNG: After dialing the called fax machine's telephone number 491 (and before it answers), the calling Group III fax machine 492 (optionally) begins sending a CalliNG tone (CNG) consisting 493 of an interrupted tone of 1100 Hz. [8] 495 CRd: Capabilities Request (CRd) [11] is a dual-tone signal with 496 tones at tones at 1375 Hz and 2002 Hz for 400 ms for the 497 initiating side and 1529 Hz and 2225 Hz for the responding 498 side, followed by a single tone at 1900 Hz for 100 ms. 499 "This signal requests the remote station transition from 500 telephony mode to an information transfer mode and requests 501 the transmission of a capabilities list message by the 502 remote station. In particular, CRd is sent by the 503 initiating station during the course of a call, or by the 504 calling station at call establishment in response to a CRe 505 or MRe." 507 CRe: Capabilities Request (CRe) [11] is a dual-tone signal with 508 tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed 509 by a single tone at 400 Hz for 100 ms. "This signal 510 requests the remote station transition from telephony mode 511 to an information transfer mode and requests the 512 transmission of a capabilities list message by the remote 513 station. In particular, CRe is sent by an automatic 514 answering station at call establishment." 516 ESi: Escape Signal (ESi) [11] is a dual-tone signal with tones 517 at 1375 Hz and 2002 Hz for 400 ms, followed by a single 518 tone at 980 Hz for 100 ms. "This signal requests the remote 519 station transition from telephony mode to an information 520 transfer mode. signal ESi is sent by the initiating 521 station." 523 ESr: Escape Signal (ESr) [11] is a dual-tone signal with tones 524 at 1529 Hz and 2225 Hz for 400 ms, followed by a single 525 tone at 1650 Hz for 100 ms. Same as ESi, but sent by the 526 responding station. 528 MRd: Mode Request (MRd) [11] is a dual-tone signals with tones 529 at 1375 Hz and 2002 Hz for 400 ms for the initiating side 530 and 1529 Hz and 2225 Hz for the responding side, followed 531 by a single tone at 1150 Hz for 100 ms. "This signal 532 requests the remote station transition from telephony mode 533 to an information transfer mode and requests the 534 transmission of a mode select message by the remote 535 station. In particular, signal MRd is sent by the 536 initiating station during the course of a call, or by the 537 calling station at call establishment in response to an 538 MRe." [11] 540 MRe: Mode Request (MRe) [11] is a dual-tone signal with tones at 541 1375 Hz and 2002 Hz for 400 ms, followed by a single tone 542 at 650 Hz for 100 ms. "This signal requests the remote 543 station transition from telephony mode to an information 544 transfer mode and requests the transmission of a mode 545 select message by the remote station. In particular, signal 546 MRe is sent by an automatic answering station at call 547 establishment." [11] 549 V.21: V.21 describes a 300 b/s full-duplex modem that employs 550 frequency shift keying (FSK). It is now used by Group 3 fax 551 machines to exchange T.30 information. The calling 552 transmits on channel 1 and receives on channel 2; the 553 answering modem transmits on channel 2 and receives on 554 channel 1. Each bit value has a distinct tone, so that V.21 555 signaling comprises a total of four distinct tones. 557 In summary, procedures in Table 2 are used. 559 Procedure indications 560 ________________________________________________________ 561 V.25 and V.8 ANS, ANS, ... 562 V.25, echo canceller disabled ANS, /ANS, ANS, /ANS 563 V.8 ANSam, ANSam, ... 564 V.8, echo canceller disabled ANSam, /ANSam, ANSam, ... 566 Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations 568 Event____________________encoding_(decimal) 569 Answer tone (ANS) 32 570 /ANS 33 571 ANSam 34 572 /ANSam 35 573 Calling tone (CNG) 36 574 V.21 channel 1, "0" bit 37 575 V.21 channel 1, "1" bit 38 576 V.21 channel 2, "0" bit 39 577 V.21 channel 2, "1" bit 40 578 CRd 41 579 CRe 42 580 ESi 43 581 ESr 44 582 MRd 45 583 MRe 46 585 Table 3: Data and fax events 587 3.12 Line Events 589 Table 4 summarizes the events and tones that can appear on a 590 subscriber line. 592 ITU Recommendation E.182 [12] defines when certain tones should be 593 used. It defines the following standard tones that are heard by the 594 caller: 596 Dial tone: The exchange is ready to receive address information. 598 PABX internal dial tone: The PABX is ready to receive address 599 information. 601 Special dial tone: Same as dial tone, but the caller's line is 602 subject to a specific condition, such as call diversion or 603 a voice mail is available (e.g., "stutter dial tone"). 605 Second dial tone: The network has accepted the address 606 information, but additional information is required. 608 Ringing tone: The call has been placed to the callee and a 609 calling signal (ringing) is being transmitted to the 610 callee. 612 Special ringing tone: A special service, such as call forwarding 613 or call waiting, is active at the called number. 615 Busy tone: The called telephone number is busy. 617 Congestion tone: Facilities necessary for the call are 618 temporarily unavailable. 620 Calling card service tone: The calling card service tone 621 consists of 60 ms of the sum of 941 Hz and 1477 Hz tones 622 (DTMF '#'), followed by 940 ms of 350 Hz and 440 Hz (U.S. 623 dial tone), decaying exponentially with a time constant of 624 200 ms. 626 Special information tone: The callee cannot be reached, but the 627 reason is neither "busy" nor "congestion". This tone should 628 be used before all call failure announcements, for the 629 benefit of automatic equipment. 631 Comfort tone: The call is being processed. This tone may be used 632 during long post-dial delays, e.g., in international 633 connections. 635 Hold tone: The caller has been placed on hold. Replaced by 636 Greensleeves 638 Record tone: The caller has been connected to an automatic 639 answering device and is requested to begin speaking. 641 Caller waiting tone: The called station is busy, but has call 642 waiting service. 644 Pay tone: The caller, at a payphone, is reminded to deposit 645 additional coins. 647 Positive indication tone: The supplementary service has been 648 activated. 650 Negative indication tone: The supplementary service could not be 652 Off-hook warning tone: The caller has left the instrument off- 653 hook for an extended period of time. activated. 655 The following tones can be heard be either calling or called party 656 during a conversation: 658 Call waiting tone: Another party wants to reach the subscriber. 660 Warning tone: The call is being recorded. This tone is not 661 required in all jurisdictions. 663 Intrusion tone: The call is being monitored, e.g., by an 664 operator. (Use by law enforcement authorities is optional.) 666 CPE alerting signal (CAS): A tone used to alert a device to an 667 arriving in-band FSK data transmission. A CAS is a combined 668 2130 and 2750 Hz tone, both with tolerances of 0.5% and a 669 duration of 80 to 80 ms. CAS is used with ADSI services and 670 Call Waiting ID services, see Bellcore GR-30-CORE, Issue 2, 671 December 1998, Section 2.5.2. 673 The following tones are heard by operators: 675 Payphone recognition tone: The person making the call or being 676 called is using a payphone (and thus it is ill-advised to 677 allow collect calls to such a person). 679 3.13 Extended Line Events 681 Table 5 summarizes country-specific events and tones that can appear 682 on a subscriber line. 684 3.14 Trunk Events 686 Table 6 summarizes the events and tones that can appear on a trunk. 687 Note that trunk can also carry line events (Section 3.12), as MF 688 signaling does not include backward signals [13]. 690 [NOTE: the list below, below wink, does not agree with the MF 691 description in van Bosse, p. 74.] 692 Event encoding (decimal) 693 _____________________________________________ 694 Off Hook 64 695 On Hook 65 696 Dial tone 66 697 PABX internal dial tone 67 698 Special dial tone 68 699 Second dial tone 69 700 Ringing tone 70 701 Special ringing tone 71 702 Busy tone 72 703 Congestion tone 73 704 Special information tone 74 705 Comfort tone 75 706 Hold tone 76 707 Record tone 77 708 Caller waiting tone 78 709 Call waiting tone 79 710 Pay tone 80 711 Positive indication tone 81 712 Negative indication tone 82 713 Warning tone 83 714 Intrusion tone 84 715 Calling card service tone 85 716 Payphone recognition tone 86 717 CPE alerting signal (CAS) 87 718 Off-hook warning tone 88 720 Table 4: E.182 line events 722 ABCD transitional: 4-bit signaling used by digital trunks. For 723 N-state signaling, the first N values are used. 725 The T1 ESF (extended super frame format) allows 2, 4, and 726 16 state signalling bit options. These signalling bits are 727 named A, B, C, and D. Signalling information is sent as 728 robbed bits in frames 6, 12, 18, and 24 when using ESF T1 729 framing. A D4 superframe only transmits 4-state signalling 730 with A and B bits. On the CEPT E1 frame, all signalling is 731 carried in timeslot 16, and two channels of 16-state (ABCD) 732 signalling are sent per frame. 734 Since this information is a state rather than a changing 735 signal, implementations SHOULD use the following triple- 736 redundancy mechanism, similar to the one specified in ITU-T 737 Rec. I.366.2 [14], Annex L. At the time of a transition, 739 Event encoding (decimal) 740 ___________________________________________________ 741 Acceptance tone 96 742 Confirmation tone 97 743 Dial tone, recall 98 744 End of three party service tone 99 745 Facilities tone 100 746 Line lockout tone 101 747 Number unobtainable tone 102 748 Offering tone 103 749 Permanent signal tone 104 750 Preemption tone 105 751 Queue tone 106 752 Refusal tone 107 753 Route tone 108 754 Valid tone 109 755 Waiting tone 110 756 Warning tone (end of period) 111 757 Warning Tone (PIP tone) 112 759 Table 5: Country-specific Line events 761 the same ABCD information is sent 3 times at an interval of 762 5 ms. If another transition occurs during this time, then 763 this continues. After a period of no change, the ABCD 764 information is sent every 5 seconds. 766 Wink: A brief transition, typically 120-290 ms, from on-hook 767 (unseized) to off-hook (seized) and back to onhook, used by 768 the incoming exchange to signal that the call address 769 signaling can proceed. 771 Incoming seizure: Incoming indication of call attempt (off- 772 hook). 774 Return seizure: Seizure by answering exchange, in response to 775 outgoing seizure. [NOTE: Not clear why the difference here, 776 but not for Unseize. Should probably be just Seizure.] 778 Unseize circuit: Transition of circuit from off-hook to on-hook 779 at the end of a call. 781 Wink off: A brief transition, typically 100-350 ms, from off- 782 hook (seized) to on-hook (unseized) and back to off-hook 783 (seized). Used in operator services trunks. 785 Event encoding (decimal) 786 __________________________________________________ 787 MF 0... 9 128... 137 788 MF K0 or KP (start-of-pulsing) 138 789 MF K1 139 790 MF K2 140 791 MF S0 to ST (end-of-pulsing) 141 792 MF S1... S3 142... 143 793 ABCD signaling (see below) 144... 159 794 Wink 160 795 Wink off 161 796 Incoming seizure 162 797 Return seizure 163 798 Unseize circuit 164 799 Continuity test 165 800 Default continuity tone 166 801 Continuity tone (single tone) 167 802 Continuity test send 168 803 Continuity verified 170 804 Loopback 171 805 Old milliwatt tone (1000 Hz) 172 806 New milliwatt tone (1004 Hz) 173 808 Table 6: Trunk events 810 Continuity tone send: A tone of 2010 Hz. 812 Continuity tone detect: A tone of 2010 Hz. 814 Continuity test send: A tone of 1780 Hz is sent by the calling 815 exchange. If received by the called exchange, it returns a 816 "continuity verified" tone. 818 Continuity verified: A tone of 2010 Hz. This is a response tone, 819 used in dual-tone procedures. 821 4 RTP Payload Format for Telephony Tones 823 4.1 Introduction 825 As an alternative to describing tones and events by name, as 826 described in Section 3, it is sometimes preferable to describe them 827 by their waveform properties. In particular, recognition is faster 828 than for naming signals since it does not depend on recognizing 829 durations or pauses. 831 There is no single international standard for telephone tones such as 832 dial tone, ringing (ringback), busy, congestion ("fast-busy"), 833 special announcement tones or some of the other special tones, such 834 as payphone recognition, call waiting or record tone. However, across 835 all countries, these tones share a number of characteristics [15]: 837 o Tones consist of either a single tone, the addition of two or 838 three tones or the modulation of two tones. (Almost all tones 839 use two frequencies; only the Hungarian "special dial tone" 840 has three.) Tones that are mixed have the same amplitude and 841 do not decay. 843 o Tones for telephony events are in the range of 25 (ringing 844 tone in Angola) to 1800 Hz. CED is the highest used tone at 845 2100 Hz. The telephone frequency range is limited to 3,400 Hz. 847 o Modulation frequencies range between 15 (ANSam tone) to 480 Hz 848 (Jamaica). Non-integer frequencies are used only for 849 frequencies of 16 2/3 and 33 1/3 Hz. (These fractional 850 frequencies appear to be derived from older AC power grid 851 frequencies.) 853 o Tones that are not continuous have durations of less than four 854 seconds. 856 o ITU Recommendation E.180 [16] notes that different telephone 857 companies proscribe a tone accuracy of between 0.5 and 1.5%. 858 The Recommendation suggests a frequency tolerance of 1%. 860 4.2 Examples of Common Telephone Tone Signals 862 As an aid to the implementor, Table 7 summarizes some common tones. 863 The rows labeled "ITU ..." refer to the general recommendation of 864 Recommendation E.180 [16]. Note that there are no specific guidelines 865 for these tones. In the table, the symbol "+" indicates addition of 866 the tones, without modulation, while "*" indicates amplitude 867 modulation. The meaning of some of the tones is described in Section 868 3.12 or Section 3.11 (for V.21). 870 4.3 Use of RTP Header Fields 872 Timestamp: The RTP timestamp reflects the measurement point for 873 the current packet. The event duration described in Section 874 3.5 extends forwards [NOTE: was "backwards", but that's 875 different from all other payloads and disagrees with RFC 876 1889] from that time. 878 Tone name frequency on period off period 879 ______________________________________________________ 880 CNG 1100 0.5 3.0 881 CED 2100 3.3 -- 882 ANS 2100 3.3 -- 883 ANSam 2100*15 3.3 -- 884 V.21 "0" bit, ch. 1 1180 0.033 885 V.21 "1" bit, ch. 1 980 0.033 886 V.21 "0" bit, ch. 2 1850 0.033 887 V.21_"1"_bit,_ch._2________1650______0.033____________ 888 ITU dial tone 425 -- -- 889 U.S. dial tone 350+440 -- -- 890 ______________________________________________________ 891 ITU ringing tone 425 0.67--1.5 3--5 892 U.S._ringing_tone_______440+480________2.0_________4.0 893 ITU busy tone 425 894 U.S. busy tone 480+620 0.5 0.5 895 ______________________________________________________ 896 ITU congestion tone 425 897 U.S. congestion tone 480+620 0.25 0.25 899 Table 7: Examples of telephony tones 901 4.4 Payload Format 903 Based on the characteristics described above, this document defines 904 an RTP payload format called "tone". (The corresponding MIME type is 905 "audio/telephone-event".) The default timestamp rate is 8,000 Hz, but 906 other rates may be defined. Note that the timestamp rate does not 907 affect the interpretation of the frequency, just the durations. 909 In accordance with current practice, this payload type does not have 910 a static payload type number, but uses a RTP payload type number 911 established dynamically and out-of-band. 913 It is shown in Fig. 1. 915 Figure 1: Payload format for tones 917 The payload contains the following fields: 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | modulation |T| volume | duration | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |R R R R| frequency |R R R R| frequency | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 |R R R R| frequency |R R R R| frequency | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 |R R R R| frequency |R R R R| frequency | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 modulation: The modulation frequency, in Hz. The field is a 9- 934 bit unsigned integer, allowing modulation frequencies up to 935 511 Hz. If there is no modulation, this field has a value 936 of zero. 938 T: If the "T" bit is set (one), the modulation frequency is to 939 be divided by three. Otherwise, the modulation frequency is 940 taken as is. 942 volume: The power level of the digit, expressed in dBm0 after 943 dropping the sign, with range from 0 to -63 dBm0. (Note: A 944 preferred level range for digital tone generators is -8 945 dBm0 to -3 dBm0.) 947 duration: The duration of the tone, measured in timestamp units. 948 The tone begins at the instant identified by the RTP 949 timestamp and lasts for the duration value. 951 The definition of duration corresponds to that for 952 sample-based codecs, where the timestamp represents 953 the sampling point for the first sample. 955 frequency: The frequencies of the tones to be added, measured in 956 Hz and represented as a 12-bit unsigned integer. The field 957 size is sufficient to represent frequencies up to 4095 Hz, 958 which exceeds the range of telephone systems. A value of 959 zero indicates silence. 961 R: This field is reserved for future use. The sender MUST set it 962 to zero, the receiver MUST ignore it. 964 4.5 Reliability 965 This payload type uses the reliability mechanism described in Section 966 3.7. 968 5 Combining Tones and Named Events 970 The payload formats in Sections 3 and 4 can be combined into a single 971 payload, as shown in the example depicted in Fig. 2. In the example, 972 the RTP packet combines two "tone" and one "telephone-event" payload. 973 The payload types are chosen arbitrarily as 97 and 98, respectively, 974 with a sample rate of 8000 Hz. Here, the redundancy format has the 975 dynamic payload type 96. 977 The packet represents a snapshot of U.S. ringing tone, 1.5 seconds 978 (12,000 timestamp units) into the second "on" part of the 2.0/4.0 979 second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) 980 into the ring cycle. The 440 + 480 Hz tone of this second cadence 981 started at RTP timestamp 48,000. Four seconds of silence preceded it, 982 but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds 983 (16383 timestamp units) can be represented. Even though the tone 984 sequence is not complete, the sender was able to determine that this 985 is indeed ringback, and thus includes the corresponding named event. 987 Figure 2: Combining tones and events in a single RTP packet 989 6 IANA Considerations 991 This document defines two new RTP payload types, named telephone- 992 event and tone, and associated Internet media (MIME) types, 993 audio/telephone-event and audio/tone. 995 Within the audio/telephone-event type, additional events MUST be 996 registered with IANA. Before registration, IANA should consult the 997 current chair of the AVT working group or its successor to avoid 998 duplication of definitions. 1000 7 Acknowledgements 1002 The suggestions of the Megaco working group are gratefully 1003 acknowledged. Detailed advice and comments were provided by Fred 1004 Burg, Fatih Erdin, Mike Fox, Terry Lyons, and Steve Magnell. 1006 8 Authors 1008 Henning Schulzrinne 1009 0 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 |V=2|P|X| CC |M| PT | sequence number | 1013 | 2 |0|0| 0 |0| 96 | 31 | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | timestamp | 1016 | 48000 | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | synchronization source (SSRC) identifier | 1019 | 0x5234a8 | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 |F| block PT | timestamp offset | block length | 1022 |1| 98 | 16383 | 4 | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 |F| block PT | timestamp offset | block length | 1025 |1| 97 | 16383 | 8 | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 |F| Block PT | 1028 |0| 97 | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | event=ring |0|0| volume=0 | duration=28383 | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | modulation=0 |0| volume=63 | duration=16383 | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 |0 0 0 0| frequency=0 |0 0 0 0| frequency=0 | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | modulation=0 |0| volume=5 | duration=12000 | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 |0 0 0 0| frequency=440 |0 0 0 0| frequency=480 | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Dept. of Computer Science 1046 Columbia University 1047 1214 Amsterdam Avenue 1048 New York, NY 10027 1049 USA 1050 electronic mail: schulzrinne@cs.columbia.edu 1052 Scott Petrack 1053 MetaTel 1054 45 Rumford Avenue 1055 Waltham, MA 02453 1056 USA 1057 electronic mail: scott.petrack@metatel.com 1059 9 Bibliography 1061 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 1062 transport protocol for real-time applications," Request for Comments 1063 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 1065 [2] International Telecommunication Union, "Procedures for starting 1066 sessions of data transmission over the public switched telephone 1067 network," Recommendation V.8, Telecommunication Standardization 1068 Sector of ITU, Geneva, Switzerland, Feb. 1998. 1070 [3] R. Kocen and T. Hatala, "Voice over frame relay implementation 1071 agreement," Implementation Agreement FRF.11, Frame Relay Forum, 1072 Foster City, California, Jan. 1997. 1074 [4] M. Handley and V. Jacobson, "SDP: session description protocol," 1075 Request for Comments (Proposed Standard) 2327, Internet Engineering 1076 Task Force, Apr. 1998. 1078 [5] International Telecommunication Union, "Multifrequency push- 1079 button signal reception," Recommendation Q.24, Telecommunication 1080 Standardization Sector of ITU, Geneva, Switzerland, 1988. 1082 [6] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. C. 1083 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP payload for 1084 redundant audio data," Request for Comments (Proposed Standard) 2198, 1085 Internet Engineering Task Force, Sept. 1997. 1087 [7] International Telecommunication Union, "Automatic answering 1088 equipment and general procedures for automatic calling equipment on 1089 the general switched telephone network including procedures for 1090 disabling of echo control devices for both manually and automatically 1091 established calls," Recommendation V.25, Telecommunication 1092 Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996. 1094 [8] International Telecommunication Union, "Procedures for document 1095 facsimile transmission in the general switched telephone network," 1096 Recommendation T.30, Telecommunication Standardization Sector of ITU, 1097 Geneva, Switzerland, July 1996. 1099 [9] International Telecommunication Union, "Echo cancellers," 1100 Recommendation G.165, Telecommunication Standardization Sector of 1101 ITU, Geneva, Switzerland, Mar. 1993. 1103 [10] International Telecommunication Union, "A modem operating at 1104 data signalling rates of up to 33 600 bit/s for use on the general 1105 switched telephone network and on leased point-to-point 2-wire 1106 telephone-type circuits," Recommendation V.34, Telecommunication 1107 Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. 1109 [11] International Telecommunication Union, "Procedures for the 1110 identification and selection of common modes of operation between 1111 data circuit-terminating equipments (dces) and between data terminal 1112 equipments (dtes) over the public switched telephone network and on 1113 leased point-to-point telephone-type circuits," Recommendation 1114 V.8bis, Telecommunication Standardization Sector of ITU, Geneva, 1115 Switzerland, Sept. 1998. 1117 [12] International Telecommunication Union, "Application of tones and 1118 recorded announcements in telephone services," Recommendation E.182, 1119 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1120 Mar. 1998. 1122 [13] J. G. van Bosse, Signaling in Telecommunications Networks 1123 Telecommunications and Signal Processing, New York, New York: Wiley, 1124 1998. 1126 [14] International Telecommunication Union, "AAL type 2 service 1127 specific convergence sublayer for trunking," Recommendation I.366.2, 1128 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1129 Feb. 1999. 1131 [15] International Telecommunication Union, "Various tones used in 1132 national networks," Recommendation Supplement 2 to Recommendation 1133 E.180, Telecommunication Standardization Sector of ITU, Geneva, 1134 Switzerland, Jan. 1994. 1136 [16] International Telecommunication Union, "Technical 1137 characteristics of tones for telephone service," Recommendation 1138 Supplement 2 to Recommendation E.180, Telecommunication 1139 Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.