1、畢業(yè)論文（設(shè)計）題目：基于RTP的linux實時語音通信系統(tǒng)的設(shè)計與實現(xiàn)摘 要隨著信息社會的高速發(fā)展，Internet已經(jīng)成為很多人生活不可缺少的一部分。當前Internet中流動的“比特”所代表的內(nèi)容已從原來的數(shù)據(jù)逐漸向?qū)崟r多媒體數(shù)據(jù)演變，它們的特點是對實時性要求非常高。但是，Internet是建立在TCP/IP之上的計算機網(wǎng)絡(luò)，最初設(shè)計時的定位決定了它不適合實時數(shù)據(jù)的傳輸。因此，1996年1月IETF音視頻傳輸工作頒布了針對實時應用的實時傳輸協(xié)議RTP/RTCP。RTP/RTCP 使Internet從理論上具備了處理實時業(yè)務的能力，解決了媒體同步問題和滿足了多媒體通信業(yè)務的要求，現(xiàn)在在IP

2、電話、網(wǎng)絡(luò)多媒體會議、遠程網(wǎng)絡(luò)教學和遠程網(wǎng)絡(luò)診斷等領(lǐng)域都有著重大的應用。 本文結(jié)合RTP/RTCP高實時性的特點，主要針對局域網(wǎng)，提出了音頻數(shù)據(jù)采用G729a壓縮，傳輸數(shù)據(jù)采用ortp庫，在linux平臺下開發(fā)的實時語音通信系統(tǒng)。本文首先介紹了實時傳輸協(xié)議的簡單應用后，詳細分析了RTP/RTCP協(xié)議；接著介紹系統(tǒng)的具體實現(xiàn)，主要分三個部分：音頻數(shù)據(jù)的采集和播放，音頻數(shù)據(jù)的解碼和編碼以及音頻數(shù)據(jù)包的發(fā)送和接收。最后簡單闡述了本系統(tǒng)在其他領(lǐng)域的可擴展性及前景。【關(guān)鍵詞】實時性，音頻傳輸，RTP/RTCP，音頻壓縮AbstractWith the rapid development of infor

3、mation society, the Internet has become an indispensable part of a lot of people life.The current flows through the Internet "bits" represented by the contents of which have been gradually from the original data to real-time multimedia data, the characteristic of them is very high demand f

4、or real-time.However, the Internet is based on TCP/IP computer networks, the initial design of location determines it is not suitable for real-time data transmission.Therefore, IETF audio and video transmission work in January 1996 issued for real-time application of real-time transmission protocol

5、RTP/RTCP.RTP/RTCP make Internet theoretically with the real-time ability of the business, the media synchronization problems and meet the requirements of the multimedia communication service, the IP telephone, network, multimedia conference, remote network teaching and remote diagnosis, etc all have

6、 important applications.In this paper, combining with the characteristics of RTP/RTCP high real-time performance, mainly for local area network (LAN), is put forward using G729a audio data compression, data transmission using ortp library, development of real-time voice communication system on the L

7、inux platform.This paper first introduces the simple application of real-time transport protocol, RTP/RTCP protocol are analyzed in detail.Then this paper introduces the implementation of system, mainly divided into three parts: audio data acquisition and playback, audio data decoding and encoding a

8、nd audio packets sent and received.The last simply expounds the system scalability and prospects in other areas.【Keywords】 Real time audio transmission, RTP/RTCP, audio compressionII21嘉應學院畢業(yè)論文(設(shè)計)前 言隨著多媒體網(wǎng)絡(luò)的發(fā)展，RTP/RTCP在眾多領(lǐng)域也得到了深入的應用，如VOIP電話、多媒體會議系統(tǒng)等應用的出現(xiàn)，也讓語音傳輸通信技術(shù)也得到了迅速的發(fā)展。然而，語音通信需要的實時性是非常高的，而且數(shù)據(jù)量大

9、。例如，一個多媒體會議系統(tǒng)，我們總是希望發(fā)言者的發(fā)言能夠盡早讓收聽者收聽到，也就是說時延盡量短；另外一個就是我們希望在收聽者收聽語音信息時，一句話平滑的，即中間沒有斷點，也就是等時性。這些都是實現(xiàn)實時語音通話應達到的要求。為此，本人在導師的指導下，詳細研究分析了RTP/RTCP協(xié)議，結(jié)合RTP/RTCP協(xié)議高實時性的特點，利用現(xiàn)有的音頻編程和網(wǎng)絡(luò)編程知識，設(shè)計和開發(fā)了這個基于RTP的linux實時語音通信系統(tǒng)。目前只實現(xiàn)了單播功能，即點對點的通信。論文的主要內(nèi)容如下：第一章：引言，主要介紹了實時多媒體數(shù)據(jù)傳輸?shù)陌l(fā)展，闡述了TCP不適合多媒體傳輸?shù)脑虿⒁肓薘TP.第二章：根據(jù)RFC3550官

10、方文檔，詳細分析了RTP/RTCP協(xié)議。第三章：介紹了linux下基于RTP的實時語音通信系統(tǒng)實現(xiàn)的基本原理和總體架構(gòu)。第四章：介紹了linux音頻編程。第五章：講解了音頻傳輸?shù)膶崿F(xiàn)。第六章：介紹了音頻解碼和編碼的實現(xiàn)。第七章：總結(jié)與展望。第一章 引言1.1實時數(shù)據(jù)傳輸?shù)陌l(fā)展我們已經(jīng)步入一個高速發(fā)展的信息社會，Internet已經(jīng)成為很多人生活不可缺少的一部分。Internet中流動的“比特”所代表的內(nèi)容已從原來的數(shù)據(jù)逐漸向多媒體演變。隨著IPv6，RSVP,RTP/RTCP一系列協(xié)議的出現(xiàn)，在Internet上實現(xiàn)多媒體通信成為可能。IPv6解決了IPv4地址資源有限，不能控制帶寬等問題，R

