NetworkWorkingGroupH.SchulzrinneRequestforComments:3551ColumbiaUniversityObsoletes:1890S.CasnerCategory:StandardsTrackPacketDesignJuly2003NetworkWorkingGroupH.SchulzrinneRequestforComments:3551ColumbiaUniversityObsoletes:1890S.CasnerCategory:StandardsTrackPacketDesignJuly2003RTPProfileforAudioandVideoConferenceswithMinimalControl
用于音频和视频会议的RTP配置文件，控制最少
StatusofthisMemo
本备忘录的状况
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD1）。本备忘录的分发不受限制。
Abstract
摘要
ThisdocumentalsodescribeshowaudioandvideodatamaybecarriedwithinRTP.ItdefinesasetofstandardencodingsandtheirnameswhenusedwithinRTP.Thedescriptionsprovidepointerstoreferenceimplementationsandthedetailedstandards.Thisdocumentismeantasanaidforimplementorsofaudio,videoandotherreal-timemultimediaapplications.
本文档还描述了如何在RTP中传输音频和视频数据。它定义了一组标准编码及其在RTP中使用时的名称。这些描述提供了参考实现和详细标准的指针。本文档旨在为音频、视频和其他实时多媒体应用的实施者提供帮助。
ThismemorandumobsoletesRFC1890.Itismostlybackwards-compatibleexceptforfunctionsremovedbecausetwointeroperableimplementationswerenotfound.TheadditionstoRFC1890codifyexistingpracticeintheuseofpayloadformatsunderthisprofileandincludenewpayloadformatsdefinedsinceRFC1890waspublished.
本备忘录废除了RFC1890。除了由于找不到两个可互操作的实现而删除的函数外，它基本上是向后兼容的。RFC1890的新增内容编纂了本概要下有效载荷格式使用的现有实践，并包括自RFC1890发布以来定义的新有效载荷格式。
TableofContents
目录
该概要文件定义了RTP版本2协议定义（RFC3550）[1]中未指定的RTP方面。此配置文件用于音频和视频会议中，会话控制最少。特别是，未提供对参数协商或成员资格控制的支持。在不使用协商或成员资格控制的会话中（例如，使用RTCP提供的静态有效负载类型和成员资格指示），该配置文件预计会有用，但该配置文件也可能与更高级别的控制协议结合使用。
Useofthisprofilemaybeimplicitintheuseoftheappropriateapplications;theremaybenoexplicitindicationbyportnumber,protocolidentifierorthelike.ApplicationssuchassessiondirectoriesmayusethenameforthisprofilespecifiedinSection11.
该配置文件的使用可能隐含在适当应用程序的使用中；可能没有端口号、协议标识符等的明确指示。会话目录等应用程序可以使用第11节中指定的此配置文件的名称。
Otherprofilesmaymakedifferentchoicesfortheitemsspecifiedhere.
其他配置文件可能会对此处指定的项目做出不同的选择。
Thisdocumentalsodefinesasetofencodingsandpayloadformatsforaudioandvideo.Thesepayloadformatdescriptionsareincludedhereonlyasamatterofconveniencesincetheyaretoosmalltowarrantseparatedocuments.UseofthesepayloadformatsisNOTREQUIREDtousethisprofile.OnlythebindingofsomeofthepayloadformatstostaticpayloadtypenumbersinTables4and5isnormative.
本文档还定义了音频和视频的一组编码和有效负载格式。这些有效负载格式描述仅为方便起见，因为它们太小，无法保证单独的文档。使用此配置文件不需要使用这些有效负载格式。只有表4和表5中的一些有效负载格式与静态有效负载类型编号的绑定是规范性的。
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[2]中的描述进行解释，并表示符合本RTP配置文件的实施要求级别。
Thisdocumentdefinesthetermmediatypeasdividingencodingsofaudioandvideocontentintothreeclasses:audio,videoandaudio/video(interleaved).
本文档将术语媒体类型定义为将音频和视频内容的编码分为三类：音频、视频和音频/视频（交错）。
RFC3550的“RTP配置文件和有效负载格式规范”一节列举了一些可以在配置文件中指定或修改的项目。本节讨论这些项目。通常，此配置文件遵循RTP规范的默认和/或建议方面。
RTPdataheader:ThestandardformatofthefixedRTPdataheaderisused(onemarkerbit).
RTP数据头：使用固定RTP数据头的标准格式（一个标记位）。
Payloadtypes:StaticpayloadtypesaredefinedinSection6.
有效载荷类型：静态有效载荷类型在第6节中定义。
RTPdataheaderadditions:NoadditionalfixedfieldsareappendedtotheRTPdataheader.
RTP数据头添加：RTP数据头没有附加固定字段。
RTPdataheaderextensions:NoRTPheaderextensionsaredefined,butapplicationsoperatingunderthisprofileMAYusesuchextensions.Thus,applicationsSHOULDNOTassumethattheRTPheaderXbitisalwayszeroandSHOULDbepreparedtoignoretheheaderextension.Ifaheaderextensionisdefinedinthefuture,thatdefinitionMUSTspecifythecontentsofthefirst16bitsinsuchawaythatmultipledifferentextensionscanbeidentified.
RTP数据头扩展：未定义RTP头扩展，但在此配置文件下运行的应用程序可能会使用此类扩展。因此，应用程序不应假定RTP报头X位始终为零，而应准备忽略报头扩展。如果将来定义了头扩展，则该定义必须指定前16位的内容，以便可以识别多个不同的扩展。
RTCPpackettypes:NoadditionalRTCPpackettypesaredefinedbythisprofilespecification.
RTCP数据包类型：此配置文件规范未定义其他RTCP数据包类型。
RTCP报告间隔：建议的常数用于RTCP报告间隔计算。在此配置文件下运行的会话可以为RTCP流量带宽指定单独的参数，而不是使用会话带宽的默认部分。RTCP流量带宽可分为两个单独的会话参数，分别用于活动数据发送者和非活动数据发送者。根据RTP规范[1]中的建议，1/4的RTCP带宽专用于数据发送方，这两个参数的建议默认值分别为1.25%和3.75%。对于特定会话，当在单向链路上操作或对于不需要接收质量反馈的会话，非数据发送方的RTCP带宽可以设置为零。数据发送方的RTCP带宽应保持为非零，以便发送方报告仍可发送以进行媒体间同步，并通过CNAME识别源。指定RTCP带宽的一个或两个会话参数的方法超出了本备忘录的范围。
SR/RRextension:NoextensionsectionisdefinedfortheRTCPSRorRRpacket.
SR/RR扩展：没有为RTCPSR或RR数据包定义扩展节。
SDESuse:ApplicationsMAYuseanyoftheSDESitemsdescribedintheRTPspecification.WhileCNAMEinformationMUSTbesenteveryreportinginterval,otheritemsSHOULDonlybesenteverythirdreportinginterval,withNAMEsentsevenoutofeighttimeswithinthatslotandtheremainingSDESitemscyclicallytakinguptheeighthslot,asdefinedinSection6.2.2oftheRTPspecification.Inotherwords,NAMEissentinRTCPpackets1,4,7,10,13,16,19,while,say,EMAILisusedinRTCPpacket22.
SDES使用：应用程序可以使用RTP规范中描述的任何SDES项。虽然CNAME信息必须每一个报告间隔发送一次，但其他项目只能每三个报告间隔发送一次，名称在该时隙内发送八次中的七次，其余SDES项目周期性地占用第八个时隙，如RTP规范第6.2.2节所定义。换句话说，名称在RTCP数据包1、4、7、10、13、16、19中发送，而电子邮件在RTCP数据包22中使用。
Security:TheRTPdefaultsecurityservicesarealsothedefaultunderthisprofile.
安全性：RTP默认安全服务也是此配置文件下的默认服务。
String-to-keymapping:Nomappingisspecifiedbythisprofile.
字符串到键的映射：此配置文件未指定任何映射。
Congestion:RTPandthisprofilemaybeusedinthecontextofenhancednetworkservice,forexample,throughIntegratedServices(RFC1633)[4]orDifferentiatedServices(RFC2475)[5],ortheymaybeusedwithbesteffortservice.
拥塞：RTP和此配置文件可在增强型网络服务的上下文中使用，例如，通过集成服务（RFC1633）[4]或差异化服务（RFC2475）[5]，或与尽力而为服务一起使用。
Ifenhancedserviceisbeingused,RTPreceiversSHOULDmonitorpacketlosstoensurethattheservicethatwasrequestedisactuallybeingdelivered.Ifitisnot,thentheySHOULDassumethattheyarereceivingbest-effortserviceandbehaveaccordingly.
如果正在使用增强服务，RTP接收器应该监控数据包丢失，以确保请求的服务实际正在交付。如果不是，那么他们应该假设他们正在接受尽力而为的服务，并相应地采取行动。
Ifbest-effortserviceisbeingused,RTPreceiversSHOULDmonitorpacketlosstoensurethatthepacketlossrateiswithinacceptableparameters.PacketlossisconsideredacceptableifaTCPflowacrossthesamenetworkpathandexperiencingthesamenetworkconditionswouldachieveanaveragethroughput,measuredonareasonabletimescale,thatisnotlessthantheRTPflowisachieving.Thisconditioncanbesatisfiedbyimplementingcongestioncontrolmechanismstoadaptthetransmissionrate(orthenumberoflayerssubscribedforalayeredmulticastsession),orbyarrangingforareceivertoleavethesessionifthelossrateisunacceptablyhigh.
Underlyingprotocol:TheprofilespecifiestheuseofRTPoverunicastandmulticastUDPaswellasTCP.(ThisdoesnotprecludetheuseofthesedefinitionswhenRTPiscarriedbyotherlower-layerprotocols.)
底层协议：概要文件指定在单播和多播UDP以及TCP上使用RTP。（当RTP由其他较低层协议承载时，这并不排除使用这些定义。）
Transportmapping:ThestandardmappingofRTPandRTCPtotransport-leveladdressesisused.
传输映射：使用RTP和RTCP到传输级地址的标准映射。
Encapsulation:ThisprofileleavestoapplicationsthespecificationofRTPencapsulationinprotocolsotherthanUDP.
封装：此配置文件将RTP封装的规范留给应用程序，而不是UDP协议。
Thisprofilelistsasetofencodings,eachofwhichiscomprisedofaparticularmediadatacompressionorrepresentationplusapayloadformatforencapsulationwithinRTP.Someofthosepayloadformatsarespecifiedhere,whileothersarespecifiedinseparateRFCs.ItisexpectedthatadditionalencodingsbeyondthesetlistedherewillbecreatedinthefutureandspecifiedinadditionalpayloadformatRFCs.
此概要文件列出了一组编码，每个编码都由特定的媒体数据压缩或表示以及用于在RTP中封装的有效负载格式组成。其中一些有效负载格式在此处指定，而其他格式在单独的RFC中指定。预计将来将创建此处列出的集合之外的其他编码，并以其他有效负载格式RFCs指定。
ThisprofilealsoassignstoeachencodingashortnamewhichMAYbeusedbyhigher-levelcontrolprotocols,suchastheSessionDescriptionProtocol(SDP),RFC2327[6],toidentifyencodingsselectedforaparticularRTPsession.
该配置文件还为每个编码分配一个短名称，该名称可由更高级别的控制协议（如会话描述协议（SDP））RFC2327[6]使用，以识别为特定RTP会话选择的编码。
在某些上下文中，以MIME内容类型的形式引用这些编码可能很有用。为了便于实现这一点，RFC3555[7]通过RFC2048[8]中规定的MIME注册过程，为此处列出的所有编码名称提供注册，这些名称作为“音频”和“视频”MIME类型下的MIME子类型名称。
Anyadditionalencodingsspecifiedforuseunderthisprofile(orothers)mayalsobeassignednamesregisteredasMIMEsubtypeswiththeInternetAssignedNumbersAuthority(IANA).Thisregistryprovidesameanstoinsurethatthenamesassignedtotheadditionalencodingsarekeptunique.RFC3555specifiestheinformationthatisrequiredfortheregistrationofRTPencodings.
在此配置文件下指定使用的任何其他编码（或其他编码）也可以被指定为在InternetassignedNumbersAuthority（IANA）注册为MIME子类型的名称。该注册表提供了一种确保分配给其他编码的名称保持唯一的方法。RFC3555指定注册RTP编码所需的信息。
Inadditiontoassigningnamestoencodings,thisprofilealsoassignsstaticRTPpayloadtypenumberstosomeofthem.However,thepayloadtypenumberspaceisrelativelysmallandcannotaccommodateassignmentsforallexistingandfutureencodings.DuringtheearlystagesofRTPdevelopment,itwasnecessarytousestaticallyassignedpayloadtypesbecausenoothermechanismhadbeenspecifiedtobindencodingstopayloadtypes.Itwasanticipatedthatnon-RTPmeansbeyondthescopeofthismemo(suchasdirectoryservicesorinvitationprotocols)wouldbespecifiedtoestablisha
除了为编码分配名称外，此概要文件还为其中一些编码分配静态RTP有效负载类型号。但是，有效负载类型编号空间相对较小，无法容纳所有现有和未来编码的分配。在RTP开发的早期阶段，有必要使用静态分配的有效负载类型，因为没有指定其他机制将编码绑定到有效负载类型。预计将指定超出本备忘录范围的非RTP方式（如目录服务或邀请协议）来建立
dynamicmappingbetweenapayloadtypeandanencoding.Now,mechanismsfordefiningdynamicpayloadtypebindingshavebeenspecifiedintheSessionDescriptionProtocol(SDP)andinotherprotocolssuchasITU-TRecommendationH.323/H.245.Thesemechanismsassociatetheregisterednameoftheencoding/payloadformat,alongwithanyadditionalrequiredparameters,suchastheRTPtimestampclockrateandnumberofchannels,withapayloadtypenumber.ThisassociationiseffectiveonlyforthedurationoftheRTPsessioninwhichthedynamicpayloadtypebindingismade.ThisassociationappliesonlytotheRTPsessionforwhichitismade,thusthenumberscanbere-usedfordifferentencodingsindifferentsessionssothenumberspacelimitationisavoided.
Thisprofilereservespayloadtypenumbersintherange96-127exclusivelyfordynamicassignment.ApplicationsSHOULDfirstusevaluesinthisrangefordynamicpayloadtypes.Thoseapplicationswhichneedtodefinemorethan32dynamicpayloadtypesMAYbindcodesbelow96,inwhichcaseitisRECOMMENDEDthatunassignedpayloadtypenumbersbeusedfirst.However,thestaticallyassignedpayloadtypesaredefaultbindingsandMAYbedynamicallyboundtonewencodingsifneeded.Redefiningpayloadtypesbelow96maycauseincorrectoperationifanattemptismadetojoinasessionwithoutobtainingsessiondescriptioninformationthatdefinesthedynamicpayloadtypes.
此配置文件专门为动态分配保留96-127范围内的有效负载类型编号。应用程序应首先将此范围内的值用于动态有效负载类型。那些需要定义32种以上动态有效负载类型的应用程序可能会绑定96以下的代码，在这种情况下，建议首先使用未分配的有效负载类型编号。但是，静态分配的有效负载类型是默认绑定，如果需要，可以动态绑定到新编码。如果试图加入会话而未获得定义动态负载类型的会话描述信息，则将负载类型重新定义到96以下可能会导致错误操作。
DynamicpayloadtypesSHOULDNOTbeusedwithoutawell-definedmechanismtoindicatethemapping.SystemsthatexpecttointeroperatewithothersoperatingunderthisprofileSHOULDNOTmaketheirownassignmentsofproprietaryencodingstoparticular,fixedpayloadtypes.
如果没有明确定义的机制来指示映射，则不应使用动态有效负载类型。期望与在此配置文件下运行的其他系统进行互操作的系统不应将其自己的专有编码分配给特定的固定负载类型。
Thisspecificationestablishesthepolicythatnoadditionalstaticpayloadtypeswillbeassignedbeyondtheonesdefinedinthisdocument.Establishingthispolicyavoidstheproblemoftryingtocreateasetofcriteriaforacceptingstaticassignmentsandencouragestheimplementationanddeploymentofthedynamicpayloadtypemechanisms.
本规范确立了一项政策，即除本文档中定义的静态有效负载类型外，不会分配其他静态有效负载类型。建立此策略避免了试图创建一组接受静态分配的标准的问题，并鼓励实现和部署动态有效负载类型机制。
ThefinalsetofstaticpayloadtypeassignmentsisprovidedinTables4and5.
表4和表5提供了静态有效负载类型分配的最后一组。
Sincetheabilitytosuppresssilenceisoneoftheprimarymotivationsforusingpacketstotransmitvoice,theRTPheadercarriesbothasequencenumberandatimestamptoallowareceivertodistinguishbetweenlostpacketsandperiodsoftimewhennodatawastransmitted.Discontiguoustransmission(silencesuppression)MAYbeusedwithanyaudiopayloadformat.ReceiversMUSTassumethatsendersmaysuppresssilenceunlessthisisrestrictedbysignalingspecifiedelsewhere.(Evenifthetransmitterdoesnotsuppresssilence,thereceivershouldbepreparedtohandleperiodswhennodataispresentsincepacketsmaybelost.)
一些有效载荷格式（见第4.5.3节和第4.5.6节）定义了“静音插入描述符”或“舒适噪声”帧，以指定静音期间可能产生的人工噪声参数，以近似源处的背景噪声。对于其他有效载荷格式，RFC3389[9]中规定了通用舒适性噪声（CN）有效载荷格式。当CN有效载荷格式与其他有效载荷格式一起使用时，RTP有效载荷类型字段中的不同值将舒适性噪声包与所选有效载荷格式的噪声包区分开来。
Forapplicationswhichsendeithernopacketsoroccasionalcomfort-noisepacketsduringsilence,thefirstpacketofatalkspurt,thatis,thefirstpacketafterasilenceperiodduringwhichpacketshavenotbeentransmittedcontiguously,SHOULDbedistinguishedbysettingthemarkerbitintheRTPdataheadertoone.Themarkerbitinallotherpacketsiszero.ThebeginningofatalkspurtMAYbeusedtoadjusttheplayoutdelaytoreflectchangingnetworkdelays.ApplicationswithoutsilencesuppressionMUSTsetthemarkerbittozero.
对于在静默期间不发送分组或偶尔发送舒适噪声分组的应用程序，应通过将RTP数据报头中的标记位设置为1来区分TalkSput的第一个分组，即在没有连续发送分组的静默期之后的第一个分组。所有其他数据包中的标记位均为零。TalkSport的开始可用于调整播放延迟以反映不断变化的网络延迟。无静音抑制的应用程序必须将标记位设置为零。
TheRTPclockrateusedforgeneratingtheRTPtimestampisindependentofthenumberofchannelsandtheencoding;itusuallyequalsthenumberofsamplingperiodspersecond.ForN-channelencodings,eachsamplingperiod(say,1/8,000ofasecond)generatesNsamples.(Thisterminologyisstandard,butsomewhatconfusing,asthetotalnumberofsamplesgeneratedpersecondisthenthesamplingratetimesthechannelcount.)
Ifmultipleaudiochannelsareused,channelsarenumberedleft-to-right,startingatone.InRTPaudiopackets,informationfromlower-numberedchannelsprecedesthatfromhigher-numberedchannels.
如果使用多个音频频道，则频道从左到右编号，从一个开始。在RTP音频数据包中，来自编号较低通道的信息优先于来自编号较高通道的信息。
Formorethantwochannels,theconventionfollowedbytheAIFF-CaudiointerchangeformatSHOULDbefollowed[3],usingthefollowingnotation,unlesssomeotherconventionisspecifiedforaparticularencodingorpayloadformat:
对于两个以上的频道，应遵循AIFF-C音频交换格式遵循的约定[3]，使用以下符号，除非为特定编码或有效负载格式指定了其他约定：
lleftrrightccenterSsurroundFfrontRrear
左左右c中心S环绕F前右后
注：RFC1890为四个音频通道的顺序定义了两种约定。由于顺序是由通道数隐式表示的，因此这是不明确的。在本次修订中，为了消除歧义，取消了“四和弦”的顺序。这一选择是基于这样一个观察结果，即四和弦消费音频格式并未流行，而环绕声随后已经流行。
SamplesforallchannelsbelongingtoasinglesamplinginstantMUSTbewithinthesamepacket.Theinterleavingofsamplesfromdifferentchannelsdependsontheencoding.GeneralguidelinesaregiveninSection4.3and4.4.
属于单个采样瞬间的所有通道的采样必须在同一数据包内。来自不同通道的样本交错取决于编码。一般指南见第4.3节和第4.4节。
ThesamplingfrequencySHOULDbedrawnfromtheset:8,000,11,025,16,000,22,050,24,000,32,000,44,100and48,000Hz.(OlderAppleMacintoshcomputershadanativesamplerateof22,254.54Hz,whichcanbeconvertedto22,050withacceptablequalitybydropping4samplesina20msframe.)However,mostaudioencodingsaredefinedforamorerestrictedsetofsamplingfrequencies.ReceiversSHOULDbepreparedtoacceptmulti-channelaudio,butMAYchoosetoonlyplayasinglechannel.
采样频率应从以下集合中抽取：8000、11025、16000、22050、24000、32000、44100和48000Hz。（较旧的AppleMacintosh计算机的本机采样率为22254.54Hz，可以通过在20毫秒的帧中删除4个采样，将其转换为质量可接受的22050。）然而，大多数音频编码是为一组更受限制的采样频率定义的。接收机应准备好接受多声道音频，但可以选择只播放一个声道。
Thefollowingrecommendationsaredefaultoperatingparameters.ApplicationsSHOULDbepreparedtohandleothervalues.Therangesgivenaremeanttogiveguidancetoapplicationwriters,allowinga
以下建议为默认操作参数。应用程序应准备好处理其他值。给出的范围旨在为应用程序编写者提供指导，允许
setofapplicationsconformingtotheseguidelinestointeroperatewithoutadditionalnegotiation.Theseguidelinesarenotintendedtorestrictoperatingparametersforapplicationsthatcannegotiateasetofinteroperableparameters,e.g.,throughaconferencecontrolprotocol.
符合这些准则的一组应用程序，无需额外协商即可进行互操作。这些指南并非旨在限制可协商一组互操作参数（例如通过会议控制协议）的应用程序的操作参数。
Insample-basedencodings,eachaudiosampleisrepresentedbyafixednumberofbits.Withinthecompressedaudiodata,codesforindividualsamplesmayspanoctetboundaries.AnRTPaudiopacketmaycontainanynumberofaudiosamples,subjecttotheconstraintthatthenumberofbitspersampletimesthenumberofsamplesperpacketyieldsanintegraloctetcount.Fractionalencodingsproducelessthanoneoctetpersample.
在基于样本的编码中，每个音频样本由固定位数表示。在压缩音频数据中，单个样本的代码可能跨越八位字节边界。RTP音频分组可以包含任意数量的音频样本，但受制于每个样本的比特数乘以每个分组的样本数产生整数八位组计数的约束。分数编码每个样本产生少于一个八位组。
Thedurationofanaudiopacketisdeterminedbythenumberofsamplesinthepacket.
Forsample-basedencodingsproducingoneormoreoctetspersample,samplesfromdifferentchannelssampledatthesamesamplinginstantSHOULDbepackedinconsecutiveoctets.Forexample,foratwo-channelencoding,theoctetsequenceis(leftchannel,firstsample),(rightchannel,firstsample),(leftchannel,secondsample),(rightchannel,secondsample),....Formulti-octetencodings,octetsSHOULDbetransmittedinnetworkbyteorder(i.e.,mostsignificantoctetfirst).Forsample-basedencodingsproducingoneormoreoctetspersample,samplesfromdifferentchannelssampledatthesamesamplinginstantSHOULDbepackedinconsecutiveoctets.Forexample,foratwo-channelencoding,theoctetsequenceis(leftchannel,firstsample),(rightchannel,firstsample),(leftchannel,secondsample),(rightchannel,secondsample),....Formulti-octetencodings,octetsSHOULDbetransmittedinnetworkbyteorder(i.e.,mostsignificantoctetfirst).Thepackingofsample-basedencodingsproducinglessthanoneoctetpersampleisencoding-specific.
每个样本产生少于一个八位组的基于样本的编码的打包是特定于编码的。
TheRTPtimestampreflectstheinstantatwhichthefirstsampleinthepacketwassampled,thatis,theoldestinformationinthepacket.
Frame-basedencodingsencodeafixed-lengthblockofaudiointoanotherblockofcompresseddata,typicallyalsooffixedlength.Forframe-basedencodings,thesenderMAYchoosetocombineseveralsuchframesintoasingleRTPpacket.ThereceivercantellthenumberofframescontainedinanRTPpacket,ifalltheframeshavethesamelength,bydividingtheRTPpayloadlengthbytheaudioframesizewhichisdefinedaspartoftheencoding.Thisdoesnotworkwhencarryingframesofdifferentsizesunlesstheframesizesarerelativelyprime.Ifnot,theframesMUSTindicatetheirsize.
基于帧的编码将固定长度的音频块编码为另一个压缩数据块，通常也是固定长度的。对于基于帧的编码，发送方可以选择将多个这样的帧组合成单个RTP分组。如果所有帧具有相同的长度，则接收机可以通过将RTP有效负载长度除以定义为编码的一部分的音频帧大小来告诉RTP分组中包含的帧的数量。当承载不同尺寸的框架时，这不起作用，除非框架尺寸相对较大。如果没有，框架必须指明其大小。
Forframe-basedcodecs,thechannelorderisdefinedforthewholeblock.Thatis,fortwo-channelaudio,rightandleftsamplesSHOULDbecodedindependently,withtheencodedframefortheleftchannelprecedingthatfortherightchannel.
对于基于帧的编解码器，为整个块定义通道顺序。也就是说，对于双声道音频，应分别对右声道和左声道采样进行编码，左声道的编码帧先于右声道的编码帧。
Allframe-orientedaudiocodecsSHOULDbeabletoencodeanddecodeseveralconsecutiveframeswithinasinglepacket.Sincetheframesizefortheframe-orientedcodecsisgiven,thereisnoneedtouseaseparatedesignationforthesameencoding,butwithdifferentnumberofframesperpacket.
所有面向帧的音频编解码器应能够在单个数据包中编码和解码多个连续帧。由于面向帧的编解码器的帧大小是给定的，因此不需要对相同的编码使用单独的指定，但是每个分组的帧数不同。
RTPpacketsSHALLcontainawholenumberofframes,withframesinsertedaccordingtoagewithinapacket,sothattheoldestframe(tobeplayedfirst)occursimmediatelyaftertheRTPpacketheader.TheRTPtimestampreflectstheinstantatwhichthefirstsampleinthefirstframewassampled,thatis,theoldestinformationinthepacket.
DVI4使用交互式多媒体协会（IMA）指定为“IMAADPCM波形类型”的自适应增量脉冲编码调制（ADPCM）编码方案。然而，此处定义为DVI4的编码在三个方面与IMA规范不同：
oTheRTPDVI4headercontainsthepredictedvalueratherthanthefirstsamplevaluecontainedtheIMAADPCMblockheader.
oRTPDVI4标头包含预测值，而不是包含IMAADPCM块标头的第一个样本值。
oIMAADPCM块包含奇数个样本，因为块的第一个样本仅包含在头中（未压缩），然后是偶数个压缩样本。DVI4只有偶数个压缩样本，使用来自报头的“predict”字对第一个样本进行解码。
oForDVI4,the4-bitsamplesarepackedwiththefirstsampleinthefourmostsignificantbitsandthesecondsampleinthefourleastsignificantbits.IntheIMAADPCMcodec,thesamplesarepackedintheoppositeorder.
o对于DVI4，4位样本与四个最高有效位中的第一个样本和四个最低有效位中的第二个样本一起打包。在IMAADPCM编解码器中，样本以相反的顺序打包。
EachpacketcontainsasingleDVIblock.Thisprofileonlydefinesthe4-bit-per-sampleversion,whileIMAalsospecifieda3-bit-per-sampleencoding.
每个数据包包含一个DVI块。此配置文件仅定义了每样本4位的版本，而IMA还指定了每样本3位的编码。
每个通道的“标题”字具有以下结构：
int16predict;/*predictedvalueoffirstsamplefromthepreviousblock(L16format)*/u_int8index;/*currentindexintostepsizetable*/u_int8reserved;/*settozerobysender,ignoredbyreceiver*/int16predict;/*predictedvalueoffirstsamplefromthepreviousblock(L16format)*/u_int8index;/*currentindexintostepsizetable*/u_int8reserved;/*settozerobysender,ignoredbyreceiver*/Eachoctetfollowingtheheadercontainstwo4-bitsamples,thusthenumberofsamplesperpacketMUSTbeevenbecausethereisnomeanstoindicateapartiallyfilledlastoctet.
报头后面的每个八位字节包含两个4位样本，因此每个数据包的样本数必须为偶数，因为无法指示部分填充的最后一个八位字节。
Packingofsamplesformultiplechannelsisforfurtherstudy.
多通道样品的包装有待进一步研究。
TheIMAADPCMalgorithmwasdescribedinthedocumentIMARecommendedPracticesforEnhancingDigitalAudioCompatibilityinMultimediaSystems(version3.0).However,theInteractiveMultimediaAssociationceasedoperationsin1997.ResourcesforanarchivedcopyofthatdocumentandasoftwareimplementationoftheRTPDVI4encodingarelistedinSection13.
IMAADPCM算法在文件《IMA增强多媒体系统中数字音频兼容性的推荐做法》（3.0版）中进行了描述。然而，互动多媒体协会于1997年停止运作。第13节列出了该文件的存档副本和RTPDVI4编码的软件实现的资源。
G722在ITU-T建议G.722“64kbit/s内的7kHz音频编码”中有规定。G.722编码器产生八位字节流，每个八位字节在RTP数据包中对齐。G.722八位字节中传输的第一位，即较高子带样本的最高有效位，应对应于RTP数据包中八位字节的最高有效位。
EventhoughtheactualsamplingrateforG.722audiois16,000Hz,theRTPclockratefortheG722payloadformatis8,000HzbecausethatvaluewaserroneouslyassignedinRFC1890andmustremainunchangedforbackwardcompatibility.Theoctetrateorsample-pairrateis8,000Hz.
尽管G.722音频的实际采样率为16000Hz，但G722有效负载格式的RTP时钟率为8000Hz，因为该值在RFC1890中被错误分配，并且必须保持不变以实现向后兼容性。八位组速率或样本对速率为8000Hz。
ThisRecommendationspecifiesacodedrepresentationthatcanbeusedforcompressingthespeechsignalcomponentofmulti-mediaservicesataverylowbitrate.Audioisencodedin30msframes,withanadditionaldelayof7.5msduetolook-ahead.AG.723.1framecanbeoneofthreesizes:24octets(6.3kb/sframe),20octets(5.3kb/sframe),or4octets.These4-octetframesarecalledSIDframes(SilenceInsertionDescriptor)andareusedtospecifycomfortnoiseparameters.Thereisnorestrictiononhow4,20,and24octetframesareintermixed.Theleastsignificanttwobitsofthefirstoctetintheframedeterminetheframesizeandcodectype:
本建议规定了可用于以极低比特率压缩多媒体服务的语音信号分量的编码表示。音频以30毫秒的帧进行编码，由于向前看，额外延迟7.5毫秒。G.723.1帧可以是三种大小之一：24个八位字节（6.3kb/s帧）、20个八位字节（5.3kb/s帧）或4个八位字节。这些4-octet帧称为SID帧（静音插入描述符），用于指定舒适噪声参数。对于如何混合4、20和24个八位组帧没有限制。帧中第一个八位字节的最低有效位决定帧大小和编解码器类型：
bitscontentoctets/frame00high-ratespeech(6.3kb/s)2401low-ratespeech(5.3kb/s)2010SIDframe411reserved
比特内容八位字节/帧00高速率语音（6.3kb/s）2401低速率语音（5.3kb/s）2010SID帧411保留
Itispossibletoswitchbetweenthetworatesatany30msframeboundary.Both(5.3kb/sand6.3kb/s)ratesareamandatorypartoftheencoderanddecoder.ReceiversMUSTacceptbothdataratesandMUSTacceptSIDframesunlessrestrictionofthesecapabilitieshasbeensignaled.TheMIMEregistrationforG723inRFC3555[7]specifiesparametersthatMAYbeusedwithMIMEorSDPtorestricttoasingledatarateortorestricttheuseofSIDframes.Thiscoderwasoptimizedtorepresentspeechwithnear-tollqualityattheaboveratesusingalimitedamountofcomplexity.
可以在任何30ms帧边界上在两个速率之间切换。这两种速率（5.3kb/s和6.3kb/s）都是编码器和解码器的必备部分。接收机必须接受这两种数据速率，并且必须接受SID帧，除非这些能力受到限制。RFC3555[7]中G723的MIME注册指定了可与MIME或SDP一起使用的参数，以限制单个数据速率或限制SID帧的使用。该编码器经过优化，以有限的复杂度以上述速率表示接近通行费质量的语音。
记录G.723.1中规定了将编码比特流打包成八位字节以及八位字节的传输顺序，并且与G.723C代码参考实现产生的顺序相同。对于6.3kb/s的数据速率，这种打包如下所示，其中头部（HDR）位始终为“00”，如图1所示，以指示以6.3kb/s的速度运行，并且Z位始终设置为零。图中显示了“网络字节顺序”中的位打包，也称为大端顺序。每个32位字的位编号为0到31，最高有效位在左边，编号为0。每个字的八位字节（字节）首先传输最重要的八位字节。每个数据字段的位按照编码的位流表示的顺序进行编号（最低有效位优先）。垂直条表示字段片段之间的边界。
图1:G.723（6.3kb/s）位打包
对于5.3kb/s的数据速率，报头（HDR）位始终为“01”，如图2所示，以指示以5.3kb/s的速度运行。
图2:G.723（5.3kb/s）位打包
图3中描绘了G.723.1SID（静默）帧的打包，其由具有模式“10”的报头（HDR）位指示。
012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|LPC|HDR|LPC|LPC|GAIN|LPC|||||||||000000|10|11110000|22111111|000000|22||543210||32109876|10987654|543210|32|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|LPC|HDR|LPC|LPC|GAIN|LPC|||||||||000000|10|11110000|22111111|000000|22||543210||32109876|10987654|543210|32|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure3:G.723SIDmodebitpacking
图3:G.723SID模式位打包
ITU-TRecommendationG.726describes,amongothers,thealgorithmrecommendedforconversionofasingle64kbit/sA-lawormu-lawPCMchannelencodedat8,000samples/sectoandfroma40,32,24,or16kbit/schannel.TheconversionisappliedtothePCMstreamusinganAdaptiveDifferentialPulseCodeModulation(ADPCM)transcodingtechnique.TheADPCMrepresentationconsistsofaseriesofcodewordswithaone-to-onecorrespondencetothesamplesinthePCMstream.TheG726dataratesof40,32,24,and16kbit/shavecodewordsof5,4,3,and2bits,respectively.
除其他外，ITU-T建议G.726描述了建议用于将以8000采样/秒编码的单个64kbit/sa律或mu律PCM信道转换为40、32、24或16kbit/s信道的算法。该转换使用自适应差分脉冲编码调制（ADPCM）转码技术应用于PCM流。ADPCM表示法由一系列与PCM流中的样本一一对应的码字组成。G726数据速率为40、32、24和16kbit/s，其码字分别为5、4、3和2位。
The16and24kbit/sencodingsdonotprovidetollqualityspeech.TheyaredesignedforusedinoverloadedDigitalCircuitMultiplicationEquipment(DCME).ITU-TG.726recommendsthatthe16and24kbit/sencodingsshouldbealternatedwithhigherdatarateencodingstoprovideanaveragesamplesizeofbetween3.5and3.7bitspersample.
16和24kbit/s编码不能提供收费质量的语音。它们设计用于过载数字电路乘法设备（DCME）。ITU-TG.726建议16和24kbit/s编码应与更高的数据速率编码交替使用，以提供每个样本3.5到3.7位之间的平均样本大小。
TheencodingsofG.726areheredenotedasG726-40,G726-32,G726-24,andG726-16.Priorto1990,G721describedthe32kbit/sADPCMencoding,andG723describedthe40,32,and16kbit/sencodings.Thus,G726-32designatesthesamealgorithmasG721inRFC1890.
G.726的编码在这里表示为G726-40、G726-32、G726-24和G726-16。在1990年之前，G721描述了32kbit/sADPCM编码，G723描述了40、32和16kbit/s编码。因此，G726-32指定的算法与RFC1890中的G721相同。
AstreamofG726codewordscontainsnoinformationontheencodingbeingused,thereforetransitionsbetweenG726encodingtypesarenotpermittedwithinasequenceofpackedcodewords.ApplicationsMUSTdeterminetheencodingtypeofpackedcodewordsfromtheRTPpayloadidentifier.
G726码字流不包含所使用编码的任何信息，因此在压缩码字序列中不允许G726编码类型之间的转换。应用程序必须根据RTP有效负载标识符确定压缩码字的编码类型。
Nopayload-specificheaderinformationSHALLbeincludedaspartoftheaudiodata.AstreamofG726codewordsMUSTbepackedintooctetsasfollows:thefirstcodewordisplacedintothefirstoctetsuchthattheleastsignificantbitofthecodewordalignswiththeleastsignificantbitintheoctet,thesecondcodewordisthenpackedsothatitsleastsignificantbitcoincideswiththeleastsignificantunoccupiedbitintheoctet.Whenacompletecodewordcannotbeplacedintoanoctet,thebitsoverlappingtheoctetboundaryareplacedintotheleastsignificantbitsofthenextoctet.PackingMUSTendwithacompletelypackedfinaloctet.Thenumberofcodewordspackedwillthereforebeamultipleof8,2,8,and4forG726-40,G726-32,G726-24,andG726-16,respectively.AnexampleofthepackingschemeforG726-32codewordsisasshown,wherebit7istheleastsignificantbitofthefirstoctet,andbitA3istheleastsignificantbitofthefirstcodeword:
音频数据中不应包含特定于有效载荷的报头信息。G726码字流必须按如下方式打包成八位字节：将第一个码字放入第一个八位字节，以便码字的最低有效位与八位字节中的最低有效位对齐，然后对第二个码字进行压缩，使其最低有效位与八位字节中最低有效未占用位一致。当一个完整的码字不能放入一个八位组时，与八位组边界重叠的位被放入下一个八位组的最低有效位。包装必须以完全包装的最后八位字节结束。因此，对于G726-40、G726-32、G726-24和G726-16，压缩的码字数将分别为8、2、8和4的倍数。G726-32码字的打包方案示例如图所示，其中位7是第一个八位字节的最低有效位，位A3是第一个码字的最低有效位：
010123456789012345+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|BBBB|AAAA|DDDD|CCCC|...|0123|0123|0123|0123|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-010123456789012345+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|BBBB|AAAA|DDDD|CCCC|...|0123|0123|0123|0123|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-AnexampleofthepackingschemeforG726-24codewordsfollows,whereagainbit7istheleastsignificantbitofthefirstoctet,andbitA2istheleastsignificantbitofthefirstcodeword:
G726-24码字的打包方案示例如下，其中位7是第一个八位组的最低有效位，位A2是第一个码字的最低有效位：
请注意，此处规定的样本以G726-16、-24、-32和-40有效载荷格式打包成八位字节的“小端”方向与ITU-T建议X.420一致，但与ITU-T建议I.366.2附录E中规定的ATMAAL2传输相反。第二组RTP有效载荷格式与I.366.2附录E的打包匹配，并由MIME子类型AAL2-G726-16、-24、-32和-40标识，将在单独的文件中指定。
G728在ITU-T建议G.728“使用低延迟码激励线性预测对16kbit/s的语音进行编码”中规定。
AG.278encodertranslates5consecutiveaudiosamplesintoa10-bitcodebookindex,resultinginabitrateof16kb/sforaudiosampledat8,000samplespersecond.Thegroupoffiveconsecutivesamplesiscalledavector.Fourconsecutivevectors,labeledV1toV4(whereV1istobeplayedfirstbythereceiver),buildoneG.728frame.Thefourvectorsof40bitsarepackedinto5octets,labeledB1throughB5.B1SHALLbeplacedfirstintheRTPpacket.
G.278编码器将5个连续音频样本转换为10位码本索引，以每秒8000个样本的速度采样的音频的比特率为16kb/s。由五个连续样本组成的组称为向量。四个连续的向量，标记为V1到V4（其中V1首先由接收器播放），构建一个G.728帧。40位的四个向量被压缩成5个八位字节，标记为B1到B5。B1应首先放入RTP包中。
参考下图，比特顺序的原则是“保持比特重要性”。来自旧向量的位比来自新向量的位更重要。帧的MSB指向B1的MSB，帧的LSB指向B5的LSB。
123300009++++++++++++++++++++++++++++++++++++++++<---V1---><---V2---><---V3---><---V4--->vectors<--B1--><--B2--><--B3--><--B4--><--B5-->octets<-------------frame1---------------->123300009++++++++++++++++++++++++++++++++++++++++<---V1---><---V2---><---V3---><---V4--->vectors<--B1--><--B2--><--B3--><--B4--><--B5-->octets<-------------frame1---------------->Inparticular,B1containstheeightmostsignificantbitsofV1,withtheMSBofV1beingtheMSBofB1.B2containsthetwoleastsignificantbitsofV1,themoresignificantofthetwoinitsMSB,andthesixmostsignificantbitsofV2.B1SHALLbeplacedfirstintheRTPpacketandB5last.
特别是，B1包含V1的八个最高有效位，V1的MSB是B1的MSB。B2包含V1的两个最低有效位、MSB中两个最低有效位中的较高有效位以及V2的六个最高有效位。B1应首先放入RTP包中，B5应最后放入。
Avoiceactivitydetector(VAD)andcomfortnoisegenerator(CNG)algorithminAnnexBofG.729isRECOMMENDEDfordigitalsimultaneousvoiceanddataapplicationsandcanbeusedinconjunctionwithG.729orG.729AnnexA.AG.729orG.729AnnexAframecontains10octets,whiletheG.729AnnexBcomfortnoiseframeoccupies2octets.ReceiversMUSTacceptcomfortnoiseframesifrestrictionoftheirusehasnotbeensignaled.TheMIMEregistrationforG729inRFC3555[7]specifiesaparameterthatMAYbeusedwithMIMEorSDPtorestricttheuseofcomfortnoiseframes.
建议将G.729附录B中的语音活动检测器（VAD）和舒适性噪声发生器（CNG）算法用于数字同步语音和数据应用，并可与G.729或G.729附录A一起使用。AG.729或G.729附录A帧包含10个八位字节，而G.729附录B舒适性噪声帧占用2个八位字节。如果未发出使用限制信号，则接收器必须接受舒适噪音框架。RFC3555[7]中G729的MIME注册指定了一个参数，该参数可与MIME或SDP一起使用，以限制舒适噪声帧的使用。
AG729RTPpacketmayconsistofzeroormoreG.729orG.729AnnexAframes,followedbyzerooroneG.729AnnexBframes.ThepresenceofacomfortnoiseframecanbededucedfromthelengthoftheRTPpayload.Thedefaultpacketizationintervalis20ms(twoframes),butinsomesituationsitmaybedesirabletosend10mspackets.An
G729RTP数据包可以由零个或多个G.729或G.729附录A帧组成，然后是零个或一个G.729附录B帧。舒适性噪声帧的存在可以从RTP有效载荷的长度推断出来。默认分组间隔为20毫秒（两帧），但在某些情况下，可能需要发送10毫秒的分组。一
examplewouldbeatransitionfromspeechtocomfortnoiseinthefirst10msofthepacket.Forsomeapplications,alongerpacketizationintervalmayberequiredtoreducethepacketrate.
例如，在数据包的前10毫秒内，从语音过渡到舒适噪声。对于某些应用，可能需要更长的分组间隔来降低分组速率。
012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|L|L1|L2|L3|P1|P|C1||0|||||0||||0123456|01234|01234|01234567||01234|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C1|S1|GA1|GB1|P2|C2||111|||||||56789012|0123|012|0123|01234|01234567|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C2|S2|GA2|GB2||111|||||89012|0123|012|0123|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|L|L1|L2|L3|P1|P|C1||0|||||0||||0123456|01234|01234|01234567||01234|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C1|S1|GA1|GB1|P2|C2||111|||||||56789012|0123|012|0123|01234|01234567|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C2|S2|GA2|GB2||111|||||89012|0123|012|0123|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure4:G.729andG.729Abitpacking
图4:G.729和G.729A钻头填料
建议G.729表8/G.729中定义了由80位组成的G.729/G.729A10ms帧的传输参数。这些参数的映射如图4所示。图中显示了“网络字节顺序”中的位打包，也称为大端顺序。每个32位字的位编号为0到31，最高有效位在左边，编号为0。每个字的八位字节（字节）首先传输最重要的八位字节。每个数据字段的位按照G.729C代码参考实现产生的顺序进行编号。
ThepackingoftheG.729AnnexBcomfortnoiseframeisshowninFig.5.
图5显示了G.729附录B舒适性噪声框架的包装。
010123456789012345+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|L|LSF1|LSF2|GAIN|R||S||||E||F||||S||0|01234|0123|01234|V|RESV=Reserved(zero)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+010123456789012345+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|L|LSF1|LSF2|GAIN|R||S||||E||F||||S||0|01234|0123|01234|V|RESV=Reserved(zero)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure5:G.729AnnexBbitpacking
图5:G.729附录B钻头填料
AnnexesDandEtoITU-TRecommendationG.729provideadditionaldatarates.Becausethedatarateisnotsignaledinthebitstream,thedifferentdataratesaregivendistinctRTPencodingnameswhicharemappedtodistinctpayloadtypenumbers.G729Dindicatesa6.4kbit/scodingmode(G.729AnnexD,formomentaryreductioninchannelcapacity),whileG729Eindicatesan11.8kbit/smode(G.729AnnexE,forimprovedperformancewithawiderangeofnarrow-bandinputsignals,e.g.,musicandbackgroundnoise).AnnexEhastwooperatingmodes,backwardadaptiveandforwardadaptive,whicharesignaledbythefirsttwobitsineachframe(themostsignificanttwobitsofthefirstoctet).
ITU-T建议G.729的附件D和E提供了额外的数据速率。由于数据速率在比特流中不发信号，不同的数据速率被赋予不同的RTP编码名称，这些名称映射到不同的有效负载类型号。G729D表示6.4kbit/s的编码模式（G.729附录D，用于瞬时降低信道容量），而G729E表示11.8kbit/s模式（G.729附录E，用于改善宽带输入信号的性能，例如音乐和背景噪声）。附录E有两种工作模式，后向自适应和前向自适应，由每个帧中的前两位（第一个八位组的最高有效位）发出信号。
Thevoiceactivitydetector(VAD)andcomfortnoisegenerator(CNG)algorithmspecifiedinAnnexBofG.729maybeusedwithAnnexDandAnnexEframesinadditiontoG.729andG.729AnnexAframes.ThealgorithmdetailsfortheoperationofAnnexesDandEwiththeAnnexBCNGarespecifiedinG.729AnnexesFandG.NotethatAnnexesFandGdonotintroduceanynewencodings.ReceiversMUSTacceptcomfortnoiseframesifrestrictionoftheirusehasnotbeensignaled.TheMIMEregistrationsforG729DandG729EinRFC3555[7]specifyaparameterthatMAYbeusedwithMIMEorSDPtorestricttheuseofcomfortnoiseframes.
除G.729和G.729附录A框架外，G.729附录B中规定的语音活动检测器（VAD）和舒适噪声发生器（CNG）算法可与附录D和附录E框架一起使用。G.729附录F和G中规定了附录D和E与附录BCNG操作的算法细节。请注意，附录F和G未引入任何新编码。如果未发出使用限制信号，则接收器必须接受舒适噪音框架。RFC3555[7]中G729D和G729E的MIME注册指定了一个参数，该参数可与MIME或SDP一起使用，以限制舒适噪声帧的使用。
ForG729D,anRTPpacketmayconsistofzeroormoreG.729AnnexDframes,followedbyzerooroneG.729AnnexBframe.Similarly,forG729E,anRTPpacketmayconsistofzeroormoreG.729AnnexEframes,followedbyzerooroneG.729AnnexBframe.ThepresenceofacomfortnoiseframecanbededucedfromthelengthoftheRTPpayload.
对于G729D，RTP数据包可以由零个或多个G.729附录D帧组成，然后是零个或一个G.729附录B帧。类似地，对于G729E，RTP分组可以由零个或多个G.729附件E帧组成，然后是零个或一个G.729附件B帧。舒适性噪声帧的存在可以从RTP有效载荷的长度推断出来。
AsingleRTPpacketmustcontainframesofonlyonedatarate,optionallyfollowedbyonecomfortnoiseframe.Thedataratemaybechangedfrompackettopacketbychangingthepayloadtypenumber.G.729AnnexesD,EandHdescribewhattheencodinganddecodingalgorithmsmustdotoaccommodateachangeindatarate.
单个RTP数据包必须仅包含一个数据速率的帧，可选地后跟一个舒适噪声帧。通过改变有效载荷类型号，可以在分组之间改变数据速率。G.729附录D、E和H描述了编码和解码算法必须做什么以适应数据速率的变化。
ForG729D,thebitsofaG.729AnnexDframeareformattedasshownbelowinFig.6(cf.TableD.1/G.729).Theframelengthis64bits.
对于G729D，G.729附录D帧的位的格式如图6所示（参见表D.1/G.729）。帧长度为64位。
012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|L|L1|L2|L3|P1|C1||0||||||||0123456|01234|01234|01234567|012345|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C1|S1|GA1|GB1|P2|C2|S2|GA2|GB2||||||||||||678|01|012|012|0123|012345678|01|012|012|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|L|L1|L2|L3|P1|C1||0||||||||0123456|01234|01234|01234567|012345|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C1|S1|GA1|GB1|P2|C2|S2|GA2|GB2||||||||||||678|01|012|012|0123|012345678|01|012|012|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure6:G.729AnnexDbitpacking
图6:G.729附录D钻头填料
G.729附录E算法的净比特率为11.8kbit/s，总共使用118位。两个位被附加为“不关心”位，以完成该帧的整数个八位字节。对于G729E，数据帧的位的格式如下面两个图所示（参见表E.1/G.729）。G729E前向自适应模式的字段如图7所示进行压缩。
图7:G.729附录E（前向自适应模式）位封装
ThefieldsfortheG729EbackwardadaptivemodearepackedasshowninFig.8.
G729E向后自适应模式的字段如图8所示进行压缩。
图8:G.729附录E（后向自适应模式）位打包
GSM(GroupSpecialeMobile)denotestheEuropeanGSM06.10standardforfull-ratespeechtranscoding,ETS300961,whichisbasedonRPE/LTP(residualpulseexcitation/longtermprediction)codingatarateof13kb/s[11,12,13].Thetextofthestandardcanbeobtainedfrom:
GSM（SpecialeMobile集团）表示欧洲GSM06.10全速率语音转码标准ETS300961，该标准基于13kb/s速率的RPE/LTP（剩余脉冲激励/长期预测）编码[11,12,13]。本标准的文本可从以下网址获得：
ETSI(EuropeanTelecommunicationsStandardsInstitute)ETSISecretariat:B.P.152F-06561ValbonneCedexFrancePhone:+3392944200Fax:+3393654716
Blocksof160audiosamplesarecompressedinto33octets,foraneffectivedatarateof13,200b/s.
160个音频样本块压缩为33个八位字节，有效数据速率为13200b/s。
TheGSMstandard(ETS300961)specifiesthebitstreamproducedbythecodec,butdoesnotspecifyhowthesebitsshouldbepackedfortransmission.ThepacketizationspecifiedherehassubsequentlybeenadoptedinETSITechnicalSpecificationTS101318.SomesoftwareimplementationsoftheGSMcodecuseadifferentpackingthanthatspecifiedhere.
GSM标准（ETS300961）规定了编解码器产生的比特流，但未规定这些比特应如何打包以进行传输。ETSI技术规范TS101318随后采用了此处规定的包装。GSM编解码器的某些软件实现使用与此处指定的不同的包装。
表2:GSM变量的排序
表3:GSM有效载荷格式
IntheGSMpackingusedbyRTP,thebitsSHALLbepackedbeginningfromthemostsignificantbit.Every160sampleGSMframeiscodedintoone33octet(264bit)buffer.Everysuchbufferbeginswitha4bitsignature(0xD),followedbytheMSBencodingofthefieldsoftheframe.Thefirstoctetthuscontains1101inthe4mostsignificantbits(0-3)andthe4mostsignificantbitsofF1(0-3)inthe4leastsignificantbits(4-7).Thesecondoctetcontainsthe2leastsignificantbitsofF1inbits0-1,andF2inbits2-7,andsoon.TheorderofthefieldsintheframeisdescribedinTable2.
在RTP使用的GSM包装中，应从最高有效位开始包装位。每160个采样GSM帧被编码到一个33八位组（264位）缓冲器中。每个这样的缓冲区都以4位签名（0xD）开始，然后是帧字段的MSB编码。因此，第一个八位组在4个最高有效位（0-3）中包含1101，在4个最低有效位（4-7）中包含F1（0-3）的4个最高有效位。第二个八位组包含位0-1中F1的2个最低有效位和位2-7中F2的2个最低有效位，依此类推。框架中字段的顺序如表2所示。
IntheRTPencodingwehavethebitpatterndescribedinTable3,whereF.isignifiestheithbitofthefieldF,bit0isthemostsignificantbit,andthebitsofeveryoctetarenumberedfrom0to7frommosttoleastsignificant.
在RTP编码中，我们有表3中描述的位模式，其中F.i表示字段F的第i位，位0是最高有效位，每个八位组的位从0到7从最高有效到最低有效进行编号。
GSM-EFRdenotesGSM06.60enhancedfullratespeechtranscoding,specifiedinETS300726whichisavailablefromETSIattheaddressgiveninSection4.5.8.Thiscodechasaframelengthof244bits.FortransmissioninRTP,eachcodecframeispackedintoa31octet(248bit)bufferbeginningwitha4-bitsignature0xCinamannersimilartothatspecifiedherefortheoriginalGSM06.10codec.ThepackingisspecifiedinETSITechnicalSpecificationTS101318.
GSM-EFR表示ETS300726中规定的GSM06.60增强全速率语音转码，可从ETSI获得，地址见第4.5.8节。此编解码器的帧长度为244位。对于RTP中的传输，每个编解码器帧以类似于此处为原始GSM06.10编解码器指定的方式打包到以4位签名0xC开头的31八位组（248位）缓冲区中。ETSI技术规范TS101318中规定了包装。
L8denoteslinearaudiodatasamples,using8-bitsofprecisionwithanoffsetof128,thatis,themostnegativesignalisencodedaszero.
L8表示线性音频数据样本，使用偏移量为128的8位精度，也就是说，最负的信号编码为零。
L16表示未压缩的音频数据样本，使用16位有符号表示，最小和最大信号电平之间有65535个等分步长，范围从-32768到32767。该值以2的补码表示，并以网络字节顺序传输（最高有效字节优先）。
TheMIMEregistrationforL16inRFC3555[7]specifiesparametersthatMAYbeusedwithMIMEorSDPtoindicatethatanalogpre-emphasiswasappliedtothesignalbeforequantizationortoindicatethatamultiple-channelaudiostreamfollowsadifferentchannelorderingconventionthanisspecifiedinSection4.1.
RFC3555[7]中L16的MIME注册规定了可与MIME或SDP一起使用的参数，以指示量化前对信号应用了模拟预加重，或指示多声道音频流遵循与第4.1节规定不同的声道顺序约定。
LPCdesignatesanexperimentallinearpredictiveencodingcontributedbyRonFrederick,whichisbasedonanimplementationwrittenbyRonZuckermanpostedtotheUsenetgroupcomp.dsponJune26,1992.Thecodecgenerates14octetsforeveryframe.Theframesizeissetto20ms,resultinginabitrateof5,600b/s.
LPC指定了一种由RonFrederick贡献的实验性线性预测编码，该编码基于RonZuckerman于1992年6月26日发布到Usenetgroupcomp.dsp的实现。编解码器为每帧生成14个八位字节。帧大小设置为20毫秒，导致比特率为5600b/s。
MPAdenotesMPEG-1orMPEG-2audioencapsulatedaselementarystreams.TheencodingisdefinedinISOstandardsISO/IEC11172-3and13818-3.TheencapsulationisspecifiedinRFC2250[14].
MPA表示封装为基本流的MPEG-1或MPEG-2音频。编码在ISO标准ISO/IEC11172-3和13818-3中定义。RFC2250[14]中规定了封装。
TheMIMEregistrationforMPAinRFC3555[7]specifiesparametersthatMAYbeusedwithMIMEorSDPtorestricttheselectionoflayer,channelcount,samplingrate,andbitrate.
RFC3555[7]中MPA的MIME注册指定了可与MIME或SDP一起使用的参数，以限制层、通道计数、采样率和比特率的选择。
PCMAandPCMUarespecifiedinITU-TRecommendationG.711.Audiodataisencodedaseightbitspersample,afterlogarithmicscaling.PCMUdenotesmu-lawscaling,PCMAA-lawscaling.AdetaileddescriptionisgivenbyJayantandNoll[15].EachG.711octetSHALLbeoctet-alignedinanRTPpacket.ThesignbitofeachG.711octetSHALLcorrespondtothemostsignificantbitoftheoctetintheRTPpacket(i.e.,assumingtheG.711samplesarehandledasoctetsonthehostmachine,thesignbitSHALLbethemostsignificantbitoftheoctetasdefinedbythehostmachineformat).The56kb/sand48kb/smodesofG.711arenotapplicabletoRTP,sincePCMAandPCMUMUSTalwaysbetransmittedas8-bitsamples.
PCMA和PCMU在ITU-T建议G.711中有规定。经过对数缩放后，音频数据被编码为每个样本8位。PCMU表示mu定律标度，PCMA表示A定律标度。Jayant和Noll[15]给出了详细说明。每个G.711八位字节应在RTP数据包中对齐。每个G.711八位字节的符号位应对应于RTP数据包中八位字节的最高有效位（即，假设G.711样本在主机上作为八位字节处理，符号位应为主机格式定义的八位字节的最高有效位）。G.711的56kb/s和48kb/s模式不适用于RTP，因为PCMA和PCMU必须始终作为8位样本传输。
SeeSection4.1regardingsilencesuppression.
关于静音抑制，见第4.1节。
电子工业协会（EIA）和电信工业协会（TIA）标准IS-733“TR45：宽带扩频通信系统的高速语音服务选项”，定义了无线CDMA应用中使用的QCELP音频压缩算法。QCELP编解码器将8000Hz的每20毫秒16位采样输入语音压缩为四个不同大小的输出帧之一：速率1（266位）、速率1/2（124位）、速率1/4（54位）或速率1/8（20位）。对于典型的语音模式，正常模式的平均输出为6.8kb/s，而低速模式的平均输出为4.7kb/s。[16]中描述了QCELP音频编解码器的打包。
冗余音频有效负载格式“红色”由RFC2198[17]规定。它定义了一种方法，通过该方法，可以在单个RTP流中传输音频分组的多个冗余副本。这样的流中的每个分组除了包含该分组化间隔的音频数据外，还包含来自先前分组化间隔的数据的（更严重压缩的）副本。这允许在解码后续分组时恢复来自丢失分组的数据的近似值，与丢失分组的静音替换相比，提供了更高的音质。
VDVIisavariable-rateversionofDVI4,yieldingspeechbitratesofbetween10and25kb/s.Itisspecifiedforsingle-channeloperationonly.Samplesarepackedintooctetsstartingatthemost-significantbit.Thelastoctetispaddedwith1bitsifthelastsampledoesnotfillthelastoctet.Thispaddingisdistinctfromthevalidcodewords.Thereceiverneedstodetectthepaddingbecausethereisnoexplicitcountofsamplesinthepacket.
VDVI是DVI4的可变速率版本，产生10到25kb/s的语音比特率。它仅指定用于单通道操作。样本从最高有效位开始打包到八位字节中。如果最后一个样本未填充最后一个八位字节，则最后一个八位字节填充1位。此填充不同于有效的码字。接收器需要检测填充，因为数据包中没有明确的样本计数。
Itusesthefollowingencoding:
它使用以下编码：
DVI4codewordVDVIbitpattern_______________________________000101021100311100411110051111100611111100711111110810901110110111111011211110113111110114111111011511111111DVI4codewordVDVIbitpattern_______________________________0001010211003111004111100511111006111111007111111108109011101101111110112111101131111101141111110115111111115.Video5.视频Thefollowingsectionsdescribethevideoencodingsthataredefinedinthismemoandgivetheirabbreviatednamesusedforidentification.ThesevideoencodingsandtheirpayloadtypesarelistedinTable5.
以下各节描述了本备忘录中定义的视频编码，并给出了用于识别的缩写名称。表5列出了这些视频编码及其有效负载类型。
AllofthesevideoencodingsuseanRTPtimestampfrequencyof90,000Hz,thesameastheMPEGpresentationtimestampfrequency.Thisfrequencyyieldsexactintegertimestampincrementsforthetypical24(HDTV),25(PAL),and29.97(NTSC)and30Hz(HDTV)frameratesand50,59.94and60Hzfieldrates.While90kHzistheRECOMMENDEDrateforfuturevideoencodingsusedwithinthisprofile,otherratesMAYbeused.However,itisnotsufficienttousethevideoframerate(typicallybetween15and30Hz)becausethatdoesnotprovideadequateresolutionfortypicalsynchronizationrequirementswhencalculatingtheRTPtimestampcorrespondingtotheNTPtimestampinanRTCPSRpacket.ThetimestampresolutionMUSTalsobesufficientforthejitterestimatecontainedinthereceiverreports.
Formostofthesevideoencodings,theRTPtimestampencodesthesamplinginstantofthevideoimagecontainedintheRTPdatapacket.Ifavideoimageoccupiesmorethanonepacket,thetimestampisthesameonallofthosepackets.Packetsfromdifferentvideoimagesaredistinguishedbytheirdifferenttimestamps.
MostofthesevideoencodingsalsospecifythatthemarkerbitoftheRTPheaderSHOULDbesettooneinthelastpacketofavideoframeandotherwisesettozero.Thus,itisnotnecessarytowaitforafollowingpacketwithadifferenttimestamptodetectthatanewframeshouldbedisplayed.
TheCELL-BencodingisaproprietaryencodingproposedbySunMicrosystems.ThebytestreamformatisdescribedinRFC2029[18].
CELL-B编码是SunMicrosystems提出的专有编码。RFC2029[18]中描述了字节流格式。
TheencodingisspecifiedinISOStandards10918-1and10918-2.TheRTPpayloadformatisasspecifiedinRFC2435[19].
ISO标准10918-1和10918-2中规定了编码。RTP有效负载格式如RFC2435[19]所述。
ITU-T建议H.261“px64kbit/s视听服务的视频编解码器”中规定了编码。RFC2032[20]中描述了封装和RTP特定属性。
1996年版本的ITU-T建议H.263“低比特率通信的视频编码”中规定了编码。RFC2190[21]中描述了封装和RTP特定属性。建议新实施使用H263-1998有效负载格式，而不是此格式。
1998年版本的ITU-T建议H.263“低比特率通信的视频编码”中规定了编码。RFC2429[22]中描述了封装和RTP特定属性。由于H.263的1998版本是1996年语法的超集，因此此有效负载格式也可以与1996年版本的H.263一起使用，并建议新的实现使用此格式。此有效负载格式不会取代RFC2190，现有实现仍在使用RFC2190，新实现中的向后兼容性可能需要RFC2190。使用1998版H.263新功能的实现必须使用RFC2429中描述的有效负载格式。
MPVdesignatestheuseofMPEG-1andMPEG-2videoencodingelementarystreamsasspecifiedinISOStandardsISO/IEC11172and13818-2,respectively.TheRTPpayloadformatisasspecifiedinRFC2250[14],Section3.
MPV分别指定使用ISO标准ISO/IEC11172和13818-2中规定的MPEG-1和MPEG-2视频编码基本流。RTP有效载荷格式如RFC2250[14]第3节所述。
TheMIMEregistrationforMPVinRFC3555[7]specifiesaparameterthatMAYbeusedwithMIMEorSDPtorestricttheselectionofthetypeofMPEGvideo.
RFC3555[7]中MPV的MIME注册指定了一个参数，该参数可与MIME或SDP一起使用，以限制MPEG视频类型的选择。
MP2TdesignatestheuseofMPEG-2transportstreams,foreitheraudioorvideo.TheRTPpayloadformatisdescribedinRFC2250[14],Section2.
MP2T指定对音频或视频使用MPEG-2传输流。RTP有效载荷格式在RFC2250[14]第2节中描述。
该编码在由RonFrederick在施乐PARC开发的第4版“nv”程序中实现。可从作者处获得更多信息：
RonFrederickBlueCoatSystemsInc.650AlmanorAvenueSunnyvale,CA94085UnitedStatesEMail:ronf@bluecoat.com
RonFrederickBlueCoatSystemsInc.加利福尼亚州桑尼维尔阿尔马诺大道650号，邮编94085美国电子邮件：ronf@bluecoat.com
表4和表5为RTP数据头的PT字段定义了该配置文件的静态有效负载类型值。此外，范围96-127中的有效载荷类型值可以通过会议控制协议动态定义，这超出了本文档的范围。例如，会话目录可以指定对于给定会话，有效负载类型96表示PCMU编码，8000Hz采样率，2个信道。表4和表5中有效负载类型为“dyn”的条目未分配静态有效负载类型，仅与动态有效负载类型一起使用。有效载荷类型2在RFC1890中分配给G721，在本规范草案版本中分配给其等效的后续版本G726-32，但其使用现在已被弃用，并且由于有效载荷格式G726-32和AAL2-G726-32的使用冲突，该静态有效载荷类型被标记为保留（见第4.5.4节）。有效载荷类型13表示RFC3389[9]中规定的舒适性噪声（CN）有效载荷格式。有效载荷类型19标记为“保留”，因为本规范的某些草案版本将该编号指定给舒适性噪声有效载荷格式的早期版本。有效负载类型范围72-76标记为“保留”，以便可以可靠地区分RTCP和RTP数据包（请参阅RTP协议规范的“协议常数摘要”一节）。
此配置文件中当前定义的有效负载类型仅分配给三个类别或媒体类型中的一个：仅音频、仅视频和音频与视频相结合的类别或媒体类型。表4和表5分别将介质类型标记为“A”、“V”和“AV”。不同媒体类型的有效负载类型不得在单个RTP会话中交错或复用，但多个RTP会话可并行使用以发送多个媒体类型。RTP源可以在会话期间更改同一媒体类型内的有效负载类型。有关更多说明，请参阅RFC3550的“多路传输RTP会话”一节。
表4：音频编码的有效负载类型（PT）
PTencodingmediatypeclockratename(Hz)_____________________________________________24unassignedV25CelBV90,00026JPEGV90,00027unassignedV28nvV90,00029unassignedV30unassignedV31H261V90,00032MPVV90,00033MP2TAV90,00034H263V90,00035-71unassigned72-76reservedN/AN/A77-95unassigned96-127dynamicdynH263-1998V90,000PTencodingmediatypeclockratename(Hz)_____________________________________________24unassignedV25CelBV90,00026JPEGV90,00027unassignedV28nvV90,00029unassignedV30unassignedV31H261V90,00032MPVV90,00033MP2TAV90,00034H263V90,00035-71unassigned72-76reservedN/AN/A77-95unassigned96-127dynamicdynH263-1998V90,000Table5:Payloadtypes(PT)forvideoandcombinedencodings
表5：视频和组合编码的有效负载类型（PT）
Sessionparticipantsagreethroughmechanismsbeyondthescopeofthisspecificationonthesetofpayloadtypesallowedinagivensession.ThissetMAY,forexample,bedefinedbythecapabilitiesoftheapplicationsused,negotiatedbyaconferencecontrolprotocolorestablishedbyagreementbetweenthehumanparticipants.
会话参与者通过超出本规范范围的机制就给定会话中允许的有效负载类型集达成一致。例如，该集合可以由所使用的应用程序的能力定义，由会议控制协议协商或由人类参与者之间的协议建立。
AudioapplicationsoperatingunderthisprofileSHOULD,ataminimum,beabletosendand/orreceivepayloadtypes0(PCMU)and5(DVI4).Thisallowsinteroperabilitywithoutformatnegotiationandensuressuccessfulnegotiationwithaconferencecontrolprotocol.
在此配置文件下运行的音频应用程序应至少能够发送和/或接收有效负载类型0（PCMU）和5（DVI4）。这允许互操作性而无需格式协商，并确保与会议控制协议的协商成功。
Underspecialcircumstances,itmaybenecessarytocarryRTPinprotocolsofferingabytestreamabstraction,suchasTCP,possiblymultiplexedwithotherdata.TheapplicationMUSTdefineitsownmethodofdelineatingRTPandRTCPpackets(RTSP[23]providesanexampleofsuchanencapsulationspecification).
在特殊情况下，可能需要在提供字节流抽象的协议（如TCP）中承载RTP，该协议可能与其他数据多路复用。应用程序必须定义自己描述RTP和RTCP数据包的方法（RTSP[23]提供了此类封装规范的示例）。
AsspecifiedintheRTPprotocoldefinition,RTPdataSHOULDbecarriedonanevenUDPportnumberandthecorrespondingRTCPpacketsSHOULDbecarriedonthenexthigher(odd)portnumber.
按照RTP协议定义中的规定，RTP数据应在偶数UDP端口号上传输，相应的RTCP数据包应在下一个更高（奇数）端口号上传输。
ApplicationsoperatingunderthisprofileMAYuseanysuchUDPportpair.Forexample,theportpairMAYbeallocatedrandomlybyasessionmanagementprogram.Asinglefixedportnumberpaircannotberequiredbecausemultipleapplicationsusingthisprofilearelikelytorunonthesamehost,andtherearesomeoperatingsystemsthatdonotallowmultipleprocessestousethesameUDPportwithdifferentmulticastaddresses.
在此配置文件下运行的应用程序可以使用任何此类UDP端口对。例如，端口对可以由会话管理程序随机分配。不需要单个固定端口号对，因为使用此配置文件的多个应用程序可能在同一主机上运行，并且有些操作系统不允许多个进程使用具有不同多播地址的同一UDP端口。
However,portnumbers5004and5005havebeenregisteredforusewiththisprofileforthoseapplicationsthatchoosetousethemasthedefaultpair.ApplicationsthatoperateundermultipleprofilesMAYusethisportpairasanindicationtoselectthisprofileiftheyarenotsubjecttotheconstraintofthepreviousparagraph.ApplicationsneednothaveadefaultandMAYrequirethattheportpairbeexplicitlyspecified.Theparticularportnumberswerechosentolieintherangeabove5000toaccommodateportnumberallocationpracticewithinsomeversionsoftheUnixoperatingsystem,whereportnumbersbelow1024canonlybeusedbyprivilegedprocessesandportnumbersbetween1024and5000areautomaticallyassignedbytheoperatingsystem.
但是，对于选择将端口号5004和5005用作默认对的应用程序，端口号5004和5005已注册为此配置文件使用。在多个配置文件下运行的应用程序可以使用此端口对作为选择此配置文件的指示，如果它们不受上一段的约束。应用程序不需要有默认值，可能需要显式指定端口对。选择的特定端口号在5000以上的范围内，以适应Unix操作系统某些版本中的端口号分配实践，其中1024以下的端口号只能由特权进程使用，1024到5000之间的端口号由操作系统自动分配。
ThisRFCrevisesRFC1890.Itismostlybackwards-compatiblewithRFC1890exceptforfunctionsremovedbecausetwointeroperableimplementationswerenotfound.TheadditionstoRFC1890codifyexistingpracticeintheuseofpayloadformatsunderthisprofile.Sincethisprofilemaybeusedwithoutusinganyofthepayloadformatslistedhere,theadditionofnewpayloadformatsinthisrevisiondoesnotaffectbackwardscompatibility.Thechangesarelistedbelow,categorizedintofunctionalandnon-functionalchanges.
本RFC修订了RFC1890。除了由于找不到两个可互操作的实现而删除的函数外，它主要与RFC1890向后兼容。RFC1890的新增内容编纂了本概要下有效载荷格式使用的现有实践。由于可以在不使用此处列出的任何有效负载格式的情况下使用此配置文件，因此在本版本中添加新的有效负载格式不会影响向后兼容性。变更如下所示，分为功能性变更和非功能性变更。
Functionalchanges:
功能变化：
o增加了第11节“IANA注意事项”，以指定此配置文件的名称注册。该附录还引用了新的第3节“注册附加编码”，该节确立了一项政策，即除了本修订版中添加的以及表4和表5中包含的静态有效负载类型外，不会对该配置文件进行额外的静态有效负载类型注册。相反，可以将其他编码名称注册为MIME子类型，以便绑定到动态负载类型。RFC3555[7]中添加了非规范性引用，其中注册了所有列出的有效负载格式的MIME子类型，其中一些具有用于有效负载格式的可选参数。
oStaticpayloadtypes4,16,17and34wereaddedtoincorporateIANAregistrationsmadesincethepublicationofRFC1890,alongwiththecorrespondingpayloadformatdescriptionsforG723andH263.
o添加了静态有效负载类型4、16、17和34，以合并自RFC1890发布以来进行的IANA注册，以及G723和H263的相应有效负载格式说明。
oFollowingworkinggroupdiscussion,staticpayloadtypes12and18wereaddedalongwiththecorrespondingpayloadformatdescriptionsforQCELPandG729.Staticpayloadtype13wasassignedtotheComfortNoise(CN)payloadformatdefinedinRFC3389.Payloadtype19wasmarkedreservedbecauseithadbeentemporarilyallocatedtoanearlierversionofComfortNoisepresentinsomedraftrevisionsofthisdocument.
o在工作组讨论之后，添加了静态有效负载类型12和18以及QCELP和G729的相应有效负载格式说明。静态有效载荷类型13被指定为RFC3389中定义的舒适性噪声（CN）有效载荷格式。有效载荷类型19被标记为保留，因为它已临时分配给本文件某些修订草案中存在的早期版本的舒适性噪音。
oThepayloadformatforG721wasrenamedtoG726-32followingtheITU-Trenumbering,andthepayloadformatdescriptionforG726wasexpandedtoincludethe-16,-24and-40datarates.Becauseofconfusionregardingdraftrevisionsofthisdocument,someimplementationsoftheseG726payloadformatspackedsamplesintooctetsstartingwiththemostsignificantbitratherthantheleastsignificantbitasspecifiedhere.Topartiallyresolvethisincompatibility,newpayloadformatsnamedAAL2-G726-16,-24,-32and-40willbespecifiedinaseparatedocument(seenoteinSection4.5.4),anduseofstaticpayloadtype2isdeprecatedasexplainedinSection6.
o在ITU-T重新编号后，G721的有效载荷格式被重命名为G726-32，G726的有效载荷格式描述被扩展为包括-16、-24和-40数据速率。由于对本文件草案修订的混淆，这些G726有效负载格式的一些实现将样本打包成八位字节，从最高有效位开始，而不是此处指定的最低有效位。为了部分解决此不兼容问题，将在单独的文档中指定名为AAL2-G726-16、-24、-32和-40的新有效负载格式（参见第4.5.4节中的注释），并且如第6节所述，不推荐使用静态有效负载类型2。
oPayloadformatsG729DandG729EwereaddedfollowingtheITU-TadditionofAnnexesDandEtoRecommendationG.729.ListingswereaddedforpayloadformatsGSM-EFR,RED,andH263-1998publishedinotherdocumentssubsequenttoRFC1890.Theseadditionalpayloadformatsarereferencedonlybydynamicpayloadtypenumbers.
o有效载荷格式G729D和G729E是在ITU-T将附件D和E添加到建议G.729之后添加的。在RFC1890之后的其他文件中，添加了有效载荷格式GSM-EFR、RED和H263-1998的列表。这些附加有效负载格式仅由动态有效负载类型编号引用。
oThedescriptionsofthepayloadformatsforG722,G728,GSM,VDVIwereexpanded.
o扩展了G722、G728、GSM和VDVI的有效载荷格式描述。
o1016音频的有效负载格式已删除，其静态有效负载类型分配1标记为“保留”，因为未找到两个可互操作的实现。
oRequirementsforcongestioncontrolwereaddedinSection2.
o第2节增加了拥塞控制要求。
oThisprofilefollowsthesuggestionintherevisedRTPspecthatRTCPbandwidthmaybespecifiedseparatelyfromthesessionbandwidthandseparatelyforactivesendersandpassivereceivers.
o此配置文件遵循修订的RTP规范中的建议，即RTCP带宽可以与会话带宽分开指定，并且可以分别为主动发送方和被动接收方指定。
oThemappingofauserpass-phrasestringintoanencryptionkeywasdeletedfromSection2becausetwointeroperableimplementationswerenotfound.
o用户密码短语字符串到加密密钥的映射已从第2节中删除，因为未找到两个可互操作的实现。
o删除了四声道音频的“四声道”样本排序约定，以消除第4.1节所述的歧义。
Non-functionalchanges:
非功能性变化：
o在第4.1节中，现在明确指出，所有音频有效负载格式都允许静音抑制。（这种情况一直存在，并且源于RTP设计的一个基本方面和分组音频的动机，但之前没有明确说明。）还解释了舒适性噪声的使用。
o在第4.1节中，将音频静音后第一个数据包上标记位设置的要求级别从“是”更改为“应该”，并阐明仅当有意不发送数据包时才设置标记位。
oSimilarly,textwasaddedtospecifythatthemarkerbitSHOULDbesettooneonthelastpacketofavideoframe,andthatvideoframesaredistinguishedbytheirtimestamps.
oRFCreferencesareaddedforpayloadformatspublishedafterRFC1890.
oRFC参考是为RFC1890之后发布的有效负载格式添加的。
oThesecurityconsiderationsandfullcopyrightsectionswereadded.
oAccordingtoPeterHoddieofApple,onlypre-1994Macintoshusedthe22254.54rateandnonethe11127.27rate,sothelatterwasdroppedfromthediscussionofsuggestedsamplingfrequencies.
o根据苹果公司的彼得·霍迪（PeterHoddie）的说法，只有1994年以前的Macintosh使用22254.54的速率，而11127.27的速率则没有，因此后者被从建议采样频率的讨论中删除。
o对表1进行了更正，将一些值从“ms/packet”列移到它们所属的“defaultms/packet”列。
oSincetheInteractiveMultimediaAssociationceasedoperations,analternateresourcewasprovidedforareferencedIMAdocument.
o由于交互式多媒体协会停止运作，为参考的IMA文件提供了替代资源。
oAnotehasbeenaddedforG722toclarifyadiscrepancybetweentheactualsamplingrateandtheRTPtimestampclockrate.
oSmallclarificationsofthetexthavebeenmadeinseveralplaces,someinresponsetoquestionsfromreaders.Inparticular:
o一些地方对文本作了一些小的澄清，有些地方是为了回答读者的问题。特别地：
-第1.1节给出了“媒体类型”的定义，以使第6节中关于多路复用RTP会话的解释更清楚地说明多路复用多个媒体。
-Theexplanationofhowtodeterminethenumberofaudioframesinapacketfromthelengthwasexpanded.
-关于如何根据长度确定数据包中的音频帧数的解释进行了扩展。
-MoredescriptionoftheallocationofbandwidthtoSDESitemsisgiven.
-给出了SDES项目带宽分配的更多描述。
-AnotewasaddedthattheconventionfortheorderofchannelsspecifiedinSection4.1maybeoverriddenbyaparticularencodingorpayloadformatspecification.
-增加了一条注释，即第4.1节中规定的信道顺序约定可由特定编码或有效载荷格式规范覆盖。
-ThetermsMUST,SHOULD,MAY,etc.areusedasdefinedinRFC2119.
-术语“必须”、“应该”、“可以”等按照RFC2119中的定义使用。
oAsecondauthorforthisdocumentwasadded.
o已添加此文档的第二位作者。
ImplementationsusingtheprofiledefinedinthisspecificationaresubjecttothesecurityconsiderationsdiscussedintheRTPspecification[1].Thisprofiledoesnotspecifyanydifferentsecurityservices.Theprimaryfunctionofthisprofileistolistasetofdatacompressionencodingsforaudioandvideomedia.
使用本规范中定义的概要文件的实现受RTP规范[1]中讨论的安全注意事项的约束。此配置文件未指定任何不同的安全服务。此配置文件的主要功能是列出音频和视频媒体的一组数据压缩编码。
Confidentialityofthemediastreamsisachievedbyencryption.Becausethedatacompressionusedwiththepayloadformatsdescribedinthisprofileisappliedend-to-end,encryptionmaybeperformedaftercompressionsothereisnoconflictbetweenthetwooperations.
媒体流的机密性是通过加密实现的。由于与此概要文件中描述的有效负载格式一起使用的数据压缩是端到端应用的，因此可以在压缩之后执行加密，因此两个操作之间没有冲突。
Apotentialdenial-of-servicethreatexistsfordataencodingsusingcompressiontechniquesthathavenon-uniformreceiver-endcomputationalload.Theattackercaninjectpathologicaldatagramsintothestreamwhicharecomplextodecodeandcausethereceivertobeoverloaded.
使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向流中注入病理数据报，这些数据报解码复杂，并导致接收器过载。
AswithanyIP-basedprotocol,insomecircumstancesareceivermaybeoverloadedsimplybythereceiptoftoomanypackets,eitherdesiredorundesired.Network-layerauthenticationMAYbeusedtodiscardpacketsfromundesiredsources,buttheprocessingcostoftheauthenticationitselfmaybetoohigh.Inamulticastenvironment,sourcepruningisimplementedinIGMPv3(RFC3376)[24]andinmulticastroutingprotocolstoallowareceivertoselectwhichsourcesareallowedtoreachit.
与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。在多播环境中，源修剪在IGMPv3（RFC3376）[24]和多播路由协议中实现，以允许接收器选择允许到达它的源。
RTP规范建立了一个配置文件名称注册表，供更高级别的控制协议使用，如会话描述协议（SDP），RFC2327[6]，以引用传输方法。此配置文件注册名称“RTP/AVP”。
第3节确立了一项政策，即除了本文件修订版中添加并包含在表4和表5中的静态RTP有效负载类型外，不会对该概要文件的静态RTP有效负载类型进行额外注册。IANA可在拒绝接受任何其他注册请求时参考该部分。在表4和表5中，请注意类型1和2已标记为保留，并且包含的“dyn”有效负载类型集已更新。第6节和第9节解释了这些变化。
[1]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC35502003年7月。
[2]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP14，RFC2119，1997年3月。
[3]苹果计算机，“音频交换文件格式AIFF-C”，1991年8月。（也ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).
[4]Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC16331994年6月。
[5]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC24751998年12月。
[6]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC2327，1998年4月。
[7]Casner，S.和P.Hoschka，“RTP有效载荷类型的MIME类型注册”，RFC3555，2003年7月。
[8]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP13，RFC2048，1996年11月。
[9]Zopf，R.，“舒适噪声（CN）的实时传输协议（RTP）有效载荷”，RFC3389，2002年9月。
[10]Deleam，D.和J.-P.Petit，“最新ITU-T低比特率语音编码器在TITMS320C54XDSP上的实时实现：结果、方法和应用”，摘自Proc。国际信号处理、技术和应用会议（ICSPAT）（马萨诸塞州波士顿），第1656-1660页，1996年10月。
[11]Mouly,M.andM.-B.Pautet,TheGSMsystemformobilecommunicationsLassay-les-Chateaux,France:EuropeMediaDuplication,1993.
[11]Mouly，M.和M.-B.Pautet，《移动通信GSM系统拉赛城堡》，法国：欧洲媒体复制，1993年。
[12]Degener，J.，“数字语音压缩”，Dobb博士期刊，1994年12月。
[13]Redl,S.,Weber,M.andM.Oliphant,AnIntroductiontoGSMBoston:ArtechHouse,1995.
[13]雷德尔，S.，韦伯，M.和M.奥列芬特，《波士顿GSM导论：阿泰奇之家》，1995年。
[14]Hoffman，D.，Fernando，G.，Goyal，V.和M.Civanlar，“MPEG1/MPEG2视频的RTP有效载荷格式”，RFC2250，1998年1月。
[15]Jayant,N.andP.Noll,DigitalCodingofWaveforms--PrinciplesandApplicationstoSpeechandVideoEnglewoodCliffs,NewJersey:Prentice-Hall,1984.
[15]Jayant，N.和P.Noll，《波形的数字编码——语音和视频的原理和应用》，新泽西州恩格伍德悬崖：普伦蒂斯大厅，1984年。
[16]McKay，K.，“PureVoice（tm）音频的RTP有效载荷格式”，RFC2658，1999年8月。
[17]帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.-C.，维加·加西亚，A.和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC21981997年9月。
[18]Speer，M.和D.Hoffman，“SunCellB视频编码的RTP有效载荷格式”，RFC2029，1996年10月。
[19]Berc，L.，Fenner，W.，Frederick，R.，McCanne，S.和P.Stewart，“JPEG压缩视频的RTP有效载荷格式”，RFC2435，1998年10月。
[20]Turletti，T.和C.Huitema，“H.261视频流的RTP有效载荷格式”，RFC2032，1996年10月。
[21]朱，C，“H.263视频流的RTP有效载荷格式”，RFC2190，1997年9月。
[22]Bormann，C.，Cline，L.，Deisher，G.，Gardos，T.，Maciocco，C.，Newell，D.，Ott，J.，Sullivan，G.，Wenger，S.和C.Zhu，“1998版ITU-TRec.H.263视频（H.263+）的RTP有效载荷格式”，RFC24291998年10月。
[23]Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[24]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.和A.Thyagarajan，“互联网组管理协议，第3版”，RFC3376，2002年10月。
DVI4
AnarchivedcopyofthedocumentIMARecommendedPracticesforEnhancingDigitalAudioCompatibilityinMultimediaSystems(version3.0),whichdescribestheIMAADPCMalgorithm,isavailableat:
描述IMAADPCM算法的文件《IMA增强多媒体系统中数字音频兼容性的推荐做法》（3.0版）的存档副本可从以下网址获得：
JackJansen提供了一个实现，网址为
ftp://ftp.cwi.nl/local/pub/audio/adpcm.sharftp://ftp.cwi.nl/local/pub/audio/adpcm.sharG722
G722
AnimplementationoftheG.722algorithmisavailableaspartoftheITU-TSTL,describedabove.
G.722算法的实现作为上述ITU-TSTL的一部分提供。
G723
ThereferenceCcodeimplementationdefiningtheG.723.1algorithmanditsAnnexesA,B,andCareavailableasanintegralpartofRecommendationG.723.1fromtheITUSalesService,addresslistedabove.BoththealgorithmandCcodearecoveredbyaspecificlicense.TheITU-TSecretariatshouldbecontactedtoobtainsuchlicensinginformation.
定义G.723.1算法的参考C代码实现及其附录A、B和C可作为建议G.723.1的组成部分从ITU销售服务处获得，地址如上所列。算法和C代码都包含在特定的许可证中。应联系ITU-T秘书处以获取此类许可信息。
G726
ITU-T建议G.726“40、32、24和16kb/s自适应差分脉冲编码调制（ADPCM）”中规定了G726。G.726算法的实现作为上述ITU-TSTL的一部分提供。
G729
ThereferenceCcodeimplementationdefiningtheG.729algorithmanditsAnnexesAthroughIareavailableasanintegralpartofRecommendationG.729fromtheITUSalesService,listedabove.AnnexIcontainstheintegratedCsourcecodeforallG.729operatingmodes.TheG.729algorithmandassociatedCcodearecoveredbyaspecificlicense.ThecontactinformationforobtainingthelicenseisavailablefromtheITU-TSecretariat.
GSM
AreferenceimplementationwaswrittenbyCarstenBormannandJuttaDegener(thenatTUBerlin,Germany).Itisavailableat
CarstenBormann和JuttaDegener（当时在德国柏林大学）编写了一个参考实现。可于
尽管RPE-LTP算法不是ITU-T标准，但作为ITU-TSTL的一部分，RPE-LTP算法有一个C代码实现。STL实现是TUBerlin版本的改编。
LPC
Animplementationisavailableat
可在以下网址获得实施：
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Zftp://parcftp.xerox.com/pub/net-research/lpc.tar.ZPCMU,PCMA
PCMU，PCMA
AnimplementationofthesealgorithmsisavailableaspartoftheITU-TSTL,describedabove.
这些算法的实现作为上述ITU-TSTL的一部分提供。
ThecommentsandcarefulreviewofSimaoCampos,RichardCoxandAVTWorkingGroupparticipantsaregratefullyacknowledged.TheGSMdescriptionwasadoptedfromtheIMTCVoiceoverIPForumServiceInteroperabilityImplementationAgreement(January1997).FredBurgandTerryLyonshelpedwiththeG.729description.
TheIETFinvitesanyinterestedpartytobringtoitsattentionanycopyrights,patentsorpatentapplications,orotherproprietaryrightswhichmaycovertechnologythatmayberequiredtopracticethisstandard.PleaseaddresstheinformationtotheIETFExecutiveDirector.
HenningSchulzrinneDepartmentofComputerScienceColumbiaUniversity1214AmsterdamAvenueNewYork,NY10027UnitedStates
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail:schulzrinne@cs.columbia.eduEMail:schulzrinne@cs.columbia.eduStephenL.CasnerPacketDesign3400HillviewAvenue,Building3PaloAlto,CA94304UnitedStates
StephenL.CasnerPacketDesign美国加利福尼亚州帕洛阿尔托市Hillview大道3400号3号楼，邮编94304
Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivativeworksthatcommentonorotherwiseexplainitorassistinitsimplementationmaybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedonallsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.
ThelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbytheInternetSocietyoritssuccessorsorassigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.