首頁 >> 新聞

在Vovida的基礎上實現自己的SIP協(xié)議棧（一）

盧政 2003/08/01

寫在前面的話

　　不少通訊方面的同好已經讀了我在去年歲末撰寫的《如何用OpenH323開發(fā)自己的H.323協(xié)議棧》,大都給予了很高的評價,甚至可以說是好評如潮,說來慚愧,我只不過把十幾個人的工作進行了整理和歸納而已,事實上我自己的代碼只有很少的一部分(主要在H.245/H.235部分),后來很多朋友向我索要RTH323的測試版本一直未果,我在這里說明一下,由于該軟件的使用和二次開發(fā)的權利已經被某歐洲公司所買斷,所以我已經無權發(fā)布測試代碼,如有不便敬請大家原諒.

　　在我們開發(fā)RTH323之際,我已經開始注意SIP協(xié)議了,并且根據RFC2543設計了不少實驗代碼,因為當時的開發(fā)有一個H.323-SIP的翻譯網關的需求,不過后來這個計劃又取消了,也從這個時候開始我逐漸對SIP有了比較濃厚的興趣,只是并沒有做什么實際的工作,僅僅初步了解了一下協(xié)議的整體構造.

　　直到去年年底,我接觸了Vovida的開放原碼的SIP系統(tǒng)--Vocal以后,我決定開始系統(tǒng)的了解SIP的整個構造,我個人認為Vocal是一個非常典型的SIP系統(tǒng),里面包含了所有構造電信級呼叫中心，區(qū)域網關以及中繼網關的所有內容,而且代碼清晰,比較易于改造；于是我花費了大概6個月的時間閱讀了整個Vocal系統(tǒng)的代碼,并在很多重要的地方做了標注.正好在今年的5月份,我的公司有構造一個大型的Voice/Video IP企業(yè)呼叫中心的計劃,我就把我對Vocal的研究成果提交給公司,方案得到通過,現在我的公司正在和國內某個知名大學合作準備在現有Vocal基礎上改造一個企業(yè)級的視頻電話呼叫平臺

　　不過我個人而言,對這個計劃不是非常的滿意,由于時間和金錢上的限制,大部分的電訊級補充服務第一階段沒有實現的,只可能在第二階段去實現該計劃,時間可能要持續(xù)很長,所以我也很希望有其他的開發(fā)公司參與完成這個方面的開發(fā),當然我們也可以為有興趣的公司提供技術咨詢或者展開合作。

　　我寫這本文的目的在于公布我個人對Vocal這個開放原代碼系統(tǒng)的一些研究成果,當然里面有很多地方沒有說得非常清楚,本身要用文字來闡述程序的設計思想就是一個非常困難的事情,所以我在里面大量的繪制了很多圖表,來幫助讀者閱讀本文,這次公布的是有關UA端的內容,后續(xù)在本文中將介紹Vocal系統(tǒng)中的Provision Server; Marshal Server; Redirect Server; HeartBeat Server:Policy Server:CDR Server:Network Manager:Feature Server:以及各種協(xié)議的Translator,讀者需要具備對SIP,H.323,MGCP,QoS的基本了解,以及對Java,XML, Call Processing Language，C++的知識，在以下章節(jié)中不會對這些基本的知識做太詳細的介紹。

　　預計本文全部刊登完畢大概需近一年的時間，我希望有軟件開發(fā)公司來和我合作完成這篇文章或者是共同從事Vocal系統(tǒng)的二次開發(fā)工作。

　　從這半年的閱讀Vocal的過程中我體會到Vocal系統(tǒng)的商業(yè)應用價值非常大，有人在論壇上和我討論：改造別人的應用平臺的難度和重新開發(fā)一個應用的難度哪個更大，雙方都各置一詞，就我個人覺得，大型的商業(yè)軟件如果按照開放原代碼來進行改造，特別是一些基礎平臺（例如操作系統(tǒng)），速度肯定是比從零開始要快很多的，RTH323就是一個成功的范例，這也是國內很多軟件廠商的基本運行模式，特別對于一些人員，技術，資金都不是非常充裕的公司這可能也是唯一的方案，但是開放原代碼的軟件大部分的效率非常低下，而且代碼冗余，注釋比較少，可讀性非常差，甚至還有一些致命錯誤（Vocal中的Feature Server中就有這樣的錯誤，往往可以造成系統(tǒng)崩潰）所以這樣做的前提條件就是能把握住工作的重點，能及時發(fā)現并排除問題，這樣才可能把開放原代碼改造成高效率的商業(yè)應用。