11、SVP(資源預留協(xié)議)，RTP/RTCP（實時傳輸/控制協(xié)議）使Internet從理論上具備了處理實時 業(yè)務的能力，解決了媒體同步問題和滿足多媒體通信業(yè)務的要求。越來越多的實時多媒體應用的出現(xiàn)，極大的豐富了人們生活，如成為這幾年的熱點的IP電話，另外還有VID、遠程網(wǎng)絡(luò)教學、遠程網(wǎng)絡(luò)診斷和網(wǎng)絡(luò)多媒體會議業(yè)務、多媒體消息型業(yè)務等。1.2國內(nèi)外研究狀況早在20世紀70年代末80年代初，如何在分組上實時傳輸語音就是一個很活躍的研究方向，到了九十年代初這個方向研究又變得異常活躍。1992年3月，IETF（Internet Engineering Task Force）在San Diego召開的會議是分

12、組網(wǎng)上第一次大規(guī)模的音頻多播應用。會議使用的音頻傳輸軟件主要是Vat（Visual Audio Tool）,它是由LBNL（Lawrence Berkeley National Laboratory）網(wǎng)絡(luò)研究小組開發(fā)的一個音頻會議工具，該小組還開發(fā)了視頻工具vic和白板工具wb。會議還使用的另一個音頻軟件是NeVoT(Network Voice Terminal),它是H.Schulzrinne等人在90年代初開發(fā)出來的。該軟件最初使用的是vat協(xié)議，但是在RTP協(xié)議制定出來后也開始支持RTP協(xié)議了。還有其他大學，研究組織研究開發(fā)出來的音頻工具TAT（Robust Audio Tool），會議

13、目錄工具SDR(session directory)，CU-SeeMe音頻會議工具等等。 在國內(nèi)，清華電子工程系網(wǎng)絡(luò)研究所多媒體通信課題組也在這方面做了大量的研究，并開發(fā)出了Cool-audio、Cool-Video、Cool-Meeting等一系列軟件。其中Cool-audio網(wǎng)絡(luò)電話于1998年推出，它是我國第一套自主版權(quán)且最有影響的Internet電話軟件。另外，東南大學計算機系，北京郵電大學電信工程學院和華中科技大學等研究機構(gòu)也在這方面做出了大量的研究工作。北京的微軟亞洲研究院的網(wǎng)絡(luò)多媒體組正在做SMART音/視頻傳輸(SMART A/V Delivery)等項。但是總的來說，國內(nèi)的研

14、究水平要遠遠落后于國外。可以說，實時多媒體數(shù)據(jù)傳輸研究已經(jīng)有了長足的進步，制定了許多相關(guān)的傳輸協(xié)議，例如：RTP（Real-time Transport Protocol）和RTCP(Real-time Transport Control Protocol),RTSP(Real-time Streaming Protocol),SIP(Session Initiation Protocol)，H.232，RSVP(Resource Reserve Protocol)，服務區(qū)分協(xié)議（Diff-Serv），多協(xié)議標記交換協(xié)議（Mulit-Protocol Label Switching，MPLS）

15、等等，這些都是構(gòu)建當前多媒體通信的主要協(xié)議。在這些協(xié)議中，RTP和RTCP主要負責實時數(shù)據(jù)以及實現(xiàn)最基本的傳輸控制，本設(shè)計就是Linux下基于RTP協(xié)議的實時音頻傳輸?shù)膶崿F(xiàn)。1.3實時多媒體數(shù)據(jù)傳輸?shù)奶攸c實現(xiàn)多媒體數(shù)據(jù)傳輸?shù)暮诵氖锹暋⑽摹D等多媒體信息的傳輸技術(shù)，它的一個顯著特點是數(shù)據(jù)量大，并且許多應用對實時性都有比較高的要求，例如，一個多媒體會議系統(tǒng)，我們總是希望發(fā)言者的發(fā)言能夠盡早讓收聽者收聽到，也就是說時延盡量短；另外一個就是我們希望在收聽者收聽語音信息時，一句話平滑的，即中間沒有斷點，也就是等時性。這些都是實現(xiàn)實時語音通話應達到的要求。1.4 TCP不適合傳輸實時多媒體數(shù)據(jù)Intern

16、et是建立在TCP/IP之上的計算機網(wǎng)絡(luò)，它最初是為提供非實時數(shù)據(jù)業(yè)務而設(shè)計的。IP協(xié)議是面向無連接的，負責主機之間的數(shù)據(jù)傳輸，但只提供“盡力而為”（best-effort）的服務，不進行檢錯和糾錯，因此經(jīng)常發(fā)生數(shù)據(jù)丟失現(xiàn)象。為保證數(shù)據(jù)的可靠傳輸，在傳輸層使用TCP協(xié)議，當接收端檢測到數(shù)據(jù)包丟失或錯誤時，要求發(fā)送端重新發(fā)送，但這樣不可避免地引起傳輸延時和占用網(wǎng)絡(luò)帶寬。因此傳統(tǒng)的TCP/IP協(xié)議傳輸實時音頻、視頻數(shù)據(jù)的能力比較差。當然在傳輸用于回放的視頻和音頻數(shù)據(jù)時，TCP也是一種選擇。如果有足夠大的緩沖區(qū)和充足的網(wǎng)絡(luò)帶寬，比如在局域網(wǎng)內(nèi)，在TCP協(xié)議上，接近實時的傳輸也是可能的。但是在大多數(shù)情

