RFC relevance of duration

As per Relevance of the word duration, we have this rfc below:

Network Working Group H.
Request for Comments: 2833 Columbia
Category: Standards Track S.

May 2000

RTP Payload for DTMF Digits, Telephony Tones and Telephony

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This memo describes how to carry dual-tone multifrequency (DTMF
signaling, other tone signals and telephony events in RTP packets

1

This memo defines two payload formats, one for carrying dual-
multifrequency (DTMF) digits, other line and trunk signals (
3), and a second one for general multi-frequency tones in RTP [1]
packets (Section 4). Separate RTP payload formats are desirable
low-rate voice codecs cannot be guaranteed to reproduce these
signals accurately enough for automatic recognition.
separate payload formats also permits higher redundancy
maintaining a low bit rate

The payload formats described here may be useful in at least
applications: DTMF handling for gateways and end systems, as well
"RTP trunks". In the first application, the Internet
gateway detects DTMF on the incoming circuits and sends the
payload described here instead of regular audio packets. The
likely has the necessary digital signal processors and algorithms,
it often needs to detect DTMF, e.g., for two-stage dialing.
the gateway detect tones relieves the receiving Internet end
from having to do this work and also avoids that low bit-rate
like G.723.1 render DTMF tones unintelligible. Secondly, an

Schulzrinne & Petrack Standards Track [Page 1]

RFC 2833 Tones May 2000

end system such as an "Internet phone" can emulate DTMF
without concerning itself with generating precise tone pairs
without imposing the burden of tone recognition on the receiver

In the "RTP trunk" application, RTP is used to replace a
circuit-switched trunk between two nodes. This is particularly
interest in a telephone network that is still mostly circuit
switched. In this case, each end of the RTP trunk encodes
channels into the appropriate encoding, such as G.723.1 or G.729.
However, this encoding process destroys in-band signaling
which is carried using the least-significant bit ("robbed
signaling") and may also interfere with in-band signaling tones,
as the MF digit tones. In addition, tone properties such as the
reversals in the ANSam tone, will not survive speech coding. Thus
the gateway needs to remove the in-band signaling information
the bit stream. It can now either carry it out-of-band in a
transport mechanism yet to be defined, or it can use the
described in this memorandum. (If the two trunk end points are
reach of the same media gateway controller, the media
controller can also handle the signaling.) Carrying it in-band
simplify the time synchronization between audio packets and the
or signal information. This is particularly relevant where
and timing matter, as in the carriage of DTMF signals

1.1

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]
indicate requirement levels for compliant implementations

2 Events vs.

A gateway has two options for handling DTMF digits and events. First
it can simply measure the frequency components of the voice
signals and transmit this information to the RTP receiver (
4). In this mode, the gateway makes no attempt to discern the
of the tones, but simply distinguishes tones from speech signals

All tone signals in use in the PSTN and meant for human
are sequences of simple combinations of sine waves, either added
modulated. (There is at least one tone, the ANSam tone [3] used
indicating data transmission over voice lines, that makes use
periodic phase reversals.)

As a second option, a gateway can recognize the tones and
them into a name, such as ringing or busy tone. The receiver
produces a tone signal or other indication appropriate to the signal

Schulzrinne & Petrack Standards Track [Page 2]

RFC 2833 Tones May 2000

Generally, since the recognition of signals often depends on
on/off pattern or the sequence of several tones, this recognition
take several seconds. On the other hand, the gateway may have
to the actual signaling information that generates the tones and
can generate the RTP packet immediately, without the detour
acoustic signals

In the phone network, tones are generated at different places
depending on the switching technology and the nature of the tone
This determines, for example, whether a person making a call to
foreign country hears her local tones she is familiar with or
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
sends a SETUP message without any Called Party digits, then
switch does digit collection, provided by the terminal as
messages, and provides dial tone over the B-channel. The terminal
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
switch at the callee, with a one-way voice path opened up as soon
the callee's phone rings. (This reduces the chance of clipping
called party's response just after answer. It also permits pre-
announcements or in-band call-progress indications to reach
caller before or in lieu of a ringing tone.) Congestion tone
special information tones can be generated by any of the
along the way, and may be generated by the caller's switch based
ISUP messages received. Busy tone is generated by the caller'
switch, triggered by the appropriate ISUP message, for
instruments, or the ISDN terminal

Gateways which send signaling events via RTP MAY send both
signals (Section 3) and the tone representation (Section 4) as
single RTP session, using the redundancy mechanism defined in
3.7 to interleave the two representations. It is generally a
idea to send both, since it allows the receiver to choose
appropriate rendering

If a gateway cannot present a tone representation, it SHOULD send
audio tones as regular RTP audio packets (e.g., as payload
PCMU), in addition to the named signals

Schulzrinne & Petrack Standards Track [Page 3]

