Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4733

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

Pages: 49
Proposed Standard
Errata
Obsoletes:  2833
Updated by:  47345244
Part 2 of 2 – Pages 23 to 49
First   Prev   None

Top   ToC   RFC4733 - Page 23   prevText

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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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   ToC   RFC4733 - 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.