【正文】 ，其序號 +1 〃 這樣能發(fā)現(xiàn)丟失的分組，同時也能將時序的RTP重新排列好 Company Logo RTP（ Cont’ d） ? 時間戳：占 32位，反映了 RTP分組中的數據的第一個字節(jié)的采樣時刻。 ? RTP的協(xié)議數據單元是用 UDP分組來承載的。 RTP—— RTP協(xié)議的相關概念 (4) Payload Type（載荷類型） ? 對傳輸的音、視頻等數據類型予以說明，并說明相關的編碼方式，接收端從而知道如何解碼和播放負載數據。 ? 對于語音來說，時戳按封包間隔和采樣速率乘積而遞增； ? 對于視頻來說，時戳的生成依賴于應用程序是否能夠分辨其幀數。 ? MMSP (Microsoft Media Server Protocol) 流媒體協(xié)議在 IP/TCP協(xié)議中的位置 ? RTP（ Realtime Transport Protocol）實時運輸協(xié)議 —— 為實時應用提供端到端的運輸，但不提供任何服務質量的保證。 流媒體傳輸協(xié)議簡介 ? RTP (Realtime Transport Protocol)：針對多媒體數據流。 ? 低于 1兆的連接速率稱為窄帶接入； ? 高于 1兆的連接速率稱為寬帶接入。 （ 2）誤碼率：信息傳輸的錯誤率。 ? 信號速率 S是指單位時間內所傳送的二制位代碼的有效位數，以 bps為單位。 Inter傳輸的基本概念（ Cont’ d） 2. 信道和帶寬 （ 1）信道 ? 按照其存在形式分為有線信道和無線信道； ? 按照其傳輸信號的類型分為模擬信道和數字信道。 ? 模擬數據是指由傳感器采集得到的連續(xù)變化的值。 ? 數字數據是指模擬數據經采集、量化、編碼后所得到的離散的值。 （ 2）帶寬 ? 信號帶寬是指信號以電磁波形式傳輸，電磁波的頻譜范圍； ? 信道帶寬是指信道上能夠傳送的最大頻率范圍； ? 在通信過程中，信號帶寬必須小于信道帶寬； ? 帶寬單位為 MHz。 ? 調制速率 B是指脈沖信號經過調制后的傳輸速率，以 BAUD為單位。 ? Pe＝出錯比特數 /傳輸比特數 ? 網絡的誤碼率主要取決于信源至信宿之間的信道的質量。 Inter傳輸服務質量 ? Quality of Service (QoS) 1. 盡力傳送（ Besteffort ） ? 單一服務模型 ? 應用程序可以在任何時候，發(fā)出任意數量的報文，而且不需要事先獲得批準，也不需要通知網絡。 ? RTCP (Realtime Transport Control Protocol)：與 RTP一起提供流量控制和擁塞控制服務。 多媒體數據塊 封裝為RTP報文 UDP用戶數據報 壓縮編碼 送入運輸層 從開發(fā)者的角度看， RTP 應當是應用層的一部分。如果能夠分辨幀速率，則使用一個固定的速率增加。 (5) Mixer（混合器） ? 將多個載荷數據組合起來產生一個發(fā)出的包，允許接收端確認當前數據的貢獻源，具有相同的同步源標識符。 ? RTP協(xié)議雖然是傳輸層協(xié)議但是沒有作為OSI體系結構中單獨的一層來實現(xiàn)。 〃 在一個會話中，他的初始序號隨機選擇。 〃 時間戳的粒度取決于信號的類型。絕對時鐘時間 ： RTP要求每一種媒體使用一個流，而視音頻就得用倆的流，絕對時鐘時間可進行圖像和聲音的同步 RTCP—— RTCP分組格式 RTSP 1. RTSP協(xié)議的工作原理 （ 1） RTSP協(xié)議的功能 ? A. 通過媒體服務器檢索媒體 ? B. 媒體服務器邀請進入會議 ? C. 將媒體加到現(xiàn)成講座中 RTSP—— RTSP協(xié)議 的工作原理 （ 2） RTSP協(xié)議的實現(xiàn) ? A. 初始化 ? B. TCP傳輸 ? C. UDP傳輸 ? D. 傳輸反饋 利用 RTSP的流媒體連接過程 OPTION OPTION Response 服務器信息 DESCRIBE DESCRIBE Response 待播放的文件信息 SETUP SETUP Response 連接信息 PLAY PLAY Re播放信息 TEARDOWN TEARDOWN Response RTSP（ Cont’d） 2. RTSP協(xié)議的結構 (p84) 具體解釋另見補充（ RTSP協(xié)議） RTSP（ Cont’d） 3. RTSP協(xié)議的特點 ? （ 1）可擴展性 ? （ 2）易解析 ? （ 3）安全 ? （ 4）獨立于傳輸 ? （ 5）多服務器能力 ? （ 6）記錄設備控制 ? （ 7）適合專業(yè)應用 ? （ 8）播放種類的中立性 ? （ 9）代理和防火墻的友好性 ? （ 10）分配服務器控制 ? （ 11）傳輸協(xié)商 ? （ 12）能力協(xié)商 RTSP（ Cont’d） 4. RTSP協(xié)議與其他協(xié)議的關系 （ 1） RTSP協(xié)議與 HTTP協(xié)議的聯(lián)系 ? 目前的協(xié)議規(guī)范同時允許網頁服務器和流媒體服務器支持 RTSP實現(xiàn)。資源預留的過程從應用程序流的源節(jié)點發(fā)送 Path消息開始，該消息會沿著流所經路徑傳到流的目的節(jié)點，并沿途建立路徑狀態(tài)；目的節(jié)點收到該 Path消息后，會向源節(jié)點回送 Resv消息，沿途建立預留狀態(tài)，如果源節(jié)點成功收到預期的 Resv消息，則認為在整條路徑上資源預留成功。 ? （ 4）當最后一個路由器接收 RESV，同時接受請求的時候，它再發(fā)送一個證實消息給接收端。 ? 最好性能傳輸為傳統(tǒng) IP傳輸。 ? 延遲敏感傳輸要求傳輸及時，并因而改變其速率。 ? IP目的地址是組播發(fā)送的組地址，或是單個接收者的單播地址。即使目的地址是單播，也可能有多個接收者，以公開端口區(qū)分。 RSVP（ Cont’ d） 4. RSVP服務質量（ QoS） ? 是流規(guī)范指定的屬性 。 ? 這樣做 ， RSVP就可維持路由器和主機狀態(tài)來提供所請求的服務 。 ? 接收者應用收到路徑信息 ， 開始發(fā)送相應資源預訂請求信息 ， 使用 RSVP指定欲點播的流描述 。一般說來， 軟狀態(tài)由基于 RSVP網絡維護，使網絡可在沒有查詢終端結點的情況下改變狀態(tài)。如在清除時間間隔到期前沒有收到相應更新信息，就刪除該狀態(tài)，顯式 teardown信息也可刪除軟狀態(tài)。 ? RSVP規(guī)范要求在拓撲改變后兩秒通過網絡初始化新資源預訂。 RSVP（ Cont’ d） 8. RSVP操作模型 —— 基本 RSVP協(xié)議操作 ? RSVP資源預訂處理初始化開始于 RSVP 后臺服務查詢本地路由協(xié)議以獲得路由。如數據鏈路層媒介有自身的 QoS管理能力，包調度器負責協(xié)調數據鏈路層，獲得 RSVP所請求的QoS。 ? 在每個結點處， RSVP程序應用一個稱為 進入允許控制的本地決定程序 決定是否能提供所請求的QoS。實際上， RSVP決不可能在每個地方都被配置。 ? 隧道技術要求 RSVP和非 RSVP路由器用本地路由表轉發(fā)到目的地址的路徑信息。 ? 與 ICMP和 IGMP相比，它是一個控制協(xié)議。發(fā)送一個流前，發(fā)送者傳輸一個路 徑信息到目的接收方，這個信息包括源 IP地址、目的 IP地址和一個流規(guī)格。因為 RSVP的預定必須建立在完全流方式的基礎上，其可擴展性問題倍受關注。 ? 使用 協(xié)議翻轉 以獲得最佳連接。