Keep-alive
在 SIP 通訊領域，keep-alive （保活）有兩種：設備的 keep-alive 與會話（session，dialog）的 keep-alive。 設備的 keep-alive 目前大家都有成熟統一的解決方案，並且符合 RFC3261 的要求，那就是採用 OPTIONS 操作進行檢測，如果對端設備返回 200OK 則說明設備 keep-alive。 終端採用 REGISTER 也可以偵測設備 keep-alive。 各廠商一直沒有會話 keep-alive 的統一解決方案。 RFC4028 規範雖然定義了 reINVITE 和 UPDATE 用於會話 keep-alive 檢測，但是這兩個操作用於會話檢測顯得太複雜了，會導致重新協商媒體，影響會話的通話品質。 目前各廠商的想法倒是基本一致：既然正常的 reINVITE 和 UPDATE 操作會導致新的媒體協商，那不攜帶 SDP 是不是就可以直接用於會話的 keep-alive？ 當然， reINVITE 是例外，「reINVITE without SDP」已經被用於 3PCC 流程，因此不可能再用於會話 keep-alive 操作。 我們根據歷年與各廠商設備對接的經驗，總結以下用於會話 keep-alive 的操作： UPDATE without SDP INFO without SDP MESSAGE without SDP 最新版本 miniSIPServer 的預設處理方式：如果在會話過程中收到上述三種 SIP 訊息，將進入會話 keep-alive 處理流程；如果會話存在，則傳回 200OK 訊息。 UPDATE 和 INFO 本身就只能在會話中傳遞，因此天然契合 keep-alive 的要求。 我們推薦優先採用 INFO，RFC3261 明確定義了 INFO，各廠商設備一定會支援 INFO 操作。 而 UPDATE 作業定義在補充協定中，部分廠商的設備未必會支援 UPDATE，更遑論 「 UPDATE without SDP 」 。 MESSAGE 即可以在會話內傳遞，也可以在會話外發起，用於傳遞即時訊息（instant message）。 我們限定 「 MESSAGE without SDP 」 只能在會話內傳遞，並保留給 keep-alive 流程處理。 ...