17、況下，我們需要再廣域網(wǎng)內(nèi)傳輸數(shù)據(jù)，在這種丟包率較高、網(wǎng)絡(luò)狀況不好的情況下，利用TCP協(xié)議進行視頻或音頻通信顯然不是很好的一個選擇。TCP協(xié)議是面向連接的協(xié)議，它的重傳機制和擁塞控制機制都是不適合用于實時多媒體傳輸?shù)摹Ｏ旅婢唧w分析網(wǎng)絡(luò)運行一下TCP和其他可靠傳輸層協(xié)議如XTP不適合實時傳輸?shù)膸讉€主要原因。（1）.啟動速度慢即便在網(wǎng)絡(luò)運行狀況良好，沒有丟失包的情況下，由于TCP的建立連接需“三次握手”，因而在初始化的過程中，需要較長的時間。而在一個實時多媒體的應用中，我們期望盡量少的延遲。（2）.TCP的重傳機制在TCP/IP協(xié)議中，當發(fā)送方收不到接收方發(fā)來的確認，并超過一定的時間，就認定該數(shù)據(jù)已

18、丟失，這時它將重傳丟失的數(shù)據(jù)包。這一過程將需要一個甚至更多的周期，這種重傳機制對于實時性要求較高的多媒體數(shù)據(jù)傳輸來說是災難性的，因為接收不得不等待重傳數(shù)據(jù)的到來，從而造成了延時和斷點。（3）.TCP的擁塞控制機制TCP擁塞控制機制在探測到有數(shù)據(jù)包丟失時，它就會減少它的擁塞窗口。另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量是不可能突然改變的，例如，標準的PCM音頻需要64Kb/s，加上一些額外控制信息，它不能再低于這個帶寬要求的網(wǎng)絡(luò)上傳輸。正確的擁塞控制應該是變換音頻、視頻信息的編碼方式，調(diào)節(jié)視頻信息的幀頻或者圖像的大小。（4）.報文頭的大小TCP和XTP報文頭都比UDP的報文頭大，T

19、CP和XTP3.6的報文頭為40字節(jié)，XTP4.0為32字節(jié)，而RTP的固定報文頭為12字節(jié)，因而它們所能攜帶的信息占整個報文的比例相對來說比較小。并且這些可靠的傳輸協(xié)議不能提供時間戳和編解碼信息，而這些信息是接收方應用程序所需要的，因此它們是不適合進行多媒體信息傳輸?shù)摹?.5 RTP的引入基于上一節(jié)的分析，我們可以清楚的認識到TCP協(xié)議是不適合用來進行傳輸實時多媒體數(shù)據(jù)的，因此考慮選擇UDP作為RTP的傳輸層協(xié)議。UDP是一種面向無連接的數(shù)據(jù)報方式，當通信一旦開始，發(fā)送方就不斷地發(fā)送數(shù)據(jù)而不需要接收端做出確認信息。它取消了重發(fā)校驗機制，因此能夠達到較高的通信速率，但不能保證報文的先后順序，也

20、不能保證數(shù)據(jù)傳輸?shù)目煽啃浴Ｒ驗橐纛l、視頻碼流比傳統(tǒng)數(shù)據(jù)對實時性要求更高，即使少量的時延，對音頻、視頻播放來說也是無法忍受的，但它們對于少量的包丟失卻不太敏感。所以本文在IP網(wǎng)絡(luò)上建立的實時音頻傳輸系統(tǒng)采用面向無連接的UDP協(xié)議進行傳輸。但是UDP傳輸?shù)牟豢煽繋韥G包、亂序等問題，所以如果在應用層采用合適的封裝方式并增加一些有利于媒體播放的信息進行傳輸，可以使得接收端在一定程度上彌補傳輸帶來的損失，這就是引入RTP的原因。同時如果收發(fā)端能夠?qū)崟r了解網(wǎng)絡(luò)和傳輸狀況，就可以適當調(diào)節(jié)自己的任務，最終使得在接收端能夠達到最好的效果，由此引入RTCP傳輸控制協(xié)議對傳輸狀況進行實時監(jiān)測和報告。RTP（Rea

21、l-time Transport Protocol）實時傳輸協(xié)議，是由Internet工程任務組（IETF）的音頻/視頻傳輸工作組制定，主要用于VoIP、視頻等實時多媒體信息的傳輸。音頻和視頻編碼信數(shù)據(jù)均封裝在RTP協(xié)議數(shù)據(jù)包中，RTP提供定時信息和數(shù)據(jù)報序號，供接收方重組數(shù)據(jù)包，但是RTP本省并不能為按順序傳送數(shù)據(jù)包提供可靠的傳輸機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。通常RTP算法并不作為一個獨立的網(wǎng)絡(luò)層來實現(xiàn)，而是作為應用程序代碼的一部分。RTCP（Real-time Transport Control Protocol）實時傳輸控制協(xié)議，它提供服務質(zhì)量的統(tǒng)計信息及

