RTP over RTSP(TCP)（一）

伺服器：live555 用戶端：VLC 視頻格式：H264  

（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)
解析：此步驟是用戶端向伺服器詢問有哪些方法可以使用。包裡面說明了用戶端請求的檔案所在的地址和連接埠，並說明播放器的版本和作業系統平台。

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
解析：接收到OPTIONS請求後服務端發出響應報文。最開始返回狀態代碼200代表請求成功。然後返回伺服器目前時間(GMT)和所支援的方法。
(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
解析：該方法是用戶端像服務端請求描述媒體的詳細資料。包中說明需要描述的媒體檔案具體目錄和名稱，定義用戶端能理解的描述類型，要求服務端以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

第一部分解析：這是服務端響應DESCRIBE請求所發回的報文。以上內容說明描述的媒體檔案具體路徑和名稱，以及所採用的描述類型(sdp)，並定義了SDP包內容的長度。以下的第二部分是SDP包的內容。
v=0
o=- 1331092087436965 1 IN IP4 222.201.145.236 
s=H.264 Video, streamed by the LIVE555 Media Server
i=slamtv60.264// 媒體名稱
t=0 0
a=tool:LIVE555 Streaming Media v2012.02.04
a=type:broadcast  廣播方式
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:slamtv60.264
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

第二部分解析：該部分是SDP包內容，包括媒體的所有初始化資訊。在傳輸時SDP包作為RTSP包裡的一部分一起發送。

(3)

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;unicast;client_port=49970-49971//傳輸協議+傳播方式（單播或多播）+接收資料的連接埠號碼。
解析：用戶端向服務端發送SETUP請求，要求服務端設定會話屬性和流媒體傳輸方式以建立會話。包內容包含用戶端軟體詳細資料，以及所需要的傳輸協議(RTP),傳播方式和用戶端用來接收資料的連接埠號碼

RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Mar 07 2012 03:48:07 GMT
Transport: RTP/AVP;unicast;destination=125.216.243.188;source=222.201.145.236;client_port=49970-49971;server_port=6970-6971/傳輸協議+傳播方式+目的IP+源IP+用戶端連接埠+服務端連接埠
Session: 62EC84AE//會話標識

解析：服務端接收到SETUP請求後建立會話，向用戶端返回會話詳細資料以及會話標識。會話標識是唯一的。至此一個會話建立完成。 (4)PLAY

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: 62EC84AE
Range: npt=0.000-//播放時間範圍，從第0秒到檔案播放完

解析：會話建立後，用戶端發出PLAY請求播放所申請的流媒體。傳輸機制按照SETUP命令所設定的進行。PLAY請求可以發送多次，伺服器會將請求放入隊列逐個處理。同時用戶端可以定義播放的時間範圍，比如從該流媒體的第N秒播放至第M秒。
RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Mar 07 2012 03:48:07 GMT
Range: npt=0.000-
Session: 62EC84AE
RTP-Info: url=rtsp://222.201.145.236/slamtv60.264/track1;seq=24735;rtptime=4146552907
解析：伺服器返回確認報文並開始傳輸串流媒體資料。資料轉送一般使用UDP發送

(5)GET_PARAMETER

GET_PARAMETER rtsp://222.201.145.236/slamtv60.264/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Session: 62EC84AE

RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Mar 07 2012 03:48:07 GMT
Session: 62EC84AE
解析：GET_PARAMETER請求檢查RUL指定的示範與媒體的參數值。沒有實體體時，GET_PARAMETER也許能用來測試使用者與伺服器的連通情況
RTCP包：

通過rtcp多次對話，判斷串連資料連線失敗。從而結束此次對話並選擇TCP協議進行下一次傳輸

（6）TEARDOWN

TEARDOWN rtsp://222.201.145.236/slamtv60.264/ RTSP/1.0
CSeq: 7
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Session: 62EC84AE

解析：流媒體全部傳輸完畢後，用戶端向服務端發出TEARDOWN請求，要求終止該會話。 RTSP/1.0 200 OK
CSeq: 7
Date: Wed, Mar 07 2012 03:48:18 GMT

解析：服務端響應TEARDOWN請求，發送迴響應報文並終止該會話，至此該會話結束，伺服器繼續等待下一個RTSP請求。

以上請求的是UDP資料包，但是請求失敗，於是選擇TCP方式進行傳輸：

（1）

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)

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

（2)

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

RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Mar 07 2012 03:48:18 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
t=0 0
a=tool:LIVE555 Streaming Media v2012.02.04
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:slamtv60.264
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 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//請求TCP協議傳輸RTP資料包

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

以下是RTP over RTSP（TCP）的資料流：

vlc通過兩次RTSP的會話建立起了rtc over tcp的會話，但是不知道問什麼，使用vlc直接用tcp串連的時候卻出現錯誤：

What does TCP Zero Window mean?

Zero Window is something to investigate.

TCP Zero Window is when the Window size in a machine remains at zero for a specified amount of time.

This means that a client is not able to receive further information at the moment, and the TCP transmission is halted until it can process the information in its receive buffer.

TCP Window size is the amount of information that a machine can receive during a TCP session and still be able to process the data. Think if it like a TCP receive buffer. When a machine initiates a TCP connection to a server, it will let the server know how much data it can receive by the Window Size.

In many Windows machines, this value is around 64512 bytes. As the TCP session is initiated and the server begins sending data, the client will decrement it's Window Size as this buffer fills. At the same time, the client is processing the data in the buffer, and is emptying it, making room for more data. Through TCP ACK frames, the client informs the server of how much room is in this buffer. If the TCP Window Size goes down to 0, the client will not be able to receive any more data until it processes and opens the buffer up again. In this case, Protocol Expert will alert a "Zero Window" in Expert View.

Troubleshooting a Zero Window For one reason or another, the machine alerting the Zero Window will not receive any more data from the host. It could be that the machine is running too many processes at that moment, and its processor is maxed. Or it could be that there is an error in the TCP receiver, like a Windows registry misconfiguration. Try to determine what the client was doing when the TCP Zero Window happened.