目 錄

一．楔子
二．H.323和SIP之間的差異
三．本文的主要內容
1．User Agent的簡介
2．UA部分主要程序部分的介紹
2．1 主程序：\SIP\UA\UA.cxx
2．2 創(chuàng)建一個User Agent的實體
2. 3 HeartLessProxy的創(chuàng)建
2．4 讓User Agent Run起來
2. 5 HeartLessProxy Run方法的實現
2. 5. 1 WorkerThread的Run方法
2.5.1.1 processSipEvent
2. 5. 1. 2 processUaDeviceEvent
2.5.1.3 processUaDigitEvent
2. 5. 2 SipThread的Run方法
2. 6 在User Agent中的四個重要實例的Run方法
2. 6. 1 媒體設備啟動
2.6.2 啟動RTP線程，用于對RTP/RTCP包的接收和發(fā)送管理；
2. 6. 3 合法用戶列表的獲取(Redirection Server專用)
2. 6. 4 監(jiān)測線程：
2. 6. 5 自動呼叫
3.開始一個呼叫和等待對方呼叫：
3. 1 系統(tǒng)創(chuàng)建StateIdle狀態(tài)：
3. 2 開始一個呼叫：
3. 2. 1 OpStartCall主程序部分：
3. 2. 2 取得鍵盤的事件
3. 2. 3 狀態(tài)機（State）對各個操作（Operator）的處理過程：
3. 2. 4 開始一個呼叫所經歷的各種操作（Operator）
3. 2. 5 如何進入待機狀態(tài)(Idle狀態(tài))
3. 2. 6 如何開始撥號并且開始一個呼叫：
3. 2. 6. 1 OpStartDialTone本地發(fā)送撥號音；
3. 2. 6. 2 OpAddDigit輸入電話號碼開始撥號：
3. 2. 6. 3 OpStopDialTone；
3. 2. 6. 4 OpInviteUrl建立一個INVITE消息并且發(fā)送到被叫；
3.2.7 進入Trying狀態(tài)
3. 2. 7. 1 OpStartTimer啟動每個事件的定時器：
3. 2. 7. 2 掛機事件的檢測機制
3. 2. 7. 3 OpStartRingbackTone向被叫進行鈴聲回放。
3.2.7.4 OpReDirect進行重定向服務的操作
3.2.7.5 授權檢查
3.2.7.6 OpFarEndAnswered處理接收到的OK回應
3.2.7.7 在Vocal中如何實現RSVP資源預留協(xié)議
3.2.8用戶處于通話的StateInCall狀態(tài)：
3. 2. 8. 1 OpStartAudioDuplex主叫打開RTP通道
3. 2. 8. 2 處理RTP/RTCP包:
3.2.8.3 ACK消息的處理過程OpAck
3. 2. 8. 4 OpConfTargetOk多方會議檢測：
3.2.9 呼叫等待
3. 2. 9. 1 呼叫等待的詳細描述：
3. 2. 9. 2 操作之間存在的競爭
3. 2. 9. 3 呼叫中所涉及模塊介紹
3.3 等待對方的呼叫
3.3.1 OpRing等待對方的振鈴消息
3. 3. 2 OpStartRinging開始響鈴
3. 3. 3 OpRingingInvite處理又一個INVITE消息（呼叫等待）
3. 3. 4 OpAnswerCall被叫打開媒體通道開始通訊
3.3.5 回到StateInCall狀態(tài)
4.如何在改造現有的終端使之能傳遞視頻流。
4.1一個H.261+的Codec的基本構造
4. 2 增加視頻能力所需要做的工作

一．引言

