明日復明日，明日何其多，說好的處理邏輯，結果一晃就幾個月過去了。

先申明一個前提，只講協議棧處理這部分，其他部分沒看過也不瞭解。

pjsip關於sip訊息的處理邏輯總體來看非常標準，中規中距，就是一個訊息的正常處理過程。

在初始化時建立了讀執行緒在一直在select監聽埠，當有接收到訊息，則將其放到rdata結構中，

通過tpmgr->endpoint完成從所謂的"傳輸層"到modules的傳遞。

後面各個modules的按優先順序處理，其實就是個剝洋蔥的過程：

首先把最基本的剝下來，訊息收發相關的資訊，這是事物層該乾的活，丟給tsx module處理。

然後把"會話"相關的資訊（此會話非sip中的會話概念，就是通俗的理解），剝下來丟給dialog module處理，都是些標識自己屬於某dialog的標識資訊。

最後就是業務相關的資訊，比如說invite，訂閱相關的，比如訂閱的事件型別，剝下來丟給其相應的usage去處理。

後面對該請求的應答，則是反向的一層一層又穿回去。

雖然省略了那些超時、重傳、重傳等待、expire的處理，但整體過程確實就是上面這些。

畢竟協議棧這部分需要乾的活就是收發訊息、序列\反序列資料，只不過好心的幫助上層做了些sip協議的一些要求，

另外將序列化後的資料都是分散存放在各個module（層）中，沒有像通常那樣給個大資料結構，僅此而已。

整體來講還是相當簡單明瞭，end.