最近做视频编解码部分，传输采用RTP协议。对学习做个记录

　　1、简介

　　实时传输协议（Real-time Transport Protocol或简写RTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议，与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性，此协议提供的服务包括数据顺序号、时间标记、传输控制等。RTP通常与辅助控制协议RTCP一起工作，RTP只负责实时数据的传输，RTCP负责对RTP的通信和会话进行带外管理（如流量控制、拥塞控制、会话源管理等）。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。

　　2、RTP的协议层次

　　

　　可以看出RTP和UDP一样位于传输层，实时语音、视频数据经过模数转换和压缩编码处理后，先送给RTP封装成为RTP数据单元，RTP数据单元被封装为UDP数据报，然后再向下递交给IP封装为IP数据包。这里有个地方需要注意：RTP分组只包含RTP数据，而控制是由另一个配套协议RTCP提供。RTP在端口号1025到65535之间选择一个未使用的偶数UDP端口号，而在同一次会话中的RTCP则使用下一个奇数UDP端口号。RTP通常和RTCP一起工作，在RTP会话期间，各参与者周期的发送RTCP消息。RTCP消息含有已发送数据的丢包统计和网络拥塞等信息，服务器可以利用这些信息动态的改变传输速率，甚至改变净荷的类型。RTCP消息也被封装为UDP数据报进行传输。

　　3、RTP的协议封装

　　

version (V): 2 bits

标明RTP版本号。协议初始版本为0，RFC3550中规定的版本号为2。

padding (P): 1 bit

如果该位被设置，则在该packet末尾包含了额外的附加信息，附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因为一些加密机制需要固定长度的数据块，或者为了在一个底层协议数据单元中传输多个RTP packets。

extension (X): 1 bit

如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。

CSRC count (CC): 4 bits

在固定头部后存在多少个CSRC标记。

marker (M): 1 bit

该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。

payload type (PT): 7 bits

标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。

sequence number: 16 bits

序列号，每个RTP packet发送后该序列号加1，接收方可以根据该序列号重新排列数据包顺序。

timestamp: 32 bits

时间戳。反映RTP packet所携带信息包中第一个字节的采样时间。

SSRC: 32 bits

数据源标识。在一个RTP Session其间每个数据流都应该有一个不同的SSRC。

CSRC list: 0 to 15 items, 每个源标识32 bits

贡献数据源标识。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。

　　4、关于RTP的类库。

　　看了网上的一些资料，.NET方面对RTP的封装看到了一个RTP.NET.DLL。有个人的博客专门介绍了这个DLL，今天只是尝试接收了一下，发现可以接收到数据。在使用这个DLL的时候，出现了“其他信息: 混合模式程序集是针对“v2.0.50727”版的运行时生成的，在没有配置其他信息的情况下，无法在 4.0 运行时中加载该程序集。”异常，解决方法很简单。在APP.Config中configuration下添加

　　<startup useLegacyV2RuntimeActivationPolicy="true">
      　　<supportedRuntime version="v4.0"/>
      </startup>

　　5、总结

　　（1）对RTP理论方面进行了一些学习，觉得现在还能理解能用到的就是上面这一些。

　　（2）初步调用了一下RTP.NET.DLL，能接收到数据

　　（3）发送的数据使用的是VLC media player工具进行测试

　　（4）参考资料有很多，基本也是摘录。

　　每天记录一点点，就能进步一点点....