rtpatransportprotocolforrealtimeapplicationsWord文件下载.docx

rtpatransportprotocolforrealtimeapplicationsWord文件下载.docx

《rtpatransportprotocolforrealtimeapplicationsWord文件下载.docx》由会员分享，可在线阅读，更多相关《rtpatransportprotocolforrealtimeapplicationsWord文件下载.docx（12页珍藏版）》请在冰豆网上搜索。

improvements.Pleaserefertothecurrenteditionofthe"

Internet

OfficialProtocolStandards"

（STD1）forthestandardizationstate

andstatusofthisprotocol.Distributionofthismemoisunlimited.AbstractThismemorandumdescribesRTP,thereal-timetransportprotocol.RTP

providesend-to-endnetworktransportfunctionssuitablefor

applicationstransmittingreal-timedata,suchasaudio,videoor

simulationdata,overmulticastorunicastnetworkservices.RTPdoes

notaddressresourcereservationanddoesnotguaranteequality-of-

serviceforreal-timeservices.Thedatatransportisaugmentedbya

controlprotocol（RTCP）toallowmonitoringofthedatadeliveryina

mannerscalabletolargemulticastnetworks,andtoprovideminimal

controlandidentificationfunctionality.RTPandRTCParedesigned

tobeindependentoftheunderlyingtransportandnetworklayers.The

protocolsupportstheuseofRTP-leveltranslatorsandmixers.TableofContents1.Introduction........................................3

2.RTPUseScenarios...................................5

2.1SimpleMulticastAudioConference...................5

2.2AudioandVideoConference..........................6

2.3MixersandTranslators..............................6

3.Definitions.........................................7

4.ByteOrder,Alignment,andTimeFormat..............9

5.RTPDataTransferProtocol..........................10

5.1RTPFixedHeaderFields.............................10

5.2MultiplexingRTPSessions...........................13Schulzrinne,etalStandardsTrack[Page1]

RFC1889RTPJanuary19965.3Profile-SpecificModificationstotheRTPHeader.....14

5.3.1RTPHeaderExtension................................14

6.RTPControlProtocol--RTCP........................15

6.1RTCPPacketFormat..................................17

6.2RTCPTransmissionInterval..........................19

6.2.1Maintainingthenumberofsessionmembers...........21

6.2.2Allocationofsourcedescriptionbandwidth..........21

6.3SenderandReceiverReports.........................22

6.3.1SR:

SenderreportRTCPpacket.......................23

6.3.2RR:

ReceiverreportRTCPpacket.....................28

6.3.3Extendingthesenderandreceiverreports...........29

6.3.4Analyzingsenderandreceiverreports...............29

6.4SDES:

SourcedescriptionRTCPpacket................31

6.4.1CNAME:

Canonicalend-pointidentifierSDESitem.....32

6.4.2NAME:

UsernameSDESitem...........................34

6.4.3EMAIL:

ElectronicmailaddressSDESitem............34

6.4.4PHONE:

PhonenumberSDESitem.......................34

6.4.5LOC:

GeographicuserlocationSDESitem.............35

6.4.6TOOL:

ApplicationortoolnameSDESitem............35

6.4.7NOTE:

Notice/statusSDESitem.......................35

6.4.8PRIV:

PrivateextensionsSDESitem..................36

6.5BYE:

GoodbyeRTCPpacket............................37

6.6APP:

Application-definedRTCPpacket................38

7.RTPTranslatorsandMixers..........................39

7.1GeneralDescription.................................39

7.2RTCPProcessinginTranslators......................41

7.3RTCPProcessinginMixers...........................43

7.4CascadedMixers.....................................44

8.SSRCIdentifierAllocationandUse..................44

8.1ProbabilityofCollision............................44

8.2CollisionResolutionandLoopDetection.............45

9.Security............................................49

9.1Confidentiality.....................................49

9.2AuthenticationandMessageIntegrity................50

10.RTPoverNetworkandTransportProtocols............51

11.SummaryofProtocolConstants.......................51

11.1RTCPpackettypes...................................52

11.2SDEStypes..........................................52

12.RTPProfilesandPayloadFormatSpecifications......53

A.Algorithms..........................................56

A.1RTPDataHeaderValidityChecks.....................59

A.2RTCPHeaderValidityChecks.........................63

A.3DeterminingtheNumberofRTPPacketsExpectedand

Lost................................................63

A.4GeneratingSDESRTCPPackets........................64

A.5ParsingRTCPSDESPackets...........................65

A.6GeneratingaRandom32-bitIdentifier...............66

A.7ComputingtheRTCPTransmissionInterval............68Schulzrinne,etalStandardsTrack[Page2]