22、提供傳輸可靠性的保證和流量的擁塞控制機制。第二章 RTP/RTCP協(xié)議介紹2.1 實時傳輸協(xié)議的簡單介紹RTP全名是Real-time Transport Protocol（實時傳輸協(xié)議）。它是IETF提出的一個標準，對應的RFC文檔為RFC3550（RFC1889為其過期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關(guān)協(xié)議RTCP（Real-time Transport Control Protocol，即實時傳輸控制協(xié)議）。RTP協(xié)議包括RTP（Real-time Transport Protocol）實時傳輸協(xié)議和RTCP（Real-time Transport Contro

23、l Protocol）實時傳輸控制協(xié)議這兩個協(xié)議。其中RTP被定義為一對一或一對多的傳輸情況下工作，實現(xiàn)實時數(shù)據(jù)的傳輸，但是它并不提供任何傳輸可靠性的保證和流量的擁塞控制機制，這些工作將由RTCP來完成。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，所以特別適合傳輸實時數(shù)據(jù)。RTP為交互式 音頻、視頻等具有實時特性的數(shù)據(jù)提供端到端的傳輸。它不是典型意義上的傳輸層協(xié)議，因為它并不具備一個典型傳輸協(xié)議的所有特點。例如：RTP沒有連接的概念，它必須建立在底層的面向連接的或無連接的傳輸協(xié)議之上；本身不依賴于特別的地址格式，而需要底層傳輸協(xié)議支持成幀和分段。一般來說，RTP是在傳

24、輸層協(xié)議之上作為應用程序的一部分加以實現(xiàn)的。在IP網(wǎng)絡(luò)上，RTP協(xié)議一般是運行在UDP之上。首先RTP可以利用UDP的多路復用功能來分別傳輸RTP數(shù)據(jù)包和RTCP控制包。其次，RTCP能實時監(jiān)控數(shù)據(jù)傳輸和服務質(zhì)量，不需要下層協(xié)議來保證實時業(yè)務的服務質(zhì)量。再次，由于UDP的傳輸時延低于TCP，能與音頻和視頻流很好匹配，保證了實時性的要求。因此，在實際應用中，RTP/RTCP/UDP用于音頻、視頻媒體，而TCP用于數(shù)據(jù)和控制信令的傳輸。當然，RTP還可以和其他合適的底層網(wǎng)絡(luò)和傳輸協(xié)議一起工作。例如它也可以在TCP或ATM等其它協(xié)議之上工作。如果底層網(wǎng)絡(luò)支持多點傳播的話，RTP還支持使用多點傳播向多

25、個目的端點發(fā)送數(shù)據(jù)。下圖表示了RTP與各種網(wǎng)絡(luò)協(xié)議的關(guān)系。 2.1 RTP與各種網(wǎng)絡(luò)協(xié)議的關(guān)系2.2 RTP協(xié)議的三類主要應用（1）簡單的多播音頻會議這里的多播主要指IP網(wǎng)絡(luò)的多播業(yè)務用于語音通信。它通過一個多播地址和一對端口來實現(xiàn)。一個端口用于RTP傳輸音頻數(shù)據(jù)，另一個端口用于傳輸RTCP控制包。這個地址和端口的信息要發(fā)布給各個與會者。當一個與會者將要發(fā)言時，其話音將以每20毫秒為一幀的間隔分成許多音頻數(shù)據(jù)包，并在數(shù)據(jù)包前加上RTP頭，然后按照RTP包頭在前，數(shù)據(jù)在后的順序?qū)⑺鼈兎庋b在UDP包中。RTP包頭可以指明語音編程類型（如PCM，ADPCM或LPC），以便發(fā)送方在會議過程中改變編碼的

26、類型了。Ineternet和其他報文網(wǎng)絡(luò)一樣，會有丟包，報文失序以及報文的不同時延問題。為了克服這些不利因素，RTP包頭攜帶時間戳和序列號，這樣接收方就可以重建源產(chǎn)生的計時信息，語音報文可以按照20毫秒的間隔連續(xù)回放了。其計時信息是接收方按照會議中不同的RTP源分別重建的。同時，接收方也可以利用序列號來估算包丟失數(shù)。與會者在會議進行期間可能加入或退出，因此了解在某一時刻有哪些人參加了會議，以及它們的語音數(shù)據(jù)接收情況是很有必要的。因此每個與會者的應用程序都周期性地廣播含有自己名字的RTCP接收報告。RTCP接收報告表明了這一與會者接收語音數(shù)據(jù)的效果，同時它可以用來控制自適應編碼器。另外，用戶也可

27、以使用名字以外的其它表示信息，這要視控制帶寬的情況而定。一個與會者離開會議時要發(fā)送RTCP BYE報文，以通知其它的參與者自己離開了。（2）音頻和視頻會議如果在一個會議里同時有音頻和視頻，它們將采用獨立的RTP會話來傳送，兩個媒體流的RTCP報文采用不同的UDP端口對或多播地址。在RTP層音頻和視頻并沒有直接的聯(lián)系，除非某個特定的用戶需要在RTCP報文中使用相同的標識將這兩個RTP會話聯(lián)系起來。音頻和視頻采用獨立的RTP會話的原因之一是可以允許部分與會者根據(jù)需要只接收者音頻或視頻流。盡管采用獨立的RTP會話，同源的音頻和視頻可以根據(jù)RTCP的時間信息進行同步回放。（3）混合器和轉(zhuǎn)換器當某一與會

