idnits 2.17.1 draft-ietf-avt-telephone-tones-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 3) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 63 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([MGCP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 91: '... senders SHOULD use the same sequenc...' RFC 2119 keyword, line 103: '... a source MAY send a TSE payload and...' RFC 2119 keyword, line 105: '... stream, or it MAY block outgoing au...' RFC 2119 keyword, line 108: '...he regular audio SHOULD be blocked for...' RFC 2119 keyword, line 128: '... the transmitter SHOULD use the named ...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (17 November 1998) is 9285 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) -- Missing reference section? 'MGCP' on line 566 looks like a reference -- Missing reference section? '1' on line 557 looks like a reference -- Missing reference section? 'RFC 2198' on line 430 looks like a reference -- Missing reference section? 'RFC2198' on line 561 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 Internet Draft SB Petrack 3 ietf-avt-telephone-tones-00.txt VocalTec 4 17 November 1998 5 Expires: 17 May, 1999 7 RTP Payloads for Telephone Signal Events 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 ABSTRACT 31 This note describes two RTP payload formats for in-band telephony 32 signal events (TSE) such as DTMF, dial-tone, ring-tone, off-hook, SIT, etc. 33 One payload is designed to carry a named signal, and the other is designed 34 carry a compact representation of actual audio waveform cadence to be played. 35 The two formats are independent, but they can be used together very usefully 36 within redundant audio payloads; this enables highly efficient and robust 37 transport of telephony network signal events along with a representation of 38 the actual audio media associated to the signal events. 40 Acknowledgements: This internet draft is an extension of H. Schulzrinne's 41 draft ietf-avt-dtmf-00.txt and borrows heavily from it (including copying 42 actual text). The main extensions appearing in this draft are as follows: 44 a) many other telephony call progress tones and signal events have been 45 added to the original DTMF and flash-hook of ietf-avt-dtmf-00.txt (an 46 attempt has been made to align this with [MGCP] and [E.180 supp2] 47 b) a second payload is defined which carries a highly compact 48 frequency representation of the audio waveform of the signal; 49 c) a few clarifications about reliability and redundancy, including how 50 the two payloads will work together. 52 Acknowledgement is also due to [MGCP]; part of this draft is an attempt 53 to use RTP to provide the signal transport required by MGCP, in a way 54 which can be reused by a large class of applications. 56 1 Introduction 58 This memo defines two payload formats for carrying in-band telephony 59 signal events (TSE) within RTP packets. These are events such as 60 DTMF tones, MF tones, on-hook, off-hook, flash-hook events, ring 61 tones and ring-back tones, continuity tones, busy tones, call waiting 62 tones, etc. A complete list is given in section 2. It is desirable to 63 transport these signals with a separate payload type for several reasons: 65 a) low-rate voice codecs cannot be guaranteed to accurately reproduce the 66 audio waveforms, while special tone generators can be driven by a special 67 payload type; 68 b) defining a separate payload type permits higher redundancy than for 69 other payload types in the audio stream; 70 c) It removes the need for complicated tone detection algorithms in 71 equipment that receives the new payload type; 72 d) it enables the separation of the detection of the signal tones in media 73 gateways from the semantic interpretation of the tones in signalling 74 gateways and "call agents" (see [MGCP]). 76 The payload type must be suitable for both gateway and end- 77 to-end scenarios. In gateway scenarios, a gateway connecting a 78 packet voice network with the PSTN recreates the signal events 79 and then injects them into the PSTN, or detects the signal events and 80 then re-encodes them with the new payload format. Since the detection 81 may take several tens of milliseconds, careful time and power (volume) 82 alignment is needed to avoid generating spurious events for some 83 applications. For other applications, such as MGCP Call Agents [MGCP] 84 or interactive voice response (IVR) systems directly connected to the 85 packet voice network, time alignment and volume levels are not 86 important, since the unit will not perform any signal analysis to 87 detect the signal events from the audio stream. 89 When these telephony signal events are carried in-band as part of the 90 audio stream, such as is the case with DTMF digits, etc. 91 senders SHOULD use the same sequence number and time-stamp base as the 92 regular audio channel to simplify recreation of analog audio at a gateway. 94 The default clock frequency is 8000 Hz, but the clock frequency can 95 be redefined when assigning the dynamic payload type. 97 This format achieves a higher than the method proposed for the Voice over 98 Frame Relay Implementation Agreement [1], even in the case of 99 sustained packet loss. 101 Note that these telephony signal events are often sent as audio 102 waveforms within the ordinary audio stream. In these cases, 103 a source MAY send a TSE payload and coded audio packets for the same 104 time instants, using TSE as the redundant encoding for the audio 105 stream, or it MAY block outgoing audio while the TSE tones are active 106 and only send TSE as both the primary and redundant encodings. 107 For signal events which are not normally sent as audio waveforms (such 108 as on-hook, flash-hook, etc.), the regular audio SHOULD be blocked for 109 the duration of the TSE. 111 In this note we define two independent payload formats: 113 a) a payload for named signal events (NSE). This payload is useful when 114 there is no need to send any encoding of the audio waveforms that are used 115 within the telephone network to represent the signal events, or when no 116 such audio waveforms exist. 118 b) a payload for signal tone frequencies (STF). This payload is useful 119 when it is desired to transmit the actual audio media associated to the 120 telephone signal event. 122 Each of these payloads can be viewed as a special type of audio compression. 123 Just as there are codecs which are highly optimised (say) for human speech, 124 these payloads are highly optimised for the special audio which signals 125 certain events within telephone networks. 127 When the transmitter and receiver both agree (via non RTP means) on the audio 128 interpretation of the TSE, the transmitter SHOULD use the named signal events 129 payload. For example, this is usually the case for two PSTN gateways within 130 a single country: "dial tone" is the same in all parts of the United States. 131 When the RTP transmitter needs finer control over the actual audio media to 132 be played at the receiver, it SHOULD use the signal tone frequencies payload. 133 For example, since ringback is different in Mexico than in the United States, 134 a Mexican gateway which used the named signal events payload to transmit 135 ringback from Mexico to the United States might result in an incorrect audio 136 signal ("USA ringback") being generated at the handset of the caller. The RTP 137 transmitter MAY use the named signal events payload as a primary payload 138 type and the tone frequencies payload as a secondary payload type within a 139 redundant audio payload type (see section 4). This will allow the transmitter 140 to send the semantic information present in the named signal ("ringback") 141 along with the representation of the audio. 143 Some of the named signal events are very long (on the order of several seconds). 144 If a gateway waits to detect the named signal event before transmitting it 145 within an NSE packet, a substantial delay might result. A gateway MAY to 146 transmit the audio within an ordinary encoded audio payload, or within 147 a signal tone frequency payload. The NSE payload can then be used as a 148 redundant audio type as soon as detection is accomplished. 150 2 Named Signal Event (NSE) Payload Format 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | event |R R| volume | duration | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 volume: The power level of the digit, expressed in dBm0 after 158 dropping the sign, with range from 0 to -63 dBm0. The range of 159 valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 160 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger 161 values denote lower volume. 163 Note: since the acceptable dip is 10 dB and the minimum detectable 164 loudness variation is 3 dB, this field could be compressed by at 165 least a bit by reducing resolution to 2 dB, if needed. 167 duration: Duration of this digit, in timestamp units. (For a sampling 168 rate of 8000 Hz, this field is sufficient to express digit 169 durations of upto approximately 8 seconds; the minimum 170 permissible digit length is 40 ms.) 172 R: This field is reserved for future use. The sender MUST set it to 173 zero, the receiver MUST ignore it. 175 event: The event name identifies the actual telephone signal event. The 176 events are encoded as follows (these events are extracted from [E.180Supp2] 177 and [MGCP]): 179 ________________________________ 180 | Encoding | Definition | 181 |(decimal) | | 182 |----------|--------------------| 183 | 0 | DTMF 0 | 184 | 1 | DTMF 1 | 185 | 2 | DTMF 2 | 186 | 3 | DTMF 3 | 187 | 4 | DTMF 4 | 188 | 5 | DTMF 5 | 189 | 6 | DTMF 6 | 190 | 7 | DTMF 7 | 191 | 8 | DTMF 8 | 192 | 9 | DTMF 9 | 193 | 10 | DTMF A | 194 | 11 | DTMF B | 195 | 12 | DTMF C | 196 | 13 | DTMF D | 197 | 14 | DTMF * | 198 | 15 | DTMF # | 199 | 16 | Flash Hook | 200 | 17 | MF 0 | 201 | 18 | MF 1 | 202 | 19 | MF 2 | 203 | 20 | MF 3 | 204 | 21 | MF 4 | 205 | 22 | MF 5 | 206 | 23 | MF 6 | 207 | 24 | MF 7 | 208 | 25 | MF 8 | 209 | 26 | MF 9 | 210 | 27 | MF K0 or KP | 211 | 28 | MF K1 | 212 | 29 | MF K2 | 213 | 30 | MF S0 or ST | 214 | 31 | MF S1 | 215 | 32 | MF S2 | 216 | 33 | MF S3 | 217 | 34 | Wink | 218 | 35 | Wink off | 219 | 36 | Incoming seizure | 220 | 37 | Return seizure | 221 | 38 | Unseize circuit | 222 | 39 | Continuity Test | 223 | 40 | Default continuity tone | 224 | 41 | Continuity tone (single tone)| 225 | 42 | Continuity test (go tone, in dual tone procedures) | 226 | 43 |Continuity verified (response tone, in dual tone procedures)| 227 | 44 | Loopback | 228 | 45 | Old Milliwatt Tone (1000 Hz) | 229 | 46 | New Milliwatt Tone (1004 Hz) | 230 | 47 | Test Line | 231 | 48 | No circuit | 232 | 49 | Answer Supervision | 233 | 50 | Offering Tone 234 | 51 | Reorder Tone I 235 | 52 | Reorder Tone II 236 | 53 | report failure | 237 | 54 | Off hook transition | 238 | 55 | On hook transition | 239 | 56 | Flash hook | 240 | 57 | Acceptance Tone 241 | 58 | Alerting Tone 242 | 59 | Answer tone | 243 | 60 | Busy tone 244 | 61 | Busy Tone II 245 | 62 | Busy Tone III | 246 | 63 | Calling Card Service Tone 247 | 64 | Call Waiting Tone | 248 | 65 | Comfort Tone 249 | 66 | Confirmation Tone (PABX) 250 | 67 | Confirmation Tone I 251 | 68 | Confirmation Tone II 252 | 69 | Congestion Tone (Network busy) | 253 | 70 | Congestion Tone II(Network busy) | 254 | 71 | Congestion Tone III (Network busy) | 255 | 72 | Dial tone | 256 | 73 | Dial Tone II 257 | 74 | Second Dial Tone 258 | 75 | Second Dial Tone II 259 | 76 | Special Dial Tone 260 | 77 | Stutter Dial Tone 261 | 78 | Recall Dial Tone 262 | 79 | End of Three Party Service Tone 263 | 80 | Error Tone 264 | 81 | Executive Override Tone (PABX) 265 | 82 | Facilities Tone 266 | 83 | Function Recognition Tone 267 | 84 | Holding Tone 268 | 85 | Intrusion Tone 269 | 86 | Interception Tone (PABX ) 270 | 87 | Line Lockout Tone 271 | 88 | Negative Indication Tone 272 | 89 | Number Unobtainable Tone 273 | 90 | Number Unobtainable Tone II 274 | 91 | Off hook warning tone 275 | 92 | Pay Tone 276 | 93 | Payphone Recognition Tone 277 | 94 | Payphone Recognition Tone II 278 | 95 | Payphone Recognition Tone III 279 | 96 | Payphone Recognition Tone IV 280 | 97 | Permanent Signal Tone 281 | 98 | Positive Indication Tone 282 | 99 | Preemption Tone 283 |100 | Prompt Tone 284 |101 | Queue Tone 285 |102 | Recall Dial Tone 286 |103 | Recorder Warning Tone 287 |104 | Refusal Tone 288 |105 | Report on completion 289 |106 | Ringing Tone 290 |107 | Ringing Tone II 291 |108 | Ringing Tone III 292 |109 | Ringing Tone IV 293 |110-117 | Distinct. Ringing (8 varieties) 294 |118 | Ringing Tone (PABX) 295 |119 | Route Tone 296 |120 | Route Tone II 297 |121 | SIT Tone 298 |122 | Test Number Tone 299 |123 | Valid Tone 300 |124 | Waiting Tone I 301 |125 | Waiting Tone II 302 |126 | Waiting Tone III 303 |127 | Warning Tone (Operator Intervening) 304 |128 | Warning Tone (End of Period) 305 |129 | Warning Tone (PIP Tone) 306 |130 | Warning Tone PABX (Operator Intervening) 307 |131-255 | Reserved 308 ---------------------------------------------------------- 310 (Note: the encoding has been chosen to be backward compatible with 311 draft-ietf-dtmf-00.txt) 313 The audio waveforms corresponding to these tones are given in 314 Supplement 2 of the ITU-T E.180 standard. They are country dependent. 315 The events listed above which are not listed there are defined 316 as follows (much better to have Bellcore standard, what about other 317 tones?) 319 Wink 320 A transition from unseized to seized to unseized trunk states 321 within a specified period. Typical seizure period is 100-350 322 msec.) 324 Incoming seizure 325 Incoming indication of call attempt. 327 Return seizure: 328 Seizure in response to outgoing seizure. 330 Unseize circuit: 331 Unseizure of a circuit at the end of a call. 333 Wink off: 334 A signal used in operator services trunks. A transition from 335 seized to unseized to seized trunk states within a specified 336 period of 100-350 ms. (To be checked) 338 Continuity Test: 339 A tone at 2010 + or - 08 Hz. 341 Continuity Test: 342 A tone at the 1780 + or - 30 Hz. 344 Continuity Verified: 345 A tone at 2010 + or - 08 Hz. 347 Milliwatt Tones: 348 Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz) 350 Line Test: 351 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0 352 + or -- 0.5dB). 354 No circuit: 355 (that annoying tri-tone, low to high) 357 Answer Supervision: 359 Reorder Tone: 360 (120 Impulses per minute tone). 362 Calling Card Service Tone: 363 60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone), 364 decaying exponentially with a time constant of 200 ms. 366 If a gateway is detecting signal events for re-encoding within this NSE 367 Payload format, it SHOULD start transmitting event packets as soon 368 as it recognizes the event and every multiple of a frame 369 period or, for sample-based codecs, every 50 ms thereafter. If an 370 event continues for more than one period, it should send a new NSE 371 packet with the RTP timestamp value corresponding to the beginning of 372 the event and the duration of the digit increased correspondingly. 373 (The RTP sequence number is incremented by one for each packet.) 374 Note that the RTP timestamp value corresponding to the beginning of the 375 digit ( perhaps combined with the SSRC) can be used to avoid a mistaken 376 interpretation of two separate tones and the creation of spurious tones 377 at the receiver, in the case of packet loss. 379 Events are sent incrementally to avoid having the 380 receiver wait for the completion of the event. Since some 381 tones are very long, this would incur a substantial 382 delay. 384 3 Signal Tone Frequency Format 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | modulation |R R| volume | duration | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | mul | freq1 |R R R R| freq2 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 volume and duration are as in the signal tone frequency format. 394 freq1 and freq2 are values from 0Hz to 4096Hz. 395 Modulation is a value from 0Hz to 255Hz. 396 mul is a value from 0 to 15 398 Freq1 must be present; the presence of freq2 is optional. 399 (Is there some reason to prefer a fixed-length payload??) 401 The tone to be played is a sum of the frequencies freq1 and freq2, modulated 402 By Func(modulation, mul), where Func is defined as follows: 404 Func (x, y) = x * y / 3 406 ([E.180 supp. 2] defines modulation frequencies which go from 16Hz to 450Hz, 407 including a few fractional values such as 16 1/3 and 20 2/3). 409 Standard tone cadences can be built up using this RTP payload very easily. 410 Receivers which receive a consecutive sequence of STF packets MUST play 411 them out with a smoothly interpolated phase. 413 (Is there a need to include a bit for phase reversal??). 415 As a simple example, ringing tone in the United States is a tone of 420Hz 416 modulated by a sine wave of 25Hz, playing for 2 seconds, followed by silence 417 for 4 seconds, and then recycling. In France, ringing tone is an unmodulated 418 440Hz tone, playing for 1.5 seconds, followed by a silence for 3.5 seconds, 419 then recycling. When a call is placed from a phone in the USA to a phone in 420 France, the TSF format SHOULD be transmitted by the French 421 PSTN gateway back to an American gateway, in order to ensure that French 422 ringback tone is heard. (If some non RTP signalling had been used to convey 423 the information to the American gateway that the remote end is in France, 424 and the American gateway knew French tone cadences, it would be possible 425 to transmit the telephone signal events via the simpler TSE payload format). 427 4 Reliability 429 To achieve reliability even when the network loses packets, the audio 430 redundancy mechanism described in [RFC 2198] is used. The effective data 431 rate is !r! times 64 bits (32 bits for the redundancy header and 32 432 bits for the DTMF payload) every 50 ms or !r! times 1280 bits/second, 433 where !r! is the number of redundant events carried in each 434 packet. The value of !r! is an implementation trade-off, with a value 435 of 5 suggested. 437 Each TSE event SHOULD be retransmitted at least three times to ensure 438 some measure of reliability. 440 The timestamp offset in RFC2198 has 14 bits, 441 so that it allows a single packet to "cover" 2.048 seconds 442 of events at a sampling rate of 8000 Hz. Including the 443 starting time of previous events allows precise 444 reconstruction of the tone sequence at a gateway. The 445 scheme is resilient to consecutive packet losses spanning 446 this interval of 2.048 seconds or !r! events, whichever is 447 less. Note that for previous events, only an average 448 loudness can be represented. 450 An encoder MAY treat either TSE payload as a highly-compressed version 451 of the current audio frame. In that mode, each RTP packet during a 452 TSE tone would contain the current audio codec rendition (say, 453 G.723.1 or G.729) of this event as well as the representation 454 described in Section 2, plus any previous digits as before. 456 This approach allows dumb gateways that do not understand 457 this format to function. It also allows the actual audio 458 waveform to be sent with no extra delay, and then to be 459 covered by the TSE format when the transmitter detects the 460 signal event. 462 It is possible to mix these two audio telephony payload formats, in 463 order to adapt to network conditions and the shared knowledge of the 464 participants in the RTP session. 466 3.1 Example 468 3.1.1 NSE format 470 A typical RTP packet, where the user is just dialing the last digit 471 of the DTMF sequence "911". The first digit was 200 ms long and 472 started at time 0, the second digit lasted 250 ms and started at time 473 800 ms, the third digit has just been pressed for 100 ms, at time 1.5 474 s. The frame duration is 50 ms. To make the parts recognizable, the 475 figure below ignores byte alignment. Timestamp and sequence number 476 are assumed to have been zero at the beginning of the first digit. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |V=2|P|X| CC |M| PT | sequence number | 482 | 2 |0|0| 0 |0| 96 | 31 | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | timestamp | 485 | 12000 | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | synchronization source (SSRC) identifier | 488 | 0x5234a8 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 |F| block PT | timestamp offset | block length | 491 |1| 96 | 12400 | 4 | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 |F| block PT | timestamp offset | block length | 494 |1| 96 | 5600 | 4 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 |F| Block PT | 497 |0| 96 | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | event |R R| volume | duration | 500 | 9 |0 0| 7 | 1600 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | event |R R| volume | duration | 503 | 1 |0 0| 10 | 2000 | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | event |R R| volume | duration | 506 | 1 |0 0| 20 | 800 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 3.1.2 Mixed NSE and STF format 511 Here is a typical packet which might be sent from a French PSTN 512 gateway back to a PSTN gateway in the USA, during the transmission of 513 ringback tone (event number 106). This packet would be sent back 1.5 514 seconds into the transmission of the ringback tone. At this point, the 515 receiver should have heard 1.5 seconds of 440Hz tone: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |V=2|P|X| CC |M| PT | sequence number | 521 | 2 |0|0| 0 |0| 97 | 31 | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | timestamp | 524 | 12000 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | synchronization source (SSRC) identifier | 527 | 0x5234a8 | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |F| block PT | timestamp offset | block length | 530 |1| 96 | 12000 | 4 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 |F| block PT | timestamp offset | block length | 533 |1| 97 | 12000 | 6 | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |F| Block PT | 536 |0| 97 | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | event=106 |R R| volume=3 | duration=12000 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | modulation=1 |R R| volume=3 | duration=12000 | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |mul=3 | freq1=440 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | modulation=0 |R R| volume=0 | duration=28000 | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |mul=0 | freq1=0 | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 5 Acknowledgements 551 The suggestions of the VoIP working group are gratefully 552 acknowledged. Steve Magnell of Dialogic Corp. gave some very 553 useful advice. 555 6 Bibliography 557 [1] R. Kocen and T. Hatala, "Voice over frame relay implementation 558 agreement," Implementation Agreement FRF.11, Frame Relay Forum, 559 Foster City, California, Jan. 1997. 561 [RFC2198] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, 562 J.-C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP payload for 563 redundant audio data," RFC 2198, Internet Engineering Task Force, 564 Sept. 1997. 566 [MGCP] M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, Internet 567 Draft, Media Gateway Control Protocol (MGCP), Work in Progress, Oct. 98. 569 [E.180] Various Tones used in National Networks, ITU-T E.180, Supplement 2