sip源碼

A. 幾種SIP客戶端

做IMS的，出於測試或是體驗的目的，總免不了要找個客戶端接到網路裡面試一試，介紹幾款使用SIP協議的軟電話，供參考。 IMSDroidGoogle的開源項目，在網上可以免費下載，只支持Android系統（看名字也能猜得到）。這個東西對於做IMS的技術人員來說真是一個好東西，首先它的協議棧遵循3GPP標准，所以不是一個單純的SIP客戶端而是IMS客戶端；其次你能想到的參數在用戶界面里基本都能夠進行配置，非常適合進行測試；最後，由於這是個開源項目，因此可以拿到源碼，有能力的話可以根據自己的需求進行二次開發。美中不足的是目前的版本穩定性稍差，不過還是那句話，用於測試的話還是可以接受的。 Bria（名字似乎有點兒邪惡。。。。。）Counterpath 出品的商業客戶端，功能強大，穩定，對Android、IOS、Windows都有相應的版本來支持，專業的就是專業。不過也有問題，首先是這個要付費的，具體價格忘記了，是一般人都能接受的價格，不過很討厭的是付費的基本版本只支持G.711音頻編解碼，如果要支持G.729等壓縮編解碼還需要再次付費；另一個問題是Bria不是完全遵循3GPP標準的，比如在初始注冊消息中不會攜帶Authorization頭域，這也就導致了在一些對協議流程要求嚴格的網路中Bria不能使用。 X-LiteBria的免費版本，功能上做了刪減。 SIP Phone言簡意賅，從名字到軟體本身都是極度精簡，也是免費軟體。對於這個東西沒啥可說的，功能確實比較簡單，可配置的東西也很少，最初測試賬號時用過，現在基本不動了。 Nokia手機對，你沒有看錯，就是諾基亞手機！ 不得不佩服一下N廠，很早就在手機系統中內置了SIP協議棧，簡單地配置一下賬號和網路入口點就可以了，進行完相應的配置後，在撥號時會提示是否使用IP通話，選擇的話就可以通過IMS進行呼叫，親身測試過的機型有E71/E72/5800。 許可權：公開 來自：labs
聲明： 本文僅代表作者個人觀點。其原創性及文中表達的意見、判斷、數據、觀點和陳述文字等內容均與中國移動研究院無關。

B. 如何調用exosip開源代碼的介面

Osip2是一個開放源代碼的sip協議棧，是開源代碼中不多使用C語言寫的協議棧之一，它具有短小簡潔的特點，專注於sip底層解析使得它的效率比較高。
eXosip是Osip2的一個擴展協議集，它部分封裝了Osip2協議棧，使得它更容易被使用。

一、介紹

Osip2是一個開放源代碼的sip協議棧，是開源代碼中不多使用C語言寫的協議棧之一，它具有短小簡潔的特點，專注於sip底層解析使得它的效率比較高。但缺點也很明顯，首先就是可用性差，沒有很好的api封裝，使得上層應用在調用協議棧時很破碎；其次，只做到了transaction層次的協議過程解析，缺少call、session、dialog等過程的解析，這也增加了使用的難度；再次，缺少線程並發處理的機制，使得它的處理能力有限。

eXosip是Osip2的一個擴展協議集，它部分封裝了Osip2協議棧，使得它更容易被使用。eXosip增加了call、dialog、registration、subscription等過程的解析，使得實用性更強。但是eXosip局限於UA的實現，使得它用於registrar、sip server等應用時極其不容易。另外，它並沒有增加線程並發處理的機制。而且只實現了音頻支持，缺少對視頻和其它數據格式的支持。

綜合來說，Osip2加上eXosip協議棧仍然是個實現Sip協議不錯的選擇。當然需要根據不同的需求來增加更多的內容。

二、Osip2協議棧的組成

Osip2協議棧大致可以分為三部分：sip協議的語法分析、sip協議的過程分析和協議棧框架。

1、Sip協議的語法分析：

主要是osipparser2部分，目前支持RFC3261和RFC3265定義的sip協議消息，包括INVITE、ACK、OPTIONS、CANCEL、BYE、SUBSCRIBE、NOTIFY、MESSAGE、REFER和INFO。不支持RFC3262定義的PRACK。

遵循RFC3264關於SDP的offer/answer模式。帶有SDP的語法分析。

支持MD5加解密演算法。支持Authorization、www_authenticate和proxy_authenticate。

2、Sip協議的過程分析：

主要是osip2部分，基於RFC3261、RFC3264和RFC3265的sip協議描述過程，圍繞transaction這一層來實現sip的解析。

Transaction是指一個發送方和接收方的交互過程，由請求和應答組成。請求分為Invite類型和Non-Invite類型。應答分為響應型的應答和確認型的應答。響應型的應答是指這個應答僅代表對方收到請求。請求經過處理後都必須返回確認型的應答。響應型的應答有1xx，確認型的應答包括2xx、3xx、4xx、5xx和6xx。一個transaction由一個請求和一個或多個響應型應答、一個確認型應答組成。

Transaction根據請求的不同和發送/接收的不同可以分為四類：ict、nict、ist和nist。

Ict是指Invite client transaction，就是會話邀請的發起方。

Nict是指Non-Invite client transaction，是指非邀請會話的發起方。

Ist是指Invite server tranaction，是指會話邀請的接收方。

