It is expected that the CI event will be most useful when the
modem content is being transmitted primarily using another payload
type. The event acts as a commentary on that content, allowing
the receiver to recognize that V.8 signalling is in progress.

2.3.1. Handling of Congestion

The tolerances built into V.8 suggest that it may be mostly robust in
the face of packet losses or delays. Playout of ANSam and /ANSam can
be extended for multiple packetization periods without harm, provided
that phase reversals occur on schedule at 450-ms intervals during
playout of the latter.

To increase robustness of transmission of the V.21-based signals,
sending applications using the V.21 events SHOULD include an integral
number of octets, including start and stop bits, in each packet. L'
presence of start and stop bits provides some hope that receiving
implementations can withstand unavoidable gaps in playout between
octets. When a message is being repeated (as is possible for CI, CM,
and JM), an even stronger robustness measure would be for the
receiver to retain a copy of the message when it is first received,
and when a packet is delayed or lost to continue playing out the
current message instance and commence a new repetition as if packets
had continued to arrive on schedule.

2.4. V.25 Events

V.25 [13] is a start-up protocol predating V.8 [9] and V.8 bis [10].
It specifies the exchange of two tone signals: CT and ANS.

CT (calling tone) consists of a series of interrupted bursts of
1300-Hz tone, on for a duration of not less than 0.5 s and not more
than 0.7 s and off for a duration of not less than 1.5 s and not more
than 2.0 s. [13]. Modems not starting with the V.8 CI signal often
use this tone.

ANS (Answer tone) is a 2100-Hz tone used to disable echo suppression
for data transmission [13], [8]. For fax machines, Recommendation
T.30 [8] refers to this tone as called terminal identification (CED)
answer tone. ANS differs from V.8 ANSam in that, unlike the latter,
it has constant amplitude.

V.25 specifically includes procedures for disabling echo suppressors
as defined by ITU-T Rec. G.164 [6]. However, G.164 echo suppressors
have now for the most part been replaced by G.165 [7] echo

Schulzrinne & Taylor Standards Track [Page 15]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
cancellers, which require phase reversals in the disabling tone (see
ANSam above). As a result, Recommendation V.25 was modified in July
2001 to say that phase reversal in the ANS tone is required if echo
cancellers are to be disabled.

One possible V.25 sequence is as follows:

1. The calling terminal starts generating CT as soon as the call is
connected.

2. The called terminal waits in silence for 1.8 to 2.5 s after
answer, then begins to transmit ANS continuously. If echo
cancellers are on the line, the phase of the ANS signal is
reversed every 450 ms. ANS will not reach the calling terminal
until the echo control equipment has been disabled. Since this
takes about a second, it can only happen in the gap between one
burst of CT and the next.

3. Following detection of ANS, the calling terminal may stop
generating CT immediately or wait until the end of the current
burst to stop. In any event, it must wait at least 400 ms (at
least 1 s if phase reversal of ANS is being used to disable echo
cancellers) after stopping CT before it can generate the calling
station response tone. This tone is modem-specific, not
specified in V.25.

4. The called terminal plays out ANS for 2.6 to 4.0 seconds or until
it has detected calling station response for 100 ms. It waits
55-95 ms (nominal 75 ms) in silence. (Note that the upper limit
of 95 ms is rather close to the point at which echo control may
reestablish itself.) If the reason for ANS termination was
timeout rather than detection of calling station response, the
called terminal begins to play out ANS again to maintain
disabling of echo control until the calling station responds.

The beginning of the event is at the beginning of the 2100-Hz
tone. The end of the event is at the sooner of the ending of the
tone or the occurrence of a phase reversal (marking the beginning
of a /ANS event).

An initial ANS event packet SHOULD NOT be sent until it is
possible to discriminate between an ANS event and an ANSam event
(see V.8 events, above).

/ANS:

/ANS reports the same physical signal as ANS, but is reported
following the first phase reversal in that signal. It begins with
the phase reversal and ends at the end of the tone. The receiver
of /ANS MUST reverse the phase of the tone at the beginning of
playout of /ANS and every 450 ms thereafter until the end of the
tone is reached.

CT:

The beginning of the CT event is at the beginning of an individual
burst of the 1300-Hz tone. The end of the event is at the end of
that tone burst. The gateway at the calling end SHOULD use a
packetization interval smaller than the nominal duration of a CT
burst, to ensure that CT playout at the called end precedes the
sending of ANS from that end.

2.4.1. Handling of Congestion

