《多媒体网路》PPT课件.ppt

《《多媒体网路》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《多媒体网路》PPT课件.ppt（109页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第六章多媒體網路(Multimedia Networking)簡介n隨著網路的快速發展，我們在網路上使用多媒體資料的機會越來越多，同時多媒體網路也漸漸受到重視，所以就有許多因應多媒體網路的協定產生了。簡介n本章節的目的：q在多媒體網路中的服務所需要的條件q在現今best-effort的網路如何達到最佳的效果q瞭解現在有哪一些協定是使用在多媒體網路中的n例如：qRTSPqRTPqH.323qSIPn本章節所要介紹的是：q多媒體網路中的應用程式qstreaming stored audio and videonRTSPqinteractive real-time appsnInternet pho

2、ne exampleqRTPqH.323 and SIPqbeyond best effortnscheduling and policingnintegrated services（Insserv）ndifferentiated services（Disserv）網路中的多媒體n在網路中的多媒體有以下幾個特徵：q對於延遲（delay）較敏感q可以容忍資料遺失（loss tolerant）q資料具有連續性（continuous data）網路中的多媒體（2）n多媒體應用程式的分類q串流儲存式（streaming stored）的audio和videon先從網路下載多媒體檔案，再播放q串流即時式

3、（streaming live）的audio和videon直接透過網路播放多媒體檔案q即時交談式（real-time interactive）videon可依照我們的需求播放多媒體檔案網路中的多媒體（3）n串流儲存式（streaming stored）的audio和videoq由使用者端去要求播放事先儲存在伺服器端的多媒體檔案並透過網路傳送q使用者可控制多媒體檔案的播放q延遲：從使用者要求到播放開始的時間大約會有1秒到10秒之間網路中的多媒體（4）n單向即時（unidirectional real-time）模式q因為real-time所以直接由網路傳送播放q也因為是即時播放，所以使用者不能控

4、制多媒體播放，只能聽和看q例如：線上TV，線上廣播網路中的多媒體（5）n交談式即時（Interactive real-time）模式q因為real-time所以直接由網路傳送播放q但是因為為交談式所以所傳送的資料並不像單向模式那麼簡單，所以所造成的延遲會增加qVideo：150 msec可接受範圍qAudio：150 msec為良好，400可接受範圍nJitterq在同一個多媒體串流中的封包的延遲變化程度網路中的多媒體（6）n在我們現在所使用的Internet是使用best effort傳送，所以對於傳送多媒體資料會有很大的影響，例如：沒有辦法對於delay或是delay variation提

5、供保證n目前往處理封包大都是：q每一個封包的地位平等qFIFOn所以我們必須將所要處理的封包做分類如何應用現在的網路傳送多媒體n使用UDP來傳送n在接收端使用暫存器和控制播放的速度已減少jittern將封包加上時間標籤以利播放n將不重要的封包丟掉如何使現在的網路更適合傳送多媒體n我們必須改變網路所使用的協定可以讓我們所使用的應用程式可以預先保留端對端的頻寬q所使用的協定必須要可以保留頻寬n例如：RSVPq必須改變router上scheduling policies來實現保留頻寬n我們必須需要更複雜的軟體來實現在使用者和router上面Streaming Stored&Audio&VideonS

6、treaming stored mediaqAudio和vedio檔案儲存在伺服器裡q由使用者發出要求存取qAudio和vedio檔案會在請求後10秒後送出q與伺服器端的交談行為是允許的n這裡指的是我們可以將多媒體檔案依照我們需求作動作（暫停、倒轉、前進）Streaming Stored&Audio&VideonMedia playerq移除jitterq解壓縮多媒體檔案q錯誤更正q圖形化介面讓我們更好控制多媒體播放q可以讓我們將播放程式嵌入到瀏覽器中q例如：Microsoft media player、Quick time、Real time player網頁伺服器的多媒體串流（1）n瀏覽器