　　在各種的IP網絡多媒體通訊協(xié)議中，當前在市場上占據主流位置的應當算是ITU的H.323和IETF的SIP兩個協(xié)議，目前在單純的話音市場，MGCP協(xié)議由于有大規(guī)模的用戶擴容能力應用也正呈現上升的趨勢，在2000年以前市場上占主流的主要是H.323協(xié)議，然而SIP協(xié)議由于它避免了復雜的原語(ASN.1)分析，它的應用也在2000年以后也得到高速的普及，甚至有超過H.323的趨勢，成為H.323最有力的競爭對手，當然，由于SIP協(xié)議的一些固有缺陷（下面將會詳細介紹這些缺陷），這種情況在未來的幾年可能不會出現，不過對于中等規(guī)模的多媒體通訊業(yè)務（每小時接入60000門）應用而言，采用SIP不失為一個方便，快捷的開發(fā)策略。

　　在各種的VOIP開放原碼的開發(fā)項目中，Vovida的基于SIP協(xié)議的VoCAL（Vovida Open CommunucAtion Library）不僅僅是在基于SIP的開放原代碼協(xié)議棧中是最為龐大而且完善的，甚至在所有的原碼開放的多媒體通訊協(xié)議棧中同樣也是完善而且全面的，目前發(fā)布的VOCAL1.4.0主要支持RFC2543，據稱在新版本的Vocal1.5.0將支持RFC3261協(xié)議；Vocal提供了基本的SIP呼叫控制和切換，例如：用戶注冊和登記，呼叫初始化，修改呼叫特性，或者重新定義呼叫特性，終止呼叫；以及一些用戶的基本呼叫特性：例如呼叫前轉，呼叫等待，呼叫阻塞，呼叫轉移，語音郵件等等。

　　對于一個Vocal系統(tǒng)的用戶而言，Vocal同樣為其提供了以下的一些能力：

1． 通過Web來配置整個Vocal系統(tǒng)；
2． 使用SNMP網管來檢測整個系統(tǒng)和呼叫組網的狀態(tài)；
3． 可以定義一個用戶的呼叫特性列表（相當于H.323系列中的H.450補充協(xié)議部分）；
4． 授權檢查；
5． 廣告信息；
6． 基于RSVP的簡單QoS保證。

　　同時，VOCAL也提供了詳細的文檔和SDK包以給用戶做二次開發(fā)，用戶可以在C++，以及Call Processing Language(CPL)，Java Telephony API上開發(fā)自己的應用。

二．H.323和SIP之間的差異：

　　這一節(jié)和本文的內容似乎沒有太大的關系，不過筆者認為作為市場主流的H.323和SIP之間需要做一個相關性的比較，以免使很多讀者在選擇協(xié)議的時候陷入歧途。

　　雖然Vocal在SIP的應用上已經可以算是一個成功的實例，所以目前單純以Vocal作為主體開發(fā)SIP的多媒體通訊系統(tǒng)從理論上是可行的，但是事實上目前所有的VOIP商業(yè)系統(tǒng)都是以H.323為主體，兼容SIP協(xié)議，似乎還沒有一個廠商在實際上支持SIP（Cisco好象有類似的產品，不過應用前景似乎不是非常明朗），首先從市場上來看，H.323的系統(tǒng)已經有大量的投資，應用也非常普遍，SIP相對比較新，似乎不夠成熟；從市場上來看，越來越多的附加服務將成為應用的主流，SIP領域相對來說比H.323能夠提供更多，更靈活的服務，而且在信令的互通性上有更加多的優(yōu)勢，當然H.323也能夠保證其他解決方案之間的互用性；但是，目前MGCP協(xié)議已經得到了大量的工業(yè)支持，簡單的終端和更加復雜完善的呼叫控制方式讓它得到了更多的應用，很可能會成為SIP的潛在競爭者。

　　其次我們從ITU和IETF的條款保證上來看，IETF所制定的草案一開始都闡述一個讓人失望的觀點：本草案作為參考資料是不合適的，除非在"制定和完善中"，這樣在協(xié)議成熟和完全理解期間必然會把一些工作引入誤區(qū)，特別是某些協(xié)議被更新和升級期間。相對而言，作為官方實體的ITU制定的協(xié)議一旦實施就不再輕易的改變，因此在發(fā)布協(xié)議前，已經對協(xié)議作了很長時間的互通性測試。

　　最后從技術上來看，SIP和H.323在技術實現上有很大的不同：

　　a．開發(fā)速度：SIP當然的優(yōu)于H.323協(xié)議太簡單了，不過如果H.323原語部分可以比較好的解析的話，事實上兩者開發(fā)速度相差不大。

