RTSP信令的交互

RTSP 有如下信令： 
 


在这之前建立一个TCP　socket用来作信令交互，叫做TCPSockfd 
OPTIONS: 
功能： 请求用于返回服务端支持的 RTSP 命令列表 
信令交互： 
C->S:  
OPTIONS * RTSP/1.0 
CSeq: 1 
Require: implicit-play 
Proxy-Require: gzipped-messages 

S->C:  
RTSP/1.0 200 OK 
CSeq: 1 
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 
这个信令不常用，一般client端知道对接的服务器有哪些命令 
CSeq：信令序列号，后面的序列号累计增加。 


DESCRIBE： 
功能： 用于请求指定的媒体流的 SDP 描述信息 。 
信令交互： 
C->S: 
DESCRIBE rtsp://10.50.108.17/vod/957509 RTSP/1.0 
CSeq: 2 
Accept: application/sdp 
S->C: 
RTSP/1.0 200 OK 
CSeq: 2 
Content-Type: application/sdp 
Content-Length: 376 

v=0 
o=- 2890844526 2890842807 IN IP4 10.50.108.17 
s=RTSP Session 
t=0 0 
r=15 0 0 0 
i= 
b=AS:1600 
c=IN IP4 0.0.0.0 
m=video 0 RTP/AVP 33 
a=rtpmap:33 MP2T/90000 
a=range:npt= 0.000-566.000//媒体流的开始时间和结束时间，以S为单位 


在descripe之后，我们建立一个UDP的socket，用于RTP包的传输，UDPSockfd,bind到一个端口，比如： 26958 
SETUP : 
功能：  命令用于配置数据交付的方法 
信令交互： 
C->S: 
SETUP rtsp://10.50.108.17/vod/957509/ RTSP/1.0 
CSeq: 2 
Transport: RTP/AVP;unicast;client_port= 26958 -26959 //通知server　发送RTP包给client这个端口,后面的26959是rtcp端口，一般没有实现 
User-Agent: CTC RTSP 1.0 
S->C: 
RTSP/1.0 200 OK 
CSeq: 2 
Session: 10145778//rtsp的session,之后的信令都要带上这个参数，并保持一致 
Transport: MP2T/RTP/UDP;unicast; destination=172.19.133.128:26958;control_address=10.50.108.17:554 ;mode=play;QAM_FRQ=131073 


172.19.133.128:26958 client端IP和port 

10.50.108.17:554　server端IP和port 


setup之后有必要做一个natdetect:私有信令，这个信令是是用UDPSockfd发的，收也是UDPSockfd来收,这样就做了一个nat穿越 
NAT_DETECT 
C->S: 
NAT_DETECT rtsp://10.50.108.17/vod/957509 RTSP/1.0 
CSeq: 1 
S->C: 




PLAY : 
功能：请求流 
C->S 
rtsp://10.50.108.17/vod/957509 RTSP/1.0 
CSeq: 3 
Session: 10145778 
User-Agent: CTC RTSP 1.0 


S->C: 
RTSP/1.0 200 OK 
CSeq: 3 
Session: 10145778 
Scale: 1.0 
Range: npt=0.000-0.000 


PAUSE 
功能：暂停 
C->S 
PAUSE rtsp://10.50.108.17/vod/957509 RTSP/1.0 
CSeq: 5 
Session: 10145778 
User-Agent: CTC RTSP 1.0 
S->C 
RTSP/1.0 200 OK 
CSeq: 5 
Session: 10016005 


GET_PARAMETER ：心跳作用 
C->S: 
GET_PARAMETER rtsp://10.50.108.17/vod/957509 RTSP/1.0 
CSeq: 4 
Session: 10145778 
User-Agent: CTC RTSP 1.0 
S->C: 
RTSP/1.0 200 OK 
CSeq: 4 
Session: 10145778 


ANNOUNCE : 
也是用UDPSockfd来收的，用来处理边界值 












RTP头： 

前12个字节在每一个RTP packet中都存在，而一系列的CSRC标记只有存在Mixer时才有。 
   version (V): 2 bits 
      标明RTP版本号。协议初始版本为0，RFC3550中规定的版本号为2。 
   padding (P): 1 bit 
      如果该位被设置，则在该packet末尾包含了额外的附加信息，附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因为一些加密机制需要固定长度的数据块，或者为了在一个底层协议数据单元中传输多个RTP packets。 
   extension (X): 1 bit 
      如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。 
   CSRC count (CC): 4 bits 
      在固定头部后存在多少个CSRC标记。 
   marker (M): 1 bit 
      该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。 
   payload type (PT): 7 bits 
      标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。 
   sequence number: 16 bits 
      序列号，每个RTP packet发送后该序列号加1，接收方可以根据该序列号重新排列数据包顺序。 
   timestamp: 32 bits 
      时间戳。反映RTP packet所携带信息包中第一个字节的采样时间。 
   SSRC: 32 bits 
      标识数据源。在一个RTP Session其间每个数据流都应该有一个不同的SSRC。 
   CSRC list: 0 to 15 items, 32 bits each 
      标识贡献的数据源。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。