第12講-多媒體傳輸協(xié)議

1第12講多媒體傳輸協(xié)議要求1.理解網(wǎng)絡(luò)多媒體傳輸?shù)幕締?wèn)題和基本解決方法2.理解流式音頻視頻的基本原理3.理解交互式音頻視頻的基本原理4.了解多媒體傳輸協(xié)議RTSP、RTP和RTCP212.1概述計(jì)算機(jī)網(wǎng)絡(luò)最初是為傳送數(shù)據(jù)信息設(shè)計(jì)的因特網(wǎng)IP層提供的“盡最大努力交付”服務(wù)，以及每一個(gè)分組獨(dú)立交付的策略，對(duì)傳送數(shù)據(jù)信息也是很合適的因特網(wǎng)使用的TCP協(xié)議可以很好地解決網(wǎng)絡(luò)不能提供可靠交付這一問(wèn)題3多媒體信息的特點(diǎn)多媒體信息（包括聲音和圖像信息）與不包括聲音和圖像的數(shù)據(jù)信息有很大的區(qū)別多媒體信息的信息量往往很大在傳輸多媒體數(shù)據(jù)時(shí)，對(duì)時(shí)延和時(shí)延抖動(dòng)均有較高的要求多媒體數(shù)據(jù)往往是實(shí)時(shí)數(shù)據(jù)(realtimedata)，它的含義是：在發(fā)送實(shí)時(shí)數(shù)據(jù)的同時(shí)，在接收端邊接收邊播放4因特網(wǎng)是非等時(shí)的模擬的多媒體信號(hào)經(jīng)過(guò)采樣和模數(shù)轉(zhuǎn)換變?yōu)閿?shù)字信號(hào)，再組裝成分組這些分組的發(fā)送速率是恒定的（等時(shí)的）傳統(tǒng)的因特網(wǎng)本身是非等時(shí)的

因此經(jīng)過(guò)因特網(wǎng)的分組變成了非恒定速率的分組tt因特網(wǎng)t模擬信號(hào)t采樣后的信號(hào)構(gòu)成分組恒定速率非恒定速率5接收端需設(shè)置適當(dāng)大小的緩存

當(dāng)緩存中的分組數(shù)達(dá)到一定的數(shù)量后再以恒定速率按順序把分組讀出進(jìn)行還原播放緩存實(shí)際上就是一個(gè)先進(jìn)先出的隊(duì)列。圖中標(biāo)明的T叫做播放時(shí)延

在接收端設(shè)置緩存tT緩存（隊(duì)列）恒定速率t非恒定速率有可能發(fā)生分組丟失6緩存使所有到達(dá)的分組都經(jīng)受了遲延早到達(dá)的分組在緩存中停留的時(shí)間較長(zhǎng)，而晚到達(dá)的分組在緩存中停留的時(shí)間則較短以非恒定速率到達(dá)的分組，經(jīng)過(guò)緩存后再以恒定速率讀出，就能夠在一定程度上消除了時(shí)延的抖動(dòng)但，付出的代價(jià)是：增加了時(shí)延緩存的影響分組發(fā)出1

2

3

4

5

6t到達(dá)分組數(shù)6543211

2

3

4

5

6t緩存時(shí)間緩存時(shí)間再推遲播放時(shí)間如果網(wǎng)絡(luò)無(wú)時(shí)延推遲播放分組遲到網(wǎng)絡(luò)出現(xiàn)時(shí)延分組1的時(shí)延分組到達(dá)1

2

34

5

