关于开发:基于声网的音视频SDK和FreeSWITCH开发WebRTC2SIP-Gateway-方案和思路

为什么做这个？

今年初接到一个我的项目工作，客户要求在本人的音视频平台零碎中集成 webrtc 性能(原零碎是基于 SIP 协定开发的，曾经稳固运行多年，有很多客户)。在比对了多家 RTC 产品的成果后，。他们对声网音视频 DEMO 成果后十分称心，指定要求用声网的 SD-RTN 传输网络，全面革新客户端软件。据客户实测，在某些国家和地区，同样网络环境下比微信要好很多，比方在东非和中国之间语音通话，提早很小、声音也更清晰。

话不多说，先列下客户要求和以后产品的问题：
1、要求全面革新 Android、IOS、Windows、MacOS、Web 版 5 个平台的客户端软件，原来的客户端别离是基于 Pjsip、Linphone、Sipjs 开发的；
2、要求在网络环境差的中央，也能满足清晰语音通话的要求（声网专为此而生）；
3、最小侵入性，尽量不扭转服务器端的零碎性能，实现客户无感降级；
4、解决 SIP 协定常常碰到丢包、被过滤 UDP 等无奈呼叫，或者呼叫听不清的问题；
5、解决 SIP 服务器常常被尝试攻打呼叫、歹意扫描注册攻打等行为，进步零碎稳定性；
6、实现 WebRTC 协定和 SIP 协定的双向互通，既要兼容 SIP 呼叫，反对 RTC 客户端送呼叫到 SIP Server，也要反对 SIP Server 呼入到客户端软件（在声网的音视频实时传输网传输）。.

其实刚接到需要的时候，大家一起探讨剖析过，感觉这种我的项目看着有不少估算，然而要做的是全平台的客户端，开发工作沉重，要思考的细节也比拟多，没准是个坑，能不能达到客户冀望难说，少数共事不倡议做。而后在领导和客户一起去 happy 一晚后，这活儿不晓得怎么就接了下来。
老板理由很简略，这也不做那也不做，那咱们能够做什么？如果谁都能做，客户还会找咱们吗？那就干吧，马上口头，各种查资料，翻阅声网的技术开发文档，并征询声网的技术同学。2 天后拿出初步计划。

                            零碎架构图

解决思路：
1、本人写信令模块，放弃灵活性，简略实现：开发 TCP Server 承当信令服务器；
2、外围是开发一个 SIP2WebRTC/WebRTC2SIP 协定转换网关，保护一个状态机;
3、开发音视频编解码处理器，解决声网语音和 SIP 语音编码互通；
4、开发一个状态治理模块，SessionManger，以保护客户端的状态 IP+ 端口；
5、联合声网的音视频 SDK，集成本人的信令模块，实现和 WebRTC2SIP 模块通信；
6、自定义常见的 SIP 呼叫信令，供各平台客户端保持一致。
罕用的 SIP 信令有：1 注册、2 呼叫、3 接听、4 挂断、5 拒接、6 勾销、7Hold、8DTMF、9 用户未反映、10 用户离线、11Transfer、12 会议(我简略介绍后面的 6 个)

咱们暂且把这个零碎命名为 WebRTC2SIP Connector 或者 SIP2WebRTC Connector 吧。至于为什么这么叫，我也不晓得，可能叫 XX Gateway 的太多了，不这么叫显不出声网的 SD-RTN 有多牛 X，我是他爹，想叫什么都能够。

理清思路后，咱们须要确认几个外围问题：
1、以哪个平台的 SDK 为根底开发这个 WebRTC2SIP Connector 外围模块？
2、Agora SDK 是否反对多并发呼叫？
3、声网的语音编码格局和视频编码格局是什么？采样率多少？
4、SIP 客户测有没有什么具体的编码要求？客户可承受固定一个语音编码，我抉择 PCMA

