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