《第六章多媒体网路(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