6t實(shí)際的網(wǎng)絡(luò)78需要解決的問(wèn)題在傳送時(shí)延敏感(delaysensitive)的實(shí)時(shí)數(shù)據(jù)時(shí)，不僅傳輸時(shí)延不能太大，而且時(shí)延抖動(dòng)也必須受到限制對(duì)于傳送實(shí)時(shí)數(shù)據(jù)，很少量分組的丟失對(duì)播放效果的影響并不大（因?yàn)檫@是由人來(lái)進(jìn)行主觀評(píng)價(jià)的），因而是可以容忍的。丟失容忍(losstolerant)也是實(shí)時(shí)數(shù)據(jù)的另一個(gè)重要特點(diǎn)9需要解決的問(wèn)題由于分組的到達(dá)可能不按序，但將分組還原和播放時(shí)又應(yīng)當(dāng)是按序的因此在發(fā)送多媒體分組時(shí)還應(yīng)當(dāng)給每一個(gè)分組加上序號(hào)。這表明還應(yīng)當(dāng)有相應(yīng)的協(xié)議支持才行要使接收端能夠?qū)⒐?jié)目中本來(lái)就存在的正常的短時(shí)間停頓（如音樂(lè)中停頓幾拍）和因某些分組的較大遲延造成的“停頓”區(qū)分開(kāi)來(lái)這就需要增加一個(gè)時(shí)間戳(timestamp)，以便告訴接收端應(yīng)當(dāng)在什么時(shí)間播放哪個(gè)分組10是否改造現(xiàn)有的因特網(wǎng)？1、大量使用光纜和高速路由器，網(wǎng)絡(luò)的時(shí)延和時(shí)延抖動(dòng)就可以足夠小，在因特網(wǎng)上傳送實(shí)時(shí)數(shù)據(jù)就不會(huì)有問(wèn)題2、把因特網(wǎng)改造為能夠?qū)Χ说蕉说膸拰?shí)現(xiàn)預(yù)留(reservation)，把使用無(wú)連接協(xié)議的因特網(wǎng)轉(zhuǎn)變?yōu)槊嫦蜻B接的網(wǎng)絡(luò)3、部分改動(dòng)因特網(wǎng)的協(xié)議棧所付出的代價(jià)較小，而這也能夠使多媒體信息在因特網(wǎng)上的傳輸質(zhì)量得到改進(jìn)11目前因特網(wǎng)提供的音頻/視頻服務(wù)大體上可分為三種類(lèi)型流式(streaming)存儲(chǔ)音頻/視頻——邊下載邊播放流式實(shí)況音頻/視頻——邊錄制邊發(fā)送交互式音頻/視頻——實(shí)時(shí)交互式通信12目前因特網(wǎng)提供的音頻/視頻服務(wù)大體上可分為三種類(lèi)型流式(streaming)存儲(chǔ)音頻/視頻——邊下載邊播放在這類(lèi)應(yīng)用中，客戶機(jī)根據(jù)需求請(qǐng)求存儲(chǔ)在服務(wù)器上的被壓縮的音頻或視頻文件目前數(shù)以千計(jì)的場(chǎng)點(diǎn)提供流式存數(shù)音頻和視頻，包括CNN和Youtube等流式實(shí)況音頻/視頻——邊錄制邊發(fā)送交互式音頻/視頻——實(shí)時(shí)交互式通信13目前因特網(wǎng)提供的音頻/視頻服務(wù)大體上可分為三種類(lèi)型流式(streaming)存儲(chǔ)音頻/視頻——邊下載邊播放流式實(shí)況音頻/視頻——邊錄制邊發(fā)送這類(lèi)應(yīng)用類(lèi)似于傳統(tǒng)的電臺(tái)廣播和電視，只是它通過(guò)因特網(wǎng)來(lái)傳輸而已這些應(yīng)用允許用戶接收從世界任何角落發(fā)出的實(shí)況無(wú)線電廣播和電視傳輸交互式音頻/視頻——實(shí)時(shí)交互式通信14目前因特網(wǎng)提供的音頻/視頻服務(wù)大體上可分為三種類(lèi)型流式(streaming)存儲(chǔ)音頻/視頻——邊下載邊播放流式實(shí)況音頻/視頻——邊錄制邊發(fā)送交互式音頻/視頻——實(shí)時(shí)交互式通信這類(lèi)應(yīng)用允許人們使用音頻/視頻互相實(shí)時(shí)通信因特網(wǎng)上的實(shí)時(shí)交互音頻通常稱(chēng)為因特網(wǎng)電話(Internettelephony)，因?yàn)閺挠脩艚嵌葋?lái)看，它類(lèi)似于傳統(tǒng)的電路交換電話服務(wù)15“邊下載邊播放”中的“下載”“邊下載邊播放”結(jié)束后，在用戶的硬盤(pán)上沒(méi)有留下有關(guān)播放內(nèi)容的任何痕跡流媒體(streamingmedia)，即流式音頻/視頻流媒體特點(diǎn)就是“邊下載邊播放”(streamingandplaying)

1612.2流式存儲(chǔ)音頻/視頻傳統(tǒng)的下載文件方法萬(wàn)維網(wǎng)服務(wù)器客戶機(jī)服務(wù)器媒體播放器

GET:音頻/視頻文件

RESPONSE

音頻/視頻文件瀏覽器17傳統(tǒng)的瀏覽器從服務(wù)器

下載音頻/視頻文件

用戶從客戶機(jī)(client)的瀏覽器上用HTTP協(xié)議向服務(wù)器請(qǐng)求下載某個(gè)音頻/視頻文件服務(wù)器如有此文件就發(fā)送給瀏覽器。在響應(yīng)報(bào)文中就裝有用戶所要的音頻/視頻文件。整個(gè)下載過(guò)程可能會(huì)花費(fèi)很長(zhǎng)的時(shí)間

當(dāng)瀏覽器完全收下這個(gè)文件后，就可以傳送給自己機(jī)器上的媒體播放器進(jìn)行解壓縮，然后播放1812.2.1具有元文件的萬(wàn)維網(wǎng)服務(wù)器元文件就是一種非常小的文件，它描述或指明其他文件的一些重要信息萬(wàn)維網(wǎng)服務(wù)器客戶機(jī)服務(wù)器媒體播放器

元文件瀏覽器

GET:元文件

RESPONSEGET:音頻/視頻文件RESPONSE19使用元文件下載音頻/視頻文件

瀏覽器用戶使用HTTP的GET報(bào)文接入到萬(wàn)維網(wǎng)服務(wù)器，這個(gè)超鏈接指向一個(gè)元文件，這個(gè)元文件有實(shí)際的音頻/視頻文件的統(tǒng)一資源定位符URL

萬(wàn)維網(wǎng)服務(wù)器把該元文件裝入HTTP響應(yīng)報(bào)文的主體，發(fā)回給瀏覽器客戶機(jī)瀏覽器調(diào)用相關(guān)的媒體播放器，把提取出的元文件傳送給媒體播放器媒體播放器使用元文件中的URL，向萬(wàn)維網(wǎng)服務(wù)器發(fā)送HTTP請(qǐng)求報(bào)文，要求下載音頻/視頻文件萬(wàn)維網(wǎng)服務(wù)器發(fā)送HTTP響應(yīng)報(bào)文，把該音頻/視頻文件發(fā)送給媒體播放器。媒體播放器邊下載邊解壓縮邊播放2012.2.2媒體服務(wù)器媒體服務(wù)器也稱(chēng)為流式服務(wù)器(streamingserver)，它支持流式音頻和視頻的傳送媒體播放器與媒體服務(wù)器的關(guān)系是客戶與服務(wù)器的關(guān)系媒體播放器不是向萬(wàn)維網(wǎng)服務(wù)器而是向媒體服務(wù)器請(qǐng)求音頻/視頻文件媒體服務(wù)器和媒體播放器之間采用另外的協(xié)議進(jìn)行交互21使用媒體服務(wù)器萬(wàn)維網(wǎng)服務(wù)器媒體播放器

元文件瀏覽器

GET:元文件

RESPONSEGET:音頻/視頻文件RESPONSE媒體服務(wù)器客戶機(jī)服務(wù)器22采用媒體服務(wù)器

下載音頻/視頻文件的步驟~