这里特别感谢一下声网，对咱们这种小众需要做出了疾速响应，也感激声网技术支持同学 Nemo，专门来到公司交换了几个小时，并分享了一些技术信息。
他倡议咱们：
1、用 Agora Windows SDK 或者 Linux SDK 开发协定转换模块；
2、2 个 SDK 都反对多并发呼叫；
3、语音是 pcm 格局，视频是 yuv 格局；采样率是 48khz

到这里心里有数了，简要文字描述下大略流程就是：
1、各客户端 SDK 启动的时候，发动 TCP 连贯，登录 TCP Server 信令服务器, WebRTC2SIP 转接模块初始化也发动 TCP 连贯登录 TCP Server，由 TCP Server 记录大家的 UID，IP 和端口等信息。
2、呼叫的时候，申请一个房间号，并依据自定义信令格局发动 calling 报文，TCP Server 收到后，转发给转接模块 WebRTC2SIP，WebRTC2SIP 收到后创立 1 个线程，解析报文，并启动声网的 SDK，退出指定房间号，开始读取音频流程，同时启动线程，封装 SIP 规范报文，发动 sip invite 申请给电话服务器 SIP Server; SIP Server 收到呼叫申请就去呼叫被叫电话号码，并返回 ring 振铃信号；WebRTC2SIP 收到振铃信号，封装自定义的振铃信息给客户端 SDK，被叫接听后，WebRTC2SIP，启动 Media Coder 开始解析媒体流，并 resample 后，写入到声网的房间外面。实现语音通话。形容个大略，置信能看明确。
3、从 SIP 呼入到声网的 SDK，大同小异，反过来。

这里要留神：
1、每个终端都要自定义编号；
2、每个呼叫都要退出声网的房间 channel 实现音视频互通；
3、因为编码不一样，所以须要 resample 这个很重要，不要接通了没有声音，单方不匹配。
4、WebRTC2SIP 模块要多线程形式解决，以实现并发呼叫；
5、WebRTC2SIP 模块要保护一个残缺的状态机，给每个通话加惟一编号，不至于出错。

到当初咱们讲清楚了大略的解决方案和技术思路，看到这里，各位客官应该明确了，其实这个做起来没啥难度，至多当初看来是这样的。

基于声网的音视频 SDK 和 FreeSWITCH 开发 WebRTC2SIP Gateway 报文设计（二）
上一篇咱们提到，罕用的 SIP 信令有：1 注册、2 振铃、3 呼叫、4 接听、5 挂断、6 勾销
有了这几个报文，电话的呼入和呼出就能够根本实现，其余拒接、DTMF 等相似。
如图所示：

约定：
1、客户端和服务器端 JSON 格局交互；
必传参数：
msgtag 是音讯惟一标记，
userid 是谁触发的，
appid 作为一个利用的标记。
sign 签名加密 (看状况)
2、服务器返回的报文必须包含 msgtag \appid\errcode
errcode=1 阐明有谬误 errmsg 就会有值；如果 errcode=0 阐明返回后果正确
个别是返回的 msgtag 是申请的 msgtag+”_res”做为辨别
3、roomID 是房间号对应声网的渠道号, 每个通话报文必须包含 roomID 用处是什么本人想。
4、callType 是 video audio 前者代表视频呼叫，后者代表语音呼叫
5、direction 呼叫方向
in 呼入 (SIP Server 把呼叫送到声网的 SDK)
out 呼出（SDK 把呼叫送到 SIP Server）
6、isSIP yes no 代表这通呼叫是外部呼叫（声网客户端实现）还是 SIP 呼叫（走落地）

这篇文章我只是简略列出外围的报文 DEMO 格局。
信令 1：注册报文

响应报文：

信令 2：呼叫报文

响应报文：

信令 3：振铃报文

响应报文：

信令 4：接听报文

响应报文：

信令 5：挂断报文

响应报文：

信令 6：勾销报文

响应报文：

