多媒體編碼與通信

第4章多媒體的傳輸趙海武上海大學通信與信息工程學院networkmultimedia@126.com2014年2月第4章多媒體的傳輸目錄4.1多媒體應用協議套4.1.1多媒體應用協議套4.1.2多媒體應用相關協議摘要4.2實時傳輸和控制協議4.2.1實時傳輸協議(RTP)4.2.2實時控制協議(RTCP)4.3實時流播協議4.3.1RTSP協議概要4.3.2RTSP協議原理4.4資源保留協議4.4.1RSVP協議概要4.4.2RSVP協議原理4.4.3RSVP文件4.5會話啟動協議4.5.1SIP概要4.5.2SIP的請求和響應4.5.3SIP服務器4.5.4SIP的消息結構4.6會話描述和會話通告協議4.6.1會話描述協議(SDP)4.6.2會話通告協議(SAP)4.7多目標廣播4.7.1多目標廣播的概念4.7.2多目標廣播地址4.7.3網際機組管理協議(IGMP)4.7.4多目標廣播路徑選擇簡介4.4資源保留協議RSVP=ResourceReSerVationSetupProtocol保留的網絡資源鏈路帶寬路由器緩存RSVP協議需要在接收端主機、發送端主機、以及沿途所有路由器上執行RFC22054.4.1資源保留協議4.4.1資源保留協議4.4.1資源保留協議RSVP是接收端啟動的協議接收端向發送端發送QoS請求，這個請求逆向傳送給沿途的所有路由器直到發送端接收端通過其他途徑獲得會話所需的資源情況HTTPSAP/SDPRSVP是信令協議RSVP利用本地的路由表獲取路徑4.4.1RSVP的工作過程RSVP的處理對象是會話RSVPsession=(DestAddress,ProtocolId[,DstPort])DestAddress是數據流的目的地址，可能是單播地址或多播地址ProtocolId是IP協議的IDDstPort是可選參數，應當是通用的目的端口號DstPort可以是UDP/TCP端口，也可以是其他傳輸層協議的等價域或者應用程序規定的域RSVP認為會話之間是相互獨立的4.4.1資源保留協議RSVP的資源保留狀態由于用戶可能隨時加入或退出會話，因此傳送路徑可能隨時發生變化，這就需要發送端周期性地發送路徑消息，接收端周期性的發送資源保留消息，用于維護沿途路由器的資源保留狀態在沒有刷新消息時，路由器將自動刪除資源保留狀態這種資源保留狀態稱為“交換狀態(switchstate)”，又稱為‘軟狀態’4.4.2RSVP的消息公共頭：8字節，7個域Vers：4位，協議版本號，RFC2205的版本號是1Flags：4位，未定義MsgType：8位，RSVPChecksum：16位，0表示沒有檢查和Send_TTL：8位，攜帶此RSVP消息的IP包的TTL值RSVPLength：16位，本消息的長度（單位：字節），包括公共頭和消息體4.4.2RSVP的工作過程RSVP的消息有7種PathmessageResvmessagePathErrorMessagesResvErrorMessagesPathTeardownMessagesResvTeardownMessagesResvConfirmationMessages4.4.2RSVP的消息4.4.2RSVP的消息Path消息<PathMessage>::=<CommonHeader> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<POLICY_DATA>...] [<senderdescriptor>]<senderdescriptor>::=<SENDER_TEMPLATE> <SENDER_TSPEC> [<ADSPEC>]4.4.2RSVP的消息Path消息的主要內容previoushopaddress：上一跳的地址SenderTemplate：發送端所發數據流的格式，用于篩選SenderTspec：發送端所發數據流的碼率規格Adspec：可選的域，收集數據流傳送沿途的信息直到接收端，接收端可根據此信息構建或動態調整QoS請求4.4.2RSVP的消息Rsev消息<ResvMessage>::=<CommonHeader> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<RESV_CONFIRM>][<SCOPE>] [<POLICY_DATA>...] <STYLE><flowdescriptorlist><flowdescriptorlist>::=<empty>| <flowdescriptorlist><flowdescriptor>4.4.3RSVP資源保留方式資源保留方式FF類型：為指定的發送端保留獨占的資源SE類型：為一組指定的發送端保留組內共享資源WF類型：為所有發送端保留共享資源WF和SE適用于廣播且不同的發送端通常不會同時發送數據的應用，而FF類型適用于單播4.4.3RSVP資源保留方式資源需求量和參與者數量之間的關系FF類型的請求不能合并，資源總的需求量是各個請求的算術和，和參與者數量是線性關系WF和SE類型的資源請求，可以在每個節點處進行合并，即節點需保留的帶寬等于下游申請保留帶寬的最大值，和參與者數量是對數關系4.4.3RSVP資源保留方式圖4-7RSVP的資源請求合并4.4.4RSVP的工作過程典型的RSVP會話過程如圖4-7所示，包含如下事件(1)發送端周期性地向session發送PATH消息，通告視聽數據流的規范，在路由器中建立逆向路徑，如圖4-7(a)所示(1.5)在某些應用中，如果想加入會話，接收端主機需要先注冊(2)接收端周期性地向發送端發送RESERVE消息，如圖4-7(b)所示，建立或刷新資源保留狀態4.4.4RSVP的工作過程(3)路由器根據PATH消息和RESERVE消息，修改資源保留狀態和視聽數據流的傳送路徑，盡量合并RESERVE消息，把合并后的RESERVE消息傳送到下一個節點，如圖4-7(c)所示(4)發送端收到最終的RESERVE消息后就開始發送視聽數據4.4.4RSVP微觀工作過程在資源申請建立的過程中，RSVP請求被傳送到兩個本地模塊：接納控制模塊和策略控制模塊接納控制模塊：決定該節點是否有足夠的資源可以滿足該RSVP請求策略控制模塊：決定用戶是否有權限申請這類服務。如果全部通過，那么RSVP請求的QoS參數就會輸入到包分類器和包調度器（鏈路層接口）完成資源預留。如果任一模塊的檢測沒有通過，那么提出該RSVP請求的應用程序進程將會得到一個錯誤的返回。RSVP并沒有規定接納控制模塊和策略控制模塊的算法，也沒有規定包分類器和包調度器的算法2023年2月3日4.4.4RSVP微觀工作過程4.4.5一個問題發送端的數據速率問題接入因特網的用戶是多種多樣的，有的使用28.8kbps速率接收數據，有的使用128kbps速率接收數據，而有的使用10Mbps甚至更高的速率接收數據。發送端到底用什么樣的數據速率向這些接收數據速率不同的用戶傳送數據？才能使所有用戶接收到？4.4.5一個問題問題的解決方案解決這個問題的一種方案是在發送端對聲音或電視進行分層編碼，每層聲音或影視的數據速率各不相同，把它們都發送到網上，以此來滿足各種不同用戶的要求。發送端不一定要知道每個接收端接收數據的速率，只需要知道這些用戶使用哪幾種接收速率即可4.5SIP概述SIP=SessionInitiationProtocolSIP的功能SIP用于創建、管理和終止任何形式的互動會話，如IP電話、多媒體會議、軟件發行、互動游戲和聊天等SIP是應用層上的協議SIP是信令協議SIP需要和很多其他協議一起工作，例如HTTP、SMTP、SDP、RTSP等4.5SIP概述歷史回顧源于90年代中期，IETF組織編寫MMUSIC標準1996年他向IETF提交了一個草案，其中包含了SIP的概念，主要針對電子郵件和文字聊天等文本應用1999年3月再次提交，刪除了關于媒體內容方面的部分，隨后IETF把它作為SIP規范第一版發布，編號RFC2543當時關于多媒體會話控制已經有了H.323和MGCP1999年9月SIP工作組從MMUSIC工作組中分離出來2002年IETF發布RFC3261，標志著SIP的基礎確立4.5.1SIP概述——相關協議SIP相關文件可在/sip/drafts.html上找到。RFC3261(2002)：SIP協議的核心規范RFC2327(1998)：會話描述協議(SDP)RFC1889(1996)：實時傳輸協議(RTP)RFC2326(1998)：實時流播協議(RTSP)RFC3262(2002)：SIP協議中100~199消息的可靠性RFC3263(2002)：使用DNS查找SIP服務器RFC3264(2002)：使用會話描述協議(SDP)的方法RFC3265(2002)：SIP事件通告RFC3266(2002)：SDP協議對IPv6的支持RFC3311(2002)：SIP修改方法RFC3361(2002)：使用DHCP查找外向SIP代理服務器RFC3428(2002)：用于即時通的SIP RFC3515(2003)：SIP調用(REFER)方法，如呼叫轉移

