【正文】 會話時，初始序號隨機選擇 〃 每發(fā)出一個 RTP分組，其序號 +1 〃 這樣能發(fā)現(xiàn)丟失的分組，同時也能將時序的RTP重新排列好 Company Logo RTP（ Cont’ d） ? 時間戳：占 32位，反映了 RTP分組中的數(shù)據(jù)的第一個字節(jié)的采樣時刻。 〃 在一個會話中，他的初始序號隨機選擇。 〃 即使沒有信號發(fā)送，時間戳的數(shù)值也要隨時間而不斷地增加。 〃 接收端使用時間戳可準確知道應(yīng)當在什么時間還原那一個數(shù)據(jù)塊，從而消除時延抖動。 〃 時間戳還可以使視頻應(yīng)用中的聲音和圖像同步。 〃 時間戳的粒度取決于信號的類型。如某話音信號 8kHz采樣，每隔 20ms構(gòu)成一個數(shù)據(jù)塊，則數(shù)據(jù)塊中包含 160個樣本*8000=160 Company Logo RTP（ Cont’ d） Company Logo 如果只有系列號，并不能完整按照順序的將 data播放出來，因為如果 data中間有一段是沒有資料的，只有系列號的話會造成錯誤，需搭配上讓它知道在哪個時間將 data正確播放出來，如此我們才能播放出正確無誤的信息 RTP（ Cont’ d） ? 同步源標識符： 32位 SSRC 表示 RTP的來源 ? SSRC與 IP地址無關(guān) ，是隨機產(chǎn)生的，兩個RTP流恰好選擇同一個 SSRC流的概率極小 〃 多個 RTP流可復(fù)用到 1個 UDP用戶數(shù)據(jù)報中 〃SSRC 可使接收端的 UDP能夠?qū)⑹盏降?RTP流送到各自的終點 Company Logo RTP（ Cont’ d） ? 參與源標識符： 32位， CSRC，用來標志源于不同地點的 RTP流 ? 在多播環(huán)境中，可以用中間的一個站（混合站）把發(fā)往同一個地點的多個 RTP流混合成一個流（可節(jié)省通信資源），而 CSRC的數(shù)值就可以把不同的 RTP流分開 RTP（ Cont’ d） RTP（ Cont’ d） ? RTP包傳輸流程 RTP（ Cont’ d） 4. RTP協(xié)議的特點 ? RTP協(xié)議具有很大的靈活性 ? 數(shù)據(jù)流和控制流分離 ? RTP協(xié)議具有很大的擴展性和適用性 RTCP 1. RTCP協(xié)議的工作原理 —— 四個功能： ? （ 1）為數(shù)據(jù)傳輸?shù)馁|(zhì)量提供反饋，并提供 QoS檢測 ? （ 2）提供不同媒體間的同步 ? （ 3）在會話的用戶界面上顯示會話參與者的標志 ? （ 4）調(diào)節(jié)信息的縮放 RTCP（ Cont’d） 2. RTCP分組格式 2 3 8 16bit Version P RC Packet type Length RTCP—— RTCP分組格式 5種類型的報文： ? SR ? RR ? SDES ? BYE ? APP 類型 縮寫表示 意義 200 SR 發(fā)送端報告 201 RR 接收端報告 202 SDES 源點報告 203 BYE 結(jié)束 204 APP 特定應(yīng)用 RTCP—— RTCP分組格式 ? 結(jié)束分組 BYE：表示關(guān)閉一個數(shù)據(jù)流 ? 特定應(yīng)用分組 APP：使應(yīng)用程序定義新的分組類型 ? 源點描述分組 SDES：給出會話中參加者的描述，他包含參加者的規(guī)范名 CNAME（電子郵件地址的字符串） RTCP—— RTCP分組格式 ? 接收端報告分組 RR：接收端周期性地向所有的點用多播方式進行報告。 ? 接收端每收到一個 RTP流就產(chǎn)生一個接受端報告分組 RR， ? RTP流的 SSRC； RTP流的分組丟失率；該RTP流中的最后一個 RTP分組的序號；分組到達時間間隔的抖動等。 RTCP—— RTCP分組格式 Company Logo RR的兩大作用 1 讓所有接收端和發(fā)送端了解當前網(wǎng)絡(luò)的狀態(tài) 2 可以使所有發(fā)送RTCP分組的站點自適應(yīng)調(diào)整自己發(fā)送 RTC分組的速率，使 RTCP不影響RTP網(wǎng)絡(luò)分組的速率 ? 發(fā)送報告端分組 SR：發(fā)送端周期性地向所有接受端用多播方式進行報告 ? 發(fā)送端每發(fā)送一個發(fā)送端報告分組 RTP，就發(fā)送一個發(fā)送端報告分組 SR ? 該 RTP的 SSRC、時間戳、絕對時鐘時間、分組數(shù)、字節(jié)數(shù) 絕對時鐘時間 ： RTP要求每一種媒體使用一個流，而視音頻就得用倆的流，絕對時鐘時間可進行圖像和聲音的同步 RTCP—— RTCP分組格式 RTSP 1. RTSP協(xié)議的工作原理 （ 1） RTSP協(xié)議的功能 ? A. 通過媒體服務(wù)器檢索媒體 ? B. 媒體服務(wù)器邀請進入會議 ? C. 將媒體加到現(xiàn)成講座中 RTSP—— RTSP協(xié)議 的工作原理 （ 2） RTSP協(xié)議的實現(xiàn) ? A. 初始化 ? B. TCP傳輸 ? C. UDP傳輸 ? D. 傳輸反饋 利用 RTSP的流媒體連接過程 OPTION OPTION Response 服務(wù)器信息 DESCRIBE DESCRIBE Response 待播放的文件信息 SETUP SETUP Response 連接信息 PLAY PLAY Re播放信息 TEARDOWN TEARDOWN Response RTSP（ Cont’d） 2. RTSP協(xié)議的結(jié)構(gòu) (p84) 具體解釋另見補充（ RTSP協(xié)議） RTSP（ Cont’d） 3. RTSP協(xié)議的特點 ? （ 1）可擴展性 ? （ 2）易解析 ? （ 3）安全 ? （ 4）獨立于傳輸 ? （ 5）多服務(wù)器能力 ? （ 6）記錄設(shè)備控制 ? （ 7）適合專業(yè)應(yīng)用 ? （ 8）播放種類的中立性 ? （ 9）代理和防火墻的友好性 ? （ 10）分配服務(wù)器控制 ? （ 11）傳輸協(xié)商 ? （ 12）能力協(xié)商 RTSP（ Cont’d） 4. RTSP協(xié)議與其他協(xié)議的關(guān)系 （ 1） RTSP協(xié)議與 HTTP協(xié)議的聯(lián)系 ? 目前的協(xié)議規(guī)范同時允許網(wǎng)頁服務(wù)器和流媒體服務(wù)器支持 RTSP實現(xiàn)。 （ 2） RTSP協(xié)議與 HTTP協(xié)議的區(qū)別 ? HTTP是一個不對稱協(xié)議；在 RTSP中， Client和 Server都可發(fā)出請求，且請求是有狀態(tài)的。 ? HTTP是無狀態(tài)協(xié)議； RTSP在任何情況下必須保持一定狀態(tài)。 ? 資源預(yù)留協(xié)議（ RSVP）最初是 IETF為 QoS的綜合服務(wù)模型定義的一個信令協(xié)議，用于在流（ flow）所經(jīng)路徑上為該流進行資源預(yù)留，從而滿足該流的QoS要求。資源預(yù)留的過程從應(yīng)用程序流的源節(jié)點發(fā)送 Path消息開始，該消息會沿著流所經(jīng)路徑傳到流的目的節(jié)點，并沿途建立路徑狀態(tài)；目的節(jié)點收到該 Path消息后，會向源節(jié)點回送 Resv消息，沿途建立預(yù)留狀態(tài)，如果源節(jié)點成功收到預(yù)期的 Resv消息，則認為在整條路徑上資源預(yù)留成功。 RSVP RSVP 1. RSVP協(xié)議工作原理 ? （ 1）發(fā)送端依據(jù)傳輸帶寬范圍的高低、傳輸延遲，以及抖動來說明發(fā)送業(yè)務(wù)。 ? （ 2）為了獲得資源預(yù)留，接收端發(fā)送一個上行的 RESV（預(yù)留請求）消息。 ? （ 3）當每個支持 RSVP的路由器沿著上行路徑接收 RESV的消息時，它采用輸入控制過程證實請求，并且配置所需的資源。 ? （ 4）當最后一個路由器接收 RESV，同時接受請求的時候，它再發(fā)送一個證實消息給接收