RTSP

RTSP被用於創建的控制媒體流的傳輸，它爲多媒體服務扮演「網絡遠程控制」的角色。儘管有時能夠把RTSP控制信息和媒體數據流交織在一塊兒傳送，但通常狀況RTSP自己並不用於轉送媒體流數據。媒體數據的傳送可經過RTP/RTCP等協議來完成。

一次基本的RTSP操做過程是:首先，客戶端鏈接到流服務器併發送一個RTSP描述命令（DESCRIBE）。流服務器經過一個SDP描述來進行反饋，反饋信息包括流數量、媒體類型等信息。客戶端再分析該SDP描述，併爲會話中的每個流發送一個RTSP創建命令(SETUP)，RTSP創建命令告訴服務器客戶端用於接收媒體數據的端口。流媒體鏈接創建完成後，客戶端發送一個播放命令(PLAY)，服務器就開始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過程當中客戶端還能夠向服務器發送命令來控制快進、快退和暫停等。最後，客戶端可發送一個終止命令(TERADOWN)來結束流媒體會話。

1、

一、OPTIONS

功能：
獲取服務器/客戶端支持的能力集
關鍵字段：無
特殊說明：IPTV系統中未使用該方法

 

 二、DESCRIBE

主要功能：
從服務器獲取流媒體文件格式信息
從服務器獲取流媒體文件傳輸信息
關鍵字段：
Content-Type：通常是SDP
Content-length：通常是SDP的長度
特殊說明：媒體信息經過SDP協議給出

 

 

 

3.SETUP
主要功能：
與服務器協商流媒體傳輸方式
此過程當中，創建RTP通道
關鍵字段：
Transport——傳輸方式
Transport: MP2T/RTP/UDP;unicast;destination=121.60.21.53;client_port=8342-8343,MP2T/RTP/TCP;unicast;destination=121.60.21.53;interleaved=0-1

 

 

 

 

四、PLAY
主要功能：
與服務器協商流媒體播放
關鍵字段：
Range——播放時間
•Range: npt=0.0-end
•Range:clock=20100318T021919.35Z-20100318T031919.80Z
Scale——播放速度
•Scale: 1.0

相對時間描述——npt(normalplay time)
方法1 位置描述
•beginning      節目起始點
•now               當前播放點
•end                節目結束點
方法2 時間描述
•直接用數字形式表示與起始點的時間
絕對時間描述——clock
ISO 8601時間戳標準

 

 

 

 

五、TEARDOWN

主要功能：拆除鏈接
關鍵字段：無

 

 

 

 

六、PAUSE
主要功能：
暫停流媒體播放
關鍵字段：無從服務器獲取參數，目前主要獲取時間範圍
保持RTSP鏈接（發送空的GET_PARAMETER）
關鍵字段（電信擴展）：
x-Timeshift_Range: clock=20100318T021915.84Z-20100318T031915.84Z
x-Timeshift_Current: clock=20100318T031915.84Z
可能存在的問題：
長時間Pause後，RTSP的TCP鏈接超時中斷。解決辦法——按期發送心跳包維持鏈接（參見GetParam）

七、GET PARAMETER
從服務器獲取參數，目前主要獲取時間範圍
保持RTSP鏈接（發送空的GET_PARAMETER）
關鍵字段（電信擴展）：
x-Timeshift_Range: clock=20100318T021915.84Z-20100318T031915.84Z
x-Timeshift_Current: clock=20100318T031915.84Z

 

 

 

 

2、簡單的rtsp消息交互的

1. 第一步：查詢服務器端可用方法
 1.C->S:OPTION request       //詢問S有哪些方法可用
1.S->C:OPTION response    //S迴應信息的public頭字段中包括提供的全部可用方法過程。

2. 第二步：獲得媒體描述信息
2.C->S:DESCRIBE request      //要求獲得S提供的媒體描述信息
2.S->C:DESCRIBE response    //S迴應媒體描述信息，通常是sdp信息
3. 第三步：創建RTSP會話
3.C->S:SETUP request             //經過Transport頭字段列出可接受的傳輸選項，請求S創建會話
3.S->C:SETUP response          //S創建會話，經過Transport頭字段返回選擇的具體轉輸選項，

並返回創建的Session ID;

4. 第四步：請求開始傳送數據
4.C->S:PLAY request        //C請求S開始發送數據
4.S->C:PLAY response            //S迴應該請求的信息
5. 第五步： 數據傳送播放中
S->C:發送流媒體數據    // 經過RTP協議傳送數據
6. 第六步：關閉會話，退出
6.C->S:TEARDOWN request      //C請求關閉會話
6.S->C:TEARDOWN response //S迴應該請求

上述的過程只是標準的、友好的rtsp流程，但實際的需求中並不必定按此過程。
其中第三和第四步是必需的！第一步，只要服務器客戶端約定好，有哪些方法可用，則option請求能夠不要。

第二步，若是咱們有其餘途徑獲得媒體初始化描述信息（好比http請求等等），

則咱們也不須要經過rtsp中的describe請求來完成。————————————————版權聲明：本文爲CSDN博主「Richard-Rong」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/rongdeguoqian/article/details/17888407