---------------------------神奇的分割线 以下内容为干货------------------------------------
本文以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。
参考资料
SIP RFC5626
OUTBOUND PROXY http://www.voip-info.org/wiki/view/SIP+outbound+proxy
新浪微博：@安静的发狂者
QQ:229675152
专注于移动互联网音视频通信领域，欢迎交流；本文为原创，转载请保留版权并联系作者