1、附录 英文原文资料 RTP: A Transport Protocol for Real-Time Applications 1 Introduction This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload typ
2、e identification, sequence numbering, times tamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services； both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable under
3、lying 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 itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees,
4、 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 packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the senders packet sequen
5、ce, 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 primarily designed to satisfy the needs of multi- participant multimedia conferences, it is not limited to that part
6、icular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable. This document defines RTP, consisting of two closely-linked parts: 1.The real-time transport protocol (RTP), to carry data that has
7、 real-time properties. 2. 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 RTCP may be sufficient for loosely controlled sessions, i.e., where there is no explicit membership control and s
8、et-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 control protocol, which is beyond the scope of this document. RTP represents a new style of protocol following t
9、he principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse 1. That is, RTP 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 impl
10、emented as a separate layer. RTP is a protocol framework that is deliberately not complete. This document specifies those functions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated
11、by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored 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 specifica
12、tion of RTP for a particular application will require one or more companion documents (see Section 12): 1.A profile specification 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
13、 RTP that are specific to a particular class of applications. Typically an application will operate under only one profile. A profile for audio and video data may be found in the companion RFC TBD. 2.Payload format specification documents, which define how a particular payload, such as an audio or v
14、ideo 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 dr
15、aft specifications. These applications include audio and video tools along with diagnostic tools such as traffic monitors. Users of these tools number in the thousands. However, the current Internet cannot yet support the full potential demand for real-time services. High-bandwidth services using RT
16、P, such as video, can potentially seriously degrade the quality of service of other network services. Thus, implementors should take appropriate precautions to limit accidental bandwidth usage. Application documentation should clearly outline the limitations and possible operational impact of high-b
17、andwidth real- time services on the Internet and other network services. 2 RTP Use Scenarios The following sections describe some aspects of the use of RTP. The examples were chosen to illustrate the basic operation of applications using RTP, not to limit what RTP may be used for. In these examples,
18、 RTP is carried on top of IP and UDP, and follows the conventions established by the profile for audio and video specified in the companion Internet-Draft draft-ietf-avt-profile 2.1 Simple Multicast Audio Conference A working group of the IETF meets to discuss the latest protocol draft, using the IP
19、 multicast services of the Internet for voice communications. Through some allocation mechanism the working group chair obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distrib
20、uted to the intended participants. If privacy is desired, the data and control packets may be encrypted as specified in Section 9.1, in which case an encryption key must also be generated and distributed. The exact details of these allocation and distribution mechanisms are beyond the scope of RTP.
21、The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. Each chunk of audio data is preceded by an RTP header； RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding (suc
22、h as PCM, ADPCM or LPC) is contained in each packet so that senders can change the encoding during a conference, for example, to accommodate a new participant that is connected through a low-bandwidth link or react to indications of network congestion. The Internet, like other packet networks, occasionally loses and reorders packets and delays them by variable amounts of time. To cope with these impairments, the RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source, so that in this example,
