由于SIP系统相对成熟,目前互联网上的SIP系统方案大多数都是基于虚拟机来实现的。
本文是基于容器化实现SIP系统的方案以及遇到的问题总结。
本文会展示两个系统的SIP实现,分别是智能语音机器人和CTI系统,不会涉及太多的业务,只是对于SIP架构实现的讨论。
智能语音机器人系统
在容器化之前,我们的方案也是基于VM的。
整个架构为:
kamailio作为sip服务器
rtpengine作为rtp代理
Freeswitch作为后端b2bua代理
event engine服务负责处理通话到达事件,通过feign通知voip机器人注册机器人坐席到kamailio中。
基于扩展性、安全性考虑,迭代为容器化部署。
升级后把kamailio和Freeswitch使用docker 容器化部署在Kubernetes集群中,为kamailio开发了Operator动态识别Freeswitch实例,放入到数据库dispatcher
表中,并通过binrpc接口通知kamailio reload dispatcher
.
这里另外有一个注意点,Freeswitch需要优雅启动和优雅关闭。
因为RTPEngine需要开放范围UDP端口,在clb下无法配置,所以最终采用安全组方式再虚拟机上配置。
clb需要开4层代理 domain 域名。
kamailio中 alias
domain。
CTI外呼系统
第二个是CTI外呼系统,在容器化之前也是基于VM架构实现的。
蓝色为呼叫起点.
由于当时未解决WebSocket加入Kamailio,所以选择坐席接入到Freeswitch中了,人工外呼在Freeswitch中进行处理外呼。
机器人外呼主要是在kamailio中,通过dispatcher配置外呼,但是呼人工的时候,需要通过Freeswitch联通Freeswitch。
CTI系统容器化之后解决了几个问题
- 解决了WebSocket集成Kamailio和WebRTC集成RTPEngine的问题。
- 统一呼出起点都是从Kamailio出发,从而使业务程序更加清晰复用。
容器化之后整个并行的通话数可以通过扩容Freeswitch的方式扩容