pjsip協議棧的一些個人總結2
阿新 • • 發佈:2018-12-11
明日復明日,明日何其多,說好的處理邏輯,結果一晃就幾個月過去了。
先申明一個前提,只講協議棧處理這部分,其他部分沒看過也不瞭解。
pjsip關於sip訊息的處理邏輯總體來看非常標準,中規中距,就是一個訊息的正常處理過程。
在初始化時建立了讀執行緒在一直在select監聽埠,當有接收到訊息,則將其放到rdata結構中,
通過tpmgr->endpoint完成從所謂的"傳輸層"到modules的傳遞。
後面各個modules的按優先順序處理,其實就是個剝洋蔥的過程:
首先把最基本的剝下來,訊息收發相關的資訊,這是事物層該乾的活,丟給tsx module處理。
然後把"會話"相關的資訊(此會話非sip中的會話概念,就是通俗的理解),剝下來丟給dialog module處理,都是些標識自己屬於某dialog的標識資訊。
最後就是業務相關的資訊,比如說invite,訂閱相關的,比如訂閱的事件型別,剝下來丟給其相應的usage去處理。
後面對該請求的應答,則是反向的一層一層又穿回去。
雖然省略了那些超時、重傳、重傳等待、expire的處理,但整體過程確實就是上面這些。
畢竟協議棧這部分需要乾的活就是收發訊息、序列\反序列資料,只不過好心的幫助上層做了些sip協議的一些要求,
另外將序列化後的資料都是分散存放在各個module(層)中,沒有像通常那樣給個大資料結構,僅此而已。
整體來講還是相當簡單明瞭,end.