【精品】流媒体RTP协议

1、standard elements of rtpthe primary standard for audio/video transport in ip networks is the real-time transport protocol (rtp), along with associated profiles and payload formats. rtp was developed by the audio/video transport working group of the internet engineering task force (ietf), and it has

2、since been adopted by the international telecommunications union (itu) as part of its h.323 series of recommendations, and by several other standards organizations. rtp provides a framework for the transport of real-time media and needs to be profiled for particular uses before it is complete. the r

3、tp profile for audio and video conferences with minimal control was standardized along with rtr and several more profiles are under development. each profile is accompanied by several payload format specifications, each of which describes the transport of a particular media format.the rtp specificat

4、ionrtp was published as an ietf proposed standard (rfc 1889) in january 1996,htpu6utph and its revision for draft standard status is almost complete.htpu50utph the first revision of itu recommendation h.323 included a verbatim copy of the rtp specification; later revisions reference the current ietf

5、 standard rtp typically sits on top of udp/ip transport, enhancing that transport with loss detection and reception quality reporting, provision for timing recovery and synchronization，payload and source identification, and marking of significant events within the media stream. most implementations

6、of rtp are part of an application or library that is layered above the udp/ip sockets interface provided by the operating system. this is not the only possible design, though, and nothing in the rtp protocol requires udp or ir for example, some implementations layer rtp above tcp/ip, and others use

7、rtp on non-lp networks, such as asynchronous transfer mode (atm)networks.there are two parts to rtp: the tdata transfer protocolt and an associated tcontrol protocolt. the rtp data transfer protocol manages delivery of real-time data, such as audio and video, between end systems. it defines an addit

8、ional level of framing for the media payload, incorporating a sequence number for loss detection, timestamp to enable timing recovery, payload type and source identifiers, and a marker for significant events within the media stream. also specified are rules for in the ietf standards process,htpu8utp

9、h a specification undergoes a development cycle in which multiple tinternet draftst are produced as the details of the design are worked out. when the design is complete, it is published as a tproposed standardt rfc. a proposed standard is generally considered stable, with all known design issues wo

10、rked out, and suitable for implementation. if that proposed standard proves useful, and if there are independent and interoperable implementations of each feature of that standard, it can then be advanced to tdraft standardt status (possibly involving changes to correct any problems found in the pro

11、posed standard). finally, after extensive experience, it may be published as a full tstandardt rfc advancement beyond proposed standard status is a significant hurdle that many protocols never achieve, timestamp and sequence number usage, although these rules are somewhat dependent on the profile an

12、d payload format in use, and for multiplexing multiple streams within a session. the rtp data transfer protocol is discussed further in htuchapter4uth.the rtp control protocol (rtcp) provides reception quality feedback, participant identification, and synchronization between media streams. rtcp runs

13、 alongside rtp and provides periodic reporting of this information. although data packets are typically sent every few milliseconds, the control protocol operates on the scale of seconds. the information sent in rtcp is necessary for synchronization between media streams一for example, for lip synchro

14、nization between audio and videoand can be useful for adapting the transmission according to reception quality feedback, and for identifying the participants. the rtp control protocol is discussedfurther in htuchapter 5uth.rtp supports the notion of tmixerst and ttranslatorst, middle boxes that can

15、operate on the media as it flows between endpoints. these may be used to translate an rtp session between different lower-layer protocolsfor example, bridging between participants on ipv4 and ipv6 networks, or bringing a unicast-only participant into a multicast group they can also adapt a media str

16、eam in some wayfor example, transcoding the data format to reduce the bandwidth, or mixing multiple streams together.it is hard to place rtp in the osi reference model it performs many of the tasks typically assigned to a transport-layer protocol, yet it is not a complete transport in itself. rtp al

17、so performs some tasks of the session layer (spanning disparate transport connections and managing participant identification in a transport-neutral manner) and of the presentation layer (defining standard representations for media data).rtp profilesit is important to be aware of the limits of the r