RFC1889RTPJanuary1996A.8EstimatingtheInterarrivalJitter..................71

B.SecurityConsiderations.............................72

C.AddressesofAuthors................................72

D.Bibliography........................................731.IntroductionThismemorandumspecifiesthereal-timetransportprotocol（RTP）,

whichprovidesend-to-enddeliveryservicesfordatawithreal-time

characteristics,suchasinteractiveaudioandvideo.Thoseservices

includepayloadtypeidentification,sequencenumbering,timestamping

anddeliverymonitoring.ApplicationstypicallyrunRTPontopofUDP

tomakeuseofitsmultiplexingandchecksumservices;

bothprotocols

contributepartsofthetransportprotocolfunctionality.However,

RTPmaybeusedwithothersuitableunderlyingnetworkortransport

protocols（seeSection10）.RTPsupportsdatatransfertomultiple

destinationsusingmulticastdistributionifprovidedbythe

underlyingnetwork.NotethatRTPitselfdoesnotprovideanymechanismtoensuretimely

deliveryorprovideotherquality-of-serviceguarantees,butrelies

onlower-layerservicestodoso.Itdoesnotguaranteedeliveryor

preventout-of-orderdelivery,nordoesitassumethattheunderlying

networkisreliableanddeliverspacketsinsequence.Thesequence

numbersincludedinRTPallowthereceivertoreconstructthe

sender'

spacketsequence,butsequencenumbersmightalsobeusedto

determinetheproperlocationofapacket,forexampleinvideo

decoding,withoutnecessarilydecodingpacketsinsequence.WhileRTPisprimarilydesignedtosatisfytheneedsofmulti-

participantmultimediaconferences,itisnotlimitedtothat

particularapplication.Storageofcontinuousdata,interactive

distributedsimulation,activebadge,andcontrolandmeasurement

applicationsmayalsofindRTPapplicable.ThisdocumentdefinesRTP,consistingoftwoclosely-linkedparts:

othereal-timetransportprotocol（RTP）,tocarrydatathathas

real-timeproperties.otheRTPcontrolprotocol（RTCP）,tomonitorthequalityof

serviceandtoconveyinformationabouttheparticipantsinan

on-goingsession.ThelatteraspectofRTCPmaybesufficient

for"

looselycontrolled"

sessions,i.e.,wherethereisno

explicitmembershipcontrolandset-up,butitisnot

necessarilyintendedtosupportallofanapplication'

scontrol

communicationrequirements.Thisfunctionalitymaybefullyor

partiallysubsumedbyaseparatesessioncontrolprotocol,Schulzrinne,etalStandardsTrack[Page3]

RFC1889RTPJanuary1996whichisbeyondthescopeofthisdocument.RTPrepresentsanewstyleofprotocolfollowingtheprinciplesof

applicationlevelframingandintegratedlayerprocessingproposedby

ClarkandTennenhouse[1].Thatis,RTPisintendedtobemalleable

toprovidetheinformationrequiredbyaparticularapplicationand

willoftenbeintegratedintotheapplicationprocessingratherthan

beingimplementedasaseparatelayer.RTPisaprotocolframework

thatisdeliberatelynotcomplete.Thisdocumentspecifiesthose

functionsexpectedtobecommonacrossalltheapplicationsforwhich

RTPwouldbeappropriate.Unlikeconventionalprotocolsinwhich

additionalfunctionsmightbeaccommodatedbymakingtheprotocol

moregeneralorbyaddinganoptionmechanismthatwouldrequire

parsing,RTPisintendedtobetailoredthroughmodificationsand/or

additionstotheheadersasneeded.ExamplesaregiveninSections

5.3and6.3.3.Therefore,inadditiontothisdocument,acompletespecificationof

RTPforaparticularapplicationwillrequireoneormorecompanion

documents（seeSection12）:

oaprofilespecificationdocument,whichdefinesasetof

payloadtypecodesandtheirmappingtopayloadformats（e.g.,

mediaencodings）.Aprofilemayalsodefineextensionsor

modificationstoRTPthatarespecifictoaparticularclassof

applications.Typicallyanapplicationwilloperateunderonly

oneprofile.Aprofileforaudioandvideodatamaybefoundin

thecompanionRFCTBD.opayloadformatspecificationdocuments,whichdefinehowa

particularpayload,suchasanaudioorvideoencoding,isto

becarriedinRTP.Adiscussionofreal-timeservicesandalgorithmsfortheir

implementationaswellasbackgrounddiscussiononsomeoftheRTP

designdecisionscanbefoundin[2].SeveralRTPapplications,bothexperimentalandcommercial,have

alreadybeenimplementedfromdraftspecifications.These