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

48次阅读

共计 4369 个字符,预计需要花费 11 分钟才能阅读完成。

为什么做这个?

今年初接到一个我的项目工作,客户要求在本人的音视频平台零碎中集成 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 文档就能够搞定了。
零碎运行了几个月没出过问题,公司要求总结下开发中碰到的问题,声网的小伙伴说,要学会回馈社区,欠缺一下学习交换的气氛。有感于这一段时间的开发工作,于是就写下这几篇文章,心愿能对大家有所帮忙。我会敲代码,不太会表白,如果大家在实现这个模块的过程中也碰到问题,想理解一些细节。欢送分割交换。

正文完
 0