前三個(gè)步驟仍然和上一節(jié)的一樣，區(qū)別就是后面兩個(gè)步驟媒體播放器使用元文件中的URL接入到媒體服務(wù)器，請(qǐng)求下載瀏覽器所請(qǐng)求的音頻/視頻文件。下載可以借助于使用UDP的任何協(xié)議，例如使用實(shí)時(shí)傳輸協(xié)議RTP

媒體服務(wù)器給出響應(yīng)，把該音頻/視頻文件發(fā)送給媒體播放器。媒體播放器在遲延了若干秒后，以流的形式邊下載邊解壓縮邊播放2312.2.3實(shí)時(shí)流式協(xié)議RTSP

(Real-TimeStreamingProtocol)

RTSP協(xié)議以客戶/服務(wù)器方式工作，它是一個(gè)多媒體播放控制協(xié)議，用來(lái)使用戶在播放從因特網(wǎng)下載的實(shí)時(shí)數(shù)據(jù)時(shí)能夠進(jìn)行控制，如：暫停/繼續(xù)、后退、前進(jìn)等因此RTSP又稱(chēng)為“因特網(wǎng)錄像機(jī)遙控協(xié)議”要實(shí)現(xiàn)RTSP的控制功能，不僅要有協(xié)議，而且要有專(zhuān)門(mén)的媒體播放器(mediaplayer)和媒體服務(wù)器(mediaserver)

24RTSP簡(jiǎn)介RTSP協(xié)議是由RealNetworks(音頻/視頻流領(lǐng)域的業(yè)界領(lǐng)袖之一)和Netcape共同提出的

RTSP協(xié)議是一個(gè)流媒體協(xié)議，用于視頻點(diǎn)播、視頻會(huì)議、視頻監(jiān)控等領(lǐng)域

知名端口：554

RTSP語(yǔ)法是基于文本的，類(lèi)似HTTP協(xié)議RTSP中的所有操作都是通過(guò)服務(wù)器和客戶端的消息應(yīng)答來(lái)完成的，其消息包括請(qǐng)求(Request)和響應(yīng)(Response)兩種25RTSP不能做什么RTSP沒(méi)有定義用于音頻和視頻的壓縮方案RTSP沒(méi)有定義音頻和視頻在網(wǎng)絡(luò)傳輸中是怎樣封裝在分組中的流式媒體的封裝可以通過(guò)RTP或?qū)Ｓ脜f(xié)議來(lái)提供RTSP不限制流式媒體如何傳輸，它可以在UDP或TCP上傳輸RTSP不限制媒體播放器如何緩沖音頻/視頻音頻/視頻可能在它一到達(dá)客戶機(jī)就開(kāi)始播放，也可能在延遲幾秒后播放，或者完全下載下來(lái)再播放

26RTSP特點(diǎn)RTSP允許媒體播放器控制媒體流傳輸暫停/繼續(xù)、播放重定位、快進(jìn)和快退等RTSP信道在很多方面和FTP的控制信道類(lèi)似RTSP本身并不傳送數(shù)據(jù)，而僅僅是使媒體播放器能夠控制多媒體流的傳送RTSP是一個(gè)帶外協(xié)議(out-of-bandprotocol)

RTSP報(bào)文在帶外發(fā)送，而媒體流的分組結(jié)構(gòu)沒(méi)有被RTSP定義，它被認(rèn)為是“帶內(nèi)”的RTSP報(bào)文和媒體流使用不同的端口號(hào)27RTSP消息格式RTSP的消息有兩大類(lèi)：請(qǐng)求消息

回應(yīng)消息請(qǐng)求消息：方法URIRTSP版本CRLF消息頭CRLFCRLF消息體CRLF28RTSP消息格式說(shuō)明方法即可用的命令，如：OPTIONS：客戶端用于得到服務(wù)器提供的可用方法DESCRIBE：客戶端用于得到會(huì)話描述信息(SDP)SETUP：客戶端提醒服務(wù)器建立會(huì)話，并確定傳輸模式PLAY：客戶端發(fā)送播放請(qǐng)求TEARDOWN：客戶端發(fā)起關(guān)閉請(qǐng)求URI是接受方的地址，如：rtsp://36RTSP版本一般都是RTSP/1.0每行后面的CRLF表示回車(chē)換行，需要接受端有相應(yīng)的解析，最后一個(gè)消息頭需要有兩個(gè)CRLF29RTSP消息格式回應(yīng)消息：RTSP版本狀態(tài)碼解釋CRLF消息頭CRLFCRLF消息體CRLF說(shuō)明RTSP版本一般都是RTSP/1.0狀態(tài)碼是一個(gè)數(shù)值

200表示成功

解釋是與狀態(tài)碼對(duì)應(yīng)的文本解釋

萬(wàn)維網(wǎng)服務(wù)器客戶機(jī)服務(wù)器媒體播放器

元文件瀏覽器媒體服務(wù)器音頻/視頻流

GET:元文件

RESPONSESETUPRESPONSEPLAYRESPONSE

RESPONSE

TEARDOWN

3031使用RTSP的媒體服務(wù)器

的工作過(guò)程

瀏覽器向萬(wàn)維網(wǎng)服務(wù)器請(qǐng)求音頻/視頻文件萬(wàn)維網(wǎng)服務(wù)器從瀏覽器發(fā)送攜帶有元文件的響應(yīng)瀏覽器把收到的元文件傳送給媒體播放器

RTSP客戶與媒體服務(wù)器的RTSP服務(wù)器建立連接

RTSP服務(wù)器發(fā)送響應(yīng)RESPONSE報(bào)文

RTSP客戶發(fā)送PLAY報(bào)文，開(kāi)始下載音頻/視頻文件

RTSP服務(wù)器發(fā)送響應(yīng)RESPONSE報(bào)文

RTSP客戶發(fā)送TEARDOWN報(bào)文斷開(kāi)連接

