明日復明日，明日何其多，說好的處理邏輯，結果一晃就幾個月過去了。
先申明乙個前提，只講協議棧處理這部分，其他部分沒看過也不了解。
pjsip關於sip訊息的處理邏輯總體來看非常標準，中規中距，就是乙個訊息的正常處理過程。
在初始化時建立了讀執行緒在一直在select監聽埠，當有接收到訊息，則將其放到rdata結構中，
通過tpmgr->endpoint完成從所謂的"傳輸層"到modules的傳遞。
後面各個modules的按優先順序處理，其實就是個剝洋蔥的過程：
首先把最基本的剝下來，訊息收發相關的資訊，這是事物層該幹的活，丟給tsx module處理。
然後把"會話"相關的資訊（此會話非sip中的會話概念，就是通俗的理解），剝下來丟給dialog module處理，都是些標識自己屬於某dialog的標識資訊。
最後就是業務相關的資訊，比如說invite，訂閱相關的，比如訂閱的事件型別，剝下來丟給其相應的usage去處理。
後面對該請求的應答，則是反向的一層一層又穿回去。
雖然省略了那些超時、重傳、重傳等待、expire的處理，但整體過程確實就是上面這些。
畢竟協議棧這部分需要幹的活就是收發訊息、序列\反序列資料，只不過好心的幫助上層做了些sip協議的一些要求，
另外將序列化後的資料都是分散存放在各個module（層）中，沒有像通常那樣給個大資料結構，僅此而已。
整體來講還是相當簡單明瞭，end.
spring restful的一些個人總結
額，好像就乙個 使用 pathvariable接收引數，引數值需要在url進行佔位，前端傳參的url url main mm am edit public string edit pathvariable long id,pathvariable string name 並且 pathvariabl...
一些個人的想法
今天是2016年4月2日，星期六。目前我已經在網際網路行業裡摸爬滾打了三年有餘，加上七年的求學生涯，轉眼一看已經十年了。過去的十年是網際網路行業蓬勃發展的十年，雲計算 資料探勘以及移動網際網路的興起讓我們的生活出現了翻天覆地的變化 在這個遍地充滿機會的時代裡，出現了乙個又乙個的弄潮兒 這是乙個最好的...
關於介面測試的一些個人總結
什麼是介面測試？所謂介面，我理解的就是乙個開關，我們通過在外面向開關發出一些指令如 開燈 關燈 調亮 調暗 等，檯燈會根據你的指令給你對應的反饋。如果你發出了調暗的指令，檯燈直接給你關掉了，那就是說明這個介面返回是有問題的。常見請求方式 get 通過請求url得到資源 post 用於新增新的內容 p...