The V.25 sequence appears to be robust in the face of lost or delayed
packets, provided that the receiver continues to play out any tone it
is in the process of playing until more packets are received. L'
receiver must play out the phase transitions for /ANS on schedule, at
450-ms intervals, even if updates of the /ANS event have been
delayed. It also appears to be possible for the sender to
temporarily increase the packetization interval to reduce packet
volumes when congestion is encountered. The one risk is that
extended playout proceeds past the actual end of the tone (as
determined retroactively), and the receiver is forced to continue
imposing an additional playout buffering lag in order to meet the
constraint on maximum duration of the nominal 75-ms silent period
following tone playout.

ITU-T Recommendation V.32 [14] is a modem using phase-shift keying
with quadrature amplitude modification. It operates on a carrier at
1800 Hz, modulated at 2400 symbols/s. The basic data rates for V.32
are 4800 and 9600 bits/s. V.32bis [15] extends the data rates up to
14400 bits/s. Most or all existing deployments are V.32bis,
typically in support of point-of-sale terminals and the like.

One reason V.32bis is still used is because of its relatively rapid
start-up sequence, particularly on leased lines. Operating over the
public telephone network, the start-up begins as follows:

a. the answering end begins with the V.25 answering procedure (1.8
to 2.5 s of silence followed by continuous ANS tone to a maximum
of 3.3 s, with possible phase reversals to disable echo
cancelling equipment);

b. the calling end waits in silence until it has detected ANS for
1 s;

c. the calling end begins to transmit a V.32/V.32bis pattern
designated AA, ie, a series of '0000' bit sequences transmitted
at 4800 bits/s;

d. upon detecting the AA pattern for at least 100 ms, the called
modem is silent for 75 +/- 20 ms, then responds with an AC
pattern, which is a series of '0011' bit sequences transmitted at
4800 bits/s.

The difference in leased line operation is that the calling modem
starts the session by sending AA. After that, the called modem
responds with AC, and the rest of the sequence is unchanged.

In support of V.32/V.32bis operation, Table 5 defines two events,
V32AA and V32AC.

Indicates that the AA calling pattern of a V.32/V.32bis terminal
has been detected.

V32AC:

Indicates that the AC answering pattern of a V.32/V.32bis terminal
has been detected.

Each of these two events begins at the beginning of its pattern, and
ends nominally when the pattern stops being received. Following the
sending of either of these events the session may continue using
V.150.1 modem relay [32] or Clearmode [17] as negotiated or
configured in advance. To help make the transition as quickly as
possible, the V32AA or V32AC event SHOULD be reported as soon as the
corresponding pattern is detected. It seems likely that the
implementation will be transmitting the event reports simultaneously
with the same data in an alternate form, typically using RFC 2198 [2]
redundancy.

2.5.1. Handling of Congestion

The primary issue raised by congestion is the loss or undue delay of
the initial report. Once the receiver is aware that an AA or AC
pattern has been detected, further reports are of no interest. L'
actual duration of the AC pattern may be as short as 27 ms. On this
basis, the appropriate sender behavior may be to send at least three
packets reporting the event using normal event updates and end of
event retransmission behavior and a fairly short packetization
interval (20-30 ms).

2.6. T.30 Events

ITU-T Recommendation T.30 [8] defines the procedures used by Group
III fax terminals. The pre-message procedures for which the events
of this section are defined are used to identify terminal
capabilities at each end and negotiate operating mode. Post-message
procedures are also included, to handle cases such as multiple
document transmission. Fax terminals support a wide variety of
protocol stacks, so T.30 has a number of options for control
protocols and sequences.

T.30 defines two tone signals used at the beginning of a call. L'
CNG signal is sent by the calling terminal. It is a pure 1100-Hz
tone played in bursts: 0.5 s on, 3 s off. It continues until timeout

Schulzrinne & Taylor Standards Track [Page 19]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
or until the calling terminal detects a response. Its primary
purpose is to let human operators at the called end know that a fax
terminal has been activated at the calling end.

The called terminal waits in silence for at least 200 ms. It then
may return CED tone (which is physically identical to V.25 ANS), or
else V.8 ANSam if it has V.8 capability. If called and calling
terminals both support V.8, the called terminal will detect CI or
more likely CM in response to its ANSam and will continue with V.8
negotiation. Otherwise, the called terminal stops transmitting CED
after 2.6 to 4 seconds, waits 75 +/- 20 ms in silence, then enters
the T.30 negotiation phase.

In the T.30 negotiation phase the terminals exchange binary messages
using V.21 signals, high channel frequencies only, at 300 bits/s.
Each message is preceded by a one-second (nominal) preamble
consisting entirely of HDLC flag octets (0x7E). This flag has the
function of preparing echo control equipment for the message that
follows.