RTSP服務(wù)器發(fā)送響應(yīng)RESPONSE報(bào)文32RTSP交互示例CSSETUPrtsp://9/zuoyou001.mp4/trackID=65537RTSP/1.0CSeq:5User-Agent:LibVLC/1.1.11(LIVE555StreamingMediav2011.05.25)Transport:RTP/AVP/TCP;unicast;interleaved=2-3Session:183719934190660238633RTSP交互示例SCRTSP/1.0200OKServer:DSS/6.0.3(Build/526.3;Platform/FreeBSD;Release/DarwinStreamingServer;State/Development;)Cseq:5Session:1837199341906602386Last-Modified:Thu,17Jan200211:20:30GMTCache-Control:must-revalidateDate:Wed,04Jan201206:14:53GMTExpires:Wed,04Jan201206:14:53GMTTransport:RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=5B56A40534RTSP交互示例CSPLAYrtsp://9/zuoyou001.mp4/RTSP/1.0CSeq:6User-Agent:LibVLC/1.1.11(LIVE555StreamingMediav2011.05.25)Session:1837199341906602386Range:npt=0.000-35RTSP交互示例SCRTSP/1.0200OKServer:DSS/6.0.3(Build/526.3;Platform/FreeBSD;Release/DarwinStreamingServer;State/Development;)Cseq:6Session:1837199341906602386Range:npt=0.00000-6640.12667RTP-Info:url=rtsp://9/zuoyou001.mp4/trackID=65536;seq=55088;rtptime=37707334,url=rtsp://9/zuoyou001.mp4/trackID=65537;seq=19114;rtptime=55015466836RTSP交互示例CSTEARDOWNrtsp://9/zuoyou001.mp4/RTSP/1.0CSeq:7User-Agent:LibVLC/1.1.11(LIVE555StreamingMediav2011.05.25)Session:183719934190660238637RTSP交互示例SCRTSP/1.0200OKServer:DSS/6.0.3(Build/526.3;Platform/FreeBSD;Release/DarwinStreamingServer;State/Development;)Cseq:7Session:1837199341906602386Connection:Close38RTSP與HTTP的異同注意RTSP和HTTP之間的相似性RTSP在語(yǔ)法和操作上與HTTP/1.1類(lèi)似，因此HTTP的擴(kuò)展機(jī)制在多數(shù)情況下可加入RTSP所有的請(qǐng)求和響應(yīng)報(bào)文都是采用ASCII文本格式，客戶機(jī)使用標(biāo)準(zhǔn)化的方法（SETUP、PLAY、PAUSE等），服務(wù)器用標(biāo)準(zhǔn)化的應(yīng)答碼來(lái)響應(yīng)

39RTSP與HTTP的異同一些區(qū)別：RTSP中客戶端和服務(wù)器都可以發(fā)出請(qǐng)求在多數(shù)情況下，數(shù)據(jù)由不同的協(xié)議傳輸RTSP服務(wù)器一直跟蹤每個(gè)正在進(jìn)行的RTSP會(huì)話中的客戶機(jī)狀態(tài)如服務(wù)器記錄客戶機(jī)是位于初始化狀態(tài)、播放狀態(tài)還是暫停狀態(tài)作為每個(gè)RTSP請(qǐng)求和響應(yīng)的一部分，會(huì)話號(hào)和序號(hào)幫助服務(wù)器跟蹤會(huì)話狀態(tài)會(huì)話號(hào)在整個(gè)會(huì)話中不變，客戶機(jī)每次發(fā)送一個(gè)新的報(bào)文就增加序號(hào)服務(wù)器使用會(huì)話號(hào)和現(xiàn)在的序號(hào)來(lái)回顯4012.3交互式音頻/視頻

12.3.1IP電話概述狹義的IP電話就是指在IP網(wǎng)絡(luò)上打電話。所謂“IP網(wǎng)絡(luò)”就是“使用IP協(xié)議的分組交換網(wǎng)”的簡(jiǎn)稱(chēng)廣義的IP電話則不僅僅是電話通信，而且還可以是在IP網(wǎng)絡(luò)上進(jìn)行交互式多媒體實(shí)時(shí)通信（包括話音、圖像等），甚至還包括即時(shí)通信IM(InstantMessaging)

IP電話網(wǎng)關(guān)的幾種連接方法分組交換電路交換電路交換

因特網(wǎng)PC到PC公用電話網(wǎng)IP

電話網(wǎng)關(guān)

因特網(wǎng)PC到固定電話機(jī)公用電話網(wǎng)IP

電話網(wǎng)關(guān)公用電話網(wǎng)IP