18、tp protocol specification because it is deliberately incomplete in two ways. first, the standard does not specify algorithms for media playout and timing regeneration, synchronization between media streams, error concealment and correction, or congestion control. these are properly the province of t

19、he application designer, and because different applications have different needs, it would be foolish for the standard to mandate a single behavior. it does, of course, provide the necessary information for these algorithms to operate when they have been specified later chapters will discuss applica

20、tion design and the trade-offs inherent in providing these features.second, some details of the transport are left open to modification by profiles and payload format definitions these include features such as the resolution of the timestamps, marking of interesting events within a media stream, and

21、 use of the pay load type field. the features that can be specified by rtp profiles include the following: mapping between the payload type identifier in the rtp header and the payload format specifications (which describe how individual media codecs are to be used with rtp). each profile will refer

22、ence multiple payload formats and may indicate how particular signaling protocols (for example, sdphtpu15utph) are used to describe the mapping. the size of the payload type identifier field in the rtp header, and the number of bits used to mark events of interest within a media stream additions to

23、the fixed rtp data transfer protocol header, if that header proves insufficient for a particular class of application. the reporting interval for the rtp control protocolfor example, to make feedback more timely at the expense of additional overhead limitations on the rtcp packet types that are to b

24、e used, if some of the information provided is not useful to that class of applications. in addition, a profile may define extensions to rtcp to report additional information. additional security mechanisms一for example, new encryption and authentication algorithms. mapping of rtp and rtcp onto lower

25、-layer transport protocols.at the time of this writing, there is a single rtp profile: the rtp profile for audio and video conferences with minimal control. this profile was published as a proposed standard (rfc 1890) along with the rtp specification in january 1996,htpu7utph and its revision for dr

26、aft standard status is almost complete.htpu49utph several new profiles are under development. those likely to be available soon include profiles specifying additional security,htpu55utph as well as feedback and repair mechanisms.htpu44utphrtp payload formatsthe final piece of the rtp framework is th

27、e payload formats, defining how particular media types are transported within rtp. payload formats are referenced by rtp profiles, and they may also define certain properties of the rtp data transfer protocol.the relation between an rtp payload format and profile is primarily one of namespace, altho

28、ugh the profile may also specify some general behavior for payload formats. the namespace relates the payload type identifier in the rtp packets to the pay load format specifications, allowing an application to relate the data to a particular media codec. in some cases the mapping between payload ty

29、pe and payload format is static; in others the mapping is dynamic via an out-of-band control protocol. for example, the rtp profile for audio and video conferences with minimal controlhtpu7utph defines a set of static payload type assignments, and a mechanism for mapping between a mime type identify

30、ing a payload format, and a payload type identifier using the session description protocol (sdp).the relation between a payload format and the rtp data transfer protocol is twofold: a pay load format will specify the use of certain rtp header fields, and it may define an additional payload header. t

31、he output produced by a media codec is translated into a series of rtp data packets一some parts mapping onto the rtp header, some into a pay load header, and most into the pay load data. the complexity of this mapping process depends on the design of the codec and on the degree of error resilience re

32、quired in some cases the mapping is simple; in others it is more complex.at 让s simplest, a payload format defines only the mapping between media clock and rtp timestamp, and mandates that each frame of codec output is placed directly into an rtp packet for transport. an example of this is the payloa

33、d format for g.722.1 audio.htpu36utph unfortunately, this is not sufficient in many cases because many codecs were developed without reference to the needs of a packet delivery system and need to be adapted to this environment. others were designed for packet networks but require additional header i

34、nformation. in these cases the payload format specification defines an additional payload header, to be placed after the main rtp header, andrules for generation of that heade匸many payload formats have been defined, matching the diversity of codecs that are in use today, and many more are under deve