28、者采用低速鏈路接入會議，而大部分與會者采用高速鏈路接入，如果讓每個與會者使用窄帶，低質(zhì)量的語音編碼器，這顯然不是一個很好的解決辦法，這時就需要使用“混合器”。混合器（Mixer）是一個RTP層的中繼設(shè)備，將它置于低速鏈路端，它對到來的音頻報文按20毫秒的間隔重新進行同步，然后將重構(gòu)的音頻數(shù)據(jù)流混合成一路窄帶的數(shù)據(jù)流轉(zhuǎn)發(fā)給窄帶用戶。這些新的報文可以按照單播或多播的形式發(fā)送給接收者。RTP包頭提供了一個字段CSRC，使混合器可以辨別混合報文的各個信源，這樣在接收端就可以正確獲知誰是發(fā)送者。“轉(zhuǎn)換器”（Translators）也是一種RTP層的中繼設(shè)備，當某些與會者不能通過多播（multicast）

29、方式直接連接到會與，比如它們處在不讓任何IP包通過的應用級防火墻之后，這時就需要用到“轉(zhuǎn)換器”。在防火墻內(nèi)外各安裝一個轉(zhuǎn)換器，當外面的轉(zhuǎn)換器接收到安全的數(shù)據(jù)包后，將它們以隧道方式直接發(fā)送給防火墻內(nèi)的轉(zhuǎn)換器，由它轉(zhuǎn)發(fā)給防火墻內(nèi)的用戶。混合器和轉(zhuǎn)換器可以針對很多不同的目的而設(shè)計。比如視頻混合器，它可以將多路不同的視頻流的單個圖像混合成一路視頻流，模擬一個群體場景。轉(zhuǎn)換器的一個應用例子是連接一些只能使用IP/UDP的主機和只能使用ST-II主機，或者對單個信源的視頻流進行逐包的編碼翻譯，而不作重新同步或混合。2.3 RTP數(shù)據(jù)包格式231 RTP數(shù)據(jù)包格式RTP報文頭格式（見RFC3550 Page

30、12）： 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

31、-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+以上域具體意義如下： （1）版本(V):2比特 此域定義了RTP的版本.此協(xié)議定義的版本是2.(值1被RTP

32、草案版本使用,值0用在最初"vat"語音工具使用的協(xié)議中.) （2）填料(P):1比特 若填料比特被設(shè)置,此包包含一到多個附加在末端的填充比特,不是負載的一部分.填料的最后一個字節(jié)包含可以忽略多少個填充比特.填料可能用于某些具有固定長度的加密算法,或者在底層數(shù)據(jù)單元中傳輸多個RTP包. （3）擴展(X):1比特 若設(shè)置擴展比特,固定頭(僅)后面跟隨一個頭擴展. （4）CSRC計數(shù)(CC):4比特 CSRC計數(shù)包含了跟在固定頭后面CSRC識別符的數(shù)目. （5）標志(M):1比特 標志的解釋由具體協(xié)議規(guī)定.它用來允許在比特流中標記重要的事件,如幀范圍.規(guī)定該標志在靜音后的第一個

33、語音包時置位. （6）負載類型(PT):7比特 此域定義了負載的格式,由具體應用決定其解釋.協(xié)議可以規(guī)定負載類型碼和負載格式之間一個默認的匹配.其他的負載類型碼可以通過非RTP方法動態(tài)定義.RTP發(fā)射機在任意給定時間發(fā)出一個單獨的RTP負載類型;此域不用來復用不同的媒體流. （7）序列號（sequence number）:16比特 每發(fā)送一個RTP數(shù)據(jù)包,序列號加一,接收機可以據(jù)此檢測包損和重建包序列.序列號的初始值是隨機的(不可預測),以使即便在源本身不加密時(有時包要通過翻譯器,它會這樣做),對加密算法泛知的普通文本攻擊也會更加困難. （8）時間標志（timestamp）:32比特 時間標

34、志反映了RTP數(shù)據(jù)包中第一個比特的抽樣瞬間.抽樣瞬間必須由隨時間單調(diào)和線形增長的時鐘得到,以進行同步和抖動計算.時鐘的分辨率必須滿足要求的同步準確度,足以進行包到達抖動測量.時鐘頻率與作為負載傳輸?shù)臄?shù)據(jù)格式獨立,在協(xié)議中或定義此格式的負載類型說明中靜態(tài)定義,也可以在通過非RTP方法定義的負載格式中動態(tài)說明.若RTP包周期性生成,可以使用由抽樣時鐘確定的額定抽樣瞬間,而不是讀系統(tǒng)時鐘.例如,對于固定速率語音,時間標志鐘可以每個抽樣周期加1.若語音設(shè)備從輸入設(shè)備讀取覆蓋160個抽樣周期的數(shù)據(jù)塊,對于每個這樣的數(shù)據(jù)塊,時間標志增加160,無論此塊被發(fā)送還是被靜音壓縮. 時間標志的起始值是隨機的,如同

35、序列號.多個連續(xù)的RTP包可能由同樣的時間標志,若他們在邏輯上同時產(chǎn)生.如屬于同一個圖象幀.若數(shù)據(jù)沒有按照抽樣的 順序發(fā)送,連續(xù)的RTP包可以包含不單調(diào)的時間標志,如MPEG交織圖象幀. （9）同步源（SSRC）:32比特 SSRC域用以識別同步源.標識符被隨機生成,以使在同一個RTP會話期中沒有任何兩個同步源有相同的SSRC識別符.盡管多個源選擇同一個SSRC識別符的概率很低,所有RTP實現(xiàn)工具都必須準備檢測和解決沖突.若一個源改變本身的源傳輸?shù)刂?必須選擇新的SSRC識別符,以避免被當作一個環(huán)路源. （10）有貢獻源（CSRC）列表:0到15項,每項32比特 CSRC列表識別在此包中負載的