The pre-transfer messages exchanged using the V.21 coding are:

Digital Identification Signal (DIS):

Characterizes the standard ITU-T capabilities of the called
terminal. This is always the first message sent.

Digital Transmit Command (DTC):

A possible response to the DIS signal by the calling terminal. It
requests the called terminal to be the transmitter of the fax
content.

Digital Command Signal (DCS):

A command message sent by the transmitting terminal to indicate
the options to be used in the transmission and request that the
other end prepare to receive fax content. This is sent by the
calling end if it will transmit, or by the called end in response
to a DTC from the calling end. It is followed by a training
signal, also sent by the transmitting terminal.

Confirmation To Receive (CFR):

A digital response confirming that the entire pre-message
procedure including training has been completed and the message
transmissions may commence.
Schulzrinne & Taylor Standards Track [Page 20]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Each message may consist of multiple frames bounded by HDLC flags.
The messages are organized as a series of octets, but like V.8 bis,
T.30 calls for the insertion of extra '0' bits to prevent spurious
recognition of HDLC flags.

T.30 also provides for the transmission of control messages after
document transmission has completed (eg, to support transmission of
multiple documents). The transition to and from the modem used for
document transmission (V.17 [24], V.27ter [26], V.29 [27], V.34 [28])
is preceded by 75 ms (nominal) of silence).

Applications supporting T.30 signalling using the telephone-event
payload MAY report the preamble preceding each message both as a
series of V.21 bit events and, when it has been recognized, as a
single V.21 preamble event. The T.30 control message following the
preamble MAY be reported in the form of a sequence of V.21 bit events
or using some other payload type. If transmitted as bit events, the
transmitted information MUST include the complete contents of the
message: the initial HDLC flags, the information field, the checksum,
the terminating HDLC flags, and the extra '0' bits added to prevent
false recognition of HDLC flags at the receiver. Implementers should
note that these extra '0' bits mean that in general T.30 messages as
transmitted on the wire will not come out to an even multiple of
octets.

The training signal sent by the transmitting terminal after DCS
consists of a steady string of V.21 high channel zeros (1850-Hz tone)
for 1.5 s. Since the bit rate (nominally 300 bits/s) should have
been clearly established when processing the preceding signalling, it
is natural that if the telephony-event payload type is being used,
this training signal will also be sent as a series of V.21 bit events
at that bit rate. However, if the sending gateway is capable of
recognizing the transition from the end of the DCS to the start of
training, it MAY report the training signal as a single extended V.21
(high channel) '0' event.

The events defined for T.30 signalling are shown in Table 6. The CED
and /CED events represent exactly the same tone signals as V.25 ANS
and /ANS, and are given the same codepoints; they are reproduced here
only for convenience.

The beginning of the event is at the beginning of the 2100-Hz
tone. The end of the event is at the sooner of the ending of the
tone or the occurrence of a phase reversal (marking the beginning
of a /CED event).

An initial CED event packet SHOULD NOT be sent until it is
possible to discriminate between a CED event and an ANSam event
(see V.8 events, above).

/CED:

/CED reports the same physical signal as CED, but is reported
following the first phase reversal in that signal. It begins with
the phase reversal and ends at the end of the tone. The receiver
of /CED MUST reverse the phase of the tone at the beginning of
playout of /CED and every 450 ms thereafter until the end of the
tone is reached.

CNG:

The beginning of the CNG event is at the beginning of an
individual burst of the 1100-Hz tone. The end of the event is at
the end of that tone burst.

V.21 preamble flag:

This event begins with the first V.21 bits transmitted after a
period of silence. It ends when a pattern of V.21 bits other than
an HDLC flag is observed. This means that the V.21 preamble event
absorbs the initial HDLC flags of the following message.

Schulzrinne & Taylor Standards Track [Page 22]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
It is expected that the V.21 preamble flag event will be most
useful when the modem content is being transmitted primarily using
another payload type. The event acts as a commentary on that
content, allowing the receiver to prepare itself to transition to
fax mode.

2.6.1. Handling of Congestion

T.30 appears to be an intermediate case in terms of its vulnerability
to congestion. Tone playout in the face of packet delay or loss is
subject to the same considerations as for V.25 (see Section 2.4.1).
Similarly, the receiver may extend playout of the preamble event
while waiting for further reports. However, gaps or extended playout
of the V.21 sequences are not feasible. This means, as with V.8 bis,
that the receiver must manage its playout buffer appropriately to
increase robustness in the face of congestion.

2.7. Events for Text Telephony

2.7.1. Signal Format Indicators for Text Telephony