電話網(wǎng)關(guān)因特網(wǎng)固定電話機(jī)到固定電話機(jī)41IP電話網(wǎng)關(guān)是公用電話網(wǎng)與IP網(wǎng)絡(luò)的接口設(shè)備1、在電話呼叫階段和呼叫釋放階段，進(jìn)行電話信令的轉(zhuǎn)換2、在通話期間，進(jìn)行話音編碼的轉(zhuǎn)換42IP電話的通話質(zhì)量在電路交換電話網(wǎng)中，任何兩端之間的通話質(zhì)量都是有保證的，但I(xiàn)P電話則不然IP電話的通話質(zhì)量主要由兩個(gè)因素決定：一個(gè)是通話雙方端到端的時(shí)延和時(shí)延抖動(dòng)另一個(gè)是話音分組的丟失率但這兩個(gè)因素是不確定的，是取決于當(dāng)時(shí)網(wǎng)絡(luò)上的通信量網(wǎng)絡(luò)通信量非常大，以致發(fā)生擁塞，就會(huì)影響IP電話的通話質(zhì)量一個(gè)用戶使用IP電話的通話質(zhì)量取決于當(dāng)時(shí)其他的許多用戶的行為43IP電話的通話質(zhì)量當(dāng)電路交換電話網(wǎng)的通信量太大時(shí)，往往使我們無(wú)法撥通電話但只要撥通電話，那電信公司就能保證讓用戶滿意的通話質(zhì)量經(jīng)驗(yàn)證明，在電話交談中，端到端的時(shí)延不應(yīng)超過(guò)250ms，否則交談?wù)呔湍芨械讲蛔匀魂懙毓秒娫捑W(wǎng)的時(shí)延一般只有50~70ms經(jīng)過(guò)同步衛(wèi)星的電話端到端時(shí)延就超過(guò)250ms，因此一般人都不太適應(yīng)經(jīng)過(guò)衛(wèi)星傳送的過(guò)長(zhǎng)時(shí)延44IP電話的端到端時(shí)延(1)話音信號(hào)進(jìn)行模數(shù)轉(zhuǎn)換要經(jīng)受時(shí)延(2)話音比特流裝配成話音分組的時(shí)延(3)話音分組的發(fā)送時(shí)間，此時(shí)間等于話音分組長(zhǎng)度與通信線路的數(shù)據(jù)率之比(4)話音分組在因特網(wǎng)中的存儲(chǔ)轉(zhuǎn)發(fā)時(shí)延(5)話音分組在接收端緩存中暫存所引起的時(shí)延(6)話音分組還原成模擬話音信號(hào)的時(shí)延(7)話音信號(hào)在通信線路上的傳播時(shí)延(8)終端設(shè)備的硬件和操作系統(tǒng)產(chǎn)生的接入時(shí)延45話音信號(hào)在通信線路上的傳播時(shí)延一般都很小（衛(wèi)星通信除外），通?？刹挥杩紤]當(dāng)采用高速光纖主干網(wǎng)時(shí)，第三項(xiàng)的時(shí)延也不大第一、第二和第六項(xiàng)時(shí)延取決于話音編碼的方法在保證話音質(zhì)量的前提下，話音信號(hào)的數(shù)碼率應(yīng)盡可能低些ITU-T已制定出不少話音質(zhì)量不錯(cuò)的低速率話音編碼標(biāo)準(zhǔn)IP電話的端到端時(shí)延46適合IP電話的

低速率話音編碼標(biāo)準(zhǔn)(1)G.729——速率為8kb/s的共軛結(jié)構(gòu)代數(shù)碼激勵(lì)線性預(yù)測(cè)聲碼器CS-ACELP(Conjugate-StructureAlgebraic-Code-ExcitedLinearPrediction)

(2)G.723.1——速率為5.3/6.3kb/s的為多媒體通信用的低速率聲碼器47要減少上述第四和第五項(xiàng)時(shí)延較為困難當(dāng)網(wǎng)絡(luò)發(fā)生擁塞而產(chǎn)生話音分組丟失時(shí)，還必須采用一定的策略（稱(chēng)為“丟失掩蔽算法”）對(duì)丟失的話音分組進(jìn)行處理如，可使用前一個(gè)話音分組來(lái)填補(bǔ)丟失的話音分組的間隙IP電話的端到端時(shí)延48接收端緩存空間和播放時(shí)延的大小對(duì)話音分組丟失率和端到端時(shí)延也有很大的影響IP電話的端到端時(shí)延49D

分組丟失率端到端時(shí)延20%10%5%100ms150ms400msABCN良好基本可用不好長(zhǎng)途電話質(zhì)量接收端播放時(shí)延增大越接近坐標(biāo)原點(diǎn)，話音質(zhì)量就越好播放時(shí)延的最佳值50播放時(shí)延的最佳值假定某IP電話的通話質(zhì)量處于圖中的B點(diǎn)位置若增大接收端緩存空間，并增大播放時(shí)延

則話音分組丟失率將減少，但端到端的時(shí)延將增加（如圖中的C點(diǎn)）繼續(xù)增大播放時(shí)延則話音分組丟失率將繼續(xù)減少，趨向于網(wǎng)絡(luò)所引起的丟失率（如圖中的D點(diǎn)）但D點(diǎn)的端到端時(shí)延很大，話音質(zhì)量很不好51播放時(shí)延的最佳值反之，若將接收端緩存空間做得很小，并減小播放時(shí)延

則端到端時(shí)延將減小，趨向于網(wǎng)絡(luò)所引起的端到端時(shí)延（如圖中的A點(diǎn)）但話音分組丟失率將大大增加，話音質(zhì)量也不好可見(jiàn)，接收端的播放時(shí)延有一個(gè)最佳值圖中的N點(diǎn)，相當(dāng)于端到端時(shí)延和話音分組丟失率都是最小但實(shí)際上并不可能工作在這個(gè)點(diǎn)上52時(shí)延估計(jì)據(jù)統(tǒng)計(jì)，當(dāng)通話雙方相距3200km時(shí)，因特網(wǎng)上的時(shí)延約為30~100ms（傳播和排隊(duì)）而所有各環(huán)節(jié)的時(shí)延總和約為100~262ms（在兩個(gè)IP電話網(wǎng)關(guān)之間）或170~562ms（在兩個(gè)PC機(jī)之間）[KAST98]可見(jiàn)，為減少時(shí)延，應(yīng)盡可能不要直接用PC機(jī)打IP電話53線速路由器提高路由器的轉(zhuǎn)發(fā)分組的速率對(duì)提高IP電話的質(zhì)量也是很重要的據(jù)統(tǒng)計(jì)，一個(gè)跨大西洋的IP電話一般要經(jīng)過(guò)2030個(gè)路由器若能改用吉比特路由器（又稱(chēng)為線速路由器），則每秒可轉(zhuǎn)發(fā)5百萬(wàn)至6千萬(wàn)個(gè)分組（即交換速率達(dá)60Gb/s左右）。這樣還可進(jìn)一步減少由網(wǎng)絡(luò)造成的時(shí)延54IP電話質(zhì)量得到很大提高現(xiàn)在很多IP電話的話音質(zhì)量已經(jīng)優(yōu)于固定電話的話音質(zhì)量一些電信運(yùn)營(yíng)商還建造了自己專(zhuān)用的IP電話線路，以便保證更好的通話質(zhì)量在IP電話領(lǐng)域，最值得一提的就是SkypeIP電話，它給全世界的廣大用戶帶來(lái)了高品質(zhì)并且廉價(jià)的通話服務(wù)55關(guān)于SkypeSkype使用GlobalIPSound公司開(kāi)發(fā)的互聯(lián)網(wǎng)低比特率編解碼器iLBC(internetLowBitrateCodec)，進(jìn)行話音的編解碼和壓縮，使其話音質(zhì)量?jī)?yōu)于傳統(tǒng)的公用電話網(wǎng)（采用電路交換）的話音質(zhì)量Skype支持兩種幀長(zhǎng)：20ms，速率為15.2kb/s，一個(gè)話音分組塊為304bit30ms，速率為13.33kb/s，一個(gè)話音分組塊為400bit