35、lopment. at the time of this writing, the following audio payload formats are in common use, although this is by no means an exhaustive list: g.711, g.723.1, g.726, g.72& g.729, gsm, qcelp, mp3, and dtmf.htpu30utphp,hptpu34utphp,hptpu38utphp,hptpu49utph the commonly used video payload formats in

36、clude h.261,h.263, andmpeg.htpu9utphp,hptpu12utphp,hptpu22utphthere are also payload formats that specify error correction schemes- for example, rfc 2198 defines an audio redundancy encoding scheme,htpu1outph and rfc 2733 defines a generic forward error correction scheme based on parity coding.htpu3

37、2utph in these payload formats there is an additional layer of indirection, the codec output is mapped onto rtp packets, and those packets themselves are mapped to produce an error-resilient transport. error correction is discussed in more detail in htuchapter 9uth, error correction.optional element

38、stwo optional pieces of the rtp framework are worth mentioning at this stage: header compression and multiplexing.theader compressiont is a means by which the overhead of the rtp and udp/ip headers can be reduced on a per-link basis. it is used on bandwidth-constrained links一for example, cellular an

39、d dial-up links一and can reduce the 40-byte combination of rtp/udp/ip headers to 2 bytes, at the expense of additional processing by the systems on the ends of the compressed link. header compression is discussed further in htuchapter 11uth.tmultiplexingt is the means by which multiple related rtp se

40、ssions are combined into one. once again, the motivation is to reduce overheads, except this time the procedure operates end-to-end. multiplexing is discussed in htuchapter12uth, multiplexing and tunnelingboth header compression and multiplexing can be considered to be part of the rtp framework unli

41、ke the profiles and payload formats, they are clearly special-purpose, optional parts of the system, and many implementations don't use either feature二、英文翻译:rtp的标准元素咅频/视频在互联网协议网络的传输的主要标准是实时传输协议，以及一系 列的配置文件与有效载荷模式。rtp是被互联网工程任务组的音频/视频传输协 议工作小组发展起来的，并且它已经被国际电信同盟以及其他一些标准组织所接 纳，作为国际电信同盟推荐的h. 323系列的一部

42、分。rtp为实时媒体传输提供了 一个框架，并且需要为特殊的用途配置文件才能完成。最低掌控度的音频、视频 会议的实时传输协议配置文件是结合实时传输协议标准化的，并且一些其他的协 议也处于发展z中。每一个配置文件都有儿个格式规范的有效载荷与z匹配，它 们中的每一个都描绘了一种特殊媒介格式的传输。rtp的说明rtp作为ietf的一种提案标准被发布于1996年1月，它的修订草案几乎是完 整的。itu建议第一木修订草案h. 323包含了rtp说明的逐字逐句的复制，后来 的修订草案则是关于现行的ietf的标准。rtp特别设立了关于用户数据协议/互联网协议传输的掌控，加强了对于传 输过程屮的丢失跟接收质量报

43、告，及时回馈跟同步性的规定，有效载荷跟来源认 证，并且对媒体资料流中的重要事件进行标记。rtp中的人多数安装启用是运行 系统提供的在用户数据协议/互联网协议接口处的应用程序或者文库。尽管这并 不是唯一可能的设计，而且rtp协议中没有任何-条要求用户数据协议或者互联 网协议，例如，一些安装启用使得rtp处于用户数据协议/互联网协议之上，而 且其他一些也在无互联网协议下使用rtp网络，比如一步转换模式网络。rtp由两部份构成：数据转换协议与相关的控制协议。rtp数据转换协议致 力于数据及时传送，比如终端z间的音频跟视频。它定义了一个媒体有效载荷框 架的额外水平，结合了丢失侦探序列，还有时间戳用来加