Legacy text telephony uses a wide variety of terminals, with
different standards favored in different parts of the world. Going
forward, the vision is that new terminals will work directly into the
packet network and be based on RFC 4103 [18] packetization of
character data. In anticipation of this migration, it is RECOMMENDED
that text carried in the PSTN by legacy modem protocols be converted
to RFC 4103 packets at the sending gateway.

During a transitional period, however, gateways of a lesser
capability may be able to recognize the nature of incoming content,
but may only be able to encode it as voice-band data on the packet
side. In such circumstances, it will help to optimize processing of
the signal at the receiving end if that end receives an indication of
the nature of the voice-encoded data signals. The events defined in
this section provide such indications, and MAY be used in conjunction
with ITU-T Recommendation V.152 [33], as one example, to carry the
content as voice-band data.

Implementers should take note of an additional class of text
terminals not considered in the events below. These terminals use
dual tone multi-frequency (DTMF) tones to encode and exchange
signals. This application is described in RFC 4733 [5], Section 3.1,
in conjunction with the registration of DTMF events.

Schulzrinne & Taylor Standards Track [Page 23]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
The events shown in Table 7 correspond to signals coming from the
following modem types:

indicates that a 2225-Hz answer tone has been detected. This is a
pure tone with no amplitude modulation and no semantics attached
to phase reversals, if there are any. The sender SHOULD report
the beginning of the event when the tone is detected. The sender
MAY send updates as the tone continues, and MUST report the end of
the event when the tone ceases. The tone concerned is generated
by a Bell 103-type modem in answer mode. This event MUST NOT be
reported outside of the startup context (ie, on the answering
side at the beginning of a call).

V21L110:

indicates that the sender has detected V.21 modulation operating
in the lower channel at 110 bits/s. Note that it may take some
time to distinguish between 300 bits/s and 110 bits/s operation.
It is expected that implementations will not transmit both this
event and individual V.21 bit events for the same content.

Schulzrinne & Taylor Standards Track [Page 25]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
V21L300:

indicates that the sender has detected V.21 modulation operating
in the lower channel at 300 bits/s. Note that it may take some
time to distinguish between 300 bits/s and 110 bits/s operation.
It is expected that implementations will not transmit both this
event and individual V.21 bit events for the same content.

V21H300:

indicates that the sender has detected V.21 modulation operating
in the upper channel at 300 bits/s. It is expected that
implementations will not transmit both this event and individual
V.21 bit events for the same content.

B103L300:

indicates that the sending device has detected Bell 103 class
modulation operating in the low channel at 300 bits/s.

V23Main:

indicates that the sending device has detected V.23 modulation
operating in the high-speed channel. As described below, this
indicator may alternate with the XCIMark indication.

V23Back:

indicates that the sending device has detected V.23 modulation
operating in the 75 bit/s back-channel.

Baud4545:

indicates that the sending device has detected Baudot modulation
operating at 45.45 bits/s.

Baud50:

indicates that the sending device has detected Baudot modulation
operating at 50 bits/s.

XCIMark:

Indicates that the sending device has detected the specific bit
pattern (0) 1111 1111(1)(0)1111 1111(1) sent at 1200 bits/s using
V.23 upper-channel modulation, following a period of V.23 main
channel "mark" (1300 Hz).
Schulzrinne & Taylor Standards Track [Page 26]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
It is assumed in all cases that the event reports described here are
being transmitted in addition to another media encoding, typically
G.711 [19] voice-band data, reporting the same information. A
natural method to do this is to combine the voice-band data with
event reports in an RFC 2198 [2] redundancy payload.

The handling of ANS2225 has been indicated above. Since it is a
specific tone, it can be handled like any other tone event.

For all of the other indicators, the sender SHOULD generate an
initial event report as soon as the nature of the audio content has
been recognized. For reliability, the initial event report SHOULD be
retransmitted twice at short intervals. (20 ms is a suggested value,
although the packetization period of the associated media may be
sufficient.) The sender MAY continue to send additional reports of
the same indicator event, although these have little value once the
receiver has adjusted itself to the type of content it is receiving.

If the nature of the content changes (eg, because it is coming from
a V.18 terminal in the probing stage), the sender MUST send an event
report for the new content type as soon as it is recognized. Si le
sender has been sending updates for the previous indicator, it SHOULD
report the end of that previous indicator event along with the
beginning of the new one.

2.7.1.1. Handling of Congestion

In the face of packet loss or delay, it is appropriate for the
receiver to continue to play out the ANS2225 event until further
packets are received. For the other events, the issue is loss of the
initial event report rather than maintenance of playout continuity.
The advice on retransmission of these other events already given
above is sufficient to deal with packet loss or delay due to
congestion.