Skype的另一特點(diǎn)是對(duì)話音分組的丟失進(jìn)行了特殊處理，因而能容忍高達(dá)30%的話音分組丟失率，通話的用戶一般感受不到話音的斷續(xù)或延遲，雜音也很小56關(guān)于SkypeSkype采用P2P和全球索引（GlobalIndex）技術(shù)提供快速路由選擇機(jī)制，管理成本大大降低。由于用戶路由信息分布式存儲(chǔ)于因特網(wǎng)的結(jié)點(diǎn)中，因此呼叫連接完成得很快Skype采用端對(duì)端加密方式，保證信息的安全性Skype使用P2P的技術(shù)，用戶數(shù)據(jù)主要存儲(chǔ)在P2P網(wǎng)絡(luò)中，因此必須保證存儲(chǔ)在公共網(wǎng)絡(luò)中的數(shù)據(jù)是可靠和沒(méi)有被篡改的。Skype對(duì)公共目錄中存儲(chǔ)的和用戶相關(guān)的數(shù)據(jù)都采用數(shù)字簽名，保證了數(shù)據(jù)無(wú)法被篡改Skype的問(wèn)世給全球信息技術(shù)和通信產(chǎn)業(yè)帶來(lái)深遠(yuǎn)的影響，也給每一位網(wǎng)絡(luò)使用者帶來(lái)生活方式的改變12.3.2IP電話所需要的

幾種應(yīng)用協(xié)議57在IP電話的通信中，至少需要兩種應(yīng)用協(xié)議：一種是信令協(xié)議，它使我們能夠在因特網(wǎng)上找到被叫用戶另一種是話音分組的傳送協(xié)議，它使我們用來(lái)進(jìn)行電話通信的話音數(shù)據(jù)能夠以時(shí)延敏感屬性在因特網(wǎng)中傳送TCPUDP信令提高服務(wù)質(zhì)量IPv4/IPv6RTSPRTCPRSVPH.323SIPRTP應(yīng)用層協(xié)議傳送音頻/視頻SDP底層網(wǎng)絡(luò)5812.3.2IP電話所需要的

幾種應(yīng)用協(xié)議5912.3.3實(shí)時(shí)傳輸協(xié)議RTP

(Real-timeTransportProtocol)

RTP為實(shí)時(shí)應(yīng)用提供端到端的傳輸，但不提供任何服務(wù)質(zhì)量(QoS)的保證多媒體數(shù)據(jù)塊經(jīng)壓縮編碼處理后，先送給RTP封裝成為RTP分組，再裝入傳輸層的UDP用戶數(shù)據(jù)報(bào)，然后再交給IP層RTP是一個(gè)協(xié)議框架，只包含了實(shí)時(shí)應(yīng)用的一些共同的功能RTP自己并不對(duì)多媒體數(shù)據(jù)塊做任何處理，而只是向應(yīng)用層提供一些附加的信息，讓?xiě)?yīng)用層知道應(yīng)當(dāng)如何進(jìn)行處理60RTP的層次從應(yīng)用開(kāi)發(fā)者的角度看，RTP應(yīng)當(dāng)是應(yīng)用層的一部分在應(yīng)用的發(fā)送端，開(kāi)發(fā)者必須編寫(xiě)用RTP封裝分組的程序代碼，然后把RTP分組交給UDP插口接口在接收端，RTP分組通過(guò)UDP插口接口進(jìn)入應(yīng)用層后，還要利用開(kāi)發(fā)者編寫(xiě)的程序代碼從RTP分組中把應(yīng)用數(shù)據(jù)塊提取出來(lái)61RTP也可看成是

傳輸層的一個(gè)子層RTP封裝了多媒體應(yīng)用的數(shù)據(jù)塊。由于RTP向多媒體應(yīng)用程序提供了服務(wù)（如時(shí)間戳和序號(hào)），因此也可以將RTP看成是在UDP之上的一個(gè)傳輸層的子層傳輸層應(yīng)用層IP數(shù)據(jù)鏈路層物理層RTPUDPRTP分組的首部格式12字節(jié)序號(hào)位01381631有效載荷類(lèi)型版本PXM參與源數(shù)時(shí)間戳同步源標(biāo)識(shí)符(SSRC)參與源標(biāo)識(shí)符(CSRC)[0..15]…發(fā)送RTP分組UDP用戶數(shù)據(jù)報(bào)IP數(shù)據(jù)報(bào)IP首部UDP首部RTP首部RTP數(shù)據(jù)部分（應(yīng)用層數(shù)據(jù)）6263RTP首部版本：占2位。當(dāng)前使用的是版本2填充P：占1位。特殊情況下用于填充擴(kuò)展X：X置1表示在此RTP首部后面還有擴(kuò)展首部，這里不做討論參與源數(shù)：占4位。這個(gè)字段給出后面的參與源標(biāo)識(shí)符的數(shù)目參與源標(biāo)識(shí)符：這是選項(xiàng)，最多可有15個(gè)。也是一個(gè)32位數(shù)，用來(lái)標(biāo)志來(lái)源于不同地點(diǎn)的RTP流64RTP首部標(biāo)記M：占1位。M置1表示這個(gè)RTP分組具有特殊意義如，在傳送視頻流時(shí)，用來(lái)表示每一幀的開(kāi)始有效載荷類(lèi)型：占7位。指出后面的RTP數(shù)據(jù)屬于何種格式的應(yīng)用如，對(duì)于音頻有效載荷：GSM(3)、LPC(7)、G.722(9)、G.28(15)等對(duì)于視頻有效載荷：活動(dòng)JPEG(26)、H.261(31)、MPEG1(32)、MPEG2(33)等65RTP首部序號(hào)：占16位。對(duì)每一個(gè)發(fā)送出的RTP分組，其序號(hào)加1

