拍乐云解析融合语音通话技术实践

·  阅读 600
拍乐云解析融合语音通话技术实践

近日,RTSCon2021开发者沙龙以线上的方式顺利举办。拍乐云服务端专家沈伟锋受邀参会,并带来了《拍乐云融合语音通话技术实践》主题演讲,分享了融合语音通话的需求背景、技术基础、架构搭建和技术实践,博得参会嘉宾的一致好评。以下为演讲实录:

融合语音通话需求背景

网络覆盖不全

从贝尔1876年发明电话,到1965年5月,美国贝尔系统的1号电子交换机(模拟)问世,再到1970年,法国开通的第一部程控数字交换机E10,之后,电话网络在全世界范围内得到了大规模的发展。而因特网(也叫互联网)起源于1969年美国军方正式启动的阿帕网(“ARPAnet”),到1989年开始才从军用转向民用,此后,因特网开始大规模地发展起来。事实上,因特网构建的基础网络(物理网络)很大一部分是基于PSTN的电路交换网络。正是由于这个历史原因,PSTN网络的覆盖率要远高于因特网,在我国的一些偏远山区,尤其是人迹稀少的地方,PSTN网络的覆盖率都是要好于互联网的。

使用成本

对于使用者来说,如果只是呼入,PSTN一般都是免费,而基于分组数据的网络,流量的费用不管是上行的流量或下行的流量都不是免费的。在不同的国家,流量的费用从小于一美元/1G到几十美元/1G不等,还是非常昂贵的,以下是部分国家2020年1GB(移动数据)平均费用:

  • 中国-0.61美元/GB
  • 墨西哥-4.77美元/GB
  • 新西兰-6.06美元/GB
  • 美国-12美元/GB
  • 加拿大-12.55美元/GB

使用的便利性

使用电话的时候不需要任何下载,一般也不需要任何设置。但基于互联网的App,一般需要提前下载App,并设置相应的环境:比如摄像头、麦克风、扬声器(耳机)、网络等。在实际的使用中经常会碰到网络不通、网络不佳、或听不到声音等问题,这些问题一般需要具备一定的专业知识的人才能解决。

特定用户群体

对于一些特定的人群,比如老年人,他们接触互联网、智能手机、电脑等比较少,尤其是广大农村的老年人。对于这样的人群,使用电话肯定会比使用App更容易上手。

用户惯性

目前,有一些互联网的应用系统,是从传统的呼叫中心发展过来的,他们的系统核心已经从过去的呼叫中心演变到了基于互联网RTC的系统,这些系统所服务的新用户群体可以是完全基于互联网App的,但对于一些已经习惯于电话使用该系统的老用户群体,会需要一个使用习惯的转换过程,不然这样的客户群体有可能会慢慢流失。

PSTN融合RTC的技术基础

图片

  • PSTN

PSTN ( Public Switched Telephone Network ):公共交换电话网络。PSTN是一种以模拟技术为基础的电路交换网络。

  • 因特网/互联网

因特网(Internet)是由广域网上众多的物理网络(子网)相互连接而成一个逻辑网络,也叫互联网。它是基于一些共同的协议,并通过众多交换机/路由器实现分组数据交换,多路复用等技术连接而成的网络。

  • PSTN和互联网之间关系

PSTN可以是互联网7层网络中的物理层。在众多的广域网互连技术中,基于PSTN进行互连所要求的通信费用最低,但同时PSTN的网络资源利用率也比较低。

  • IMS

IMS(IP Multimedia Subsystem):网际协议多媒体子系统,是由朗讯(Lucent)提出的下一代通信网(NGN)实现大融合方案的网络架构,被认为是下一代网络的核心技术。IMS的目标不仅是在现网基础上提供新的业务,而且它还要能提供现在以及未来因特网上能够承载的所有的业务。

  • SIP

SIP(Session Initialization Protocol):会话初始化协议。IMS系统采用SIP协议进行端到端的呼叫控制。

  • SDP

SDP(Session Description Protocol):会话描述协议。SIP协议使用SDP来描述如何设置和初始化会话及会话中使用到的多媒体,主要包括会话者信息,会话时间,网络传输方式,媒体信息等等。

  • RTP/RTCP

