《多媒体网路ppt课件》由会员分享，可在线阅读，更多相关《多媒体网路ppt课件（109页珍藏版）》请在金锄头文库上搜索。
1、第六章多媒體網路(Multimedia Networking)簡介n隨著網路的快速發展，我們在網路上运用多媒體資料的機會越來越多，同時多媒體網路也漸漸遭到重視，所以就有許多因應多媒體網路的協定產生了。簡介n本章節的目的：n在多媒體網路中的服務所需求的條件n在現今best-effort的網路如何達到最正确的效果n瞭解現在有哪一些協定是运用在多媒體網路中的n例如：nRTSPnRTPnH.323nSIPn本章節所要介紹的是：n多媒體網路中的應用程式nstreaming stored audio and videonRTSPninteractive real-time appsnInternet ph
2、one examplenRTPnH.323 and SIPnbeyond best effortnscheduling and policingnintegrated servicesInsservndifferentiated servicesDisserv網路中的多媒體n在網路中的多媒體有以下幾個特徵：n對於延遲delay較敏感n可以容忍資料遺失loss tolerantn資料具有連續性continuous data網路中的多媒體2n多媒體應用程式的分類n串流儲存式streaming stored的audio和videon先從網路下載多媒體檔案，再播放n串流即時式streaming liv
3、e的audio和videon直接透過網路播放多媒體檔案n即時交談式real-time interactivevideon可按照我們的需求播放多媒體檔案網路中的多媒體3n串流儲存式streaming stored的audio和videon由运用者端去要求播放事先儲存在伺服器端的多媒體檔案並透過網路傳送n运用者可控制多媒體檔案的播放n延遲：從运用者要求到播放開始的時間大約會有1秒到10秒之間網路中的多媒體4n單向即時unidirectional real-time方式n因為real-time所以直接由網路傳送播放n也因為是即時播放，所以运用者不能控制多媒體播放，只能聽和看n例如：線上TV，線上廣播
4、網路中的多媒體5n交談式即時Interactive real-time方式n因為real-time所以直接由網路傳送播放n但是因為為交談式所以所傳送的資料並不像單向方式那麼簡單，所以所呵斥的延遲會添加nVideo： 150 msec可接受範圍nAudio： 150 msec為良好，400可接受範圍nJittern在同一個多媒體串流中的封包的延遲變化程度網路中的多媒體6n在我們現在所运用的Internet是运用best effort傳送，所以對於傳送多媒體資料會有很大的影響，例如：沒有辦法對於delay或是delay variation提供保證n目前往處理封包大都是：n每一個封包的位置平等nFI
5、FOn所以我們必須將所要處理的封包做分類如何應用現在的網路傳送多媒體n运用UDP來傳送n在接纳端运用暫存器和控制播放的速度已減少jittern將封包加上時間標籤以利播放n將不重要的封包丟掉如何使現在的網路更適合傳送多媒體n我們必須改變網路所运用的協定可以讓我們所运用的應用程式可以預先保管端對端的頻寬n所运用的協定必須要可以保管頻寬n例如：RSVPn必須改變router上scheduling policies來實現保管頻寬n我們必須需求更複雜的軟體來實現在运用者和router上面Streaming Stored & Audio & VideonStreaming stored medianAud
6、io和vedio檔案儲存在伺服器裡n由运用者發出要求存取nAudio和vedio檔案會在請求後10秒後送出n與伺服器端的交談行為是允許的n這裡指的是我們可以將多媒體檔案按照我們需求作動作暫停、倒轉、前進Streaming Stored & Audio & VideonMedia playern移除jittern解壓縮多媒體檔案n錯誤更正n圖形化介面讓我們更好控制多媒體播放n可以讓我們將播放程式嵌入到瀏覽器中n例如：Microsoft media player、Quick time、Real time player網頁伺服器的多媒體串流1n瀏覽器透過HTTP要求多媒體資料n伺服器透過HTTP回應
7、瀏覽器n瀏覽器會去呼叫media player來播放多媒體資料n缺點：nMedia player必須透過瀏覽器和伺服器溝通網頁伺服器的多媒體串流2n瀏覽器和伺服器一樣透過HTTP溝通n瀏覽器只會收到meta file，並且呼叫media playernMedia player會透過TCP和伺服器建立連線，並运用HTTP交換訊息且開始播放檔案n缺點：n雖然不需透過瀏覽器接纳多媒體資料，但是透過HTTP不能讓我們运用快轉、倒轉、暫停等功能n也許我們可以試試运用UDP來傳送多媒體串流伺服器n透過網頁伺服器達成多媒體需求的溝通nMedia player再與多媒體串流伺服器利用UDP溝通，取代了TCP的
8、运用即時串流協定Real Time Streaming Protocol: RTSPnRFC：2326n用戶端與伺服器方式的應用層協定n提供运用者一些控制多媒體功能，例如：快轉、倒轉、暫停等n运用HTTP協定傳送多媒體資料，但是HTTP本身無法儲存連續性的多媒體資料即時串流協定Real Time Streaming Protocol: RTSP續nRTSP的缺點n無法定義要如何對多媒體資料加封n無法限制多媒體資料透過什麼協定傳送n無法定義media player如何暫存資料n現實網路當中我們大多运用RTSP來當作傳送控制訊號control message的協定out of band contr
9、olnRTSP的控制信息和多媒體資料运用不同的port號，所以我們稱為out-of-bandn多媒體資料的資料結構並不是定義在RTSP，所以我們認為是in-bandn假设RTSP的信息和傳送多媒體資料的port有重複的話，我們稱為interleavedRTSP的運作程序Meta file的範例Twister RTSP sessionn每一個RTSP都有一個session的識別號，每一個識別號由伺服器選定n用戶端运用SETUP發出請求，然後伺服器會回應一個識別號給用戶端n用戶端會不断运用這一個識別號直到這一個session結束為止RTSP交換訊息範例 C: SETUP rtspaudio.exa
10、mple/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtspaudio.example/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtspaudio.example/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN r
11、tspaudio.example/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OKReal-time interactive applicationsn我們大多所运用的交談式應用有：nPC對PC的電話nPC對家用電話nDialpadnNet2phonen視訊會議nWeb camsn接著我們將詳細介紹PC對PC的網路電話Internet phone over best-effort (1)n之前提過在現今網路會有packet delay、loss 和 jitternInternet phone的例子n在通話時才會產生封包nBit r
12、ate為64kbpsn通話時每20 msec會產生160 bytes的chunknChunkheader加封後利用UDP傳送n因為有能够資料流失，所以接纳端必須有判斷的機制Internet phone (2)nPacket lossn运用UDP加封封包nDatagram能够會超出router queuen的TCP可以減少loss但是會添加delayn端對端的延遲n端對端的延遲在400 msec以內我們可以接受nDelay jittern必須要在20 msec內n移除jitter的方法nsequence numbersntimestampsndelaying playoutInternet ph
13、one (3): fixed playout delayn這裡是运用固定的delay time q，而每一個trunk會被mark上一個time stampn所以再接纳端會在time=t+q時播放假设超出這歌時間就會丟棄這個資料n所以在這裡不需求sequence numbernq在這裡是一個trade offn較大的q，較少的封包被丟棄n較小的q，有較好的交談性Internet phone (4): fixed playout delaynFirst playout schedule: begins at pn Second playout schedule: begins at pRecov
14、ery from packet loss (1)nLoss：是因為資料遺失或是超過播放的時間限制nforward error correction (FEC)n每n個chunk為一個group，並参与一個額外的XOR chunkn所以總共會送出n+1個trunk，並會添加頻寬的1/nn可以從n+1 chunks中更正一個chunkn接纳一切chunks的延遲必須要固定nTrade offnn添加，頻寬、loss rate和播放延遲亦會添加Recovery from packet loss (2)n2nd FEC schemen下一個封包會夾帶一個跟前一個一樣但quality較差的封包，萬一前一
15、個封包掉了，後一個可以補回來Recovery from packet loss (3)nInterleavingn將一個封包在細分成數個小單位，然後前後交叉傳送以降低loss的機會Real-Time Protocol (RTP)nRFC：1889n和前面的RTSP所不同的是RTP為了封包攜帶audio和video有定義封包的結構nRTP封包提供了n封包攜帶的資料格式識別n封包序號編號n時間標記nRTP通常在終端系統运用nRTP运用UDP來加封封包RTP runs on top of UDPnRTP和UDP共同組成了傳送層n應用成的程式透過RTP和UDP溝通n因為RTP是為了額外提供：n埠號，I
16、P位址n錯誤更正n資料格式識別n封包序號編號n時間標記RTP and QoSnRTP並沒有提供適時的資料傳送和任何麼品質服務保證nRTP對於封包的加封只會在終端系統看的出來n因為如此在傳統的routing機制中沒有辦法對於RTP所傳送的封包最任何特別的服務n所以為了提供應用程式有品質服務保證，在網路之中必須运用類似RSVP這樣可以預先保管頻寬的機制來提供所需求的品質保證RTP HeadernPayload Type (7 bits)：提供了128種能够的encoding的方法nPayload type 0: PCM mu-law, 64 KbpsnPayload type 3, GSM, 13
17、 KbpsnPayload type 7, LPC, 2.4 KbpsnPayload type 26, Motion JPEGnPayload type 31. H.261nPayload type 33, MPEG2 videonSequence Number (16 bits)：用來偵測封包的遺失LOSSRTP HeadernTimestamp field (32 bytes)：用來反映出第一個資料封包的採樣和用來移除jitternSynchronization Source identifier (SSRC)： 32 bits，當作是一個資料源頭的識別號，這一個識別好是亂數決定的Rea
18、l-Time Control Protocol (RTCP)n和RTP會同時發生作用n每一個RTP的session會用RTCP溝通，讓應用程式獲得有用的資訊n並且會統計有多少個封包被傳送、多少封包遺失、jitter變化n有了這一些資訊應用程式可以用來調整效能n例如：loss rate增大時RTCP - Continuedn每一個RTP session都會有一個multicast address，而一切屬於這一個session的RTP和RTCP都會运用這一個addressnRTP和RTCP的封包是由不同的埠號來區分nRTCP會有三種report packetsnReceiver report p
19、acketsnSender report packetsnSource description packetsRTCP-report packetsnReceiver report packetsn紀錄封包遺失的片段、遺失的sequence number、平均的inter-arrival jitternSender report packetsnRTP串流的SSRC、現在的時間、現在所傳送的封包個數和現在所傳送的byte數nSource description packetsn傳送者的、傳送者的名字、RTP串流所相關的SSRC，這一個封包提供了SSRC和运用者機器之間的對應串流的同步nRTCP
20、可以用來同步在同一個RTP session裡的多媒體串流n例如：視訊會議裡包含影像和聲音n在RTP封包裡的時間標記是依靠video或audio的取樣率決定的，而不是real-time的n接纳端會运用sender report packet的資訊來做同步RTCP Bandwidth ScalingnRTCP約佔整個session的頻寬的5%n例如：傳送的速率為2Mbps，則RTCP約為100kbpsn假设每一個接纳端都傳送RTCP給一切其他的接纳端，這樣RTCP的traffic會很大nRTCP佔的100kbps會在分為接纳端75kbps75%和傳送端的25kbps25%H.323nH.323亦是
21、為了在網路上傳送多媒體資料所產生的一個協定，較有名的應用程式為：Microsoft Net meetingn接著我們將簡單介紹H.323這一個協定nOverviewnH.323 terminalnH. 323 encodingnGatekeepernGatewaynAudio codecsnVideo codecsOverview (1)n目標：可以達到即時的通訊n由ITU所建議运用n應用的範圍n單獨的機器例如：網路電話n在PC上的應用n點對點或是多點的視訊會議Overview (2)n在H.323裡面定義了n端點的機器如何撥接一個呼叫calln端點的機器如何交換共同的audio/video解
22、碼nAudio和video如何加封來透過網路傳送nAudio和video如何同步n端點的機器如何和他的gatekeeper溝通n網路電話和普通PSTN/ISDN的電話如何溝通Overview (3)nTelephone callsnVideo callsnConferencesnWhiteboardsn一切的機器必須援助H.323Overview (4)H.323SS7, InbandH.323的端點機器必須援助nG.711 nITU 所制訂的語音壓縮標準所制訂的語音壓縮標準nRTP n將多媒體加封的協定將多媒體加封的協定nH.245 n在端點機器之間用來傳送控制訊號的在端點機器之間用來傳送控
23、制訊號的“Out-of-band 控制協定控制協定nQ.931 n用來建立撥接的用來建立撥接的signaling協定協定nRAS (Registration/Admission/Status) 通道協定通道協定 n用來和用來和gatekeeper溝通的協定溝通的協定H.323 TerminalH.323的編碼encodingnAudionH.323的終端機器必須援助G.711，用來傳送壓縮的與語音，voice rate = 56/64 kbpsnOptional：G.722, G.728, G.729nVideon對於H.323的終端機器是optionaln終端機器必須援助QCIF H.261
24、 (176x144 像素)nH.261 option：CIF, 4CIF, 16CIFnH.261是用來和运用多重64kbps的頻道溝通Generating audio packet stream in H.323AudioSourceEncoding:e.g., G.711 or G.723.1RTP packetencapsulationUDP socketInternet orGatekeeperH.245 Control Channeln一個H.323串流能够會包含多個不同種類的多媒體資料n每一個H.323 session都會有一個H.245的控制頻道nH.245控制頻道是一個reli
25、ableTCP的控制頻道n主要任務n開啟或關閉一個多媒體頻道n相容性的交換n在開始傳送資料前，會先交換編碼的演算法Information flowsGatekeeper1n在這裡gatekeeper是optional，提供n位址轉換成IP位址n頻寬的管理n因為billing的方便，H.323的calls能够會由gatekeeper管理nRAS是用來terminal-gatekeeper之間溝通的協定H.323 terminalsGatekeeperRouterInternetLAN = “ZoneRASGatekeeper2nH.323的設備必須要跟他那個區域的gatekeeper做註冊的動作
26、n假设gatekeeper存在的話，每一個終端設備要撥接一個call的前要先經過gatekeeper赞同n假设獲得赞同，終端設備會傳送給gatekeeper，裡面包含了要轉換成IP位址的資訊GatewaynIP區域和PSTNor ISDN的橋樑n終端設備运用H.245和Q.931和gateway溝通H.323 terminalsGatekeeperRouterInternetLAN = “ZoneRASGatewayPSTNAudio codecsMOS (Mean Opinion Score)Video codecsnH.261 (p x 64 kbit/s)nISDN上傳送VideonRe
27、solutions : QCIF, CIFnH.263 (y.Assured Forwarding PHB Group (cont.)nDescription:nA packet with drop precedence p must be forwarded with higher probability than a packet with drop precedence q, if pq.nAn IP packet that belongs to an AF class i and has drop precedence j within is marked with the AFij.
28、nA DS node must allocate a configurable, minimum amount of forwarding resources to each implemented AF class.nAn 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
29、rding PHB Group (cont.)nAF PHB recommend codepoint:010000010010010100011000100000101000011010011100100100100010101100101010AF1AF2AF3AF4lowmidhighExpedited Forwarding PHB nReference:nIETF RFC 2598.nDescription:nThe EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, en
30、d-to-end service through DS domains.nThe departure rate of the aggregates packets from DS nodes must equal or exceed a configurable rate.nThe 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 unusedqEF PHB recommend codepoint:q101110