2.7.2. Use of Events with V.18 Modems

ITU-T Recommendation V.18 [11] defines a terminal for text
conversation, possibly in combination with voice. V.18 is intended
to interoperate with a variety of legacy text terminals, so its
start-up sequence can consist of a series of stimuli designed to
determine what is at the other end. Two V.18 terminals talking to
each other will use V.8 to negotiate startup and continue at the
physical level with V.21 at 300 bits/s carrying 7-bit characters
bounded by start and stop bits.
Schulzrinne & Taylor Standards Track [Page 27]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
The V.18 terminal is also designed to interoperate with the text
modems listed in the previous sub-section. The startup sequences for
all these different terminal types are naturally quite different.
The V.18 initial startup sequence specifically addresses itself to
V.8-capable terminals and V.21 terminals and, by the combination of
signals, to V.23 videotex terminals. During the initial startup
sequence, the V.18 terminal listens for frequency responses
characterizing the other terminal types. If it does not make contact
in the preliminary step, it probes for each type specifically. By
the nature of the application, V.18 has been designed to provide an
extremely robust startup capability.

The handling of the V.18 XCI signal is a specific case of the
procedures described in the previous section. XCI is a signal
transmitted in high-band V.23 modulation to stimulate V.23 terminals
to respond and to allow detection of V.18 capabilities in a DCE. L'
3-second XCI signal uses the V.23 upper channel having periods of
"mark" (ie, 1300 Hz) alternating with the XCIMark pattern. L'
full definition is found in V.18, Section 3.13. The sender SHOULD
indicate V23Main during the transmission of the "mark" portion of
XCI, and change the indication to XCIMark when that pattern is
detected.

2.8. A Generic Indicator

Numerous proprietary modem protocols exist, as well as standardized
protocols not identified above. Table 8 defines a single indicator
event that may be used to identify modem content when a more specific
event is unavailable. Typically, this would be sent in combination
with another payload type, for example, voice-band data as specified
by ITU-T Recommendation V.152 [33].

As with the indicators in the previous section, the sender SHOULD
generate an initial event report as soon as the nature of the audio
content has been recognized. For reliability, the initial event
report SHOULD be retransmitted twice at short intervals. (20 ms is a
suggested value, although the packetization period of the associated
media may be sufficient.) The sender MAY continue to send additional
reports of the VBDGen event, although these have little value once
the receiver has adjusted itself to the type of content it is
receiving.

indicates that the sender has detected tone patterns indicating
the operation of some form of modem. This indicator SHOULD NOT be
sent if a more specific event is available.

3. Strategies for Handling Fax and Modem Signals

As described in Section 1.2, the typical data application involves a
pair of gateways interposed between two terminals, where the
terminals are in the PSTN. The gateways are likely to be serving a
mixture of voice and data traffic, and need to adopt payload types
appropriate to the media flows as they occur. If voice compression
is in use for voice calls, this means that the gateways need the
flexibility to switch to other payload types when data streams are
recognized.

Within the established IETF framework, this implies that the gateways
must negotiate the potential payloads (voice, telephone-event, tones,
voice-band data, T.38 fax [21], and possibly RFC 4103 [18] text and
Clearmode [17] octet streams) as separate payload types. From a
timing point of view, this is most easily done at the beginning of a
call, but results in an over-allocation of resources at the gateways
and in the intervening network.

One alternative is to use named events to buy time while out-of-band
signals are exchanged to update to the new payload type applicable to
the session. Thanks to the events defined in this document, this is
a viable approach for sessions beginning with V.8, V.8 bis, T.30, or
V.25 control sequences.

Named data-related events also allow gateways to optimize their
operation when data signals are received in a relatively general
form. One example is the use of V.8-related events to deduce that
the voice-band data being sent in a G.711 payload comes from a
higher-speed modem and therefore requires disabling of echo
cancellers.

Schulzrinne & Taylor Standards Track [Page 29]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
All of the control procedures described in the sub-sections of
Section 2 eventually give way to data content. As mentioned above,
this content will be carried by other payload types. Receiving
gateways MUST be prepared to switch to the other payload type within
the time constraints associated with the respective applications.
(For several of the procedures documented above, the sender provides
75 ms of silence between the initial control signalling and the
sending of data content.) In some cases (V.8 bis [10], T.30 [8]),
further control signalling may happen after the call has been
established.

A possible strategy is to send both the telephone-event and the data
payload in an RFC 2198 [2] redundancy arrangement. The receiving
gateway then propagates the data payload whenever no event is in
progress. For this to work, the data payload and events (when
present) MUST cover exactly the same content over the same time
period; otherwise, spurious events will be detected downstream. An
example of this mode of operation is shown below.