7、透過HTTP要求多媒體資料n伺服器透過HTTP回應瀏覽器n瀏覽器會去呼叫media player來播放多媒體資料n缺點：qMedia player必須透過瀏覽器和伺服器溝通網頁伺服器的多媒體串流（2）n瀏覽器和伺服器一樣透過HTTP溝通n瀏覽器只會收到meta file，並且呼叫media playernMedia player會透過TCP和伺服器建立連線，並使用HTTP交換訊息且開始播放檔案n缺點：q雖然不需透過瀏覽器接收多媒體資料，但是透過HTTP不能讓我們使用快轉、倒轉、暫停等功能q也許我們可以試試使用UDP來傳送多媒體串流伺服器n透過網頁伺服器達成多媒體需求的溝通nMedia play

8、er再與多媒體串流伺服器利用UDP溝通，取代了TCP的使用即時串流協定（Real Time Streaming Protocol:RTSP）nRFC：2326q用戶端與伺服器模式的應用層協定q提供使用者一些控制多媒體功能，例如：快轉、倒轉、暫停等q使用HTTP協定傳送多媒體資料，但是HTTP本身無法儲存連續性的多媒體資料即時串流協定（Real Time Streaming Protocol:RTSP）（續）nRTSP的缺點q無法定義要如何對多媒體資料加封q無法限制多媒體資料透過什麼協定傳送q無法定義media player如何暫存資料n現實網路當中我們大多使用RTSP來當作傳送控制訊號（con

9、trol message）的協定out of band controlnRTSP的控制信息和多媒體資料使用不同的port號，所以我們稱為out-of-bandn多媒體資料的資料結構並不是定義在RTSP，所以我們認為是in-bandn如果RTSP的信息和傳送多媒體資料的port有重複的話，我們稱為interleavedRTSP的運作程序Meta file的範例Twister RTSP sessionn每一個RTSP都有一個session的識別號，每一個識別號由伺服器選定n用戶端使用SETUP發出請求，然後伺服器會回應一個識別號給用戶端n用戶端會一直使用這一個識別號直到這一個session結束為止

10、RTSP交換訊息範例 Transport:rtp/udp;compression;port=3056;mode=PLAY S:RTSP/1.0 200 1 OK Session 4231 Session:4231 Range:npt=0-Session:4231 Range:npt=37 Session:4231 S:200 3 OKReal-time interactive applicationsn我們大多所使用的交談式應用有：qPC對PC的電話qPC對家用電話nDialpadnNet2phoneq視訊會議qWeb camsn接著我們將詳細介紹PC對PC的網路電話Internet phon

11、e over best-effort(1)n之前提過在現今網路會有packet delay、loss 和 jitternInternet phone的例子q在通話時才會產生封包qBit rate為64kbpsq通話時每20 msec會產生160 bytes的chunkqChunkheader加封後利用UDP傳送q因為有可能資料流失，所以接收端必須有判斷的機制Internet phone(2)nPacket lossq使用UDP加封封包qDatagram可能會超出router queueq的TCP可以減少loss但是會增加delayn端對端的延遲q端對端的延遲在400 msec以內我們可以接受n

12、Delay jitterq必須要在20 msec內n移除jitter的方法qsequence numbersqtimestampsqdelaying playoutInternet phone(3):fixed playout delayn這裡是使用固定的delay time q，而每一個trunk會被mark上一個time stampn所以再接收端會在time=t+q時播放如果超出這歌時間就會丟棄這個資料n所以在這裡不需要sequence numbernq在這裡是一個trade offq較大的q，較少的封包被丟棄q較小的q，有較好的交談性Internet phone(4):fixed pla

13、yout delaynFirst playout schedule:begins at pn Second playout schedule:begins at pRecovery from packet loss(1)nLoss：是因為資料遺失或是超過播放的時間限制nforward error correction(FEC)q每n個chunk為一個group，並加入一個額外的XOR chunkq所以總共會送出n+1個trunk，並會增加頻寬的1/nq可以從n+1 chunks中更正一個chunkq接收所有chunks的延遲必須要固定qTrade offnn增加，頻寬、loss rate和播放

