【正文】 ag，F(xiàn)rom頭域，必須與200響應(yīng)的To域一致。缺省時(shí)，ACK或者BYE的RequestURI被設(shè)置成在200響應(yīng)中的地址。相反的，UAC可以從To頭域拷貝地址到RequestURI。在每個(gè)響應(yīng)中，UAC也會注意到To和From的值。對于每個(gè)呼叫歷程（Call Leg），To頭域變成遠(yuǎn)端地址，而From頭域變成本地地址。 主叫或者被叫產(chǎn)生二級并發(fā)請求一旦呼叫已經(jīng)建立，主叫或者被叫可以產(chǎn)生Invite或者Bye請求，來改變或者結(jié)束呼叫。不管是主叫還是被叫產(chǎn)生新的請求，在請求中的頭域如下設(shè)置。對于期望的Call Leg，To頭域設(shè)置為遠(yuǎn)端地址，F(xiàn)rom頭域設(shè)置為本地地址（兩者包含任何tags）。聯(lián)系頭域與先前響應(yīng)或者請求的Contact域不同。Request URI應(yīng)該設(shè)置成聯(lián)系頭域的值，這個(gè)聯(lián)系頭域被先前的從遠(yuǎn)端發(fā)送過來的請求或者響應(yīng)接收，或者設(shè)置成遠(yuǎn)端地址。 接收的并發(fā)請求當(dāng)請求后來被接收，將進(jìn)行下面的檢查：如果CallID是新的，不管是否是To和From頭域的值，認(rèn)為請求是一個(gè)新的呼叫。如果CallID已經(jīng)存在，那么請求是對于一個(gè)存在的呼叫。如果To,From, CallID和Cseq值與先前接收的一致，則這個(gè)請求是一個(gè)重傳請求。如果上面兩步?jīng)]有匹配到，To和From域比較存在的Call Leg和本地及遠(yuǎn)端的地址。如果這里匹配，在請求中的Cseq比上一個(gè)Cseq值，這樣對于存在的Call Leg，這個(gè)請求是一個(gè)新的事務(wù)。 SIP消息機(jī)制 SIP URL結(jié)構(gòu)SIP URLs使用于SIP消息的頭部，表示發(fā)起者(From)，當(dāng)前地址(Request—URI)，重定向地址(Contact)，請求的最終接受者(To)。SIP協(xié)議采用的URI的一般結(jié)構(gòu)是：SIP：用戶名：口令@主機(jī)：端口；傳送參數(shù)；用戶參數(shù)；方法參數(shù)；生存期參數(shù)；服務(wù)器地址參數(shù)；頭部名=頭部值這里未采用嚴(yán)格的BNF形式化表示形式。其中“SIP”表示需采用SIP協(xié)議和所指示的端系統(tǒng)通信。用戶名可由任意字符組成，一般可取類似于Email用戶名的形式。SIP URL的一個(gè)特定功能是允許主機(jī)類型為IP電話網(wǎng)關(guān)，此時(shí)的用戶名可為一般的電話號碼。由于BNF語法表示不能區(qū)分電話號碼和一般的用戶名，因此在域名后面增加了“用戶參數(shù)”字段，該字段有兩個(gè)可選值：IP和phone，當(dāng)其設(shè)定為“phone”時(shí)，表示用戶名為電話號碼，對應(yīng)的端系統(tǒng)為IP電話網(wǎng)關(guān)?！爸鳈C(jī)”可為主機(jī)域名或IPv4地址?！岸丝凇北硎菊埱笙⑺屯亩丝谔?，其缺省值為5060，即公開SIP端口號?？诹羁梢灾糜赟IP URL中，但一般不這樣做，因?yàn)槠浒踩允侵档每紤]的?！皞魉蛥?shù)”指示采用TCP還是UDP傳送，缺省值為UDP?！胺?wù)器地址參數(shù)”指示和該用戶通信的服務(wù)器地址，通常為多播地址?！吧嫫趨?shù)”指示UDP多播數(shù)據(jù)包的壽命，僅當(dāng)傳送參數(shù)為UDP且服務(wù)器地址參數(shù)為多播地址時(shí)才能使用。 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：邀請用戶加入某會話，會話包含于消息體中。ACK：對于INVITE請求的最終響應(yīng)的證實(shí)。成功的響應(yīng)由發(fā)出INVITE請求的UAC給予響應(yīng)，不成功的響應(yīng)可以由收到此響應(yīng)的第一個(gè)有狀態(tài)代理服務(wù)器給予響應(yīng)，也可以由UAC給予響應(yīng)。OPTIONS：詢問服務(wù)器的能力。BYE：UAC指示釋放已經(jīng)建立的呼叫。BYE請求按INVITE請求同樣的方式前轉(zhuǎn)，可以由主叫方或者被叫方發(fā)出。收到BYE請求后，應(yīng)該停止向發(fā)出請求的一方發(fā)送媒體流。REGISTER：在SIP服務(wù)器上注冊To字段地址。CANCEL：取消一個(gè)尚未完成的請求。對于已經(jīng)完成的請求，則沒有影響。響應(yīng)消息響應(yīng)狀態(tài)碼：第一位指示響應(yīng)類別，后兩位數(shù)字表示該類中的具體響應(yīng)。1XX：表示呼叫進(jìn)展。2XX：表示請求已經(jīng)成功接收，完全理解并被接受。3XX：重定向響應(yīng)，表示需采取進(jìn)一步動作，完成該請求。4XX：客戶出錯。5XX：服務(wù)器出錯，表示服務(wù)器不能完成合法的請求。6XX：全局故障。表示任何服務(wù)器都不能完成該請求。INVITE是SIP協(xié)議的核一心機(jī)制。發(fā)出邀請請求后，終端用戶或者網(wǎng)絡(luò)應(yīng)該回送響應(yīng)。在SIP中，響應(yīng)分成兩大類。一類是中間響應(yīng)，報(bào)告呼叫進(jìn)展情況，另一類是最終響應(yīng)，包括成功響應(yīng)和失敗響應(yīng)?？蛻艉头?wù)器之間的操作從第一個(gè)請求到最終請求的所有消息構(gòu)成一個(gè)SIP事務(wù)。一個(gè)正常成功的呼叫包含三個(gè)事務(wù)：邀請請求發(fā)起的事務(wù)到成功最終響應(yīng)。對這個(gè)響應(yīng)的ACK請求。呼叫終結(jié)請求BYE發(fā)起的事務(wù)。注意對不成功邀請的響應(yīng)的應(yīng)答不構(gòu)成一個(gè)單獨(dú)的事務(wù)。SIP協(xié)議定義的是呼叫建立、終結(jié)和修改的信息，并不涉及媒體控制。媒體類型，編碼格式和收發(fā)地址等信息由SDP傳送。SIP可以采用不同的應(yīng)用層控制協(xié)議。如果采用UDP傳送，要求響應(yīng)消息沿著請求消息發(fā)送的同樣路徑傳送，以支持中間服務(wù)器對呼叫的監(jiān)視和狀態(tài)控制。對于經(jīng)多播UDP傳送的請求，其響應(yīng)應(yīng)送往同一個(gè)多播地址和目的端口。如果采用TCP傳送，則同一事務(wù)的請求和響應(yīng)應(yīng)該在同一TCP連接上發(fā)送。同一客戶到同一服務(wù)器的若干事務(wù)請求可以用同一TCP連接，也可以用不同的TCP連接。 SIP呼叫控制過程和示例呼叫是由一個(gè)會議的所有參與者組成的，在SIP系統(tǒng)中，呼叫由CallID唯一標(biāo)識。一個(gè)端到端的IP會話與一個(gè)SIP呼叫相對應(yīng)，而在基于多點(diǎn)控制單元(MCU)的會議中，每一個(gè)參與者通過單獨(dú)的呼叫將自己引薦給MCU，完成多點(diǎn)會議的初始化。SIP協(xié)議支持三種呼叫模式：由用戶代理客戶機(jī)(UAC)向用戶代理服務(wù)器(UAS)直接呼叫，由UAC在重定向服務(wù)器的輔助下進(jìn)行重定向呼叫和由代理服務(wù)器代表UAC向被叫發(fā)起呼叫。以重定向服務(wù)器信令過程為例，來說明呼叫建立過程()。①主叫方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ù)器重定向服務(wù)器被叫15467823 呼叫建立過程注冊服務(wù)器經(jīng)常用作啟動后的注冊，由于在REGISTER消息中使用了SIP URL地址的緣故，因此，當(dāng)INVITE請求到達(dá)時(shí)，代理服務(wù)器或者重定向服務(wù)器可以直接正確地轉(zhuǎn)發(fā)請求信息。這一基于注冊服務(wù)器的轉(zhuǎn)發(fā)特性形成了網(wǎng)絡(luò)對支持真正的號碼移動性服務(wù)的基礎(chǔ)。在此，需要注意的是，通常一個(gè)SIP網(wǎng)絡(luò)服務(wù)器能夠?qū)崿F(xiàn)對不同種類服務(wù)器的組合。 程序設(shè)計(jì)思想簡介。是一個(gè)標(biāo)準(zhǔn)的基于對話框的編程。下面通過一對呼叫的連接過程說明程序?qū)εcSIP消息的整個(gè)處理過程。假設(shè)終端A呼叫終端B，也就是說A，B是兩個(gè)這里實(shí)現(xiàn)的用戶代理。在這個(gè)基類中首先需要調(diào)用SDP_init()函數(shù)來申請系統(tǒng)的資源，包括包括資源和鏈表的處理。然后需要編寫OnInitDialog()函數(shù)。oSIP的初始化工作都是包含在OnInitDialog()函數(shù)中的。在這個(gè)函數(shù)中首先需要設(shè)置系統(tǒng)的回調(diào)函數(shù)。這些回調(diào)函數(shù)的具體實(shí)現(xiàn)放在全局變量中。因?yàn)榘l(fā)送跟接受消息采用的是Socket編程，所以這個(gè)函數(shù)中還需要將發(fā)送數(shù)據(jù)的Socket進(jìn)行初始化。RTP流的本地接收發(fā)送端口就是在這里設(shè)置的。語音的發(fā)送與接受一般采用的協(xié)議有TCP跟UDP兩種。這里采用的是UDP。初始化工作做完后然后就可以編寫A呼叫B的OnCall函數(shù)了。這個(gè)函數(shù)中調(diào)用osip_dialog_invite()數(shù)來產(chǎn)生一個(gè)呼叫(invite)請求，也就是一個(gè)完整的SIP包。這個(gè)請求包含了包括發(fā)送數(shù)據(jù)的IP地址、端口等一些本地信息。呼叫請求的SIP包創(chuàng)建好之后就可以調(diào)用osip_dialog_send_request ()來發(fā)送了，在這個(gè)函數(shù)中系統(tǒng)首先調(diào)用ua_transaction_new()來產(chǎn)生一個(gè)新的狀態(tài)機(jī)。這時(shí)候新產(chǎn)生的狀態(tài)機(jī)就是用戶代理A的狀態(tài)是ICT。狀態(tài)機(jī)產(chǎn)生后，系統(tǒng)調(diào)用ua_transaction_execute()來把消息交給狀態(tài)機(jī)處理。FifoAdd()函數(shù)負(fù)責(zé)把消息放在消息隊(duì)列當(dāng)中。這樣這個(gè)呼叫請求就發(fā)送完成了。狀態(tài)機(jī)自身從DIALOG_IDLE狀態(tài)跳轉(zhuǎn)到DIALOG_INVITING狀態(tài)，等待用戶代理B的回應(yīng)。同時(shí)系統(tǒng)調(diào)用SetTimer0函數(shù)來設(shè)置超時(shí)控制。當(dāng)一個(gè)超時(shí)(一般為500ms)到達(dá)的時(shí)候。向?qū)Ψ街匕l(fā)一次數(shù)據(jù)包。并且把超時(shí)時(shí)間增加一倍，繼續(xù)重發(fā)數(shù)據(jù)包，如此循環(huán)。當(dāng)?shù)竭_(dá)一定時(shí)間后，系統(tǒng)認(rèn)為對方?jīng)]有響應(yīng)，則終止該呼叫請求。這里的用戶代理B會一直在另一個(gè)線程中調(diào)用ReceiveFrom()在某個(gè)端口上來監(jiān)聽消息。一旦監(jiān)聽到有消息到達(dá)。它就會調(diào)用osip_parse()函數(shù)來解析此消息并調(diào)用osip_find_transaction_and_add_event()函數(shù)將消息跟事物(transaction)匹配。如果函數(shù)返回1，那說明沒有找到跟此消息匹配的事物，系統(tǒng)會調(diào)用osip_create_transaction()數(shù)來創(chuàng)建一個(gè)新的狀態(tài)機(jī)來處理這個(gè)消息，這個(gè)新的狀態(tài)機(jī)就是IST(帶invite的server端狀態(tài)機(jī))。如果函數(shù)返回值不為1，說明已經(jīng)存在與此消息匹配的事物，那系統(tǒng)直接調(diào)用函數(shù)將消息放在消息隊(duì)列中等待狀態(tài)機(jī)處理。B的IST狀態(tài)機(jī)收到invite請求后就會調(diào)用先前設(shè)置好的ist _invite _ received()這個(gè)回調(diào)函數(shù)?；卣{(diào)函數(shù)都是在全局變量中事先寫好的。在這個(gè)函數(shù)中B首先將自己的狀態(tài)設(shè)為DIALOG_INVITED，然后產(chǎn)生lxx消息進(jìn)而發(fā)送給A。A收到B發(fā)送過來的lxx消息系統(tǒng)就會調(diào)用回調(diào)函數(shù)ict_lxx_received()。并且發(fā)送ACK給B，B受到后將其狀態(tài)設(shè)為DIALOG_ESTABHSHED，并且發(fā)送2xx消息。當(dāng)A收到2xx消息后會再次向A發(fā)送ACK表示確認(rèn)。這樣A的一次ICT服務(wù)就完成了。等B再次收到ACK消息后，B就將其狀態(tài)設(shè)為DIALOG_TERMINATED，完成了此次的IST服務(wù)。其中當(dāng)A收到2xx消息后會調(diào)用SDP_agree()函數(shù)來進(jìn)行媒體協(xié)商。媒體協(xié)商主要解決的就是呼叫過程中兩個(gè)終端之間存在的語音編碼能力集不匹配的問題。媒體協(xié)商好之后就可以調(diào)用startsession()函數(shù)來啟動RTP模塊。以上便是OSIP協(xié)議棧的一個(gè)簡單但完整的呼叫過程，它只處理信令模塊的部分。信令模塊跟媒體模塊是分離的。信令模塊的通訊正常與否可以通過抓保工具來進(jìn)行測試。接下來介紹媒體模塊。也就是RTP流的建立。在Invite信令中，A告訴了B本地的RTP接收地址和端口，B在200OK中告知了A本地的RTP的接收地址和端口。因此，信令結(jié)束后，A和B就可實(shí)現(xiàn)流的互通(通常是音頻)，RTP流是依靠SIP信令里的信息建立超來的，但和SIP或者SIP信令本身而言并沒有任何必然聯(lián)系。另外，就RTP要傳送的音頻數(shù)據(jù)本身而言(例如音頻數(shù)據(jù))，和SIP更沒有必然聯(lián)系。通常，數(shù)據(jù)是這樣產(chǎn)生的，A采集音頻數(shù)據(jù)，然后交給編解碼模塊進(jìn)行處理。采集和發(fā)送對于程序?qū)崿F(xiàn)來說。和相對文件的操作是類似的。采集就是對聲卡數(shù)據(jù)的讀取，發(fā)送是對于Socket的寫。分別創(chuàng)建各自的讀和寫的類來實(shí)現(xiàn)以上功能。壓縮完后的數(shù)據(jù)，由RTP打包，然后發(fā)送給B。B接收這些數(shù)據(jù)，拆RTP包，拿出原始數(shù)據(jù)，交給解碼，解出數(shù)據(jù)后給播放進(jìn)行搖放。RTP流的基本建立過程就是這樣的。至此一個(gè)完整的用戶代理設(shè)計(jì)完成。 程序重要模塊介紹 UAS部分的事件處理case EXOSIP_CALL_INVITE: sprintf(out_str, 收到來自%s的呼叫!,uac_erequestfromurlstring)。 pMainWndGetDlgItem(IDC_CALL_STATUS)SetWindowText(out_str)。 eXosip_lock ()。 eXosip_call_send_answer(uac_etid, 180, NULL)。 if(0 != eXosip_call_build_answer(uac_etid, 200, amp。answer)) { eXosip_call_send_answer(uac_etid, 603, NULL)。 AfxMessageBox(error build answer!)。 continue。 } eXosip_unlock ()。 pMainWndcall_id = uac_ecid。 pMainWnddialog_id = uac_edid。上面的模塊是UAS的偵聽模塊，主要是當(dāng)收到UAC的呼叫請求時(shí)，及時(shí)作出反應(yīng)。這里發(fā)送“180”是反饋UAC一個(gè)