在一次RTP會(huì)話開(kāi)始時(shí)的初始序號(hào)是隨機(jī)選擇的

時(shí)間戳：占32位。反應(yīng)了RTP分組中的數(shù)據(jù)的第一個(gè)字節(jié)的采樣時(shí)刻在一次會(huì)話開(kāi)始時(shí)時(shí)間戳的初始值也是隨機(jī)選擇的即使是在沒(méi)有信號(hào)發(fā)送時(shí)，時(shí)間戳的數(shù)值也要隨時(shí)間而不斷地增加66RTP首部同步源標(biāo)識(shí)符SSRC：占32位。是一個(gè)數(shù)，用于標(biāo)識(shí)RTP流的來(lái)源SSRC與IP地址無(wú)關(guān)，在新的RTP流開(kāi)始時(shí)隨機(jī)產(chǎn)生兩個(gè)流被分配相同SSRC的概率是很小的，如果發(fā)生了，這兩個(gè)源應(yīng)選擇一個(gè)新的SSRC值6712.3.4實(shí)時(shí)傳輸控制協(xié)議RTCP(RTPControlProtocol)

RTCP是與RTP配合使用的協(xié)議RTCP協(xié)議主要功能是：服務(wù)質(zhì)量的監(jiān)視與反饋、媒體間的同步，以及多播組中成員的標(biāo)識(shí)RTCP分組也使用UDP傳送，但RTCP并不對(duì)聲音或視頻分組進(jìn)行封裝可將多個(gè)RTCP分組封裝在一個(gè)UDP數(shù)據(jù)報(bào)中RTCP分組周期性地在網(wǎng)上傳送，它帶有發(fā)送端和接收端對(duì)服務(wù)質(zhì)量的統(tǒng)計(jì)信息報(bào)告(如已發(fā)送的分組數(shù)和字節(jié)數(shù)、分組丟失率、分組到達(dá)時(shí)間間隔的抖動(dòng)等)

68RTCP使用的五種分組類(lèi)型1、結(jié)束分組BYE，表示關(guān)閉一個(gè)數(shù)據(jù)流2、特定應(yīng)用分組APP，使應(yīng)用程序能夠定義新的分組類(lèi)型69RTCP使用的五種分組類(lèi)型3、接收端報(bào)告分組RR，用來(lái)使接收端周期性地向所有的點(diǎn)用多播方式進(jìn)行報(bào)告接收端每收到一個(gè)RTP流（一次會(huì)話包含多個(gè)RTP流）就產(chǎn)生一個(gè)接收端報(bào)告分組RRRR分組的內(nèi)容有：所收到的RTP流的SSRC；該RTP流的分組丟失率（若分組丟失率太高，發(fā)送端就應(yīng)該適當(dāng)?shù)亟档桶l(fā)送分組的速率）；在該RTP流中的最后一個(gè)RTP分組的序號(hào)；分組到達(dá)時(shí)間間隔的抖動(dòng)等70RTCP使用的五種分組類(lèi)型3、接收端報(bào)告分組RR，用來(lái)使接收端周期性地向所有的點(diǎn)用多播方式進(jìn)行報(bào)告發(fā)送RR分組有兩個(gè)目的：第一，可以使所有的接收端和發(fā)送端了解當(dāng)前網(wǎng)絡(luò)的狀態(tài)第二，可以使所有發(fā)送RTCP分組的站點(diǎn)自適應(yīng)地調(diào)整自己發(fā)送RTCP分組的速率，使得起控制作用的RTCP分組不要過(guò)多地影響傳送應(yīng)用數(shù)據(jù)的RTP分組在網(wǎng)絡(luò)中的傳輸。通常是使RTCP分組的通信量不超過(guò)網(wǎng)絡(luò)中數(shù)據(jù)分組的數(shù)據(jù)量的5%，而接收端的通信量又應(yīng)小于所有RTCP分組的通信量的75%

71RTCP使用的五種分組類(lèi)型4、發(fā)送端報(bào)告分組SR，用來(lái)使發(fā)送端周期性地向所有接收端用多播方式進(jìn)行報(bào)告發(fā)送端每發(fā)送一個(gè)RTP流就要發(fā)送一個(gè)發(fā)送端報(bào)告分組SRSR分組的內(nèi)容有：該RTP流的SSRC；該RTP流中最新產(chǎn)生的RTP分組的時(shí)間戳和絕對(duì)時(shí)鐘時(shí)間（或墻上時(shí)鐘時(shí)間wallclocktime）；該RTP流包含的分組數(shù)；該RTP流包含的字節(jié)數(shù)。絕對(duì)時(shí)鐘時(shí)間是必要的。因?yàn)镽TP要求每一種媒體使用一個(gè)流。例如，要傳送視頻圖像和相應(yīng)的聲音就需要傳送兩個(gè)流。有了絕對(duì)時(shí)鐘時(shí)間就可以進(jìn)行圖像和聲音的同步。72RTCP使用的五種分組類(lèi)型5、源點(diǎn)描述分組SDES，給出會(huì)話中參加者的描述它包括參加者的規(guī)范名CNAME(CanonicalNAME)