　　b．多播：在這個方面IETF具有優(yōu)勢，有非常強大的應用經驗的，SIP已經設計在很多多播的骨干網絡上，h.323v1,v2要使用多單播同時進行的方式才能完成，不過H.323V3版本多播的支持就已經非常不錯了。

　　c．地址的運用上SIP使用Url上的機制非常靈活，這樣可以讓SIP以一種非常靈活的方式重定向到非SIP服務器上去，被另外一個SIP呼叫的SIP終端也能重定向到某個網頁或者是電子郵件地址。對于H.323而言，命名的機制就非常混亂了，從ASN.1的文件我們可以看到有h323-ID，url-ID，transport-ID，email-ID，partynumber等等。

　　d．對于SIP而言，所有的消息都采用文本編碼，所以SIP消息非常簡單，這樣在開發(fā)的時候簡單的網絡檢測就可以調試，反觀H.323協(xié)議采用了PER或者BER的二進制編碼方式，信令不是非常直觀。

　　e.系統(tǒng)資源的消耗上，SIP可以說是開銷驚人，每次服務器發(fā)出通告的時候，都需要建立一個監(jiān)聽套接字，這樣的結果勢必造成大量的閑置套接字，假設在建立一個完整的Proxy/Register/RTP Gateway/三者和而為一的園區(qū)出口網關的時候，資源上勢必會非常的緊張，這個是不能不予以考慮的問題。相反H.323在打開邏輯通道的情況下（OpenLogicalChannel消息）只建立一個套接字。

f. SIP沒有會議控制能力，所以僅僅只能做到點對點的媒體通訊，而H.323一開始就考慮了會議功能，其中還包含了H.332會議控制協(xié)議。（Vocal提供了一個Conferencing Server可以做普通的會議控制）。

g. 基于無線的網絡而言，H.323有很大優(yōu)勢，由于信令采用了二進制編碼，所以比較適合手持設備實現，而SIP由于采用了文本方式就沒有這樣的能力。

三．本文的主要內容

　　和RTH323的介紹一樣，我在下面將會盡量詳細的分析一下Vocal的整個原代碼，當然不可能做到完全系統(tǒng)地向大家展示Vocal的精妙之處，其實我自己對這個協(xié)議棧還是有相當多不了解的地方，希望大家能對我們的研究提出寶貴意見，后續(xù)的文章將會以連載的方式對Vocal進行介紹，順序如下：

3.1 Vovida User Agent:
3.2 Vovida Provision Server:
3.3 Marshal Server;
3.4 Redirect Server;
3.5 HeartBeat Server:
3.6 Policy Server:
3.7 CDR Server:
3.8 Network Manager:
3.9 Feature Server:
3.10 Translator Server:

　　我們現在可以開始進入Vovida的第一個實體的介紹--User Agent


