服务器：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.