idnits 2.17.1 draft-ietf-avt-rfc2833biscas-05.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, updated by RFC 4748 on line 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1014. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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). (Using the creation date from RFC4733, updated by this document, for RFC5378 checks: 2002-05-29) -- 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 7, 2007) is 6162 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) -- Looks like a reference, but probably isn't: 'RFCxxxx' on line 867 -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- 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' -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '11') (Obsoleted by RFC 4733, RFC 4734) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 15 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: 4733 (if approved) T. Taylor 5 Expires: December 9, 2007 Nortel 6 June 7, 2007 8 Definition of Events For Channel-Oriented Telephony Signalling 9 draft-ietf-avt-rfc2833biscas-05 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 9, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo updates RFC 4733 to add event codes for telephony signals 43 used for channel-associated signalling when carried in the telephony 44 event RTP payload. It supersedes and adds to the original assignment 45 of event codes for this purpose in RFC 2833 section 3.14. As 46 documented in Appendix A of RFC 4733, certain of the RFC 2833 events 47 have been deprecated, because their specification was ambiguous, 48 erroneous or redundant. In fact, the degree of change from RFC 2833 49 section 3.14 is such that implementations of the present document 50 will be fully backward compatible with RFC 2833 implementations only 51 in the case of full ABCD-bit signalling. The positive benefits of 52 the present document are an expanded coverage of signalling systems 53 and a more carefully specified and documented coverage of signalling 54 systems covered by RFC 2833. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Event Definitions . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Signalling System No. 5 . . . . . . . . . . . . . . . . . 7 63 2.1.1. Signalling System No. 5 Line Signals . . . . . . . . . 7 64 2.1.2. Signalling System No. 5 Register Signals . . . . . . . 8 65 2.2. Signalling System R1 and North American MF . . . . . . . . 9 66 2.2.1. Signalling System R1 Line Signals . . . . . . . . . . 9 67 2.2.2. Signalling System R1 Register Signals . . . . . . . . 9 68 2.3. Signalling System R2 . . . . . . . . . . . . . . . . . . . 11 69 2.3.1. Signalling System R2 Line Signals . . . . . . . . . . 11 70 2.3.2. Signalling System R2 Register Signals . . . . . . . . 11 71 2.4. ABCD Transitional signalling For Digital Trunks . . . . . 13 72 2.5. Continuity Tones . . . . . . . . . . . . . . . . . . . . . 14 73 2.6. Trunk Unavailable Event . . . . . . . . . . . . . . . . . 15 74 2.7. Metering Pulse Event . . . . . . . . . . . . . . . . . . . 15 75 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 16 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 83 Intellectual Property and Copyright Statements . . . . . . . . . . 26 85 1. Introduction 87 1.1. Terminology 89 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 90 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 91 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 92 indicate requirement levels for compliant implementations. 94 In addition to the abbreviations defined below for specific events, 95 this document uses the following abbreviations: 97 MF Multi-frequency 99 PSTN Public Switched (circuit) Telephone Network 101 RTP Real-time Transport Protocol [2] 103 1.2. Overview 105 This document extends the set of telephony events defined within the 106 framework of RFC 4733 [4] to include signalling events that can 107 appear on a circuit in the telephone network. Most of these events 108 correspond to signals within one of several channel-associated 109 signalling systems still in use in the PSTN. 111 Trunks (or circuits) in the PSTN are the media paths between 112 telephone switches. A succession of protocols have been developed 113 using tones and electrical conditions on individual trunks to set up 114 telephone calls using them. The events defined in this document 115 support an application where such PSTN signalling is carried between 116 two gateways without being interworked to signalling in the IP 117 network: the "RTP trunk" application. 119 In the "RTP trunk" application, RTP is used to replace a normal 120 circuit-switched trunk between two nodes. This is particularly of 121 interest in a telephone network that is still mostly circuit- 122 switched. In this case, each end of the RTP trunk encodes audio 123 channels into the appropriate encoding, such as G.723.1 [13] or G.729 124 [14]. However, this encoding process destroys in-band signalling 125 information which is carried using the least-significant bit ("robbed 126 bit signalling") and may also interfere with in-band signalling 127 tones, such as the MF (multi-frequency) digit tones. 129 In a typical application, the gateways may exchange roles from one 130 call to the next: they must be capable of either sending or receiving 131 each signal in the table. 133 This document defines events related to four different signalling 134 systems. Three of these are based on the exchange of multi-frequency 135 tones. The fourth operates on digital trunks only, and makes use of 136 low-order bits stolen from the encoded media. In addition, this 137 document defines tone events for supporting tasks such as continuity 138 testing of the media path. 140 Implementors are warned that the descriptions of signalling 141 systems given below are incomplete. They are provided to give 142 context to the related event definitions, but omit many details 143 important to implementation. 145 2. Event Definitions 147 Table 1 lists all of the events defined in this document. As 148 indicated in Table 8 (Appendix A) of RFC 4733 [4], use of certain of 149 the RFC 2833 [11] event codes has been deprecated, because their 150 specification was ambiguous, erroneous or redundant. In fact, the 151 degree of change from RFC 2833 section 3.14 is such that 152 implementations of the present document will be fully backward 153 compatible with RFC 2833 implementations only in the case of full 154 ABCD-bit signalling. The positive benefits of the present document 155 are an expanded coverage of signalling systems and a more carefully 156 specified and documented coverage of the signalling systems included 157 in RFC 2833. 159 Note that the IANA registry for telephony event codes was set up by 160 RFC 4733, not by RFC 2833. Thus event code assignments originally 161 made in RFC 2833 appear in the registry only if reaffirmed in RFC 162 4733 or an update to RFC 4733 such as the present document. 164 +---------------------+------------+-------------+--------+---------+ 165 | Event | Frequency | Event Code | Event | Volume? | 166 | | (Hz) | | Type | | 167 +---------------------+------------+-------------+--------+---------+ 168 | MF 0...9 | (Table 2) | 128...137 | tone | yes | 169 | | | | | | 170 | MF Code 11 (SS No. | 700+1700 | 123 | tone | yes | 171 | 5) or KP3P/ST3P | | | | | 172 | (R1) | | | | | 173 | | | | | | 174 | MF KP (SS No. 5) or | 1100+1700 | 124 | tone | yes | 175 | KP1 (R1) | | | | | 176 | | | | | | 177 | MF KP2 (SS No. 5) | 1300+1700 | 125 | tone | yes | 178 | or KP2P/ST2P (R1) | | | | | 179 | | | | | | 180 | MF ST (SS No. 5 and | 1500+1700 | 126 | tone | yes | 181 | R1) | | | | | 182 | | | | | | 183 | MF Code 12 (SS No. | 900+1700 | 127 | tone | yes | 184 | 5) or KP'/STP (R1) | | | | | 185 | | | | | | 186 | ABCD signalling | N/A | 144...159 | state | no | 187 | | | | | | 188 | AB signalling (C, D | N/A | 208...211 | state | no | 189 | unused) | | | | | 190 | | | | | | 191 | A bit signalling | N/A | 206...207 | state | no | 192 | (B, C, D unused) | | | | | 193 | | | | | | 194 | Continuity | 2000 | 121 | tone | yes | 195 | check-tone | | | | | 196 | | | | | | 197 | Continuity | 1780 | 122 | tone | yes | 198 | verify-tone | | | | | 199 | | | | | | 200 | Metering pulse | N/A | 174 | other | no | 201 | | | | | | 202 | Trunk unavailable | N/A | 175 | other | no | 203 | | | | | | 204 | MFC Forward 1...15 | (Table 4) | 176...190 | tone | yes | 205 | | | | | | 206 | MFC Backward 1...15 | (Table 5) | 191...205 | tone | yes | 207 +---------------------+------------+-------------+--------+---------+ 209 Table 1: Trunk signalling events 211 2.1. Signalling System No. 5 213 Signalling System No. 5 (SS No. 5) is defined in ITU-T 214 Recommendations Q.140 through Q.180 [5]. It has two systems of 215 signals: "line" signalling, to acquire and release the trunk, and 216 "register" signalling, to pass digits forward from one switch to the 217 next. 219 2.1.1. Signalling System No. 5 Line Signals 221 No. 5 line signalling uses tones at two frequencies: 2400 and 2600 222 Hz. The tones are used singly for most signals, but together for the 223 Clear-forward and Release-guard. (This reduces the chance of an 224 accidental call release due to carried media content duplicating one 225 of the frequencies.) The specific signal indicated by a tone depends 226 on the stage of call set-up at which it is applied. 228 No events are defined in support of No. 5 line signalling. However, 229 implementations MAY use the AB bit events described in Section 2.4 230 and shown in Table 1 to propagate SS No. 5 line signals. If they do 231 so, they MUST use the following mappings. These mappings are based 232 on an underlying mapping equating A=0 to presence of 2400 Hz signal 233 and B=0 to presence of 2600 Hz signal in the indicated direction. 235 o both 2400 and 2600 Hz present: event code 208; 237 o 2400 Hz present: event code 210; 239 o 2600 Hz present: event code 209; 241 o neither signal present: event code 211. 243 The initial event report for each signal SHOULD be generated as soon 244 as the signal is recognized, and in any case no later than the time 245 of recognition as indicated in ITU-T Recommendation Q.141, Table 1 246 (i.e. 40 ms for "seizing" and "proceed-to-send", 125 ms for all other 247 signals). The packetization interval following the initial report 248 SHOULD be chosen with considerations of reliable transmission given 249 first priority. Note that the receiver must supply its own volume 250 values for converting these events back to tones. Moreover, the 251 receiver MAY extend the playout of "seizing" until it has received 252 the first report of a KP event (see below), so that it has better 253 control of the interval between ending of the seizing signal and 254 start of KP playout. 256 The KP has to be sent beginning 80 +/- 20 ms after the SS No. 5 257 "seizing" signal has stopped. 259 2.1.2. Signalling System No. 5 Register Signals 261 No. 5 register signalling uses pairs of tones to convey digits and 262 signals framing them. The tone combinations and corresponding 263 signals are shown in the Table 2. All signals except KP1 and KP2 are 264 sent for a duration of 55 ms. KP1 and KP2 are sent for a duration of 265 100 ms. Inter-signal pauses are always 55 ms. 267 Upper Frequency (Hz) 269 +-----------------+---------+---------+---------+---------+---------+ 270 | Lower Frequency | 900 | 1100 | 1300 | 1500 | 1700 | 271 | (Hz) | | | | | | 272 +-----------------+---------+---------+---------+---------+---------+ 273 | 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | Code 11 | 274 | | | | | | | 275 | 900 | | Digit 3 | Digit 5 | Digit 8 | Code 12 | 276 | | | | | | | 277 | 1100 | | | Digit 6 | Digit 9 | KP1 | 278 | | | | | | | 279 | 1300 | | | | Digit 0 | KP2 | 280 | | | | | | | 281 | 1500 | | | | | ST | 282 +-----------------+---------+---------+---------+---------+---------+ 284 Table 2: SS No. 5 Register Signals 286 The KP signals are used to indicate start of digit signalling. KP1 287 indicates a call expected to terminate in a national network served 288 by the switch to which the signalling is being sent. KP2 indicates a 289 call that is expected to transit through the switch to which the 290 signalling is being sent, to another international exchange. The end 291 of digit signalling is indicated by the ST signal. Code 11 or Code 292 12 following a country code (and possibly another digit) indicates a 293 call to be directed to an operator position in the destination 294 country. A Code 12 may be followed by other digits indicating a 295 particular operator to whom the call is to be directed. 297 Implementations using the telephone-events payload to carry SS No. 5 298 register signalling MUST use the following events from Table 1 to 299 convey the register signals shown in Table 2: 301 o event code 128 to convey Digit 0 303 o event codes 129-137 to convey Digits 1 through 9 respectively 305 o event code 123 to convey Code 11 306 o event code 124 to convey KP1 308 o event code 125 to convey KP2 310 o event code 126 to convey ST 312 o event code 127 to convey Code 12. 314 The sending implementation SHOULD send an initial event report for 315 the KP signals as soon as they are recognized, and MUST send an event 316 report for all of these signals as soon as they have completed. 318 2.2. Signalling System R1 and North American MF 320 Signalling System R1 is mainly used in North America, as is the more 321 common variant designated simply "MF". R1 is defined in ITU-T 322 Recommendations Q.310-Q.332 [6], while MF is defined in [9]. 324 Like SS No. 5, R1/MF has both line and register signals. The line 325 signals (not counting Busy and Reorder) are implemented on analogue 326 trunks through the application of a 2600 Hz tone, and on digital 327 trunks by using ABCD signalling. Interpretation of the line signals 328 is state-dependent (as with SS No. 5). 330 2.2.1. Signalling System R1 Line Signals 332 In accordance with Table 1/Q.311, implementations MAY use the A bit 333 events described in Section 2.4 and shown in Table 1 to propagate R1 334 line signals. If they do so, they MUST use the following mappings. 335 These mappings are based on an underlying mapping equating A=0 to 336 presence of 2600 Hz signal in the indicated direction and A=1 to 337 absence of that signal. 339 o 2600 Hz present: event code 206; 341 o no signal present: event code 207. 343 2.2.2. Signalling System R1 Register Signals 345 R1 has a signal capacity of 15 codes for forward inter-register 346 signals but no backward inter-register signals. Each code or digit 347 is transmitted by a tone pair from a set of 6 frequencies. The R1 348 register signals consist of KP, ST, and the digits "0" through "9". 349 The frequencies allotted to the signals are shown in Table 3. Note 350 that these frequencies are the same as those allotted to the 351 similarly-named SS No. 5 register signals, except that KP uses the 352 frequency combination corresponding to KP1 in SS No. 5. Table 3 also 353 shows additional signals used in North American practice: KP', KP2P, 354 KP3P, STP or ST', ST2P, and ST3P [9]. 356 Upper Frequency (Hz) 358 +------------+---------+---------+---------+---------+--------------+ 359 | Lower | 900 | 1100 | 1300 | 1500 | 1700 | 360 | Frequency | | | | | | 361 | (Hz) | | | | | | 362 +------------+---------+---------+---------+---------+--------------+ 363 | 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | KP3P or ST3P | 364 | | | | | | | 365 | 900 | | Digit 3 | Digit 5 | Digit 8 | KP' or STP | 366 | | | | | | | 367 | 1100 | | | Digit 6 | Digit 9 | KP | 368 | | | | | | | 369 | 1300 | | | | Digit 0 | KP2P or ST2P | 370 | | | | | | | 371 | 1500 | | | | | ST | 372 +------------+---------+---------+---------+---------+--------------+ 374 Table 3: R1/MF Register Signals 376 Implementations using the telephone-events payload to carry North 377 American R1 register signalling MUST use the following events from 378 Table 1 to convey the register signals shown in Table 3: 380 o event code 128 to convey Digit 0; 382 o event codes 129-137 to convey Digits 1 through 9 respectively; 384 o event code 123 to convey KP3P or ST3P. 386 o event code 124 to convey KP; 388 o event code 125 to convey KP2P or ST2P; 390 o event code 126 to convey ST; 392 o event code 127 to convey KP' or STP; 394 As with the original telephony signals, the receiver interprets 395 codes 123, 125, and 127 as KPx or STx signals based on their 396 position in the signalling sequence. 398 Unlike SS No. 5, R1 allows a large tolerance for the time of onset of 399 register signalling following the recognition of start-dialling line 400 signal. This means that sending implementations MAY wait to send a 401 KP event report until the KP has completed. 403 2.3. Signalling System R2 405 International Signalling System R2 is described in ITU-T 406 Recommendations Q.400-Q.490 [7], but there are many national 407 variants. R2 line signals are continuous, out-of-band, link by link, 408 and channel associated. R2 (inter)register signals are 409 multifrequency, compelled, in-band, end to end, and also channel 410 associated. 412 2.3.1. Signalling System R2 Line Signals 414 R2 line signals may be analog, one-bit digital using the A bit in the 415 16th channel, or digital using both A and B bits. Implementations 416 MAY use the A bit or AB bit events described in Section 2.4 and shown 417 in Table 1 to propagate these signals. If they do so, they MUST use 418 the following mappings. 420 1. For the analog R2 line signals shown in Table 1 of ITU-T 421 Recommendation Q.411, implementations MUST map as follows. This 422 mapping is based on an underlying mapping of A bit = 0 when tone 423 is present. 425 * event code 206 (Table 1) is used to indicate the Q.411 426 "tone-on" condition 428 * event code 207 (Table 1), is used to indicate the Q.411 "tone- 429 off" condition. 431 2. The digital R2 line signals as described by ITU-T Recommendation 432 Q.421 are carried in two bits, A and B. The mapping between A and 433 B bit values and event codes SHALL be the same in both directions 434 and SHALL follow the principles for A and B bit mapping specified 435 in Section 2.4. 437 2.3.2. Signalling System R2 Register Signals 439 In R2 signalling, the signalling sequence is initiated from the 440 outgoing exchange by sending a line "seizing" signal. After the line 441 "seizing" signal (and "seizing acknowledgment" signal in R2D), the 442 signalling sequence continues using MF register signals. ITU-T 443 Recommendation Q.441 classifies the forward MF register signals 444 (upper frequencies) into Groups I and II, the backward MF register 445 signals (lower frequencies) into Groups A and B. These groups are 446 significant with respect both to what sort of information they convey 447 and where they can occur in the signalling sequence. 449 The tones used in R2 register signalling are combinations of two out 450 of six frequencies. National versions may be reduced to 10 signals 451 (two out of five fgrequencies), or 6 signals (two out of four 452 frequencies). 454 R2 register signalling is a compelled tone signalling protocol, 455 meaning that one tone is played until an "acknowledgment or directive 456 for the next tone" is received which indicates that the original tone 457 should cease. A R2 forward register signal is acknowledged by a 458 backward signal. A backward signal is acknowledged by the end of the 459 forward signal. In exceptional circumstances specified in ITU-T Rec. 460 Q.442 the downstream entity may send backward signals autonomously 461 rather than in response to specific forward signals. 463 In R2 signalling, the signalling sequence is initiated from the 464 outgoing exchange by sending a forward Group I signal. The first 465 forward signal is typically the first digit of the called number. 466 The incoming exchange typically replies with a backward Group A-1 467 indicating to the outgoing exchange to send the next digit of the 468 called number. 470 The tones have meaning; however, the meaning varies depending on 471 where the tone occurs in the signalling. The meaning may also depend 472 on the country. Thus, to avoid an unmanageable number of events, 473 this document simply provides means to indicate the 15 forward and 15 474 backward MF R2 tones (i.e., using event codes 176-190 and 191-205 475 respectively as shown in Table 1). The frequency pairs for these 476 tones are shown in Table 4 and Table 5. 478 Upper Frequency (Hz) 480 +----------------------+-------+-------+-------+--------+--------+ 481 | Lower Frequency (Hz) | 1500 | 1620 | 1740 | 1860 | 1980 | 482 +----------------------+-------+-------+-------+--------+--------+ 483 | 1380 | Fwd 1 | Fwd 2 | Fwd 4 | Fwd 7 | Fwd 11 | 484 | | | | | | | 485 | 1500 | | Fwd 3 | Fwd 5 | Fwd 8 | Fwd 12 | 486 | | | | | | | 487 | 1620 | | | Fwd 6 | Fwd 9 | Fwd 13 | 488 | | | | | | | 489 | 1740 | | | | Fwd 10 | Fwd 14 | 490 | | | | | | | 491 | 1860 | | | | | Fwd 15 | 492 +----------------------+-------+-------+-------+--------+--------+ 494 Table 4: R2 Forward Register Signals 495 Upper Frequency (Hz) 497 +-----------------+---------+---------+---------+---------+---------+ 498 | Lower Frequency | 1140 | 1020 | 900 | 780 | 660 | 499 | (Hz) | | | | | | 500 +-----------------+---------+---------+---------+---------+---------+ 501 | 1020 | Bkwd 1 | | | | | 502 | | | | | | | 503 | 900 | Bkwd 2 | Bkwd 3 | | | | 504 | | | | | | | 505 | 780 | Bkwd 4 | Bkwd 5 | Bkwd 6 | | | 506 | | | | | | | 507 | 660 | Bkwd 7 | Bkwd 8 | Bkwd 9 | Bkwd 10 | | 508 | | | | | | | 509 | 540 | Bkwd 11 | Bkwd 12 | Bkwd 13 | Bkwd 14 | Bkwd 15 | 510 +-----------------+---------+---------+---------+---------+---------+ 512 Table 5: R2 Backward Register Signals 514 2.4. ABCD Transitional signalling For Digital Trunks 516 ABCD is a 4-bit signalling system used by digital trunks, where A, B, 517 C, and D are the designations of the individual bits. Signalling may 518 be 16-state (all four bits used), 4-state (A and B bits used) or 519 2-state (A-bit only used). ABCD signalling events are all mutually 520 exclusive states. The most recent state transition determines the 521 current state. 523 When using Extended Super Frame (ESF) T1 framing, signalling 524 information is sent as robbed bits in frames 6, 12, 18, and 24. A D4 525 superframe only transmits 4-state signalling with A and B bits. On 526 the CEPT E1 frame, all signalling is carried in timeslot 16, and two 527 channels of 16-state (ABCD) signalling are sent per frame. ITU-T 528 Recommendation G.704 [10] gives the details of ABCD bit placement 529 within the various framing arrangements. 531 The meaning of ABCD signals varies with the application. One example 532 of a specification of ABCD signalling codes is T1.403.02 [16], which 533 reflects North American practice for "loop" signalling as opposed to 534 the trunk signalling discussed in previous sections. 536 Since ABCD information is a state rather than a changing signal, 537 implementations SHOULD use the following triple-redundancy mechanism, 538 similar to the one specified in ITU-T Rec. I.366.2 [15], Annex L. At 539 the time of a transition, the same ABCD information is sent 3 times 540 at an interval of 5 ms. If another transition occurs during this 541 time, then this continues. After a period of no change, the ABCD 542 information is sent every 5 seconds. 544 As shown in Table 1, the 16 possible states are represented by event 545 codes 144 to 159 respectively. Implementations using these event 546 codes MUST map them to and from the ABCD information based on the 547 following principles: 549 1. State numbers are derived from the used subset of ABCD bits by 550 treating them as a single binary number, where the A bit is the 551 high-order bit. 553 2. State numbers map to event codes by order of increasing value 554 (i.e., state number 0 maps to event code 144, ..., state number 555 15 maps to event code 159). 557 If only the A and B bits are being used, then the mapping to event 558 codes shall be as follows: 560 o A=0, B=0 maps to event code 208; 562 o A=0, B=1 maps to event code 209; 564 o A=1, B=0 maps to event code 210; 566 o A=1, B=1 maps to event code 211; 568 Finally, if only the A bit is used, 570 o A = 0 maps to event code 206; 572 o A = 0 maps to event code 207; 574 Separate event codes are assigned to A and AB bit signalling 575 because, as indicated in Rec. G.704 [10], when the B, C, and D 576 bits are unused their default values differ between transmission 577 systems. By specifying codes for only the used bits, this memo 578 allows the receiving gateway to fill in the remaining bits 579 according to local configuration. 581 2.5. Continuity Tones 583 Continuity tones are used for testing circuit continuity during call 584 setup. Two basic procedures are used. In international practice, 585 clause 7 of ITU- T Recommendation Q.724 [8] describes a procedure 586 applicable to four-wire trunk circuits, where a single 2000 +/- 20 Hz 587 check-tone is transmitted from the initiating telephone switch. The 588 remote switch sets up a loopback, and continuity check passes if the 589 sending switch can detect the tone on the return path. Q.724 clause 590 8 describes the procedure for two-wire trunk circuits. The two-wire 591 procedure involves two tones: a 2000 Hz tone sent in the forward 592 direction, and a 1780 +/- 20 Hz tone sent in response. 594 If implementations use the telephone-events payload type to propagate 595 continuity check-tones, they MUST map these tones to event codes as 596 follows: 598 o For four-wire continuity testing, the 2000 Hz check-tone is mapped 599 to event code 121. 601 o For two-wire continuity testing, the initial 2000 Hz check-tone Hz 602 tone is mapped to event code 121. The 1780 Hz continuity verify 603 tone is mapped to event code 122. 605 2.6. Trunk Unavailable Event 607 This event indicates that the trunk is unavailable for service. The 608 length of the downtime is indicated in the duration field. The 609 duration field is set to a value that allows adequate granularity in 610 describing downtime. A value of 1 second is RECOMMENDED. When the 611 trunk becomes unavailable, this event is sent with the same timestamp 612 three times at an interval of 20 ms. If the trunk persists in the 613 unavailable state at the end of the indicated duration, then the 614 event is retransmitted, preferably with the same redundancy scheme. 616 Unavailability of the trunk might result from a failure or an 617 administrative action. This event is used in a stateless manner to 618 synchronize trunk unavailability between equipment connected through 619 provisioned RTP trunks. It avoids the unnecessary consumption of 620 bandwidth in sending a continuous stream of RTP packets with a fixed 621 payload for the duration of the downtime, as would be required in 622 certain E1-based applications. In T1-based applications, trunk 623 conditioning via the ABCD transitional events can be used instead. 625 2.7. Metering Pulse Event 627 The metering pulse event may be used to transmit meter pulsing for 628 billing purposes. For background information, one possible reference 629 is http://www.seg.co.uk/telecomm/automat3.htm. Since the metering 630 pulse is a discrete event, each metering pulse event report MUST have 631 both the 'M' and 'E' bits set. Meter pulsing is normally transmitted 632 by out-of-band means while conversation is in progress. Senders MUST 633 therefore be prepared to transmit both the telephone-event and audio 634 payload types simultaneously. Metering pulse events MUST be 635 retransmitted as recommended in section 2.5.1.4 of RFC 4733 [4]. It 636 is RECOMMENDED that the retransmission interval be the lesser of 50 637 ms and the pulsing rate, but no less than audio packetization rate. 639 3. Congestion Considerations 641 The ability to adapt to congestion varies with the signalling system 642 being used and also differs between line and register signals. 644 With the specific exception of register signalling for S.S. No. 5 and 645 R1/MF, the signals desribed in this document are fairly tolerant of 646 lengthened durations should these be necessary. Thus in congested 647 conditions, the sender may adapt by lengthening the reporting 648 interval for the tones concerned. At the receiving end, if a tone is 649 being played out and an under-run occurs due to delayed or lost 650 packets, it is best to continue playing the tone until the next 651 packet arrives. Interrupting a tone prematurely, with or without 652 resumption, can cause the call setup attempt to fail, whereas 653 extended playout just increases the call setup time. 655 Register signalling for S.S. No. 5 and R1/MF is subject to time 656 constraints. Both the tone signals and the silent periods between 657 them have specified durations and tolerances of the order of 5 to 10 658 ms. The durations of the individual tones are of the order of two to 659 three packetization intervals (55/68 ms, with the initial KP lasting 660 100 ms). The critical requirement for transmission of the telephony- 661 event payload is that the receiver knows which signal to play out at 662 a given moment. It is less important that the receiver receive 663 timely notification of the end of each tone. Rather, it should play 664 out the sequence with the durations specified by the signalling 665 standard instead of the actual durations reported. 667 These considerations suggest that as soon as a register signal has 668 been reliably identified, the sender should emit a report of that 669 tone. It should then provide an update within 5 ms for reliability, 670 and no more updates until reporting the end of the tone. 672 Increasing the playout buffer at the receiver during register 673 signalling will increase reliability. This has to be weighed against 674 the implied increase in call setup time. 676 4. Security Considerations 678 The events for which event codes are provided in this document relate 679 directly to the setup, billing, and takedown of telephone calls. As 680 such, they are subject, using the terminology of RFC 3552 [12], to 681 threats to both communications and system security. The attacks of 682 concern are: 684 o confidentiality violations (monitoring of calling and called 685 numbers); 687 o establishment of unauthorized telephone connections through 688 message insertion; 690 o hijacking of telephone connections through message insertion or 691 man-in-the-middle modification of messages; 693 o denial of service to individual telephone calls through message 694 insertion, modification, deletion, or delay. 696 To prevent these attacks, the transmission of the telephony 697 signalling events described in this memo MUST be given 698 confidentiality protection. Message authentication and the 699 protection of message integrity MUST also be provided. These address 700 the threats posed by message insertion and modification. With these 701 measures in place, RTP sequence numbers and the redundancy provided 702 by the RFC 4733 procedures for transmission of events add protection 703 against and some resiliency in the face of message deletion. 705 The Secure Real-time Transport Protocol (SRTP) [3] meets the 706 requirements for protection of confidentiality, message integrity, 707 and message authentication described above. It SHOULD therefore be 708 used to protect media streams containing the events described in this 709 document. 711 Note that the appropriate method of key distribution for SRTP may 712 vary with the specific application. 714 In some deployments it may be preferable to use other means to 715 provide protection equivalent to that provided by SRTP. 717 Additional security considerations are described in RFC 4733 [4]. 719 5. IANA Considerations 721 This document defines the event codes shown in Table 6. These events 722 are additions to the telephone-event registry established by RFC 4733 723 [4]. The reference for all of them is the present document. 725 +------------+-----------------------------------------+-----------+ 726 | Event Code | Event Name | Reference | 727 +------------+-----------------------------------------+-----------+ 728 | 121 | Continuity check-tone | [RFCxxxx] | 729 | | | | 730 | 122 | Continuity verify-tone | [RFCxxxx] | 731 | | | | 732 | 123 | MF Code 11 (SS No. 5) or KP3P/ST3P (R1) | [RFCxxxx] | 733 | | | | 734 | 124 | MF KP (SS No. 5) or KP1 (R1) | [RFCxxxx] | 735 | | | | 736 | 125 | MF KP2 (SS No. 5) or KP2P/ST2P (R1) | [RFCxxxx] | 737 | | | | 738 | 126 | MF ST (SS No. 5 and R1) | [RFCxxxx] | 739 | | | | 740 | 127 | MF Code 12 (SS No. 5) or KP'/STP (R1) | [RFCxxxx] | 741 | | | | 742 | 128 | SS No. 5 or R1 digit "0" | [RFCxxxx] | 743 | | | | 744 | 129 | SS No. 5 or R1 digit "1" | [RFCxxxx] | 745 | | | | 746 | 130 | SS No. 5 or R1 digit "2" | [RFCxxxx] | 747 | | | | 748 | 131 | SS No. 5 or R1 digit "3" | [RFCxxxx] | 749 | | | | 750 | 132 | SS No. 5 or R1 digit "4" | [RFCxxxx] | 751 | | | | 752 | 133 | SS No. 5 or R1 digit "5" | [RFCxxxx] | 753 | | | | 754 | 134 | SS No. 5 or R1 digit "6" | [RFCxxxx] | 755 | | | | 756 | 135 | SS No. 5 or R1 digit "7" | [RFCxxxx] | 757 | | | | 758 | 136 | SS No. 5 or R1 digit "8" | [RFCxxxx] | 759 | | | | 760 | 137 | SS No. 5 or R1 digit "9" | [RFCxxxx] | 761 | | | | 762 | 144 | ABCD signalling state '0000' | [RFCxxxx] | 763 | | | | 764 | 145 | ABCD signalling state '0001' | [RFCxxxx] | 765 | | | | 766 | 146 | ABCD signalling state '0010' | [RFCxxxx] | 767 | 147 | ABCD signalling state '0011' | [RFCxxxx] | 768 | | | | 769 | 148 | ABCD signalling state '0100' | [RFCxxxx] | 770 | | | | 771 | 149 | ABCD signalling state '0101' | [RFCxxxx] | 772 | | | | 773 | 150 | ABCD signalling state '0110' | [RFCxxxx] | 774 | | | | 775 | 151 | ABCD signalling state '0111' | [RFCxxxx] | 776 | | | | 777 | 152 | ABCD signalling state '1000' | [RFCxxxx] | 778 | | | | 779 | 153 | ABCD signalling state '1001' | [RFCxxxx] | 780 | | | | 781 | 154 | ABCD signalling state '1010' | [RFCxxxx] | 782 | | | | 783 | 155 | ABCD signalling state '1011' | [RFCxxxx] | 784 | | | | 785 | 156 | ABCD signalling state '1100' | [RFCxxxx] | 786 | | | | 787 | 157 | ABCD signalling state '1101' | [RFCxxxx] | 788 | | | | 789 | 158 | ABCD signalling state '1110' | [RFCxxxx] | 790 | | | | 791 | 159 | ABCD signalling state '1111' | [RFCxxxx] | 792 | | | | 793 | 174 | Metering pulse | [RFCxxxx] | 794 | | | | 795 | 175 | Trunk unavailable | [RFCxxxx] | 796 | | | | 797 | 176 | MFC forward signal 1 | [RFCxxxx] | 798 | | | | 799 | 177 | MFC forward signal 2 | [RFCxxxx] | 800 | | | | 801 | 178 | MFC forward signal 3 | [RFCxxxx] | 802 | | | | 803 | 179 | MFC forward signal 4 | [RFCxxxx] | 804 | | | | 805 | 180 | MFC forward signal 5 | [RFCxxxx] | 806 | | | | 807 | 181 | MFC forward signal 6 | [RFCxxxx] | 808 | | | | 809 | 182 | MFC forward signal 7 | [RFCxxxx] | 810 | | | | 811 | 183 | MFC forward signal 8 | [RFCxxxx] | 812 | | | | 813 | 184 | MFC forward signal 9 | [RFCxxxx] | 814 | | | | 815 | 185 | MFC forward signal 10 | [RFCxxxx] | 816 | | | | 817 | 186 | MFC forward signal 11 | [RFCxxxx] | 818 | | | | 819 | 187 | MFC forward signal 12 | [RFCxxxx] | 820 | | | | 821 | 188 | MFC forward signal 13 | [RFCxxxx] | 822 | | | | 823 | 189 | MFC forward signal 14 | [RFCxxxx] | 824 | | | | 825 | 190 | MFC forward signal 15 | [RFCxxxx] | 826 | | | | 827 | 191 | MFC backward signal 1 | [RFCxxxx] | 828 | | | | 829 | 192 | MFC backward signal 2 | [RFCxxxx] | 830 | | | | 831 | 193 | MFC backward signal 3 | [RFCxxxx] | 832 | | | | 833 | 194 | MFC backward signal 4 | [RFCxxxx] | 834 | | | | 835 | 195 | MFC backward signal 5 | [RFCxxxx] | 836 | | | | 837 | 196 | MFC backward signal 6 | [RFCxxxx] | 838 | | | | 839 | 197 | MFC backward signal 7 | [RFCxxxx] | 840 | | | | 841 | 198 | MFC backward signal 8 | [RFCxxxx] | 842 | | | | 843 | 199 | MFC backward signal 9 | [RFCxxxx] | 844 | | | | 845 | 200 | MFC backward signal 10 | [RFCxxxx] | 846 | | | | 847 | 201 | MFC backward signal 11 | [RFCxxxx] | 848 | | | | 849 | 202 | MFC backward signal 12 | [RFCxxxx] | 850 | | | | 851 | 203 | MFC backward signal 13 | [RFCxxxx] | 852 | | | | 853 | 204 | MFC backward signal 14 | [RFCxxxx] | 854 | | | | 855 | 205 | MFC backward signal 15 | [RFCxxxx] | 856 | | | | 857 | 206 | A bit signalling state '0' | [RFCxxxx] | 858 | | | | 859 | 207 | A bit signalling state '1' | [RFCxxxx] | 860 | | | | 861 | 208 | AB bit signalling state '00' | [RFCxxxx] | 862 | | | | 863 | 209 | AB bit signalling state '01' | [RFCxxxx] | 864 | | | | 865 | 210 | AB bit signalling state '10' | [RFCxxxx] | 866 | | | | 867 | 211 | AB bit signalling state '11' | [RFCxxxx] | 868 +------------+-----------------------------------------+-----------+ 870 Table 6: Channel-oriented signalling events to be added to the audio/ 871 telephone-event event code registry 873 Note to RFC Editor: please replace "RFCxxxx" in the above table 874 with the actual RFC number of this document. 876 Note to IANA: because of an oversight, RFC 4733 did not indicate 877 that event codes 144-159 and 206-211 were specifically reserved 878 for this document. Their assignment here is valid. 880 6. Acknowledgements 882 The complete list of acknowledgements for contribution to the 883 development and revision of RFC 2833 is contained in RFC 4733 [4]. 884 The Editor believes or is aware that the following people contributed 885 specifically to the present document: Flemming Andreasen, Rex 886 Coldren, Bill Foster, Alfred Hoenes, Rajesh Kumar, Aleksandar Lebl, 887 Zarko Markov, Oren Peleg, Moshe Samoha, Adrian Soncodi, and Yaakov 888 Stein. Steve Norreys and Roni Even provided useful review comments. 890 7. References 892 7.1. Normative References 894 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 895 Levels", BCP 14, RFC 2119, March 1997. 897 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 898 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 899 RFC 3550, July 2003. 901 [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 902 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 903 RFC 3711, March 2004. 905 [4] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, 906 Telephony Tones, and Telephony Signals", RFC 4733, 907 December 2006. 909 [5] International Telecommunication Union, "Specifications for 910 signalling system no. 5", ITU-T Recommendation Q.140-Q.180, 911 November 1988. 913 [6] International Telecommunication Union, "Specifications of 914 Signalling System R1", ITU-T Recommendation Q.310-Q.332, 915 November 1988. 917 [7] International Telecommunication Union, "Specifications of 918 Signalling System R2", ITU-T Recommendation Q.400-Q.490, 919 November 1988. 921 [8] International Telecommunication Union, "Telephone user part 922 signalling procedures", ITU-T Recommendation Q.724, 923 November 1988. 925 [9] Telcordia Technologies, "LSSGR: signalling for Analog 926 Interfaces", Generic Requirement GR-506, June 1996. 928 [10] International Telecommunication Union, "Synchronous frame 929 structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s 930 hierarchical levels", ITU-T Recommendation G.704, October 1998. 932 7.2. Informative References 934 [11] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 935 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 937 [12] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 938 Security Considerations", BCP 72, RFC 3552, July 2003. 940 [13] International Telecommunication Union, "Speech coders : Dual 941 rate speech coder for multimedia communications transmitting at 942 5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996. 944 [14] International Telecommunication Union, "Coding of speech at 8 945 kbit/s using conjugate-structure algebraic-code-excited linear- 946 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 948 [15] International Telecommunication Union, "AAL type 2 service 949 specific convergence sublayer for trunking", ITU-T 950 Recommendation I.366.2, February 1999. 952 [16] ANSI/T1, "Network and Customer Installation Interfaces -- DS1 953 Robbed-Bit signalling State Definitions", American National 954 Standard for Telecommunications T1.403.02-1999, May 1999. 956 Authors' Addresses 958 Henning Schulzrinne 959 Columbia U. 960 Dept. of Computer Science 961 Columbia University 962 1214 Amsterdam Avenue 963 New York, NY 10027 964 US 966 Email: schulzrinne@cs.columbia.edu 968 Tom Taylor 969 Nortel 970 1852 Lorraine Ave 971 Ottawa, Ontario K1H 6Z8 972 CA 974 Email: tom.taylor@rogers.com 976 Full Copyright Statement 978 Copyright (C) The IETF Trust (2007). 980 This document is subject to the rights, licenses and restrictions 981 contained in BCP 78, and except as set forth therein, the authors 982 retain all their rights. 984 This document and the information contained herein are provided on an 985 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 986 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 987 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 988 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 989 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 990 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 992 Intellectual Property 994 The IETF takes no position regarding the validity or scope of any 995 Intellectual Property Rights or other rights that might be claimed to 996 pertain to the implementation or use of the technology described in 997 this document or the extent to which any license under such rights 998 might or might not be available; nor does it represent that it has 999 made any independent effort to identify any such rights. Information 1000 on the procedures with respect to rights in RFC documents can be 1001 found in BCP 78 and BCP 79. 1003 Copies of IPR disclosures made to the IETF Secretariat and any 1004 assurances of licenses to be made available, or the result of an 1005 attempt made to obtain a general license or permission for the use of 1006 such proprietary rights by implementers or users of this 1007 specification can be obtained from the IETF on-line IPR repository at 1008 http://www.ietf.org/ipr. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights that may cover technology that may be required to implement 1013 this standard. Please address the information to the IETF at 1014 ietf-ipr@ietf.org. 1016 Acknowledgment 1018 Funding for the RFC Editor function is provided by the IETF 1019 Administrative Support Activity (IASA).