奇怪的 SIP 呼叫流程
最近几天帮助泰国的朋友检查一个呼叫业务流程，其中涉及很多细节和业务流程，不过让我觉得特别意外的是他使用的 VoIP 运营商的 SIP 呼叫流程。首次遇到这样的流程，请先参考下图的概要描述：
这个流程的奇怪之处在于：（1）VoIP 运营商发起呼叫时，INVITE 消息的媒体地址居然是“0.0.0.0”，这很明确告诉被叫：主叫只发送媒体流、甚至根本不处理媒体流；（2）被叫应答后，VoIP 运营商再次发起 reINVITE 流程，此时才真正指示出自己的真实媒体地址（当然也包括最终的媒体编码）。
通常的 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 则直接建立两边的通道，让主叫直接听被叫的放音。