全球眼
实时视频传输和控制协议v2
修改历史
复审人
一、说明
这份协议描述了视频服务器与流媒体分发服务器、视频服务器与企业客户端之间传输实时视频的方法。
文档中没有针对媒体分发服务器与企业客户端（第三方播放器）之间的通信方法，但是媒体分发服务器与企业客户端（第三方播放器）之间的通信方法尊守RTC1889和RPC2326定义的规范。
在这篇文档里我们把象视频服务器这样能够给观看者提供视频数据的设备称为逻辑上的服务端角色（也就是视频源），象企业客户端这样播放视频的终端设备称为逻辑上的客户端角色（也就是接收者或观看者）。
流媒体分发服务器同时具有两种角色。
交互流程中列出了两种模式，我们当前要先实现接模式。
推模式是为了视频服务器在私网环境时也可以通过流媒体发服务器向用户提供视频服务。
推模式暂不实现。
协议中没有提及RTCP协议，但并不影响视频通信质量，而且目前很难实现有效的编解码之间返馈的处理方法，所以现在，以及将来的一段时间都不会考虑RTCP协议，除非出现有效的视频质量控制机制。
本文参考RFC 1889、1890、2326、3550完成，如有不符合标准的、或者不完善的陈述，请提出来，发电子邮件到piaoxichuang@。
如果您有更好的想法也可以通过邮件进行交流。
二、协议
通信方式使用RTP over TCP方式。
（RTC1889、RFC2326）
1、一个完整的包
网络字节顺序
2、RTP包的封装（RTP over TCP）
网络字节顺序
Channel Identifier：取值0。
因为只有一个流在一个TCP连接中传递，同时不使用RTCP协议。
参见RFC 2326 [10.12]节。
Lenth：取值为RTP包的大小，包括RTP头部，但不包含本身的4个字节，以BYTE为单位。
3、RTP 12字节头部
网络字节顺序
V：版本，取值2。
[可能会使用0值，还没想清楚，可能的使用情况是为了实现防火墙穿透] P：附加数据，取值为0。
X：扩展头，取值为1。
CC：CSRC列表数量，取值为0。
M：记号，取值0或1。
关于M字段的取值：如果扩展头中T字段为1，则当一个包（RTP Packet）是一个帧（Sample）的最后一个包时取值1，否则取值0；扩展头中T字段为1时，由于指令长度较小，一个RTP就可以传输完成，所以取值为1。
除非要使用多个RTP包传输，最后一个RTP包取值为1，前面的包取值为0。
PT：负载类型，动态，取值96。
参见RFC 1890 [7]节。
Sequence Number：RTP包的序号，初始值是随机的，不是0。
Timestamp：以视频编码算法提供者的需要填写或单调增长的时间戳。
[将来可能把这个值也传递给视频解码算法中去。
]
SSRC：随机数，用于在同一个会话中区分不同的流。
建议使用MD32。
UINT Y[4]
If Y = MD5(X) Then
MD32(X) = Y[1] ^ Y[2] ^ Y[3] ^ Y[4]
注：RTP包大小最大值为2048。
（因为DSS支持的最大包为2048Bytes）
4、RTP扩展头
网络字节顺序
T：扩展头标志，取值0或1。
Packet Type：负载类型。
取值见下表：
[5.3.1]节。
1、Playload的格式
扩展头部定义的Playload类型：
T=0，Packet Type=1
XML格式，定义如下
<Message>
<Camera ID=”S” Naming=”S” />
<Ticket>S</Ticket>
</Message>
T=0，Packet Type=2
XML格式，定义如下
<Message>
<Successed>N</Successed>
</Message>
T=0，Packet Type=3
二进制的原始视频头部数据
T=1，Packet Type=1
二进制的原始视频数据
T=1，Packet Type=2
二进制的原始音频数据
T=1，Packet Type=3
二进制的原始视频数据
注：Naming是摄像头的全局唯一标识符，用与平台与联，目前的视频服务器协议可以忽略
这个属性。
三、交互流程
在全球眼系统中，对于实时视频传输控制协议扮演服务器角色的是前端视频服务器，扮演客户端角色的有企业客户端、流分发服务器、显示服务器、WEB客户端。
下面以前端视频服务器与流分发服务器为例说明实时视频传输控制协议的交互流程。
1、拉模式
第一步：流分发服务器（客户端角色）发起到前端视频服务器（服务器角色）的TCP连接请求，前端视频服务器接受这个连接。
完成TCP连接的建立。
（扩展头部T字段为0，Packet 第二步：流分发服务器发送连接请求数据报到前端视频服务器。
Type为1）
第三步：前端视频服务器验证请求，如果请求有效，则回应给流分发服务器连请求应答（扩展头部T字段为0，Packet Type为2）数据报；如果请求无效，则回应给流分发服务器一个请求有错的连接请求应答（扩展头部T字段为0，Packet Type为2）数据报，并关闭TCP 连接，前端视频服务器（服务器角色）算法结束。
第四步：流分发服务器如果接收到一个正确的连接请求应答，则进入第五步；否则如果接收到错误的连接请求应答（或者说没有接收到连接请求应答），则关闭TCP连接，流分发服务器（客户端角色）算法结束。
第五步：前端视频服务器向流分发服务器发送视频头部（扩展头部T字段为0，Packet Type 为3）数据报。
第六步：前端视频服务器根据编码器产生的实时音视频数据向流分发服务器发送视频数据报（扩展头部T字段为1，Packet Type为1，2，3）。
第七步：前端视频服务器重复第六步，直到TCP连接断开，前端视频服务器算法结束。
第八步：流分发服务器持续接收前端视频服务器在第六步、第七步发送的视频数据报。
第九步：流分发服务器不再需要视频流数据时（停止观看），流分发服务器关闭TCP连接，流分发服务器（客户端角色）算法结束。
2、推模式
算法与拉模式相似，只在第一步、第二步、第三步算法中把服务器角色和客户端角色对换。
算法描述如下：
第一步：前端视频服务器（服务器角色）发起到流分发服务器（客户端角色）的TCP连接请求，流分发服务器接受这个连接。
完成TCP连接的建立。
第二步：流分发服务器发送连接请求数据报到流分发服务器。
（扩展头部T字段为0，Packet Type为1）
第三步：流分发服务器验证请求，如果请求有效，则回应给前端视频服务器连请求应答（扩展头部T字段为0，Packet Type为2）数据报；如果请求无效，则回应给前端视频服务器一个请求有错的连接请求应答（扩展头部T字段为0，Packet Type为2）数据报，并关闭TCP 连接，流分发服务器（客户端角色）算法结束。
第四步：前端视频服务器如果接收到一个正确的连接请求应答，则进入第五步；否则如果接收到错误的连接请求应答（或者说没有接收到连接请求应答），则关闭TCP连接，前端视频服务器（服务器角色）算法结束。
第五步：前端视频服务器向流分发服务器发送视频头部（扩展头部T字段为0，Packet Type 为3）数据报。
第六步：前端视频服务器根据编码器产生的实时音视频数据向流分发服务器发送视频数据报（扩展头部T字段为1，Packet Type为1，2，3）。
第七步：前端视频服务器重复第六步，直到TCP连接断开，前端视频服务器算法结束。
第八步：流分发服务器持续接收前端视频服务器在第六步、第七步发送的视频数据报。
第九步：流分发服务器不再需要视频流数据时（停止观看），流分发服务器关闭TCP连接，流分发服务器（客户端角色）算法结束。
四、兼容性
视频服务器作为服务端角色，应该实现对原来版本实时视频传输协议的兼容机制。
这篇文档中不会规定实现新旧版本的兼容机制或算法。
最终实现者可以考虑基于数据包头部来区分版本。
五、传输控制
1、服务器角色
●服务器角色在发送数据时必须保证视频帧的完整性
●服务器角色必须支持一个时间阀值，以保证由服务器解色在传输上引入的时延小于该阀
值。
●服务器应该统计传输的丢帧率，并在到达一个预定义的阀值时放弃该传输。
2、客户端角色。