【正文】 sg, TransactionUser* tu = 0)。 一、發(fā)送消息的兩個重載函數(shù)： /** Interface for the TU to send a message. Makes a copy of the SipMessage. Caller is responsible for deleting the memory and may do so as soon as it returns. Loose Routing processing as per RFC3261 must be done before calling send by the TU. See Helper::processStrictRoute param msg SipMessage to send. param tu TransactionUser to send from. */ void send(const SipMessageamp。 (msg, TimeLimitFifoMessage::InternalElement)。 現(xiàn)在我們先重點關(guān)注一下 sendToTU： void TransactionState::sendToTU(TransactionUser* tu, TransactionControlleramp。 controller, TransactionMessage* msg)。 正是 setTransactionUser 給予消息 Transaction User 歸屬。 } TransactionUser* tu。 void setTransactionUser(TransactionUser* t) { tu = t。 因此接口類 Message中存在這個函數(shù)就不足為奇啦： class Message { 。 把 SipStack中的 Transaction User 角色獨立出來交與一個獨立的類管理是個不錯的選擇。 tu) { (tu)。這個函數(shù)基本上能 讓我們看到 TU 和 SipStack交互間其 visitor/observer模式的影子。)。 在整個的協(xié)議棧架構(gòu)中 SipStack 處于 承上啟下的位置，它既面向 DUM層 (表現(xiàn)為向DialogUsageManager 服務(wù) )又可以直接為外界（如 UI）所用；列舉其主要面向外界的接口函數(shù)： /** Adds a TU to the TU selection chain. Tu39。因此兩者在層次上也是不一樣的。 Session 是基于 SDP Message 的交互，沒有 SDP 的交互， 就沒有 Session。在 Dialog 狀態(tài)下雙方不一定可以作雙向的 RTP 傳輸。有一個最為重要的區(qū)別是： Session 是完成了 SDP 的OfferAnswer 過程，也就是此時雙方可以進行雙向的 RTP 傳輸了。二者的分別主要基于目前出現(xiàn)的 subscription 應(yīng)用，對于 session 和subscription 可以共享一個 dialog， dialog 由基本的會話標識組成， 如 CallID,FromTag,ToTag，以及一些目的 target 等共性單元組成。 個人 一直比較喜歡這段論述： session 有兩種含義，一種是傳統(tǒng)意義上的 RTP 會話，一種是信令意義上的會話。 而上面的各個對象的 PROCESS 或者 DISPATCH 函數(shù)產(chǎn)生的各種狀態(tài)的變化并觸發(fā)相應(yīng)事件。 在 Dum（ DialogUsageManager）的類中基本上這樣一條線 (以 INVITE 為例 )： DialogUsageManager 產(chǎn)生 Dialog Set, Dialog Set 產(chǎn)生 Dialog, Dialog 產(chǎn)生InviteSession。 1 也許是事務(wù)用戶層 DialogUsageManager 是 sip 事務(wù)層管理類，是一個大總管的角色；看其 Makexxx 系列的函數(shù)能明白它能發(fā)起一系列登陸、會話邀請的動作及其回復(fù)。 DUM 利用事件回調(diào)模型，事件響應(yīng)可以選擇繼承系列 XXXHandler 抽象接口，并向 TU 注冊，以實現(xiàn) VISITOR 模式 。 msg)…… 狀態(tài)機的位置： DialogUsageManager::iningProcess， DialogSet::dispatch， Dialog::dispatch 在整個 Resiprocate 大家族中事務(wù)層概念 1的體現(xiàn)是 TransactionUser 類，而其真正的實現(xiàn)和管理類就是 DialogUsageManager；從其： class DialogUsageManager : public HandleManager, public TransactionUser 能看出來； HandleManager 點出了 DialogUsageManager 的管理功能的本質(zhì)，并且管理各種對象（ Handle 是各類對象的句柄）。 return mLastId。// typedef HashMapHandled::Id, Handled* HandleMap。 ham) : mHam(ham), mId(Handled::npos) { mId = (this)。 operator*() const { return *get()。 operator () { return *get()。 } const T* operator() const { return get()。源碼中也非常注重效率如 Sip Core 部分中大量 Hash 表的建立 。 部分設(shè)計的理解 OBSERVER/VISITOR/COMMAND/ITERATOR 模式，工廠模式 (大量容器的使用也是一種變體如 :DialogSet)，代理類句柄類（界面實現(xiàn)分離，隱藏實現(xiàn) ? ） ,?? 大量的界面類 (如 AppXXX 系列 )是遵循大師 BS“界面和實現(xiàn)分離”的原則吧；而句柄方式對對象的間接管理是老外的慣用伎倆啦 ,關(guān)于句柄設(shè)計從大師 BS 的著作到Effective C++的 Handle_Body 論和 C++沉思錄 的大段描述再到 C++ Model Design都有發(fā)揮和外延，感興趣可以觀之。在 Resiprocate中一些 RFC3261 中定義元素的對應(yīng)： 建議：利用 CRC 卡片的方式去記錄理解 Resiprocate 中的大量的類及其關(guān)系。 可以這樣來考慮 ,比如我們知道 RFC 定義了一個 SIP MESSAGE 的概念；下面是從 RFC 文檔拷貝的內(nèi)容： SIP 消息 = 起始行 *消息頭部 CRLF(空行 ) [消息體 ] 因此 SIP Message 這個概念元素還包括了更多的元素和概念； SIP Message 中我們能抽 象出更通用的概念我們暫且叫它 Message。 Resiprocate 中大部分類就是對 RFC3261 各種 SIP 元素、組件的封裝，并且也體現(xiàn)了RFC 協(xié)議設(shè)計的層次。封裝變化的概念。 下面是 SIP 的分層圖示， IETF 堅持分層，不同模塊功能相對獨立，各層之間松散耦合。協(xié)議棧的層次 SIP 為應(yīng)用層 (ApplicationLayer)的協(xié)議，所以不需要改變操作系統(tǒng)便可以支持。 SIP 已經(jīng)獲得 3GPP (Third GenerationPartnership Project)、 3GPP2 (Third Generation Partnership ProjectNumber 2)等機構(gòu)認證，成為未來第三代行動通訊 (3G) 的標準。 事務(wù)用戶層 (Transaction User) 事務(wù)層 (Transaction ) 傳輸層 (Transport) 語法與編碼層 (Syntax and Encoding) 關(guān)于 Resiprocate 設(shè)計 首先祭出這面大旗 ,” 類是對概念的描述，面向接口編程 。 ” 這不是我講的 ,是大師們的口水。 在面向?qū)ο蟮脑O(shè)計中我們首先就要厘清問題域的所在； SIP Stack 的設(shè)計就是要充分考慮完整展現(xiàn) RFC定義的各種元素和概念以及讓這些獨立而又關(guān)聯(lián)的元素互動起來成為一個活的系統(tǒng)。 起始行的概念 E文 Request Line以及 Status Line 又包括了很多消息頭（這是包容的關(guān)系）， SIPURL 也包括消息頭，等等，還有什么參數(shù)什么的元素呢；當我 們在考慮和提煉這些概念和元素的時候，我們思考怎么抽象他們呢，它們又有什么基本的元素及其共性呢？他們之間的關(guān)系如何組織呢？Resiprocate的源碼告訴了我們?nèi)绾稳ピO(shè)計和封裝這些概念的上佳實現(xiàn)。 CRC：類、職責、協(xié)作。 插播： 源碼中的大量 Clone 函數(shù)是模仿大師 BS 的虛擬構(gòu)造函數(shù)一說 ,是原型模式的體現(xiàn)；源碼中對同步的封裝值得借鑒，其中 有“資源開始即初始化”理論的體現(xiàn)；在 DUM 部分回調(diào)機制所遵循的著名“好萊塢原則”；句柄和代理的一個特點就是重載了 operator、operator*等 。 T* operator() { return get()。 } Tamp。 } const Tamp。 } Handled::Handled(HandleManageramp。 } Handled::Id HandleManager::create(Handled* handled) { mHandleMap[++mLastId] = handled。 //HandleMap mHandleMap。 } 1. SIP Stack 分析 1． 1 Resiprocate SIP Stack 系統(tǒng)架構(gòu)圖示 1． 2 FIFO 流的走向圖 1． 3 Sending datagram 1. 4 Process Ining UDP 2. Application/DUM 設(shè)計淺析 抽象接口： CLASS HANDLED ， CLASS InviteSessionHandler(諸如此類 ) ?? 對象之源： CLASS HANDLED（ 多態(tài)和控制的基礎(chǔ) ） … … 交互控制 ： CLASS Handle， CLASS HandleManager…… 概念封裝成類典型 ： CLASS Dialog, CLASS DialogId, CLASS DialogSet, CLASS DialogSetId, CLASS InviteSession… .. Utility 工具類： CLASS BaseCreator , CLASS DestroyUsage, CLASS Profile?? 流動之源： DialogUsageManager::process()， Dialog::dispatch(const SipMessageamp。 在整個 Resiprocate 系統(tǒng)中不管是我們發(fā)出或者收到的 SIP Message 都是放進了先進先出的隊列然后不斷輪詢處理，這有點象 Windows 的消息系統(tǒng)，對應(yīng)收發(fā)的消息 DUM 提供事件通知的機制。我在另外的文 檔 里 也提到這是 Reactor（ Dispatcher,Notifier）模式，應(yīng)用程序開發(fā)者只負責實現(xiàn)具體事件處理程序，并在反應(yīng)器上注冊它們 “ 好萊塢原則 ” 。 Dum 定義了很多句柄管理類，通過它我們能得到真實的對象，從而完成操作，這在事件響應(yīng)中非常有用。 InviteSession 又分 Client InviteSession 和 Server InviteSession。 在 DUM 的 IM/PRESENSE 部分廣泛使用 SUBSCRIBE/NOTIFY 的模式，目前協(xié)議的定義似乎參照成熟的設(shè)計模式。 SIP中的會話指后一種， 在層次上它在 dialog 之上，也就是 dialog 可以看成 session 的組成單元。而 session 除了具備這