為了處理對話(huà)存活機制進(jìn)行管理，SIP協(xié)議支持了一個(gè)非常重要的關(guān)于定時(shí)器的擴展協(xié)議，這就是RFC4028。在此協(xié)議中規定了兩個(gè)針對SIP會(huì )話(huà)超時(shí)定時(shí)器：Session-Expires（SE）和Min-SE（MSE）。這里提醒讀者，一些人理解這里的M為MAX了，當然后續就會(huì )有很多悲劇出現。Session-Expires 終端用來(lái)通過(guò)INVITE或者UPDATE傳輸會(huì )話(huà)生命周期，Min-SE用來(lái)傳輸代理服務(wù)器端允許最小會(huì )話(huà)周期值。UAs通過(guò)周期性地發(fā)送re-INVITE或者UPDATE請求來(lái)保持會(huì )話(huà)存活狀態(tài)。示例中是鼎信SIP 話(huà)機設置中關(guān)于定時(shí)器（SE）設置：
根據RFC4028-5，MSE默認設置為90秒，通過(guò)響應碼422返回中傳輸。服務(wù)器端通過(guò)MSE設置來(lái)校驗其設置范圍，鼎信IPPBX UC200 示例關(guān)于定時(shí)器設置:
通過(guò)終端（SE）和服務(wù)器端（MSE）設置可以看出，盡管在用戶(hù)端設置了某個(gè)參數值，但是如果超過(guò)了服務(wù)器端MSE的設置，仍然不會(huì )成功設置。因為服務(wù)器端MSE也進(jìn)行了設置處理。在具體的關(guān)于SIP話(huà)話(huà)定時(shí)器的SE和MSE的處理流程如下：
關(guān)于SIP會(huì )話(huà)超時(shí)SE和MSE協(xié)商機制-RFC4028
在以上示例中，我們可以看到，用戶(hù)通過(guò)INVITE發(fā)送一個(gè)SE為：50秒，服務(wù)器端不接受，因此返回一個(gè)422（參考rfc4028-6），假設服務(wù)器指示僅接受最小80秒的MSE。終端又根據服務(wù)器端的設置最小要求，設置為SE為80秒。代理服務(wù)器 1 看到終端按照此建議值設置了SE，滿(mǎn)足了自己本身的MSE要求，然后轉發(fā)到第二個(gè)代理服務(wù)器，在設置中設置了SE 80秒，MSE也是80秒。假設第二個(gè)代理服務(wù)器同樣也不能接受這樣的設置，也對第一個(gè)代理發(fā)送一個(gè)建議的MSE值：90秒。第一個(gè)代理服務(wù)器通過(guò)和第一個(gè)終端協(xié)商后又重新發(fā)送一個(gè)新的SE設置為90秒的定時(shí)器超時(shí)設置，并且攜帶了第二個(gè)代理服務(wù)器的MSE定時(shí)器設置90秒。最后實(shí)現存活機制流程。
通過(guò)以上關(guān)于ME和MSE處理機制的流程我們看到，用戶(hù)側不能任意設置ME，服務(wù)器端也需要小心設置MSE值。因為，MSE事實(shí)上是一種對服務(wù)器的一種保護機制，如果服務(wù)器端對話(huà)話(huà)處理能力遇到性能瓶頸，資源不足的話(huà)，SE設置過(guò)低，導致服務(wù)器端驗證響應過(guò)于頻繁，可能最后導致系統穩定性問(wèn)題。筆者這里僅介紹了關(guān)于會(huì )話(huà)定時(shí)器SE和MSE的關(guān)系設置，在SIP服務(wù)器的環(huán)境配置中還有其他的定時(shí)器討論需要讀者做進(jìn)一步的了解，通過(guò)這些定時(shí)器設置獲得更多關(guān)于SIP處理的時(shí)間設置：
參考資料：
- https://www.rfc-editor.org/rfc/rfc4028.html
- www.dinstar.cn
- www.asterisk.org.cn