Note that there are a number of cases where no control sequence will
precede the data content. This is true, for example, for a number of
legacy text terminal types. In such instances, the events defined in
Section 2.7 in particular MAY be sent to help the remote gateway
optimize its handling of the alternative payload.

4. Example of V.8 Negotiation

This section presents an example of the use of the event codes
defined in Section 2. The basic scenario is the startup sequence for
duplex V.34 modem operation. It is assumed that once the initial V.8
sequence is complete, the gateways will enter into voice-band data
operation using G.711 encoding to transmit the modem signals. L'
basic packet sequence is indicated in Table 9. Sample packets are
then shown in detail for two variants on event transmission strategy:

For simplicity and semi-realism, the times shown for the example
scenario assume a fixed lag at each gateway of 20 ms between the
packet side of the gateway and the local user equipment and vice
versa (ie, minimum of 40 ms between packet received and packet sent
specifically in response to the received packet). A propagation
delay of 5 ms is assumed between gateways. It is assumed that the

At the basic V.8 protocol level, the table assumes that the answering
modem waits 0.2 s (200 ms) from the beginning of the call to start
transmitting ANSam. The calling modem waits 1 s (1000 ms) from the
time it begins to receive ANSam until it begins to send the V.8 CM
signal. Both modems wait 75 ms from the time they finish sending and
receiving CJ, respectively, until they begin sending V.34 modem
signals.

+------------+------------------------------------ ------------------+
| Time (ms) | Event |
+------------+------------------------------------ ------------------+
| 220.0 | The called gateway detects the start of ANSam from |
| | its end. |
| | |
| 250.0 | The called gateway sends out the first ANSam event |
| | packet. M bit is set, timestamp is ts0 + 1760 |
| | (where ts0 is the timestamp value at the start of |
| | the call). The initial ANSam event continues until |
| | a phase shift is detected at 670.0 ms (see below). |
| | Up to this time, the called gateway sends out |
| | further ANSam event updates, with the same initial |
| | timestamp, M bit off, and cumulative duration |
| | increasing by 240 units each time. |
| | |
| 255.0 | The calling gateway receives the first ANSam event |
| | report and begins playout of ANSam tone at its end. |
| | |
| 275.0 | The calling terminal receives the beginning of ANSam |
| | tone and starts its timer. It will begin sending |
| | the CM signal 1 s later (at 1275.0 ms into the |
| | call). |
| | |
| 670.0 | The called gateway detects a phase shift in the |
| | incoming signal, marking a change from ANSam to |
| | /ANSam. This happens to coincide with the end of a |
| | packetization interval. For the sake of the |
| | example, assume that the called gateway does not |
| | detect this in time for the event report it sends |
| | out. |
| | |

Schulzrinne & Taylor Standards Track [Page 31]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
| 700.0 | The called gateway issues its next-scheduled event |
| | report packet, indicating an initial report for |
| | /ANSam (M bit set, timestamp ts0 + 5360, duration |
| | 240 timestamp units). The packet also carries the |
| | first retransmission of the final ANSam report, |
| | total duration 3600 units, this time with the E bit |
| | set. |
| | |
| 1295.0 | The calling gateway begins to receive the CM signal |
| | from the calling modem. |
| | |
| 1325.0 | The calling gateway sends a packet containing the |
| | first 9 bits of the CM signal. |
| | |
| 1445.0 | The calling gateway sends out a packet containing |
| | the last 4 bits of the first CM signal, plus the |
| | first 5 bits of the next repetition of that signal. |
| | CM bits will continue to be transmitted from the |
| | calling gateway until 2015.0 ms (see below), for a |
| | total of 24 packets. (The final packet also carries |
| | the beginning of the CJ signal.) |
| | |
| 1596.7 | The called gateway completes playout of the final |
| | bit of the second occurrence of the CM signal. |
| | |
| 1636.7 | The called gateway detects end of /ANSam (and |
| | beginning of JM) from the called modem. The next |
| | packet is not yet due to go out. |
| | |
| 1660.0 | The called gateway sends out a packet combining the |
| | final /ANSam event report (E bit set and total |
| | duration 533 timestamp units) with the first 7 bits |
| | of the JM signal. The M bit for the packet is set |
| | and the packet timestamp is ts0 + 12560 (the start |
| | of the now-discontinued /ANSam event). |
| | |
| 1690.0 | The called gateway sends out a packet containing the |
| | next nine bits of JM signal. The M bit is set and |
| | the timestamp is ts0 + 13280 (beginning of the first |
| | bit in the packet). JM will continue to be |
| | transmitted until 2170.0 ms (see below), for a total |
| | of 18 packets (plus two for final retransmissions). |
| | |
| 1938.3 | The calling gateway completes playout of the final |
| | packet of the second occurrence of the JM signal. |
| | |
| 1995.0 | The calling gateway begins to receive the initial |
| | bits of the CJ signal. |

