開源的協議棧很多了，爲什麼我要寫一個新的協議棧呢？
SIP協議越來越複雜了，而開源實現的協議棧更加複雜，效率十分低下。因爲他們試圖面面俱到，有的協議棧還試圖兼容或轉換H323。總之，沒有看到一個簡單的。
在我看來，要搞明白一個開源協議棧內部的構造並加以靈活應用，並不比我從底層開發一個新的、適應性強的協議棧來的容易。
再說，我喜歡自造車輪，SIP協議文本我研讀了不下20遍，也寫過簡單的SIP轉發服務器和註冊服務器，有一定基礎。
相對來說，SS7的ISUP編解碼更復雜些，我在這上面做過很多應用。
另外，有幾個客戶急需，希望我的平臺能立即支持。
開發協議棧（和媒體庫）並反覆測試直到它非常穩定，花了我將近1個月的時間，很久沒有這麼高強度的編碼了，經常在深夜解決程序Bug的時候還要對付蚊蟲，它是深圳一種更爲常見的Bug。
我設計SIP協議棧（包括媒體庫）的目標如下：
0、簡單
實現一定要簡單，這樣才能穩健。
API接口也要簡單，這要感謝前面和GregCheng的合作，他對SIP技術還有業界有精到的見解，他定義了一個合理的API界面。
1、和藍星際平臺無縫結合
藍星際Koodoo語言的可編程能力超強，結合後就實現了SIP的動態可編程能力。
這很重要，現在運營商都進入IMS商用部署階段了，他們對SIP進行了諸多擴展，“可編程的SIP”是個吸引人的目標，靈活性是很重要的。
2、大容量的併發性
比如單機1000-2000線，實際應用能到480路併發就可以，相當於單機16E1，夠大了。
大容量併發的瓶頸在媒體處理。
好在現在服務器的性能都很好了，當然，必須要有優良的結構設計。
3、穩定性
系統的應用，是成爲運營商IMS上的一個AS（帶媒體功能的應用服務器），或者IP呼叫中心的軟交換部件，或者是個可編程的信令或媒體網關，
總之是個需長期穩健運行的服務器。
（經過一段時間應用測試，目前可以說相當穩定了）
4、功能
首先要合乎標準，如SIP的標準，RTP的標準，DTMF的常用標準等。不一定實現標準的全部，但最主要的部分要實現（至少要和其他系統能夠互聯互通）。
通話要清晰，通話質量優先（帶寬不重要了）。
支持多帳號註冊，自動維護註冊狀態。
雙方通話或多方會議。
文件播放或錄製，可對會議進行放音或錄製。
取捨決策：
1、僅考慮windows環境
windows服務器現在已經很穩定了，但可維護性比Linux強的多。
當然，我採用C/C++實現，要移植到別的系統，不難。
2、先實現IpV4和UDP
傳輸層是獨立的模塊。IpV6，TCP，沒問題，有需要的時候我增加模塊即可。
3、先實現G711A編碼
G711A即A率8000採樣的單聲道PCM編碼，我國電話網上的標準就是這個編碼。
首先，語音質量最好。其次，因爲和電話網接口一致，省去轉換的麻煩。另外，編碼簡單，在會議混音是佔用CPU最少，能夠做到大容量併發。
缺點，佔更多的帶寬，僅聲音有效載荷部分每個通道就要佔用64K的帶寬。
這個決策基於這個前提：網絡帶寬按摩爾定律增長，帶寬越來越不是問題，通話質量比帶寬更重要。
其他編碼和視頻等暫不支持。
4、DTMF
僅實現RTP的101載荷，和Xlite等是一樣的。
按照RFC2833標準實現。
5、需要支持會議
某些呼叫中心應用，多方通話是常見的。
6、支持某些語音卡
支持三匯的全部系列語音卡，因爲他們有實時的IP錄放音接口。
這樣可以構造及其簡單和低成本的IP呼叫中心或媒體網關。
7、RTP採用JrtpLib開源庫
這個庫是C++實現的，接口簡單，很好。
8、不考慮實現爲客戶端協議棧
或者說，不優先考慮。
SIP協議棧實現：
1、概念（基本上和RFC3261一致）
消息 - SIP原始消息，包括請求消息和應答消息
字段 - SIP字段頭域
對話 - 標識一次呼叫
事務 - 對話內的一個小來回，比如Invite事務或Bye事務
TU - 會話用戶
簡化起見，每個TU最多隻能進行一個對話，對於服務器而言一個通道就是一個TU，因此可能有幾千個預先創建好的TU對象
會話 - 一般是指接通後進行的媒體會話
2、實現
傳輸層 (負責消息的收發。收到的消息並不解析直接放到緩衝隊列)
消息緩衝層(隊列)
事務層 (構造事務或處理事務狀態機)
TU層
驅動層 (對消息解析然後匹配到對話或事務)
API層 (C語言接口，供應用層調用)
媒體庫實現:
Channel對象 - 媒體通道，裏面一般包含rtp對象; 外部通道，則提供接口給語音卡層面連接
Rtp對象 - 負責進行媒體流的收發
收發器 - 比如rtp發送器，rtp接收器，文件播放play（是個接收器，從文件接收數據），文件錄音rec（是個發送器，將混音後的數據發送到文件）
線程池 - 通過配置線程池的大小，可以優化性能。
Session對象 - 會話可以連接多個通道，即相當於通道加入到會話，可以以只聽方式加入。會話對象類似於多人會話的會議室。
驅動層
API層 (C語言接口，供應用層調用)
如何實現高性能：
1、多線程
2、簡單的並行算法
3、簡單的對象之間的接口
小試牛刀，最近的兩個應用：
1、外呼營銷中心
爲了節省費用並控制顯號，他們和一外地voip運營商合作，該voip運營商提供數個sip帳號。
傳統辦法：用XLite軟電話手工呼叫，需要很多帳號，而且不方便系統控制（如錄音和業務管理）。
採用藍星際系統：
座席 --> 藍星際系統（SIP協議棧）--> Voip運營商
系統集中分配號碼，控制呼叫，並對每個通話進行錄音。操作和使用習慣就和他們原先基於E1的外呼營銷系統一樣。
藍星際系統是個純軟件，安裝在一個windows2003的4核服務器上。
屬於呼叫密集型應用，60多個座席不通呼叫，每次通話都進行錄製，錄製格式爲A率8000採樣的wav文件（後臺會自動壓縮爲Mp3存儲）。
通話聲音很清晰。
2、WebCall
客戶是經營增值業務的。
他們的企業客戶通過Web集成的頁面，進行WebCall，進行兩方的會話或多方的會議。
普通手機、固話號碼和SIP分機可以一起進行通話或會議。
企業客戶業務系統通過WebService方式調用我們開發的WebCall接口。
藍星際平臺SIP for三匯卡，採用4E1三匯語音卡。
操作系統windows2003 server。
鳴謝：Greg Cheng, Steven Shen