規(guī)范名是參加者的電子郵件地址的字符串7312.3.5H.323現(xiàn)在的IP電話有兩套信令標(biāo)準(zhǔn)：一套是ITU-U定義的H.323協(xié)議一套是IETF提出的會(huì)話發(fā)起協(xié)議SIPH.323是國(guó)際電信聯(lián)盟遠(yuǎn)程通信標(biāo)準(zhǔn)化組織(ITU-T)于1996年制訂的一個(gè)名稱(chēng)很長(zhǎng)的建議書(shū)，1998年的第二個(gè)版本改用的名稱(chēng)是“基于分組的多媒體通信系統(tǒng)”請(qǐng)注意：H.323不是一個(gè)單獨(dú)的協(xié)議，而是一組協(xié)議H.323包括系統(tǒng)和構(gòu)件的描述、呼叫模型的描述、呼叫信令過(guò)程、控制報(bào)文、復(fù)用、話音編解碼器、視像編解碼器以及數(shù)據(jù)協(xié)議等，但不保證服務(wù)質(zhì)量(QoS)

74H.323終端使用H.323協(xié)議

進(jìn)行多媒體通信分組交換網(wǎng)（例如，因特網(wǎng)）H.323H.323終端H.323終端

75H.323標(biāo)準(zhǔn)指明的四種構(gòu)件(1)H.323終端——可以是PC機(jī)，也可以是運(yùn)行H.323程序的單個(gè)設(shè)備(2)網(wǎng)關(guān)——網(wǎng)關(guān)連接到兩種不同的網(wǎng)絡(luò)，使H.323網(wǎng)絡(luò)可以和非H.323網(wǎng)絡(luò)進(jìn)行通信(3)網(wǎng)閘(gatekeeper)——相當(dāng)于整個(gè)H.323網(wǎng)絡(luò)的大腦，所有的呼叫都要通過(guò)網(wǎng)閘，因?yàn)榫W(wǎng)閘提供地址轉(zhuǎn)換、授權(quán)、帶寬管理和計(jì)費(fèi)功能(4)多點(diǎn)控制單元MCU(MultipointControlUnit)——支持三個(gè)或更多的H.323終端的音頻或視頻會(huì)議76H.323網(wǎng)關(guān)用來(lái)和

非H.323網(wǎng)絡(luò)進(jìn)行連接因特網(wǎng)公用電話網(wǎng)網(wǎng)關(guān)網(wǎng)閘H.323終端

多點(diǎn)控制單元MCU77H.323的協(xié)議體系結(jié)構(gòu)音頻/視頻應(yīng)用音頻編解碼視頻編解碼RTCPH.225.0登記信令H.225.0呼叫信令H.245控制信令RTPUDPTCPIP信令和控制數(shù)據(jù)應(yīng)用T.120數(shù)據(jù)H.323的出發(fā)點(diǎn)是以已有的電路交換電話網(wǎng)為基礎(chǔ)，增加了IP電話的功能（即遠(yuǎn)距離傳輸采用IP網(wǎng)絡(luò)）H.323的信令也沿用原有電話網(wǎng)的信令模式，因此與原有電話網(wǎng)的連接比較容易7812.3.6會(huì)話發(fā)起協(xié)議SIP

(SessionInitiationProtocol)雖然H.323系列現(xiàn)在已被大部分生產(chǎn)IP電話的廠商采用，但由于H.323過(guò)于復(fù)雜，不便于發(fā)展基于IP的新業(yè)務(wù)，因此IETF的MMUSIC工作組制定了另一套標(biāo)準(zhǔn)，即會(huì)話發(fā)起協(xié)議SIPSIP是一套較為簡(jiǎn)單且實(shí)用的標(biāo)準(zhǔn)，目前已成為因特網(wǎng)的建議標(biāo)準(zhǔn)（RFC3261~3266）7912.3.6會(huì)話發(fā)起協(xié)議SIP

(SessionInitiationProtocol)SIP協(xié)議以因特網(wǎng)為基礎(chǔ)，把IP電話視為因特網(wǎng)上的新應(yīng)用SIP協(xié)議只涉及到IP電話的信令和有關(guān)服務(wù)質(zhì)量問(wèn)題，而沒(méi)有提供像H.323那樣多的功能SIP沒(méi)有指定使用RTP協(xié)議，但實(shí)際上大家還是選用RTP和RTCP作為配合使用的協(xié)議80SIP系統(tǒng)的構(gòu)件SIP使用文本方式的客戶服務(wù)器協(xié)議SIP系統(tǒng)只有兩種構(gòu)件：用戶代理

網(wǎng)絡(luò)服務(wù)器

用戶代理包括用戶代理客戶和用戶代理服務(wù)器

前者用來(lái)發(fā)起呼叫而后者用來(lái)接受呼叫81SIP系統(tǒng)的構(gòu)件網(wǎng)絡(luò)服務(wù)器分為代理服務(wù)器和重定向服務(wù)器

代理服務(wù)器接受來(lái)自主叫用戶的呼叫請(qǐng)求，并將其轉(zhuǎn)發(fā)給下一跳代理服務(wù)器，最后將呼叫請(qǐng)求轉(zhuǎn)發(fā)給被叫用戶重定向服務(wù)器不接受呼叫，它通過(guò)響應(yīng)告訴客戶下一跳代理服務(wù)器的地址，由客戶按此地址向下一跳代理服務(wù)器重新發(fā)送呼叫請(qǐng)求82SIP地址十分靈活可以是電話號(hào)碼，也可以是電子郵件地址、IP地址或其他類(lèi)型的地址但一定要使用SIP的地址格式，例如：電話號(hào)碼sip:zhangsan@8625-87654321IPv4地址sip:zhangsan@6電子郵件地址sip:zhangsan@83SIP協(xié)議和HTTP類(lèi)似，SIP是基于報(bào)文的協(xié)議SIP使用了HTTP的許多首部、編碼規(guī)則、差錯(cuò)碼以及一些鑒別機(jī)制，它比H.323具有更好的可擴(kuò)縮性SIP的會(huì)話共有三個(gè)階段：建立會(huì)話通信終止會(huì)話

84一個(gè)簡(jiǎn)單的SIP會(huì)話

主叫方被叫方OK:地址ACKINVITE:地址，選項(xiàng)建立會(huì)話BYE終止會(huì)話電話交談通信tt85SIP會(huì)話的建立和終止上圖中，SIP的會(huì)話建立和會(huì)話終止階段