每个RTP包中都有前12 个字节，而CSRC identifier 列表仅在 mixer 插入时才有。域解析如下：version (V): 2 bits rtp 版本标识，说明定义了两个版本padding （P）：1 bit 如果设定padding，在报文尾端就会包含一个或者多个padding字节，这不属于payload。最后一个字节padding有一个计数器，标识需要忽略多少个padding字节（包括自己）。一些加密算法可能需要固定块长度的padding，或者是为了在更底层数据单元中携带一些rtp报文extension（X）：1 bit 如果设定了extensio 位，定长头字段后面会有一个头拓展CSRC count（CC）：4 bits CSRC count 标识了定长头字段中包含的csrc identifier 的数量maker （M）：1 bit maker 是由一个profile 定义的。用来允许标识在像报文流中界定帧界等事件，一个profile 可能定义了附加的标识位或者通过修改 payload type 域中的数量位来指定有没有标识位payload type（PT）：7 bits 这个字段定一个RTP payload 的格式在和应用中定义解析。profile 可能指定一个从 payload type 码字 到 payload format 的默认 静态映射。也可以通过 non-rtp 方法来定义附加的 payload type 码字。一个 rtp 源 有可能在会话中改变 payload type，但是这个域在复用独立的媒体时不同的。接受者必须忽略它不识别的payload typesequence number：16 bits 每发送一个rtp数据报文序列号值加一，接受者也可以用来检测丢失的包或者重建报文序列。初始的值是随机的，这样就使得 konwn-plaintext 攻击更加困难，即使源没有加密，因为要通过的 translator 会做这些事情。timestamp：32 bits timestamp 反映的是RTP 数据报文中第一个字段的采样时刻的时间瞬时值。采样时间值必须是从恒定的和线性的时间中得到以便同步和jitter计算。必须保证同步和测量报文jitter 到来所需要的时间精度。时间频率是与payload 所携带的数据格式有关的，在profile 中静态的定义或是在定义格式 payload format 中，或通过 non-rtp 方法所定义的payload format 中动态定义。 对于序列号来说，timestamp 初始值是随机的。主要他们是同时生产的，这些连续的rtp报文就会有相同的timestamp，例如同属一个视频帧。 不同媒体流的 rtp timestamp 可能有不同的速率，通常由独立的随机 offset。虽然这些timestamp 对已重建单流的时序是足够的，但是直接比较不同的timestamp来获取同步是不够的。因此对于每一个媒介来说，rtp timestamp 与采样时刻是通过与从参考时钟而来的timestamp 作为对比而建立时间戳对（pair），系统时钟timestamp 是数据被采样的时刻。系统时钟被不同的媒体共享以便同步。
SSRC:32 bits ssrc 域识别同步源。为了防止在一个会话中有相同的同步源有相同的ssrc identifier，这个 identifier 必须随机选取。CSRC list ：0-15 items，32 bits each csrc list 表示哪些在本报文中对payload 作了贡献的源。号数是由cc 域定。如果有多于15 个贡献源，只有15个源可以被标识。CSRC identifier 是由 mixer 利用 贡献源 ssrc identifier 插入的。如理，对于音频报文，所有混合在一起的源 SSRC identifier 被列出来，以便接受者识别正确的 讲话者。4. rtp 的带宽控制 为了实施传输数据，RTP 利用了简单而便捷的udp协议来实现网络传输。由于udp协议是一种无连接传输协议，不保证报文传输的正确性和有序性，也不提供流量控制功能。另一方面，在多媒体通信中，由于多媒体数据的特性性，不适宜采用通常的重传纠错方法来提供正确性，而是采用控制传送带宽方式来减少报文丢失，以满足多媒体所需的QOS，在rtp协议中，通过rtcp报文提供了基于无连接传输协议的端到端控制机制，这是一种基于接受者反馈的网络的网络传输QOS监测机制，在rtcp 的接收报告中包含了当前网络传输qos有关信息，如报文丢失率，报文丢失累计，接受到的最高序列号，平均延时抖动以及用于计算发布接受报告往返所需时间的时间标签等。发送者可通过这些信息监测和评价网络传输qos 状况，并可采取适当的策略实施同步控制。 rtp协议规定，每个rtp系统必须实现rtcp的控制功能，由内部功能模块定期自动执行。rtcp 报文时轻载信息，其信息量与最低的数据通信量相平衡，它所产生的通信量只是数据通信量的5%左右。 要实施端到端的强制同步控制，其前提条件是发送端要能获取网络失调信息。一种可行的同步控制策略是：各个接受端将一种轻载的网路失调状态信息反馈给发送端，发送端据此进行强制性同步控制，以满足接收端演示质量要求。 基于rtp 的带宽控制算法正是利用这种控制策略来实施强制性同步控制的，其基本思想是在rtp协议机制支持下，发送端通过接收端周期反馈的接收报告来评价当前网络传输的qos，并以此对数据发送速率进行适当的调整。5. rtp的profile 机制 rtp 为具体的应用提供了非常大的灵活性，它将传输协议与具体的应用环境，具体的控制策略分开，传输协议本身只提供完成实时传输的机制，开发者可以根据不同的应用环境，自主选择适合的配置环境，以及适合的控制策略。 这里所说的控制策略指的是你可以根据自己特定的应用需求，来实现特定的一些RTCP 控制算法，比如前面提到的丢包的检测算法，丢包的重传策略，一些视频会议应用中的控制方案等等，对于上面说得适合的配置环境，主要是指rtp的相关配置和负载的定义，rtp协议为了广泛支持各种多媒体格式（如 h264，mpeg-4,mjpeg,mpeg），没有在协议中体现出具体的应用配置，而是通过profile配置文件以及负载格式说明文件的信息来提供，对于任何一种特定的应用，rtp定义了一个profile文件以及相关的负载说明，相关文件如下所示：
6.rtcp协议 rtcp 原理是向会话中所有成员周期性地发送控制包来实现，应用程序通过接受这些控制数据包，从中获取会话参与者的相关资料，以及网络状况，分组丢失概率等反馈信息，从而能对服务质量进行控制或者对网络状况进行诊断 rtcp 协议的功能是通过不同的RTCP数据包门来实现的，主要有如下几种类型： SR（sender report）：发送端报告，所谓发送端是指发出RTP数据包的应用程序或者终端，发送端同时也可以是接收端 RR(receiver report)：接收端报告，所谓接收端是指仅接受但不发送RTP数据包的应用程序或终端 SDES 源描述，主要功能是作为会话成员有关表示信息的载体，如用户名，邮件地址，电话号码等，此外还具有向会话成员传达控制信息的功能。 BYE 通知离开，主要功能是指示某一个或者几个圆不再有效，即通知会中其他成员自己将推出会话 APP 由应用程序自己定义，解决了RTCP 的拓展性问题，并且为协议的实现者提供了很大的灵活性RTCP 数据包携带有服务质量控制的必要信息，能够对服务质量进行动态调整，并能够对网络拥塞进行有效的控制。由于RTCP 数据报采用的是组播方式，因此会话中所有成员都可以通过RTCP 数据包返回控制信息，来了解其他参与者的情况。例如在流媒体应用场合下，发送流媒体的应用程序周期性地产生发送端报告SR，该RTCP 数据含有不同媒体间的同步信息，以及已经发送的数据包和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已经的发送端发送接收端报告RR，该rtcp数据报含有已接受数据报的最大序列号，丢失的数据包数目，延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计往返时延，并且可以根据数据包对视概率和时延抖动情况动态调整发送速率，改善网络拥塞状况，或者根据网络状况平滑调整应用程序的服务质量。RTCP具有以下四个功能：（1）基本功能是提供数据传输质量的反馈，这是RTP作为一种传输协议的主要作用，它与其他协议的流量和阻塞控制相关，反馈可能对自适应编码有直接作用，但是ip组播的实验表明它对于冲接收机得到反馈的信息以诊断传输故障也有决定性作用，向所有成员发送接收反馈可以使 观察员 评估这些问题是局本部的还是全局的，利用类似多点广播的传输机制，可以使某些实体，如没有加入会议的网络网络业务观察员，接收到反馈信息并作为第三类监视员来诊断网络故障，反馈功能通过rtcp发射机和接收机报告来实现。（2）RTCP 为每个RTP 源传输一个固定的标识符，成为标识名或CNAME，由于当发生冲突或程序重启时SSRC可能改变，接收机就要用CNAME来跟踪每个成员，接收机还要用CNAME来关联一系列相关rtp会话中来自一个成员的多个数据流，例如同步语音和图像。（3）前两个功能要求所有成员都发送rtcp包，因此必须控制速率使得RTP成员数可以逐级增长，通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会议中所有成员的数目。（4）可选的功能是传输最小的会议控制信息，例如在用户接口中显示的成员识别，这最可能在 松散控制的会议中起作用，在 松散控制 会议里， 成员可以不经过资格控制和参数协商而加入或退出会议。rtcp 作为一个延伸到所有成员的方便通路，必须要支持具体应用所需的所有控制信息7.简单的rtp/rtcp的FAQ（1）rtp包头并不包含包长度信息，接收端如何进行rtp分包 一般情况下 一个udp 包内是一个rtp包，不包含多个rtp包，rtp头里面有一个标识，说明此RTP包的尾部是否由充填。如果没有填充，这个udp包负载就是rtp包分组。如果有填充，这个包的最后两个字节标识充填的长度； （2）怎样重组乱序的数据包 根据rtp包的序列号来排序（3）怎样实现音视频同步 根据音频和视频各自的rtp包中的时间戳，与同一个源的rtcp 包中的系统时间，实现音视频同步（4）rtp一般是建立在udp上传输音视频数据，如何实现传输质量控制 通过rtcp协议（5）为什么 rtp 可以解决时延问题，和适用实时视频流 rtp 协议是大多数情况是基于UDP 传输的，rtp本身不提供按顺序传送数据包的可靠传送机制，也不提供流量控制和拥塞控制，它依赖rtcp 提供这些服务，这样，对于那些丢失的数据包，不存在由于超市检测而带来的时延，同时，对于那些丢弃的包，也可以由上层根据重要性来选择性的重传。比如对于I帧，P帧，B帧数据，其重要性依次降低，故在网络情况不好的情况下，可以考虑在B帧丢失甚至P帧丢失的情况下不进行重传，这样在客户端方面，虽然可能会有短暂的不清晰画面，但却保证了实时性。 8.参考博客和文档http://www.cnblogs.com/CskyWarrior/p/4516338.htmlhttp://blog.sina.com.cn/s/blog_8795b0970101eooo.htmlhttp://blog.csdn.net/hrbeuwhw/article/details/8135109http://blog.csdn.net/ljzcom/article/details/9834439http://blog.csdn.net/occupy8/article/details/9041803RFC 3550新闻热点
疑难解答