Schulzrinne & Taylor Standards Track [Page 32]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
| | |
| 2015.0 | The calling gateway sends a packet containing the |
| | final 3 bits of the first decad of a CM signal and |
| | first 6 bits of a CJ signal. |
| | |
| 2095.0 | The calling gateway receives the last bit of the CJ |
| | signal. A period of silence lasting 75-ms begins at |
| | the called end. It is not yet time to send out an |
| | event report. |
| | |
| 2105.0 | The calling gateway sends out a packet containing |
| | the final 6 bits of the CJ signal. |
| | |
| 2130.0 | The called gateway finishes playing out the last CJ |
| | signal bit sent to it. |
| | |
| 2135.0 | The calling gateway sends a packet containing no new |
| | events, but retransmissions of the last 15 bits of |
| | the CJ signal (in two generations). |
| | |
| 2165.0 | The calling gateway sends out a packet containing no |
| | new events, but retransmissions of the final 6 bits |
| | of the CJ signal. |
| | |
| 2170.0 | The called gateway sends out the last packet |
| | containing bits of the JM signal (except for |
| | retransmissions). Note that according to the V.8 |
| | specification these bits do not in general complete |
| | a JM signal or even an "octet" of that signal |
| | (although they happen to do so in this example). A |
| | 75 ms period of silence begins at the called end. |
| | |
| 2170.0 | The calling gateway begins to receive V.34 |
| | signalling from the called modem. |
| | |
| 2175.0 | The calling gateway finishes playing out the last JM |
| | signal bit sent to it. |
| | |
| 2195.0 | The calling gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17360 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 200 8-bit samples. Packetization interval |
| | is shown here as continuing to be 30 ms. It could |
| | be less, but MUST NOT be more because that would |
| | make the silent period too long. |
| | |
Schulzrinne & Taylor Standards Track [Page 33]

This indicates two media streams, the first for G.711 (ie, voice or
voice-band data), the second for triply-redundant telephone events.
As RFC 2198 notes, it is also possible for the sender to send
telephone-event payloads without redundancy in the second stream,
although the redundant form is the primary transmission mode. (It
would be reasonable to send the interim ANSam reports without
redundancy.) The set of telephone events supported includes the DTMF
events (not relevant in this example), and all of the data events
defined in this document. In fact, only event codes 34-35 and 37-40
are used in the example.

For the purpose of illustrating the use of RFC 2198 redundancy as
well as showing the basic composition of the event reports, the
second packet reporting JM signal bits (sent by the called gateway at
1690.0 ms) seems to be a good choice. This packet will also carry
the second retransmission of the final /ANSam event report and the
first retransmission of the initial 7 bits of the JM signal. L'
detailed content of the packet is shown in Figure 1. To see the
contents of the successive generations more clearly, they are
presented as if they were aligned on successive 32-bit boundaries.
In fact, they are all offset by one octet, following on consecutively
from the RFC 2198 header.

The M bit is set in the RTP header for the packet, as required for
the coding of multiple events in the primary block of data. In fact,
RFC 2198 implies that this is the correct behavior, but does not say
so explicitly. The E bit is set for every event. It is possible
that it would not be set for the final event in the primary block.

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Since all of the events in the above packet are consecutive and
adjacent, it would have been permissible according to the telephone-
event payload specification to carry them as a simple event payload
without the RFC 2198 header. The advantage of the latter is that the
receiving gateway can skip over the retransmitted events when
processing the packet, unless it needs them.

This indicates one media stream, with G.711 (ie, voice or voice-
band data) as the primary content, along with three blocks of
telephone events. RFC 2198 requires that the more voluminous
representation (ie, the G.711) be the primary one. The most recent
block of events covers the same time period as the voice-band data.
The other two streams provide the first and second retransmissions of
the events as in the previous example. Because G.711 is the primary
content, the M bit for the packets will in general not be set, except
after periods of silence.

Figure 2 shows the detailed packet content for the same sample point
as in the previous figure, but including the G.711 content.

The V.21 bit events defined in this document may be used to transmit
user-sensitive data. This could include initial log-on sequences and
application-level protocol exchanges as well as user content. As a
result, such a usage of V.21 bit events entails, in the terminology
of [16], threats to both communications and system security. L'
attacks of concern are:

