SIP、NAT问题阐述及其解决方案分析(2)

 3 ．服务器端解决方案

　　服务器端解决方案主要包括： B2BUA （ Back-to-BackUserAgent ）、服务器端 RTP 中继。

　　 B2BUA 是一个接收请求并充当 UAS 处理请求的逻辑实体，主要是通过两个 UA 以 Back-to-Back 的工作模式控制经过它的呼叫。 B2BUA 与 SIP 代理服务器不同， B2BUA 可以接收呼叫，并能对其进行修改，以其它形式代表发起呼叫的 UA 向终端目标发起呼叫，并能充当呼叫双方的媒体协商代表或对其进行监控管理。 B2BUA 可以对经过它的来自于私网的呼叫进行处理完成 NAT 的穿越。为适应所有类型 NAT 的环境， B2BUA 也需要做媒体流的中介，因此，对于通信双方来说，呼叫控制信令和媒体流在传输过程中均增加了一跳，随着用户的增加， B2BUA 将成为系统瓶颈。

　　服务器端 RTP 中继的方式相对 B2BUA 有所改进，它将 B2BUA 所完成的功能集成到了 SIP 代理服务器上，由 SIP 系统中的代理服务器完成信令部分的 NAT 处理修改，另外增设独立运行的媒体中继服务器来完成媒体流的中继。也就是说，将信令部分的 NAT 穿越和媒体流部分的 NAT 穿越分离开来，由不同的功能组件完成。服务器端 RTP 中继方式相对 B2BUA 来说，具有更好的可扩展性，目前已经被推认为在对称性 NAT 环境下的首选解决方案。

　　三、服务器端 RTP 中继的工作原理

　　通过中继 RTP 媒体流穿越 NAT 的方法，其工作原理可以简单描述为： SIP 代理服务器对私网内用户呼叫的信令进行解析与处理，改写其中的某些头域，使得对应的响应消息以及随后的 SIP 信令可以顺利地在通信双方间传递；改写 SDP 中携带的 RTP/RTCP 地址信息，使得会话中随后的媒体流均经过指定的媒体中继服务器中继，从而完成信令和媒体流的 NAT 穿越。对于呼叫方和被叫方来说，媒体中继服务器均扮演着对方通信实体的角色。采用中继 RTP 媒体流穿越 NAT 方法建立会话的过程如图 1 所示。

　　 SIP 代理服务器需要修改的信息包括：

　　（ 1 ）最外层的 Via 头域：添加 received 和 rport 参数，记录下接收到消息的源地址，使得此消息对应的回应消息能顺利返回。

　　 (2)Contact 头域：修改成接收到消息的源地址，使得消息的接受者能将随后的消息发送到正确的地址。

　　 (3)SDP 中描述媒体的 RTP/RTCP 相应的 IP 地址和端口：对于需要 NAT 处理的会话邀请请求 INVITE ， SIP 代理服务器请求媒体中继服务器分配地址和端口用以中继媒体流，并且将 INVITE 和 200OK 的 SDP 中的 c= 和 m= 参数修改成分配的地址，从而使双方媒体流通过媒体中继服务器中继。

　　媒体中继服务器的功能是中继转发会话双方的媒体流数据包。当一方的 RTP 数据包到达媒体中继服务器时，媒体中继服务器记录下发送数据包的源地址；当接收到另一方的数据包时，媒体中继服务器就知道了向何处转发。这是非常必要的，因为 SIPUA 媒体流只有真正穿过 NAT 之后， NAT 地址映射关系才会建立，相应的映射地址才是可知的。

　　值得注意的是，媒体中继服务器只有在接收到通信两方发送的第一个 RTP 包之后，才能建立起中继路径，并转发会话双方的 RTP 媒体包。在对称性 NAT 的情况下，客户终端必须使用同一个 IP 地址 /port 端口来发送和接收 RTP 数据包，即为对称性 RTP 。

　　四、总结

　　综上所述， SIPNAT 问题已有多种解决方案。客户端解决方案，虽然无需对现有 NAT 做任何改动，但对 SIPUA 的要求较高，需要支持相应的协议，而且到目前为止还无法解决通信双方均处在对称性 NAT 的情况；路由边界的各种解决方案，均需要对 NAT 设备升级，但目前网络实际已部署了大量的不支持相关特性的 NAT 设备，因而这种方式可行性较差；服务器端解决方案，通过中继 RTP 数据包来解决所有类型 NAT 的穿越，缺点就是增加了包的时延和丢包的可能性。具体采用哪种方式解决 SIPNAT 问题需要从以下角度进行综合考虑：（ 1 ）升级要求：哪些网络元素需要做升级；（ 2 ）网络业务量：应用这种解决方案后，是否会引入新的网络开销；（ 3 ）语音质量：此解决方案是否影响语音质量，增加时延或丢包率；（ 4 ）运营商的投资：运营商是否需要做大量投资；（ 5 ）企业投资：如果面向企业客户，企业是否需要做大量投资；（ 6 ）确定性：此解决方案是否只能在特定环境下生效，是否可以支持各种应用方案，是否可以穿越各种 NAT ；（ 7 ）扩展性：此方案是否支持大规模应用。

(结束)