idnits 2.17.1 draft-ietf-avt-rfc2833bisdata-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2088. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2833, but the abstract doesn't seem to directly say this. It does mention RFC2833 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 15, 2006) is 6497 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport (avt) H. Schulzrinne 3 Internet-Draft Columbia U. 4 Updates: xxxx (if approved) T. Taylor 5 Obsoletes: 2833 (if approved) Nortel 6 Expires: December 17, 2006 June 15, 2006 8 Definition of Events For Modem, FAX, and Text Telephony Signals 9 draft-ietf-avt-rfc2833bisdata-08 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 17, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo updates RFC xxxx to add event codes for modem, FAX, and 43 text telephony signals when carried in the telephony event RTP 44 payload. It supersedes the assignment of event codes for this 45 purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. 47 [Note to RFC Editor: please replace "RFC xxxx" in the header above 48 and throughout this document with the RFC number assigned to 49 draft-ietf-avt-rfc2833bis-15. Please also make the appropriate 50 change to the fifth normative reference.] 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions of Events For Control of Data, FAX, and Text 58 Telephony Sessions . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. V.8 bis Events . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1.1. Handling of Congestion . . . . . . . . . . . . . . . . 9 61 2.2. V.21 Events . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.2.1. Handling of Congestion . . . . . . . . . . . . . . . . 11 63 2.3. V.8 Events . . . . . . . . . . . . . . . . . . . . . . . . 12 64 2.3.1. Handling of Congestion . . . . . . . . . . . . . . . . 14 65 2.4. V.25 Events . . . . . . . . . . . . . . . . . . . . . . . 15 66 2.4.1. Handling of Congestion . . . . . . . . . . . . . . . . 17 67 2.5. V.32/V.32bis Events . . . . . . . . . . . . . . . . . . . 17 68 2.5.1. Handling of Congestion . . . . . . . . . . . . . . . . 19 69 2.6. T.30 Events . . . . . . . . . . . . . . . . . . . . . . . 19 70 2.6.1. Handling of Congestion . . . . . . . . . . . . . . . . 22 71 2.7. Events For Text Telephony . . . . . . . . . . . . . . . . 22 72 2.7.1. Signal Format Indicators For Text Telephony . . . . . 22 73 2.7.2. Use of Events With V.18 Modems . . . . . . . . . . . . 26 74 2.8. A Generic Indicator . . . . . . . . . . . . . . . . . . . 27 75 3. Strategies For Handling FAX and Modem Signals . . . . . . . . 29 76 4. Example of V.8 Negotiation . . . . . . . . . . . . . . . . . . 31 77 4.1. Simultaneous Transmission of Events and Retransmitted 78 Events Using RFC 2198 Redundancy . . . . . . . . . . . . . 35 79 4.2. Simultaneous Transmission of Events and Voice Band 80 Data Using RFC 2198 Redundancy . . . . . . . . . . . . . . 38 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 46 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 47 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 88 Intellectual Property and Copyright Statements . . . . . . . . . . 51 90 1. Introduction 92 1.1. Terminology 94 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 95 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 96 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. 98 In addition to those defined for specific events, this document uses 99 the following abbreviations: 101 FAX facsimile 103 HDLC High-level Data Link Control 105 PSTN Public Switched (circuit) Telephone Network 107 1.2. Overview 109 This document extends the set of telephony events defined within the 110 framework of RFC xxxx [5] to include the control events and tones 111 that can appear on a subscriber line serving a FAX machine, a modem, 112 or a text telephony device. The events are organized into several 113 groups, corresponding to the ITU-T Recommendation in which they are 114 defined. Their purpose is to support negotiation, start-up and 115 takedown of FAX, modem, or text telephony sessions and transitions 116 between operating modes. The actual FAX, modem, and text payload is 117 typically carried by other payload types, e.g, V.150.1 [32] modem 118 relay, voice band data as formalized in ITU-T Rec. V.152 [33], 119 CLEARMODE [17] for digital data, T.38 [21] for FAX, or RFC 4103 [18] 120 for character-mode text). 122 NOTE: implementors SHOULD NOT rely on the descriptions of the various 123 modem protocols described below without consulting the original 124 references (generally ITU-T Recommendations). The descriptions are 125 provided in this document to give a context for the use of the events 126 defined here. They frequently omit important details needed for 127 implementation. 129 The typical application of these events is to allow the Internet to 130 serve as a bridge between terminals operating on the PSTN. This 131 application is characterized as follows: 133 o each gateway will act both as sender and as receiver; 135 o time constraints apply to the exchange of signals, making the 136 early identification and reporting of events desirable so that 137 receiver playout can proceed in timely fashion; 139 o the receiver must play out events in their proper order; 141 o transfer of the events must be reliable. Applications will vary 142 in their ability to recover from missing events. 144 In some cases, an implementation may simply ignore certain events, 145 such as FAX tones, that do not make sense in a particular 146 environment. Section 2.4.1 of RFC xxxx [5] specifies how an 147 implementation can use the SDP "fmtp" parameter within an SDP 148 description [3] to indicate which events it is prepared to handle. 150 Regardless of which events they support, implementations MUST be 151 prepared to send and receive data signals using payload types other 152 than telephone-event, simultaneously with the use of the latter. 153 This is discussed further in Section 3. 155 In many cases, continuity of playout is critical. In principal this 156 is achieved through buffering at the receiving end. It is generally 157 desirable to minimize such buffering to reduce round-trip response 158 times. Maintenance of a constant packetization interval at the 159 sending end while reporting events is helpful for this purpose. 161 A further word on time constraints is in order. Time constraints 162 governing the duration of tones do not pose a problem when using the 163 telephone-events payload type: the payload specifies the duration and 164 the receiving gateway can play out the tones accordingly. Problems 165 come when time constraints are specified for the duration of silence 166 between tones. A silent period of "at least x ms" is not a problem - 167 - event notifications can be received late, but they can still be 168 played out at their specified durations. 170 The problem comes with requirements of silence for "exactly" some 171 period or for "at most" some period. The most general constraint of 172 the latter type has to do with the operation of echo suppressors 173 (ITU-T Rec. G.164 [6]) and echo cancellers (ITU-T Rec. G.165 [7]). 174 These devices may re-activate after as little as 100 ms of no signal 175 on the line. As a result, in any situation where echo suppressors or 176 cancellers must be disabled for signalling to work, tone events must 177 be reported quickly enough to ensure that these devices do not become 178 re-enabled. 180 2. Definitions of Events For Control of Data, FAX, and Text Telephony 181 Sessions 183 2.1. V.8 bis Events 185 Recommendation V.8 bis [10] is a general procedure for two endpoints 186 to establish each others' capabilities and to transition between 187 different operating modes, both at call startup and after the call 188 has been established. It supports many of the same terminals as V.8 189 [9] (Section 2.3 below), but allows more detailed parameter 190 negotiation. It lacks support for some of the older V-series modems 191 defined in V.8, but adds capabilities for simultaneous or alternating 192 voice and data, H.324 [20] multilink, and T.120 [23] conferencing. 194 Following V.8 bis capability negotiations, if the terminals have 195 negotiated a modem-based operating mode, they initiate the actual 196 modem session using either V.8, a truncated version of V.8 197 (preferred), or V.25 start-up. V.25 is described in Section 2.4. 199 V.8 bis distinguishes between "signals" and "messages". The V.8 bis 200 signals: ESi/ESr, MRe/MRd, and CRe/CRd -- consist of tones, as 201 described in the next few paragraphs. The V.8 bis messages: MS, CL, 202 CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), and NACK(4) -- consist 203 of sequences of bits transported over V.21 [12] modulation. 205 Signals are intended to be comprehensible at the receiver even in the 206 presence of voice content. They consist of two tone segments. The 207 first segment consists of a dual frequency tone held for 400 ms, and 208 has the function of preparing the receiver and any in-line echo 209 suppressor or canceller for what follows. The specific frequencies 210 depend only on whether the signal is from the initiator or the 211 responder in a transaction. When using the telephone-event payload, 212 the V8bISeg and V8bRSeg events in Table 1 represent the first segment 213 of any V.8 bis signal in the initiating and responding case 214 respectively. 216 The complete V.8 bis strategy for dealing with echo suppressors or 217 cancellers is described in Rec. V.8 bis Appendix III. The only 218 silent period constraints imposed are of the "at least" type, 219 posing no difficulties for the use of the telephone-event payload. 221 The second segment follows immediately after the first, and is a 222 single tone held for 100 ms. The frequency used indicates the 223 specific signal of the six signals defined. When using the 224 telephone-event payload, the second segment of a V.8 bis signal is 225 represented by the applicable event: CRdSeg, CReSeg, MRdSeg, MReSeg, 226 ESiSeg, or ESrSeg, as defined in Table 1. ESiSeg and ESrSeg use the 227 same frequencies as V.21 low and high channel '1' bits respectively 228 (see Table 2), and are therefore assigned the same event codes. 230 V.8 bis messages use V.21 [12] frequency-shift signalling to transfer 231 message content. V.21 is described in the next section. V.8 bis 232 uses V.21 in half-duplex mode at 300 bits/s, with the lower channel 233 assigned to the initiator and the upper channel to the responder. 235 Each V.8 bis message is preceded by a 100 ms preamble of continuous 236 V.21 marking frequency except if it was immediately preceded by an 237 ESi or ESr signal (the second segment of which is that same V.21 238 marking frequency). The sender SHALL NOT report this preamble tone 239 using the ESiSeg or ESrSeg events; these are to be used only for the 240 V.8 bis signals to which they pertain. 242 Spelling this out, continuous V.21 marking tone immediately 243 following V8bISeg and V8bRSeg is reported as ESiSeg or ESrSeg 244 respectively. Continuous V.21 marking tone occurring in any other 245 context, and particularly after CRdSeg, CReSeg, MRdSeg, or MReSeg, 246 is reported by other means such as a different payload type or 247 using the V.21 '1' bit events defined in Section 2.2. 249 No events are defined for V.8 bis messages, but a brief description 250 follows. 252 o the V.8 bis CL message describes the sending terminal's 253 capabilities; 255 o the CLR message also describes capabilities, but indicates that 256 the sender wants to receive a CL in return; 258 o the MS establishes a particular operating mode; 260 o the ACK and NAK messages are used to terminate the message 261 transactions. 263 The V.8 bis messages are organized as a sequence of octets. The 264 first two to five octets are HDLC flags (0x7E). Then comes a message 265 type identifier (four bits), a V.8 bis version identifier (four 266 bits), zero to two more octets of identifying information, followed 267 by zero or more information field parameters in the form of bit maps. 268 An individual bit map is one to five octets in length. Up to 64 269 octets of non-standard information may also be present. The 270 information fields are followed by a checksum and one to three HDLC 271 flags. Because of limits on the size of any one information field, 272 V.8 bis defines segmentation procedures. Excess data is sent in an 273 additional message, but only after prompting from the receiving end. 275 Applications supporting V.8 bis signalling using the telephone-events 276 payload MAY transfer V.8 bis messages in the form of sequences of 277 bits, using the V.21 bit events defined in the next section. If they 278 do so, the transmitted information MUST include the complete contents 279 of the message: the initial HDLC flags, the information field, the 280 checksum, and the terminating HDLC flags. 282 Transmission MUST also include the extra '0' bits added according to 283 the procedures of Rec. V.8 bis clause 7.2.8 to prevent false 284 recognition of HDLC flags at the receiver. Implementors should note 285 that these extra '0' bits mean that in general V.8 bis messages as 286 transmitted on the wire will not come out to an even multiple of 287 octets. Sending implementations MAY choose to vary the packetization 288 interval to include exactly one octet of information plus any extra 289 '0' bits inserted into that octet; the resulting variation will be 290 insignificant compared with the amount of buffering required to guard 291 against network delays in delivery of packets to the receiver (see 292 below). 294 One reason for reporting the V.21 bits exactly as presented on the 295 wire is to match the corresponding content if it is also carried 296 by other means, such as voice-band data. 298 The power levels of the V.8 bis and V.21 signals are subject to 299 national regulation. Thus it seems suitable to model V.8 bis events 300 as tones for which the volumes SHOULD be specified by the sender. If 301 the receiver is rendering the V.8 bis tones as audio content for 302 onward transmission, the receiver MAY use the volumes contained in 303 the event reports, or MAY modify the volumes to match downstream 304 national requirements. 306 Table 1 summarizes the event codes defined for V.8 bis signalling in 307 this document. The individual events are described following the 308 table. Each event begins when the beginning of the tone segment is 309 detected and ends when the tone is no longer detected. 311 +---------+-------------+-----------+------------+------+---------+ 312 | Event | Freq. (Hz) | Dur. (ms) | Event Code | Type | Volume? | 313 +---------+-------------+-----------+------------+------+---------+ 314 | ESiSeg | 980 | 100 | 38 | tone | yes | 315 | | | | | | | 316 | ESrSeg | 1650 | 100 | 40 | tone | yes | 317 | | | | | | | 318 | CRdSeg | 1900 | 100 | 23 | tone | yes | 319 | | | | | | | 320 | CReSeg | 400 | 100 | 24 | tone | yes | 321 | | | | | | | 322 | MRdSeg | 1150 | 100 | 25 | tone | yes | 323 | | | | | | | 324 | MReSeg | 650 | 100 | 26 | tone | yes | 325 | | | | | | | 326 | V8bISeg | 1375 + 2002 | 400 | 28 | tone | yes | 327 | | | | | | | 328 | V8bRSeg | 1529 + 2225 | 400 | 29 | tone | yes | 329 +---------+-------------+-----------+------------+------+---------+ 331 Table 1: Events for V.8 bis signals 333 ESiSeg: 335 The second segment of a V.8 bis initiating Escape Signal (ESi). 336 The complete ESi signal is represented by events V8bISeg followed 337 by ESiSeg. ESi will be followed by an MS, CL, or CLR message from 338 the same terminal. A 1.5 s silent interval may come between the 339 ESi signal and the transmission of the MS, CL or CLR message to 340 accommodate network echo suppressors. 342 ESrSeg: 344 The second segment of a V.8 bis responding Escape Signal (ESr). 345 The complete ESr signal is represented by events V8bRSeg followed 346 by ESrSeg. ESr is always sent by the calling terminal in response 347 to an MRe or CRe from an automatic answering station. It will be 348 followed by an MS, CL or CLR message. The ESr signal turns off 349 any announcement being generated by the automatic answering 350 station. 352 CRdSeg: 354 The second segment of a V.8 bis Capabilities Request signal (CRd). 355 The first segment of the CRd signal is represented either by 356 V8bISeg or V8bRSeg, depending on context. The other end will 357 return a capabilities list (CL or CLR message). 359 CReSeg: 361 The second segment of a V.8 bis Capabilities Request signal (CRe) 362 initiated by an automatic answering terminal. The complete CRe 363 signal is represented by events V8bISeg followed by CReSeg. The 364 calling terminal will respond with a CRd signal or a CL or CLR 365 message. 367 MRdSeg: 369 The second segment of a V.8 bis Mode Request signal (MRd). The 370 first segment of the MRd signal is represented either by V8bISeg 371 or V8bRSeg, depending on context. The other end will return a CRd 372 signal or an MS message. 374 MReSeg: 376 The second segment of a V.8 bis Mode Request signal (MRe) 377 initiated by an automatic answering terminal. The complete MRe 378 signal is represented by events V8bISeg followed by MReSeg. The 379 calling terminal will respond with an MRd or CRd signal or an MS 380 message. 382 V8bISeg: 384 The first segment of an initiating V.8 bis signal, which may be 385 one of ESi, CRd, CRe, MRd, or MRe. 387 V8bRSeg: 389 The first segment of a responding V.8 bis signal, which may be one 390 of ESr, CRd, or MRd. 392 2.1.1. Handling of Congestion 394 V.8 bis implementations are unlikely to tolerate gaps or extensions 395 in playout times due to congestion-caused packet delay. At a 396 minimum, the current transaction is liable to be reset when these 397 defects in playout occur. As a result, careful management of the 398 playout buffer is required at the receiver to increase robustness in 399 the face of possible lost or delayed packets. The playout algorithm 400 should also be such as not to cause event playout to exceed the 401 nominal duration of the event. 403 V.8 bis does not appear to offer opportunities for dynamic adaptation 404 to congestion through manipulation of the packetization interval. 406 2.2. V.21 Events 408 V.21 [12] is a modem protocol offering data transmission at a maximum 409 rate of 300 bits/s. Two channels are defined, supporting full duplex 410 data transmission if required. The low channel uses frequencies 980 411 Hz for '1' (mark) and 1180 Hz for '0' (space); the high channel uses 412 frequencies 1650 Hz for '1' and 1850 Hz for '0'. The modem can 413 operate synchronously or asynchronously. 415 V.21 is used by other protocols (e.g., V.8 bis, V.18, T.30) for 416 transmission of control data, and is also used in its own right 417 between text terminals. The V.21 events are summarized in Table 2. 419 Sending implementations SHOULD report a completed event for every bit 420 transmitted (i.e., rather than at transitions between '0' and '1'). 421 Bit events are assumed to begin and end with the clock interval for 422 the event, neglecting the rise and fall times between bit 423 transitions. Thus it is important for a gateway to determine the 424 actual bit rate in use before beginning to report V.21 events. 426 Sometimes determination of the bit rate is not immediately 427 possible, as in the case of the 100 ms training signal at V.21 428 mark frequency used before V.8 bis messages. Transmission of a 429 single longer-duration V.21 event is reasonable under these 430 circumstances and should not cause any difficulties at the 431 receiving end. 433 Implementations SHOULD pack multiple events into one packet, using 434 the procedures of section 2.5.1.5 of RFC xxxx [5]. Eight to ten bits 435 is a reasonable packetization interval. 437 Reliable transmission of V.21 events is important, to prevent data 438 corruption. Reporting an event per bit rather than per transition 439 increases reporting redundancy and thus reporting reliability, since 440 each event completion is transmitted three times as described in 441 section 2.5.1.4 of RFC xxxx [5]. To reduce the number of packets 442 required for reporting, implementations SHOULD carry the 443 retransmitted events using RFC 2198 [2] redundancy encoding. This is 444 illustrated in the example in Section 4.1. 446 The time to transmit one V.21 bit at the nominal rate of 300 bits/s 447 is 3.33 ms, or 26.67 timestamp units at the default 8000 Hz sampling 448 rate for the telephone-events payload type. Because this duration is 449 not an integral number of timestamp units, accurate reporting of the 450 beginning of the event and the event duration is impossible. Sending 451 gateways SHOULD round V.21 event starting times to the nearest whole 452 timestamp unit. 454 When sending multiple consecutive V.21 events in a succession of 455 packets, the sending gateway MUST ensure that individual event 456 durations reported do not cause the last event of one packet to 457 overlap with the first event of the next, taking into account the 458 respective initial event timestamps. To accomplish this, the sending 459 gateway MUST derive the individual event durations as the succession 460 of differences between the event starting times (so that, at 8000 Hz, 461 every third event has reported duration 26 units, the remainder 27 462 units). 464 Where a receiving gateway recognizes that a packet reports a 465 consecutive series of V.21 bit events, it SHOULD play them out at a 466 uniform rate despite the possible one-timestamp-unit discrepancies in 467 their reported spacing and duration. 469 +--------------------+----------------+------------+------+---------+ 470 | Event | Frequency (Hz) | Event Code | Type | Volume? | 471 +--------------------+----------------+------------+------+---------+ 472 | V.21 channel 1, | 1180 | 37 | tone | yes | 473 | '0' bit | | | | | 474 | | | | | | 475 | V.21 channel 1, | 980 | 38 | tone | yes | 476 | '1' bit | | | | | 477 | | | | | | 478 | V.21 channel 2, | 1850 | 39 | tone | yes | 479 | '0' bit | | | | | 480 | | | | | | 481 | V.21 channel 2, | 1650 | 40 | tone | yes | 482 | '1' bit | | | | | 483 +--------------------+----------------+------------+------+---------+ 485 Table 2: Events for V.21 signals 487 Implementations that choose to transmit V.21 content using a 488 different payload type may wish to use one of the indicator events 489 defined in Table 7 to alert the receiver to the nature of the 490 content. It is not expected that an implementation will send both 491 one of these indicator events and the V.21 bit events defined above 492 for the same content. 494 2.2.1. Handling of Congestion 496 The duration of V.21 bits cannot be extended from its nominal value 497 (which depends on the transmission rate). The playout algorithm at 498 the receiver should take this constraint into account when 499 compensating for the delay or loss of packets due to congestion. 501 Other congestion-related considerations depend on the specific 502 application for which the V.21 bit events are being used. 504 2.3. V.8 Events 506 V.8 [9] is an older general negotiation and control protocol, 507 supporting startup for the following terminals: H.324 [20] 508 multimedia, V.18 [11] text, T.101 [22] videotext, T.30 [8] send or 509 receive FAX, and a long list of V-series modems including V.34 [28], 510 V.90 [29], V.91 [30], and V.92 [31]. In contrast to V.8 bis [10], in 511 V.8 only the calling terminal can determine the operating mode. 513 V.8 does not use the same terminology as V.8 bis. Rather, it defines 514 four signals which consist of bits transferred by V.21 [12] at 300 515 bits/s: the call indicator signal (CI), the call menu signal (CM), 516 the CM terminator (CJ), and the joint menu signal (JM). In addition, 517 it uses tones defined in V.25 [13] and T.30 [8] (described below), 518 and one tone (ANSam) defined in V.8 itself. The calling terminal 519 sends using the V.21 low channel; the answering terminal uses the 520 high channel. 522 The basic protocol sequence is subject to a number of variations to 523 accommodate different terminal types. A pure V.8 sequence is as 524 follows: 526 1. After an initial period of silence, the calling terminal 527 transmits the V.8 CI signal. It repeats CI at least three times, 528 continuing with occasional pauses until it detects ANSam tone. 529 The CI indicates whether the calling terminal wants to function 530 as H.324, V.18, T.30 send, T.30 receive, or a V-series modem. 532 2. The answering terminal transmits ANSam after detecting CI. ANSam 533 will disable any G.164 [6] echo suppressors on the circuit after 534 400 ms and any G.165 [7] echo cancellers after one second of 535 ANSam playout. 537 3. On detecting ANSam, the calling terminal pauses at least half a 538 second, then begins transmitting CM to indicate detailed 539 capabilities within the chosen mode. 541 4. After detecting at least two identical sequences of CM, the 542 answering terminal begins to transmit JM, indicating its own 543 capabilities (or offering an alternative terminal type if it 544 cannot support the one requested). 546 5. After detecting at least two identical sequences of JM, the 547 calling terminal completes the current octet of CM, then 548 transmits CJ to acknowledge the JM signal. It pauses exactly 75 549 ms, then starts operating in the selected mode. 551 6. The answering terminal transmits JM until it has detected CJ. At 552 that point it stops transmitting JM immediately, pauses exactly 553 75 ms, then starts operating in the selected mode. 555 The CI, CM, and JM signals all consist of a fixed sequence of ten '1' 556 bits followed by a signal-dependent pattern of ten synchronization 557 bits, followed by one or more octets of variable information. Each 558 octet is preceded by a '0' start bit and followed by a '1' stop bit. 559 The combination of the synchronization pattern and V.21 channel 560 uniquely identifies the message type. The CJ signal consists of 561 three successive octets of all zeros with stop and start bits but 562 without the preceding '1's and synchronizing pattern of the other 563 signals. 565 Applications MAY report each instance of a CM, JM, and CJ signal 566 respectively as a series of V.21 bit events (Section 2.2), or may use 567 another payload type to carry this information. Applications 568 supporting V.8 signalling using the telephone-events payload MAY 569 report the synchronization part of the CI signal (ten '1's followed 570 by '00000 00001') both as a series of V.21 bit events and, when it 571 has been recognized, as a single CI event. 573 Note that the CI event covers only the synchronization part of the 574 CI signal. The remaining call function octet and its start and 575 stop bit need to be transmitted also, either as a series of V.21 576 bit events or in some other payload format. Presumably the 577 calling end gateway will use the same format for the CM and CJ 578 signals. 580 The overlapping nature of V.8 signalling means that there is no risk 581 of silence exceeding 100 ms once ANSam has disabled any echo control 582 circuitry. However, the 75 ms pause before entering operation in the 583 selected data mode will require both the calling and the answering 584 gateways to recognize the completion of CJ, so they can change from 585 playout of telephone-events to playout of the data-bearing payload 586 after the 75 ms period. 588 +--------+----------------------+------------+------+---------+ 589 | Event | Frequency (Hz) | Event Code | Type | Volume? | 590 +--------+----------------------+------------+------+---------+ 591 | ANSam | 2100 x 15 | 34 | tone | yes | 592 | | | | | | 593 | /ANSam | 2100 x 15 phase rev. | 35 | tone | yes | 594 | | | | | | 595 | CI | (V.21 bits) | 53 | tone | yes | 596 +--------+----------------------+------------+------+---------+ 598 Table 3: Events for V.8 signals 600 ANSam: 602 Modified answer tone ANSam consists of a sinewave signal at 2100 603 Hz, amplitude-modulated by a sine wave at 15 Hz. The beginning of 604 the event is at the beginning of the tone. The end of the event 605 is at the sooner of the ending of the tone or the occurence of a 606 phase reversal (marking the beginning of a /ANSam event). Phase 607 reversals are used to disable echo cancellation; if they are being 608 applied, they occur at 450 ms intervals. 610 An ANSam event packet SHOULD NOT be sent until it is possible to 611 discriminate between an ANSam event and an ANS event (see V.25 612 events, below). 614 The modulated envelope for the ANSam tone ranges in amplitude 615 between 0.8 and 1.2 times its average amplitude. The average 616 transmitted power is governed by national regulations. Thus it 617 makes sense to indicate the volume of the signal. 619 /ANSam: 621 /ANSam reports the same physical signal as ANSam, but is reported 622 following the first phase reversal in that signal. It begins with 623 the phase reversal and ends at the end of the tone. The receiver 624 of /ANSam MUST reverse the phase of the tone at the beginning of 625 playout of /ANSam and every 450 ms thereafter until the end of the 626 tone is reached. 628 CI: 630 CI reports the occurence of the V.21 bit pattern '11111 11111 631 00000 00001' indicating the beginning of a V.8 CI signal. The 632 event begins at the beginning of the first bit and ends at the end 633 of the last one. This event MUST NOT be reported except in a 634 context where a V.8 CI signal might be expected (i.e., at the 635 calling end during call setup). Note that if the calling modem 636 sends the CI signal at all, it will typically repeat the signal 637 several times. 639 It is expected that the CI event will be most useful when the 640 modem content is being transmitted primarily using another payload 641 type. The event acts as a commentary on that content, allowing 642 the receiver to recognize that V.8 signalling is in progress. 644 2.3.1. Handling of Congestion 646 The tolerances built into V.8 suggest that it may be mostly robust in 647 the face of packet losses or delays. Playout of ANSam and /ANSam can 648 be extended for multiple packetization periods without harm, provided 649 that phase reversals occur on schedule at 450 ms intervals during 650 playout of the latter. 652 To increase robustness of transmission of the V.21-based signals, 653 sending applications using the V.21 events SHOULD include an integral 654 number of octets, including start and stop bits, in each packet. The 655 presence of start and stop bits provides some hope that receiving 656 implementations can withstand unavoidable gaps in playout between 657 octets. When a message is being repeated (as is possible for CI, CM, 658 and JM), an even stronger robustness measure would be for the 659 receiver to retain a copy of the message when it is first received, 660 and when a packet is delayed or lost to continue playing out the 661 current message instance and commence a new repetition as if packets 662 had continued to arrive on schedule. 664 2.4. V.25 Events 666 V.25 [13] is a start-up protocol predating V.8 [9] and V.8 bis [10]. 667 It specifies the exchange of two tone signals: CT and ANS. 669 CT (calling tone) consists of a series of interrupted bursts of 1300 670 Hz tone, on for a duration of not less than 0.5 s and not more than 671 0.7 s and off for a duration of not less than 1.5 s and not more than 672 2.0 s. [13]. Modems not starting with the V.8 CI signal often use 673 this tone. 675 ANS (answering tone) is a 2100 Hz tone used to disable echo 676 suppression for data transmission [13], [8]. For FAX machines, 677 Recommendation T.30 [8] refers to this tone as called terminal 678 identification (CED) answer tone. ANS differs from V.8 ANSam in 679 that, unlike the latter, it has constant amplitude. 681 V.25 specifically includes procedures for disabling echo suppressors 682 as defined by ITU-T Rec. G.164 [6]. However, G.164 echo suppressors 683 have now for the most part been replaced by G.165 [7] echo 684 cancellers, which require phase reversals in the disabling tone (see 685 ANSam above). As a result, Recommendation V.25 was modified in July, 686 2001 to say that phase reversal in the ANS tone is required if echo 687 cancellers are to be disabled. 689 One possible V.25 sequence is as follows: 691 1. The calling terminal starts generating CT as soon as the call is 692 connected. 694 2. The called terminal waits in silence for 1.8 to 2.5 s after 695 answer, then begins to transmit ANS continuously. If echo 696 cancellers are on the line the phase of the ANS signal is 697 reversed every 450 ms. ANS will not reach the calling terminal 698 until the echo control equipment has been disabled. Since this 699 takes about a second it can only happen in the gap between one 700 burst of CT and the next. 702 3. Following detection of ANS, the calling terminal may stop 703 generating CT immediately or wait until the end of the current 704 burst to stop. In any event, it must wait at least 400 ms (at 705 least 1 s if phase reversal of ANS is being used to disable echo 706 cancellers) after stopping CT before it can generate the calling 707 station response tone. This tone is modem-specific, not 708 specified in V.25. 710 4. The called terminal plays out ANS for 2.6 to 4.0 seconds or until 711 it has detected calling station response for 100 ms. It waits 712 55- 95 ms (nominal 75 ms) in silence. (Note that the upper limit 713 of 95 ms is rather close to the point at which echo control may 714 reestablish itself.) If the reason for ANS termination was 715 timeout rather than detection of calling station response, the 716 called terminal begins to play out ANS again to maintain 717 disabling of echo control until the calling station responds. 719 The events defined for V.25 signalling are shown in Table 4. 721 +-------------------+----------------+------------+------+---------+ 722 | Event | Frequency (Hz) | Event Code | Type | Volume? | 723 +-------------------+----------------+------------+------+---------+ 724 | Answer tone (ANS) | 2100 | 32 | tone | yes | 725 | | | | | | 726 | /ANS | 2100 ph. rev. | 33 | tone | yes | 727 | | | | | | 728 | CT | 1300 | 49 | tone | yes | 729 +-------------------+----------------+------------+------+---------+ 731 Table 4: Events for V.25 signals 733 ANS: 735 The beginning of the event is at the beginning of the 2100 Hz 736 tone. The end of the event is at the sooner of the ending of the 737 tone or the occurence of a phase reversal (marking the beginning 738 of a /ANS event). 740 An initial ANS event packet SHOULD NOT be sent until it is 741 possible to discriminate between an ANS event and an ANSam event 742 (see V.8 events, above). 744 /ANS: 746 /ANS reports the same physical signal as ANS, but is reported 747 following the first phase reversal in that signal. It begins with 748 the phase reversal and ends at the end of the tone. The receiver 749 of /ANS MUST reverse the phase of the tone at the beginning of 750 playout of /ANS and every 450 ms thereafter until the end of the 751 tone is reached. 753 CT: 755 The beginning of the CT event is at the beginning of an individual 756 burst of the 1300 Hz tone. The end of the event is at the end of 757 that tone burst. The gateway at the calling end SHOULD use a 758 packetization interval smaller than the nominal duration of a CT 759 burst, to ensure that CT playout at the called end precedes the 760 sending of ANS from that end. 762 2.4.1. Handling of Congestion 764 The V.25 sequence appears to be robust in the face of lost or delayed 765 packets, provided that the receiver continues to play out any tone it 766 is in the process of playing until more packets are received. The 767 receiver must play out the phase transitions for /ANS on schedule, at 768 450 ms intervals, even if updates of the /ANS event have been 769 delayed. It also appears to be possible for the sender to 770 temporarily increase the packetization interval to reduce packet 771 volumes when congestion is encountered. The one risk is that 772 extended playout proceeds past the actual end of the tone (as 773 determined retroactively), and the receiver is forced to continue 774 imposing an additional playout buffering lag in order to meet the 775 constraint on maximum duration of the nominal 75 ms silent period 776 following tone playout. 778 2.5. V.32/V.32bis Events 780 ITU-T Recommendation V.32 [14] is a modem using phase-shift keying 781 with quadrature amplitude modification. It operates on a carrier at 782 1800 Hz, modulated at 2400 symbols/s. The basic data rates for V.32 783 are 4800 and 9600 bits/s. V.32bis [15] extends the data rates up to 784 14,400 bits/s. Most or all existing deployments are V.32bis, 785 typically in support of point-of-sale terminals and the like. 787 One reason V.32bis is still used is because of its relatively rapid 788 start-up sequence, particularly on leased lines. Operating over the 789 public telephone network, the start-up begins as follows: 791 a. the answering end begins with the V.25 answering procedure (1.8 792 to 2.5 s of silence followed by continuous ANS tone to a maximum 793 of 3.3 s, with possible phase reversals to disable echo 794 cancelling equipment); 796 b. the calling end waits in silence until it has detected ANS for 797 1 s; 799 c. the calling end begins to transmit a V.32/V.32bis pattern 800 designated AA, i.e., a series of '0000' bit sequences transmitted 801 at 4800 bits/s; 803 d. upon detecting the AA pattern for at least 100 ms, the called 804 modem is silent for 75 +/- 20 ms, then responds with an AC 805 pattern, which is a series of '0011' bit sequences transmitted at 806 4800 bits/s. 808 The difference in leased line operation is that the calling modem 809 starts the session by sending AA. After that, the called modem 810 responds with AC, and the rest of the sequence is unchanged. 812 In support of V.32/V.32bis operation, Table 5 defines two events, 813 V32AA and V32AC. 815 +----------------+------------------+------------+------+---------+ 816 | Event | Bit Pattern | Event Code | Type | Volume? | 817 +----------------+------------------+------------+------+---------+ 818 | V32AA | b'0000' repeated | 63 | tone | yes | 819 | | | | | | 820 | V32AC | b'0011' repeated | 27 | tone | yes | 821 +----------------+------------------+------------+------+---------+ 823 Table 5: Events for V.32/V.32bis signals 825 V32AA: 827 Indicates that the AA calling pattern of a V.32/V.32bis terminal 828 has been detected. 830 V32AC: 832 Indicates that the AC answering pattern of a V.32/V.32bis terminal 833 has been detected. 835 Each of these two events begins at the beginning of its pattern, and 836 ends nominally when the pattern stops being received. Following the 837 sending of either of these events the session may continue using 838 V.150.1 modem relay [32] or CLEARMODE [17] as negotiated or 839 configured in advance. To help make the transition as quickly as 840 possible, the V32AA or V32AC event SHOULD be reported as soon as the 841 corresponding pattern is detected. It seems likely that the 842 implementation will be transmitting the event reports simultaneously 843 with the same data in an alternate form, typically using RFC 2198 [2] 844 redundancy. 846 2.5.1. Handling of Congestion 848 The primary issue raised by congestion is the loss or undue delay of 849 the initial report. Once the receiver is aware that an AA or AC 850 pattern has been detected, further reports are of no interest. The 851 actual duration of the AC pattern may be quite short: as little as 27 852 ms. On this basis, the appropriate sender behaviour may be to send 853 at least three packets reporting the event using normal event updates 854 and end of event retransmission behaviour and a fairly short 855 packetization interval (20-30 ms). 857 2.6. T.30 Events 859 ITU-T Recommendation T.30 [8] defines the procedures used by Group 860 III FAX terminals. The pre-message procedures for which the events 861 of this section are defined are used to identify terminal 862 capabilities at each end and negotiate operating mode. Post-message 863 procedures are also included, to handle cases such as multiple 864 document transmission. FAX terminals support a wide variety of 865 protocol stacks, so T.30 has a number of options for control 866 protocols and sequences. 868 T.30 defines two tone signals used at the beginning of a call. The 869 CNG signal is sent by the calling terminal. It is a pure 1100 Hz 870 tone played in bursts: 0.5 s on, 3 s off. It continues until timeout 871 or until the calling terminal detects a response. Its primary 872 purpose is to let human operators at the called end know that a FAX 873 terminal has been activated at the calling end. 875 The called terminal waits in silence for at least 200 ms. It then 876 may return CED tone (which is physically identical to V.25 ANS), or 877 else V.8 ANSam if it has V.8 capability. If called and calling 878 terminals both support V.8, the called terminal will detect CI or 879 more likely CM in response to its ANSam and will continue with V.8 880 negotiation. Otherwise, the called terminal stops transmitting CED 881 after 2.6 to 4 seconds, waits 75 +/- 20 ms in silence, then enters 882 the T.30 negotiation phase. 884 In the T.30 negotiation phase the terminals exchange binary messages 885 using V.21 signals, high channel frequencies only, at 300 bits/s. 886 Each message is preceded by a one-second (nominal) preamble 887 consisting entirely of HDLC flag octets (0x7E). This flag has the 888 function of preparing echo control equipment for the message which 889 follows. 891 The pre-transfer messages exchanged using the V.21 coding are: 893 Digital Identification Signal (DIS): 895 Characterizes the standard ITU-T capabilities of the called 896 terminal. This is always the first message sent. 898 Digital Transmit Command (DTC): 900 A possible response to the DIS signal by the calling terminal. It 901 requests the called terminal to be the transmitter of the FAX 902 content. 904 Digital Command Signal (DCS): 906 A command message sent by the transmitting terminal to indicate 907 the options to be used in the transmission and request that the 908 other end prepare to receive FAX content. This is sent by the 909 calling end if it will transmit, or by the called end in response 910 to a DTC from the calling end. It is followed by a training 911 signal, also sent by the transmitting terminal. 913 Confirmation To Receive (CFR): 915 A digital response confirming that the entire pre-message 916 procedure including training has been completed and the message 917 transmissions may commence. 919 Each message may consist of multiple frames bounded by HDLC flags. 920 The messages are organized as a series of octets, but like V.8 bis, 921 T.30 calls for the insertion of extra '0' bits to prevent spurious 922 recognition of HDLC flags. 924 T.30 also provides for the transmission of control messages after 925 document transmission has completed (e.g., to support transmission of 926 multiple documents). The transition to and from the modem used for 927 document transmission (V.17 [24], V.27ter [26], V.29 [27], V.34 [28]) 928 is preceded by 75 ms (nominal) of silence). 930 Applications supporting T.30 signalling using the telephone-events 931 payload MAY report the preamble preceding each message both as a 932 series of V.21 bit events and, when it has been recognized, as a 933 single V.21 preamble event. The T.30 control message following the 934 preamble MAY be reported in the form of a sequence of V.21 bit events 935 or using some other payload type. If transmitted as bit events, the 936 transmitted information MUST include the complete contents of the 937 message: the initial HDLC flags, the information field, the checksum, 938 the terminating HDLC flags, and the extra '0' bits added to prevent 939 false recognition of HDLC flags at the receiver. Implementors should 940 note that these extra '0' bits mean that in general T.30 messages as 941 transmitted on the wire will not come out to an even multiple of 942 octets. 944 The training signal sent by the transmitting terminal after DCS 945 consists of a steady string of V.21 high channel zeros (1850 Hz tone) 946 for 1.5 s. Since the bit rate (nominally 300 bits/s) should have 947 been clearly established when processing the preceding signalling, it 948 is natural that if the telephony-event payload type is being used 949 this training signal will also be sent as a series of V.21 bit events 950 at that bit rate. However, if the sending gateway is capable of 951 recognizing the transition from the end of the DCS to the start of 952 training, it MAY report the training signal as a single extended V.21 953 (high channel) '0' event. 955 The events defined for T.30 signalling are shown in Table 6. The CED 956 and /CED events represent exactly the same tone signals as V.25 ANS 957 and /ANS, and are given the same codepoints; they are reproduced here 958 only for convenience. 960 +--------------------+----------------+------------+------+---------+ 961 | Event | Frequency (Hz) | Event Code | Type | Volume? | 962 +--------------------+----------------+------------+------+---------+ 963 | CED (Called tone) | 2100 | 32 | tone | yes | 964 | | | | | | 965 | /CED | 2100 ph. rev. | 33 | tone | yes | 966 | | | | | | 967 | CNG (Calling tone) | 1100 | 36 | tone | yes | 968 | | | | | | 969 | V.21 preamble flag | (V.21 bits) | 54 | tone | yes | 970 +--------------------+----------------+------------+------+---------+ 972 Table 6: Events for T.30 signals 974 CED: 976 The beginning of the event is at the beginning of the 2100 Hz 977 tone. The end of the event is at the sooner of the ending of the 978 tone or the occurence of a phase reversal (marking the beginning 979 of a /CED event). 981 An initial CED event packet SHOULD NOT be sent until it is 982 possible to discriminate between a CED event and an ANSam event 983 (see V.8 events, above). 985 /CED: 987 /CED reports the same physical signal as CED, but is reported 988 following the first phase reversal in that signal. It begins with 989 the phase reversal and ends at the end of the tone. The receiver 990 of /CED MUST reverse the phase of the tone at the beginning of 991 playout of /CED and every 450 ms thereafter until the end of the 992 tone is reached. 994 CNG: 996 The beginning of the CNG event is at the beginning of an 997 individual burst of the 1100 Hz tone. The end of the event is at 998 the end of that tone burst. 1000 V.21 preamble flag: 1002 This event begins with the first V.21 bits transmitted after a 1003 period of silence. It ends when a pattern of V.21 bits other than 1004 an HDLC flag is observed. This means that the V.21 preamble event 1005 absorbs the initial HDLC flags of the following message. 1007 It is expected that the V.21 preamble flag event will be most 1008 useful when the modem content is being transmitted primarily using 1009 another payload type. The event acts as a commentary on that 1010 content, allowing the receiver to prepare itself to transition to 1011 FAX mode. 1013 2.6.1. Handling of Congestion 1015 T.30 appears to be an intermediate case in terms of its vulnerability 1016 to congestion. Tone playout in the face of packet delay or loss is 1017 subject to the same considerations as for V.25 (see Section 2.4.1). 1018 Similarly, the receiver may extend playout of the preamble event 1019 while waiting for further reports. However, gaps or extended playout 1020 of the V.21 sequences are not feasible. This means, as with V.8 bis, 1021 that the receiver must manage its playout buffer appropriately to 1022 increase robustness in the face of congestion. 1024 2.7. Events For Text Telephony 1026 2.7.1. Signal Format Indicators For Text Telephony 1028 Legacy text telephony uses a wide variety of terminals, with 1029 different standards favoured in different parts of the world. Going 1030 forward, the vision is that new terminals will work directly into the 1031 packet network and be based on RFC 4103 [18] packetization of 1032 character data. In anticipation of this migration, it is RECOMMENDED 1033 that text carried in the PSTN by legacy modem protocols be converted 1034 to RFC 4103 packets at the sending gateway. 1036 During a transitional period, however, gateways of a lesser 1037 capability may be able to recognize the nature of incoming content, 1038 but may only be able to encode it as voice-band data on the packet 1039 side. In such circumstances, it will help to optimize processing of 1040 the signal at the receiving end if that end receives an indication of 1041 the nature of the voice-encoded data signals. The events defined in 1042 this section provide such indications, and MAY be used in conjunction 1043 with ITU-T Recommendation V.152 [33], as one example, to carry the 1044 content as voice-band data. 1046 Implementors should take note of an additional class of text 1047 terminals not considered in the events below. These terminals use 1048 DTMF tones to encode and exchange signals. This application is 1049 described in RFC xxxx [5] section 3.1, in conjunction with the 1050 registration of DTMF events. 1052 The events shown in Table 7 correspond to signals coming from the 1053 following modem types: 1055 o Baudot [34], a five bit character encoding nominally operating at 1056 45.45 or 50 bits/s with frequencies 1800 Hz = '0', 1400 Hz = '1'; 1058 o EDT, which is V.21 [12] operating at 110 bits/s in half-duplex 1059 mode (lower channel only); characters are 7 bit IA5 plus initial 1060 start bit, trailing parity bit, and two stop bits; 1062 o Bell 103 mode (documented in Recommendation V.18 Annex D), which 1063 is structurally similar to V.21, but uses different frequencies: 1064 lower channel, 1070 Hz = '0', 1270 Hz = '1'; upper channel, 2025 1065 Hz = '0', 2225 Hz = '1'; characters are US ASCII framed by one 1066 start bit, one trailing parity bit, and one stop bit; 1068 o V.23 [25] based videotex, in Minitel and Prestel versions. V.23 1069 offers a forward channel operating at 1200 bits/s if possible 1070 (2100 Hz = '0', 1300 Hz = '1') or otherwise at 600 bits/s (1700 Hz 1071 = '0', 1300 Hz = '1'), and a 75 bits/s backward channel which is 1072 transmitting 390 Hz (continuous '1's) except when '0' is to be 1073 transmitted (450 Hz); 1075 o a non-V.18 text terminal using V.21 [12] at 300 bits/s. 1076 Characters are 7 bit national (e.g., US ASCII) with a start bit, 1077 parity, and one stop bit. 1079 +----------+-----------+----------------+---------+-------+---------+ 1080 | Event | Bit Rate | Frequency (Hz) | Event | Type | Volume? | 1081 | | bits/s | | Code | | | 1082 +----------+-----------+----------------+---------+-------+---------+ 1083 | ANS2225 | N/A | 2225 | 52 | tone | yes | 1084 | | | | | | | 1085 | V21L110 | 110 | 980/1180 | 55 | other | no | 1086 | | | | | | | 1087 | V21L300 | 300 | 980/1180 | 30 | other | no | 1088 | | | | | | | 1089 | V21H300 | 300 | 1650/1850 | 31 | other | no | 1090 | | | | | | | 1091 | B103L300 | 300 | 1070/1270 | 56 | other | no | 1092 | | | | | | | 1093 | V23Main | 600/1200 | 1700-2100/1300 | 57 | other | no | 1094 | | | | | | | 1095 | V23Back | 75 | 450/390 | 58 | other | no | 1096 | | | | | | | 1097 | Baud4545 | 45.45 | 1800/1400 | 59 | other | no | 1098 | | | | | | | 1099 | Baud50 | 50 | 1800/1400 | 60 | other | no | 1100 | | | | | | | 1101 | XCIMark | 1200 | 2100/1300 | 62 | tone | yes | 1102 +----------+-----------+----------------+---------+-------+---------+ 1104 Table 7: Indicators for text telephony 1106 ANS2225: 1108 indicates that a 2225 Hz answer tone has been detected. This is a 1109 pure tone with no amplitude modulation and no semantics attached 1110 to phase reversals, if there are any. The sender SHOULD report 1111 the beginning of the event when the tone is detected. The sender 1112 MAY send updates as the tone continues, and MUST report the end of 1113 the event when the tone ceases. The tone concerned is generated 1114 by a Bell 103-type modem in answer mode. This event MUST NOT be 1115 reported outside of the startup context (i.e., on the answering 1116 side at the beginning of a call). 1118 V21L110: 1120 indicates that the sender has detected V.21 modulation operating 1121 in the lower channel at 110 bits/s. Note that it may take some 1122 time to distinguish between 300 bits/s and 110 bits/s operation. 1123 It is expected that implementations will not transmit both this 1124 event and individual V.21 bit events for the same content. 1126 V21L300: 1128 indicates that the sender has detected V.21 modulation operating 1129 in the lower channel at 300 bits/s. Note that it may take some 1130 time to distinguish between 300 bits/s and 110 bits/s operation. 1131 It is expected that implementations will not transmit both this 1132 event and individual V.21 bit events for the same content. 1134 V21H300: 1136 indicates that the sender has detected V.21 modulation operating 1137 in the upper channel at 300 bits/s. It is expected that 1138 implementations will not transmit both this event and individual 1139 V.21 bit events for the same content. 1141 B103L300: 1143 indicates that the sending device has detected Bell 103 class 1144 modulation operating in the low channel at 300 bits/s. 1146 V23Main: 1148 indicates that the sending device has detected V.23 modulation 1149 operating in the high speed channel. As described below, this 1150 indicator may alternate with the XCIMark indication. 1152 V23Back: 1154 indicates that the sending device has detected V.23 modulation 1155 operating in the 75 bit/s back-channel. 1157 Baud4545: 1159 indicates that the sending device has detected Baudot modulation 1160 operating at 45.45 bits/s. 1162 Baud50: 1164 indicates that the sending device has detected Baudot modulation 1165 operating at 50 bits/s. 1167 XCIMark: 1169 Indicates that the sending device has detected the specific bit 1170 pattern (0) 1111 1111(1)(0)1111 1111(1) sent at 1200 bits/s using 1171 V.23 upper channel modulation, following a period of V.23 main 1172 channel "mark" (1300 Hz). 1174 It is assumed in all cases that the event reports described here are 1175 being transmitted in addition to another media encoding, typically 1176 G.711 [19] voice-band data, reporting the same information. A 1177 natural method to do this is to combine the voice-band data with 1178 event reports in an RFC 2198 [2] redundancy payload. 1180 The handling of ANS2225 has been indicated above. Since it is a 1181 specific tone, it can be handled like any other tone event. 1183 For all of the other indicators, the sender SHOULD generate an 1184 initial event report as soon as the nature of the audio content has 1185 been recognized. For reliability, the initial event report SHOULD be 1186 retransmitted twice at short intervals. (20 ms is a suggested value, 1187 although the packetization period of the associated media may be 1188 sufficient.) The sender MAY continue to send additional reports of 1189 the same indicator event, although these have little value once the 1190 receiver has adjusted itself to the type of content it is receiving. 1192 If the nature of the content changes (e.g., because it is coming from 1193 a V.18 terminal in the probing stage), the sender MUST send an event 1194 report for the new content type as soon as it is recognized. If the 1195 sender has been sending updates for the previous indicator, it SHOULD 1196 report the end of that previous indicator event along with the 1197 beginning of the new one. 1199 2.7.1.1. Handling of Congestion 1201 In the face of packet loss or delay, it is appropriate for the 1202 receiver to continue to play out the ANS2225 event until further 1203 packets are received. For the other events, the issue is loss of the 1204 initial event report rather than maintenance of playout continuity. 1205 The advice on retransmission of these other events already given 1206 above is sufficient to deal with packet loss or delay due to 1207 congestion. 1209 2.7.2. Use of Events With V.18 Modems 1211 ITU-T Recommendation V.18 [11] defines a terminal for text 1212 conversation, possibly in combination with voice. V.18 is intended 1213 to interoperate with a variety of legacy text terminals, so its 1214 start-up sequence can consist of a series of stimuli designed to 1215 determine what is at the other end. Two V.18 terminals talking to 1216 each other will use V.8 to negotiate startup and continue at the 1217 physical level with V.21 at 300 bits/s carrying 7-bit characters 1218 bounded by start and stop bits. 1220 The V.18 terminal is also designed to interoperate with the text 1221 modems listed in the previous sub-section. The startup sequences for 1222 all these different terminal types are naturally quite different. 1223 The V.18 initial startup sequence specifically addresses itself to 1224 V.8-capable terminals and V.21 terminals and, by the combination of 1225 signals, to V.23 videotex terminals. During the initial startup 1226 sequence the V.18 terminal listens for frequency responses 1227 characterizing the other terminal types. If it does not make contact 1228 in the preliminary step it probes for each type specifically. By the 1229 nature of the application, V.18 has been designed to provide an 1230 extremely robust startup capability. 1232 The handling of the V.18 XCI signal is a specific case of the 1233 procedures described in the previous section. XCI is a signal 1234 transmitted in high-band V.23 modulation to stimulate V.23 terminals 1235 to respond and to allow detection of V.18 capabilities in a DCE. The 1236 3 second XCI signal uses the V.23 upper channel having periods of 1237 "mark" (i.e. 1300 Hz) alternating with the XCIMark pattern. The full 1238 definition is found in V.18 section 3.13. The sender SHOULD indicate 1239 V23Main during the transmission of the "mark" portion of XCI, and 1240 change the indication to XCIMark when that pattern is detected. 1242 2.8. A Generic Indicator 1244 Numerous proprietary modem protocols exist, as well as standardized 1245 protocols not identified above. Table 8 defines a single indicator 1246 event which may be used to identify modem content when a more 1247 specific event is unavailable. Typically this would be sent in 1248 combination with another payload type, for example, voice-band data 1249 as specified by ITU-T Recommendation V.152 [33]. 1251 As with the indicators in the previous section, the sender SHOULD 1252 generate an initial event report as soon as the nature of the audio 1253 content has been recognized. For reliability, the initial event 1254 report SHOULD be retransmitted twice at short intervals. (20 ms is a 1255 suggested value, although the packetization period of the associated 1256 media may be sufficient.) The sender MAY continue to send additional 1257 reports of the VBDGen event, although these have little value once 1258 the receiver has adjusted itself to the type of content it is 1259 receiving. 1261 +--------+---------------+------------+-----------+-------+---------+ 1262 | Event | Bit Rate | Frequency | Event | Type | Volume? | 1263 | | bits/s | (Hz) | Code | | | 1264 +--------+---------------+------------+-----------+-------+---------+ 1265 | VBDGen | Variable | Variable | 61 | other | no | 1266 +--------+---------------+------------+-----------+-------+---------+ 1268 Table 8: Generic modem signal indicator 1270 VBDGen: 1272 indicates that the sender has detected tone patterns indicating 1273 the operation of some form of modem. This indicator SHOULD NOT be 1274 sent if a more specific event is available. 1276 3. Strategies For Handling FAX and Modem Signals 1278 As described in Section 1.2, the typical data application involves a 1279 pair of gateways interposed between two terminals, where the 1280 terminals are in the PSTN. The gateways are likely to be serving a 1281 mixture of voice and data traffic, and need to adopt payload types 1282 appropriate to the media flows as they occur. If voice compression 1283 is in use for voice calls, this means that the gateways need the 1284 flexibility to switch to other payload types when data streams are 1285 recognized. 1287 Within the established IETF framework, this implies that the gateways 1288 must negotiate the potential payloads (voice, telephone-events, 1289 tones, voice-band data, T.38 FAX [21], and possibly RFC 4103 [18] 1290 text and CLEARMODE [17] octet streams) as separate payload types. 1291 From a timing point of view, this is most easily done at the 1292 beginning of a call, but results in an over-allocation of resources 1293 at the gateways and in the intervening network. 1295 One alternative is to use named events to buy time while out-of-band 1296 signals are exchanged to update to the new payload type applicable to 1297 the session. Thanks to the events defined in this document, this is 1298 a viable approach for sessions beginning with V.8, V.8 bis, T.30, or 1299 V.25 control sequences. 1301 Named data-related events also allow gateways to optimize their 1302 operation when data signals are received in a relatively general 1303 form. One example is the use of V.8-related events to deduce that 1304 the voice-band data being sent in a G.711 payload comes from a 1305 higher-speed modem and therefore requires disabling of echo 1306 cancellers. 1308 All of the control procedures described in the sub-sections of 1309 Section 2 eventually give way to data content. As mentioned above, 1310 this content will be carried by other payload types. Receiving 1311 gateways MUST be prepared to switch to the other payload type within 1312 the time constraints associated with the respective applications. 1313 (For several of the procedures documented above, the sender provides 1314 75 ms of silence between the initial control signalling and the 1315 sending of data content.) In some cases (V.8 bis [10], T.30 [8]), 1316 further control signalling may happen after the call has been 1317 established. 1319 A possible strategy is to send both telephone-events and the data 1320 payload in an RFC 2198 [2] redundancy arrangement. The receiving 1321 gateway then propagates the data payload whenever no event is in 1322 progress. For this to work, the data payload and events (when 1323 present) MUST cover exactly the same content over the same time 1324 period; otherwise spurious events will be detected downstream. An 1325 example of this mode of operation is shown below. 1327 Note that there are a number of cases where no control sequence will 1328 precede the data content. This is true, for example, for a number of 1329 legacy text terminal types. In such instances, the events defined in 1330 Section 2.7 in particular MAY be sent to help the remote gateway 1331 optimize its handling of the alternative payload. 1333 4. Example of V.8 Negotiation 1335 This section presents an example of the use of the event codes 1336 defined in Section 2. The basic scenario is the startup sequence for 1337 duplex V.34 modem operation. It is assumed that once the initial V.8 1338 sequence is complete the gateways will enter into voice band data 1339 operation using G.711 encoding to transmit the modem signals. The 1340 basic packet sequence is indicated in Table 9. Sample packets are 1341 then shown in detail for two variants on event transmission strategy: 1343 o simultaneous transmission of events and retransmitted events using 1344 RFC 2198 [2] redundancy; 1346 o simultaneous transmission of events, retransmitted events, and 1347 voice band data covering the same content using RFC 2198 1348 redundancy. 1350 For simplicity and semi-realism, the times shown for the example 1351 scenario assume a fixed lag at each gateway of 20 ms between the 1352 packet side of the gateway and the local user equipment and vice 1353 versa (i.e., minimum of 40 ms between packet received and packet sent 1354 specifically in response to the received packet). A propagation 1355 delay of 5 ms is assumed between gateways. It is assumed that the 1356 event packetization interval is 30 ms, a reasonable compromise 1357 between packet volume and buffering delay, particularly for V.21 1358 events. 1360 At the basic V.8 protocol level, the table assumes that the answering 1361 modem waits 0.2 s (200 ms) from the beginning of the call to start 1362 transmitting ANSam. The calling modem waits 1 s (1000 ms) from the 1363 time it begins to receive ANSam until it begins to send the V.8 CM 1364 signal. Both modems wait 75 ms from the time they finish sending and 1365 receiving CJ respectively until they begin sending V.34 modem 1366 signals. 1368 +------------+------------------------------------------------------+ 1369 | Time (ms) | Event | 1370 +------------+------------------------------------------------------+ 1371 | 220.0 | The called gateway detects the start of ANSam from | 1372 | | its end. | 1373 | | | 1374 | 250.0 | The called gateway sends out the first ANSam event | 1375 | | packet. M bit is set, timestamp is ts0 + 1760 | 1376 | | (where ts0 is the timestamp value at the start of | 1377 | | the call). The initial ANSam event continues until | 1378 | | a phase shift is detected at 670.0 ms (see below). | 1379 | | Up to this time, the called gateway sends out | 1380 | | further ANSam event updates, with the same initial | 1381 | | timestamp, M bit off, and cumulative duration | 1382 | | increasing by 240 units each time. | 1383 | | | 1384 | 255.0 | The calling gateway receives the first ANSam event | 1385 | | report and begins playout of ANSam tone at its end. | 1386 | | | 1387 | 275.0 | The calling terminal receives the beginning of ANSam | 1388 | | tone and starts its timer. It will begin sending | 1389 | | the CM signal 1 s later (at 1275.0 ms into the | 1390 | | call). | 1391 | | | 1392 | 670.0 | The called gateway detects a phase shift in the | 1393 | | incoming signal, marking a change from ANSam to | 1394 | | /ANSam. This happens to coincide with the end of a | 1395 | | packetization interval. For the sake of the | 1396 | | example, assume that the called gateway does not | 1397 | | detect this in time for the event report it sends | 1398 | | out. | 1399 | | | 1400 | 700.0 | The called gateway issues its next-scheduled event | 1401 | | report packet, indicating an initial report for | 1402 | | /ANSam (M-bit set, timestamp ts0 + 5360, duration | 1403 | | 240 timestamp units). The packet also carries the | 1404 | | first retransmission of the final ANSam report, | 1405 | | total duration 3600 units, this time with the E-bit | 1406 | | set. | 1407 | | | 1408 | 1120.0 | The called gateway detects another phase shift and | 1409 | | subsequently reports the end of /ANSam and the | 1410 | | beginning of ANSam. | 1411 | | | 1412 | 1295.0 | The calling gateway begins to receive the CM signal | 1413 | | from the calling modem. | 1414 | | | 1415 | 1325.0 | The calling gateway sends a packet containing the | 1416 | | first 9 bits of the CM signal. | 1417 | | | 1418 | 1445.0 | The calling gateway sends out a packet containing | 1419 | | the last 4 bits of the first CM signal, plus the | 1420 | | first 5 bits of the next repetition of that signal. | 1421 | | CM bits will continue to be transmitted from the | 1422 | | calling gateway until 2015.0 ms (see below), for a | 1423 | | total of 24 packets. (The final packet also carries | 1424 | | the beginning of the CJ signal.) | 1425 | | | 1426 | 1570.0 | The called gateway detects another phase shift and | 1427 | | subsequently reports the end of ANSam and the | 1428 | | beginning of /ANSam. | 1429 | | | 1430 | 1596.7 | The called gateway completes playout of the final | 1431 | | bit of the second occurence of the CM signal. | 1432 | | | 1433 | 1636.7 | The called gateway detects end of /ANSam (and | 1434 | | beginning of JM) from the called modem. The next | 1435 | | packet is not yet due to go out. | 1436 | | | 1437 | 1660.0 | The called gateway sends out a packet combining the | 1438 | | final /ANSam event report (E-bit set and total | 1439 | | duration 533 timestamp units) with the first 7 bits | 1440 | | of the JM signal. The M-bit for the packet is set | 1441 | | and the packet timestamp is ts0 + 12560 (the start | 1442 | | of the now-discontinued /ANSam event). | 1443 | | | 1444 | 1690.0 | The called gateway sends out a packet containing the | 1445 | | next nine bits of JM signal. The M-bit is set and | 1446 | | the timestamp is ts0 + 13280 (beginning of the first | 1447 | | bit in the packet). JM will continue to be | 1448 | | transmitted until 2170.0 ms (see below), for a total | 1449 | | of 18 packets (plus two for final retransmissions). | 1450 | | | 1451 | 1938.3 | The calling gateway completes playout of the final | 1452 | | packet of the second occurence of the JM signal. | 1453 | | | 1454 | 1995.0 | The calling gateway begins to receive the initial | 1455 | | bits of the CJ signal. | 1456 | | | 1457 | 2015.0 | The calling gateway sends a packet containing the | 1458 | | final 3 bits of the first decad of a CM signal and | 1459 | | first 6 bits of a CJ signal. | 1460 | | | 1461 | 2095.0 | The calling gateway receives the last bit of the CJ | 1462 | | signal. A period of silence lasting 75 ms begins at | 1463 | | the called end. It is not yet time to send out an | 1464 | | event report. | 1465 | | | 1466 | 2105.0 | The calling gateway sends out a packet containing | 1467 | | the final 6 bits of the CJ signal. | 1468 | | | 1469 | 2130.0 | The called gateway finishes playing out the last CJ | 1470 | | signal bit sent to it. | 1471 | | | 1472 | 2135.0 | The calling gateway sends a packet containing no new | 1473 | | events, but retransmissions of the last 15 bits of | 1474 | | the CJ signal (in two generations). | 1475 | | | 1476 | 2165.0 | The calling gateway sends out a packet containing no | 1477 | | new events, but retransmissions of the final 6 bits | 1478 | | of the CJ signal. | 1479 | | | 1480 | 2170.0 | The called gateway sends out the last packet | 1481 | | containing bits of the JM signal (except for | 1482 | | retransmissions). Note that according to the V.8 | 1483 | | specification these bits do not in general complete | 1484 | | a JM signal or even an "octet" of that signal | 1485 | | (although they happen to do so in this example). A | 1486 | | 75 ms period of silence begins at the called end. | 1487 | | | 1488 | 2170.0 | The calling gateway begins to receive V.34 | 1489 | | signalling from the called modem. | 1490 | | | 1491 | 2175.0 | The calling gateway finishes playing out the last JM | 1492 | | signal bit sent to it. | 1493 | | | 1494 | 2195.0 | The calling gateway sends out a first packet of V.34 | 1495 | | signalling as voice band data (PCMU). Timestamp is | 1496 | | ts0 + 17360 and M-bit is set to indicate the | 1497 | | beginning of content after silence. The packet | 1498 | | contains 200 8-bit samples. Packetization interval | 1499 | | is shown here as continuing to be 30 ms. It could | 1500 | | be less, but MUST NOT be more because that would | 1501 | | make the silent period too long. | 1502 | | | 1503 | 2200.0 | The called gateway sends a packet containing no new | 1504 | | events, but retransmissions of the last 18 bits of | 1505 | | the JM signal (in two generations). | 1506 | | | 1507 | 2225.0 | The calling gateway sends out the second packet of | 1508 | | V.34 signalling as voice band data (PCMU). | 1509 | | Timestamp is ts0 + 17560 and M-bit is not set. The | 1510 | | packet contains 240 8-bit samples. | 1511 | | | 1512 | 2230.0 | The called gateway sends out a packet containing no | 1513 | | new events, but retransmissions of the final 9 bits | 1514 | | of the JM signal. | 1515 | | | 1516 | 2245.0 | The called gateway begins to receive V.34 signalling | 1517 | | from the called modem. | 1518 | | | 1519 | 2255.0 | The calling gateway sends out a third packet of V.34 | 1520 | | signalling as voice band data (PCMU). Timestamp is | 1521 | | ts0 + 17800 and M-bit is not set. The packet | 1522 | | contains 240 8-bit samples. | 1523 | | | 1524 | 2260.0 | The called gateway sends out a first packet of V.34 | 1525 | | signalling as voice band data (PCMU). Timestamp is | 1526 | | ts0 + 17960 and M-bit is set to indicate the | 1527 | | beginning of content after silence. The packet | 1528 | | contains 120 samples. Packetization interval is | 1529 | | shown here as continuing to be 30 ms. It could be | 1530 | | less, but MUST NOT be more because that would make | 1531 | | the silent period too long. | 1532 | | | 1533 | . . . | . . . | 1534 +------------+------------------------------------------------------+ 1536 Table 9: Events for Example V.8 Scenario 1538 4.1. Simultaneous Transmission of Events and Retransmitted Events Using 1539 RFC 2198 Redundancy 1541 Negotiation of the transmission mode being described in this section 1542 would use SDP similar to the following: 1544 m=audio 12343 RTP/AVP 99 1545 a=rtpmap:99 pcmu/8000 1546 m=audio 12345 RTP/AVP 100 101 1547 a=rtpmap:100 red/8000/1 1548 a=fmtp:100 101/101/101 1549 a=rtpmap:101 telephone-event/8000 1550 a=fmtp:101 0-15,32-41,43,46,48-49,52-68 1552 This indicates two media streams, the first for G.711 (i.e., voice or 1553 voice-band data), the second for triply-redundant telephone events. 1554 As RFC 2198 notes, it is also possible for the sender to send 1555 telephone-event payloads without redundancy in the second stream, 1556 although the redundant form is the primary transmission mode. (It 1557 would be reasonable to send the interim ANSam reports without 1558 redundancy.) The set of telephone events supported includes the DTMF 1559 events (not relevant in this example), and all of the data events 1560 defined in this document. In fact, only event codes 34-35 and 37-40 1561 are used in the example. 1563 For the purpose of illustrating the use of RFC 2198 redundancy as 1564 well as showing the basic composition of the event reports, the 1565 second packet reporting JM signal bits (sent by the called gateway at 1566 1690.0 ms) seems to be a good choice. This packet will also carry 1567 the second retransmission of the final /ANSam event report and the 1568 first retransmission of the initial 7 bits of the JM signal. The 1569 detailed content of the packet is shown in Figure 1. To see the 1570 contents of the successive generations more clearly, they are 1571 presented as if they were aligned on successive 32-bit boundaries. 1572 In fact, they are all offset by one octet, following on consecutively 1573 from the RFC 2198 header. 1575 The M-bit is set in the RTP header for the packet, as required for 1576 the coding of multiple events in the primary block of data. In fact, 1577 RFC 2198 implies that this is the correct behaviour, but does not say 1578 so explicitly. The E-bit is set for every event. It is possible 1579 that it would not be set for the final event in the primary block. 1581 0 1 2 3 1582 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 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 |V=2|P|X| CC=0 |1| PT=100 | sequence number = seq0 + 48 | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | timestamp = ts0 + 13280 | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | synchronization source (SSRC) identifier | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 |1| block PT=101| timestamp offset = 720 | block length = 4 | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 |1| block PT=101| timestamp offset = 267 | block length = 28 | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 |0| block PT=101| (begin block for /ANSam ...) 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 /ANSam block (second retransmission) 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | event = 35 |1|R| volume | duration = 533 | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 First 7 bits of JM (="1111111" in V.21 high channel) 1604 (first retransmission) 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | event = 40 |1|R| volume | duration = 27 | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 / (5 similar events, durations 27,26,27,27,26 respectively) / 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | event = 40 |1|R| volume | duration = 27 | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 Next 9 bits of JM (="111000000" in V.21 high channel) 1615 (new content) 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | event = 40 |1|R| volume | duration = 27 | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 / (7 similar events, codes 40,40,39,39,39,39,39 and / 1621 / durations 26,27,27,26,27,27,26 respectively) / 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | event = 39 |1|R| volume | duration = 27 | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 Figure 1: Packet Contents, Redundant Events Only 1628 Since all of the events in the above packet are consecutive and 1629 adjacent, it would have been permissible according to the telephone- 1630 events payload specification to carry them as a simple event payload 1631 without the RFC 2198 header. The advantage of the latter is that the 1632 receiving gateway can skip over the retransmitted events when 1633 processing the packet, unless it needs them. 1635 4.2. Simultaneous Transmission of Events and Voice Band Data Using RFC 1636 2198 Redundancy 1638 Negotiation of the transmission mode being described in this section 1639 would use SDP similar to the following: 1641 m=audio 12343 RTP/AVP 99 100 101 1642 a=rtpmap:99 red/8000/1 1643 a=fmtp:99 100/101/101/101 1644 a=rtpmap:100 pcmu/8000 1645 a=rtpmap:101 telephone-event/8000 1646 a=fmtp:101 0-15,32-41,43,46,48-49,52-68 1648 This indicates one media stream, with G.711 (i.e., voice or voice- 1649 band data) as the primary content, along with three blocks of 1650 telephone events. RFC 2198 requires that the more voluminous 1651 representation (i.e., the G.711) be the primary one. The most recent 1652 block of events covers the same time period as the voice-band data. 1653 The other two streams provide the first and second retransmissions of 1654 the events as in the previous example. Because G.711 is the primary 1655 content, the M-bit for the packets will in general not be set, except 1656 after periods of silence. 1658 Figure 2 shows the detailed packet content for the same sample point 1659 as in the previous figure, but including the G.711 content. 1661 0 1 2 3 1662 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 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 |V=2|P|X| CC=0 |0| PT=99 | sequence number = seq0 + 48 | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | timestamp = ts0 + 13280 | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | synchronization source (SSRC) identifier | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 |1| block PT=101| timestamp offset = 720 | block length = 4 | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 |1| block PT=101| timestamp offset = 267 | block length = 28 | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 |1| block PT=101| timestamp offset = 0 | block length = 36 | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 |0| block PT=100| (begin block for /ANSam ...) 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 /ANSam block (second retransmission) 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | event = 35 |1|R| volume | duration = 533 | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 First 7 bits of JM (="1111111" in V.21 high channel) 1686 (first retransmission) 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | event = 40 |1|R| volume | duration = 27 | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 / (5 similar events, durations 27,26,27,27,26 respectively) / 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 | event = 40 |1|R| volume | duration = 27 | 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 Next 9 bits of JM (="111000000" in V.21 high channel) 1697 (new content) 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | event = 40 |1|R| volume | duration = 27 | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 / (7 similar events, codes 40,40,39,39,39,39,39 and / 1703 / durations 26,27,27,26,27,27,26 respectively) / 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | event = 39 |1|R| volume | duration = 27 | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 30 ms of G.711-encoded voice-band data (240 samples) 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Sample 1 | Sample 2 | Sample 3 | Sample 4 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 / . . . / 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | Sample 237 | Sample 238 | Sample 239 | Sample 240 | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 Figure 2: Packet Contents With Voice-Band Data Combined With Events 1720 5. Security Considerations 1722 The V.21 bit events defined in this document may be used to transmit 1723 user-sensitive data. This could include initial log-on sequences and 1724 application-level protocol exchanges as well as user content. As a 1725 result, such an usage of V.21 bit events entails, in the terminology 1726 of [16], threats to both communications and system security. The 1727 attacks of concern are: 1729 o confidentiality violations and password sniffing; 1731 o hijacking of data sessions through message insertion; 1733 o modification of the transmitted content through man-in-the-middle 1734 attacks; 1736 o denial of service by means of message insertion, deletion, and 1737 modification aimed at interference with the application protocol. 1739 To prevent these attacks, the transmission of V.21 bit events MUST be 1740 given confidentiality protection. Message authentication and the 1741 protection of message integrity MUST also be provided. These address 1742 the threats posed by message insertion and modification. With these 1743 measures in place, RTP sequence numbers and the redundancy provided 1744 by the RFC xxxx procedures for transmission of events add protection 1745 against and some resiliency in the face of message deletion. 1747 The other events defined in this document (and V.21 bit events within 1748 control sequences) are used only for the setup and control of 1749 sessions between data terminals or FAX devices. While disclosure of 1750 these events would not expose user-sensitive data, it can potentially 1751 expose capabilities of the user equipment that could be exploited by 1752 attacks in the PSTN domain. Thus confidentiality protection SHOULD 1753 be provided. The primary threat is denial of service, through 1754 injection of inappropriate signals at vulnerable points in the 1755 control sequence, or through alteration or blocking of enough event 1756 packets to disrupt that sequence. To meet the injection threat, 1757 message authentication and integrity protection MUST be provided. 1759 The Secure Real-time Transport Protocol (SRTP) [4] meets the 1760 requirements for protection of confidentiality, message integrity, 1761 and message authentication described above. It SHOULD therefore be 1762 used to protect media streams containing the events described in this 1763 document. 1765 Note that the appropriate method of key distribution for SRTP may 1766 vary with the specific application. 1768 In some deployments it may be preferable to use other means to 1769 provide protection equivalent to that provided by SRTP. 1771 6. IANA Considerations 1773 This document adds the events in Table 10 to the registry established 1774 by RFC xxxx [5]. 1776 +-------+--------------------------------------------+--------------+ 1777 | Event | Event Name | Reference | 1778 | Code | | | 1779 +-------+--------------------------------------------+--------------+ 1780 | 23 | CRdSeg: second segment of V.8 bis CRd | | 1781 | | signal | | 1782 | | | | 1783 | 24 | CReSeg: second segment of V.8 bis CRe | | 1784 | | signal | | 1785 | | | | 1786 | 25 | MRdSeg: second segment of V.8 bis MRd | | 1787 | | signal | | 1788 | | | | 1789 | 26 | MReSeg: second segment of V.8 bis MRe | | 1790 | | signal | | 1791 | | | | 1792 | 27 | V32AC: A pattern of bits modulated at 4800 | | 1793 | | bits/s, emitted by a V.32/V.32bis | | 1794 | | answering terminal upon detection of the | | 1795 | | AA pattern. | | 1796 | | | | 1797 | 28 | V8bISeg: first segment of initiating V.8 | | 1798 | | bis signal | | 1799 | | | | 1800 | 29 | V8bRSeg: first segment of responding V.8 | | 1801 | | bis signal | | 1802 | | | | 1803 | 30 | V21L300: 300 bits/s low channel V.21 | | 1804 | | indication | | 1805 | | | | 1806 | 31 | V21H300: 300 bits/s high channel V.21 | | 1807 | | indication | | 1808 | | | | 1809 | 32 | ANS (V.25 Answer tone). Also known as CED | | 1810 | | (T.30 Called tone). | | 1811 | | | | 1812 | 33 | /ANS (V.25 Answer tone after phase shift). | | 1813 | | Also known as /CED (T.30 Called tone after | | 1814 | | phase shift) | | 1815 | | | | 1816 | 34 | ANSam (V.8 amplitude modified Answer tone) | | 1817 | | | | 1818 | 35 | /ANSam (V.8 amplitude modified Answer tone | | 1819 | | after phase shift) | | 1820 | | | | 1821 | 36 | CNG (T.30 Calling tone) | | 1822 | | | | 1823 | 37 | V.21 channel 1 (low channel), '0' bit | | 1824 | | | | 1825 | 38 | V.21 channel 1, '1' bit. Also used for | | 1826 | | ESiSeg (second segment of V.8 bis ESi | | 1827 | | signal). | | 1828 | | | | 1829 | 39 | V.21 channel 2, '0' bit | | 1830 | | | | 1831 | 40 | V.21 channel 2, '1' bit. Also used for | | 1832 | | ESrSeg (second segment of V.8 bis ESr | | 1833 | | signal). | | 1834 | | | | 1835 | 49 | CT (V.25 Calling Tone) | | 1836 | | | | 1837 | 52 | ANS2225: 2225 Hz indication for text | | 1838 | | telephony | | 1839 | | | | 1840 | 53 | CI (V.8 Call Indicator signal preamble) | | 1841 | | | | 1842 | 54 | V.21 preamble flag (T.30) | | 1843 | | | | 1844 | 55 | V21L110: 110 bits/s V.21 indication for | | 1845 | | text telephony | | 1846 | | | | 1847 | 56 | B103L300: Bell 103 low channel indication | | 1848 | | for text telephony | | 1849 | | | | 1850 | 57 | V23Main: V.23 main channel indication for | | 1851 | | text telephony | | 1852 | | | | 1853 | 58 | V23Back: V.23 back channel indication for | | 1854 | | text telephony | | 1855 | | | | 1856 | 59 | Baud4545: 45.45 bits/s Baudot indication | | 1857 | | for text telephony | | 1858 | | | | 1859 | 60 | Baud50: 50 bits/s Baudot indication for | | 1860 | | text telephony | | 1861 | | | | 1862 | 61 | VBDGen: Tone patterns indicative of use of | | 1863 | | an unidentified modem type | | 1864 | | | | 1865 | 62 | XCIMark: A pattern of bits modulated in | | 1866 | | the V.23 main channel, emitted by a V.18 | | 1867 | | calling terminal. | | 1868 | | | | 1869 | 63 | V32AA: A pattern of bits modulated at 4800 | | 1870 | | bits/s, emitted by a V.32/V.23bis calling | | 1871 | | terminal. | | 1872 +-------+--------------------------------------------+--------------+ 1874 Table 10: Data-Related Additions To RFC xxxx Telephony Event Registry 1876 7. Acknowledgements 1878 Scott Petrack was the original author of RFC 2833. Henning 1879 Schulzrinne later loaned his expertise to complete the document, but 1880 Scott must be credited with the energy behind the idea of a compact 1881 encoding of tones over IP. 1883 Gunnar Hellstrom and Keith Chu provided particularly useful comments 1884 helping to shape the present document. Amiram Allouche and Ido Benda 1885 drew the authors' attention to the value of including events for 1886 V.32/V.32bis in the document, and Yaakov Stein confirmed details of 1887 operation of this modem. 1889 8. References 1891 8.1. Normative References 1893 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1894 Levels", BCP 14, RFC 2119, March 1997. 1896 [2] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, 1897 M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP 1898 Payload for Redundant Audio Data", RFC 2198, September 1997. 1900 [3] Handley, M. and V. Jacobson, "SDP: Session Description 1901 Protocol", RFC 2327, April 1998. 1903 [4] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1904 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1905 RFC 3711, March 2004. 1907 [5] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, 1908 Telephony Tones and Telephony Signals", Work in 1909 progress: draft-ietf-avt-rfc2833bis-15.txt, June 2006. 1911 [6] International Telecommunication Union, "Echo suppressors", 1912 ITU-T Recommendation G.164, November 1988. 1914 [7] International Telecommunication Union, "Echo cancellers", ITU-T 1915 Recommendation G.165, March 1993. 1917 [8] International Telecommunication Union, "Procedures for document 1918 facsimile transmission in the general switched telephone 1919 network", ITU-T Recommendation T.30, July 2003. 1921 [9] International Telecommunication Union, "Procedures for starting 1922 sessions of data transmission over the public switched 1923 telephone network", ITU-T Recommendation V.8, November 2000. 1925 [10] International Telecommunication Union, "Procedures for the 1926 identification and selection of common modes of operation 1927 between data circuit-terminating equipments (DCEs) and between 1928 data terminal equipments (DTEs) over the public switched 1929 telephone network and on leased point-to-point telephone-type 1930 circuits", ITU-T Recommendation V.8 bis, November 2000. 1932 [11] International Telecommunication Union, "Operational and 1933 interworking requirements for {DCEs operating in the text 1934 telephone mode", ITU-T Recommendation V.18, November 2000. 1936 See also Recommendation V.18 Amendment 1, Nov. 2002. 1938 [12] International Telecommunication Union, "300 bits per second 1939 duplex modem standardized for use in the general switched 1940 telephone network", ITU-T Recommendation V.21, November 1988. 1942 [13] International Telecommunication Union, "Automatic answering 1943 equipment and general procedures for automatic calling 1944 equipment on the general switched telephone network including 1945 procedures for disabling of echo control devices for both 1946 manually and automatically established calls", ITU-T 1947 Recommendation V.25, October 1996. 1949 See also Corrigendum 1 to Recommendation V.25, Jul. 2001. 1951 [14] International Telecommunication Union, "A family of 2-wire, 1952 duplex modems operating at data signalling rates of up to 9600 1953 bit/s for use on the general switched telephone network and on 1954 leased telephone-type circuits", ITU-T Recommendation V.32, 1955 March 1993. 1957 [15] International Telecommunication Union, "A duplex modem 1958 operating at data signalling rates of up to 14 400 bit/s for 1959 use on the general switched telephone network and on leased 1960 point-to-point 2-wire telephone-type circuits", ITU-T 1961 Recommendation V.32bis, February 1991. 1963 8.2. Informative References 1965 [16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1966 Security Considerations", BCP 72, RFC 3552, July 2003. 1968 [17] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent 1969 Call", RFC 4040, April 2005. 1971 [18] Hellstrom, G. and P. Jones, "RTP Payload for Text 1972 Conversation", RFC 4103, June 2005. 1974 [19] International Telecommunication Union, "Pulse code modulation 1975 (PCM) of voice frequencies", ITU-T Recommendation G.711, 1976 November 1988. 1978 [20] International Telecommunication Union, "Terminal for low bit- 1979 rate multimedia communication", ITU-T Recommendation H.324, 1980 March 2002. 1982 [21] International Telecommunication Union, "Procedures for real- 1983 time Group 3 facsimile communication over IP networks", ITU-T 1984 Recommendation T.38, July 2003. 1986 [22] International Telecommunication Union, "International 1987 interworking for videotex services", ITU-T 1988 Recommendation T.101, November 1994. 1990 [23] International Telecommunication Union, "Data protocols for 1991 multimedia conferencing", ITU-T Recommendation T.120, 1992 July 1996. 1994 [24] International Telecommunication Union, "A 2-wire modem for 1995 facsimile applications with rates up to 14 400 bit/s", ITU-T 1996 Recommendation V.17, February 1991. 1998 [25] International Telecommunication Union, "600/1200-baud modem 1999 standardized for use in the general switched telephone 2000 network", ITU-T Recommendation V.23, November 1988. 2002 [26] International Telecommunication Union, "4800/2400 bits per 2003 second modem standardized for use in the general switched 2004 telephone network", ITU-T Recommendation V.27ter, 2005 November 1988. 2007 [27] International Telecommunication Union, "9600 bits per second 2008 modem standardized for use on point-to-point 4-wire leased 2009 telephone-type circuits", ITU-T Recommendation V.29, 2010 November 1988. 2012 [28] International Telecommunication Union, "A modem operating at 2013 data signalling rates of up to 33 600 bit/s for use on the 2014 general switched telephone network and on leased point-to-point 2015 2-wire telephone-type circuits", ITU-T Recommendation V.34, 2016 February 1998. 2018 [29] International Telecommunication Union, "A digital modem and 2019 analogue modem pair for use on the Public Switched Telephone 2020 Network (PSTN) at data signalling rates of up to 56 000 bit/s 2021 downstream and up to 33 600 bit/s upstream", ITU-T 2022 Recommendation V.90, September 1998. 2024 [30] International Telecommunication Union, "A digital modem 2025 operating at data signalling rates of up to 64 000 bit/s for 2026 use on a 4-wire circuit switched connection and on leased 2027 point-to-point 4-wire digital circuits", ITU-T 2028 Recommendation V.91, May 1999. 2030 [31] International Telecommunication Union, "Enhancements to 2031 Recommendation V.90", ITU-T Recommendation V.92, November 2000. 2033 [32] International Telecommunication Union, "Modem-over-IP networks: 2035 Procedures for the end-to-end connection of V-series DCEs", 2036 ITU-T Recommendation V.150.1, January 2003. 2038 [33] International Telecommunication Union, "Procedures for 2039 supporting voice-band data over IP networks", ITU-T 2040 Recommendation V.152, January 2005. 2042 [34] Telecommunications Industry Association, "A Frequency Shift 2043 Keyed Modem for Use on the Public Switched Telephone Network", 2044 ANSI TIA- 825-A-2003, April 2003. 2046 Authors' Addresses 2048 Henning Schulzrinne 2049 Columbia U. 2050 Dept. of Computer Science 2051 Columbia University 2052 1214 Amsterdam Avenue 2053 New York, NY 10027 2054 US 2056 Email: schulzrinne@cs.columbia.edu 2058 Tom Taylor 2059 Nortel 2060 1852 Lorraine Ave 2061 Ottawa, Ontario K1H 6Z8 2062 CA 2064 Email: taylor@nortel.com 2066 Intellectual Property Statement 2068 The IETF takes no position regarding the validity or scope of any 2069 Intellectual Property Rights or other rights that might be claimed to 2070 pertain to the implementation or use of the technology described in 2071 this document or the extent to which any license under such rights 2072 might or might not be available; nor does it represent that it has 2073 made any independent effort to identify any such rights. Information 2074 on the procedures with respect to rights in RFC documents can be 2075 found in BCP 78 and BCP 79. 2077 Copies of IPR disclosures made to the IETF Secretariat and any 2078 assurances of licenses to be made available, or the result of an 2079 attempt made to obtain a general license or permission for the use of 2080 such proprietary rights by implementers or users of this 2081 specification can be obtained from the IETF on-line IPR repository at 2082 http://www.ietf.org/ipr. 2084 The IETF invites any interested party to bring to its attention any 2085 copyrights, patents or patent applications, or other proprietary 2086 rights that may cover technology that may be required to implement 2087 this standard. Please address the information to the IETF at 2088 ietf-ipr@ietf.org. 2090 Disclaimer of Validity 2092 This document and the information contained herein are provided on an 2093 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2094 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2095 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2096 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2097 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2098 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2100 Copyright Statement 2102 Copyright (C) The Internet Society (2006). This document is subject 2103 to the rights, licenses and restrictions contained in BCP 78, and 2104 except as set forth therein, the authors retain all their rights. 2106 Acknowledgment 2108 Funding for the RFC Editor function is currently provided by the 2109 Internet Society.