第六章 多媒體網路 (Multimedia Networking)

1. 第六章多媒體網路(Multimedia Networking)

2. 簡介 • 隨著網路的快速發展，我們在網路上使用多媒體資料的機會越來越多，同時多媒體網路也漸漸受到重視，所以就有許多因應多媒體網路的協定產生了。

3. 簡介 • 本章節的目的： • 在多媒體網路中的服務所需要的條件 • 在現今best-effort的網路如何達到最佳的效果 • 瞭解現在有哪一些協定是使用在多媒體網路中的 • 例如： • RTSP • RTP • H.323 • SIP

4. 本章節所要介紹的是： • 多媒體網路中的應用程式 • streaming stored audio and video • RTSP • interactive real-time apps • Internet phone example • RTP • H.323 and SIP • beyond best effort • scheduling and policing • integrated services（Insserv） • differentiated services（Disserv）

5. 網路中的多媒體 • 在網路中的多媒體有以下幾個特徵： • 對於延遲（delay）較敏感 • 可以容忍資料遺失（loss tolerant） • 資料具有連續性（continuous data）

6. 網路中的多媒體（2） • 多媒體應用程式的分類 • 串流儲存式（streaming stored）的audio和video • 先從網路下載多媒體檔案，再播放 • 串流即時式（streaming live）的audio和video • 直接透過網路播放多媒體檔案 • 即時交談式（real-time interactive）video • 可依照我們的需求播放多媒體檔案

7. 網路中的多媒體（3） • 串流儲存式（streaming stored）的audio和video • 由使用者端去要求播放事先儲存在伺服器端的多媒體檔案並透過網路傳送 • 使用者可控制多媒體檔案的播放 • 延遲：從使用者要求到播放開始的時間大約會有1秒到10秒之間

8. 網路中的多媒體（4） • 單向即時（unidirectional real-time）模式 • 因為real-time所以直接由網路傳送播放 • 也因為是即時播放，所以使用者不能控制多媒體播放，只能聽和看 • 例如：線上TV，線上廣播

9. 網路中的多媒體（5） • 交談式即時（Interactive real-time）模式 • 因為real-time所以直接由網路傳送播放 • 但是因為為交談式所以所傳送的資料並不像單向模式那麼簡單，所以所造成的延遲會增加 • Video：< 150 msec可接受範圍 • Audio：< 150 msec為良好，<400可接受範圍 • Jitter • 在同一個多媒體串流中的封包的延遲變化程度

10. 網路中的多媒體（6） • 在我們現在所使用的Internet是使用best effort傳送，所以對於傳送多媒體資料會有很大的影響，例如：沒有辦法對於delay或是delay variation提供保證 • 目前往處理封包大都是： • 每一個封包的地位平等 • FIFO • 所以我們必須將所要處理的封包做分類

11. 如何應用現在的網路傳送多媒體 • 使用UDP來傳送 • 在接收端使用暫存器和控制播放的速度已減少jitter • 將封包加上時間標籤以利播放 • 將不重要的封包丟掉

12. 如何使現在的網路更適合傳送多媒體 • 我們必須改變網路所使用的協定可以讓我們所使用的應用程式可以預先保留端對端的頻寬 • 所使用的協定必須要可以保留頻寬 • 例如：RSVP • 必須改變router上scheduling policies來實現保留頻寬 • 我們必須需要更複雜的軟體來實現在使用者和router上面

13. Streaming Stored & Audio & Video • Streaming stored media • Audio和vedio檔案儲存在伺服器裡 • 由使用者發出要求存取 • Audio和vedio檔案會在請求後10秒後送出 • 與伺服器端的交談行為是允許的 • 這裡指的是我們可以將多媒體檔案依照我們需求作動作（暫停、倒轉、前進）

14. Streaming Stored & Audio & Video • Media player • 移除jitter • 解壓縮多媒體檔案 • 錯誤更正 • 圖形化介面讓我們更好控制多媒體播放 • 可以讓我們將播放程式嵌入到瀏覽器中 • 例如：Microsoft media player、Quick time、Real time player…

15. 網頁伺服器的多媒體串流（1） • 瀏覽器透過HTTP要求多媒體資料 • 伺服器透過HTTP回應瀏覽器 • 瀏覽器會去呼叫media player來播放多媒體資料 • 缺點： • Media player必須透過瀏覽器和伺服器溝通

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

17. 多媒體串流伺服器 • 透過網頁伺服器達成多媒體需求的溝通 • Media player再與多媒體串流伺服器利用UDP溝通，取代了TCP的使用

