Internet Engineering Task Force AVT WG Internet Draft Schulzrinne/Petrack draft-ietf-avt-tones-00.txt Columbia U./MetaTel June 25, 1999 Expires: December, 1999 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. 1 Introduction This memo defines a payload type for carrying dual-tone multifrequency (DTMF) digits and other line and trunk signals in RTP [1] packets. A separate RTP payload type is desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. Defining a separate payload type also permits higher redundancy while maintaining a low bit rate. The payload types described here may be useful in at least two applications: DTMF handling for gateways and end sytems, as well as "RTP trunks". In the first application, the Internet telephony gateway detects DTMF on the incoming circuits and sends the RTP payload described here instead of regular audio packets. The gateway Schulzrinne/Petrack [Page 1]
Internet Draft Tones June 25, 1999 likely has the necessary digital signal processors and algorithms, as it often needs to detect DTMF, e.g., for two-stage dialing. Having the gateway detect tones relieves the receiving Internet end system from having to do this work and also avoids that low bit-rate codecs like G.723.1 render DTMF tones unintelligible. Similarly, an Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs. In the "RTP trunk" application, RTP is used to replace a normal circuit-switched trunk between two nodes. This is particularly of interest in a telephone network that is still mostly circuit- switched. In this case, each end of the RTP trunk encodes audio channels into the appropriate encoding, such as G.723.1 or G.729. However, this encoding process destroys in-band signaling information which is carried using the least-significant bit ("robbed bit signaling") and may also interfere with in-band signaling tones, such as the MF digit tones. In addition, tone properties such as the phase reversals in the ANSam tone, will ot survive speech coding. Thus, the gateway needs to remove the in-band signaling information from the bit stream. It can now either carry it out-of-band in a signaling transport mechanism yet to be defined, or it can use the mechanism described in this memorandum. (If the two trunk end points are within reach of the same media gateway controller, the media gateway controller can also handle the signaling.) Carrying it in-band may simplify the time synchronization between audio packets and the tone or signal information. This is particularly relevant where duration and timing matter, as in the carriage of DTMF signals. A gateway has two options for handling DTMF digits and signals. First, it can simply measure the frequency components of the voice band signals and transmit this information to the RTP receiver. All tone signals in use in the PSTN and meant for human consumption are sequences of simple combinations of sine waves, either added or modulated. (There is at least one tone, the ANSam tone [2] used for indicating data transmission over voice lines, that makes use of periodic phase reversals.) As a second option, it can recognize the tones and translate them into a name, such as ringing or busy tone. The receiver then produces a tone signal or other indication appropriate to the signal. Generally, since the recognition of signals often depends on their on/off pattern or the sequence of several tones, this recognition can take several seconds. On the other hand, the gateway may have access to the actual signaling information that generates the tones and thus can generate the RTP packet immediately, without the detour through acoustic signals. In the phone network, tones are generated at different places, Schulzrinne/Petrack [Page 2]
Internet Draft Tones June 25, 1999 depending on the switching technology and the nature of the tone. This determines, for example, whether a person making a call to a foreign country hears her local tones she is familiar with or the tones as used in the country called. For analog lines, Dial tone is always generated by the local switch. ISDN terminals may generate dial tone locally and then send a Q.931 SETUP message containing the dialed digits. If the terminal just sends a SETUP message without any Called Party digits, then the switch does digit collection, provided by the terminal as KEYPAD messages, and provides dial tone over the B-channel. The terminal can either use the audio signal on the B-channel or can use the Q.931 messages to trigger locally generated dial tone. Ringing tone (also called ringback tone) is generated by the local switch at the callee, with a one-way voice path opened up as soon as the callee's phone rings. (This reduces the chance of clipping of the called party's response just after answer. It also permits pre-answer announcements or in-band call-progress-indications to reach the caller before or in lieu of ringing tone.) Congestion tone and special information tones can be generated by any of the switches along the way, and may be generated by the caller's switch based on ISUP messages received. Busy tone is generated by the caller's switch, triggered by the appropriate ISUP message, for analog instruments, or the ISDN terminal. Gateways which send signalling events via RTP SHOULD send both named signals (Section 2) and the tone representation (Section 4) as a single RTP session, using the redundancy mechanism defined in Section 2.4. The receiver can then choose the appropriate rendering. If a gateway cannot present a tone representation, it SHOULD send the audio tones as regular RTP audio packets (e.g., as payload type PCMU), in addition to the named signals. 2 RTP Payload Format for Named Telephone Events 2.1 Requirements The DTMF payload type must be suitable for both gateway and end-to- end scenarios. In the gateway scenario, a gateway connecting a packet voice network to the PSTN recreates the DTMF tones and injects them into the PSTN. Since DTMF digit recognition takes several tens of milliseconds, the first few milliseconds of a digit will arrive as regular audio packets. Thus, careful time and power (volume) alignment is needed to avoid generating spurious digits. For interactive voice response (IVR) systems directly connected to Schulzrinne/Petrack [Page 3]
Internet Draft Tones June 25, 1999 the packet voice network, time alignment and volume levels are not important, since the unit will not perform any signal analysis to detect DTMF tones from the audio stream. DTMF digits and named events are carried as part of the audio stream, and SHOULD use the same sequence number and time-stamp base as the regular audio channel to simplify recreation of analog audio at a gateway. The default clock frequency is 8000 Hz, but the clock frequency can be redefined when assigning the dynamic payload type. This format achieves a higher redundancy even in the case of sustained packet loss than the method proposed for the Voice over Frame Relay Implementation Agreement [3]. In circumstances where exact timing alignment between the audio stream and the DTMF digits is not important and data is sent unicast, such as the IVR example mentioned earlier, it may be preferable to use a reliable control stream such as H.245. A source MAY send events and coded audio packets for the same time instants, using events as the redundant encoding for the audio stream, or it MAY block outgoing audio while event tones are active and only send named events as both the primary and redundant encodings. This payload definition is used by five different payload types: dtmf for DTMF tones (Section 2.7); fax for fax-related tones (Section 2.8); line for standard subscriber line tones (Section 2.9); linex for country-specific subscriber line tones (Section 3) and; trunk for trunk events (Section 3.1). The payload format is identical, but the payload types assigned MUST be different. The separation into different payload types makes it easy for end systems to declare their capabilities using session description protocols such as SDP. If desired, end systems can declare support of a subset of these payload types by including a "fmtp" parameter listing the supported event types. Details are for further study. A compliant implementation MUST support the events listed in Table 1. If it uses some other, out-of-band mechanism for signaling line Schulzrinne/Petrack [Page 4]
Internet Draft Tones June 25, 1999 conditions, it does not have to implement the other payload types. In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Depending on the available user interfaces, an implementation MAY render all tones in Table 5 the same or, preferably, use the tones conveyed by the concurrent "tone" payload or other RTP audio payload. Alternatively, it could provide a textual representation. Note that end systems that emulate telephones only need to support the "dtmf" and "line" payload type. Systems that receive trunk signaling need to implement the "dtmf", "fax", "line", and "trunk' payload types, since MF trunks also carry most of the "line" signals. Systems that do not support fax functionality do not need to render fax-related events in the "fax" payload type. The payload type distinguishes between a (line) DTMF 0 tone and a (trunk) MF 0 tone. They payload type is signalled dynamically (for example, within an SDP [4] or an H.245 message), or by some other non-RTP means. 2.2 Use of RTP Header Fields Timestamp: The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 2.3 extends forwards [NOTE: was "backwards", but that's different from all other payloads and disagrees with RFC 1889] from that time. 2.3 Payload Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |R R| volume | duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ events: The DTMF digits and line events are encoded as shown in Section 2.9; the trunk events are shown in Section 3.1. volume: The power level of the digit, expressed in dBm0 after dropping the sign, with range from 0 to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger Schulzrinne/Petrack [Page 5]
Internet Draft Tones June 25, 1999 values denote lower volume. This value is defined only for DTMF digits. For other events, it is set to zero. Note: Since the acceptable dip is 10 dB and the minimum detectable loudness variation is 3 dB, this field could be compressed by at least a bit by reducing resolution to 2 dB, if needed. duration: Duration of this digit, in timestamp units. Thus, the digit began at the instant identified by the RTP timestamp. For a sampling rate of 8000 Hz, this field is sufficient to express digit durations of upto approximately 8 seconds. R: This field is reserved for future use. The sender MUST set it to zero, the receiver MUST ignore it. An audio source SHOULD start transmitting event packets as soon as it recognizes an event and every 50 ms thereafter or the packet interval for the audio codec used for this session, if known. (Precise spacing between event packets is not necessary.) Q.24 [5], Table A-1, indicates that all administrations surveyed use a minimum signal duration of 40 ms, with signaling velocity (tone and pause) of no less than 93 ms. If a digit continues for more than one period, it should send a new event packet with the RTP timestamp value corresponding to the beginning of the digit and the duration of the digit increased correspondingly. (The RTP sequence number is incremented by one for each packet.) If there has been no new digit in the last interval, the digit SHOULD be retransmitted three times (or until the next event is recognized) to ensure some measure of reliability for the last event. DTMF digits and events are sent incrementally to avoid having the receiver wait for the completion of the digit. Since some tones are two seconds long, this would incur a substantial delay. The transmitter does not know if digit length is important and thus needs to transmit immediately and incrementally. If the receiver application does not care about digit length, the incremental transmission mechanism avoids delay. Some applications, such as gateways into the GSTN, care about both delays and digit duration. 2.4 Reliability Schulzrinne/Petrack [Page 6]
Internet Draft Tones June 25, 1999 To achieve reliability even when the network loses packets, the audio redundancy mechanism described in RFC 2198 [6] is used. The effective data rate is r times 64 bits (32 bits for the redundancy header and 32 bits for the DTMF payload) every 50 ms or r times 1280 bits/second, where r is the number of redundant DTMF digits carried in each packet. The value of r is an implementation trade-off, with a value of 5 suggested. The timestamp offset in this redundancy scheme has 14 bits, so that it allows a single packet to "cover" 2.048 seconds of DTMF digits at a sampling rate of 8000 Hz. Including the starting time of previous digits allows precise reconstruction of the tone sequence at a gateway. The scheme is resilient to consecutive packet losses spanning this interval of 2.048 seconds or r digits, whichever is less. Note that for previous digits, only an average loudness can be represented. An encoder MAY treat the event payload as a highly-compressed version of the current audio frame. In that mode, each RTP packet during a DTMF tone would contain the current audio codec rendition (say, G.723.1 or G.729) of this digit as well as the representation described in Section 2.3, plus any previous digits as before. This approach allows dumb gateways that do not understand this format to function. See also the discussion in Section 1. TBD: It may be possible 2.5 Example A typical RTP packet, where the user is just dialing the last digit of the DTMF sequence "911". The first digit was 200 ms long (1600 timestamp units) and started at time 0, the second digit lasted 250 ms (2000 timestamp units) and started at time 800 ms (6400 timestamp units), the third digit was pressed at time 1.4 s (11,200 timestamp units) and the packet shown was sent at 1.45 s (11,600 timestamp units). The frame duration is 50 ms. To make the parts recognizable, the figure below ignores byte alignment. Timestamp and sequence number are assumed to have been zero at the beginning of the first digit. In this example, the dynamic payload types 96 and 97 have been assigned for the redundancy mechanism and the DTMF payload, respectively. Schulzrinne/Petrack [Page 7]
Internet Draft Tones June 25, 1999 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |0| 96 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 11200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | | 0x5234a8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | |1| 97 | 11200 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | |1| 97 | 4800 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Block PT | |0| 97 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | digit |R R| volume | duration | | 9 |0 0| 7 | 1600 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | digit |R R| volume | duration | | 1 |0 0| 10 | 2000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | digit |R R| volume | duration | | 1 |0 0| 20 | 400 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.6 Compact Reliability Scheme A more compact representation could be achieved by measuring DTMF tones in a different sampling rate from that of the surrounding audio codec, e.g., as multiples of 1, 10, 40 or 50 ms. Each RTP payload type should have a fixed sampling rate, so choosing a value that depends on frame interval of the surrounding codec is not recommended. For a sampling interval of 50 ms, the following payload would "cover" 8 seconds of duration and offset: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | offset |R R R| digit |R R| volume | duration | Schulzrinne/Petrack [Page 8]
Internet Draft Tones June 25, 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.7 DTMF Events Tables 1 summarizes the events belonging to the DTMF payload type. It uses the RTP encoding name "dtmf" and the MIME type "audio/dtmf". Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16 Table 1: DTMF events 2.8 Data Modem and Fax Events Table 2.8 summarizes the events and tones that can appear on a subscriber line serving a fax machine or modem. It uses the encoding name "data" and the MIME type "audio/data". The tones are described below, with additional detail in Table 7. ANS: This 2100 +/- 15 Hz tone is used to disable echo suppression for data transmission [7,8]. For fax machines, Recommendation T.30 [8] refers to this tone as called terminal identification (CED) answer tone. /ANS: This is the same signal as ANS, except that it reverses phase at an interval of 450 +/- 25 ms. It disables both echo cancellers and echo suppressors. (In the ITU Recommendation, this signal is rendered as ANS with a bar on top.) ANSam: The modified answer tone (ANSam) [2] is a sinewave signal at 2100 +/- 1 Hz with phase reversals at an interval of 450 +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone [9,7] is sent by modems [10] and faxes to disable echo suppressors. /ANSam: This is the same signal as ANSam, except that it reverses phase at an interval of 450 +/- 25 ms. It disables both echo cancellers and echo suppressors. (In the ITU Recommendation, this signal is rendered as ANSam with a bar on top.) Schulzrinne/Petrack [Page 9]
Internet Draft Tones June 25, 1999 CNG: After dialing the called fax machine's telephone number (and before it answers), the calling Group III fax machine (optionally) begins sending a CalliNG tone (CNG) consisting of an interrupted tone of 1100 Hz. [8] CRd: Capabilities Request (CRd) [11] is a dual-tone signal with tones at tones at 1375 Hz and 2002 Hz for 400 ms for the initiating side and 1529 Hz and 2225 Hz for the responding side, followed by a single tone at 1900 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRd is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to a CRe or MRe." CRe: Capabilities Request (CRe) [11] is a dual-tone signal with tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 400 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRe is sent by an automatic answering station at call establishment." ESi: Escape Signal (ESi) [11] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 980 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode. signal ESi is sent by the initiating station." ESr: Escape Signal (ESr) [11] is a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1650 Hz for 100 ms. Same as ESi, but sent by the responding station. MRd: Mode Request (MRd) [11] is a dual-tone signals with tones at 1375 Hz and 2002 Hz for 400 ms for the initiating side and 1529 Hz and 2225 Hz for the responding side, followed by a single tone at 1150 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRd is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to an MRe." [11] MRe: Mode Request (MRe) [11] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 650 Hz Schulzrinne/Petrack [Page 10]
Internet Draft Tones June 25, 1999 for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRe is sent by an automatic answering station at call establishment." [11] V.21: V.21 describes a 300 b/s full-duplex modem that employs frequency shift keying (FSK). It is now used by Group 3 fax machines to exchange T.30 information. The calling transmits on channel 1 and receives on channel 2; the answering modem transmits on channel 2 and receives on channel 1. Each bit value has a distinct tone, so that V.21 signaling comprises a total of four distinct tones. In summary, procedures in Table 2 are used. Procedure indications ________________________________________________________ V.25 and V.8 ANS, ANS, ... V.25, echo canceller disabled ANS, /ANS, ANS, /ANS V.8 ANSam, ANSam, ... V.8, echo canceller disabled ANSam, /ANSam, ANSam, ... Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations Event____________________encoding_(decimal) Answer tone (ANS) 1 ANSam 2 Calling tone (CNG) 3 V.21 channel 1, "0" bit 4 V.21 channel 1, "1" bit 5 V.21 channel 2, "0" bit 6 V.21 channel 2, "1" bit 7 Table 3: Data and fax events 2.9 Line Events Table 4 summarizes the events and tones that can appear on a subscriber line. It uses the encoding name "line" and the MIME type "audio/line". Schulzrinne/Petrack [Page 11]
Internet Draft Tones June 25, 1999 ITU Recommendation E.182 [12] defines when certain tones should be used. It defines the following standard tones that are heard by the caller: Dial tone: The exchange is ready to receive address information. PABX internal dial tone: The PABX is ready to receive address information. Special dial tone: Same as dial tone, but the caller's line is subject to a specific condition, such as call diversion or a voice mail is available (e.g., "stutter dial tone"). Second dial tone: The network has accepted the address information, but additional information is required. Ringing tone: The call has been placed to the callee and a calling signal (ringing) is being transmitted to the callee. Special ringing tone: A special service, such as call forwarding or call waiting, is active at the called number. Busy tone: The called telephone number is busy. Congestion tone: Facilities necessary for the call are temporarily unavailable. Calling card service tone: The calling card service tone consists of 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'), followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone), decaying exponentially with a time constant of 200 ms. Special information tone: The callee cannot be reached, but the reason is neither "busy" nor "congestion". This tone should be used before all call failure announcements, for the benefit of automatic equipment. Comfort tone: The call is being processed. This tone may be used during long post-dial delays, e.g., in international connections. Hold tone: The caller has been placed on hold. Replaced by Greensleeves Record tone: The caller has been connected to an automatic answering device and is requested to begin speaking. Caller waiting tone: The called station is busy, but has call waiting Schulzrinne/Petrack [Page 12]
Internet Draft Tones June 25, 1999 service. Pay tone: The caller, at a payphone, is reminded to deposit additional coins. Positive indication tone: The supplementary service has been activated. Negative indication tone: The supplementary service could not be Off-hook warning tone: The caller has left the instrument off-hook for an extended period of time. activated. The following tones can be heard be either calling or called party during a conversation: Call waiting tone: Another party wants to reach the subscriber. Warning tone: The call is being recorded. This tone is not required in all jurisdictions. Intrusion tone: The call is being monitored, e.g., by an operator. (Use by law enforcement authorities is optional.) CPE alerting signal (CAS): A tone used to alert a device to an arriving in-band FSK data transmission. A CAS is a combined 2130 and 2750 Hz tone, both with tolerances of 0.5% and a duration of 80 to 80 ms. CAS is used with ADSI services and Call Waiting ID services, see Bellcore GR-30-CORE, Issue 2, December 1998, Section 2.5.2. The following tones are heard by operators: Payphone recognition tone: The person making the call or being called is using a payphone (and thus it is ill-advised to allow collect calls to such a person). 3 Extended Line Events Table 5 summarizes country-specific events and tones that can appear on a subscriber line. It uses the encoding name "linex" and the MIME type "audio/linex". 3.1 Trunk Events Table 6 summarizes the events and tones that can appear on a trunk. Schulzrinne/Petrack [Page 13]
Internet Draft Tones June 25, 1999 Event encoding (decimal) _____________________________________________ Off Hook 0 On Hook 1 Dial tone 2 PABX internal dial tone 3 Special dial tone 4 Second dial tone 5 Ringing tone 6 Special ringing tone 7 Busy tone 8 Congestion tone 9 Special information tone 10 Comfort tone 11 Hold tone 12 Record tone 13 Caller waiting tone 14 Call waiting tone 15 Pay tone 16 Positive indication tone 17 Negative indication tone 18 Warning tone 19 Intrusion tone 20 Calling card service tone 21 Payphone recognition tone 22 CPE alerting signal (CAS) 23 Off-hook warning tone 24 Table 4: E.182 line events It uses the encoding name "TRUNK" and the MIME type "audio/trunk". Note that trunk can also carry line events, as MF signaling does not include backward signals [13]. [NOTE: the list below, below wink, does not agree with the MF description in van Bosse, p. 74.] Wink: A brief transition, typically 120-290 ms, from on-hook (unseized) to off-hook (seized) and back to onhook, used by the incoming exchange to signal that the call address signaling can proceed. Incoming seizure: Incoming indication of call attempt (off-hook). Return seizure: Seizure by answering exchange, in response to outgoing seizure. [NOTE: Not clear why the difference here, but Schulzrinne/Petrack [Page 14]
Internet Draft Tones June 25, 1999 Event encoding (decimal) ___________________________________________________ Acceptance tone 0 Confirmation tone 1 Dial tone, recall 2 End of three party service tone 3 Facilities tone 4 Line lockout tone 5 Number unobtainable tone 6 Offering tone 7 Permanent signal tone 8 Preemption tone 9 Queue tone 10 Refusal tone 11 Route tone 12 Valid tone 13 Waiting tone 14 Warning tone (end of period) 15 Warning Tone (PIP tone) 16 Table 5: Country-specific Line events not for Unseize. Should probably be just Seizure.] Unseize circuit: Transition of circuit from off-hook to on-hook at the end of a call. Wink off: A brief transition, typically 100-350 ms, from off-hook (seized) to on-hook (unseized) and back to off-hook (seized). Used in operator services trunks. [CHECK!] Continuity tone send: A tone of 2010 Hz. Continuity tone detect: A tone of 2010 Hz. Continuity test send: A tone of 1780 Hz is sent by the calling exchange. If received by the called exchange, it returns a "continuity verified" tone. Continuity verified: A tone of 2010 Hz. This is a response tone, used in dual-tone procedures. Line test: 105 [EXPLAIN!] test line progress tones (2225 Hz at -10 dbm0). 4 RTP Payload Format for Telephony Tones Schulzrinne/Petrack [Page 15]
Internet Draft Tones June 25, 1999 Event encoding (decimal) __________________________________________________ MF 0... 9 0... 9 MF K0 or KP (start-of-pulsing) 10 MF K1 11 MF K2 12 MF S0 to ST (end-of-pulsing) 13 MF S1... S3 14... 16 Wink 17 Wink off 18 Incoming seizure 19 Return seizure 20 Unseize circuit 21 Continuity test 22 Default continuity tone 23 Continuity tone (single tone) 24 Continuity test send 25 Continuity verified 26 Loopback 27 Old milliwatt tone (1000 Hz) 28 New milliwatt tone (1004 Hz) 29 Table 6: Trunk events 4.1 Requirements As an alternative to describing tones and events by name, it is sometimes preferable to describe them by their acoustic properties. In particular, recognition is faster than for naming signals. There is no single international standard for telephone tones such as dial tone, ringing (ringback), busy, congestion ("fast-busy"), special announcement tones or some of the other special tones, such as payphone recognition, call waiting or record tone. However, across all countries, these tones share a number of characteristics [14]: o Tones consist of either a single tone, the addition of two or three tones or the modulation of two tones. (Almost all tones use two frequencies; only the Hungarian "special dial tone" has three.) Tones that are mixed have the same amplitude and do not decay. o Tones for telephony events are in the range of 25 (ringing tone in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz. The telephone frequency range is limited to 3,400 Hz. Schulzrinne/Petrack [Page 16]
Internet Draft Tones June 25, 1999 o Modulation frequencies range between 15 (ANSam tone) to 480 Hz (Jamaica). Non-integer frequencies are used only for frequencies of 16 2/3 and 33 1/3 Hz. (These fractional frequencies appear to be derived from older AC power grid frequencies.) o Tones that are not continuous have durations of less than four seconds. o ITU Recommendation E.180 [15] notes that different telephone companies proscribe a tone accuracy of between 0.5 and 1.5%. The Recommendation suggests a frequency tolerance of 1%. 4.2 Examples of Common Telephone Tone Signals As an aid to the implementor, Table 7 summarizes some common tones. The rows labeled "ITU ..." refer to the general recommendation of Recommendation E.180 [15]. Note that there are no specific guidelines for these tones. In the table, the symbol "+" indicates addition of the tones, without modulation, while "*" indicates amplitude modulation. [ADD ADDITIONAL COUNTRIES, IF DESIRED.] The meaning of some of the tones is described in Section 2.9 or Section 2.8 (for V.21). 4.3 Use of RTP Header Fields Timestamp: The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 2.3 extends forwards [NOTE: was "backwards", but that's different from all other payloads and disagrees with RFC 1889] from that time. 4.4 Payload Format Based on the characteristics described above, the payload format is shown in Fig. 1. Figure 1: Payload format for tones The payload contains the following fields: modulation: The modulation frequency, in Hz. The field is a 9-bit unsigned integer, allowing modulation frequencies up to 511 Hz. Schulzrinne/Petrack [Page 17]
Internet Draft Tones June 25, 1999 Tone name frequency on period off period ______________________________________________________ CNG 1100 0.5 3.0 CED 2100 3.3 -- ANS 2100 3.3 -- ANSam 2100*15 3.3 -- V.21 "0" bit, ch. 1 1180 0.033 V.21 "1" bit, ch. 1 980 0.033 V.21 "0" bit, ch. 2 1850 0.033 V.21_"1"_bit,_ch._2________1650______0.033____________ ITU dial tone 425 -- -- U.S. dial tone 350+440 -- -- ______________________________________________________ ITU ringing tone 425 0.67--1.5 3--5 U.S._ringing_tone_______440+480________2.0_________4.0 ITU busy tone 425 U.S. busy tone 480+620 0.5 0.5 ______________________________________________________ ITU congestion tone 425 U.S. congestion tone 480+620 0.25 0.25 Table 7: Examples of telephony tones 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulation |T| volume | duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| frequency |R R R R| frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| frequency |R R R R| frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| frequency |R R R R| frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If there is no modulation, this field has a value of zero. T: If the "T" bit is set (one), the modulation frequency is to be divided by three. Otherwise, the modulation frequency is taken as is. volume: The power level of the digit, expressed in dBm0 after dropping the sign, with range from 0 to -63 dBm0. (Note: A Schulzrinne/Petrack [Page 18]
Internet Draft Tones June 25, 1999 preferred level range for digital tone generators is -8 dBm0 to -3 dBm0.) duration: The duration of the tone, measured in timestamp units. The tone begins at the instant identified by the RTP timestamp and lasts for the duration value. The definition of duration corresponds to that for sample- based codecs, where the timestamp represents the sampling point for the first sample. frequency: The frequencies of the tones to be added, measured in Hz and represented as a 12-bit unsigned integer. The field size is sufficient to represent frequencies up to 4095 Hz, which exceeds the range of telephone systems. A value of zero indicates silence. R: This field is reserved for future use. The sender MUST set it to zero, the receiver MUST ignore it. The RTP payload type is designated as "TONE", the MIME type as "audio/tone". The default timestamp rate is 8,000 Hz, but other rates may be used. Note that the timestamp rate does not affect the interpretation of the frequency, just the durations. 4.5 Reliability Same as Section 2.4. 5 Combining Tones and Named Signals The payload formats in Sections 2 and 4 can be combined into a single payload, as shown in the example depicted in Fig. 2. In the example, the RTP packet combines two TONE and one LINE payload. The payload types are chosen arbitrarily as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the redundancy format has the dynamic payload type 96. The packet represents a snapshot of U.S. ringing tone, 1.5 seconds (12,000 timestamp units) into the second "on" part of the 2.0/4.0 second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) into the ring cycle. The 440 + 480 Hz tone of this second cadence started at RTP timestamp 48,000. Four seconds of silence preceded it, but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds (16383 timestamp units) can be represented. Even though the tone sequence is not complete, the sender was able to determine that this is indeed ringback, and thus includes the corresponding LINE event. Schulzrinne/Petrack [Page 19]
Internet Draft Tones June 25, 1999 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |0| 96 | 31 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 48000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | | 0x5234a8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | |1| 98 | 16383 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | |1| 97 | 16383 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Block PT | |0| 97 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event=ring |0|0| volume=0 | duration=28383 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulation=0 |0| volume=63 | duration=16383 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| frequency=0 |0 0 0 0| frequency=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulation=0 |0| volume=5 | duration=12000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| frequency=440 |0 0 0 0| frequency=480 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Combining tones and events in a single RTP packet 6 History o This draft combines draft-ietf-avt-dtmf-00 and draft-ietf- avt-telephone-tones-01. Schulzrinne/Petrack [Page 20]
Internet Draft Tones June 25, 1999 o From draft draft-ietf-avt-dtmf-00, the interval was changed to be uniform at 50 ms, since audio frame interval may change based on codec. o From draft-ietf-avt-telephone-tones-01, a generic tone representation was added. 7 IANA Considerations This document defines three new RTP payload names and associated MIME Types, TONE (audio/tone), LINE (audio/line) and TRUNK (audio/trunk). Within the TRUNK and LINE RTP payload types, additional entries for events MUST be registered with IANA. Before registration, IANA should consult the current chair of the AVT working group or its successor to avoid duplication of definitions. 8 Acknowledgements The suggestions of the Megaco working group are gratefully acknowledged. Detailed advice and comments were provided by Fred Burg, Fatih Erdin, Mike Fox, Terry Lyons, and Steve Magnell. 9 Authors Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu Scott Petrack MetaTel 284 North Avenue Weston, MA 02493 USA electronic mail: scott.petrack@metatel.com 10 Bibliography [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. [2] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network," Recommendation V.8, Telecommunication Standardization Schulzrinne/Petrack [Page 21]
Internet Draft Tones June 25, 1999 Sector of ITU, Geneva, Switzerland, Feb. 1998. [3] R. Kocen and T. Hatala, "Voice over frame relay implementation agreement," Implementation Agreement FRF.11, Frame Relay Forum, Foster City, California, Jan. 1997. [4] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments (Proposed Standard) 2327, Internet Engineering Task Force, Apr. 1998. [5] International Telecommunication Union, "Multifrequency push- button signal reception," Recommendation Q.24, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1988. [6] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP payload for redundant audio data," Request for Comments (Proposed Standard) 2198, Internet Engineering Task Force, Sept. 1997. [7] International Telecommunication Union, "Automatic answering equipment and general procedures for automatic calling equipment on the general switched telephone network including procedures for disabling of echo control devices for both manually and automatically established calls," Recommendation V.25, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996. [8] International Telecommunication Union, "Procedures for document facsimile transmission in the general switched telephone network," Recommendation T.30, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 1996. [9] International Telecommunication Union, "Echo cancellers," Recommendation G.165, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993. [10] International Telecommunication Union, "A modem operating at data signalling rates of up to 33 600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits," Recommendation V.34, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. [11] International Telecommunication Union, "Procedures for the identification and selection of common modes of operation between data circuit-terminating equipments (dces) and between data terminal equipments (dtes) over the public switched telephone network and on leased point-to-point telephone-type circuits," Recommendation V.8bis, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Sept. 1998. Schulzrinne/Petrack [Page 22]
Internet Draft Tones June 25, 1999 [12] International Telecommunication Union, "Application of tones and recorded announcements in telephone services," Recommendation E.182, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1998. [13] J. G. van Bosse, Signaling in Telecommunications Networks Telecommunications and Signal Processing, New York, New York: Wiley, 1998. [14] International Telecommunication Union, "Various tones used in national networks," Recommendation Supplement 2 to Recommendation E.180, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994. [15] International Telecommunication Union, "Technical characteristics of tones for telephone service," Recommendation Supplement 2 to Recommendation E.180, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994. Schulzrinne/Petrack [Page 23]