RFC 2833 Tones May 2000

3 RTP Payload Format for Named Telephone

3.1

The payload format for named telephone events described below
suitable for both gateway and end-to-end scenarios. In the
scenario, an Internet telephony gateway connecting a packet
network to the PSTN recreates the DTMF tones or other
events and injects them into the PSTN. Since, for example, DTMF
recognition takes several tens of milliseconds, the first
milliseconds of a digit will arrive as regular audio packets. Thus
careful time and power (volume) alignment between the audio
and the events is needed to avoid generating spurious digits at
receiver

DTMF digits and named telephone events are carried as part of
audio stream, and MUST use the same sequence number and time-
base as the regular audio channel to simplify the generation of
waveforms at a gateway. The default clock frequency is 8,000 Hz,
the clock frequency can be redefined when assigning the
payload type

The payload format described here achieves a higher redundancy
in the case of sustained packet loss than the method proposed for
Voice over Frame Relay Implementation Agreement [4].

If an end system is directly connected to the Internet and does
need to generate tone signals again, time alignment and power
are not relevant. These systems rely on PSTN gateways or Internet
systems to generate DTMF events and do not perform their own
waveform analysis. An example of such a system is an
interactive voice-response (IVR) system

In circumstances where exact timing alignment between the
stream and the DTMF digits or other events is not important and
is sent unicast, such as the IVR example mentioned earlier, it may
preferable to use a reliable control protocol rather than
packets. In those circumstances, this payload format would not
used

3.2 Simultaneous Generation of Audio and

A source MAY send events and coded audio packets for the same
instants, using events as the redundant encoding for the
stream, or it MAY block outgoing audio while event tones are
and only send named events as both the primary and
encodings

Schulzrinne & Petrack Standards Track [Page 4]

RFC 2833 Tones May 2000

Note that a period covered by an encoded tone may overlap in
with a period of audio encoded by other means. This is likely
occur at the onset of a tone and is necessary to avoid
errors in the interpretation of the reproduced tone at the
end. Implementations supporting this payload format must be
to handle the overlap. It is RECOMMENDED that gateways only
the encoded tone since the audio may contain spurious
introduced by the audio compression algorithm. However, it
anticipated that these extra tones in general should not
with recognition at the far end

3.3 Event

This payload format is used for five different types of signals

o DTMF tones (Section 3.10);

o fax-related tones (Section 3.11);

o standard subscriber line tones (Section 3.12);

o country-specific subscriber line tones (Section 3.13) and

o trunk events (Section 3.14).

A compliant implementation MUST support the events listed in Table 1
with the exception of "flash". If it uses some other, out-of-
mechanism for signaling line conditions, it does not have
implement the other events

In some cases, an implementation may simply ignore certain events
such as fax tones, that do not make sense in a
environment. Section 3.9 specifies how an implementation can use
SDP "fmtp" parameter within an SDP description to indicate
inability to understand a particular event or range of events

Depending on the available user interfaces, an implementation
render all tones in Table 5 the same or, preferably, use the
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
the events described in Sections 3.10 and 3.12, while systems
receive trunk signaling need to implement those in Sections 3.10,
3.11, 3.12 and 3.14, since MF trunks also carry most of the "line
signals. Systems that do not support fax or modem functionality
not need to render fax-related events described in Section 3.11.

Schulzrinne & Petrack Standards Track [Page 5]

RFC 2833 Tones May 2000

The RTP payload format is designated as "telephone-event", the
type as "audio/telephone-event". The default timestamp rate is 8000
Hz, but other rates may be defined. In accordance with
practice, this payload format does not have a static payload
number, but uses a RTP payload type number established
and out-of-band

3.4 Use of RTP Header

Timestamp: The RTP timestamp reflects the measurement point
the current packet. The event duration described in
3.5 extends forwards from that time. The receiver
jitter for RTCP receiver reports based on all packets with
given timestamp. Note: The jitter value should primarily
used as a means for comparing the reception quality
two users or two time-periods, not as an absolute measure

Marker bit: The RTP marker bit indicates the beginning of a
event

3.5 Payload

The payload format is shown in Fig. 1.

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 |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Payload Format for Named

events: The events are encoded as shown in Sections 3.10
3.14.

volume: For DTMF digits and other events representable as tones
this field describes the power level of the tone,
in dBm0 after dropping the sign. Power levels range from 0
-63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (
accept); lower than -55 dBm0 must be rejected (TR-TSY-000181,
ITU-T Q.24A). Thus, larger values denote lower volume.
value is defined only for DTMF digits. For other events,
is set to zero by the sender and is ignored by the receiver

Schulzrinne & Petrack Standards Track [Page 6]

RFC 2833 Tones May 2000

duration: Duration of this digit, in timestamp units. Thus,
event began at the instant identified by the RTP
and has so far lasted as long as indicated by this parameter
The event may or may not have ended

