rfc2833.txt

RFC 的详细文档！

Schulzrinne & Petrack       Standards Track                    [Page 22]

RFC 2833                         Tones                          May 2000


           which exceeds the range of telephone systems. A value of zero
           indicates silence. A single tone can contain any number of
           frequencies.

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

4.5 Reliability

   This payload format uses the reliability mechanism described in
   Section 3.7.

5 Combining Tones and Named Events

   The payload formats in Sections 3 and 4 can be combined into a single
   payload using the method specified in RFC 2198. Fig. 4 shows an
   example. In that example, the RTP packet combines two "tone" and one
   "telephone-event" payloads.  The payload types are chosen arbitrarily
   as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the
   redundancy format has the dynamic payload type 96.

   The packet represents a snapshot of U.S. ringing tone, 1.5 seconds
   (12,000 timestamp units) into the second "on" part of the 2.0/4.0
   second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units)
   into the ring cycle. The 440 + 480 Hz tone of this second cadence
   started at RTP timestamp 48,000. Four seconds of silence preceded it,
   but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds
   (16383 timestamp units) can be represented. Even though the tone
   sequence is not complete, the sender was able to determine that this
   is indeed ringback, and thus includes the corresponding named event.

6 MIME Registration

6.1 audio/telephone-event

      MIME media type name: audio

      MIME subtype name: telephone-event

      Required parameters: none.











Schulzrinne & Petrack       Standards Track                    [Page 23]

RFC 2833                         Tones                          May 2000


     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 |P|X|  CC   |M|     PT      |       sequence number         |
    | 2 |0|0|   0   |0|     96      |              31               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           timestamp                           |
    |                             48000                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           synchronization source (SSRC) identifier            |
    |                            0x5234a8                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|   block PT  |     timestamp offset      |   block length    |
    |1|     98      |            16383          |         4         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|   block PT  |     timestamp offset      |   block length    |
    |1|     97      |            16383          |         8         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|   Block PT  |
    |0|     97      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  event=ring   |0|0| volume=0  |     duration=28383            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | modulation=0    |0| volume=63 |     duration=16383            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0|     frequency=0       |0 0 0 0|    frequency=0        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | modulation=0    |0| volume=5  |     duration=12000            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0|     frequency=440     |0 0 0 0|    frequency=480      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4: Combining tones and events in a single RTP packet

      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 either be a
           single integer or two integers separated by a hyphen.  No
           white space is allowed in the argument. The integers
           designate the event numbers supported by the implementation.
           All implementations MUST support events 0 through 15, so that
           the parameter can be omitted if the implementation only
           supports these events.




Schulzrinne & Petrack       Standards Track                    [Page 24]

RFC 2833                         Tones                          May 2000


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

      Encoding considerations: This type is only defined for transfer
           via RTP [1].

      Security considerations: See the "Security Considerations"
           (Section 7) section 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:

           1. Magic number(s): N/A

           2. File extension(s): N/A

           3. Macintosh file type code: N/A

6.2 audio/tone

      MIME media type name: audio

      MIME subtype name: tone

      Required parameters: none

      Optional parameters: The "rate" parameter describes the sampling
           rate, in Hertz. The number is written as a floating point
           number or as an integer. If omitted, the default value is
           8000 Hz.

      Encoding considerations: This type is only defined for transfer
           via RTP [1].

      Security considerations: See the "Security Considerations"
           (Section 7) section in this document.

      Interoperability considerations: none

      Published specification: This document.



Schulzrinne & Petrack       Standards Track                    [Page 25]

RFC 2833                         Tones                          May 2000


      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:

           1. Magic number(s): N/A

           2. File extension(s): N/A

           3. Macintosh file type code: N/A

7 Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification (RFC 1889 [1]), and any appropriate RTP profile (for
   example RFC 1890 [19]).This implies that confidentiality of the media
   streams is achieved by encryption. Because the data compression used
   with this payload format is applied end-to-end, encryption may be
   performed after compression so there is no conflict between the two
   operations.

   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.

   In older networks employing in-band signaling and lacking appropriate
   tone filters, the tones in Section 3.14 may be used to commit toll
   fraud.

   Additional security considerations are described in RFC 2198 [6].

8 IANA Considerations

   This document defines two new RTP payload formats, named telephone-
   event and tone, and associated Internet media (MIME) types,
   audio/telephone-event and audio/tone.

   Within the audio/telephone-event type, additional events MUST be
   registered with IANA. Registrations are subject to approval by the
   current chair of the IETF audio/video transport working group, or by
   an expert designated by the transport area director if the AVT group
   has closed.






Schulzrinne & Petrack       Standards Track                    [Page 26]

RFC 2833                         Tones                          May 2000


   The meaning of new events MUST be documented either as an RFC or an
   equivalent standards document produced by another standardization
   body, such as ITU-T.

9 Acknowledgements

   The suggestions of the Megaco working group are gratefully
   acknowledged.  Detailed advice and comments were provided by Fred
   Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar
   Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins.

10 Authors' Addresses

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA

   EMail:  [e-mail]


   Scott Petrack
   MetaTel
   45 Rumford Avenue
   Waltham, MA 02453
   USA

   EMail:  [e-mail]

11 Bibliography

   [1]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP:  A Transport Protocol for Real-Time Applications", RFC
        1889, January 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  International Telecommunication Union, "Procedures for starting
        sessions of data transmission over the public switched telephone
        network," Recommendation V.8, Telecommunication Standardization
        Sector of ITU, Geneva, Switzerland, Feb. 1998.

   [4]  R. Kocen and T. Hatala, "Voice over frame relay implementation
        agreement", Implementation Agreement FRF.11, Frame Relay Forum,
        Foster City, California, Jan. 1997.



Schulzrinne & Petrack       Standards Track                    [Page 27]

RFC 2833                         Tones                          May 2000


   [5]  International Telecommunication Union, "Multifrequency push-
        button signal reception," Recommendation Q.24, Telecommunication
        Standardization Sector of ITU, Geneva, Switzerland, 1988.

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

   [7]  Handley M. and V. Jacobson, "SDP: Session Description Protocol",
        RFC 2327, April 1998.

   [8]  International Telecommunication Union, "Automatic answering
        equipment and general procedures for automatic calling equipment
        on the general switched telephone network including procedures
        for disabling of echo control devices for both manually and
        automatically established calls," Recommendation V.25,
        Telecommunication Standardization Sector of ITU, Geneva,
        Switzerland, Oct. 199