36、有貢獻源.識別符的數(shù)目在CC域中給定.若有貢獻源多于15個,僅識別15個.CSRC識別符由混合器插入,用有貢獻源的SSRC識別符.例如語音包,混合產(chǎn)生新包的所有源的SSRC標識符都被陳列,以期在接收機處正確指示交談者.注意：前12個字節(jié)出現(xiàn)在每個RTP包中,僅僅在被混合器插入時,才出現(xiàn)CSRC識別符列表.RTP報文擴展頭格式（見RFC3550 Page18）： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

37、+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | . |若RTP頭中的擴展比特位X置1,則一個長度可變的頭擴展部分被加到RTP固定頭之后,頭擴展包含16比特的長度域,指示擴展項中32比特字的個數(shù),不包括4個字節(jié)擴展頭(因此零是有效值).RTP固定頭之后只允許有一個頭擴展.為允許多個互操作實現(xiàn)獨立生成不同的頭擴展,或某種特定實現(xiàn)有多種不同的頭擴展,擴展項的前16比特用

38、以識別標識符或參數(shù).這16比特的格式由具體實現(xiàn)的上層協(xié)議定義.基本的RTP說明并不定義任何頭擴展本身。第三章 實時語音通信系統(tǒng)簡介3.1 系統(tǒng)平臺本系統(tǒng)是在linux下實現(xiàn)的，選用Ubuntu 12.04作為軟件的實現(xiàn)平臺，vim作為編寫工具，編程語言采用C+。在linux平臺上，音頻采集采用ALSA（Advanced Linux Sound Architecture ）的lib庫，利用網(wǎng)上現(xiàn)有的oRTP庫實現(xiàn)基于RTP的實時語音傳輸。Linux是一位芬蘭的年輕人Linus Benedict Torvalds于1991年10月在赫爾辛基大學對外正式發(fā)布一套操作系統(tǒng)，它一種Unix風格的操作系統(tǒng)

39、，在源代碼級上兼容絕大部分Unix標準，是一個支持多用戶、多進程、多線程、功能強大而且執(zhí)行穩(wěn)定的操作系統(tǒng)。非常重要的一點，Linux還是一種開放、免費的操作系統(tǒng)，還具有可移植性和自由代碼等特性，這是其它操作系統(tǒng)所無法比擬的。目前Linux已經(jīng)得到了越來越多的應用。3.2 系統(tǒng)實現(xiàn)的基本原理和框架結(jié)構(gòu)本系統(tǒng)主要實現(xiàn)音頻數(shù)據(jù)的實時傳輸通話。采用在計算機以太網(wǎng)上進行點對點的通信模式。具體的過程是：上層通過麥克風采集音頻數(shù)據(jù)，然后采用G729a進行音頻壓縮，發(fā)送方RTP協(xié)議從上層接收音頻數(shù)據(jù)（這里采用PCM編碼），封裝成RTP數(shù)據(jù)包發(fā)送給下層協(xié)議UDP，UDP提供RTP和RTCP的分流，RTP使用一個

40、偶數(shù)號端口，相應的RTCP使用其后的奇數(shù)號端口。接收方則對網(wǎng)絡(luò)層傳來的數(shù)據(jù)包解封，并交由RTP提取音頻數(shù)據(jù)，然后進行音頻解壓縮，再經(jīng)揚聲器播放出來。下面圖3.1是本系統(tǒng)的基本框架流程圖：實時語音通信模塊實現(xiàn)過程見下圖3.1：圖3.1 基本框架流程圖本系統(tǒng)核心模塊是語音通話模塊的實現(xiàn)，下面是語音通話模塊的流程圖：3.2語音通話模塊的流程圖第四章 linux音頻編程4.1 音頻編程簡介音頻信號是一種連續(xù)變化的模擬信號，但計算機只能處理和記錄二進制的數(shù)字信號，由自然音源得到的音頻信號必須經(jīng)過一定的變換，成為數(shù)字音頻信號之后，才能送到計算機中作進一步的處理。數(shù)字音頻系統(tǒng)通過將聲波的波型轉(zhuǎn)換成一系列二進

41、制數(shù)據(jù)，來實現(xiàn)對原始聲音的現(xiàn)，實現(xiàn)這一步驟的設(shè)備常被稱為模/數(shù)轉(zhuǎn)換器（A/D）。A/D轉(zhuǎn)換器以每秒鐘上萬次的速率對聲波進行采樣，每個采樣點都記錄下了原始模擬聲波在某一時刻的狀態(tài)，通常稱之為樣本sample），而每一秒鐘所采樣的數(shù)目則稱為采樣頻率，通過將一串連續(xù)的樣本連接起來，就可以在計算機中描述一段聲音了。對于采樣過程中的每一個樣本來說，數(shù)字音頻系統(tǒng)會分配一定存儲位來記錄聲波的振幅，一般稱之為采樣分辯率或者采樣精度，采樣精度越高，聲音還原時就會越細膩。數(shù)字音頻涉及到的概念非常多，對于在Linux下進行音頻編程的程序員來說，最重要的是理解聲音數(shù)字化的兩個關(guān)鍵步驟：采樣和量化。采樣就是每隔一定時間

