关于RTSP-Over-HTTP

--------------------更新2018.07.10-------------------

myRtspClient-1.3.0开始支持RTSP-Over-HTTP

--------------------更新2018.07.10结束-------------------

一、概述

RTSP-Over-HTTP的关键（同时也是全部内容）在于：让RTSP报文通过HTTP端口（即80端口）通信。

我们知道RTSP的标准端口是554，但是由于各种不同的防火墙等安全策略配置的原因，客户端在访问554端口时可能存在限制，从而无法正常传输RTSP报文。

但是HTTP端口（80端口）是普遍开放的，于是就有了让RTSP报文通过80端口透传的想法，即RTSP-Over-HTTP。

二、暂无标准

目前RTSP-Over-HTTP没有标准做法，苹果公司出了一份非正式文档公开在外，并且也被LIVE555等支持。

三、LIVE555的RTSP-Over-HTTP

对照着苹果公司的“Tunneling QuickTime RTSP and RTP over HTTP”文档，LIVE555的具体做法如下：

首先客户端开启2个socket链接服务器HTTP端口，我们称这2个socket分别为“数据socket”和“命令socket”。

Step 1、客户端通过“数据socket”发送HTTP GET命令，请求RTSP链接。

Step 2、服务器通过“数据socket”响应HTTP GET命令，并回复成功/失败。

Step 3、客户端创建“命令socket”，并通过“命令socket”发送HTTP POST命令，建立RTSP会话。

至此，HTTP的辅助功能完成，服务器不返回客户端的HTTP POST命令。接下来是RTSP在HTTP端口上的标准流程，但是需要通过2个socket协同完成，“命令socket”只负责发送，“数据socket”只负责接受。

Step 4、客户端通过“命令socket”发送RTSP命令（BASE64编码加密）。

Step 5、服务器通过“数据socket”响应RTSP命令（明文）。

Step 6、重复Step4-Step5，直到客户端发送RTSP PLAY命令，服务器响应RTSP PLAY命令。

Step 7、服务器通过“数据socket”向客户端传输音视频数据

数据交互完毕后。。。

Step 8、客户端通过“命令socket”发送RTSP TEARDOWN命令（BASE64编码加密）

Step 9、服务器通过“数据socket”响应RTSP TEARDOWN命令（明文）。

Step 10、关闭2个socket。

四、TCP分包

UDP传输时，对应每一次Send，数据包之间存在明确的边界。但是TCP则不同，TCP的数据传输始终是一串流畅而没有边界的数据流，“封包”的概念得由应用层来定义，否则就会出现“断包”和“粘包”现象。为此，RFC7826[14 Embeded (Interleaved) Binary Data]规定了，在传输媒体数据时，会前缀4字节包头：

字节1:固定值字符'$'

字节2:通道ID，一般可取2个值，1个表示是RTP数据包（数值小），另一个表示RTCP数据包（数值大），具体在RTSP会命令中指明（如下图：客户端申请使用通道0和1，服务器返回5和6，则以5和6为准）

字节3-4:数据内容大小。

五、HTTP透传现状

各个厂家的音视频服务器客户端之所以兼容RTSP协议，为的就是RTSP协议的标准通用，不同厂家的设备可以相互兼容。

如果套了一层非标准非通用的透传协议，那么各个厂家就失去了做RTSP-Over-HTTP的理由。Live555在具体实现苹果的RTSP-Over-HTTP时，使用双socket收发的方式，如果不是使用Live555的函数库，只是根据苹果的RTSP-Over-HTTP文档实现透传，若是具体实现方式不同的话，也不一定可以和Live555保持兼容。而且他们大都有自己的私有音视频传输协议，这时候，他们往往会问这么一个问题：为什么不用自己的私有协议做HTTP透传呢？

所以，市场上另有一种透传做法就是利用私有协议通过HTTP透传，而不是RTSP，反正也解决了防火墙问题。

myRtspClient暂不支持RTSP-Over-HTTP

五、相关链接

LIVE555 RTSP-Over-HTTP透传示例：http://www.rosoo.net/a/201509/17373.html

LIVE555 RTSP-Over-HTTP透传wireshark抓包（透传端口8000）：https://pan.baidu.com/s/1hrNWyna