14、延遲亦會增加Recovery from packet loss(2)n2nd FEC schemeq下一個封包會夾帶一個跟前一個一樣但quality較差的封包，萬一前一個封包掉了，後一個可以補回來Recovery from packet loss(3)nInterleavingq將一個封包在細分成數個小單位，然後前後交叉傳送以降低loss的機會Real-Time Protocol(RTP)nRFC：1889n和前面的RTSP所不同的是RTP為了封包攜帶audio和video有定義封包的結構nRTP封包提供了q封包攜帶的資料格式識別q封包序號編號q時間標記nRTP通常在終端系統使用nRTP使用U

15、DP來加封封包RTP runs on top of UDPnRTP和UDP共同組成了傳送層n應用成的程式透過RTP和UDP溝通n因為RTP是為了額外提供：q埠號，IP位址q錯誤更正q資料格式識別q封包序號編號q時間標記RTP and QoSnRTP並沒有提供適時的資料傳送和任何麼品質服務保證nRTP對於封包的加封只會在終端系統看的出來q因為如此在傳統的routing機制中沒有辦法對於RTP所傳送的封包最任何特別的服務n所以為了提供應用程式有品質服務保證，在網路之中必須使用類似RSVP這樣可以預先保留頻寬的機制來提供所需要的品質保證RTP HeadernPayload Type(7 bits)：

16、提供了128種可能的encoding的方法qPayload type 0:PCM mu-law,64 KbpsqPayload type 3,GSM,13 KbpsqPayload type 7,LPC,2.4 KbpsqPayload type 26,Motion JPEGqPayload type 31.H.261qPayload type 33,MPEG2 videonSequence Number(16 bits)：用來偵測封包的遺失LOSSRTP HeadernTimestamp field(32 bytes)：用來反映出第一個資料封包的採樣和用來移除jitternSynchroni

17、zation Source identifier(SSRC)：32 bits，當作是一個資料源頭的識別號，這一個識別好是亂數決定的Real-Time Control Protocol(RTCP)n和RTP會同時發生作用n每一個RTP的session會用RTCP溝通，讓應用程式獲得有用的資訊n並且會統計有多少個封包被傳送、多少封包遺失、jitter變化n有了這一些資訊應用程式可以用來調整效能q例如：loss rate增大時RTCP-Continuedn每一個RTP session都會有一個multicast address，而所有屬於這一個session的RTP和RTCP都會使用這一個addre

18、ssnRTP和RTCP的封包是由不同的埠號來區分nRTCP會有三種report packetsqReceiver report packetsqSender report packetsqSource description packetsRTCP-report packetsnReceiver report packetsq紀錄封包遺失的片段、遺失的sequence number、平均的inter-arrival jitternSender report packetsqRTP串流的SSRC、現在的時間、現在所傳送的封包個數和現在所傳送的byte數nSource description pa

19、cketsq傳送者的e-mail、傳送者的名字、RTP串流所相關的SSRC，這一個封包提供了SSRC和使用者（機器）之間的對應串流的同步nRTCP可以用來同步在同一個RTP session裡的多媒體串流q例如：視訊會議裡包含影像和聲音n在RTP封包裡的時間標記是依附video或audio的取樣率決定的，而不是real-time的n接收端會使用sender report packet的資訊來做同步RTCP Bandwidth ScalingnRTCP約佔整個session的頻寬的5%q例如：傳送的速率為2Mbps，則RTCP約為100kbpsq如果每一個接收端都傳送RTCP給所有其他的接收端，這

20、樣RTCP的traffic會很大qRTCP佔的100kbps會在分為接收端75kbps（75%）和傳送端的25kbps（25%）H.323nH.323亦是為了在網路上傳送多媒體資料所產生的一個協定，較有名的應用程式為：Microsoft Net meetingn接著我們將簡單介紹H.323這一個協定qOverviewqH.323 terminalqH.323 encodingqGatekeeperqGatewayqAudio codecsqVideo codecsOverview(1)n目標：可以達到即時的通訊n由ITU所建議使用n應用的範圍q單獨的機器（例如：網路電話）q在PC上的應用q點對

21、點或是多點的視訊會議Overview(2)n在H.323裡面定義了q端點的機器如何撥接一個呼叫（call）q端點的機器如何交換共同的audio/video解碼qAudio和video如何加封來透過網路傳送qAudio和video如何同步q端點的機器如何和他的gatekeeper溝通q網路電話和一般PSTN/ISDN的電話如何溝通Overview(3)nTelephone callsnVideo callsnConferencesnWhiteboardsn所有的機器必須支援H.323Overview(4)H.323SS7,InbandH.323的端點機器必須支援nG.711 qITU 所制訂的語

22、音壓縮標準nRTP q將多媒體加封的協定nH.245 q在端點機器之間用來傳送控制訊號的“Out-of-band”控制協定nQ.931 q用來建立撥接的signaling協定nRAS(Registration/Admission/Status)通道協定 q用來和gatekeeper溝通的協定H.323 TerminalH.323的編碼（encoding）nAudioqH.323的終端機器必須支援G.711，用來傳送壓縮的與語音，voice rate=56/64 kbpsqOptional：G.722,G.728,G.729nVideoq對於H.323的終端機器是optionalq終端機器必須支

23、援QCIF H.261(176x144 像素)qH.261 option：CIF,4CIF,16CIFqH.261是用來和使用多重64kbps的頻道溝通Generating audio packet stream in H.323AudioSourceEncoding:e.g.,G.711 RTP packetencapsulationUDP socketInternet orGatekeeperH.245 Control Channeln一個H.323串流可能會包含多個不同種類的多媒體資料n每一個H.323 session都會有一個H.245的控制頻道nH.245控制頻道是一個reliabl

24、e（TCP）的控制頻道n主要任務q開啟或關閉一個多媒體頻道q相容性的交換n在開始傳送資料前，會先交換編碼的演算法Information flowsGatekeeper（1）n在這裡gatekeeper是optional，提供q位址轉換成IP位址q頻寬的管理n因為billing的方便，H.323的calls可能會由gatekeeper管理nRAS是用來terminal-gatekeeper之間溝通的協定H.323 terminalsGatekeeperRouterInternetLAN=“Zone”RASGatekeeper（2）nH.323的設備必須要跟他那個區域的gatekeeper做註冊的

25、動作n如果gatekeeper存在的話，每一個終端設備要撥接一個call的前要先經過gatekeeper同意n如果獲得同意，終端設備會傳送e-mail給gatekeeper，裡面包含了要轉換成IP位址的資訊GatewaynIP區域和PSTN（or ISDN）的橋樑n終端設備使用H.245和Q.931和gateway溝通H.323 terminalsGatekeeperRouterInternetLAN=“Zone”RASGatewayPSTNAudio codecsMOS(Mean Opinion Score)Video codecsnH.261(p x 64 kbit/s)qISDN上傳送V

26、ideoqResolutions:QCIF,CIFnH.263(y.Assured Forwarding PHB Group(cont.)nDescription:qA packet with drop precedence p must be forwarded with higher probability than a packet with drop precedence q,if pq.qAn IP packet that belongs to an AF class i and has drop precedence j within is marked with the AFij

27、.qA DS node must allocate a configurable,minimum amount of forwarding resources to each implemented AF class.qAn AF class may also be configurable to receive more forwarding resources than minimum when excess resources are available either from other AF classes or from other PHB groups.Assured Forwa

28、rding PHB Group(cont.)nAF PHB recommend codepoint:010000010010010100011000100000101000011010011100100100100010101100101010AF1AF2AF3AF4lowmidhighExpedited Forwarding PHB nReference:qIETF RFC 2598.nDescription:qThe EF PHB can be used to build a low loss,low latency,low jitter,assured bandwidth,end-to-

29、end service through DS domains.qThe departure rate of the aggregates packets from DS nodes must equal or exceed a configurable rate.qThe EF traffic receives this rate independent of the intensity of any other traffic attempting to transit the node.Expedited Forwarding PHB(cont.)qDSCP:Diffserv codepointqCU:currently unusednEF PHB recommend codepoint:q101110