tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4734

 
 
 

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

Part 2 of 2, p. 29 to 47
Prev RFC Part

 


prevText      Top      Up      ToC       Page 29 
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.

Top      Up      ToC       Page 30 
   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

Top      Up      ToC       Page 31 
   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.                                                 |
   |            |                                                      |

Top      Up      ToC       Page 32 
   |      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.                               |

Top      Up      ToC       Page 33 
   |            |                                                      |
   |     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.                     |
   |            |                                                      |

Top      Up      ToC       Page 34 
   |     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

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
       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

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
       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         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 39 
             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

Top      Up      ToC       Page 40 
   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                                 |              |
   |       |                                            |              |

Top      Up      ToC       Page 41 
   |   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                         |              |
   |       |                                            |              |

Top      Up      ToC       Page 42 
   |   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.

Top      Up      ToC       Page 43 
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.

Top      Up      ToC       Page 44 
   [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.

Top      Up      ToC       Page 45 
   [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.

Top      Up      ToC       Page 46 
   [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

Top      Up      ToC       Page 47 
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.