多媒體編碼通信17-多媒體的傳輸-2

多媒體編碼與通信

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

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