4.5.1SIP概述SIP已得到廣泛認可和采納SIP已經被用于3G移動通信網絡的會話控制微軟已經在WindowsXP、PocketPC和MSN中采用了SIP，并計劃在CE.net中使用基于SIP的VoIP接口層SunMicrosystems在JAVA語言中定義了支持SIP的應用編程接口QQ等網絡通信工具也使用了SIPSIP已成為繼HTTP和SMTP之后的最重要的協議之一4.5.1SIP概述——特性(1)易讀性強：用文本來描述SIP消息(2)相對簡單：只有6種基本方法，把它們組合在一起就可完成多媒體會話呼叫的控制，減少了復雜性(3)獨立于傳輸層：SIP可以使用UDP,TCP和定義在RFC4346(2006)的傳輸層安全(TransportLayerSecurity，TLS)等協議4.5.1SIP概述——特性(4)客戶機/服務機結構：SIP共享HTTP和SMTP的設計原理，共享HTTP的狀態碼(5)移動性強：可用統一資源標識符(URI)查找用戶(6)需要其他協議輔助：如使用會話描述協議(SDP)來描述會話(7)不提供服務質量(QoS)保障方法，但可與RSVP等協議聯用(8)靈活可擴展：SIP能夠連接任何IP網絡：有線LAN/WAN、3G、WiFiSIP能夠連接任何IP設備：電話、PC、PDA、手機4.5.2SIP的請求和響應圖4-8IP電話使用SIP的基本呼叫方法4.5.2SIP的請求和響應在IP電話系統中，用SIP的基本呼叫方法，如圖4-8所示(1)SIP代理服務器(SIPproxyserver)：用于來回傳遞SIP消息的服務器(2)SIP用戶代理(SIPuseragent)：通信雙方使用的收發SIP消息的設備，如電話機、安裝有SIP客戶軟件的電腦、手機、PDA等4.5.2SIP的請求和響應(1)A通過代理服務器向B發出通話INVITE(邀請)，①和②；(2)代理服務器用代碼100(試試看)回應A，③；(3)B用代碼180(響鈴)通過代理服務器回應A，④和⑤；(4)B用代碼200(OK)通過代理服務器響應A，⑥和⑦；(5)A通過代理服務器向B發送ACK(確認)，⑧和⑨；(6)A和B通過RTP通話；(7)B通過代理服務器向A發送BYE(再見)，⑩和；(8)A通過代理服務器向B發送OK，和；(9)整個過程結束4.5.2SIP的請求和響應SIP請求用文字表示，SIP響應用3位數字表示SIP的請求和響應統稱為消息SIP請求說明INVITE(邀請)邀請用戶參加會話ACK(響應)確認INVITE得到響應OPTIONS(選項)請求提供服務器能力的消息CANCEL(取消)終止請求BYE(再見)終止用戶之間的連接REGISTER(注冊)登記用戶當前所在地INFO(消息)會話期間的信令表4-4SIP命令(方法)4.5.2SIP的請求和響應代碼類型說明100~199信息告訴接收者相關請求已經收到，但處理結果還不知道，如100表示試試看，180表示響鈴200~299成功請求或接收成功，如200表示OK,202表示接收到300~399重定位表示用戶所在地已經變動，如302表示臨時移動400~499客戶端有錯請求有錯，如404表示沒有找到,480表示暫時不能響應，486表示忙500~599服務器有錯服務器故障，如501不執行600~699不成功請求不能完成，如603表示拒絕表4-5SIP響應4.5.3SIP服務器圖4-9使用梯形排列的SIP會話4.5.3SIP服務器A發出INVITE(邀請)由于A不知道B在網上的位置，于是就將邀請發送給代理服務器1代理服務器1也不知道B的具體位置，于是告訴用戶A試試看的同時，通過DNS服務器查找用戶B查找的結果是B不在本地，于是代理服務器1將A的邀請發送給代理服務器2代理服務器2找到了B，把A的邀請轉發給B余下的過程與前一節介紹的過程類似4.5.3SIP服務器在互聯網上建立多媒體會話需要多種服務器才能完成例如，大多數情況下，會話邀請人不知道被叫方的IP地址，但往往知道對方的電子郵件地址，在這種情況下就需要使用附加服務器來完成地址轉換服務器是軟件，不同的服務器可以位于同一臺機器上4.5.3SIP服務器(1)SIP代理服務器(SIPProxyServer)主要解決SIP消息的傳輸路徑，既擔當服務器的角色又擔當客戶器的角色。它接收SIP消息，在需要時將SIP消息轉發到另一個SIP代理服務器其他功能：可包括稱為AAA的認證(authentication)、授權(authorization)和計費(accounting)處理的SIP請求可能是域內的，也可能是通過地址變換等處理后轉發到域外的4.5.3SIP服務器(2)SIP注冊服務器(SIPRegistrar)包含本域中所有用戶代理的位置的數據庫。它接收用戶的注冊請求，并更新數據庫中用戶的位置信息(3)SIP位置服務器(SIPLocationServer)存儲用戶注冊地址的數據庫，提供詳細的用戶地址信息，它的數據庫可能是全局的(4)SIP重定向服務器(SIPRedirectServer)用于為呼叫方返回被叫方的地址。它將請求消息返回給呼叫方，表示需要嘗試不同的路徑才能聯系上被叫方，因為被叫方可能已暫時或永久性地移到其他地方4.5.3SIP服務器圖4-10SIP服務器4.5.4SIP的消息結構SIP消息分成請求和響應消息，這兩類消息的結構類似圖4-12表示請求和響應消息的結構和示例如要深入了解請求和響應中各個域的含義和用法，請閱讀RFC3261(SIP:SessionInitiationProtocol)RFC4566(SDP:SessionDescriptionProtocol)4.5.4SIP的消息結構1.SIPURISIP的實體用統一資源標識符(UniformResourceIdentifier，URI)來標識。形式為“SIP：用戶名@域名”4.5.4SIP的消息結構圖4-11SIP請求格式4.5.4SIP的消息結構(1)起始行：由方法(Method)、請求地址(Request-URI)和SIP版本(SIP-Version)組成本例中的方法為INVITE請求地址為sip:bob@SIP版本為2.04.5.4SIP的消息結構(2)消息頭由下列部分組成：Via：呼叫方期待接收響應的地址(如)，以及標識呼叫的分支參數Max-Forward：本請求到達被叫方所歷經的最大路由段數To：被叫方的名字和SIPURIFrom：呼叫方的名字和SIPURI，以及一個標簽參數。標簽參數是軟電話添加的隨機字符串(如1928301774)，作為對話的標識符4.5.4SIP的消息結構Call-ID：標識這個呼叫的全局唯一標識符，它是由隨機字符串和安裝“軟電話”的主機名或IP地址組合生成的。Call-ID與To域中的標簽(本例未列出)和From域中的標簽相結合可完