GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4734

Network Working Group H. Schulzrinne Request for Comments: 4734 Columbia U. Obsoletes: 2833 T. Taylor Updates: 4733 Nortel Category: Standards Track December 2006

  Definition of Events for Modem, Fax, and Text Telephony Signals

Status of This Memo

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

Copyright Notice

 Copyright (C) The IETF Trust (2006).

Abstract

 This memo updates RFC 4733 to add event codes for modem, fax, and
 text telephony signals when carried in the telephony event RTP
 payload.  It supersedes the assignment of event codes for this
 purpose in RFC 2833, and therefore obsoletes that part of RFC 2833.

Schulzrinne & Taylor Standards Track [Page 1] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

Table of Contents

 1. Introduction ....................................................3
    1.1. Terminology ................................................3
    1.2. Overview ...................................................3
 2. Definitions of Events for Control of Data, Fax, and Text
    Telephony Sessions ..............................................5
    2.1. V.8 bis Events .............................................5
         2.1.1. Handling of Congestion ..............................9
    2.2. V.21 Events ...............................................10
         2.2.1. Handling of Congestion .............................11
    2.3. V.8 Events ................................................12
         2.3.1. Handling of Congestion .............................15
    2.4. V.25 Events ...............................................15
         2.4.1. Handling of Congestion .............................17
    2.5. V.32/V.32bis Events .......................................18
         2.5.1. Handling of Congestion .............................19
    2.6. T.30 Events ...............................................19
         2.6.1. Handling of Congestion .............................23
    2.7. Events for Text Telephony .................................23
         2.7.1. Signal Format Indicators for Text Telephony ........23
         2.7.2. Use of Events with V.18 Modems .....................27
    2.8. A Generic Indicator .......................................28
 3. Strategies for Handling Fax and Modem Signals ..................29
 4. Example of V.8 Negotiation .....................................30
    4.1. Simultaneous Transmission of Events and
         Retransmitted Events Using RFC 2198 Redundancy ............35
    4.2. Simultaneous Transmission of Events and Voice-Band
         Data Using RFC 2198 Redundancy ............................37
 5. Security Considerations ........................................39
 6. IANA Considerations ............................................40
 7. Acknowledgements ...............................................42
 8. References .....................................................43
    8.1. Normative References ......................................43
    8.2. Informative References ....................................44

Schulzrinne & Taylor Standards Track [Page 2] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

1. Introduction

1.1. Terminology

 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 [1].
 In addition to those defined for specific events, this document uses
 the following abbreviations:
 Fax    facsimile
 HDLC   High-level Data Link Control
 PSTN   Public Switched (circuit) Telephone Network

1.2. Overview

 This document extends the set of telephony events defined within the
 framework of RFC 4733 [5] to include the control events and tones
 that can appear on a subscriber line serving a fax machine, a modem,
 or a text telephony device.  The events are organized into several
 groups, corresponding to the ITU-T Recommendation in which they are
 defined.  Their purpose is to support negotiation, start-up and
 takedown of fax, modem, or text telephony sessions and transitions
 between operating modes.  The actual fax, modem, and text payload is
 typically carried by other payload types (e.g., V.150.1 [32] modem
 relay, voice-band data as formalized in ITU-T Rec. V.152 [33],
 Clearmode [17] for digital data, T.38 [21] for fax, or RFC 4103 [18]
 for character-mode text).
 NOTE: implementers SHOULD NOT rely on the descriptions of the various
 modem protocols described below without consulting the original
 references (generally ITU-T Recommendations).  The descriptions are
 provided in this document to give a context for the use of the events
 defined here.  They frequently omit important details needed for
 implementation.
 The typical application of these events is to allow the Internet to
 serve as a bridge between terminals operating on the PSTN.  This
 application is characterized as follows:
 o  each gateway will act both as sender and as receiver;
 o  time constraints apply to the exchange of signals, making the
    early identification and reporting of events desirable so that
    receiver playout can proceed in a timely fashion;

Schulzrinne & Taylor Standards Track [Page 3] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 o  the receiver must play out events in their proper order;
 o  transfer of the events must be reliable.  Applications will vary
    in their ability to recover from missing events.
 In some cases, an implementation may simply ignore certain events,
 such as fax tones, that do not make sense in a particular
 environment.  Section 2.4.1 of RFC 4733 [5] specifies how an
 implementation can use the Session Description Protocol (SDP) "fmtp"
 parameter within an SDP description [4] to indicate which events it
 is prepared to handle.
 Regardless of which events they support, implementations MUST be
 prepared to send and receive data signals using payload types other
 than telephone-event, simultaneously with the use of the latter.
 This is discussed further in Section 3.
 In many cases, continuity of playout is critical.  In principle, this
 is achieved through buffering at the receiving end.  It is generally
 desirable to minimize such buffering to reduce round-trip response
 times.  Maintenance of a constant packetization interval at the
 sending end while reporting events is helpful for this purpose.
 A further word on time constraints is in order.  Time constraints
 governing the duration of tones do not pose a problem when using the
 telephone-event payload type: the payload specifies the duration and
 the receiving gateway can play out the tones accordingly.  Problems
 occur when time constraints are specified for the duration of silence
 between tones.  A silent period of "at least x ms" is not a problem
 -- event notifications can be received late, but they can still be
 played out at their specified durations.
 The problem occurs if silence must last for a specific duration or at
 most some specific period.  The most general constraint of the latter
 type has to do with the operation of echo suppressors (ITU-T
 Rec. G.164 [6]) and echo cancellers (ITU-T Rec. G.165 [7]).  These
 devices may re-activate after as little as 100 ms of no signal on the
 line.  As a result, in any situation where echo suppressors or
 cancellers must be disabled for signalling to work, tone events must
 be reported quickly enough to ensure that these devices do not become
 re-enabled.

Schulzrinne & Taylor Standards Track [Page 4] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

2. Definitions of Events for Control of Data, Fax, and Text Telephony

  Sessions