For a sampling rate of 8000 Hz, this field is sufficient
express event durations of up to approximately 8 seconds

E: If set to a value of one, the "end" bit indicates that
packet contains the end of the event. Thus, the
parameter above measures the complete duration of the event

A sender MAY delay setting the end bit until
the last packet for a tone, rather than on its
transmission. This avoids having to wait to detect
the tone has indeed ended

Receiver implementations MAY use different algorithms
create tones, including the two described here. In the first
the receiver simply places a tone of the given duration
the audio playout buffer at the location indicated by
timestamp. As additional packets are received that extend
same tone, the waveform in the playout buffer is
accordingly. (Care has to be taken if audio is mixed, i.e.,
summed, in the playout buffer rather than simply copied.)
Thus, if a packet in a tone lasting longer than the
interarrival time gets lost and the playout delay is short,
gap in the tone may occur. Alternatively, the receiver
start a tone and play it until it receives a packet with
"E" bit set, the next tone, distinguished by a
timestamp value or a given time period elapses. This is
robust against packet loss, but may extend the tone if
retransmissions of the last packet in an event are lost
Limiting the time period of extending the tone is
to avoid that a tone "gets stuck". Regardless of
algorithm used, the tone SHOULD NOT be extended by more
three packet interarrival times. A slight extension of
durations and shortening of pauses is generally harmless

R: This field is reserved for future use. The sender MUST set
to zero, the receiver MUST ignore it

Schulzrinne & Petrack Standards Track [Page 7]

RFC 2833 Tones May 2000

3.6 Sending Event

An audio source SHOULD start transmitting event packets as soon as
recognizes an event and every 50 ms thereafter or the packet
for the audio codec used for this session, if known. (The sender
not need to maintain precise time intervals between event packets
order to maintain precise inter-event times, since the
information is contained in the timestamp.)

Q.24 [5], Table A-1, indicates that all administrations
use a minimum signal duration of 40 ms, with signaling
(tone and pause) of no less than 93 ms

If an event continues for more than one period, the source
the events should send a new event packet with the RTP
value corresponding to the beginning of the event and the duration
the event increased correspondingly. (The RTP sequence number
incremented by one for each packet.) If there has been no new
in the last interval, the event SHOULD be retransmitted three
or until the next event is recognized. This ensures that the
of the event can be recognized correctly even if the last packet
an event is lost

DTMF digits and events are sent incrementally to avoid having
receiver wait for the completion of the event. Since some
are two seconds long, this would incur a substantial delay.
transmitter does not know if event length is important and
needs to transmit immediately and incrementally. If the
application does not care about event length, the
transmission mechanism avoids delay. Some applications, such
gateways into the PSTN, care about both delays and event duration

3.7

During an event, the RTP event payload format provides
updates on the event. The error resiliency depends on the
delay at the receiver. For example, for a playout delay of 120 ms
a packet gap of 50 ms, two packets in a row can get lost
causing a gap in the tones generated at the receiver

The audio redundancy mechanism described in RFC 2198 [6] MAY be
to recover from packet loss across events. The effective data rate
r times 64 bits (32 bits for the redundancy header and 32 bits
the telephone-event payload) every 50 ms or r times 1280 bits/second
where r is the number of redundant events carried in each packet.
value of r is an implementation trade-off, with a value of 5
suggested

Schulzrinne & Petrack Standards Track [Page 8]

RFC 2833 Tones May 2000

The timestamp offset in this redundancy scheme has 14 bits,
that it allows a single packet to "cover" 2.048 seconds
telephone events at a sampling rate of 8000 Hz. Including
starting time of previous events allows precise reconstruction
the tone sequence at a gateway. The scheme is resilient
consecutive packet losses spanning this interval of 2.048
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
of the current audio frame. In that mode, each RTP packet during
event would contain the current audio codec rendition (say, G.723.1
or G.729) of this digit as well as the representation described
Section 3.5, plus any previous events seen earlier

This approach allows dumb gateways that do not understand
format to function. See also the discussion in Section 1.

3.8

A typical RTP packet, where the user is just dialing the last
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
units), the third digit was pressed at time 1.4 s (11,200
units) and the packet shown was sent at 1.45 s (11,600
units). The frame duration is 50 ms. To make the parts recognizable
the figure below ignores byte alignment. Timestamp and
number are assumed to have been zero at the beginning of the
digit. In this example, the dynamic payload types 96 and 97 have
assigned for the redundancy mechanism and the telephone
payload, respectively

Schulzrinne & Petrack Standards Track [Page 9]

RFC 2833 Tones May 2000

3.9 Indication of Receiver Capabilities using

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 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Example RTP packet after dialing "911"

Receivers MAY indicate which named events they can handle,
example, by using the Session Description Protocol (RFC 2327 [7]).
The payload formats use the following fmtp format to list the
values that they can receive

a=fmtp:
The list of values consists of comma-separated elements, which can
either a single decimal number or two decimal numbers separated by
hyphen (dash), where the second number is larger than the first.
whitespace is allowed between numbers or hyphens. The list does
have to be sorted

Schulzrinne & Petrack Standards Track [Page 10]

RFC 2833 Tones May 2000

For example, if the payload format uses the payload type number 100,
and the implementation can handle the DTMF tones (events 0
15) and the dial and ringing tones, it would include the
description in its SDP message

a=fmtp:100 0-15,66,70

Since all implementations MUST be able to receive events 0
15, listing these events in the a=fmtp line is OPTIONAL

The corresponding MIME parameter is "events", so that the
sample media type definition corresponds to the SDP example above

audio/telephone-event;events="0-11,66,67";rate="8000"

3.10 DTMF

Table 1 summarizes the DTMF-related named events within
telephone-event payload format

Event encoding (decimal
_________________________
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16

Table 1: DTMF named

3.11 Data Modem and Fax

Table 3.11 summarizes the events and tones that can appear on
subscriber line serving a fax machine or modem. The tones
described below, with additional detail in Table 7.

ANS: This 2100 +/- 15 Hz tone is used to disable
suppression for data transmission [8,9]. For fax machines
Recommendation T.30 [9] refers to this tone as
terminal identification (CED) answer tone

/ANS: This is the same signal as ANS, except that it
phase at an interval of 450 +/- 25 ms. It disables
echo cancellers and echo suppressors. (In the
Recommendation V.25 [8], this signal is rendered as
with a bar on top.)

Schulzrinne & Petrack Standards Track [Page 11]

RFC 2833 Tones May 2000

ANSam: The modified answer tone (ANSam) [3] is a sinewave
at 2100 +/- 1 Hz without phase reversals, amplitude-
by a sinewave at 15 +/- 0.1 Hz. This tone is sent by
if network echo canceller disabling is not required

/ANSam: The modified answer tone with phase reversals (ANSam) [3]
is a sinewave signal at 2100 +/- 1 Hz with phase reversals
intervals of 450 +/- 25 ms, amplitude-modulated by a
at 15 +/- 0.1 Hz. This tone [10,8] is sent by modems [11]
faxes to disable echo suppressors

CNG: After dialing the called fax machine's telephone number (
before it answers), the calling Group III fax
(optionally) begins sending a CalliNG tone (CNG)
of an interrupted tone of 1100 Hz. [9]

CRdi: Capabilities Request (CRd), initiating side, [12] is
dual-tone signal with tones at 1375 Hz and 2002 Hz for 400
ms, followed by a single tone at 1900 Hz for 100 ms. "
signal requests the remote station transition from
mode to an information transfer mode and requests
transmission of a capabilities list message by the
station. In particular, CRdi is sent by the
station during the course of a call, or by the
station at call establishment in response to a CRe or MRe."

CRdr: CRdr is the response tone to CRdi (see above). It
of a dual-tone signal with tones at 1529 Hz and 2225 Hz
400 ms, followed by a single tone at 1900 Hz for 100 ms

CRe: Capabilities Request (CRe) [12] is a dual-tone signal
tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed
a single tone at 400 Hz for 100 ms. "This signal requests
remote station transition from telephony mode to
information transfer mode and requests the transmission of
capabilities list message by the remote station.
particular, CRe is sent by an automatic answering station
call establishment."

CT: "The calling tone [8] consists of a series of
bursts of binary 1 signal or 1300 Hz, on for a duration
not less than 0.5 s and not more than 0.7 s and off for
duration of not less than 1.5 s and not more than 2.0 s."
Modems not starting with the V.8 call initiation tone
use this tone

Schulzrinne & Petrack Standards Track [Page 12]

RFC 2833 Tones May 2000

ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones
1375 Hz and 2002 Hz for 400 ms, followed by a single tone
980 Hz for 100 ms. "This signal requests the remote
transition from telephony mode to an information
mode. signal ESi is sent by the initiating station."

ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones
1529 Hz and 2225 Hz for 400 ms, followed by a single tone
1650 Hz for 100 ms. Same as ESi, but sent by the
station

MRdi: Mode Request (MRd), initiating side, [12] is a dual-
signal with tones at 1375 Hz and 2002 Hz for 400 ms
by a single tone at 1150 Hz for 100 ms. "This signal
the remote station transition from telephony mode to
information transfer mode and requests the transmission of
mode select message by the remote station. In particular
signal MRd is sent by the initiating station during
course of a call, or by the calling station at
establishment in response to an MRe." [12]

MRdr: MRdr is the response tone to MRdi (see above). It
of a dual-tone signal with tones at 1529 Hz and 2225 Hz
400 ms, followed by a single tone at 1150 Hz for 100 ms