o confidentiality violations and password sniffing;

o hijacking of data sessions through message insertion;

o modification of the transmitted content through man-in-the-middle
attacks;

o denial of service by means of message insertion, deletion, and
modification aimed at interference with the application protocol.

To prevent these attacks, the transmission of V.21 bit events MUST be
given confidentiality protection. Message authentication and the
protection of message integrity MUST also be provided. These address
the threats posed by message insertion and modification. With these
measures in place, RTP sequence numbers and the redundancy provided
by the RFC 4733 procedures for transmission of events add protection
against and some resiliency in the face of message deletion.

The other events defined in this document (and V.21 bit events within
control sequences) are used only for the setup and control of
sessions between data terminals or fax devices. While disclosure of
these events would not expose user-sensitive data, it can potentially
expose capabilities of the user equipment that could be exploited by
attacks in the PSTN domain. Thus, confidentiality protection SHOULD
be provided. The primary threat is denial of service, through
injection of inappropriate signals at vulnerable points in the
control sequence or through alteration or blocking of enough event

Schulzrinne & Taylor Standards Track [Page 39]

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
packets to disrupt that sequence. To meet the injection threat,
message authentication and integrity protection MUST be provided.

The Secure Real-time Transport Protocol (SRTP) [3] meets the
requirements for protection of confidentiality, message integrity,
and message authentication described above. It SHOULD therefore be
used to protect media streams containing the events described in this
document.

Note that the appropriate method of key distribution for SRTP may
vary with the specific application.

In some deployments, it may be preferable to use other means to
provide protection equivalent to that provided by SRTP.

6. IANA Considerations

This document adds the events in Table 10 to the registry established
by RFC 4733 [5].

Scott Petrack was the original author of RFC 2833. Henning
Schulzrinne later loaned his expertise to complete the document, but
Scott must be credited with the energy behind the idea of a compact
encoding of tones over IP.

Gunnar Hellstrom and Keith Chu provided particularly useful comments
helping to shape the present document. Amiram Allouche and Ido Benda
drew the authors' attention to the value of including events for
V.32/V.32bis in the document, and Yaakov Stein confirmed details of
operation of this modem.

[8] International Telecommunication Union, "Procedures for document
facsimile transmission in the general switched telephone
network", ITU-T Recommendation T.30, July 2003.

[9] International Telecommunication Union, "Procedures for starting
sessions of data transmission over the public switched
telephone network", ITU-T Recommendation V.8, November 2000.

[10] 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", ITU-T Recommendation V.8 bis, November 2000.

RFC 4734 Modem, Fax, and Text Telephony Events December 2006
[12] International Telecommunication Union, "300 bits per second
duplex modem standardized for use in the general switched
telephone network", ITU-T Recommendation V.21, November 1988.

[13] 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", ITU-T
Recommendation V.25, October 1996.

See also Corrigendum 1 to Recommendation V.25, Jul. 2001.

[14] International Telecommunication Union, "A family of 2-wire,
duplex modems operating at data signalling rates of up to 9600
bit/s for use on the general switched telephone network and on
leased telephone-type circuits", ITU-T Recommendation V.32,
March 1993.

[15] International Telecommunication Union, "A duplex modem
operating at data signalling rates of up to 14 400 bit/s for
use on the general switched telephone network and on leased
point-to-point 2-wire telephone-type circuits", ITU-T
Recommendation V.32bis, February 1991.

[25] International Telecommunication Union, "600/1200-baud modem
standardized for use in the general switched telephone
network", ITU-T Recommendation V.23, November 1988.

[26] International Telecommunication Union, "4800/2400 bits per
second modem standardized for use in the general switched
telephone network", ITU-T Recommendation V.27ter,
November 1988.

[27] International Telecommunication Union, "9600 bits per second
modem standardized for use on point-to-point 4-wire leased
telephone-type circuits", ITU-T Recommendation V.29,
November 1988.

[28] 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", ITU-T Recommendation V.34,
February 1998.

[29] International Telecommunication Union, "A digital modem and
analogue modem pair for use on the Public Switched Telephone
Network (PSTN) at data signalling rates of up to 56 000 bit/s
downstream and up to 33 600 bit/s upstream", ITU-T
Recommendation V.90, September 1998.

[30] International Telecommunication Union, "A digital modem
operating at data signalling rates of up to 64 000 bit/s for
use on a 4-wire circuit switched connection and on leased
point-to-point 4-wire digital circuits", ITU-T
Recommendation V.91, May 1999.

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne & Taylor Standards Track [Page 47]