一种大规模sip server架构的实现

多年来做sip终端比较多，服务器一般直接采用Asterisk。
最近，做一个通信产品的整合，把桌面IM， WebIM，Voip,Call center等合到一起。这时有时候从整体上考虑一下这些产品的相关性。个人发现，其实，sip架构就是一个IM，甚至，现代的IM的功能和复杂性都远超SIP。那为什么IM的产品非常多，而SIP的Server确一直都在抄开源项目吗？感觉，有点对sip过于神化了，其实，完全可以用普通的方法实现一个大规模的Server。拿以前做过的一个项目来说：

1 linux下使用udp select 模型(连epoll都用不到，压力测试单机轻松过万)。
2 终端发REGISTER，server验证用户名，口令，成功后创建一个CUser对象，追加到user map中， 返回200 OK(演示代码，暂不考虑180)。
3 如果该用户名口令已经存在，删掉原来的，重新生成一个Cusr 对象。
4 终端每30秒发一个保活包。
5 对user map保活操作，每30秒轮循查CUser，超时做相关处理。
6 终端发INVITE，server创建一个Session对象，加到Session map中。Session中包含各种状态机。
7 如果支持穿透NAT，转发INVITE时，由Session负责协调，在SDP中带上源终端音视频的外网IP和端口。
8 Session map也做保活，每一条命令转发后，超时做相关处理。
9 协商成功，转发RTP数据，或双方直接点对点。
10 会话完成，终端 发Bye，从map中删掉该　Session
11 终端 发UnRegister，从map中删掉user


Asterisk代码把所有的逻辑处理都放在一个.c里，这一个.c代码超过2万行，现在想起来看代码的时候还心有余悸。其实，如果做个简单一些的sip proxy，不考虑全面兼容市面上的硬件设备，完全可以按上面的流程自己实现一个。至少，上面的UDP通信，用户管理和会话管理，比Asterisk方便的多，也更容易维护。至少可以解决不同终端用同一账号同时在线，测试过很多视频会议终端和voip电话终端，都有这个现象(当然卖给用户的时候，每个终端的账号都固定设置好了，不会冲突)。