18. 即時串流協定（Real Time Streaming Protocol: RTSP） • RFC：2326 • 用戶端與伺服器模式的應用層協定 • 提供使用者一些控制多媒體功能，例如：快轉、倒轉、暫停等… • 使用HTTP協定傳送多媒體資料，但是HTTP本身無法儲存連續性的多媒體資料

19. 即時串流協定（Real Time Streaming Protocol: RTSP）（續） • RTSP的缺點 • 無法定義要如何對多媒體資料加封 • 無法限制多媒體資料透過什麼協定傳送 • 無法定義media player如何暫存資料 • 現實網路當中我們大多使用RTSP來當作傳送控制訊號（control message）的協定

20. out of band control • RTSP的控制信息和多媒體資料使用不同的port號，所以我們稱為out-of-band • 多媒體資料的資料結構並不是定義在RTSP，所以我們認為是in-band • 如果RTSP的信息和傳送多媒體資料的port有重複的話，我們稱為interleaved

21. RTSP的運作程序

22. Meta file的範例 <title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>

23. RTSP session • 每一個RTSP都有一個session的識別號，每一個識別號由伺服器選定 • 用戶端使用SETUP發出請求，然後伺服器會回應一個識別號給用戶端 • 用戶端會一直使用這一個識別號直到這一個session結束為止

24. RTSP交換訊息範例 C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK

25. Real-time interactive applications • 我們大多所使用的交談式應用有： • PC對PC的電話 • PC對家用電話 • Dialpad • Net2phone • 視訊會議 • Web cams • 接著我們將詳細介紹PC對PC的網路電話

26. Internet phone over best-effort (1) • 之前提過在現今網路會有packet delay、loss 和jitter • Internet phone的例子 • 在通話時才會產生封包 • Bit rate為64kbps • 通話時每20 msec會產生160 bytes的chunk • Chunk＋header加封後利用UDP傳送 • 因為有可能資料流失，所以接收端必須有判斷的機制

27. Internet phone (2) • Packet loss • 使用UDP加封封包 • Datagram可能會超出router queue • 的TCP可以減少loss但是會增加delay • 端對端的延遲 • 端對端的延遲在400 msec以內我們可以接受 • Delay jitter • 必須要在20 msec內 • 移除jitter的方法 • sequence numbers • timestamps • delaying playout

28. Internet phone (3): fixed playout delay • 這裡是使用固定的delay time q，而每一個trunk會被mark上一個time stamp • 所以再接收端會在time=t+q時播放如果超出這歌時間就會丟棄這個資料 • 所以在這裡不需要sequence number • q在這裡是一個trade off • 較大的q，較少的封包被丟棄 • 較小的q，有較好的交談性

29. Internet phone (4): fixed playout delay • First playout schedule: begins at p • Second playout schedule: begins at p’

30. Recovery from packet loss (1) • Loss：是因為資料遺失或是超過播放的時間限制 • forward error correction (FEC) • 每n個chunk為一個group，並加入一個額外的XOR chunk • 所以總共會送出n+1個trunk，並會增加頻寬的1/n • 可以從n+1 chunks中更正一個chunk • 接收所有chunks的延遲必須要固定 • Trade off • n增加，頻寬、loss rate和播放延遲亦會增加

31. Recovery from packet loss (2) • 2nd FEC scheme • 下一個封包會夾帶一個跟前一個一樣但quality較差的封包，萬一前一個封包掉了，後一個可以補回來

32. Recovery from packet loss (3) • Interleaving • 將一個封包在細分成數個小單位，然後前後交叉傳送以降低loss的機會

33. Real-Time Protocol (RTP) • RFC：1889 • 和前面的RTSP所不同的是RTP為了封包攜帶audio和video有定義封包的結構 • RTP封包提供了 • 封包攜帶的資料格式識別 • 封包序號編號 • 時間標記 • RTP通常在終端系統使用 • RTP使用UDP來加封封包

34. RTP runs on top of UDP • RTP和UDP共同組成了傳送層 • 應用成的程式透過RTP和UDP溝通 • 因為RTP是為了額外提供： • 埠號，IP位址 • 錯誤更正 • 資料格式識別 • 封包序號編號 • 時間標記

35. RTP and QoS • RTP並沒有提供適時的資料傳送和任何麼品質服務保證 • RTP對於封包的加封只會在終端系統看的出來 • 因為如此在傳統的routing機制中沒有辦法對於RTP所傳送的封包最任何特別的服務 • 所以為了提供應用程式有品質服務保證，在網路之中必須使用類似RSVP這樣可以預先保留頻寬的機制來提供所需要的品質保證

