rtp實(shí)時(shí)軟件傳輸協(xié)議

1、1 / 21RTP: A Tran sportProtocol for Real-TimeApplicati ons1 In troducti onThis memora ndum specifiesthe real-timetran sportprotocol(RTP),which providesen d-to-e nd deliveryservices for data withreal-time characteristics, such as in teractive audio andvideo. Those services include payload type identi

2、fication,sequenee numbering, timestamping and delivery monitoring. Applications typically runRTP on top of UDP to make use of its multiplexing andchecksum services; both protocolscon tribute parts ofthe tran sportprotocolfun cti on ality.However, RTP may beused with other suitable underlying network

3、 or tran sportprotocols (seeSecti on10). RTPsupports data transfer to multiple destinations usingmulticastdistributionif provided by theun derly ing n etwork.2 / 21Note that RTP itself does not provide anymechanism to ensure timely delivery or provide otherquality-of-service guarantees, but relies o

4、n lower-layerservices to do so. It does not guarantee delivery orprevent out-of-order delivery, nor does it assume that theunderlying network is reliable and delivers packets insequence. The sequence numbers included in RTP allowthe receiver to reconstruct the senders packet sequence,but sequence nu

5、mbers might also be used to determinethe proper location of a packet, for example in videodecoding, without necessarily decoding packets insequence.While RTP is primarily designed to satisfy the needsof multi- participant multimedia conferences, it is notlimited to that particular application. Stora

6、ge of continuousdata, interactive distributed simulation, active badge, andcontrol and measurement applications may also find RTPapplicable.This document defines RTP, consisting oftwo closely-linked parts:1. The real-time transport protocol (RTP), to carry data3 / 21that has real-time properties.2.

7、The RTPcontrol protocol (RTCP), to monitor thequality of service and to convey information about theparticipants in an on-going session.The latteraspect of RTCPmay be sufficientforlooselycontrolledsessions,i.e.,wherethere isno explicitmembership controlandset-up, but it is not necessarily intended t

8、o support all ofan applications control communication requirements.This functionality may be fully or partially subsumed by aseparate session control protocol, which is beyond thescope of this document.RTP represents a new style of protocol following theprinciples of application level framing and in

9、tegrated layerprocessing proposed by Clark and Tennenhouse 1. Thatis, RTP is intended to be malleable to provide theinformation required by a particular application and willoften be integrated into the application processing ratherthan being implemented as a separate layer. RTP is aprotocol framewor

10、k that is deliberately not complete. This4 / 21document specifies those functions expected to becommon across all the applications for which RTPwouldbe appropriate. Unlike conventional protocols in whichadditional functions might be accommodated by makingthe protocol more general or by adding an opt

11、ionmechanism that would require parsing, RTP is intended tobe tailored through modifications and/or additions to theheaders as needed. Examples are given in Sections 5.3and 6.3.3.Therefore, in addition to this document, a completespecification of RTP for a particularapplicati on will require one or

12、more compa niondocuments (see Section 12 ):1 . A profile specification document, which defi nes a setof payload type codes and theirmapp ing to payload formats (e.g., media en cod in gs).Aprofile may also defi neextensions or modifications to RTP that are specific to aparticular class of application

13、s. Typically an applicationwill operateunder5 / 21only one profile. A profile for audio and video data may befound in the companion RFC TBD.2 . Payload format specification documents, which define how a particular payload, such asan audio or video en cod in g, is to be carried in RTP.A discussionof

14、real-time services andalgorithms for their implementation as well as backgrounddiscussionon some of the RTPdesigndecisi ons can be found in 2.Several RTP applicati ons,bothexperimental and commercial, have alreadybeenimplemented from draft specifications. These applicationsinclude audio and video to

15、ols along with diagnostic toolssuch as traffic monitors. Users of these tools number inthe thousands. However, the current Internet cannot yetsupport the full potential demand for real-time services.High-bandwidth services using RTP, such as video, canpotentially seriously degrade the quality of ser

16、vice of othernetwork services. Thus, implementors should takeappropriate precautions to limit accidental bandwidthusage. Application documentation should clearly outline6 / 21the limitations andpossible operational impact ofhigh-bandwidth real- time services on the Internet andother network services

17、.2 RTP Use ScenariosThe following sections describe some aspects of theuse of RTP. The examples werechosen to illustrate the basic operation of applicationsusing RTP, not to limit what RTP may be used for. In theseexamples, RTP is carried on top of IP and UDP, andfollows the conventionsestablished b

18、y the profile foraudio and video specified in the companion In ternet-Draftdraft-ietf-avt-profile2.1 Simple Multicast Audio Co nferenceA working group of the IETF meets to discuss thelatest protocol draft, using the IP multicast services of theIn ter net for voice com muni cati ons.Through somealloc

19、ati onmechanism the working group chair obtains a multicastgroup address and pair of ports. One port is used for audiodata, and the other is used for con trol (RTCP) packets.This address and port informationis distributed to the7 / 21inten ded participa nts. If privacy is desired, the data andcon trol packets may be en crypted as specified in Section 9.1 , in which case an encryption key must also begenerated and distributed. The exact details of theseallocation and distribution mechanisms are beyond thescope of RTP.The audio conferencing application used by eachconferen