rtpatransportprotocolforrealtimeapplicationsWord文件下载.docx

1、 improvements. Please refer to the current edition of the Internet Official Protocol Standards （STD 1） for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end n

2、etwork transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is au

3、gmented by a control protocol （RTCP） to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol su

4、pports the use of RTP-level translators and mixers.Table of Contents 1. Introduction . 3 2. RTP Use Scenarios . 5 2.1 Simple Multicast Audio Conference . 5 2.2 Audio and Video Conference . 6 2.3 Mixers and Translators . 6 3. Definitions . 7 4. Byte Order, Alignment, and Time Format . 9 5. RTP Data T

5、ransfer Protocol . 10 5.1 RTP Fixed Header Fields . 10 5.2 Multiplexing RTP Sessions . 13Schulzrinne, et al Standards Track Page 1RFC 1889 RTP January 1996 5.3 Profile-Specific Modifications to the RTP Header. 14 5.3.1 RTP Header Extension . 14 6. RTP Control Protocol - RTCP . 15 6.1 RTCP Packet For

6、mat . 17 6.2 RTCP Transmission Interval . 19 6.2.1 Maintaining the number of session members . 21 6.2.2 Allocation of source description bandwidth . 21 6.3 Sender and Receiver Reports . 22 6.3.1 SR: Sender report RTCP packet . 23 6.3.2 RR: Receiver report RTCP packet . 28 6.3.3 Extending the sender

7、and receiver reports . 29 6.3.4 Analyzing sender and receiver reports . 29 6.4 SDES: Source description RTCP packet . 31 6.4.1 CNAME: Canonical end-point identifier SDES item . 32 6.4.2 NAME: User name SDES item . 34 6.4.3 EMAIL: Electronic mail address SDES item . 34 6.4.4 PHONE: Phone number SDES

8、item . 34 6.4.5 LOC: Geographic user location SDES item . 35 6.4.6 TOOL: Application or tool name SDES item . 35 6.4.7 NOTE: Notice/status SDES item . 35 6.4.8 PRIV: Private extensions SDES item . 36 6.5 BYE: Goodbye RTCP packet . 37 6.6 APP: Application-defined RTCP packet . 38 7. RTP Translators a

9、nd Mixers . 39 7.1 General Description . 39 7.2 RTCP Processing in Translators . 41 7.3 RTCP Processing in Mixers . 43 7.4 Cascaded Mixers . 44 8. SSRC Identifier Allocation and Use . 44 8.1 Probability of Collision . 44 8.2 Collision Resolution and Loop Detection . 45 9. Security . 49 9.1 Confident

10、iality . 49 9.2 Authentication and Message Integrity . 50 10. RTP over Network and Transport Protocols . 51 11. Summary of Protocol Constants . 51 11.1 RTCP packet types . 52 11.2 SDES types . 52 12. RTP Profiles and Payload Format Specifications . 53 A. Algorithms . 56 A.1 RTP Data Header Validity

11、Checks . 59 A.2 RTCP Header Validity Checks . 63 A.3 Determining the Number of RTP Packets Expected and Lost . 63 A.4 Generating SDES RTCP Packets . 64 A.5 Parsing RTCP SDES Packets . 65 A.6 Generating a Random 32-bit Identifier . 66 A.7 Computing the RTCP Transmission Interval . 68Schulzrinne, et a

12、l Standards Track Page 2RFC 1889 RTP January 1996 A.8 Estimating the Interarrival Jitter . 71 B. Security Considerations . 72 C. Addresses of Authors . 72 D. Bibliography . 731. Introduction This memorandum specifies the real-time transport protocol （RTP）, which provides end-to-end delivery services

13、 for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, timestamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protoc

14、ols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols （see Section 10）. RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network. Note that RTP

15、 itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packe

16、ts in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the senders packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence. While RTP is prim

17、arily designed to satisfy the needs of multi- participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable. This document defin

18、es RTP, consisting of two closely-linked parts: o the real-time transport protocol （RTP）, to carry data that has real-time properties. o the RTP control protocol （RTCP）, to monitor the quality of service and to convey information about the participants in an on-going session. The latter aspect of RT

19、CP may be sufficient for loosely controlled sessions, i.e., where there is no explicit membership control and set-up, but it is not necessarily intended to support all of an applications control communication requirements. This functionality may be fully or partially subsumed by a separate session c

20、ontrol protocol,Schulzrinne, et al Standards Track Page 3RFC 1889 RTP January 1996 which is beyond the scope of this document. RTP represents a new style of protocol following the principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse 1. That is, RT

21、P is intended to be malleable to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer. RTP is a protocol framework that is deliberately not complete. This document specifies those f

22、unctions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tail

23、ored through modifications and/or additions to the headers as needed. Examples are given in Sections 5.3 and 6.3.3. Therefore, in addition to this document, a complete specification of RTP for a particular application will require one or more companion documents （see Section 12）: o a profile specifi

24、cation document, which defines a set of payload type codes and their mapping to payload formats （e.g., media encodings）. A profile may also define extensions or modifications to RTP that are specific to a particular class of applications. Typically an application will operate under only one profile.

25、 A profile for audio and video data may be found in the companion RFC TBD. o payload format specification documents, which define how a particular payload, such as an audio or video encoding, is to be carried in RTP. A discussion of real-time services and algorithms for their implementation as well as background discussion on some of the RTP design decisions can be found in 2. Several RTP applications, both experimental and commercial, have already been implemented from draft specifications. These