(點擊放大）

User Agent

1．User Agent的簡介：
　　User Agent是描述一個普通的用戶終端，用戶代理，以下都簡稱UA端。本身來說UA端的代碼在Linux或者是Windows上都可以編譯運行。在Vocal中資料最詳細是User Agent的介紹了，有關UA描述的所有的代碼部分部分集中在\SIP\UA目錄下面，SIP的Stack軟件主要集中在\SIP\SIPSTACK，SIP消息和狀態(tài)的基類描述主要集中在\SIP\BASE;大家如果對SIP的狀態(tài)和命令不是非常熟悉的話，可以進入\SIP\UA\目錄下瀏覽以下的幾個線圖：

1． UaOverView.gif:
　　對于UA中全部的主要類的關系描述，主要是展現了一些比較重要的基類。
2． UaSimpleStatesComplet.gif
　　UA端的一個簡單的呼叫和應答的全部命令和狀態(tài)的交互示意圖。
3． Ua-States.gif
　　UA狀態(tài)遷移的示意圖。
　　另外在UA中我們會把基本的SIPStack的一些調用做一下詳細的介紹，所以篇幅可能會比較長。

下面是一些所使用到的SIP基本的類的介紹：
　　HeartlessProxy ：創(chuàng)建了一個容納呼叫的"容器"，和SIP的消息堆棧，以及WorkThread和SipThread（用于對SIP消息的隊列處理）,由HeartlessProxy：：Run()方法調用這寫線程的Run方法，使他們啟動。該類的初始化是用一個Builder的基本類對它進行實例化。

　　BasicProxy：由源自HeartlessProxy，它讓系統(tǒng)使用HeartBeat機制，在這個類中創(chuàng)建了三個HeartBeat類型的線程：HeartbeatTxThread，HeartbeatRxThread，HouseKeepingThread，不過暫時在Ua中都沒有應用到，一般是用在HeartBeat Server中（注：HeartBeat的機制就是指在Vocal的Server集群通過多播端口向HeartBeat Server發(fā)送HeartBeat數據報，如果在指定的時間內沒有收到該數據報，那么認為該服務器處于Down狀態(tài)，由HeartbeatServer發(fā)送狀態(tài)消息到SNMP網管，同時啟動備份設備，這個機制類似于BGP,EIGRP協(xié)議中的后備路由方案）。

　　SipThread：SipThread源自ThreadIf（Thread Interface），主要作用是接收并且在sipstack對所收到的SIP消息排隊，并且對接收的SipMsg（SIP消息）產生相應的Sip本地處理事件SipEvent，并且把他們放置在一個Fifo隊列中等待處理，SipThread::thread()是循環(huán)處理的線程。

　　WorkerThread：和SipThread一樣，它也是源自ThreadIf，主要作用在于接受并且列隊處理上面SipThread收到的Sip本地處理事件SipEvent。

　　Builder：是一個基本類，它由WorkerThread調用，在這個類中包含了針對用戶代理的CallContainer（包含所收到的各種呼叫信息）類的指針，從代碼上看Builder在HeartLessProxy/BasicProxy被創(chuàng)建的時候創(chuàng)建。

　　Feature： Feature是一個狀態(tài)(State)容器，用于裝載各種狀態(tài)，從所有的狀態(tài)上來說，Feature是所有State的集合，Feature，State,Operator之間的關系是一種容器包含的關系，在Feature::process()中會調用State::process()來完成各個狀態(tài)的處理，它會返回下一個在容器內要處理的狀態(tài)（Sate）。.

　　State: State是Operator的集合容器， State::process() 調用 Operator::process().和上面所描述的一樣Operator返回在容器內的下一個操作（Operator）。

　　Operator : Operator則是一個基本類，Operator::process() 是一個虛函數，他需要其他的Operator子類對它進行實例化，它實質上也是描述各種操作的一個基本類。

　　SipProxyEvent: 這個是一個基本類，用于描述各種SIP的事件信息，包括各種SIP消息和各種本地的設備消息，同時它包含了SIP消息的輸出隊列指針，使用的時候，可以把他載入輸出的FIFO中。

　　SipEvent: 從SipProxyEvent上繼承，用于描述各種SIP消息，使用中當SipThread收到一個SipMsg的時候創(chuàng)建一個SipEvent，同樣SipEvent也會安裝在輸出的FIFO中（Outputfifo）。

　　DeviceEvnet: 從SipProxyEvent上繼承，用于描述本地設備事件。

　　TimerEvent：從SipProxyEvent上繼承，在設定的時鐘超時的時候產生該事件。

　　CallContainer: 是CallInfo類的容器類。

　　CallInfo: 是一個基本類，用于對呼叫的各種信息的描述集合，任何一個SipProxyEvent都包含了一個CallInfo。

　　CallProcessingQueue: 一個用于裝載各種SipProxyEvent消息的FiFO隊列，在構造HeartLessProxy的它被創(chuàng)建，WorkerThread對他中間的消息進行排隊處理。

　　FeatureThread：被Marshal Server調用用于發(fā)送接受subscribe/Notify消息對，得到合法的用戶的列表和呼叫特性（在后面介紹marshal和Feature Server的時候會詳細介紹）。

　　ResGwDeviece: 所有設備的基本類，用于描述所有的設備，當然它中間的很多屬性需要具體的設備進行實例化。


(點擊放大）

下面介紹一下在UA端所使用到的基本類：

　　UserAgent: 用于描述一個基本的用戶代理，它通過Run方法啟動以后打開了用戶端的RTP通道和設備媒體設備處理進程，并且啟動了HeartlessProxy的Run方法，開始啟動SIP消息處理線程。

　　DeviceThread: 用于處理各種媒體設備，以及輸入輸出設備的線程，將收到的設備消息放在CallProcessingQueue隊列中。

　　RTPThread: 用于處理RTP/RTCP會話。

　　SubScribemanager: 用于MS端發(fā)送subscribe消息到RS端，以及接收Notify消息，處理用戶的呼叫特性列表。

　　UaCallContainer: 繼承CallContainer類，主要在Ua端使用，定義了UA呼叫的各種信息的集合。

　　SipTransceiver: SIP消息的發(fā)送和接收器的描述，包含有一個接收緩沖隊列和發(fā)送緩沖隊列。

　　UaBuilder: Builder類在Ua端的描述，繼承了Builder的各種描述，這個是UA端的一個重要的類，它負責構建各種SIP消息事件，并且在這里包含了UA的注冊和各種狀態(tài)機的初始化和實例化過程。

　　UaConfiguration: CFG文件的描述類。

　　UaCallInfo:屬于CallInfo的子類，包含了UA的各種工作狀態(tài)，可以讓不同狀態(tài)下的所有所有的Call操作（發(fā)送和接收），使用一個相同的狀態(tài)機。

　　RegisterManager:用于跟蹤處理UA端的注冊。

　　LoadGenThread:檢測線程，用于大量的呼叫時候對系統(tǒng)的檢測.


(點擊放大）

　　其實這幾個線圖對UA的描述還是非常粗糙，如果大家對UA端的代碼沒有任何的閱讀的話，看他們是完全看不懂的，這些只能是一些內部開發(fā)人員專用文檔而已，下面我們開始對UA原代碼部分做詳細的介紹：

2．UA部分主要程序部分的介紹：

2．1 主程序：\SIP\UA\UA.cxx
　　主程序部分主要是根據CFG文件中的定義建立本地的呼叫和等待接收進程。

main( int argc, char* argv[] )
{
… …
//是否把當前的UA設置為守護進程。由CFG文件確定。
if ( UaCommandLine::instance()->getBoolOpt( "daemon" ) )
{
// TODO set cpLog to use syslog
assert( Daemon() >= 0 );
}
… …
if (UaCommandLine::instance( ) -> getIntOpt( "retransmit" ))
{
SipTransceiver::reTransOn();
}
else
{
SipTransceiver::reTransOff();
}

if (UaCommandLine::instance()->getIntOpt("retransinitial") != 500 ||
UaCommandLine::instance()->getIntOpt("retransmax") != 4000 )
{
SipTransceiver::setRetransTime(
UaCommandLine::instance()->getIntOpt("retransinitial"),
UaCommandLine::instance()->getIntOpt("retransmax")
);
}
//這里是打開配置文件，我們在這里使用的配置文件暫時定為Ua1001.cfg（以下均相同）
const string cfgStr = UaCommandLine::instance()->getStringOpt( "cfgfile" );
FILE *cfgFile = fopen( cfgStr.c_str(), "r");
if ( cfgFile == 0 )
{
cerr << "can not open " << cfgStr << endl;
cerr << "Usage: " << argv[0] << " " << appUsage << endl;
exit( 0 );
}
else
{
fclose( cfgFile );
UaConfiguration::instance( cfgStr );
}
// if the config file has a log level, do something about it
if(UaConfiguration::instance()->getLogFilename() != "")
{
int retval = cpLogOpen(
UaConfiguration::instance()->getLogFilename().c_str());
if(retval == 0)
{
cpLog(LOG_ALERT, "Could not open %s",
UaConfiguration::instance()->getLogFilename().c_str());
}
}
//創(chuàng)建一個Uabuilder類，它在類狀態(tài)圖中的位置可以參考Uaoverview.gif中它的位置,
Sptr < UaBuilder > uaBuilder = new UaBuilder;
//在這里創(chuàng)建一個用戶代理，我們要確定它在本地的偵聽和發(fā)送的端口，我們同樣從CFG文
//件中得到。
UserAgent ua( uaBuilder, Data( UaConfiguration::instance()->getLocalSipPort() ).convertInt() );
ua.run();
if ( UaCommandLine::instance()->getBoolOpt( "voicemail" ) )
{
//下面的兩個Run我們暫時不定義，在SNMP網管的時候將介紹HearterBeat的時候在做//詳細的闡述（所謂的HeartBeat技術是在多播口上定時發(fā)送heartbeat消息，以通知目前//端點的狀態(tài)，類似于BGP協(xié)議中的Hello消息。
#if defined(HAS_VOICEMAIL)
cpLog( LOG_DEBUG, "UA is running as voicemail front end" );
if( !UaCommandLine::instance()->getBoolOpt("no_heartbeat") )
{
#if defined(HAS_HEARTBEAT)
// Create and start heartbeat transmit thread
Sptr < HeartbeatTxThread > heartbeatThread
= new HeartbeatTxThread(sipPort,
500,
(const char*)"226.2.2.5",
6000);
heartbeatThread->run();
heartbeatThread->join();
#endif
}
#else
cpLog( LOG_ERR, "UA is NOT compiled to run as voicemail front end" );
#endif
}
//加入UA端到本地的運行隊列里面
ua.join();
return 0;
} // ua main()

　　看完了UA的主程序，我們可以看到，目前在UA端的部分的主要工作就是創(chuàng)建一個User Agent的實體UserAgent然后調用Run方法讓它運行，那么我們看一下UserAgent這個關鍵類的一些基本情況：


(點擊放大）

2．2 創(chuàng)建一個User Agent的實體：

　　在創(chuàng)建一個User Agent的實體的同時還有一個非常重要的實體HeartLesProxy，用于處理SIP的各種消息，并且開啟后臺工作線程；它的創(chuàng)建過程我們稍后做詳細介紹。

UserAgent::UserAgent( Sptr uaBuilder, unsigned short sipPort, Data appName )
: HeartLessProxy( uaBuilder, sipPort, appName )
{
const char* useDevice = "NULL"; // default to NULL_HARDWARE
… …
//用什么聲音設備？在這里我們暫時定為Sound Card好了，如果要是用Quicknet來集成
//各種壓縮算法當然更好，不過價格也高了一些，下面都以Sound Card作為標準介紹。
if( UaCommandLine::instance()->getBoolOpt( "soundcard" ) )
{
useDevice = "SOUNDCARD";
}
//LOAD GENERATION是一個檢測線程，可以在屏幕上打印各種命令的往復消息，以及系統(tǒng)的各//種統(tǒng)的狀態(tài)。
if(! UaConfiguration::instance()->getLoadGenOn())
{
// Create devices only if load gen is turned OFF.
//設備實例化，并且向帶入設備名稱以及所要處理的消息隊列，在實例化的過程中會//打開一個聲卡設備，并且將這個聲卡設備綁定兩個輸入的命令，輸出命令的FIFO
//隊列當中，（inputQ，和outputQ）詳細可以參看SoundCardDevice的建構函數，它//闡述了如何綁定這兩個隊列inputQ,outputQ,并且初始化ResGwDevice（所有的聲音//設備的父類）。
UaDevice::instance( useDevice, myCallProcessingQueue );
if( ! (strcmp(useDevice, "NONE") == 0) )
{
cpLog( LOG_DEBUG, "Create RTP Thread" );
//創(chuàng)建一個RTP包處理線程用于對RTP Packet的處理
rtpThread = new RtpThread( UaDevice::instance() );
assert( rtpThread != 0 );
}
//這里調用了sound Card的設備消息處理線程的創(chuàng)立，用于處理與聲卡設備相關的各種消//息.
deviceThread = new DeviceThread( UaDevice::instance() );
assert( deviceThread != 0 );

cpLog( LOG_DEBUG, "Create SubscribeManager" );
Sptr subManager = new SubscribeManager( mySipStack );

if ( UaConfiguration::instance()->getSubscribeOn() )
{
cpLog( LOG_DEBUG, "Create Feature Thread" );
//這里建立一個向FS發(fā)送消息的線程,關于這個部分的內容在Feature //Server的部分再做詳細介紹.
featureThread = new FeatureThread( subManager );
assert( featureThread != 0 );
uaBuilder->setSubscribeManager( subManager );
}
}
else
{
… …
}

// 是否打開重傳機制？
if (UaCommandLine::instance( ) -> getBoolOpt( "retransmit" ) )
{
SipTransceiver::reTransOn();
}
else
{
SipTransceiver::reTransOff();
}

// 定義接收代理服務器（Proxy）發(fā)出的消息所儲存的容器
myCallContainer = new UaCallContainer;
assert( myCallContainer != 0 );
//綁定容器到用戶端
uaBuilder->setCallContainer( myCallContainer );
//設置SIP的消息堆棧
uaBuilder->setSipStack( mySipStack );
//開始向注冊服務器發(fā)送注冊（Register）消息。
uaBuilder->startRegistration();
}
2．3 HeartLessProxy的創(chuàng)建：
HeartLessProxy
(
const Sptr < Builder > builder,
unsigned short defaultSipPort,
Data applName,
bool filterOn,
bool nat,
SipAppContext aContext
)
{
myCallContainer = new CallContainer;

myBuilder = builder;
myBuilder->setCallContainer(myCallContainer);
//這里創(chuàng)建了一個消息的輸出隊列，在前面的創(chuàng)建一個UserAgent的實體的過程中已經
//闡述過會把它綁定到相關的設備上去
myCallProcessingQueue = new Fifo < Sptr < SipProxyEvent > >;
//這里創(chuàng)建一個WorkThread線程在該線程中的myBuilder->process(nextEvent)
//檢查消息隊列myFifo中的返回消息(調用Uabuilder->process進行檢查),從而
//得到返回的消息。
//很明顯，這里新創(chuàng)建了一個 myWorkerThread工作線程，我們等一下就會看到如何把它Run
//起來
myWorkerThread = new WorkerThread(myCallProcessingQueue, myBuilder);

//創(chuàng)建一個SIP消息收發(fā)器的實體，在這個實體的構建里主要是把收發(fā)SIP消息的TCP/UDP
//的收發(fā)通道創(chuàng)建（SipUdpConnection和SipUdpConnection）。同時會構造一個SNMP的
//SipAgent.他的主要作用是向SNMP網關發(fā)送SNMP消息，描述網絡的運行狀態(tài)
if ( filterOn == true )
{
mySipStack = new SipTransceiverFilter(applName, defaultSipPort, nat, aContext);
}
else
{
mySipStack = new SipTransceiver(applName, defaultSipPort, nat, aContext);
}
myBuilder->setSipStack(mySipStack);
//創(chuàng)建一個SIP消息的解析線程 。
mySipThread = new SipThread(mySipStack, myCallProcessingQueue);

… …
}

2．4 讓User Agent Run起來：

　　構建User Agent的工作已經完畢，現在應該讓調用它的Run方法了；從下面的程序可以看到，Run方法的調用，讓整個程序進入一種"Idle"的狀態(tài)，等待命令輸入和狀態(tài)的產生，這個過程我們可以看到在Ua.CXX的Main程序中調用（ua.run()）。

Void UserAgent::run()
{
//調用HeartLessProxy的Run方法，稍后做詳細的介紹
HeartLessProxy::run();
… …
deviceThread->run(); //調用SoundcardDevice::hardwareMain(0)
… …
rtpThread->run();//調用SoundCardDevice::processRTP()進行RTP流的處理
… …
//在這里向FS發(fā)送隊列(myQ = new Fifo < Sptr < SubscribeMsg > >)中的各種消息,不
//過在Ua1001.cfg中,參數Subscribe_on設置為OFF所以,本章我們對FS暫不予以分析,
//在最后一章詳細分析FS的時候回著重分析它.
featureThread->run();//調用subscribeManager::subscribeMain()
… …
//后臺監(jiān)測線程開啟.
loadGenThread->run();//調用LoadGenMonitor::lgMain()

// User TimerEvent to kick start the load generator
… …
} // UserAgent::run

（未完待續(xù)）

作者供稿 CTI論壇編輯

作者聯系方法：lu_zheng@21cn.com

在Vovida的基礎上實現自己的SIP協(xié)議棧（二）


分類信息:     文摘
曲松县| 延川县| 大港区| 枣阳市| 钟山县| 芒康县| 布拖县| 固镇县| 睢宁县| 罗甸县| 汾西县| 灌南县| 寿阳县| 泽普县| 大厂| 浪卡子县| 阿拉善左旗| 清远市| 十堰市| 阜宁县| 临湘市| 霍城县| 淅川县| 泽库县| 聊城市| 九龙坡区| 黄陵县| 庄河市| 滨海县| 达尔| 嘉黎县| 多伦县| 临西县| 巴南区| 朔州市| 库车县| 五指山市| 阿荣旗| 仙居县| 乌海市| 江孜县|