Nist是指Non-Invite server transaction，是指非邀請會話的接收方。

每種類型的transaction都有自己相應的狀態機，Osip2協議棧根據狀態機來處理所有的sip事件，所以這部分就是整個協議棧的核心。但是因為Osip2隻做到transaction這一層，所以它可以忽略掉call、registration等應用的復雜性，顯得相當簡單，這就使得需要使用它的應用必須要自己處理應用的邏輯。必須注意的一點是，transaction的資源在Osip里是由協議棧負責釋放的，但是在Osip2里改成由使用的應用負責釋放。

下面簡單的用時序圖來描述四種transaction的狀態機，只著重於描述狀態間的轉換，忽略了調用的處理函數，也簡化了很多沒有狀態變換的事件。也就是說，每個狀態下定義的事件並沒有完整的表現在圖中，不要以為這些事件沒定義或在該狀態下沒有處理。

圖中方框里的是狀態名，箭頭線上的是觸發狀態變換的事件名稱。同一個狀態下的事件並沒有時序關系。

Ict的狀態機如下：

（圖略）

Nict的狀態機如下：

（圖略）

Ist的狀態機如下：

（圖略）

Nist的狀態機如下：

（圖略）

3、協議棧框架：

框架並不是指代碼的某一部分，而是指它的構成形式。主要有三部分：底層套接字接收/發送，模塊間通信管道，上層調用api介面。

Osip2並不實現底層套接字的接收/發送，由eXosip實現，現在只支持UDP的鏈路連接。

模塊間的通信管道包括：transaction的消息管道、jevent的消息管道。Transaction的消息管道是驅動其狀態機的部件，通過不斷的接收來自底層套接字的遠端信令，或者來自上層調用的指令，根據上述的狀態機制來驅動這個transaction的運轉。Jevent的消息管道是eXosip實現的，用於匯報底層事件，使得調用程序能處理感興趣的事件。

上層調用的api介面大致有兩類：sip協議的調用介面和sdp協議的調用介面。EXosip封裝了大部分的sip協議調用介面，一般來說都不需要直接調用osip2的介面函數。介面函數很多，在這里就不詳述了，函數定義請參照源代碼部分的注釋。

三、eXosip協議棧的分析

eXosip是Osip2協議棧的封裝和調用。它實現了作為單個sip終端的大部分功能，如register、call、subscription等。

EXosip使用UDP socket套接字實現底層sip協議的接收/發送。並且封裝了sip消息的解釋器。

EXosip使用定時輪循的方式調用Osip2的transaction處理函數，這部分是協議棧運轉的核心。透過添加/讀取transaction消息管道的方式，驅動transaction的狀態機，使得來自遠端的sip信令能匯報給調用程序，來自調用程序的反饋能通過sip信令回傳給遠端。

EXosip增加了對各個類型transaction的超時處理，確保所有資源都能循環使用，不會被耗用殆盡。

EXosip使用jevent消息管道來向上通知調用程序底層發生的事件，調用程序只要讀取該消息管道，就能獲得感興趣的事件，進行相關的處理。

EXosip里比較重要的應用有j_calls、j_subscribes、j_notifies、j_reg、j_pub、osip_negotiation和authinfos。J_calls對應呼叫鏈表，記錄所有當前活動的呼叫。J_reg對應注冊鏈表，記錄所有當前活動的注冊信息。Osip_negotiation記錄本地的能力集，用於能力交換。Authinfos記錄需要的認證信息。

C. 如何學習sip，eXosip/osip！！！希望給點建議。

1、先了解sip協議本身
2、閱讀exosip、osip相關文檔
3、下載和編譯exosip、osip源碼
4、寫demo

D. sip協議如何用C語言實現

1、開源的sip伺服器端，比較好用的是Asterisk，標准C程序實現，代碼清晰。

2、sip的client相對比較多，主要有exosip,pjsip和opal。exosip簡單易用，在PC上用比較方便。但是涉及的相關資源太多，用了osip,srtp,ms2等眾多的開源庫，ms2下面還用到了ffmpeg，別的不說，光編譯就是噩夢。opal功能最強，雖然也用到了ffmpeg ，但是自己封裝的非常好，採用插件方式，調用靈活。opal採用class方式提供封裝，介面非常友好。感覺唯一不爽的地方，就是低層使用了ptlib，雖然多平台下都很好用，但放在嵌入式下感覺稍龐大了一些。pjsip精巧，方便移植，嵌入式下應該是首選。不過視頻頻支持方面擴展起來比opal麻煩。個人感覺，對於windows開發者來說，pjsip最大的好處就是代碼調試方便。整個工程一次編譯通過，另外兩個庫還要找很多相關的資源
。
3、其他的一些協議棧也調試過，比如reSipphone，好象是這個名字，還有Yate，不過從快速開發角度看，都不太合適。現在搞sip開發的，一開始就是先找好協議棧。linphone,ekiga什麼的，但龐大。對於剛開始做的，最好是一個精簡的demo。後來找到pjsip下面的幾個例子，慢慢地了解了sip的工作流程，當然少不了抓包工具和tcpmp。
不過，其實，sip沒有想像中的那麼麻煩。現在回頭看，剛開始做項目，使用協議棧絕對不是好想法。如果換個方向，先熟悉SIP基本協議，然後自己改造一個，或完全寫一個，可能效果更好。