RTP(Real-time Transport Protocol)实时传输协议,定义了在互联网上传输多媒体时的标准数据包格式。RTCP(Real-time Transport Control Protocol)实时传输控制协议,主要用于QoS反馈和同步媒体流。

融合语音通话技术实践

图片我们来看看电话呼入的一个基本流程:首先用户侧使用电话拨入会议专用号码,经过IMS系统承载的SIP呼入Pano服务,经过Pano前置四层负载均衡器,进入其中一个可用的Pano SIP LB。Pano SIP LB分配一个可用的SIP2RTC Gateway。SIP2RTC Gateway发起re-Invite,并开始IVR交互入会过程,同时请求Pano Service LB分配RTC媒体服务,并加入媒体服务。最后SIP2RTC Gateway桥接两边的会话,并做相应的协议转换和媒体转码合流。基于此,融合语音通话就需要具备如下技术特性:

服务的高可用

  • SIP LB Active-Standby模式防止单节点故障,可演进到Active-Active模式的SIP LB池来支持水平扩展;
  • SIP2RTC Gateway池可水平扩展,支持高并发;
  • SIP LB/SIP2RTC Gateway任何一个节点失效后,系统会自动快速进行会话迁移,保障通话不中断;
  • 加持Pano RTC媒体服务的高可用高并发。

完善的会控能力

锁住会议、静音参会者、移除参会者、分组讨论、查询/关闭会议等

多运营商多线路负载均衡

得益于IMS对后端运营商的各种网络的融合,我们可以用统一的接口对接所有运营商的网络。PSTN网络是基于电路交换的网络,而且是对线路独占的,同一个号码能支持的线路资源是有限的,本系统通过多线路资源负载均衡达到高并发的需求。

IVR个性化定制

会议场景的IVR主要包括:入会引导,信息或错误提示等,本系统支持对所有这些交互IVR的定制。

再来说说我们在过程中遇到了哪些坑。

NAT keepalive, 导致SIP(over UDP) NAT没有被转换

这个问题在SIP over TCP的情况下并不存在,只有在SIP over UDP时才会碰到。为了能到达正确的目的地及响应能按原路正确的返回,SIP(over UDP)会话在经过NAT的时候,会在via头中添加路由信息,还会改写request-line的目标地址。这种应用层的NAT转换在不同的设备上的实现方式各不相同,尤其是软件实现的NAT,有些NAT会自动根据UDP会话的第一个包是不是SIP协议来自动标记是否需要做SIP的NAT转换。一开始我们是通过软终端(linephone)模拟电话呼入来测试的,但是经常发现过一段时间,SIP的NAT转换莫名其妙的没有了。后来发觉,这个软终端会定期发送NAT keepalive包,来做UDP的保活,避免NAT上的UDP五元组的对应关系被删除,但是当我们的PC经过一段时间的休眠状态后,在激活的时候,NAT上的这个五元组对应关系已经被删除,并且这个软终端在激活的时候首先发出了NAT keepalive,导致NAT认为这个“新”的UDP会话不是SIP会话,最终导致SIP NAT转换没有被启动。图片

乱序的容错处理(sip over UDP)

这个问题是由于UDP的乱序导致后续的re-Invite先于前面的 200 OK的响应。对于一个容错处理好的系统,比较合适的做法是当收到新的re-Invite的时候,应该允许进入新的重新协商的阶段,而不是简单的拒绝,当老的200 OK到达的时候直接丢弃就可以了。然后,在我们对接的过程中发现,这种情况下,re-Invite会被直接拒绝掉。解决这个问题的最简单的办法是把SIP over UDP改成SIP over TCP,或者对re-Invite做适当的延迟处理即可。图片

一个SDK连接所有语音通话场景

截止当前,融合语音通话已服务于视频会议、远程问诊、金融营销、远程面试、智能硬件五大场景客户,一个SDK连接所有语音通话场景,实现VoIP和PSTN的互联互通,同时支持多平台集成,跨不同的终端,用户可按需选择接入方式,享受高质量、高稳定的语音通话体验。

当然,拍乐云的目标不止于此,我们期待通过持续的产品迭代和技术创新,重塑人与人的连接、人与物的连接,让信息传递更高效。

分类:
开发工具
标签:
收藏成功!
已添加到「」, 点击更改