--------------------更新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