MRe: Mode Request (MRe) [12] is a dual-tone signal with tones
1375 Hz and 2002 Hz for 400 ms, followed by a single tone
650 Hz for 100 ms. "This signal requests the remote
transition from telephony mode to an information
mode and requests the transmission of a mode select
by the remote station. In particular, signal MRe is sent
an automatic answering station at call establishment." [12]

V.21: V.21 describes a 300 b/s full-duplex modem that
frequency shift keying (FSK). It is used by Group 3
machines to exchange T.30 information. The calling
on channel 1 and receives on channel 2; the answering
transmits on channel 2 and receives on channel 1. Each
value has a distinct tone, so that V.21 signaling comprises
total of four distinct tones

Schulzrinne & Petrack Standards Track [Page 13]

RFC 2833 Tones May 2000

In summary, procedures in Table 2 are used

Procedure
___________________________________________________
V.25 and V.8
V.25, echo canceller disabled ANS, /ANS, ANS, /
V.8
V.8, echo canceller disabled /

Table 2: Use of ANS, ANSam and /ANSam in V.x

Event encoding (decimal
___________________________________________________
Answer tone (ANS) 32
/ANS 33
ANSam 34
/ANSam 35
Calling tone (CNG) 36
V.21 channel 1, "0" bit 37
V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40
CRdi 41
CRdr 42
CRe 43
ESi 44
ESr 45
MRdi 46
MRdr 47
MRe 48
CT 49

Table 3: Data and fax named

3.12 Line

Table 4 summarizes the events and tones that can appear on
subscriber line

ITU Recommendation E.182 [13] defines when certain tones should
used. It defines the following standard tones that are heard by
caller

Dial tone: The exchange is ready to receive address information

Schulzrinne & Petrack Standards Track [Page 14]

RFC 2833 Tones May 2000

PABX internal dial tone: The PABX is ready to receive
information

Special dial tone: Same as dial tone, but the caller's line
subject to a specific condition, such as call diversion or
voice mail is available (e.g., "stutter dial tone").

Second dial tone: The network has accepted the
information, but additional information is required

Ring: This named signal event causes the recipient to generate
alerting signal ("ring"). The actual tone or other
used to render this named event is left up to the receiver
(This differs from the ringing tone, below, heard by

Ringing tone: The call has been placed to the callee and a
signal (ringing) is being transmitted to the callee.
tone is also called "ringback".

Special ringing tone: A special service, such as call
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
unavailable

Calling card service tone: The calling card service tone
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
reason is neither "busy" nor "congestion". This tone
be used before all call failure announcements, for
benefit of automatic equipment

Comfort tone: The call is being processed. This tone may be
during long post-dial delays, e.g., in
connections

Hold tone: The caller has been placed on hold

Record tone: The caller has been connected to an
answering device and is requested to begin speaking

Schulzrinne & Petrack Standards Track [Page 15]

RFC 2833 Tones May 2000

Caller waiting tone: The called station is busy, but has
waiting service

Pay tone: The caller, at a payphone, is reminded to
additional coins

Positive indication tone: The supplementary service has
activated

Negative indication tone: The supplementary service could not
activated

Off-hook warning tone: The caller has left the instrument off-
for an extended period of time

The following tones can be heard by either calling or called
during a conversation

Call waiting tone: Another party wants to reach the subscriber

Warning tone: The call is being recorded. This tone is
required in all jurisdictions

Intrusion tone: The call is being monitored, e.g., by an operator

CPE alerting signal: A tone used to alert a device to an
in-band FSK data transmission. A CPE alerting signal is
combined 2130 and 2750 Hz tone, both with tolerances of 0.5%
and a duration of 80 to. 80 ms. The CPE alerting signal
used with ADSI services and Call Waiting ID services [14].

The following tones are heard by operators

Payphone recognition tone: The person making the call or
called is using a payphone (and thus it is ill-advised
allow collect calls to such a person).

Schulzrinne & Petrack Standards Track [Page 16]

RFC 2833 Tones May 2000

Event encoding (decimal
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89

Table 4: E.182 line

3.13 Extended Line

Table 5 summarizes country-specific events and tones that can
on a subscriber line

3.14 Trunk

Table 6 summarizes the events and tones that can appear on a trunk
Note that trunk can also carry line events (Section 3.12), as
signaling does not include backward signals [15].

ABCD transitional: 4-bit signaling used by digital trunks. For N
state signaling, the first N values are used

Schulzrinne & Petrack Standards Track [Page 17]

RFC 2833 Tones May 2000

Event encoding (decimal
___________________________________________________
Acceptance tone 96
Confirmation tone 97
Dial tone, recall 98
End of three party service tone 99
Facilities tone 100
Line lockout tone 101
Number unobtainable tone 102
Offering tone 103
Permanent signal tone 104
Preemption tone 105
Queue tone 106
Refusal tone 107
Route tone 108
Valid tone 109
Waiting tone 110
Warning tone (end of period) 111
Warning Tone (PIP tone) 112

Table 5: Country-specific Line

The T1 ESF (extended super frame format) allows 2, 4, and 16
state signaling bit options. These signaling bits are
A, B, C, and D. Signaling information is sent as robbed
in frames 6, 12, 18, and 24 when using ESF T1 framing. A D
superframe only transmits 4-state signaling with A and
bits. On the CEPT E1 frame, all signaling is carried
timeslot 16, and two channels of 16-state (ABCD)
are sent per frame

Since this information is a state rather than a
signal, implementations SHOULD use the following triple
redundancy mechanism, similar to the one specified in ITU-
Rec. I.366.2 [16], Annex L. At the time of a transition,
same ABCD information is sent 3 times at an interval of 5 ms
If another transition occurs during this time, then
continues. After a period of no change, the ABCD
is sent every 5 seconds

Wink: A brief transition, typically 120-290 ms, from on-
(unseized) to off-hook (seized) and back to onhook, used
the incoming exchange to signal that the call
signaling can proceed

Incoming seizure: Incoming indication of call attempt (off-hook).

Schulzrinne & Petrack Standards Track [Page 18]

RFC 2833 Tones May 2000

Event encoding (decimal
__________________________________________________
MF 0... 9 128...137
MF K0 or KP (start-of-pulsing) 138
MF K1 139
MF K2 140
MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142...143
ABCD signaling (see below) 144...159
Wink 160
Wink off 161
Incoming seizure 162
Seizure 163
Unseize circuit 164
Continuity test 165
Default continuity tone 166
Continuity tone (single tone) 167
Continuity test send 168
Continuity verified 170
Loopback 171
Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173

Table 6: Trunk

Seizure: Seizure by answering exchange, in response to
seizure

Unseize circuit: Transition of circuit from off-hook to on-hook
the end of a call

Wink off: A brief transition, typically 100-350 ms, from off-
(seized) to on-hook (unseized) and back to off-hook (seized).
Used in operator services trunks

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
exchange. If received by the called exchange, it returns
"continuity verified" tone

Continuity verified: A tone of 2010 Hz. This is a response tone
used in dual-tone procedures

Schulzrinne & Petrack Standards Track [Page 19]

RFC 2833 Tones May 2000

4 RTP Payload Format for Telephony

4.1

As an alternative to describing tones and events by name,
described in Section 3, it is sometimes preferable to describe
by their waveform properties. In particular, recognition is
than for naming signals since it does not depend on
durations or pauses

There is no single international standard for telephone tones such
dial tone, ringing (ringback), busy, congestion ("fast-busy"),
special announcement tones or some of the other special tones,
as payphone recognition, call waiting or record tone. However,
all countries, these tones share a number of characteristics [17]:

o Telephony tones consist of either a single tone, the
of two or three tones or the modulation of two tones. (
all tones use two frequencies; only the Hungarian "special
tone" has three.) Tones that are mixed have the same
and do not decay

o Tones for telephony events are in the range of 25 (ringing
in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz
The telephone frequency range is limited to 3,400 Hz. (
piano has a range from 27.5 to 4186 Hz.)

o Modulation frequencies range between 15 (ANSam tone) to 480
(Jamaica). Non-integer frequencies are used only
frequencies of 16 2/3 and 33 1/3 Hz. (These
frequencies appear to be derived from older AC power
frequencies.)

o Tones that are not continuous have durations of less than
seconds

o ITU Recommendation E.180 [18] notes that different
companies require a tone accuracy of between 0.5 and 1.5%.
Recommendation suggests a frequency tolerance of 1%.

4.2 Examples of Common Telephone Tone

As an aid to the implementor, Table 7 summarizes some common tones
The rows labeled "ITU ..." refer to the general recommendation
Recommendation E.180 [18]. Note that there are no specific
for these tones. In the table, the symbol "+" indicates addition

Schulzrinne & Petrack Standards Track [Page 20]

RFC 2833 Tones May 2000

the tones, without modulation, while "*" indicates
modulation. The meaning of some of the tones is described in
3.12 or Section 3.11 (for V.21).

Tone name frequency on period off
______________________________________________________
CNG 1100 0.5 3.0
V.25 CT 1300 0.5 2.0
CED 2100 3.3 --
ANS 2100 3.3 --
ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.00333
V.21 "1" bit, ch. 1 980 0.00333
V.21 "0" bit, ch. 2 1850 0.00333
V.21 "1" bit, ch. 2 1650 0.00333
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

4.3 Use of RTP Header

Timestamp: The RTP timestamp reflects the measurement point
the current packet. The event duration described in
3.5 extends forwards from that time

4.4 Payload

Based on the characteristics described above, this document
an RTP payload format called "tone" that can represent
consisting of one or more frequencies. (The corresponding MIME
is "audio/tone".) The default timestamp rate is 8,000 Hz, but
rates may be defined. Note that the timestamp rate does not
the interpretation of the frequency, just the durations

In accordance with current practice, this payload format does
have a static payload type number, but uses a RTP payload type
established dynamically and out-of-band

It is shown in Fig. 3.

Schulzrinne & Petrack Standards Track [Page 21]

RFC 2833 Tones May 2000

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Payload format for

The payload contains the following fields

modulation: The modulation frequency, in Hz. The field is a 9-
unsigned integer, allowing modulation frequencies up to 511
Hz. If there is no modulation, this field has a value
zero

T: If the "T" bit is set (one), the modulation frequency is to
divided by three. Otherwise, the modulation frequency
taken as is

This bit allows frequencies accurate to 1/3 Hz,
modulation frequencies such as 16 2/3 Hz are in
use

volume: The power level of the tone, expressed in dBm0
dropping the sign, with range from 0 to -63 dBm0. (Note:
preferred level range for digital tone generators is -8 dBm
to -3 dBm0.)

duration: The duration of the tone, measured in timestamp units
The tone begins at the instant identified by the
timestamp and lasts for the duration value

The definition of duration corresponds to that for sample
based codecs, where the timestamp represents the
point for the first sample

frequency: The frequencies of the tones to be added, measured
Hz and represented as a 12-bit unsigned integer. The
size is sufficient to represent frequencies up to 4095 Hz

Schulzrinne & Petrack Standards Track [Page 22]

RFC 2833 Tones May 2000

which exceeds the range of telephone systems. A value of
indicates silence. A single tone can contain any number
frequencies

R: This field is reserved for future use. The sender MUST set
to zero, the receiver MUST ignore it

4.5

This payload format uses the reliability mechanism described
Section 3.7.

5 Combining Tones and Named

The payload formats in Sections 3 and 4 can be combined into a
payload using the method specified in RFC 2198. Fig. 4 shows
example. In that example, the RTP packet combines two "tone" and
"telephone-event" payloads. The payload types are chosen
as 97 and 98, respectively, with a sample rate of 8000 Hz. Here,
redundancy format has the dynamic payload type 96.

The packet represents a snapshot of U.S. ringing tone, 1.5
(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
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
(16383 timestamp units) can be represented. Even though the
sequence is not complete, the sender was able to determine that
is indeed ringback, and thus includes the corresponding named event

6 MIME

6.1 audio/telephone-

MIME media type name:

MIME subtype name: telephone-

Required parameters: none

Schulzrinne & Petrack Standards Track [Page 23]

RFC 2833 Tones May 2000

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 |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 4: Combining tones and events in a single RTP

Optional parameters: The "events" parameter lists the
supported by the implementation. Events are listed as one
more comma-separated elements. Each element can either be
single integer or two integers separated by a hyphen.
white space is allowed in the argument. The
designate the event numbers supported by the implementation
All implementations MUST support events 0 through 15, so
the parameter can be omitted if the implementation
supports these events

Schulzrinne & Petrack Standards Track [Page 24]

RFC 2833 Tones May 2000

The "rate" parameter describes the sampling rate, in Hertz
The number is written as a floating point number or as
integer. If omitted, the default value is 8000 Hz

Encoding considerations: This type is only defined for
via RTP [1].

Security considerations: See the "Security Considerations
(Section 7) section in this document

Interoperability considerations:

Published specification: This document

Applications which use this media: The telephone-event
subtype supports the transport of events occurring
telephone systems over the Internet

Additional information

1. Magic number(s): N/

2. File extension(s): N/

3. Macintosh file type code: N/

6.2 audio/

MIME media type name:

MIME subtype name:

Required parameters:

Optional parameters: The "rate" parameter describes the
rate, in Hertz. The number is written as a floating
number or as an integer. If omitted, the default value
8000 Hz

Encoding considerations: This type is only defined for
via RTP [1].

Security considerations: See the "Security Considerations
(Section 7) section in this document

Interoperability considerations:

Published specification: This document

Schulzrinne & Petrack Standards Track [Page 25]

RFC 2833 Tones May 2000

Applications which use this media: The tone audio subtype
the transport of pure composite tones, for example
commonly used in the current telephone system to signal
progress

Additional information

1. Magic number(s): N/

2. File extension(s): N/

3. Macintosh file type code: N/

7 Security

RTP packets using the payload format defined in this
are subject to the security considerations discussed in the
specification (RFC 1889 [1]), and any appropriate RTP profile (
example RFC 1890 [19]).This implies that confidentiality of the
streams is achieved by encryption. Because the data compression
with this payload format is applied end-to-end, encryption may
performed after compression so there is no conflict between the
operations

This payload type does not exhibit any significant non-uniformity
the receiver side computational complexity for packet processing
cause a potential denial-of-service threat

In older networks employing in-band signaling and lacking
tone filters, the tones in Section 3.14 may be used to commit
fraud

Additional security considerations are described in RFC 2198 [6].

8 IANA

This document defines two new RTP payload formats, named telephone
event and tone, and associated Internet media (MIME) types
audio/telephone-event and audio/tone

Within the audio/telephone-event type, additional events MUST
registered with IANA. Registrations are subject to approval by
current chair of the IETF audio/video transport working group, or
an expert designated by the transport area director if the AVT
has closed

Schulzrinne & Petrack Standards Track [Page 26]

RFC 2833 Tones May 2000

The meaning of new events MUST be documented either as an RFC or
equivalent standards document produced by another
body, such as ITU-T

9

The suggestions of the Megaco working group are
acknowledged. Detailed advice and comments were provided by
Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox,
Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins

10 Authors'

Henning
Dept. of Computer
Columbia
1214 Amsterdam
New York, NY 10027

EMail: schulzrinne@cs.columbia.

Scott

45 Rumford
Waltham, MA 02453

EMail: scott.petrack@metatel.

11

[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson
"RTP: A Transport Protocol for Real-Time Applications",
1889, January 1996.

[2] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.

[3] International Telecommunication Union, "Procedures for
sessions of data transmission over the public switched
network," Recommendation V.8, Telecommunication
Sector of ITU, Geneva, Switzerland, Feb. 1998.

[4] R. Kocen and T. Hatala, "Voice over frame relay
agreement", Implementation Agreement FRF.11, Frame Relay Forum
Foster City, California, Jan. 1997.

Schulzrinne & Petrack Standards Track [Page 27]

RFC 2833 Tones May 2000

[5] International Telecommunication Union, "Multifrequency push
button signal reception," Recommendation Q.24,
Standardization Sector of ITU, Geneva, Switzerland, 1988.

[6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
for Redundant Audio Data", RFC 2198, September 1997.

[7] Handley M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.

[8] International Telecommunication Union, "Automatic
equipment and general procedures for automatic calling
on the general switched telephone network including
for disabling of echo control devices for both manually
automatically established calls," Recommendation V.25,
Telecommunication Standardization Sector of ITU, Geneva
Switzerland, Oct. 1996.

[9] International Telecommunication Union, "Procedures for
facsimile transmission in the general switched
network," Recommendation T.30, Telecommunication
Sector of ITU, Geneva, Switzerland, July 1996.

[10] International Telecommunication Union, "Echo cancellers,"
Recommendation G.165, Telecommunication Standardization
of ITU, Geneva, Switzerland, Mar. 1993.

[11] International Telecommunication Union, "A modem operating
data signaling rates of up to 33 600 bit/s for use on
general switched telephone network and on leased point-to-
2-wire telephone-type circuits," Recommendation V.34,
Telecommunication Standardization Sector of ITU, Geneva
Switzerland, Feb. 1998.

[12] International Telecommunication Union, "Procedures for
identification and selection of common modes of
between data circuit-terminating equipments (DCEs) and
data terminal equipments (DTEs) over the public
telephone network and on leased point-to-point telephone-
circuits," Recommendation V.8bis,
Standardization Sector of ITU, Geneva, Switzerland, Sept. 1998.

[13] International Telecommunication Union, "Application of tones
recorded announcements in telephone services,"
E.182, Telecommunication Standardization Sector of ITU, Geneva
Switzerland, Mar. 1998.

Schulzrinne & Petrack Standards Track [Page 28]

RFC 2833 Tones May 2000

[14] Bellcore, "Functional criteria for digital loop
systems," Technical Requirement TR-NWT-000057,
(formerly Bellcore), Morristown, New Jersey, Jan. 1993.

[15] J. G. van Bosse, Signaling in Telecommunications
Telecommunications and Signal Processing, New York, New York
Wiley, 1998.

[16] International Telecommunication Union, "AAL type 2
specific convergence sublayer for trunking,"
I.366.2, Telecommunication Standardization Sector of ITU
Geneva, Switzerland, Feb. 1999.

[17] International Telecommunication Union, "Various tones used
national networks," Recommendation Supplement 2
Recommendation E.180, Telecommunication Standardization
of ITU, Geneva, Switzerland, Jan. 1994.

[18] International Telecommunication Union, "
characteristics of tones for telephone service,"
Supplement 2 to Recommendation E.180,
Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.

[19] Schulzrinne, H., "RTP Profile for Audio and Video
with Minimal Control", RFC 1890, January 1996.

Schulzrinne & Petrack Standards Track [Page 29]

RFC 2833 Tones May 2000

12 Full Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Schulzrinne & Petrack Standards Track [Page 30]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX