tech-invite   World Map     

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

RFC 4733

 
 
 

RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals

Part 2 of 2, p. 23 to 49
Prev RFC Part

 


prevText      Top      Up      ToC       Page 23 
3.  Specification of Event Codes for DTMF Events

   This document defines one class of named events: DTMF tones.

3.1.  DTMF Applications

   DTMF signalling [10] is typically generated by a telephone set or
   possibly by a PBX (Private branch telephone exchange).  DTMF digits
   may be consumed by entities such as gateways or application servers
   in the IP network, or by entities such as telephone switches or IVRs
   in the circuit switched network.

Top      Up      ToC       Page 24 
   The DTMF events support two possible applications at the sending end:

   1.  The Internet telephony gateway detects DTMF on the incoming
       circuits and sends the RTP payload described here instead of
       regular audio packets.  The gateway likely has the necessary
       digital signal processors and algorithms, as it often needs to
       detect DTMF, e.g., for two-stage dialing.  Having the gateway
       detect tones relieves the receiving Internet end system from
       having to do this work and also avoids having low bit-rate codecs
       like G.723.1 [20] render DTMF tones unintelligible.

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

   A similar distinction occurs at the receiving end.

   1.  In the gateway scenario, an Internet telephony gateway connecting
       a packet voice network to the PSTN re-creates the DTMF tones or
       other telephony events and injects them into the PSTN.

   2.  In the end system scenario, the DTMF events are consumed by the
       receiving entity itself.

   In the most common application, DTMF tones are sent in one direction
   only, typically from the calling end.  The consuming device is most
   commonly an IVR.  DTMF may alternate with voice from either end.  In
   most cases, the only constraint on tone duration is that it exceed a
   minimum value.  However, in some cases a long-duration tone (in
   excess of 1-2 seconds) has special significance.

      ITU-T Recommendation Q.24 [11], Table A-1, indicates that the
      legacy switching equipment in the countries surveyed expects a
      minimum recognizable signal duration of 40 ms, a minimum pause
      between signals of 40 ms, and a maximum signalling rate of 8 to 10
      digits per second depending on the country.  Human-generated DTMF
      signals, of course, are generally longer with larger pauses
      between them.

   DTMF tones may also be used for text telephony.  This application is
   documented in ITU-T Recommendation V.18 [27] Annex B.  In this case,
   DTMF is sent alternately from either end (half-duplex mode), with a
   minimum 300-ms turn-around time.  The only constraints on tone
   durations in this application are that they and the pauses between
   them must exceed specified minimum values.  It is RECOMMENDED that a
   gateway at the sending end be capable of detecting DTMF signals as
   specified by V.18 Annex B (tones and pauses >=40 ms), but should send

Top      Up      ToC       Page 25 
   event durations corresponding to those of a V.18 DTMF sender (tones
   >=70 ms, pauses >=50 ms).  This may occasionally imply some degree of
   buffering of outgoing events, but if the source terminal conforms to
   V.18 Annex B, this should not get out of hand.

   Since minor increases in tone duration are harmless for all
   applications of DTMF, but unintended breaks in playout of a DTMF
   digit can confuse the receiving endpoint by creating the appearance
   of extra digits, receiving applications that are converting DTMF
   events back to tones SHOULD use the second playout algorithm rather
   than the first one in Section 2.5.2.2.  This provides some robustness
   against packet loss or congestion.

3.2.  DTMF Events

   Table 3 shows the DTMF-related event codes within the telephone-event
   payload format.  The DTMF digits 0-9 and * and # are commonly
   supported.  DTMF digits A through D are less frequently encountered,
   typically in special applications such as military networks.

                    +-------+--------+------+---------+
                    | Event | Code   | Type | Volume? |
                    +-------+--------+------+---------+
                    | 0--9  | 0--9   | tone | yes     |
                    | *     | 10     | tone | yes     |
                    | #     | 11     | tone | yes     |
                    | A--D  | 12--15 | tone | yes     |
                    +-------+--------+------+---------+

                        Table 3: DTMF Named Events

3.3.  Congestion Considerations

   The key considerations for the delivery of DTMF events are
   reliability and avoidance of unintended breaks within the playout of
   a given tone.  End-to-end round-trip delay is not a major
   consideration except in the special case where DTMF tones are being
   used for text telephony.  Assuming that, as recommended in
   Section 3.1 above, the second playout algorithm of Section 2.5.2.2 is
   in use, a temporary increase in packetization interval to as much as
   100 ms or double the normal interval, whichever is less, should be
   harmless.

Top      Up      ToC       Page 26 
4.  RTP Payload Format for Telephony Tones

4.1.  Introduction

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

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

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

   o  In-band tones for telephony events are in the range of 25 Hz
      (ringing tone in Angola) to 2600 Hz (the tone used for line
      signalling in SS No. 5 and R1).  The in-band telephone frequency
      range is limited to 3400 Hz.  R2 defines a 3825 Hz out-of-band
      tone for line signalling on analogue trunks.  (The piano has a
      range from 27.5 to 4186 Hz.)

   o  Modulation frequencies range between 15 (ANSam tone) to 480 Hz
      (Jamaica).  Non-integer frequencies are used only for frequencies
      of 16 2/3 and 33 1/3 Hz.

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

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

Top      Up      ToC       Page 27 
4.2.  Examples of Common Telephone Tone Signals

   As an aid to the implementor, Table 4 summarizes some common tones.
   The rows labeled "ITU ..." refer to ITU-T Recommendation E.180 [18].
   In these rows, the on and off durations are suggested ranges within
   which local standards would set specific values.  The symbol "+" in
   the table indicates addition of the tones, without modulation, while
   "*" indicates amplitude modulation.

   +-------------------------+-------------------+----------+----------+
   | Tone Name               | Frequency         | On Time  | Off Time |
   |                         |                   | (s)      | (s)      |
   +-------------------------+-------------------+----------+----------+
   | CNG                     | 1100              | 0.5      | 3.0      |
   | V.25 CT                 | 1300              | 0.5      | 2.0      |
   | CED                     | 2100              | 3.3      | --       |
   | ANS                     | 2100              | 3.3      | --       |
   | ANSam                   | 2100*15           | 3.3      | --       |
   | V.21 bit                | 980 or 1180 or    | 0.00333  | --       |
   |                         | 1650 or 1850      |          |          |
   | -------------           | ----------        | -------- | -------- |
   | ITU dial tone           | 425               | --       | --       |
   | U.S. dial tone          | 350+440           | --       | --       |
   | ITU ringing tone        | 425               | 0.67-1.5 | 3-5      |
   | U.S. ringing tone       | 440+480           | 2.0      | 4.0      |
   | ITU busy tone           | 425               | 0.1-0.6  | 0.1-0.7  |
   | U.S. busy tone          | 480+620           | 0.5      | 0.5      |
   | ITU congestion tone     | 425               | 0.1-0.6  | 0.1-0.7  |
   | U.S. congestion tone    | 480+620           | 0.25     | 0.25     |
   +-------------------------+-------------------+----------+----------+

                   Table 4: Examples of Telephony Tones

4.3.  Use of RTP Header Fields

4.3.1.  Timestamp

   The RTP timestamp reflects the measurement point for the current
   packet.  The event duration described in Section 4.3.3 begins at that
   time.

4.3.2.  Marker Bit

   The tone payload type uses the marker bit to distinguish the first
   RTP packet reporting a given instance of a tone from succeeding
   packets for that tone.  The marker bit SHOULD be set to 1 for the
   first packet, and to 0 for all succeeding packets relating to the
   same tone.

Top      Up      ToC       Page 28 
4.3.3.  Payload Format

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

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

   The payload format is shown in Figure 2.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    modulation   |T|  volume   |          duration             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |R R R R|       frequency       |R R R R|       frequency       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |R R R R|       frequency       |R R R R|       frequency       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ......

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |R R R R|       frequency       |R R R R|      frequency        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: Payload Format for Tones

   The payload contains the following fields:

   modulation:
      The modulation frequency, in Hz.  The field is a 9-bit unsigned
      integer, allowing modulation frequencies up to 511 Hz.  If there
      is no modulation, this field has a value of zero.  Note that the
      amplitude of modulation is not indicated in the payload and must
      be determined by out-of-band means.

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

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

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

   duration:
      The duration of the tone, measured in timestamp units and
      presented in network byte order.  The tone begins at the instant
      identified by the RTP timestamp and lasts for the duration value.
      The value of zero is not permitted, and tones with such a duration
      SHOULD be ignored.

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

   frequency:
      The frequencies of the tones to be added, measured in Hz and
      represented as a 12-bit unsigned integer.  The field size is
      sufficient to represent frequencies up to 4095 Hz, which exceeds
      the range of telephone systems.  A value of zero indicates
      silence.  A single tone can contain any number of frequencies.  If
      no frequencies are specified, the packet reports a period of
      silence.

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

4.3.4.  Optional Media Type Parameters

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

4.4.  Procedures

   This section defines the procedures associated with the tone payload
   type.

4.4.1.  Sending Procedures

   The sender MAY send an initial tones packet as soon as a tone is
   recognized, or MAY wait until a pre-negotiated packetization period
   has elapsed.  The first RTP packet for a tone SHOULD have the marker
   bit set to 1.

Top      Up      ToC       Page 30 
   In the case of longer-duration tones, the sender SHOULD generate
   multiple RTP packets for the same tone instance.  The RTP timestamp
   MUST be updated for each packet generated (in contrast, for instance,
   to the timestamp for packets carrying telephone events).  Subsequent
   packets for the same tone SHOULD have the marker bit set to 0, and
   the RTP timestamp in each subsequent packet MUST equal the sum of the
   timestamp and the duration in the preceding packet.

   A final RTP packet MAY be generated as soon as the end of the tone is
   detected, without waiting for the latest packetization period to
   elapse.

   The telephone-event payload described in Section 2 is inherently
   redundant, in that later packets for the same event carry all of the
   earlier history of the event except for variations in volume.  In
   contrast, each packet for the tone payload type stands alone; a lost
   packet means a gap in the information available at the receiving end.
   Thus, for increased reliability, the sender SHOULD combine new and
   old tone reports in the same RTP packet using RFC 2198 [2] audio
   redundancy.

4.4.2.  Receiving Procedures

   Receiving implementations play out the tones as received, typically
   with a playout delay to allow for lost packets.  When playing out
   successive tone reports for the same tone (marker bit is zero, the
   RTP timestamp is contiguous with that of the previous RTP packet, and
   payload content is identical), the receiving implementation SHOULD
   continue the tone without change or a break.

4.4.3.  Handling of Congestion

   If the sender determines that packets are being lost due to
   congestion (e.g., through RTCP receiver reports), it SHOULD increase
   the packetization interval for initial and interim tone reports so as
   to reduce traffic volume to the receiver.  The degree to which this
   is possible without causing damaging consequences at the receiving
   end depends both upon the playout delay used at that end and upon the
   specific application associated with the tones.  Both the maximum
   packetization interval and maximum increase in packetization interval
   at any one time are therefore a matter of configuration or out-of-
   band negotiation.

Top      Up      ToC       Page 31 
5.  Examples

   Consider a DTMF dialling sequence, where the user dials the digits
   "911" and a sending gateway detects them.  The first digit is 200 ms
   long (1600 timestamp units) and starts at time 0; the second digit
   lasts 250 ms (2000 timestamp units) and starts at time 880 ms (7040
   timestamp units); the third digit is pressed at time 1.4 s (11,200
   timestamp units) and lasts 220 ms (1760 timestamp units).  The frame
   duration is 50 ms.

   Table 5 shows the complete sequence of events assuming that only the
   telephone-event payload type is being reported.  For simplicity: the
   timestamp is assumed to begin at 0, the RTP sequence number at 1, and
   volume settings are omitted.

   +-------+-----------+------+--------+------+--------+--------+------+
   |  Time | Event     |   M  |  Time- |  Seq |  Event |  Dura- |   E  |
   |  (ms) |           |  bit |  stamp |   No |  Code  |   tion |  bit |
   +-------+-----------+------+--------+------+--------+--------+------+
   |     0 | "9"       |      |        |      |        |        |      |
   |       | starts    |      |        |      |        |        |      |
   |    50 | RTP       |  "1" |      0 |    1 |    9   |    400 |  "0" |
   |       | packet 1  |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |   100 | RTP       |  "0" |      0 |    2 |    9   |    800 |  "0" |
   |       | packet 2  |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |   150 | RTP       |  "0" |      0 |    3 |    9   |   1200 |  "0" |
   |       | packet 3  |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |   200 | RTP       |  "0" |      0 |    4 |    9   |   1600 |  "0" |
   |       | packet 4  |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |   200 | "9" ends  |      |        |      |        |        |      |
   |   250 | RTP       |  "0" |      0 |    5 |    9   |   1600 |  "1" |
   |       | packet 4  |      |        |      |        |        |      |
   |       | first     |      |        |      |        |        |      |
   |       | retrans-  |      |        |      |        |        |      |
   |       | mission   |      |        |      |        |        |      |
   |   300 | RTP       |  "0" |      0 |    6 |    9   |   1600 |  "1" |
   |       | packet 4  |      |        |      |        |        |      |
   |       | second    |      |        |      |        |        |      |
   |       | retrans-  |      |        |      |        |        |      |
   |       | mission   |      |        |      |        |        |      |
   |   880 | First "1" |      |        |      |        |        |      |
   |       | starts    |      |        |      |        |        |      |

Top      Up      ToC       Page 32 
   |   930 | RTP       |  "1" |   7040 |    7 |    1   |    400 |  "0" |
   |       | packet 5  |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |   ... | ...       |  ... |    ... |  ... |   ...  |    ... |  ... |
   |  1130 | RTP       |  "0" |   7040 |   11 |    1   |   2000 |  "0" |
   |       | packet 9  |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |  1130 | First "1" |      |        |      |        |        |      |
   |       | ends      |      |        |      |        |        |      |
   |  1180 | RTP       |  "0" |   7040 |   12 |    1   |   2000 |  "1" |
   |       | packet 9  |      |        |      |        |        |      |
   |       | first     |      |        |      |        |        |      |
   |       | retrans-  |      |        |      |        |        |      |
   |       | mission   |      |        |      |        |        |      |
   |  1230 | RTP       |  "0" |   7040 |   13 |    1   |   2000 |  "1" |
   |       | packet 9  |      |        |      |        |        |      |
   |       | second    |      |        |      |        |        |      |
   |       | retrans-  |      |        |      |        |        |      |
   |       | mission   |      |        |      |        |        |      |
   |  1400 | Second    |      |        |      |        |        |      |
   |       | "1"       |      |        |      |        |        |      |
   |       | starts    |      |        |      |        |        |      |
   |  1450 | RTP       |  "1" |  11200 |   14 |    1   |    400 |  "0" |
   |       | packet 10 |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |   ... | ...       |  ... |    ... |  ... |   ...  |    ... |  ... |
   |  1620 | Second    |      |        |      |        |        |      |
   |       | "1" ends  |      |        |      |        |        |      |
   |  1650 | RTP       |  "0" |  11200 |   18 |    1   |   1760 |  "1" |
   |       | packet 14 |      |        |      |        |        |      |
   |       | sent      |      |        |      |        |        |      |
   |  1700 | RTP       |  "0" |  11200 |   19 |    1   |   1760 |  "1" |
   |       | packet 14 |      |        |      |        |        |      |
   |       | first     |      |        |      |        |        |      |
   |       | retrans-  |      |        |      |        |        |      |
   |       | mission   |      |        |      |        |        |      |
   |  1750 | RTP       |  "0" |  11200 |   20 |    1   |   1760 |  "1" |
   |       | packet 14 |      |        |      |        |        |      |
   |       | second    |      |        |      |        |        |      |
   |       | retrans-  |      |        |      |        |        |      |
   |       | mission   |      |        |      |        |        |      |
   +-------+-----------+------+--------+------+--------+--------+------+

                    Table 5: Example of Event Reporting

Top      Up      ToC       Page 33 
   Table 6 shows the same sequence assuming that only the tone payload
   type is being reported.  This looks somewhat different.  For
   simplicity: the timestamp is assumed to begin at 0, the sequence
   number at 1.  Volume, the T bit, and the modulation frequency are
   omitted.  The latter two are always 0.

   +-------+-----------+-----+--------+------+--------+-------+--------+
   |  Time | Event     |  M  |  Time- |  Seq | Dura-  | Freq 1| Freq 2 |
   |  (ms) |           | bit |  stamp |   No | tion   | (Hz)  | (Hz)   |
   +-------+-----------+-----+--------+------+--------+-------+--------+
   |     0 | "9"       |     |        |      |        |       |        |
   |       | starts    |     |        |      |        |       |        |
   |    50 | RTP       | "1" |      0 |    1 | 400    | 852   | 1477   |
   |       | packet 1  |     |        |      |        |       |        |
   |       | sent      |     |        |      |        |       |        |
   |   100 | RTP       | "0" |    400 |    2 | 400    | 852   | 1477   |
   |       | packet 2  |     |        |      |        |       |        |
   |       | sent      |     |        |      |        |       |        |
   |   ... | ...       | ... |    ... |  ... | ...    | ...   | ...    |
   |   200 | RTP       | "0" |   1200 |    4 | 400    | 852   | 1477   |
   |       | packet 4  |     |        |      |        |       |        |
   |       | sent      |     |        |      |        |       |        |
   |   200 | "9" ends  |     |        |      |        |       |        |
   |   880 | First "1" |     |        |      |        |       |        |
   |       | starts    |     |        |      |        |       |        |
   |   930 | RTP       | "1" |   7040 |    5 | 400    | 697   | 1209   |
   |       | packet 5  |     |        |      |        |       |        |
   |       | sent      |     |        |      |        |       |        |
   |   980 | RTP       | "0" |   7440 |    6 | 400    | 697   | 1209   |
   |       | packet 6  |     |        |      |        |       |        |
   |       | sent      |     |        |      |        |       |        |
   |   ... | ...       | ... |    ... |  ... | ...    | ...   | ...    |
   |  1130 | First "1" |     |        |      |        |       |        |
   |       | ends      |     |        |      |        |       |        |
   |  1400 | Second    |     |        |      |        |       |        |
   |       | "1"       |     |        |      |        |       |        |
   |       | starts    |     |        |      |        |       |        |
   |  1450 | RTP       | "1" |  11200 |   10 | 400    | 697   | 1209   |
   |       | packet 10 |     |        |      |        |       |        |
   |       | sent      |     |        |      |        |       |        |
   |   ... | ...       | ... |    ... |  ... | ...    | ...   | ...    |
   |  1620 | Second    |     |        |      |        |       |        |
   |       | "1" ends  |     |        |      |        |       |        |
   |  1650 | RTP       | "0" |  12800 |   14 | 160    | 697   | 1209   |
   |       | packet 14 |     |        |      |        |       |        |
   |       | sent      |     |        |      |        |       |        |
   +-------+-----------+-----+--------+------+--------+-------+--------+
                    Table 6: Example of Tone Reporting

Top      Up      ToC       Page 34 
   Now consider a combined payload, where the tone payload is the
   primary payload type and the event payload is treated as a redundant
   encoding (one level of redundancy).  Because the primary payload is
   tones, the tone payload rules determine the setting of the RTP header
   fields.  This means that the RTP timestamp always advances.  As a
   corollary, the timestamp offset for the events payload in the RFC
   2198 header increases by the same amount.

   One issue that has to be considered in a combined payload is how to
   handle retransmissions of final event reports.  The tone payload
   specification does not recommend retransmissions of final packets, so
   it is unclear what to put in the primary payload fields of the
   combined packet.  In the interests of simplicity, it is suggested
   that the retransmitted packets copy the fields relating to the
   primary payload (including the RTP timestamp) from the original
   packet.  The same principle can be applied if the packet includes
   multiple levels of event payload redundancy.

   The figures below all illustrate "RTP packet 14" in the above tables.
   Figure 3 shows an event-only payload, corresponding to Table 5.
   Figure 4 shows a tone-only payload, corresponding to Table 6.
   Finally, Figure 5 shows a combined payload, with tones primary and
   events as a single redundant layer.  Note that the combined payload
   has the RTP sequence numbers shown in Table 5, because the
   transmitted sequence includes the retransmitted packets.

   Figure 3 assumes that the following SDP specification was used.  This
   session description provides for separate streams of G.729 [21] audio
   and events.  Packets reported within the G.729 stream are not
   considered here.

      m=audio 12344 RTP/AVP 99
      a=rtpmap:99 G729/8000
      a=ptime:20
      m=audio 12346 RTP/AVP 100
      a=rtpmap:100 telephone-event/8000
      a=fmtp:100 0-15
      a=ptime:50

Top      Up      ToC       Page 35 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      | 2 |0|0|   0   |0|    100      |            18                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      |                             11200                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      |                            0x5234a8                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     event     |E R| volume    |          duration             |
      |       1       |1 0|    20     |             1760              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: Example RTP Packet for Event Payload

   Figure 4 assumes that an SDP specification similar to that of the
   previous case was used.

      m=audio 12344 RTP/AVP 99
      a=rtpmap:99 G729/8000
      a=ptime:20
      m=audio 12346 RTP/AVP 101
      a=rtpmap:101 tone/8000
      a=ptime:50

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      | 2 |0|0|   0   |0|    101      |             14                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      |                             12800                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      |                            0x5234a8                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    modulation   |T|  volume   |          duration             |
      |        0        |0|    20     |             160               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R R R R|       frequency       |R R R R|       frequency       |
      |0 0 0 0|          697          |0 0 0 0|         1209          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: Example RTP Packet for Tone Payload

Top      Up      ToC       Page 36 
   Figure 5, for the combined payload, assumes the following SDP session
   description:

      m=audio 12344 RTP/AVP 99
      a=rtpmap:99 G729/8000
      a=ptime:20
      m=audio 12346 RTP/AVP 102 101 100
      a=rtpmap:102 red/8000/1
      a=fmtp:102 101/100
      a=rtpmap:101 tone/8000
      a=rtpmap:100 telephone-event/8000
      a=fmtp:100 0-15
      a=ptime:50

   For ease of presentation, Figure 5 presents the actual payloads as if
   they began on 32-bit boundaries.  In the actual packet, they follow
   immediately after the end of the RFC 2198 header, and thus are
   displaced one octet into successive words.

Top      Up      ToC       Page 37 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      | 2 |0|0|   0   |0|    102      |             18                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      |                             12800                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      |                            0x5234a8                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|   block PT  |  timestamp offset         |   block length    |
      |1|      100    |       1600                |        4          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|   block PT  |   event payload begins ...                    /
      |0|      101    |                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Event payload

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     event     |E R| volume    |          duration             |
      |       1       |1 0|    20     |             1760              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Tone payload

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    modulation   |T|  volume   |          duration             |
      |        0        |0|    20     |             160               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R R R R|       frequency       |R R R R|       frequency       |
      |0 0 0 0|          697          |0 0 0 0|         1209          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5: Example RTP Packet for Combined Tone and Event Payloads

Top      Up      ToC       Page 38 
6.  Security Considerations

   RTP packets using the payload formats defined in this specification
   are subject to the security considerations discussed in the RTP
   specification (RFC 3550 [5]), and any appropriate RTP profile (for
   example, RFC 3551 [13]).  The RFC 3550 discussion focuses on
   requirements for confidentiality.  Additional security considerations
   relating to implementation are described in RFC 2198 [2].

   The telephone-event payload defined in this specification is highly
   compressed.  A change in value of just one bit can result in a major
   change in meaning as decoded at the receiver.  Thus, message
   integrity MUST be provided for the telephone-event payload type.

   To meet the need for protection both of confidentiality and
   integrity, compliant implementations SHOULD implement the Secure
   Real-time Transport Protocol (SRTP) [7].

      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.

   Provided that gateway design includes robust, low-overhead tone
   generation, this payload type does not exhibit any significant non-
   uniformity in the receiver side computational complexity for packet
   processing to cause a potential denial-of-service threat.

7.  IANA Considerations

   This document updates the descriptions of two RTP payload formats,
   'telephone-event' and 'tone', and associated Internet media types,
   audio/telephone-event and audio/tone.  It also documents the event
   codes for DTMF tone events.

   Within the audio/telephone-event type, events MUST be registered with
   IANA.  Registrations are subject to the policies "Specification
   Required" and "Expert Review" as defined in RFC 2434 [3].  The IETF-
   appointed expert must ensure that:

   a.  the meaning and application of the proposed events are clearly
       documented;

   b.  the events cannot be represented by existing event codes,
       possibly with some minor modification of event definitions;

Top      Up      ToC       Page 39 
   c.  the number of events is the minimum necessary to fulfill the
       purpose of their application(s).

   The expert is further responsible for providing guidance on the
   allocation of event codes to the proposed events.  Specifically, the
   expert must indicate whether the event appears to be the same as one
   defined in RFC 2833 but not specified in any new document.  In this
   case, the event code specified in RFC 2833 for that event SHOULD be
   assigned to the proposed event.  Otherwise, event codes MUST be
   assigned from the set of available event codes listed below.  If this
   set is exhausted, the criterion for assignment from the reserved set
   of event codes is to first assign those that appear to have the
   lowest probability of being revived in their RFC 2833 meaning in a
   new specification.

   The documentation for each event MUST indicate whether the event is a
   state, tone, or other type of event (e.g., an out-of-band electrical
   event such as on-hook or an indication that will not itself be played
   out as tones at the receiving end).  For tone events, the
   documentation MUST indicate whether the volume field is applicable or
   must be set to 0.

   In view of the tradeoffs between the different reliability mechanisms
   discussed in Section 2.6, documentation of specific events SHOULD
   include a discussion of the appropriate design decisions for the
   applications of those events.

   Legal event codes range from 0 to 255.  The initial registry content
   is shown in Table 7, and consists of the sixteen events defined in
   Section 3 of this document.  The remaining codes have the following
   disposition:

   o  codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available
      for assignment;

   o  codes 23-40, 49, and 52-63 are reserved for events defined in
      [16];

   o  codes 121-137 and 174-205 are reserved for events defined in [17];

   o  codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved
      in the first instance for specifications reviving the
      corresponding RFC 2833 events, and in the second instance for
      general assignment after all other codes have been assigned.

Top      Up      ToC       Page 40 
        +------------+--------------------------------+-----------+
        | Event Code | Event Name                     | Reference |
        +------------+--------------------------------+-----------+
        |          0 | DTMF digit "0"                 |  RFC 4733 |
        |          1 | DTMF digit "1"                 |  RFC 4733 |
        |          2 | DTMF digit "2"                 |  RFC 4733 |
        |          3 | DTMF digit "3"                 |  RFC 4733 |
        |          4 | DTMF digit "4"                 |  RFC 4733 |
        |          5 | DTMF digit "5"                 |  RFC 4733 |
        |          6 | DTMF digit "6"                 |  RFC 4733 |
        |          7 | DTMF digit "7"                 |  RFC 4733 |
        |          8 | DTMF digit "8"                 |  RFC 4733 |
        |          9 | DTMF digit "9"                 |  RFC 4733 |
        |         10 | DTMF digit "*"                 |  RFC 4733 |
        |         11 | DTMF digit "#"                 |  RFC 4733 |
        |         12 | DTMF digit "A"                 |  RFC 4733 |
        |         13 | DTMF digit "B"                 |  RFC 4733 |
        |         14 | DTMF digit "C"                 |  RFC 4733 |
        |         15 | DTMF digit "D"                 |  RFC 4733 |
        +------------+--------------------------------+-----------+

            Table 7: audio/telephone-event Event Code Registry

7.1.  Media Type Registrations

7.1.1.  Registration of Media Type audio/telephone-event

   This registration is done in accordance with [6] and [8].

   Type name: audio

   Subtype name: telephone-event

   Required parameters: none.

   Optional parameters:

      The "events" parameter lists the events supported by the
      implementation.  Events are listed as one or more comma-separated
      elements.  Each element can be either a single integer providing
      the value of an event code or an integer followed by a hyphen and
      a larger integer, presenting a range of consecutive event code
      values.  The list does not have to be sorted.  No white space is
      allowed in the argument.  The union of all of the individual event
      codes and event code ranges designates the complete set of event
      numbers supported by the implementation.  If the "events"
      parameter is omitted, support for events 0-15 (the DTMF tones) is
      assumed.

Top      Up      ToC       Page 41 
      The "rate" parameter describes the sampling rate, in Hertz.  The
      number is written as an integer.  If omitted, the default value is
      8000 Hz.

   Encoding considerations:

      In the terminology defined by [8] section 4.8, this type is framed
      and binary.

   Security considerations:

      See Section 6, "Security Considerations", in this document.

   Interoperability considerations: none.

   Published specification: this document.

   Applications which use this media:

      The telephone-event audio subtype supports the transport of events
      occurring in telephone systems over the Internet.

   Additional information:

      Magic number(s): N/A.
      File extension(s): N/A.
      Macintosh file type code(s): N/A.

   Person & email address to contact for further information:

      Tom Taylor, taylor@nortel.com.
      IETF AVT Working Group.

   Intended usage: COMMON.

   Restrictions on usage:

      This type is defined only for transfer via RTP [5].

   Author: IETF Audio/Video Transport Working Group.

   Change controller:

      IETF Audio/Video Transport Working Group as delegated from the
      IESG.

Top      Up      ToC       Page 42 
7.1.2.  Registration of Media Type audio/tone

   This registration is done in accordance with [6] and [8].

   Type name: audio

   Subtype name: tone

   Required parameters: none

   Optional parameters:

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

   Encoding considerations:

      In the terminology defined by [8] section 4.8, this type is framed
      and binary.

   Security considerations:

      See Section 6, "Security Considerations", in this document.

   Interoperability considerations: none

   Published specification: this document.

   Applications which use this media:

      The tone audio subtype supports the transport of pure composite
      tones, for example, those commonly used in the current telephone
      system to signal call progress.

   Additional information:

      Magic number(s): N/A.
      File extension(s): N/A.
      Macintosh file type code(s): N/A.

   Person & email address to contact for further information:

      Tom Taylor, taylor@nortel.com.
      IETF AVT Working Group.

   Intended usage: COMMON.

Top      Up      ToC       Page 43 
   Restrictions on usage:

      This type is defined only for transfer via RTP [5].

   Author: IETF Audio/Video Transport Working Group.

   Change controller:

      IETF Audio/Video Transport Working Group as delegated from the
      IESG.

8.  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.

   In RFC 2833, the suggestions of the Megaco working group were
   acknowledged.  Colin Perkins and Magnus Westerland, Chairs of the AVT
   Working Group, provided helpful advice in the formation of the
   present document.  Over the years, detailed advice and comments for
   RFC 2833, this document, or both were provided by Hisham Abdelhamid,
   Flemming Andreasen, Fred Burg, Steve Casner, Dan Deliberato, Fatih
   Erdin, Bill Foster, Mike Fox, Mehryar Garakani, Gunnar Hellstrom,
   Rajesh Kumar, Terry Lyons, Steve Magnell, Zarko Markov, Tim
   Melanchuk, Kai Miao, Satish Mundra, Kevin Noll, Vern Paxson, Oren
   Peleg, Raghavendra Prabhu, Moshe Samoha, Todd Sherer, Adrian Soncodi,
   Yaakov Stein, Mira Stevanovic, Alex Urquizo, and Herb Wildfeur.

9.  References

9.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]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

   [4]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

Top      Up      ToC       Page 44 
   [5]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [6]   Casner, S. and P. Hoschka, "MIME Type Registration of RTP
         Payload Formats", RFC 3555, July 2003.

   [7]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

   [8]   Freed, N. and J. Klensin, "Media Type Specifications and
         Registration Procedures", BCP 13, RFC 4288, December 2005.

   [9]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", RFC 4566, July 2006.

   [10]  International Telecommunication Union, "Technical features of
         push-button telephone sets", ITU-T Recommendation Q.23,
         November 1988.

   [11]  International Telecommunication Union, "Multifrequency push-
         button signal reception", ITU-T Recommendation Q.24,
         November 1988.

9.2.  Informative References

   [12]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
         Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [13]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
         Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

   [14]  Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent
         Call", RFC 4040, April 2005.

   [15]  Hellstrom, G. and P. Jones, "RTP Payload for Text
         Conversation", RFC 4103, June 2005.

   [16]  Schulzrinne, H. and T. Taylor, "Definition of Events for Modem,
         Fax, and Text Telephony Signals", RFC 4734, December 2006.

   [17]  Schulzrinne, H. and T. Taylor, "Definition of Events For
         Channel-Oriented Telephony Signalling", Work In Progress ,
         November 2005.

Top      Up      ToC       Page 45 
   [18]  International Telecommunication Union, "Technical
         characteristics of tones for the telephone service", ITU-T
         Recommendation E.180/Q.35, March 1998.

   [19]  International Telecommunication Union, "Pulse code modulation
         (PCM) of voice frequencies", ITU-T Recommendation G.711,
         November 1988.

   [20]  International Telecommunication Union, "Speech coders : Dual
         rate speech coder for multimedia communications transmitting at
         5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996.

   [21]  International Telecommunication Union, "Coding of speech at 8
         kbit/s using conjugate-structure algebraic-code-excited linear-
         prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.

   [22]  International Telecommunication Union, "ISDN user-network
         interface layer 3 specification for basic call control", ITU-T
         Recommendation Q.931, May 1998.

   [23]  International Telecommunication Union, "Procedures for real-
         time Group 3 facsimile communication over IP networks", ITU-T
         Recommendation T.38, July 2003.

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

   [25]  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.

   [26]  International Telecommunication Union, "Procedures for
         supporting Voice-Band Data over IP Networks", ITU-T
         Recommendation V.152, January 2005.

   [27]  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.
   [28]  VOIP Troubleshooter LLC, "Indepth: Packet Loss Burstiness",
         2005,
         <http://www.voiptroubleshooter.com/indepth/burstloss.html>.

Top      Up      ToC       Page 46 
Appendix A.  Summary of Changes from RFC 2833

   The memo has been significantly restructured, incorporating a large
   number of clarifications to the specification.  With the exception of
   those items noted below, the changes to the memo are intended to be
   backwards-compatible clarifications.  However, due to inconsistencies
   and unclear definitions in RFC 2833 [12] it is likely that some
   implementations interpreted that memo in ways that differ from this
   version.

   RFC 2833 required that all implementations be capable of receiving
   the DTMF events (event codes 0-15).  Section 2.5.1.1 of the present
   document requires that a sender transmit only the events that the
   receiver is capable of receiving.  In the absence of a knowledge of
   receiver capabilities, the sender SHOULD assume support of the DTMF
   events but of no other events.  The sender SHOULD indicate what
   events it can send.  Section 2.5.2.1 requires that a receiver
   signalling its capabilities using SDP MUST indicate which events it
   can receive.

   Non-zero values in the volume field of the payload were applicable
   only to DTMF tones in RFC 2833, and for other events the receiver was
   required to ignore them.  The present memo requires that the
   definition of each event indicate whether the volume field is
   applicable to that event.  The last paragraph of Section 2.5.2.2
   indicates what a receiver may do if it receives volumes with zero
   values for events to which the volume field is applicable.  Along
   with the RFC 2833 receiver rule, this ensures backward compatibility
   in both directions of transmission.

   Section 2.5.1.3 and Section 2.5.2.3 introduce a new procedure for
   reporting and playing out events whose duration exceeds the capacity
   of the payload duration field.  This procedure may cause momentary
   confusion at an old (RFC 2833) receiver, because the timestamp is
   updated without setting the E bit of the preceding event report and
   without setting the M bit of the new one.

   Section 2.5.1.5 and Section 2.5.2.4 introduce a new procedure whereby
   a sequence of short-duration events may be packed into a single event
   report.  If an old (RFC 2833) receiver receives such a report, it may
   discard the packet as invalid, since the packet holds more content
   than the receiver was expecting.  In any event, the additional events
   in the packet will be lost.

Top      Up      ToC       Page 47 
   Section 2.3.5 introduces the possibility of "state" events and
   defines procedures for setting the duration field for reports of such
   events.  Section 2.5.1.2 defines special exemptions from the setting
   of the E bit for state events.  Three more sections mention
   procedures related to these events.

   The Security Considerations section is updated to mention the
   requirement for protection of integrity.  More importantly, it makes
   implementation of SRTP [7] mandatory for compliant implementations,
   without specifying a mandatory-to-implement method of key
   distribution.

   Finally, this document establishes an IANA registry for event codes
   and establishes criteria for their documentation.  This document
   provides an initial population for the new registry, consisting
   solely of the sixteen DTMF events.  Two companion documents [16] and
   [17] describe events related to modems, fax, and text telephony and
   to channel-associated telephony signalling, respectively.  Some
   changes were made to the latter because of errors and redundancies in
   the RFC 2833 assignments.  The remaining events defined in RFC 2833
   are deprecated because they do not appear to have been implemented,
   but their codes have been conditionally reserved in case any of them
   is needed in the future.  Table 8 indicates the disposition of the
   event codes in detail.  Event codes not mentioned in this table were
   not allocated by RFC 2833 and continue to be unused.

   +-------------+---------------------------------------+-------------+
   | Event Codes | RFC 2833 Description                  | Disposition |
   +-------------+---------------------------------------+-------------+
   |        0-15 | DTMF digits                           | RFC 4733    |
   |          16 | Line flash (deprecated)               | Reserved    |
   |       23-31 | Unused                                | [16]        |
   |       32-40 | Data and fax                          | [16]        |
   |       41-48 | Data and fax (V.8bis, deprecated)     | Reserved    |
   |       52-63 | Unused                                | [16]        |
   |       64-89 | E.182 line events (deprecated)        | Reserved    |
   |      96-112 | Country-specific line events          | Reserved    |
   |             | (deprecated)                          |             |
   |     121-127 | Unused                                | [17]        |
   |     128-137 | Trunks: MF 0-9                        | [17]        |
   |     138-143 | Trunks: other MF (deprecated)         | Reserved    |
   |     144-159 | Trunks: ABCD signalling               | [17]        |
   |     160-168 | Trunks: various (deprecated)          | Reserved    |
   |     170-173 | Trunks: various (deprecated)          | Reserved    |
   |     174-205 | Unused                                | [17]        |
   +-------------+---------------------------------------+-------------+

           Table 8: Disposition of RFC 2833-defined Event Codes

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