44、强及时冋馈，有效载荷 类型跟来源认证，并且对媒体资料流之中的重要事件进行标记。在ietf的标准化进程屮，一个说明经历了一个发展周期，在这z中，多种被 作为设计的细节而产生的因特网草案被策划出来。当设计完成的时候，它被作为一个rtc的标准提案。一个标准提案通常被认 为是一个稳定的，以及被解决的众所周知的设计问题，并且适合于启用。如果该标准提案被证明是有效的，并口是独立而冃此标准的每一个特征的启用都 是彼此协作的，那么它将成为宪法草案（很可能包含改正所有在进程中发现的问 题的改变）。最后，经过大量的实践，它也许会被作为一个完全标准的rtp。标准宪法提 案的基础上的提升是一个中重更的挑战，大多数的协

45、议都不曾到达过。时间戳跟序列的使用，尽管这些规则都是有点依赖于配置文件跟有效载荷的 使用以及对于多路技术与一个季节中的多重资源流。rtp控制协议提供接收质量 反馈，参与性认证，以及在媒体资源流z间的同步性。实施控制传输协议伴随rtp起运行并提供这种信息的定期报告，尽管每几 秒钟就有一些数据被打包并特别发送，控制协议都以秒的比例运行。用rtcp发送的信息是媒体资料流之间的同步性所必须的一一比如，咅频与 视频之间的同步对白录音并且根据接收适量反馈报告，它对适应传动装置与 认证参与者的身份也是很有用的。rtp支持混音器与翻译器的观念，能在媒体运 行的就像它在中段z间的流动一样的中间盒了。这些也许会被

46、用来翻译不同的比 较底层的协议的服务器对话一一比如，互联网通信协议第六版与第四版之间的嫁 接，或者带来一个单一传播，作为一个多路传播的参与者。它们也能够用某种方 式参与媒体流，比如，对数据格式进行代码转换以此来减少频带宽度，或者把多 种资源流混合到一起。把rtp放到开放式系统互联网参考模型里是很怵i难的。它执行了大多数的特 别分派给运输层协议的任务，然而它自己并不是一个完整的运输系统。rtp也执 行着一些会话层的任务（扩展单独的运输联系以及致力于对中立运输习惯参与者 的身份认证）以及一些代表性层级（为媒体数据定义标准代表性）rtp配置文件明白rtp协议说明的限制性是很重要的，因为它在两个地方的

47、不完整性是故 意造成的。第一，对媒体有效载荷的特定算法没有标准，并且时间的匣复，媒体硫z间 的同步性，错误的掩盖和改正，或者拥挤控制也都没有特定的标准。这些在应用 设计的领域是合适的，并且因为不同的应用有不同的需要，对-个单一的反应制 定标准是非常愚蠢的。它的确这些演算的一些特性的运行提供了必要的信息。第二，运输的一些细节可以被协议，有效载荷模式的定义所修改。这些包括 一些特点，比如时间戳的解决，媒体流中有资金交易事件的标记，以及有效载荷 领域的使用。能被rtp定义的特点包括以下儿点：在rtp数据头与有效载荷模式说明之间的有效载荷类型认证者之间的绘图（这 种绘图描述了单个的多媒体数字编码解码器

48、跟rtp起使用的方法）。每一个协 议将会与多觅有效载荷模式相关联并且能暗示特殊信号协议（比如：信号资料处 理器）是怎样描述绘图的。在rtp数据头中的有效载荷认证类型参与者领域的人小，用来标记媒体流中有 资金交易的事件的字节的数量。固定的rtp数据转换协议数据头的附加，如果那个数据头被证明对于一个特 殊阶层的应用时不充分的的 rtp控制协议的报告间隔比如，使得反馈在附加费用的方面更具有时效 性。如果提供的信息被证明对那一层次的应用是无效的，实时传输控制协议的限制 性将会被使用。另外，一个协议也许定义了对实时传输控制协议的扩展从而报告 额外的信息。额外的安全机制新的机密技术与鉴定算法。rtp的绘制与实时传输控制协议被加入底层地运输协议。在写这篇文章的时候，有一个为最小控制屮的音频与视频会议而单独设立的 rtp协议。这个协议被作为标准提案并结合rtp说明被