如图下面设计的报文非常简单，置信大家都看得明确。不须要过多语言阐明，供大家参考吧。
不管客户端还是 WebRTC2SIP connector 实质上都是声网的音视频 SDK 客户端，而后集成了自定义的报文，所以他们初始化的时候，须要调用一个专门的的接口临时叫做 initSIP，调用这个接口的时候传递 type 类型参数；如果是手机端或者电脑端、网页端调用，返回 TCP Server 地址和端口, 供他们建设连贯；如果是 connector 转接服务器申请的话，除了返回 TCP Server 地址和端口外，还要返回 SIP Server 地址及端口，以及呼叫送号前缀。不然 SDK 发动电话呼叫的时候，connector 不晓得电话要转送到哪里。这个开发一个 http 接口就能够实现。

APP 初始化，调用 initSIP 接口，建设 TCP 连贯，或者呼叫的时候在建设 TCP 连贯；
TCP Server 维持所有终端的状态及网络地位做 Session Manager 角色
主叫输出的号码编辑封装 calling 报文，通过 tcp socket 发给服务器，同时 UI 出现拨号期待页面；
被叫收到 calling 报文，就封装 ringing 报文，通过 tcp socket 发给服务器，服务器查问 Session Manager 查问主被叫的 IP 和端口，实现音讯的路由转发，主叫收到就显示振铃页面，同时 WebRTC2SIP connector 启动 media coder 线程去解析和 resample 读取到的音频流。就这样一个个的报文交互串起来，就能够实现整个 SIP 呼叫逻辑。
有趣味的同学，快去试试吧。

基于声网的音视频 SDK 和 FreeSWITCH 开发 WebRTC2SIP Gateway 遇到的坑（三）
前两篇文章我简略介绍了开发 WebRTC2SIP 的设计架构图和报文逻辑，看着简简单单，做起来还是有很多事件要思考的。咱们在开发的过程中，也是磕磕绊绊，一步一个脚印（坑）走过去的。碰到的很多问题都是兼容的问题。
咱们碰到过哪些问题呢？咱们总结下来，开发时遇到了这些问题：

1 怎么解决早起媒体？
2 怎么解决加密不被过滤？
3 怎么避免 SIP 注册攻打和匿名呼叫攻打？
4 怎么反对音讯扩大，扩大反对更多服务？
5 正在通话呼叫（calling ringing）过程中，主叫或者被叫断线了，怎么探测？怎么 recover，主动重连话务？
6 通话单方任一方忽然杀死 SDK 过程 怎么告诉对方？
7 SIP 呼入的时候，如果被叫不在线？怎么个解决逻辑？
8 客户要求实现同一个账户同振怎么实现？
9 客户要求反对新版本的的 SDK 呼入呼出的同时，让同一套账户体系反对 SIP 的呼入和呼出；如果有人呼入，要求 SIP 客户端和声网客户端，都要响铃，即要兼容原来的客户固定资产（SIP 话机等）能够持续被应用。

除了这些还有在测试阶段发现很多诡异的问题
1、比方电话接通后，说着说着就没声音了，
2、谈话会卡断，有时候接通就会卡有的时候通话几分钟后会卡
3、常常碰到被叫挂机，声网的 SDK 还在写日志，一天 50 个电话写日志几十 G
4、单通，一方听不到声音
5、编码问题，码率不统一
6、各种莫名解体：启动解体，接通解体，挂机解体，神经病似得说崩就解体。
一路走来，几个共事常常剖析代码到中午。终于在测试 4 个月后稳定下来。其实当初回头看，就是因为没有吃透声网的 API 文档，没有好好利用社区的性能。如果你碰到的坑是上述的问题，那么花点工夫认真撸几遍 API 文档就能够搞定了。
零碎运行了几个月没出过问题，公司要求总结下开发中碰到的问题，声网的小伙伴说，要学会回馈社区，欠缺一下学习交换的气氛。有感于这一段时间的开发工作，于是就写下这几篇文章，心愿能对大家有所帮忙。我会敲代码，不太会表白，如果大家在实现这个模块的过程中也碰到问题，想理解一些细节。欢送分割交换。