RTSP SDP RTP/RTCP
介紹應用層 RTSP、SDP；
傳輸層 RTP、TCP、UDP；
網絡層 IPSDP：
（1）SDP（Session Description Protocol）是服務器端生成的描述媒體文件的編碼信息以及所在服務器的鏈接等信息的文件，客戶端通過它來設置播放軟件的參數。SDP只是一種用于會話描述的協議，它并不是一種傳輸協議，只是用于在不同傳輸協議之間傳遞消息的通知協議，其主要目的是解決多媒體會話通知、邀請和另外一些媒體會話的初始化工作。
（2） SDP內容包括：會話名稱和目的、會話持續時間、媒體類（音頻、視頻等）、傳輸協議（RTP/UDP/IP，H.320等）、媒體編碼格式（MPEG4、H.263、H.264等）、接收媒體的相關信息端口和格式等。
RTSP：
（1）RTSP是應用級協議，用于流媒體服務器和終端播放器之間的媒體流會話的建立和控制。RTSP本身不被用于傳輸媒體數據，而是用于控制媒體流播放的過程，如會話建立、暫停、停止、快進、快退、錄制等。媒體傳輸協議和相應的參數在會話建立過程中雙方協商確定，一般采用RTP協議。RTSP是文本協議，其功能和HTTP及SIP類似，不同之處是RTSP及SIP本身不傳輸媒體流數據，而HTTP可以。
（2） RTSP可以承載在TCP或UDP之上（一般為TCP），端口號為554。RTSP通過定義一些“Method”來實現會話的控制，其主要的Mothod有：DESCRIBE、SETUP、PLAY、PAUSE、RECORD、REDIRECT、TEARDOWN等。同時，RTSP通過會話描述協議（SDP）來協商雙方的媒體格式、傳輸協議等。
RTP/RTCP：
（1）整個RTP 協議由兩個密切相關的部分組成：RTP 數據協議和RTP控制協議，當應用程序開始一個RTP會話時將使用兩對端口：一對用于RTP，另外一對用于RTCP。RTP是針對多媒體數據流的傳輸協議，能夠提供時間信息并提供流同步，但本身并不能提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。RTP通常采用UDP來傳送數據。
（2） RTCP和RTP一起提供流量控制和擁塞控制服務，RTCP的主要功能是為數據的傳送情況提供反饋。在RTP會話期間，各參與者周期性..傳送RTCP包，RTCP包中含有已發送的數據包數量、丟失的數據包數量等統計信息，服務器可以據這些信息動態收變傳輸速率，甚至收變有效負荷的類。RTP和RTCP配合使用，能夠以有效的反饋和最小的開銷使傳輸效率最佳化。
RTP/RTSP/RTCP的區別用一句簡單的話總結：RTSP發起/終結流媒體、RTP傳輸流媒體數據、RTCP對RTP進行控制，同步。
?RTP：實時傳輸協議（Real-time Transport Protocol）
RTP/RTCP是實際傳輸數據的協議oRTP傳輸音頻/視頻數據，如果是PLAY，Server發送到Client端，如果是RECORD，可以由Client發送到Server
整個RTP協議由兩個密切相關的部分組成：RTP數據協議和RTP控制協議（即RTCP）
?RTSP：實時流協議（Real Time Streaming Protocol，RTSP）
RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義可以知道起對話和控制作用
RTSP的對話過程中SETUP可以確定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的發送，等等
?RTCP：
RTP/RTCP是實際傳輸數據的協議
RTCP包括Sender Report和Receiver Report，用來進行音頻/視頻的同步以及其他用途，是一種控制協議
以下是每個協議的概要介紹：
一、RTP數據協議
RTP數據協議負責對流媒體數據進行封包并實現媒體流的實時傳輸，每一個RTP數據報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個字節的含義是固定的，而負載則可以是音頻或者視頻數據。其中比較重要的幾個域及其意義如下：
?CSRC記數（CC）：表示CSRC標識的數目。CSRC標識緊跟在RTP固定頭部之后，用來表示RTP數據報的來源，RTP協議允許在同一個會話中存在多個數據源，它們可以通過RTP混合器合并為一個數據源。例如，可以產生一個 CSRC列表來表示一個電話會議，該會議通過一個RTP混合器將所有講話者的語音數據組合為一個RTP數據源。
?負載類型（PT）：標明RTP負載的格式，包括所采用的編碼算法、采樣頻率、承載通道等。例如，類型2表明該RTP數據包中承載的是用ITU G.721算法編碼的語音數據，采樣頻率為8000Hz，并且采用單聲道。
?序列號：用來為接收方提供探測數據丟失的方法，但如何處理丟失的數據則是應用程序自己的事情，RTP協議本身并不負責數據的重傳。
?時間戳：記錄了負載中第一個字節的采樣時間，接收方能夠時間戳能夠確定數據的到達是否受到了延遲抖動的影響，但具體如何來補償延遲抖動則是應用程序自己的事情。
從RTP數據報的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數據等信息，這些都為實時的流媒體傳輸提供了相應的基礎。RTP協議的目的是提供實時數據（如交互式的音頻和視頻）的端到端傳輸服務，因此在RTP中沒有連接的概念，它可以建立在底層的面向連接或面向非連接的傳輸協議之上；RTP也不依賴于特別的網絡地址格式，而僅僅只需要底層傳輸協議支持組幀（Framing）和分段（Segmentation）就足夠了；另外RTP本身還不提供任何可靠性機制，這些都要由傳輸協議或者應用程序自己來保證。在典型的應用場合下，RTP一般是在傳輸協議之上作為應用程序的一部分加以實現的，
二、RTCP控制協議
RTCP控制協議需要與RTP數據協議一起配合使用，當應用程序啟動一個RTP會話時將同時占用兩個端口，分別供RTP和RTCP使用。RTP本身并不能為按序傳輸數據包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會采用與RTP相同的分發機制，向會話中的所有成員周期性地發送控制信息，應用程序通過接收這些數據，從中獲取會話參與者的相關資料，以及網絡狀況、分組丟失概率等反饋信息，從而能夠對服務質量進行控制或者對網絡狀況進行診斷。
RTCP協議的功能是通過不同的RTCP數據報來實現的，主要有如下幾種類型：
?SR：發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也可以是接收端。
?RR：接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。
?SDES：源描述，主要功能是作為會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。
?BYE：通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。
?APP：由應用程序自己定義，解決了RTCP的擴展性問題，并且為協議的實現者提供了很大的靈活性。
RTCP數據報攜帶有服務質量監控的必要信息，能夠對服務質量進行動態的調整，并能夠對網絡擁塞進行有效的控制。由于RTCP數據報采用的是多播方式，因此會話中的所有成員都可以通過RTCP數據報返回的控制信息，來了解其他參與者的當前情況。
在一個典型的應用場合下，發送媒體流的應用程序將周期性地產生發送端報告SR，該RTCP數據報含有不同媒體流間的同步信息，以及已經發送的數據報和字節的計數，接收端根據這些信息可以估計出實際的數據傳輸速率。另一方面，接收端會向所有已知的發送端發送接收端報告RR，該RTCP數據報含有已接收數據報的最大序列號、丟失的數據報數目、延時抖動和時間戳等重要信息，發送端應用根據這些信息可以估計出往返時延，并且可以根據數據報丟失概率和時延抖動情況動態調整發送速率，以改善網絡擁塞狀況，或者根據網絡狀況平滑地調整應用程序的服務質量。
三、RTSP實時流協議
作為一個應用層協議，RTSP提供了一個可供擴展的框架，它的意義在于使得實時流媒體數據的受控和點播變得可能。總的說來，RTSP是一個流媒體表示協議，主要用來控制具有實時特性的數據發送，但它本身并不傳輸數據，而是必須依賴于下層傳輸協議所提供的某些服務。RTSP可以對流媒體提供諸如播放、暫停、快進等操作，它負責定義具體的控制消息、操作方法、狀態碼等，此外還描述了與RTP間的交互操作。
由RTSP控制的媒體流集合可以用表示描述（Presentation Description）來定義，所謂表示是指流媒體服務器提供給客戶機的一個或者多個媒體流的集合，而表示描述則包含了一個表示中各個媒體流的相關信息，如數據編碼/解碼算法、網絡地址、媒體流的內容等。雖然RTSP服務器同樣也使用標識符來區別每一流連接會話（Session），但RTSP連接并沒有被綁定到傳輸層連接（如TCP等），也就是說在整個 RTSP連接期間，RTSP用戶可打開或者關閉多個對RTSP服務器的可靠傳輸連接以發出RTSP請求。此外，RTSP連接也可以基于面向無連接的傳輸協議（如UDP等）。
RTSP協議目前支持以下操作：
?檢索媒體：允許用戶通過HTTP或者其它方法向媒體服務器提交一個表示描述。如表示是組播的，則表示描述就包含用于該媒體流的組播地址和端口號；如果表示是單播的，為了安全在表示描述中應該只提供目的地址。
?邀請加入：媒體服務器可以被邀請參加正在進行的會議，或者在表示中回放媒體，或者在表示中錄制全部媒體或其子集，非常適合于分布式教學。
?添加媒體：通知用戶新加入的可利用媒體流，這對現場講座來講顯得尤其有用。RTSP請求也可以交由代理、通道或者緩存來進行處理。
RTSP消息格式: RTSP的消息有兩大類,一是請求消息(request),一是回應消息(response),兩種消息的格式不同.
請求消息:
方法 URI RTSP版本 CR LF
消息頭 CR LF CR LF
消息體 CR LF
其中方法包括OPTION回應中所有的命令,URI是接受方的地址,例如 :
rtsp://192.168.20.136
RTSP版本一般都是 RTSP/1.0.每行后面的CR LF表示回車換行，需要接受端有相應的解析，最后一個消息頭需要有兩個CR LF
回應消息:
RTSP版本 狀態碼 解釋 CR LF
消息頭 CR LF CR LF
消息體 CR LF
其中RTSP版本一般都是RTSP/1.0,狀態碼是一個數值,200表示成功,解釋是與狀態碼對應的文本解釋.
簡單的rtsp交互過程: C表示rtsp客戶端,S表示rtsp服務端
1.C->S:OPTION request //詢問S有哪些方法可用
1.S->C:OPTION response //S回應信息中包括提供的所有可用方法
2.C->S:DESCRIBE request //要求得到S提供的媒體初始化描述信息
2.S->C:DESCRIBE response //S回應媒體初始化描述信息，主要是sdp
3.C->S:SETUP request //設置會話的屬性，以及傳輸模式，提醒S建立會話
3.S->C:SETUP response //S建立會話，返回會話標識符，以及會話相關信息
4.C->S:PLAY request //C請求播放
4.S->C:PLAY response //S回應該請求的信息
S->C:發送流媒體數據
5.C->S:TEARDOWN request //C請求關閉會話
5.S->C:TEARDOWN response //S回應該請求
上述的過程是標準的、友好的rtsp流程，但實際的需求中并不一定按部就班來。其中第3和4步是必需的！第一步，只要服務器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述信息（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。第五步，可以根據系統需求的設計來決定是否需要。
rtsp中常用方法:
1.OPTION
目的是得到服務器提供的可用方法:
?OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每個消息都有序號來標記，第一個包通常是option請求消息
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器的回應信息包括提供的一些方法,例如:
?RTSP/1.0 200 OK Server: UServer 0.9.7_rc1
Cseq: 1 //每個回應消息的cseq數值和請求消息的cseq相對應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE,GET_PARAMETER //服務器提供的可用的方法
2.DESCRIBE
C向S發起DESCRIBE請求,為了得到會話描述信息(SDP):
?DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 2
token:
?Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器回應一些對此會話的描述信息(sdp):
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 2
x-prev-url: rtsp://192.168.20.136:5000
x-next-url: rtsp://192.168.20.136:5000
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri, 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp://192.168.20.136:5000/xxx666/
Content-Length: 344
Content-Type: application/sdp
v=0 //以下都是sdp信息
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136
s=/xxx666
u=http:///
e=admin@
c=IN IP4 0.0.0.0
t=0 0
a=isma-compliance:1,1.0,1 a=range:
npt=0-
m=video 0 RTP/AVP 96 //m表示媒體描述，下面是對會話中視頻通道的媒體描述
?a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=245; config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307 a=control:trackID=0//trackID＝0表示視頻流用的是通道0
3.SETUP 客戶端提醒服務器建立會話,并確定傳輸模式:
?SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
?//uri中帶有trackID＝0，表示對該通道進行設置。Transport參數設置了傳輸模式，包的結構。接下來的數據包頭部第二個字節位置就是interleaved，它的值是每個通道都不同的，trackID＝0的interleaved值有兩個0或1，0表示rtp包，1表示rtcp包，接受端根據interleaved的值來區別是哪種數據包。
服務器回應信息:
?RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 3 Session: 6310936469860791894
//服務器回應的會話標識符
Cache-Control: no-cache
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567
4.PLAY 客戶端發送播放請求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 4
Session: 6310936469860791894
Range: npt=0.000- //設置播放時間的范圍
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器回應信息:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 4
Session: 6310936469860791894
Range: npt=0.000000-
RTP-Info: url=trackID=0;
seq=17040;rtptime=1467265309 //seq和rtptime都是rtp包中的信息
5.TEARDOWN 客戶端發起關閉請求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 5
Session: 6310936469860791894
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器回應:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 5
Session: 6310936469860791894
Connection: Close
以上方法都是交互過程中最為常用的,其它還有一些重要的方法如 get/set_parameter,pause,redirect等等 ps: sdp的格式 v=o=s=i=u=e=p=c=b=:t=r=z=.... k=k=:a=a=:m=o = （所有者/創建者和會話標識符）
s = （會話名稱）
i = * （會話信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號碼）
c = * （連接信息）
b = * （帶寬信息）
z = * （時間區域調整）
k = * （加密密鑰）
a = * （0 個或多個會話屬性行）
時間描述：
t = （會話活動時間）
r = * （0或多次重復次數）
媒體描述：
m = （媒體名稱和傳輸地址）
i = * （媒體標題）
c = * （連接信息 — 如果包含在會話層則該字段可選）
b = * （帶寬信息）
k = * （加密密鑰）
a = * （0 個或多個媒體屬性行）
RTSP點播消息流程實例（客戶端：VLC， RTSP服務器：LIVE555 Media Server)
1)C(Client)-> M(Media Server)
OPTIONS rtsp://192.168.1.109/1.mpg RTSP/1.0
CSeq: 1
user-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)
1)M -> C
RTSP/1.0 200 OK
CSeq: 1
Date: wed, Feb 20 2008 07:13:24 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
2)C -> M
DESCRIBE rtsp://192.168.1.109/1.mpg RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)
2)M -> C
RTSP/1.0 200 OK
CSeq: 2
Date: wed, Feb 20 2008 07:13:25 GMT
Content-Base: rtsp://192.168.1.109/1.mpg/
Content-type: application/sdp
Content-length: 447
v=0
o =- 2284269756 1 IN IP4 192.168.1.109
s=MPEG-1 or 2 program Stream, streamed by the LIVE555 Media Server
i=1.mpg
t=0 0
a=tool:LIVE555 Streaming Media v2008.02.08
a=type:broadcast
a=control:*
a=range:npt=0-66.181
a=x-qt-text-nam:MPEG-1 or Program Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:1.mpg
m=video 0 RTP/AVP 32
c=IN IP4 0.0.0.0
a=control:track1
m=audio 0 RTP/AVP 14
c=IN IP4 0.0.0.0
a=control:track2
3)C -> M
SETUP rtsp://192.168.1.109/1.mpg/track1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP; unicast;client_port=1112-1113
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)
3)M -> C
RTSP/1.0 200 OK
CSeq: 3
Date: wed, Feb 20 2008 07:13:25 GMT
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1112-1113;server_port=6970-6971
Session: 3
4)C -> M
SETUP rtsp://192.168.1.109/1.mpg/track2 RTSP/1.0
CSeq: 4
Transport: RTP/AVP; unicast;client_port=1114-1115
Session: 3
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)
4)M -> C
RTSP/1.0 200 OK
CSeq: 4
Date: wed, Feb 20 2008 07:13:25 GMT
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1114-1115;server_port=6972-6973
Session: 3
5)C -> M
PLAY rtsp://192.168.1.109/1.mpg/ RTSP/1.0
CSeq: 5
Session: 3
Range: npt=0.000-
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)
5)M -> C
RTSP/1.0 200 OK
CSeq: 5
Range: npt=0.000-
Session: 3
RTP-Info: url=rtsp://192.168.1.109/1.mpg/track1;seq=9200;rtptime=214793785,url=rtsp://192.168.1.109/1.mpg/track2;seq=12770;rtptime=31721
(開始傳輸流媒體...)
一、整體框架圖
Android中基于NuPlayer的RTSP框架如下圖所示。
整個圖主要分為兩個部分，一部分是NuPlayer的架構，另一部分則是實現了基于RTSP的流媒體播放功能，即RTSPSource。當然還有一些其他的Source，如圖中的HTTPLiveSource，還有圖中沒有畫出的GenericSource、StreamingSource等，他們是并列關系，實現了不同的播放功能。
二、NuPlayer架構
1、NuPlayerDriver是對NuPlayer的封裝，與NuPlayerDriver處于并列位置的是StagefrightPlayer，他們都繼承MediaPlayerInterface接口。通過NuPlayer來實現播放的功能。
2、NuPlayer真正實現了播放的功能，通過各個Source的接口來得到數據流的信息和解碼數據本身。
三、RTSP功能實現架構（重點中的重點）
1、RTSPSource是NuPlayer架構的Source，給NuPlayer輸送媒體所需數據信息和媒體數據。在整個NuPlayer架構中，與RTSPSource并列的Source有HTTPLiveSource、GenericSource、StreamingSource，還有一個MP4Source，他們都繼承NuPlayer::Source。
2、MyHandler是RTSP的核心，其中包含ARTSPConnection和ARTPConnection兩大部分。MyHandler負責向Server端發送Request和處理Response，并負責將待解碼的媒體數據傳送給RTSPSource。
3、AnotherPacketSource在RTSPSource中作為mAudioTrack和mVideoTrack，他雖然繼承了MediaSource接口，但是并沒有使用read來讀數據，而是通過dequeueAccessUnit接口來獲得數據。RTSPSource通過調用queueAccessUnit結構將數據保存到這里。
4、ARTSPConnection負責維護RTSP的socket，發送Request，循環接收Server端數據，響應Server的Request。這里只是接收Response，真正的處理在MyHandler里。
5、ARTPConnection負責維護RTP和RTCP的socket，接收RTP和RTCP包，周期性發送RTCP包。需要說明的一點是，如果傳輸RTP和RTCP數據使用的是TCP，那么會共用RTSP的socket；如果用的是UDP，那么針對每個stream都會創建兩個socket，一個用于傳輸RTP數據，一個用于傳輸RTCP數據。
6、ARTPSource，每個RTP數據流都有一個ARTPSource，后者會創建一個ARTPAssembler。依據處理數據流的壓縮格式，實例化對應格式的Assembler。在ARTPSource中實現的一個最主要而且重要的功能就是根據SeqNum對RTP包進行排序。
7、ARTPAssembler對ARTPConnection接收到的數據進行處理，說的簡單一點就將接收到的媒體數據進行重組，以滿足解碼器的要求。如AVC數據，他會把單一NAL，NAL分片和復合NAL分別處理后，都以單獨NAL的形式回調傳給RTSPSource，存放在AnotherPacketSource中，供decoder端使用。目前支持的Assembler有一下幾種，他們都繼承ARTPAssembler。
（1）AAVCAssembler
（2）AMPEG4AudioAssembler
（3）AH263Assembler
（4）AAMRAssembler
（5）AMPEG4ElementaryAssembler
（6）ARawAudioAssembler
（7）AMPEG2TSAssembler
8、APacketSource用來包存和設置每個stream的屬性。針對每個stream都會創建一個APacketSource