36. RTP Header • Payload Type (7 bits)：提供了128種可能的encoding的方法 • Payload type 0: PCM mu-law, 64 Kbps • Payload type 3, GSM, 13 Kbps • Payload type 7, LPC, 2.4 Kbps • Payload type 26, Motion JPEG • Payload type 31. H.261 • Payload type 33, MPEG2 video • Sequence Number (16 bits)：用來偵測封包的遺失LOSS

37. RTP Header • Timestamp field (32 bytes)：用來反映出第一個資料封包的採樣和用來移除jitter • Synchronization Source identifier (SSRC)： 32 bits，當作是一個資料源頭的識別號，這一個識別好是亂數決定的

38. Real-Time Control Protocol (RTCP) • 和RTP會同時發生作用 • 每一個RTP的session會用RTCP溝通，讓應用程式獲得有用的資訊 • 並且會統計有多少個封包被傳送、多少封包遺失、jitter變化 • 有了這一些資訊應用程式可以用來調整效能 • 例如：loss rate增大時…

39. RTCP - Continued • 每一個RTP session都會有一個multicast address，而所有屬於這一個session的RTP和RTCP都會使用這一個address • RTP和RTCP的封包是由不同的埠號來區分 • RTCP會有三種report packets • Receiver report packets • Sender report packets • Source description packets

40. RTCP--report packets • Receiver report packets • 紀錄封包遺失的片段、遺失的sequence number、平均的inter-arrival jitter • Sender report packets • RTP串流的SSRC、現在的時間、現在所傳送的封包個數和現在所傳送的byte數 • Source description packets • 傳送者的e-mail、傳送者的名字、RTP串流所相關的SSRC，這一個封包提供了SSRC和使用者（機器）之間的對應

41. 串流的同步 • RTCP可以用來同步在同一個RTP session裡的多媒體串流 • 例如：視訊會議裡包含影像和聲音 • 在RTP封包裡的時間標記是依附video或audio的取樣率決定的，而不是real-time的 • 接收端會使用sender report packet的資訊來做同步

42. RTCP Bandwidth Scaling • RTCP約佔整個session的頻寬的5% • 例如：傳送的速率為2Mbps，則RTCP約為100kbps • 如果每一個接收端都傳送RTCP給所有其他的接收端，這樣RTCP的traffic會很大 • RTCP佔的100kbps會在分為接收端75kbps（75%）和傳送端的25kbps（25%）

43. H.323 • H.323亦是為了在網路上傳送多媒體資料所產生的一個協定，較有名的應用程式為：Microsoft Net meeting • 接著我們將簡單介紹H.323這一個協定 • Overview • H.323 terminal • H. 323 encoding • Gatekeeper • Gateway • Audio codecs • Video codecs

44. Overview (1) • 目標：可以達到即時的通訊 • 由ITU所建議使用 • 應用的範圍 • 單獨的機器（例如：網路電話） • 在PC上的應用 • 點對點或是多點的視訊會議

45. Overview (2) • 在H.323裡面定義了 • 端點的機器如何撥接一個呼叫（call） • 端點的機器如何交換共同的audio/video解碼 • Audio和video如何加封來透過網路傳送 • Audio和video如何同步 • 端點的機器如何和他的gatekeeper溝通 • 網路電話和一般PSTN/ISDN的電話如何溝通

46. Overview (3) • Telephone calls • Video calls • Conferences • Whiteboards • 所有的機器必須支援H.323

47. Overview (4) H.323 SS7, Inband

48. H.323的端點機器必須支援 • G.711 • ITU 所制訂的語音壓縮標準 • RTP • 將多媒體加封的協定 • H.245 • 在端點機器之間用來傳送控制訊號的“Out-of-band” 控制協定 • Q.931 • 用來建立撥接的signaling協定 • RAS (Registration/Admission/Status) 通道協定 – • 用來和gatekeeper溝通的協定

49. H.323 Terminal

50. H.323的編碼（encoding） • Audio • H.323的終端機器必須支援G.711，用來傳送壓縮的與語音，voice rate = 56/64 kbps • Optional：G.722, G.728, G.729 • Video • 對於H.323的終端機器是optional • 終端機器必須支援QCIF H.261 (176x144 像素) • H.261 option：CIF, 4CIF, 16CIF • H.261是用來和使用多重64kbps的頻道溝通