RTP over TCP

通常來說，RTSP提供UDP方式發送RTP流。當然，發送流媒體時，UDP往往是更好的選擇。

下面是使用UDP時的一些問題：

UDP協議上的RTSP/RTP需要打開許多UDP端口（每一路流媒體都需要2個UDP端口，一個用於接收數據，一個用於接收控制信息）；
當因特網上的路由器沒有打開這些端口的時候，第一點將會存在問題；
中間網絡路由器很容易就過濾或者忽略掉UDP數據包；
UDP是不可靠傳輸協議，媒體包在因特網上傳輸時會面臨着丟包。

如果在TCP傳輸協議上承載RTSP/RTP將解決這些問題

RTSP/RTP的控制命令和數據都通過一個端口，即RTSP的端口（默認爲554），進行交互。
TCP協議提供可靠的流傳輸。
TCP包更容易穿透中間網絡路由器。

在TCP傳輸協議上承載RTSP/RTP也不是完美的，同樣存在一些問題：

由於二元交織，會使得RTP包封包和解包的過程變得更加複雜。
TCP是可靠的傳輸協議，但正是因爲如此，會導致在實時流媒體中的延時。
使用TCP傳輸協議承載RTSP/RTP需要花更多的功夫。

接下來讓我們來了解一下怎麼使用TCP承載RTSP/RTP。

TCP承載RTSP/RTP

當使用TCP協議承載RTSP/RTP時，所有的命令和媒體數據都將通過RTSP端口，通常是554，進行發送。同時，數據將經過二元交織格式化之後才能發送。

接下來我們將描述使用TCP承載RTSP/RTP的主要要素：

SETUP

要使用TCP連接，RTSP客戶端需要在SETUP階段請求TCP連接。SETUP命令中應該包括如下格式的Transport：
Transport: RTP/AVP/TCP;interleaved=0-1

上述Transport將告訴服務端使用TCP協議發送媒體數據，並且使用信道 0 和 1 對流數據以及控制信息進行交織。詳細說來，使用偶數信道作爲數據傳輸信道，使用奇數信道作爲控制信道（數據信道 + 1）。所以，如果你設定數據信道爲 0 ，那控制信道應該是 0 + 1 = 1。

下面是一個rtsp客戶端請求通過rtp over tcp方式建立連接報文；

SETUP之後，RTP數據將通過用來發送RTSP命令的TCP Socket進行發送。RTP數據將以如下格式進行封裝：

| magic number | channel number | data length | data  |magic number - 

magic number：   RTP數據標識符，"$" 一個字節
channel number： 信道數字 - 1個字節，用來指示信道
data length ：   數據長度 - 2個字節，用來指示插入數據長度
data ：          數據 - ，比如說RTP包，總長度與上面的數據長度相同

RTP，RTCP數據和RTSP數據共享TCP數據通道，所以必須有一個標識來區別三種數據。

RTP和RTCP數據會以$符號＋1個字節的通道編號＋2個字節的數據長度，共4個字節的前綴開始，RTSP數據是沒有前綴數據的。RTP數據和RTCP數據的區別在於第二個字節的通道編號，

下面給出一個 RTP OVER TCP 方式數據頭結構定義 4oct

    typedef struct rtsp_interleaved
    { 
        unsigned int magic : 8;// $
        unsigned int channel : 8; //0-1
        unsigned int rtp_len : 16;
    }RILF;

下面給出一個完整的交互過程：

（1） OPTIONS 客戶端向服務器詢問有哪些方法可以使用**

OPTIONS rtsp://222.201.145.236/slamtv60.264 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)

服務器接收到OPTIONS請求後發出響應報文。狀態碼200代表請求成功。然後返回服務器當前時間(GMT)和所支持的方法。

RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Mar 07 2012 03:48:07 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

(2) DESCRIBE 客戶端像服務端請求描述媒體的詳細信息。

DESCRIBE rtsp://222.201.145.236/slamtv60.264 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Accept: application/sdp

服務端響應DESCRIBE請求所發回的報文，通過SDP協議發送媒體屬性。

RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Mar 07 2012 03:48:07 GMT
Content-Base: rtsp://222.201.145.236/slamtv60.264/
Content-Type: application/sdp
Content-Length: 527

v=0
o=- 1331092087436965 1 IN IP4 222.201.145.236 
s=H.264 Video, streamed by the LIVE555 Media Server
i=slamtv60.264//媒體名稱
a=type:broadcast  廣播方式
a=control:*
a=range:npt=0-
m=video 0 RTP/AVP 96 //媒體類型+端口+傳輸協議+格式列表
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D4033;sprop-parameter-sets=Z01AM5JUDAS0IAAAAwBAAAAM0eMGVA==,aO48gA==
a=control:track1

(3) SETUP 客戶端向服務端發送SETUP請求，要求服務端設置會話屬性和流媒體傳輸方式以建立會話

SETUP rtsp://222.201.145.236/slamtv60.264/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Transport: RTP/AVP/TCP;unicast; interleaved=0-1
//Transport:傳輸協議+傳播方式（單播或多播）+通道號。

服務端響應DESCRIBE請求所發回的報文

RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Mar 07 2012 03:48:18 GMT
Transport: RTP/AVP/TCP;unicast;destination=125.216.243.188;source=222.201.145.236;interleaved=0-1
Session: 289BFEAE

(4) PLAY 會話建立後，客戶端發出PLAY請求播放所申請的流媒體。傳輸機制按照SETUP命令所設置的進行

PLAY rtsp://222.201.145.236/slamtv60.264/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Session: 289BFEAE
Range: npt=0.000-

服務器迴應

RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Mar 07 2012 03:48:18 GMT
Range: npt=0.000-
Session: 289BFEAE
RTP-Info: url=rtsp://222.201.145.236/slamtv60.264/track1;seq=61622;rtptime=1335382752