《第六章多媒体网路(Multimedia Networking)》由会员分享，可在线阅读，更多相关《第六章多媒体网路(Multimedia Networking)（109页珍藏版）》请在金锄头文库上搜索。
1、第六章 多媒體網路(Multimedia Networking)簡介n隨著網路的快速發展，我們在網路上使用多 媒體資料的機會越來越多，同時多媒體網路 也漸漸受到重視，所以就有許多因應多媒體 網路的協定產生了。簡介n本章節的目的：q在多媒體網路中的服務所需要的條件q在現今best-effort的網路如何達到最佳的效果q瞭解現在有哪一些協定是使用在多媒體網路中 的n例如：qRTSPqRTPqH.323qSIPn本章節所要介紹的是：q多媒體網路中的應用程式qstreaming stored audio and videonRTSPqinteractive real-time appsnInterne
2、t phone 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先從網路下載多媒體檔案，再播放
3、q串流即時式（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：Twister RTSP sessionn每一個RTSP都有一個session的識別號，每 一個識別號由伺服器選定n用戶端使用SETUP發出請求，然後伺服器會 回應一個識別號給用戶端n用戶端會一直使用這一個識別號直到這一個 session結束為止RTSP交換訊息範例C: SETUP rtsp:/ RTSP
5、/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp:/ RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp:/ RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp:/ RTSP/1.0 Session: 4231 S: 200 3 OKReal-time interactive applicationsn我們大多所使用的交談式應用有
6、：qPC對PC的電話qPC對家用電話nDialpadnNet2phoneq視訊會議qWeb camsn接著我們將詳細介紹PC對PC的網路電話Internet phone 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使用UD
7、P加封封包qDatagram可能會超出router queueq的TCP可以減少loss但是會增加delayn端對端的延遲q端對端的延遲在400 msec以內我們可以接受nDelay jitterq必須要在20 msec內n移除jitter的方法qsequence numbersqtimestampsqdelaying playoutInternet phone (3): fixed playout delayn這裡是使用固定的delay time q，而每一個 trunk會被mark上一個time stampn所以再接收端會在time=t+q時播放如果超出 這歌時間就會丟棄這個資料n所以在這
8、裡不需要sequence numbernq在這裡是一個trade offq較大的q，較少的封包被丟棄q較小的q，有較好的交談性Internet phone (4): fixed playout 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所以
9、總共會送出n+1個trunk，並會增加頻寬的 1/nq可以從n+1 chunks中更正一個chunkq接收所有chunks的延遲必須要固定qTrade offnn增加，頻寬、loss rate和播放延遲亦會增加Recovery from packet loss (2)n2nd FEC schemeq下一個封包會夾帶一個跟前一個一樣但quality較差的封 包，萬一前一個封包掉了，後一個可以補回來Recovery from packet loss (3)nInterleavingq將一個封包在細分成數個小單位，然後前後交叉傳送 以降低loss的機會Real-Time Protocol (RTP)
10、nRFC：1889n和前面的RTSP所不同的是RTP為了封包攜 帶audio和video有定義封包的結構nRTP封包提供了q封包攜帶的資料格式識別q封包序號編號q時間標記nRTP通常在終端系統使用nRTP使用UDP來加封封包RTP runs on top of UDPnRTP和UDP共同組成了傳送層n應用成的程式透過RTP和UDP溝通n因為RTP是為了額外提供：q埠號，IP位址q錯誤更正q資料格式識別q封包序號編號q時間標記RTP and QoSnRTP並沒有提供適時的資料傳送和任何麼品 質服務保證nRTP對於封包的加封只會在終端系統看的出 來q因為如此在傳統的routing機制中沒有辦法對於
11、 RTP所傳送的封包最任何特別的服務n所以為了提供應用程式有品質服務保證，在 網路之中必須使用類似RSVP這樣可以預先 保留頻寬的機制來提供所需要的品質保證RTP HeadernPayload Type (7 bits)：提供了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, MP
12、EG2 videonSequence Number (16 bits)：用來偵測封包的遺失 LOSSRTP HeadernTimestamp field (32 bytes)：用來反映出第一個資 料封包的採樣和用來移除jitternSynchronization Source identifier (SSRC)： 32 bits ，當作是一個資料源頭的識別號，這一個識別好是 亂數決定的Real-Time Control Protocol (RTCP)n和RTP會同時發生作用n每一個RTP的session會用RTCP溝通，讓應 用程式獲得有用的資訊n並且會統計有多少個封包被傳送、多少封包 遺失、
13、jitter變化n有了這一些資訊應用程式可以用來調整效能q例如：loss rate增大時RTCP - Continuedn每一個RTP session都會有 一個multicast address，而 所有屬於這一個session的 RTP和RTCP都會使用這一 個addressnRTP和RTCP的封包是由不 同的埠號來區分nRTCP會有三種report packetsqReceiver report packetsqSender report packetsqSource description packetsRTCP-report packetsnReceiver report packe
14、tsq紀錄封包遺失的片段、遺失的sequence number、平均的inter-arrival jitternSender report packetsqRTP串流的SSRC、現在的時間、現在所傳送 的封包個數和現在所傳送的byte數nSource description packetsq傳送者的e-mail、傳送者的名字、RTP串流所相 關的SSRC，這一個封包提供了SSRC和使用者（ 機器）之間的對應串流的同步nRTCP可以用來同步在同一個RTP session裡 的多媒體串流q例如：視訊會議裡包含影像和聲音n在RTP封包裡的時間標記是依附video或 audio的取樣率決定的，而不是r
15、eal-time的n接收端會使用sender report packet的資訊來 做同步RTCP Bandwidth ScalingnRTCP約佔整個session的頻寬的5%q例如：傳送的速率為2Mbps，則RTCP約為 100kbpsq如果每一個接收端都傳送RTCP給所有其他的接 收端，這樣RTCP的traffic會很大qRTCP佔的100kbps會在分為接收端75kbps（ 75%）和傳送端的25kbps（25%）H.323nH.323亦是為了在網路上傳送多媒體資料所產生的 一個協定，較有名的應用程式為：Microsoft Net meetingn接著我們將簡單介紹H.323這一個協定q
16、OverviewqH.323 terminalqH. 323 encodingqGatekeeperqGatewayqAudio codecsqVideo codecsOverview (1)n目標：可以達到即時的通訊n由ITU所建議使用n應用的範圍q單獨的機器（例如：網路電話）q在PC上的應用q點對點或是多點的視訊會議Overview (2)n在H.323裡面定義了q端點的機器如何撥接一個呼叫（call）q端點的機器如何交換共同的audio/video解碼qAudio和video如何加封來透過網路傳送qAudio和video如何同步q端點的機器如何和他的gatekeeper溝通q網路電話和一般PSTN/ISDN的電話如何溝通Overview (3)nTelephone