2.1. V.8 bis Events

 Recommendation V.8 bis [10] is a general procedure for two endpoints
 to establish each other's capabilities and to transition between
 different operating modes, both at call startup and after the call
 has been established.  It supports many of the same terminals as V.8
 [9] (Section 2.3 below), but allows more detailed parameter
 negotiation.  It lacks support for some of the older V-series modems
 defined in V.8, but adds capabilities for simultaneous or alternating
 voice and data, H.324 [20] multilink, and T.120 [23] conferencing.
 Following V.8 bis capability negotiations, if the terminals have
 negotiated a modem-based operating mode, they initiate the actual
 modem session using either V.8, a truncated version of V.8
 (preferred), or V.25 start-up.  V.25 is described in Section 2.4.
 V.8 bis distinguishes between "signals" and "messages".  The V.8 bis
 signals -- ESi/ESr, MRe/MRd, and CRe/CRd -- consist of tones, as
 described in the next few paragraphs.  The V.8 bis messages -- MS,
 CL, CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), and NACK(4) --
 consist of sequences of bits transported over V.21 [12] modulation.
 Signals are intended to be comprehensible at the receiver even in the
 presence of voice content.  They consist of two tone segments.  The
 first segment consists of a dual-frequency tone held for 400 ms, and
 has the function of preparing the receiver and any in-line echo
 suppressor or canceller for what follows.  The specific frequencies
 depend only on whether the signal is from the initiator or the
 responder in a transaction.  When using the telephone-event payload,
 the V8bISeg and V8bRSeg events in Table 1 represent the first segment
 of any V.8 bis signal in the initiating and responding case,
 respectively.
    The complete V.8 bis strategy for dealing with echo suppressors or
    cancellers is described in Rec. V.8 bis Appendix III.  The only
    silent period constraints imposed are of the "at least" type,
    posing no difficulties for the use of the telephone-event payload.
 The second segment follows immediately after the first, and is a
 single tone held for 100 ms.  The frequency used indicates the
 specific signal of the six signals defined.  When using the
 telephone-event payload, the second segment of a V.8 bis signal is
 represented by the applicable event: CRdSeg, CReSeg, MRdSeg, MReSeg,

Schulzrinne & Taylor Standards Track [Page 5] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 ESiSeg, or ESrSeg, as defined in Table 1.  ESiSeg and ESrSeg use the
 same frequencies as V.21 low and high channel '1' bits, respectively
 (see Table 2), and are therefore assigned the same event codes.
 V.8 bis messages use V.21 [12] frequency-shift signalling to transfer
 message content.  V.21 is described in the next section.  V.8 bis
 uses V.21 in half-duplex mode at 300 bits/s, with the lower channel
 assigned to the initiator and the upper channel to the responder.
 Each V.8 bis message is preceded by a 100-ms preamble of continuous
 V.21 marking frequency except if it was immediately preceded by an
 ESi or ESr signal (the second segment of which is that same V.21
 marking frequency).  The sender SHALL NOT report this preamble tone
 using the ESiSeg or ESrSeg events; these are to be used only for the
 V.8 bis signals to which they pertain.
    Spelling this out, continuous V.21 marking tone immediately
    following V8bISeg and V8bRSeg is reported as ESiSeg or ESrSeg,
    respectively.  Continuous V.21 marking tone occurring in any other
    context, and particularly after CRdSeg, CReSeg, MRdSeg, or MReSeg,
    is reported by other means such as a different payload type or
    using the V.21 '1' bit events defined in Section 2.2.
 No events are defined for V.8 bis messages, but a brief description
 follows.
 o  the V.8 bis CL message describes the sending terminal's
    capabilities;
 o  the CLR message also describes capabilities, but indicates that
    the sender wants to receive a CL in return;
 o  the MS establishes a particular operating mode;
 o  the ACK and NAK messages are used to terminate the message
    transactions.
 The V.8 bis messages are organized as a sequence of octets.  The
 first two to five octets are HDLC flags (0x7E).  Then comes a message
 type identifier (four bits), a V.8 bis version identifier (four
 bits), zero to two more octets of identifying information, followed
 by zero or more information field parameters in the form of bit maps.
 An individual bit map is one to five octets in length.  Up to 64
 octets of non-standard information may also be present.  The
 information fields are followed by a checksum and one to three HDLC
 flags.  Because of limits on the size of any one information field,
 V.8 bis defines segmentation procedures.  Excess data is sent in an
 additional message, but only after prompting from the receiving end.

Schulzrinne & Taylor Standards Track [Page 6] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 Applications supporting V.8 bis signalling using the telephone-event
 payload MAY transfer V.8 bis messages in the form of sequences of
 bits, using the V.21 bit events defined in the next section.  If they
 do so, the transmitted information MUST include the complete contents
 of the message: the initial HDLC flags, the information field, the
 checksum, and the terminating HDLC flags.
 Transmission MUST also include the extra '0' bits added according to
 the procedures of Rec. V.8 bis, clause 7.2.8, to prevent false
 recognition of HDLC flags at the receiver.  Implementers should note
 that these extra '0' bits mean that in general V.8 bis messages as
 transmitted on the wire will not come out to an even multiple of
 octets.  Sending implementations MAY choose to vary the packetization
 interval to include exactly one octet of information plus any extra
 '0' bits inserted into that octet; the resulting variation will be
 insignificant compared with the amount of buffering required to guard
 against network delays in delivery of packets to the receiver (see
 below).
    One reason for reporting the V.21 bits exactly as presented on the
    wire is to match the corresponding content if it is also carried
    by other means, such as voice-band data.
 The power levels of the V.8 bis and V.21 signals are subject to
 national regulation.  Thus, it seems suitable to model V.8 bis events
 as tones for which the volumes SHOULD be specified by the sender.  If
 the receiver is rendering the V.8 bis tones as audio content for
 onward transmission, the receiver MAY use the volumes contained in
 the event reports, or MAY modify the volumes to match downstream
 national requirements.
 Table 1 summarizes the event codes defined for V.8 bis signalling in
 this document.  The individual events are described following the
 table.  Each event begins when the beginning of the tone segment is
 detected and ends when the tone is no longer detected.

Schulzrinne & Taylor Standards Track [Page 7] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

  +---------+-------------+-----------+------------+------+---------+
  | Event   | Freq.  (Hz) | Dur. (ms) | Event Code | Type | Volume? |
  +---------+-------------+-----------+------------+------+---------+
  | ESiSeg  |      980    |    100    |     38     | tone |   yes   |
  |         |             |           |            |      |         |
  | ESrSeg  |     1650    |    100    |     40     | tone |   yes   |
  |         |             |           |            |      |         |
  | CRdSeg  |     1900    |    100    |     23     | tone |   yes   |
  |         |             |           |            |      |         |
  | CReSeg  |      400    |    100    |     24     | tone |   yes   |
  |         |             |           |            |      |         |
  | MRdSeg  |     1150    |    100    |     25     | tone |   yes   |
  |         |             |           |            |      |         |
  | MReSeg  |      650    |    100    |     26     | tone |   yes   |
  |         |             |           |            |      |         |
  | V8bISeg | 1375 + 2002 |    400    |     28     | tone |   yes   |
  |         |             |           |            |      |         |
  | V8bRSeg | 1529 + 2225 |    400    |     29     | tone |   yes   |
  +---------+-------------+-----------+------------+------+---------+
                  Table 1: Events for V.8 bis Signals
 ESiSeg:
    The second segment of a V.8 bis initiating Escape Signal (ESi).
    The complete ESi signal is represented by events V8bISeg followed
    by ESiSeg.  ESi will be followed by an MS, CL, or CLR message from
    the same terminal.  A 1.5-s silent interval may come between the
    ESi signal and the transmission of the MS, CL, or CLR message to
    accommodate network echo suppressors.
 ESrSeg:
    The second segment of a V.8 bis responding Escape Signal (ESr).
    The complete ESr signal is represented by events V8bRSeg followed
    by ESrSeg.  ESr is always sent by the calling terminal in response
    to an MRe or CRe from an automatic answering station.  It will be
    followed by an MS, CL, or CLR message.  The ESr signal turns off
    any announcement being generated by the automatic answering
    station.
 CRdSeg:
    The second segment of a V.8 bis Capabilities Request signal (CRd).
    The first segment of the CRd signal is represented either by
    V8bISeg or V8bRSeg, depending on context.  The other end will
    return a capabilities list (CL or CLR message).

Schulzrinne & Taylor Standards Track [Page 8] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 CReSeg:
    The second segment of a V.8 bis Capabilities Request signal (CRe)
    initiated by an automatic answering terminal.  The complete CRe
    signal is represented by events V8bISeg followed by CReSeg.  The
    calling terminal will respond with a CRd signal or a CL or CLR
    message.
 MRdSeg:
    The second segment of a V.8 bis Mode Request signal (MRd).  The
    first segment of the MRd signal is represented either by V8bISeg
    or V8bRSeg, depending on context.  The other end will return a CRd
    signal or an MS message.
 MReSeg:
    The second segment of a V.8 bis Mode Request signal (MRe)
    initiated by an automatic answering terminal.  The complete MRe
    signal is represented by events V8bISeg followed by MReSeg.  The
    calling terminal will respond with an MRd or CRd signal or an MS
    message.
 V8bISeg:
    The first segment of an initiating V.8 bis signal, which may be
    one of ESi, CRd, CRe, MRd, or MRe.
 V8bRSeg:
    The first segment of a responding V.8 bis signal, which may be one
    of ESr, CRd, or MRd.

2.1.1. Handling of Congestion

 V.8 bis implementations are unlikely to tolerate gaps or extensions
 in playout times due to congestion-caused packet delay.  At a
 minimum, the current transaction is liable to be reset when these
 defects in playout occur.  As a result, careful management of the
 playout buffer is required at the receiver to increase robustness in
 the face of possible lost or delayed packets.  The playout algorithm
 should also be such as not to cause event playout to exceed the
 nominal duration of the event.
 V.8 bis does not appear to offer opportunities for dynamic adaptation
 to congestion through manipulation of the packetization interval.

Schulzrinne & Taylor Standards Track [Page 9] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

2.2. V.21 Events

 V.21 [12] is a modem protocol offering data transmission at a maximum
 rate of 300 bits/s.  Two channels are defined, supporting full duplex
 data transmission if required.  The low channel uses frequencies 980
 Hz for '1' (mark) and 1180 Hz for '0' (space); the high channel uses
 frequencies 1650 Hz for '1' and 1850 Hz for '0'.  The modem can
 operate synchronously or asynchronously.
 V.21 is used by other protocols (e.g., V.8 bis, V.18, T.30) for
 transmission of control data, and is also used in its own right
 between text terminals.  The V.21 events are summarized in Table 2.
 Sending implementations SHOULD report a completed event for every bit
 transmitted (i.e., rather than at transitions between '0' and '1').
 Bit events are assumed to begin and end with the clock interval for
 the event, neglecting the rise and fall times between bit
 transitions.  Thus, it is important for a gateway to determine the
 actual bit rate in use before beginning to report V.21 events.
    Sometimes determination of the bit rate is not immediately
    possible, as in the case of the 100-ms training signal at V.21
    mark frequency used before V.8 bis messages.  Transmission of a
    single longer-duration V.21 event is reasonable under these
    circumstances and should not cause any difficulties at the
    receiving end.
 Implementations SHOULD pack multiple events into one packet, using
 the procedures of Section 2.5.1.5 of RFC 4733 [5].  Eight to ten bits
 is a reasonable packetization interval.
 Reliable transmission of V.21 events is important, to prevent data
 corruption.  Reporting an event per bit rather than per transition
 increases reporting redundancy and thus reporting reliability, since
 each event completion is transmitted three times as described in
 Section 2.5.1.4 of RFC 4733 [5].  To reduce the number of packets
 required for reporting, implementations SHOULD carry the
 retransmitted events using RFC 2198 [2] redundancy encoding.  This is
 illustrated in the example in Section 4.1.
 The time to transmit one V.21 bit at the nominal rate of 300 bits/s
 is 3.33 ms, or 26.67 timestamp units at the default 8000-Hz sampling
 rate for the telephone-event payload type.  Because this duration is
 not an integral number of timestamp units, accurate reporting of the
 beginning of the event and the event duration is impossible.  Sending
 gateways SHOULD round V.21 event starting times to the nearest whole
 timestamp unit.

Schulzrinne & Taylor Standards Track [Page 10] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 When sending multiple consecutive V.21 events in a succession of
 packets, the sending gateway MUST ensure that individual event
 durations reported do not cause the last event of one packet to
 overlap with the first event of the next, taking into account the
 respective initial event timestamps.  To accomplish this, the sending
 gateway MUST derive the individual event durations as the succession
 of differences between the event starting times (so that, at 8000 Hz,
 every third event has reported duration 26 units, the remainder 27
 units).
 Where a receiving gateway recognizes that a packet reports a
 consecutive series of V.21 bit events, it SHOULD play them out at a
 uniform rate despite the possible one-timestamp-unit discrepancies in
 their reported spacing and duration.
 +--------------------+----------------+------------+------+---------+
 | Event              | Frequency (Hz) | Event Code | Type | Volume? |
 +--------------------+----------------+------------+------+---------+
 | V.21 channel 1,    |           1180 |         37 | tone |     yes |
 | '0' bit            |                |            |      |         |
 |                    |                |            |      |         |
 | V.21 channel 1,    |            980 |         38 | tone |     yes |
 | '1' bit            |                |            |      |         |
 |                    |                |            |      |         |
 | V.21 channel 2,    |           1850 |         39 | tone |     yes |
 | '0' bit            |                |            |      |         |
 |                    |                |            |      |         |
 | V.21 channel 2,    |           1650 |         40 | tone |     yes |
 | '1' bit            |                |            |      |         |
 +--------------------+----------------+------------+------+---------+
                   Table 2: Events for V.21 Signals
 Implementations that choose to transmit V.21 content using a
 different payload type may wish to use one of the indicator events
 defined in Table 7 to alert the receiver to the nature of the
 content.  It is not expected that an implementation will send both
 one of these indicator events and the V.21 bit events defined above
 for the same content.

2.2.1. Handling of Congestion

 The duration of V.21 bits cannot be extended from its nominal value
 (which depends on the transmission rate).  The playout algorithm at
 the receiver should take this constraint into account when
 compensating for the delay or loss of packets due to congestion.

Schulzrinne & Taylor Standards Track [Page 11] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 Other congestion-related considerations depend on the specific
 application for which the V.21 bit events are being used.

2.3. V.8 Events

 V.8 [9] is an older general negotiation and control protocol,
 supporting startup for the following terminals: H.324 [20]
 multimedia, V.18 [11] text, T.101 [22] videotext, T.30 [8] send or
 receive fax, and a long list of V-series modems including V.34 [28],
 V.90 [29], V.91 [30], and V.92 [31].  In contrast to V.8 bis [10], in
 V.8 only the calling terminal can determine the operating mode.
 V.8 does not use the same terminology as V.8 bis.  Rather, it defines
 four signals that consist of bits transferred by V.21 [12] at 300
 bits/s: the call indicator signal (CI), the call menu signal (CM),
 the CM terminator (CJ), and the joint menu signal (JM).  In addition,
 it uses tones defined in V.25 [13] and T.30 [8] (described below),
 and one tone (ANSam) defined in V.8 itself.  The calling terminal
 sends using the V.21 low channel; the answering terminal uses the
 high channel.
 The basic protocol sequence is subject to a number of variations to
 accommodate different terminal types.  A pure V.8 sequence is as
 follows:
 1.  After an initial period of silence, the calling terminal
     transmits the V.8 CI signal.  It repeats CI at least three times,
     continuing with occasional pauses until it detects ANSam tone.
     The CI indicates whether the calling terminal wants to function
     as H.324, V.18, T.30 send, T.30 receive, or a V-series modem.
 2.  The answering terminal transmits ANSam after detecting CI.  ANSam
     will disable any G.164 [6] echo suppressors on the circuit after
     400 ms and any G.165 [7] echo cancellers after one second of
     ANSam playout.
 3.  On detecting ANSam, the calling terminal pauses at least half a
     second, then begins transmitting CM to indicate detailed
     capabilities within the chosen mode.
 4.  After detecting at least two identical sequences of CM, the
     answering terminal begins to transmit JM, indicating its own
     capabilities (or offering an alternative terminal type if it
     cannot support the one requested).

Schulzrinne & Taylor Standards Track [Page 12] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 5.  After detecting at least two identical sequences of JM, the
     calling terminal completes the current octet of CM, then
     transmits CJ to acknowledge the JM signal.  It pauses exactly 75
     ms, then starts operating in the selected mode.
 6.  The answering terminal transmits JM until it has detected CJ.  At
     that point, it stops transmitting JM immediately, pauses exactly
     75 ms, then starts operating in the selected mode.
 The CI, CM, and JM signals all consist of a fixed sequence of ten '1'
 bits followed by a signal-dependent pattern of ten synchronization
 bits, followed by one or more octets of variable information.  Each
 octet is preceded by a '0' start bit and followed by a '1' stop bit.
 The combination of the synchronization pattern and V.21 channel
 uniquely identifies the message type.  The CJ signal consists of
 three successive octets of all zeros with stop and start bits but
 without the preceding '1's and synchronizing pattern of the other
 signals.
 Applications MAY report each instance of a CM, JM, and CJ signal,
 respectively, as a series of V.21 bit events (Section 2.2), or may
 use another payload type to carry this information.  Applications
 supporting V.8 signalling using the telephone-event payload MAY
 report the synchronization part of the CI signal (ten '1's followed
 by '00000 00001') both as a series of V.21 bit events and, when it
 has been recognized, as a single CI event.
    Note that the CI event covers only the synchronization part of the
    CI signal.  The remaining call function octet and its start and
    stop bits need to be transmitted also, either as a series of V.21
    bit events or in some other payload format.  Presumably, the
    calling end gateway will use the same format for the CM and CJ
    signals.
 The overlapping nature of V.8 signalling means that there is no risk
 of silence exceeding 100 ms once ANSam has disabled any echo control
 circuitry.  However, the 75-ms pause before entering operation in the
 selected data mode will require both the calling and the answering
 gateways to recognize the completion of CJ, so they can change from
 playout of telephone-event to playout of the data-bearing payload
 after the 75-ms period.

Schulzrinne & Taylor Standards Track [Page 13] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

    +--------+----------------------+------------+------+---------+
    | Event  |       Frequency (Hz) | Event Code | Type | Volume? |
    +--------+----------------------+------------+------+---------+
    | ANSam  |            2100 x 15 |         34 | tone |     yes |
    |        |                      |            |      |         |
    | /ANSam | 2100 x 15 phase rev. |         35 | tone |     yes |
    |        |                      |            |      |         |
    | CI     |          (V.21 bits) |         53 | tone |     yes |
    +--------+----------------------+------------+------+---------+
                    Table 3: Events for V.8 Signals
 ANSam:
    The modified answer tone ANSam consists of a sinewave signal at
    2100 Hz, amplitude-modulated by a sine wave at 15 Hz.  The
    beginning of the event is at the beginning of the 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 /ANSam
    event).  Phase reversals are used to disable echo cancellation; if
    they are being applied, they occur at 450-ms intervals.
    An ANSam event packet SHOULD NOT be sent until it is possible to
    discriminate between an ANSam event and an ANS event (see V.25
    events, below).
    The modulated envelope for the ANSam tone ranges in amplitude
    between 0.8 and 1.2 times its average amplitude.  The average
    transmitted power is governed by national regulations.  Thus, it
    makes sense to indicate the volume of the signal.
 /ANSam:
    /ANSam reports the same physical signal as ANSam, 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 /ANSam MUST reverse the phase of the tone at the beginning of
    playout of /ANSam and every 450 ms thereafter until the end of the
    tone is reached.
 CI:
    CI reports the occurrence of the V.21 bit pattern '11111 11111
    00000 00001' indicating the beginning of a V.8 CI signal.  The
    event begins at the beginning of the first bit and ends at the end
    of the last one.  This event MUST NOT be reported except in a
    context where a V.8 CI signal might be expected (i.e., at the
    calling end during call setup).  Note that if the calling modem

Schulzrinne & Taylor Standards Track [Page 14] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

    sends the CI signal at all, it will typically repeat the signal
    several times.
    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.  The
 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 events defined for V.25 signalling are shown in Table 4.
 +-------------------+----------------+------------+------+---------+
 | Event             | Frequency (Hz) | Event Code | Type | Volume? |
 +-------------------+----------------+------------+------+---------+
 | Answer tone (ANS) | 2100           |         32 | tone |     yes |
 |                   |                |            |      |         |
 | /ANS              | 2100 ph. rev.  |         33 | tone |     yes |
 |                   |                |            |      |         |
 | CT                | 1300           |         49 | tone |     yes |
 +-------------------+----------------+------------+------+---------+
                   Table 4: Events for V.25 Signals

Schulzrinne & Taylor Standards Track [Page 16] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 ANS:
    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.  The
 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.

Schulzrinne & Taylor Standards Track [Page 17] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

2.5. V.32/V.32bis Events

 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
 14,400 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, i.e., 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.
  +----------------+------------------+------------+------+---------+
  | Event          | Bit Pattern      | Event Code | Type | Volume? |
  +----------------+------------------+------------+------+---------+
  | V32AA          | b'0000' repeated |         63 | tone |     yes |
  |                |                  |            |      |         |
  | V32AC          | b'0011' repeated |         27 | tone |     yes |
  +----------------+------------------+------------+------+---------+
               Table 5: Events for V.32/V.32bis Signals

Schulzrinne & Taylor Standards Track [Page 18] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 V32AA:
    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.  The
 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.  The
 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 (e.g., 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.

Schulzrinne & Taylor Standards Track [Page 21] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 +--------------------+----------------+------------+------+---------+
 | Event              | Frequency (Hz) | Event Code | Type | Volume? |
 +--------------------+----------------+------------+------+---------+
 | CED (Called tone)  | 2100           |         32 | tone |     yes |
 |                    |                |            |      |         |
 | /CED               | 2100 ph. rev.  |         33 | tone |     yes |
 |                    |                |            |      |         |
 | CNG (Calling tone) | 1100           |         36 | tone |     yes |
 |                    |                |            |      |         |
 | V.21 preamble flag | (V.21 bits)    |         54 | tone |     yes |
 +--------------------+----------------+------------+------+---------+
                   Table 6: Events for T.30 Signals
 CED:
    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:
 o  Baudot [34], a five bit character encoding nominally operating at
    45.45 or 50 bits/s with frequencies 1800 Hz = '0', 1400 Hz = '1';
 o  EDT, which is V.21 [12] operating at 110 bits/s in half-duplex
    mode (lower channel only); characters are 7-bit IA5 plus initial
    start bit, trailing parity bit, and two stop bits;
 o  Bell 103 mode (documented in Recommendation V.18 Annex D), which
    is structurally similar to V.21, but uses different frequencies:
    lower channel, 1070 Hz = '0', 1270 Hz = '1'; upper channel, 2025
    Hz = '0', 2225 Hz = '1'; characters are US ASCII framed by one
    start bit, one trailing parity bit, and one stop bit;
 o  V.23 [25] based videotex, in Minitel and Prestel versions.  V.23
    offers a forward channel operating at 1200 bits/s if possible
    (2100 Hz = '0', 1300 Hz = '1') or otherwise at 600 bits/s (1700 Hz
    = '0', 1300 Hz = '1'), and a 75 bits/s backward channel, which is
    transmitting 390 Hz (continuous '1's) except when '0' is to be
    transmitted (450 Hz);
 o  a non-V.18 text terminal using V.21 [12] at 300 bits/s.
    Characters are 7-bit national (e.g., US ASCII) with a start bit,
    parity, and one stop bit.

Schulzrinne & Taylor Standards Track [Page 24] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 +----------+-----------+----------------+---------+-------+---------+
 | Event    | Bit Rate  | Frequency (Hz) |   Event |  Type | Volume? |
 |          | bits/s    |                |    Code |       |         |
 +----------+-----------+----------------+---------+-------+---------+
 | ANS2225  | N/A       | 2225           |      52 |  tone |     yes |
 |          |           |                |         |       |         |
 | V21L110  | 110       | 980/1180       |      55 | other |      no |
 |          |           |                |         |       |         |
 | V21L300  | 300       | 980/1180       |      30 | other |      no |
 |          |           |                |         |       |         |
 | V21H300  | 300       | 1650/1850      |      31 | other |      no |
 |          |           |                |         |       |         |
 | B103L300 | 300       | 1070/1270      |      56 | other |      no |
 |          |           |                |         |       |         |
 | V23Main  | 600/1200  | 1700-2100/1300 |      57 | other |      no |
 |          |           |                |         |       |         |
 | V23Back  | 75        | 450/390        |      58 | other |      no |
 |          |           |                |         |       |         |
 | Baud4545 | 45.45     | 1800/1400      |      59 | other |      no |
 |          |           |                |         |       |         |
 | Baud50   | 50        | 1800/1400      |      60 | other |      no |
 |          |           |                |         |       |         |
 | XCIMark  | 1200      | 2100/1300      |      62 |  tone |     yes |
 +----------+-----------+----------------+---------+-------+---------+
                Table 7: Indicators for Text Telephony
 ANS2225:
    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 (i.e., 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 (e.g., 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.  If the
 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.  The
 3-second XCI signal uses the V.23 upper channel having periods of
 "mark" (i.e., 1300 Hz) alternating with the XCIMark pattern.  The
 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.

Schulzrinne & Taylor Standards Track [Page 28] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 +--------+---------------+------------+-----------+-------+---------+
 | Event  | Bit Rate      | Frequency  |     Event |  Type | Volume? |
 |        | bits/s        | (Hz)       |      Code |       |         |
 +--------+---------------+------------+-----------+-------+---------+
 | VBDGen | Variable      | Variable   |        61 | other |      no |
 +--------+---------------+------------+-----------+-------+---------+
                Table 8: Generic Modem Signal Indicator
 VBDGen:
    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.  The
 basic packet sequence is indicated in Table 9.  Sample packets are
 then shown in detail for two variants on event transmission strategy:
 o  simultaneous transmission of events and retransmitted events using
    RFC 2198 [2] redundancy;
 o  simultaneous transmission of events, retransmitted events, and
    voice-band data covering the same content using RFC 2198
    redundancy.
 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 (i.e., 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

Schulzrinne & Taylor Standards Track [Page 30] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 event packetization interval is 30 ms, a reasonable compromise
 between packet volume and buffering delay, particularly for V.21
 events.
 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] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 |     2200.0 | The called gateway sends a packet containing no new  |
 |            | events, but retransmissions of the last 18 bits of   |
 |            | the JM signal (in two generations).                  |
 |            |                                                      |
 |     2225.0 | The calling gateway sends out the second packet of   |
 |            | V.34 signalling as voice-band data (PCMU).           |
 |            | Timestamp is ts0 + 17560 and M bit is not set.  The  |
 |            | packet contains 240 8-bit samples.                   |
 |            |                                                      |
 |     2230.0 | The called gateway sends out a packet containing no  |
 |            | new events, but retransmissions of the final 9 bits  |
 |            | of the JM signal.                                    |
 |            |                                                      |
 |     2245.0 | The called gateway begins to receive V.34 signalling |
 |            | from the called modem.                               |
 |            |                                                      |
 |     2255.0 | The calling gateway sends out a third packet of V.34 |
 |            | signalling as voice-band data (PCMU).  Timestamp is  |
 |            | ts0 + 17800 and M bit is not set.  The packet        |
 |            | contains 240 8-bit samples.                          |
 |            |                                                      |
 |     2260.0 | The called gateway sends out a first packet of V.34  |
 |            | signalling as voice-band data (PCMU).  Timestamp is  |
 |            | ts0 + 17960 and M bit is set to indicate the         |
 |            | beginning of content after silence.  The packet      |
 |            | contains 120 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.                          |
 |            |                                                      |
 |      . . . | . . .                                                |
 +------------+------------------------------------------------------+
               Table 9: Events for Example V.8 Scenario

Schulzrinne & Taylor Standards Track [Page 34] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

4.1. Simultaneous Transmission of Events and Retransmitted Events Using

    RFC 2198 Redundancy
 Negotiation of the transmission mode being described in this section
 would use SDP similar to the following:
    m=audio 12343 RTP/AVP 99
    a=rtpmap:99 pcmu/8000
    m=audio 12345 RTP/AVP 100 101
    a=rtpmap:100 red/8000/1
    a=fmtp:100 101/101/101
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15,32-41,43,46,48-49,52-68
 This indicates two media streams, the first for G.711 (i.e., 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.  The
 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.

Schulzrinne & Taylor Standards Track [Page 35] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

     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=0  |1|  PT=100     |   sequence number = seq0 + 48 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              timestamp = ts0 + 13280                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           synchronization source (SSRC) identifier            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1| block PT=101|  timestamp offset = 720   | block length =  4 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1| block PT=101|  timestamp offset = 267   | block length = 28 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0| block PT=101|     (begin block for /ANSam ...)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    /ANSam block (second retransmission)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 35  |1|R| volume    |       duration = 533        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            First 7 bits of JM (="1111111" in V.21 high channel)
                  (first retransmission)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 40  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /    (5 similar events, durations 27,26,27,27,26 respectively)  /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 40  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Next 9 bits of JM (="111000000" in V.21 high channel)
                  (new content)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 40  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /     (7 similar events, codes 40,40,39,39,39,39,39 and         /
    /      durations 26,27,27,26,27,27,26 respectively)             /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 39  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 1: Packet Contents, Redundant Events Only

Schulzrinne & Taylor Standards Track [Page 36] 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.

4.2. Simultaneous Transmission of Events and Voice-Band Data Using RFC

    2198 Redundancy
 Negotiation of the transmission mode being described in this section
 would use SDP similar to the following:
    m=audio 12343 RTP/AVP 99 100 101
    a=rtpmap:99 red/8000/1
    a=fmtp:99 100/101/101/101
    a=rtpmap:100 pcmu/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15,32-41,43,46,48-49,52-68
 This indicates one media stream, with G.711 (i.e., voice or voice-
 band data) as the primary content, along with three blocks of
 telephone events.  RFC 2198 requires that the more voluminous
 representation (i.e., 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.

Schulzrinne & Taylor Standards Track [Page 37] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

     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=0  |0|  PT=99      |   sequence number = seq0 + 48 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              timestamp = ts0 + 13280                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           synchronization source (SSRC) identifier            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1| block PT=101|  timestamp offset = 720   | block length =  4 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1| block PT=101|  timestamp offset = 267   | block length = 28 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1| block PT=101|  timestamp offset = 0     | block length = 36 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0| block PT=100|     (begin block for /ANSam ...)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    /ANSam block (second retransmission)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 35  |1|R| volume    |       duration = 533        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            First 7 bits of JM (="1111111" in V.21 high channel)
                  (first retransmission)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 40  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /    (5 similar events, durations 27,26,27,27,26 respectively)  /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 40  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Next 9 bits of JM (="111000000" in V.21 high channel)
                  (new content)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 40  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /     (7 similar events, codes 40,40,39,39,39,39,39 and         /
    /      durations 26,27,27,26,27,27,26 respectively)             /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     event = 39  |1|R| volume    |       duration = 27         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Schulzrinne & Taylor Standards Track [Page 38] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

           30 ms of G.711-encoded voice-band data (240 samples)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Sample 1    |   Sample 2    |   Sample 3    |   Sample 4    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                            . . .                              /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Sample 237  |   Sample 238  |   Sample 239  |   Sample 240  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Figure 2: Packet Contents with Voice-Band Data Combined with Events

5. Security Considerations

 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.  The
 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].
 +-------+--------------------------------------------+--------------+
 | Event | Event Name                                 |    Reference |
 |  Code |                                            |              |
 +-------+--------------------------------------------+--------------+
 |   23  | CRdSeg: second segment of V.8 bis CRd      |     RFC 4734 |
 |       | signal                                     |              |
 |       |                                            |              |
 |   24  | CReSeg: second segment of V.8 bis CRe      |     RFC 4734 |
 |       | signal                                     |              |
 |       |                                            |              |
 |   25  | MRdSeg: second segment of V.8 bis MRd      |     RFC 4734 |
 |       | signal                                     |              |
 |       |                                            |              |
 |   26  | MReSeg: second segment of V.8 bis MRe      |     RFC 4734 |
 |       | signal                                     |              |
 |       |                                            |              |
 |   27  | V32AC: A pattern of bits modulated at 4800 |     RFC 4734 |
 |       | bits/s, emitted by a V.32/V.32bis          |              |
 |       | answering terminal upon detection of the   |              |
 |       | AA pattern.                                |              |
 |       |                                            |              |
 |   28  | V8bISeg: first segment of initiating V.8   |     RFC 4734 |
 |       | bis signal                                 |              |
 |       |                                            |              |
 |   29  | V8bRSeg: first segment of responding V.8   |     RFC 4734 |
 |       | bis signal                                 |              |
 |       |                                            |              |

Schulzrinne & Taylor Standards Track [Page 40] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 |   30  | V21L300: 300 bits/s low channel V.21       |     RFC 4734 |
 |       | indication                                 |              |
 |       |                                            |              |
 |   31  | V21H300: 300 bits/s high channel V.21      |     RFC 4734 |
 |       | indication                                 |              |
 |       |                                            |              |
 |   32  | ANS (V.25 Answer tone).  Also known as CED |     RFC 4734 |
 |       | (T.30 Called tone).                        |              |
 |       |                                            |              |
 |   33  | /ANS (V.25 Answer tone after phase shift). |     RFC 4734 |
 |       | Also known as /CED (T.30 Called tone after |              |
 |       | phase shift)                               |              |
 |       |                                            |              |
 |   34  | ANSam (V.8 amplitude modified Answer tone) |     RFC 4734 |
 |       |                                            |              |
 |   35  | /ANSam (V.8 amplitude modified Answer tone |     RFC 4734 |
 |       | after phase shift)                         |              |
 |       |                                            |              |
 |   36  | CNG (T.30 Calling tone)                    |     RFC 4734 |
 |       |                                            |              |
 |   37  | V.21 channel 1 (low channel), '0' bit      |     RFC 4734 |
 |       |                                            |              |
 |   38  | V.21 channel 1, '1' bit.  Also used for    |     RFC 4734 |
 |       | ESiSeg (second segment of V.8 bis ESi      |              |
 |       | signal).                                   |              |
 |       |                                            |              |
 |   39  | V.21 channel 2, '0' bit                    |     RFC 4734 |
 |       |                                            |              |
 |   40  | V.21 channel 2, '1' bit.  Also used for    |     RFC 4734 |
 |       | ESrSeg (second segment of V.8 bis ESr      |              |
 |       | signal).                                   |              |
 |       |                                            |              |
 |   49  | CT (V.25 Calling Tone)                     |     RFC 4734 |
 |       |                                            |              |
 |   52  | ANS2225: 2225-Hz indication for text       |     RFC 4734 |
 |       | telephony                                  |              |
 |       |                                            |              |
 |   53  | CI (V.8 Call Indicator signal preamble)    |     RFC 4734 |
 |       |                                            |              |
 |   54  | V.21 preamble flag (T.30)                  |     RFC 4734 |
 |       |                                            |              |
 |   55  | V21L110: 110 bits/s V.21 indication for    |     RFC 4734 |
 |       | text telephony                             |              |
 |       |                                            |              |
 |   56  | B103L300: Bell 103 low channel indication  |     RFC 4734 |
 |       | for text telephony                         |              |
 |       |                                            |              |

Schulzrinne & Taylor Standards Track [Page 41] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 |   57  | V23Main: V.23 main channel indication for  |     RFC 4734 |
 |       | text telephony                             |              |
 |       |                                            |              |
 |   58  | V23Back: V.23 back channel indication for  |     RFC 4734 |
 |       | text telephony                             |              |
 |       |                                            |              |
 |   59  | Baud4545: 45.45 bits/s Baudot indication   |     RFC 4734 |
 |       | for text telephony                         |              |
 |       |                                            |              |
 |   60  | Baud50: 50 bits/s Baudot indication for    |     RFC 4734 |
 |       | text telephony                             |              |
 |       |                                            |              |
 |   61  | VBDGen: Tone patterns indicative of use of |     RFC 4734 |
 |       | an unidentified modem type                 |              |
 |       |                                            |              |
 |   62  | XCIMark: A pattern of bits modulated in    |     RFC 4734 |
 |       | the V.23 main channel, emitted by a V.18   |              |
 |       | calling terminal.                          |              |
 |       |                                            |              |
 |   63  | V32AA: A pattern of bits modulated at 4800 |     RFC 4734 |
 |       | bits/s, emitted by a V.32/V.23bis calling  |              |
 |       | terminal.                                  |              |
 +-------+--------------------------------------------+--------------+
 Table 10: Data-Related Additions to RFC 4733 Telephony Event Registry

7. Acknowledgements

 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.

Schulzrinne & Taylor Standards Track [Page 42] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

8. References

8.1. Normative References

 [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
 [2]   Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
       M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP
       Payload for Redundant Audio Data", RFC 2198, September 1997.
 [3]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
       Norrman, "The Secure Real-time Transport Protocol (SRTP)",
       RFC 3711, March 2004.
 [4]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
       Description Protocol", RFC 4566, July 2006.
 [5]   Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
       Telephony Tones, and Telephony Signals", RFC 4733, December
       2006.
 [6]   International Telecommunication Union, "Echo suppressors",
       ITU-T Recommendation G.164, November 1988.
 [7]   International Telecommunication Union, "Echo cancellers", ITU-T
       Recommendation G.165, March 1993.
 [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.
 [11]  International Telecommunication Union, "Operational and
       interworking requirements for {DCEs operating in the text
       telephone mode", ITU-T Recommendation V.18, November 2000.
       See also Recommendation V.18 Amendment 1, Nov. 2002.

Schulzrinne & Taylor Standards Track [Page 43] 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.

8.2. Informative References

 [16]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
       Security Considerations", BCP 72, RFC 3552, July 2003.
 [17]  Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent
       Call", RFC 4040, April 2005.
 [18]  Hellstrom, G. and P. Jones, "RTP Payload for Text
       Conversation", RFC 4103, June 2005.
 [19]  International Telecommunication Union, "Pulse code modulation
       (PCM) of voice frequencies", ITU-T Recommendation G.711,
       November 1988.
 [20]  International Telecommunication Union, "Terminal for low bit-
       rate multimedia communication", ITU-T Recommendation H.324,
       March 2002.
 [21]  International Telecommunication Union, "Procedures for real-
       time Group 3 facsimile communication over IP networks", ITU-T
       Recommendation T.38, July 2003.

Schulzrinne & Taylor Standards Track [Page 44] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 [22]  International Telecommunication Union, "International
       interworking for videotex services", ITU-T
       Recommendation T.101, November 1994.
 [23]  International Telecommunication Union, "Data protocols for
       multimedia conferencing", ITU-T Recommendation T.120,
       July 1996.
 [24]  International Telecommunication Union, "A 2-wire modem for
       facsimile applications with rates up to 14 400 bit/s", ITU-T
       Recommendation V.17, 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.
 [31]  International Telecommunication Union, "Enhancements to
       Recommendation V.90", ITU-T Recommendation V.92, November 2000.

Schulzrinne & Taylor Standards Track [Page 45] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

 [32]  International Telecommunication Union, "Modem-over-IP networks:
       Procedures for the end-to-end connection of V-series DCEs",
       ITU-T Recommendation V.150.1, January 2003.
 [33]  International Telecommunication Union, "Procedures for
       supporting voice-band data over IP networks", ITU-T
       Recommendation V.152, January 2005.
 [34]  Telecommunications Industry Association, "A Frequency Shift
       Keyed Modem for Use on the Public Switched Telephone Network",
       ANSI TIA- 825-A-2003, April 2003.

Authors' Addresses

 Henning Schulzrinne
 Columbia U.
 Dept. of Computer Science
 Columbia University
 1214 Amsterdam Avenue
 New York, NY  10027
 US
 EMail: schulzrinne@cs.columbia.edu
 Tom Taylor
 Nortel
 1852 Lorraine Ave
 Ottawa, Ontario  K1H 6Z8
 Canada
 EMail: taylor@nortel.com

Schulzrinne & Taylor Standards Track [Page 46] RFC 4734 Modem, Fax, and Text Telephony Events December 2006

Full Copyright Statement

 Copyright (C) The IETF Trust (2006).
 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4734.txt · Last modified: 2006/12/12 01:39 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki