利用开源软件搭建电信级VOIP/IM运营平台--架构篇

浏览数：26 / 时间：2015年06月11日

移动互联网的发展为整个VOIP通信行业开拓了新的战场，一时间各类即时通信软件如雨后春筝般冒了出来，再一次创造了移动互联网的发展神话。SIP协议做为音视频通信的首选标准，应用也越来越广泛。

---------------------------神奇的分割线以下内容为干货------------------------------------

本文以SIP协议为基础，以实现电信级VOIP运营平台为背景，结合当前中国的网络特点，探讨如何构建服务器端平台。

中国是特色社会主义国家，其特色表示在社会生活的方方面面，其中包括我们的三种3G标准，电信和联通的固网布局，也体现在各式各样的网络接入。为满足特色的需要，我们需要完成具有特色社会主义的服务平台，至少满足以下需求：

1。满足最基本条件：负载均衡、冗余备份、稳定性、可用性、可扩展性。

2。中国网络特点：因历史原因形成的天然网络屏障，各种二级运营商林立，各种封杀，各种端口限制、流量限制、协议封杀等，以及各种网络设备、防火墙的奇形怪状问题。

下面我们直接从整个系统的架构开始分析：

SIP服务架构采用两层模式，相对用户而言，第一层是SIP Outbound Proxy，下面简称OB。OB需根据运营商和地域不同，部署在全国各地，具体部署策略一方面是需要考虑成本，另一方面需要考虑所部点的覆盖面，这也决定了用户登录时OB服务器的分配策略。

其主要作用是：

1.扛用户连接，根据之前博文描述《移动互联网SIP在线状态方案分析》建议用户与服务器之间使用TCP连接，因此OB首要任务是接受用户请求。

2.连接保活，不管使用TCP还是UDP，都需要进行保活，具体方案可参见前博文《移动互联网SIP在线状态方案分析》。

3.转发服务，OB是outbound proxy服务，只是接收请求并根据SIP request-line进行转发。

第二层是SIP APP Server, 这些是应用服务器的总称，可根据业务需要添加各类应用服务器，比如用于IM的聊天服务器，即所有MESSAGE消息通过此服务器进行转发；用于视频通信的SIP Proxy；用于处理自助服务的B2BUA；也可以添加用于支持PSTN的计费和路由服务等。下面简称APP。因OB是部署到不同地域、不同运营商的网络中，为保证OB与APP的连接速度，需要将APP部署BGP机房。同时APP服务器不需要直接向用户服务，为保证APP服务器的安全，需要添加防火墙并设置白名单。

通过两层架构，将核心业务层与用户分离开来，SIP 消息的传输是先到用户已连接的OB，然后OB根据不同的业务转到对应的APP，如果是需要转到被叫的，APP服务先从DB中获取被叫的Location信息，然后将消息转发到被叫所在OB，OB再转发给最终用户进行处理。由此带来的好处就是高扩展性，APP可根据业务需求进行无限扩展，同时可以对APP进行热替换升级，而不影响用户正常使用。以下讨论一些实际问题：

1.OB和APP服务器的分配策略：

通常有两种方法，一是有一个配置服务器，由用户主动去取配置，此时就可根据用户的IP信息获取对应的服务器。不过此种方法通常不够准确，一些小的借网运营商出口通常不在当地城市，如果是移动终端建议加上手机号码和GPS经纬度综合计算。同此配置服务也需要收集OB和APP的负载信息及存活信息，以实现动态分配和负载均衡。注意不要让配置服务变成一个单点。

另一种方法是使用DNS动态解析，此方法在网上已有较多介绍，此处就不再敷述。其分配方法可参考以上策略。

2.OB服务端口选择：

不建议使用默认5060端口，较多的防火墙会对5060端口上数据进行过滤。建议使用如443这样的端口，多数防火墙不会去解析此端口数据。

3.应对端口封杀

较多的企业办公网络都有端口限制，并且限制规则各式各样，针对此类问题，在OB上监听多个常用端口，客户端先尝试一个默认端口（解决80%的问题），如果失败再启用多端口检测，连接成功哪个就用哪个。

4.应对攻击

这里提到的攻击是指来自外部的，比如屡试不爽的DDOS攻击。当遇到这种情况那就只能自求多福了，但此架构分为两层，对攻击者而言只能针对某一区域的OB服务器攻击，最坏情况就是某区域停止服务，并不会导致整个系统全部瘫痪。

5.用户有效性

图中的一个用户有两个连接分别连到两个OB服务是指一个SIP UA可以有多个连接，分别连接到不同的OB，且两个连接都是有效的，这是通过sip contact header中的 reg-id来标识的，具体用法见RFC5626。但由此带来的流量也Double了，是否有用就需要根据业务情况权衡了。

6.RTP传输

此文主要描述SIP架构，RTP传输策略之后再描述。

描述此种架构的标准是RFC5626，如果想实现此类方案建议仔细阅读此RFC。