42、就讀一次聲音信號的幅度，而量化則是將采樣得到的聲音信號幅度轉(zhuǎn)換為數(shù)字值，從本質(zhì)上講，采樣是時間上的數(shù)字化，而量化則是幅度上的數(shù)字化。下面介紹幾個在進行音頻編程時經(jīng)常需要用到的技術(shù)指標：（1）.采樣頻率采樣頻率是指將模擬聲音波形進行數(shù)字化時，每秒鐘抽取聲波幅度樣本的次數(shù)。采樣頻率的選擇應該遵循奈奎斯特（Harry Nyquist）采樣理論：如果對某一模擬信號進行采樣，則采樣后可還原的最高信號頻率只有采樣頻率的一半，或者說只要采樣頻率高于輸入信號最高頻率的兩倍，就能從采樣信號系列重構(gòu)原始信號。正常人聽覺的頻率范圍大約在20Hz20kHz之間，根據(jù)奈奎斯特采樣理論，為了保證聲音不失真，采樣頻率應該在

43、40kHz左右。常用的音頻采樣頻率有8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz等，如果采用更高的采樣頻率，還可以達到DVD的音質(zhì)。（2）.采樣的位數(shù)采樣位數(shù)可以理解為采 集卡處理聲音的解析度。這個數(shù)值越大，解析度就越高，錄制和回放的聲音就越真實。我們首先要知道：電腦中的聲音文件是用數(shù)字0和1來 表示的。所以在電腦上錄音的本質(zhì)就是把模擬聲音信號轉(zhuǎn)換成數(shù)字信號。反之，在播放時則是把數(shù)字信號還原成模擬聲音信號輸出。采集卡的位是指采集卡在采集和 播放聲音文件時所使用數(shù)字聲音信號的二進制位數(shù)。采集卡的位客觀地反映了數(shù)字聲音信號對輸入聲音信號描述

44、的準確程度。8位代表2的8次方-256，16 位則代表2的16次方-64K。比較一下，一段相同的音樂信息，16位聲卡能把它分為64K個精度單位進行處理，而8位聲卡只能處理256個精度單位， 造成了較大的信號損失，最終的采樣效果自然是無法相提并論的。常用的采樣位數(shù)有8位、12位和16位。采樣位數(shù)越高，信號的動態(tài)范圍越大，數(shù)字化后的音頻信號就越可能接近原始信號，但所需要的存貯空間也越大。 （3）.聲道數(shù)聲道數(shù)是反映音頻數(shù)字化質(zhì)量的另一個重要因素，它有單聲道和雙聲道之分。雙聲道又稱為立體聲，在硬件中有兩條線路，音質(zhì)和音色都要優(yōu)于單聲道，但數(shù)字化后占據(jù)的存儲空間的大小要比單聲道多一倍。出于對安全性方面

45、的考慮，Linux下的應用程序無法直接對聲卡這類硬件設(shè)備進行操作，而是必須通過內(nèi)核提供的驅(qū)動程序才能完成。在Linux上進行音頻編程的本質(zhì)就是要借助于驅(qū)動程序，來完成對聲卡的各種操作。目前Linux 有三個主流的聲卡驅(qū)動程序集：OSS/Lite（也稱為OSS/Free）、OSS/Full（商業(yè)軟件）、ALSA（自由軟件）。OSS/Lite 是現(xiàn)在linux內(nèi)核中自帶的聲卡驅(qū)動程序集，最初由 Hannu Savolainen開發(fā)。后來 Hannu 跑去開發(fā) Open Sound System（也就是上面所說的OSS/Full）。由于 Hannu 的“逃跑”，RH 資助 Alan Cox 增強 H

46、annu 開發(fā)的驅(qū)動程序，并使它們完全模塊化。現(xiàn)在 Alan Cox 是內(nèi)核聲卡驅(qū)程集的維護人。OSS/Lite 從kernel-2.0開始并入內(nèi)核，現(xiàn)在大家使用的聲卡驅(qū)程默認都是OSS/Lite中的。 OSS/Full 是由 4Front Technologies 開發(fā)并銷售的商業(yè)軟件。它可以驅(qū)動很多聲卡并且可以用在很多 UNIX 系統(tǒng)中。OSS/Full 完全兼容以前基于 OSSLite 開發(fā)的應用程序。作為一個商業(yè)軟件，你雖然可以使用它，但是你得不到它的源代碼，并且你必須為此而付錢。 ALSA 標準是一個先進的linux聲音體系。它包含內(nèi)核驅(qū)動集合，API庫和工具對Linux聲音進行支持

47、。ALSA 包含一系列內(nèi)核驅(qū)動對不同的聲卡進行支持，還提供了libasound的API庫。用這些進行寫程序不需要打開設(shè)備等操作，所以編程人員在寫程序的時候不會被底層的東西困擾。與此相反OSS/Free 驅(qū)動在內(nèi)核層次調(diào)用，需要指定設(shè)備名和調(diào)用ioctl。為提供向后兼容， ALSA 提供內(nèi)核模塊模仿 OSS/Free 驅(qū)動，所以大多數(shù)的程序不需要改動。 ALSA 擁有調(diào)用插件的能力對新設(shè)備提供擴展，包括那些用軟件模擬出來的虛擬設(shè)備。 ALSA 還提供一組命令行工具包括 mixer, sound file player 和工具控制一些特別的聲卡的特別的作用。4.2 ALSA音頻編程4.2.1 AL

