【正文】 負(fù)責(zé)用戶代理的注冊和各種狀態(tài)機(jī)的初始化、實(shí)例化過程。Register線程負(fù)責(zé)用戶注冊。 狀態(tài)機(jī)根據(jù)RFC3261對用戶代理的功能行為描述和兩方通話的業(yè)務(wù)流程．可以為User Agent模塊的狀態(tài)機(jī)設(shè)計(jì)了五個狀態(tài)：Idle、Ringing、InCall、Trying和Calling Error。當(dāng)主叫發(fā)出呼叫請求時，系統(tǒng)生成SIP本地事件，狀態(tài)轉(zhuǎn)為Trying。如果被叫不摘機(jī)，超時事件將被觸發(fā)，主叫狀態(tài)轉(zhuǎn)為Calling Error，被叫返回Idle狀態(tài)。如果主叫在響鈴的時候主動掛機(jī)，狀態(tài)轉(zhuǎn)為Idle。會話結(jié)束后，雙方返回Idle狀態(tài)。所謂表驅(qū)動實(shí)現(xiàn)，是指把狀態(tài)機(jī)轉(zhuǎn)換成一張表，表的每一行對于每一種狀態(tài)，表的每一列對應(yīng)每一種事件，表中的每一個元素由過程和狀態(tài)組成。所謂的過程驅(qū)動是指每一種狀態(tài)對應(yīng)一個過程，根據(jù)當(dāng)前狀態(tài)執(zhí)行相應(yīng)的過程。而過程驅(qū)動適合以下協(xié)議：語義復(fù)雜，狀態(tài)不多，但是有復(fù)雜的出錯處理。與狀態(tài)機(jī)相關(guān)的類有Builder、State machine、State、Operator。這些子類是分別針對不同事件設(shè)置的，具體的事件處理由它們的成員函數(shù)process(event)完成。State的Operator隊(duì)列有三種：入口隊(duì)列Entry Operators、執(zhí)行隊(duì)列Operators、出口隊(duì)列Exit Operators。然后當(dāng)事件觸發(fā)時，調(diào)用State：：process()這個函數(shù)將順序調(diào)用過程隊(duì)列中每一項(xiàng)的process()在Operator：：process()中，會判斷是否應(yīng)該由這個Operator來處理事件。當(dāng)狀態(tài)改變時，當(dāng)前狀態(tài)的出口隊(duì)列中每一個Operator：：process()都被調(diào)用，以完成收尾工作并為下一個狀態(tài)做準(zhǔn)備。OpInviteUrl處理該事件，發(fā)送INVITE消息到被叫，并將狀態(tài)置為Trying。①如果主叫收到被叫的180或者183狀態(tài)消息，說明被叫正在嘗試建立會話連接，那么OpStartRingingBackTone將取消OpStartTimer創(chuàng)建的定時器，并且通知應(yīng)用層振鈴。有時，主叫會收到多個180、183狀態(tài)消息，OpStartRingingBackTone負(fù)責(zé)檢查SDP是否有變化，并保存最新的設(shè)置。然后該事件被OpTimeout檢測到，狀態(tài)轉(zhuǎn)為Calling Error，由OpOnHook進(jìn)行處理，取消此次呼叫。InCall狀態(tài)入口隊(duì)列的OpStartAudioDuplex負(fù)責(zé)配置RTP通道的屬性(包括：包的大小、端口、帶寬等)。如果被叫應(yīng)用層先掛機(jī)，主叫將收到BYE消息，OpEndCall負(fù)責(zé)刪除呼叫占用的內(nèi)存空間，并通知應(yīng)用層被叫已掛機(jī)。Statemachine是State的集合。Builder是Statemachine的集合，它的處理函數(shù)process首先對事件進(jìn)行預(yù)處理，比如：攔截錯誤的狀念消息、調(diào)用Register線程處理與注冊相關(guān)的消息、為新INVITE事件(即新的呼叫請求)創(chuàng)建Call Info信息等。每個Manager線程含有一個Builder，由它負(fù)責(zé)事件的分配及處理。系統(tǒng)的靈活服務(wù)性又一次得到保證。這樣，多個實(shí)體的不同的狀念機(jī)可以方便的載入一個Builder，從而實(shí)現(xiàn)一機(jī)多用，多服務(wù)。（1）首先UAC向代理服務(wù)器（PS）發(fā)送INVITE請求消息；（2）SIP 代理服務(wù)器向重定向服務(wù)器（RS）發(fā)送請求消息；（3）RS產(chǎn)生302重定向應(yīng)答消息并返回給PS，此302消息中包含下一步路由信息；（4）PS向RS所指定的PS（即UAS端的SIP代理服務(wù)器）發(fā)送INVITE請求；（5）被呼叫方的PS發(fā)送INVITE請求給RS；（6）RS返回302應(yīng)答消息，PS從此消息中得知被呼叫方用戶的位置；（7）PS 發(fā)送INVITE 給被呼叫方的SIP 用戶代理服務(wù)器（UAS）；（8）UAS向UAC發(fā)送200OK應(yīng)答，表示接受會話邀請；（9）UAC向UAS發(fā)送ACK請求消息，表示確定會話的建立，通過三次握手成功建立會話，會話建立后雙方可以進(jìn)行相互通信。另外，SIP移動性方案中會話雙方直接通信，也不需要IP隧道封裝，因此還具有時延小、帶寬效率高的優(yōu)點(diǎn)。 用戶代理的功能介紹綜合分析以上用戶代理的業(yè)務(wù)，可以總結(jié)出一個用戶代理需要實(shí)現(xiàn)以下這些功能： 處理SIP消息一個用戶代理需要根據(jù)用戶的各種控制命令進(jìn)行連接等操作，而這些控制命令是由SIP 消息來承載的，所以用戶代理必須能夠生成SIP 協(xié)議中所規(guī)定的各種消息，并根據(jù)具體的情況來設(shè)置消息中的各種參數(shù)。所有這些對SIP 消息的生成、設(shè)置、接收、解析的操作，是用戶代理一個最基本的功能。一方面，它從上層的應(yīng)用程序中得到用戶的各種操作和命令，并以次為依據(jù)產(chǎn)生各種SIP 消息，然后交給下層的傳輸層去發(fā)送到指定的地址；而另一方面，它又通過傳輸層接收其他地方的用戶代理發(fā)送來的SIP 消息，以作出各種響應(yīng)并將得到的信息交給上層的應(yīng)用程序去處理。 定時功能從前面對用戶代理的業(yè)務(wù)描述可以看出，用戶代理有可能會頻繁地進(jìn)行消息重發(fā)和超時判斷等操作，而這些都必須要引入定時功能來實(shí)現(xiàn)。 其他功能從用戶代理的結(jié)構(gòu)設(shè)計(jì)這個角度來說，上面三個功能是它的最基本的功能，只要代碼能夠從結(jié)構(gòu)上實(shí)現(xiàn)這三個功能，就基本能承擔(dān)一個用戶代理在整個SIP協(xié)議棧中的作用了。在這里，對這些非基本的功能不再一一介紹，本文將在后面的設(shè)計(jì)中將它們體現(xiàn)出來。通過對這些業(yè)務(wù)的描述，分析出用戶代理的基本功能，并進(jìn)而給出合理的設(shè)計(jì)方案。 主叫發(fā)出初始邀請請求當(dāng)UAC希望初始化一個呼叫，就發(fā)出一個INVITE請求。Request_URI包含同一個地址。如果From地址可以出現(xiàn)在請求中，并在同一個呼叫中，由其他User agent client產(chǎn)生，主叫必須插入tag出參數(shù)到From域中。 被叫發(fā)出的響應(yīng)被叫接收到初始的INVITE請求，被叫可以接受，重定向，或者拒絕呼叫。響應(yīng)的信息必須從請求域中拷貝下面的域：To,From,CallID,Cseq和Via域。因?yàn)橐粋€從UAC的請求應(yīng)該Fork（分叉）并到達(dá)多個主機(jī)，UAC將根據(jù)tag區(qū)分來自不同UAS’s的響應(yīng)。這里包含一個被叫希望連接的被叫地址，包括目前INVITE請求的ACK。這些分別變成本地或者遠(yuǎn)端Call Leg地址。每個響應(yīng)通過To頭域中的“tag”參數(shù)區(qū)別。為了識別，它發(fā)送一個ACK請求，為了結(jié)束，發(fā)送一個BYE請求。缺省時，ACK或者BYE的RequestURI被設(shè)置成在200響應(yīng)中的地址。在每個響應(yīng)中，UAC也會注意到To和From的值。 主叫或者被叫產(chǎn)生二級并發(fā)請求一旦呼叫已經(jīng)建立，主叫或者被叫可以產(chǎn)生Invite或者Bye請求，來改變或者結(jié)束呼叫。對于期望的Call Leg，To頭域設(shè)置為遠(yuǎn)端地址，F(xiàn)rom頭域設(shè)置為本地地址（兩者包含任何tags）。Request URI應(yīng)該設(shè)置成聯(lián)系頭域的值，這個聯(lián)系頭域被先前的從遠(yuǎn)端發(fā)送過來的請求或者響應(yīng)接收，或者設(shè)置成遠(yuǎn)端地址。如果CallID已經(jīng)存在，那么請求是對于一個存在的呼叫。如果上面兩步?jīng)]有匹配到，To和From域比較存在的Call Leg和本地及遠(yuǎn)端的地址。 SIP消息機(jī)制 SIP URL結(jié)構(gòu)SIP URLs使用于SIP消息的頭部，表示發(fā)起者(From)，當(dāng)前地址(Request—URI)，重定向地址(Contact)，請求的最終接受者(To)。其中“SIP”表示需采用SIP協(xié)議和所指示的端系統(tǒng)通信。SIP URL的一個特定功能是允許主機(jī)類型為IP電話網(wǎng)關(guān)，此時的用戶名可為一般的電話號碼?！爸鳈C(jī)”可為主機(jī)域名或IPv4地址?？诹羁梢灾糜赟IP URL中，但一般不這樣做，因?yàn)槠浒踩允侵档每紤]的?！胺?wù)器地址參數(shù)”指示和該用戶通信的服務(wù)器地址，通常為多播地址。 SIP消息結(jié)構(gòu)SIP消息的一般格式，用ABNF范式形式化表示：SIPmessage = Request/ResponseGenericmessage= startline*messageheaderCRLF[messagebody]Startline = Requestline/Status1inemessageheader=(generalheader/request—header/responseheader/entityheader)Requestline =Method SP RequestURI SP SIP—Version CRLFStatusline= SIP—Version SP StatusCode SP Reason—Phrase CRLFSIP—Version= “SIP/”請求方法INVITE：邀請用戶加入某會話，會話包含于消息體中。成功的響應(yīng)由發(fā)出INVITE請求的UAC給予響應(yīng)，不成功的響應(yīng)可以由收到此響應(yīng)的第一個有狀態(tài)代理服務(wù)器給予響應(yīng)，也可以由UAC給予響應(yīng)。BYE：UAC指示釋放已經(jīng)建立的呼叫。收到BYE請求后，應(yīng)該停止向發(fā)出請求的一方發(fā)送媒體流。CANCEL：取消一個尚未完成的請求。響應(yīng)消息響應(yīng)狀態(tài)碼：第一位指示響應(yīng)類別，后兩位數(shù)字表示該類中的具體響應(yīng)。2XX：表示請求已經(jīng)成功接收，完全理解并被接受。4XX：客戶出錯。6XX：全局故障。INVITE是SIP協(xié)議的核一心機(jī)制。在SIP中，響應(yīng)分成兩大類?？蛻艉头?wù)器之間的操作從第一個請求到最終請求的所有消息構(gòu)成一個SIP事務(wù)。對這個響應(yīng)的ACK請求。注意對不成功邀請的響應(yīng)的應(yīng)答不構(gòu)成一個單獨(dú)的事務(wù)。媒體類型，編碼格式和收發(fā)地址等信息由SDP傳送。如果采用UDP傳送，要求響應(yīng)消息沿著請求消息發(fā)送的同樣路徑傳送，以支持中間服務(wù)器對呼叫的監(jiān)視和狀態(tài)控制。如果采用TCP傳送，則同一事務(wù)的請求和響應(yīng)應(yīng)該在同一TCP連接上發(fā)送。 SIP呼叫控制過程和示例呼叫是由一個會議的所有參與者組成的，在SIP系統(tǒng)中，呼叫由CallID唯一標(biāo)識。SIP協(xié)議支持三種呼叫模式：由用戶代理客戶機(jī)(UAC)向用戶代理服務(wù)器(UAS)直接呼叫，由UAC在重定向服務(wù)器的輔助下進(jìn)行重定向呼叫和由代理服務(wù)器代表UAC向被叫發(fā)起呼叫。①主叫方UAC向被叫域服務(wù)器發(fā)送請求INVITE；②該服務(wù)器配置成重定向服務(wù)器，向定位服務(wù)器發(fā)出查詢請求；③定位服務(wù)器返回被叫當(dāng)前地址；④重定向服務(wù)器向主叫UAC回送302響應(yīng)“Moved temporarily”，Contact字段置入被叫當(dāng)前地址；⑤主叫UAC回送證實(shí)消息ACK；⑥主叫UAC向被叫用戶當(dāng)前地址重新發(fā)送INVITE消息；⑦被叫用戶UAS回送200響應(yīng)消息；⑧主叫用戶UAC向被叫用戶UAS回送證實(shí)消息ACK。這一基于注冊服務(wù)器的轉(zhuǎn)發(fā)特性形成了網(wǎng)絡(luò)對支持真正的號碼移動性服務(wù)的基礎(chǔ)。 程序設(shè)計(jì)思想簡介。下面通過一對呼叫的連接過程說明程序?qū)εcSIP消息的整個處理過程。，在這個基類中首先需要調(diào)用SDP_init()函數(shù)來申請系統(tǒng)的資源，包括包括資源和鏈表的處理。oSIP的初始化工作都是包含在OnInitDialog()函數(shù)中的。這些回調(diào)函數(shù)的具體實(shí)現(xiàn)放在全局變量中。RTP流的本地接收發(fā)送端口就是在這里設(shè)置的。這里采用的是UDP。這個函數(shù)中調(diào)用osip_dialog_invite()數(shù)來產(chǎn)生一個呼叫(invite)請求，也就是一個完整的SIP包。呼叫請求的SIP包創(chuàng)建好之后就可以調(diào)用osip_dialog_send_request ()來發(fā)送了，在這個函數(shù)中系統(tǒng)首先調(diào)用ua_transaction_new()來產(chǎn)生一個新的狀態(tài)機(jī)。狀態(tài)機(jī)產(chǎn)生后，系統(tǒng)調(diào)用ua_transaction_execute()來把消息交給狀態(tài)機(jī)處理。這樣這個呼叫請求就發(fā)送完成了。同時系統(tǒng)調(diào)用SetTimer0函數(shù)來設(shè)置超時控制。向?qū)Ψ街匕l(fā)一次數(shù)據(jù)包。當(dāng)?shù)竭_(dá)一定時間后，系統(tǒng)認(rèn)為對方?jīng)]有響應(yīng)，則終止該呼叫請求。一旦監(jiān)聽到有消息到達(dá)。如果函數(shù)返回1，那說明沒有找到跟此消息匹配的事物，系統(tǒng)會調(diào)用osip_create_transaction()數(shù)來創(chuàng)建一個新的狀態(tài)機(jī)來處理這個消息，這個新的狀態(tài)機(jī)就是IST(帶invite的server端狀態(tài)機(jī))。B的IST狀態(tài)機(jī)收到invite請求后就會調(diào)用先前設(shè)置好的ist _invite _ received()這個回調(diào)函數(shù)。在這個函數(shù)中B首先將自己的狀態(tài)設(shè)為DIALOG_INVITED，然后產(chǎn)生lxx消息進(jìn)而發(fā)送給A。并且發(fā)送ACK給B，B受到后將其狀態(tài)設(shè)為DIALOG_ESTABHSHED，并且發(fā)送2xx消息。這樣A的一次ICT服務(wù)就完成了。其中當(dāng)A收到2xx消息后會調(diào)用SDP_agree()函數(shù)來進(jìn)行媒體協(xié)商。媒體協(xié)商好之后就可以調(diào)用startsession()函數(shù)來啟動RTP模塊。信令模塊跟媒體模塊是分離的。接下來介紹媒體模塊。在Invite信令中，A告訴了B本地的RTP接收地址和端口，B在200OK中告知了A本地的RTP的接收地址和端口。另外，就RTP要傳送的音頻數(shù)據(jù)本身而言(例如音頻數(shù)據(jù))，和SIP更沒有必然聯(lián)系。采集和發(fā)送對于程序?qū)崿F(xiàn)來說。采集就是對聲卡數(shù)據(jù)的讀取，發(fā)送是對于Socket的寫。壓縮完后的數(shù)據(jù)，由RTP打包，然后發(fā)送給B。RTP流的基本建立過程就是這樣的。 程序重要模塊介紹 UAS部分的事件處理case EXOSIP_CALL_INVITE: sprintf(out_str, 收到來自%s的呼叫!,uac_erequestfromurlstring)。 eXosip_lock ()。 if(0 != eXosip_call_build_answer(uac_etid, 200, amp。 AfxMessageBox(error build answer!)。 } eXosip_unlock ()。 pMainWnddialog_id = uac_edid。這里發(fā)送“180”是反饋UAC一個“