奇怪的 SIP 呼叫流程
最近幾天幫助泰國的朋友檢查一個呼叫業務流程，其中涉及很多細節和業務流程，不過讓我覺得特別意外的是他使用的 VoIP 運營商的 SIP 呼叫流程。首次遇到這樣的流程，請先參考下圖的概要描述：
通常的 SIP 呼叫流程在發起呼叫時就明確指示自己的真實媒體信息，因此在被叫應答後，沒有必要再發起 reINVITE 流程。然而這家運營商為什麼要放棄傳統做法、採用這麼奇怪的流程呢？
這家運營商是美國的一家運營商，而且規模很大，其設備供應商也是一家世界級的大軟件公司（非常、非常大），因此這個流程肯定不是隨意修改的結果，必定有其特殊的目的。仔細揣摩後，我認為它可能是為了節省媒體資源才這麼做。
被叫方一般會振鈴幾秒、十幾秒、甚至幾十秒後，才可能應答。另外，呼叫量特別大時，統計上只有10%左右的呼叫最終才會應答。這家運營商採用這個流程，只需要在被叫真正應答之後才開始分配媒體資源，考慮到這是一家規模很大的運營商，這種流程確實可以節省很多的媒體資源。
VoIP 網絡往往是主叫播放回鈴音，因此這是個非常聰明、折中的呼叫流程，確實只有在被叫側應答之後才處理真實媒體流。然而現實網絡組網是非常複雜的，這個聰明到有些投機取巧的方法有固有的缺陷，請參考下圖：
被叫側如果對接了傳統的 PSTN 網絡，例如 VoIP 網關，很有可能直接返回 183 消息並攜帶被叫的媒體信息。傳統的 PSTN 網絡往往是被叫側播放回鈴音，並且也有一些被叫側放音的業務（例如“彩鈴”），此時這家 VoIP 運營商就有問題了。
由於它告訴給被叫的地址是“0.0.0.0”，因此被叫振鈴音（或者業務音）就無法傳達到主叫側。 VoIP 運營商可以向被叫發送 UPDATE 消息來傳遞自己的真實媒體信息，但被叫未必會支持 UPDATE 消息，這個是擴展消息，不是所有的 SIP 設備都必須支持。而且 PSTN 網絡往往會要求對 18x 消息用 PRACK 流程確認，因此即便支持 UPDATE 消息，這個特殊流程實際也急劇放大了被叫側振鈴階段流程的複雜度。
这也就是我们的泰国朋友遇到的问题。
解决方式是在 VoIP 运营商与 PSTN 网络之间架设 miniSIPServer：（1）miniSIPServer 与 VoIP
之间建立完全应答的呼叫通道； （2）miniSIPServer 与 PSTN 之间维持正常的呼叫流程；（3）miniSIPServer
判断被叫侧是否自己放回铃音（或者业务音），如果（a）被叫没有放音，则 miniSIPServer 主动给 VoIP
运营商放回铃音（或者呼叫等待音），而如果（b）被叫有放音，miniSIPServer 则直接建立两边的通道，让主叫直接听被叫的放音。
留言