48、SA庫的安裝在linux終端下執(zhí)行：$ sudo apt-get install libasound2-dev安裝完畢！4.2.2 音頻數(shù)據(jù)的采集和播放的實現(xiàn)一個典型的音頻程序應該具有以下結(jié)構(gòu)：（1）打開音頻設(shè)備（2）為設(shè)備設(shè)置參數(shù)（主要參數(shù)有三個：采樣率、采樣位數(shù)、通道數(shù)）（3）向音頻設(shè)備讀/寫音頻數(shù)據(jù)（4）關(guān)閉設(shè)備Alsa庫為我們實現(xiàn)這些操作提供了豐富的接口，我們利用Alsa接口把語音的采集和播放封裝成一個類class CWavPlayer，下面是class CWavPlayer的部分代碼：class CWavPlayerpublic:CWavPlayer(uint32_t sample_

49、rate = 8000, uint16_t bit_per_sample = 16, uint16_t channels = 2);/構(gòu)造函數(shù)CWavPlayer(CWavPlayer &other);CWavPlayer();public:void wav_play(int fd);/音頻播放void read_wav_header(int fd);void write_wav_header(int fd, int dtime = 20);uint32_t snd_read_pcm(uint32_t rcount, char *wave_buf);void open_pcm_devi

50、ces(snd_pcm_stream_t mode = SND_PCM_STREAM_PLAYBACK);/打開音頻設(shè)備void wav_record(uint16_t dtimes, int fd); /采集音頻數(shù)據(jù)void prepare_wav_params(const int dtime);void print_wav() const; /print the params of wav structvoid set_pcm_params();/設(shè)置設(shè)備參數(shù)void alsa_record(char *sendBuffer);void set_pcm_mixer(); /設(shè)置混音器CWa

51、vPlayer &operator=(CWavPlayer &other);public:uint32_t get_chunk_byte() const return chunk_byte;snd_pcm_t *get_handle() const return handle;snd_pcm_uframes_t get_period_size() const return period_size;private:uint32_t sample_rate;/采樣率uint16_t bit_per_sample;/采樣位數(shù)uint16_t channels;/聲道uint32_t

52、chunk_byte; /周期長度（bytes）uint32_t bit_per_frame;/幀大小snd_pcm_t *handle;/設(shè)備句柄snd_pcm_uframes_t period_size;/周期WAVHeader_t *wav;/the point of struct;下面介紹一下系統(tǒng)中語音的采集部分的實現(xiàn)。1.首先讓我們封裝一個打開音頻設(shè)備的函數(shù)：void CWavPlayer:open_pcm_devices(snd_pcm_stream_t mode)int rc;if (rc = snd_pcm_open(&handle, "default&quo

53、t;, mode, 0) < 0)std:cerr << "snd_pcm_open:" << std:endl;exit(1);snd_pcm_open是Alsa庫提供的打開設(shè)備調(diào)用函數(shù)，這里我們指定打開缺省的音頻設(shè)備，并根據(jù)參數(shù)mode將設(shè)備置為錄音或是播放狀態(tài)，如果參數(shù)mode是SND_PCM_STREAM_PLAYBACK，則為打開播放設(shè)備；如果參數(shù)mode是SND_PCM_STREAM_CAPTURE，則為打開錄音設(shè)備。如果設(shè)備打開成功，pcm_handle便指向該設(shè)備句柄。2.第二步是設(shè)置參數(shù)，參數(shù)設(shè)置不當將會導致音頻設(shè)備無法正常工

54、作。在設(shè)置參數(shù)前，我們需要了解一下各個參數(shù)的含義以及一些基本概念。（1）樣本長度(sample)：樣本是記錄音頻數(shù)據(jù)最基本的單位，常見的有8位和16位。（2）通道數(shù)(channel)：該參數(shù)為1表示單聲道，2則是立體聲。（3）楨(frame)：楨記錄了一個聲音單元，其長度為樣本長度與通道數(shù)的乘積。（4）采樣率(rate)：每秒鐘采樣次數(shù)，該次數(shù)是針對楨而言。（5）周期(period)：音頻設(shè)備一次處理所需要的楨數(shù)，對于音頻設(shè)備的數(shù)據(jù)訪問以及音頻數(shù)據(jù)的存儲，都是以此為單位。交錯模式(interleaved)：是一種音頻數(shù)據(jù)的記錄方式，在交錯模式下，數(shù)據(jù)以連續(xù)楨的形式存放，即首先記錄完楨1的左聲道

55、樣本和右聲道樣本（假設(shè)為立體聲格式），再開始楨2的記錄。而在非交錯模式下，首先記錄的是一個周期內(nèi)所有楨的左聲道樣本，再記錄右聲道樣本，數(shù)據(jù)是以連續(xù)通道的方式存儲。不過多數(shù)情況下，我們只需要使用交錯模式就可以了。明白了各參數(shù)含義及關(guān)系后，我們開始設(shè)置參數(shù)：void CWavPlayer:set_pcm_params()snd_pcm_hw_params_t *hw_params;snd_pcm_hw_params_malloc(&hw_params);snd_pcm_hw_params_any(handle, hw_params);/設(shè)備初始化snd_pcm_hw_params_set_

56、access(handle, hw_params,SND_PCM_ACCESS_RW_INTERLEAVED);/設(shè)置為交錯模式switch(bit_per_sample/8)/設(shè)置采樣位數(shù)case 1:snd_pcm_hw_params_set_format(handle, hw_params, SND_PCM_FORMAT_U8);break ;case 2:snd_pcm_hw_params_set_format(handle, hw_params, SND_PCM_FORMAT_S16_LE);break ;case 3:snd_pcm_hw_params_set_format(handle, hw_params, SND_PCM_FORMAT_S24_LE);break ;snd_pcm_hw_params_set_channels(handle, hw_params, channels); /設(shè)置通道數(shù)int dir = 0;snd_pcm_hw_params_set_rate_near(handle, hw_params, &sample_ra