Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >技术解码丨实时音视频与PSTN融合的解决方案

技术解码丨实时音视频与PSTN融合的解决方案

作者头像
腾讯即时通信IM
发布于 2021-03-22 07:22:05
发布于 2021-03-22 07:22:05
2.2K0
举报
文章被收录于专栏:即时通信IM即时通信IM

一、背景

01

什么是实时音视频(RTC)

实时音视频(Real-Time Communication,简称RTC),从字面上理解就是实时的进行音频和视频的交流,最主要的特点就是“实时”。这里的实时性可以分为三个档次:

腾讯云实时音视频 TRTC 延时已经可以做到300ms以下,我们常见的QQ和腾讯会议上的语音通话、视频通话,都是实时音视频的应用场景。

首先,我们来了解下为什么会产生延时。以QQ为例,两个QQ用户通过外网发起语音通话,主叫方语音呼叫接听方,这个过程一般会分为两层来处理。一个是信令层的处理,另一个是码流层的处理。信令层主要用于通话的建立、连接、资源的准备,并协商码流编解码类型等相关信息,码流层专注于音视频数据处理。这里主要以音频来说明,要进行实时语音通话,则要进行音频数据的采集、预处理、编码、网络传输、解码、播放等步骤。由于双方都是在Internet上进行通话,需要将主叫的声音传输到被叫方,即是将采集到的语音数据传输到接收端。接收端收到音频流数据后,会进行解码,之后是播放器进行播放。这里面有很关键的一点,就是我们的通话是建立在Internet之上,这种语音通话也称之为VOIP,是需要依赖网络传输的,所以就会产生延时。从主叫说话的第一个字开始到被加听到的那个字之间会经过一定距离的物理传输,这就产生了延时。

那么如何才能做到低延时呢?我们在传输协议上直接选择来UDP。UDP虽然不可靠,但是它的传输效率比较高,相对于TCP少了三次握手和四次挥手。因为外网的环境时好时坏,UDP又是不可靠的,在Internet传输音视频数据时容易产生抖动,所以我们需要一个抗抖动的能力。当网络质量不好产生丢包时,我们也需要一个抗丢包的能力。外网的质量波动比较大,也需要一种自适应的方式来动态调节发送的码流,称之为流控,可以按一定的周期来检测主被叫双方接收的包量,来计算丢包率、延时和码率等,用于来控制发送端的采样率、发送的码率和组包间隔;当时网络质量不好时,我们可以把发送端的采样率和码率降低,减少发送的整体包量,进而减小网络的拥堵。网络质量好时,我们可以提高发送端的采样率和码率,增加发送的整体包量,会让接收端有较好的语音质量。

音视频处理(这里要重点说的是音频),必然会涉及到语音的增强处理。语音进行采集后,会进行一些预处理。比如说主叫端在说话的时候离麦克风比较远,造成采集的音量比较小,这样接收端听到声音就会小。但是经过AGC处理后,可以把音量适当的调大,让接收端听到正常的声音。还有回声消除AEC用于消除听到回声情况,当噪声比较大时,通过ANC把噪声降下来,让人说话的声音突出,可以在接收端清晰听见说话内容。下图是常用的提高语音质量需要考虑的方面。

02

什么是PSTN

PSTN,从字面意思来看就是公共交换电话网,是一种比较老的技术。虽然历史较久,但电话现在依然是我们使用和应用场景最广泛的一种实时语音通话方式。通常有着急的事情大家都会优先选择电话的方式来沟通。座机或手机通过电话线和PBX相联(程控交换机)然后通过物理线路,连到运营商公共专用网络,进行语音流、信令流的传输,再传输到被叫用户最近的PBX,通过电话线呼起被叫。被叫的手机响铃,被叫就可以选择接听,手机的麦克风会采集对应的人声,通过相同的交换机传回来,这样主被叫双方就可以进行实时通话。

PSTN一般都采用专线专网,它的缺点就是网络利用率比较低。两个电话用户同时进行通话会独占一路物理线路,这路物理线路在那一刻就只供主被叫双方使用,不像英特网一样都是多种通话共享占用。随着技术的发展,PSTN也出现了一种新的方式,在PSTN网络可以使用SIP_TRUNK的方式,把里面的信令流和数据流传到Internet上。处理信令的方式是采用标准的SIP协议,码流采用标准的RTP协议来传输。

03

为什么要融合

主要原因是有较多的业务场景需要。

  • 如在QQ讨论组里多个人想一起进行语音通话,但是他邀请的其中一个用户可能是QQ离线的,这个离线用户就无法加入进来了。
  • 多人会议也类似,开会的场景一般都比较紧急,大家希望可以直接打个电话就可以把用户接入到会议中进行讨论。
  • 另一个场景就是智能门禁,现在的智能门禁系统,简单地来说类似一个Pad,使用Android操作系统,安装了一个类似QQ或者实时音视频的App,可以让拜访者跟业主进行交流。这种App在业主的手机上通常不会长期启动,不像QQ或者微信那样长期处于在线状态。当这个App离线时,访客拜访业主,通过App就会找不到业主,此时如果可以通过门禁直接打电话,业主和拜访者就可以相互进行语音通话了,随后业主再通过电话的方式把门禁打开。
  • 还有在各种网站上的客服电话,直接在网页上点击一下就可以打电话给客服人员,进行语音沟通。

要实现上面各种业务场景需求,就需要将实时音视频VOIP和传统的PSTN融合起来。

二、如何融合

01

分析差异

首先我们要看一下两者的差异。以QQ语音通话为例,前面提到过,一个完整的音视频处理要分很多步,音频采集、预处理、编码、网络传输、解码和播放等。在网络传输协议上,QQ语音通话是使用自己的私有协议,而PSTN使用的是标准的SIP+RTP协议,这是运营商采用的国际标准协议。

QQ支持的编码有很多,有SILK、AAC、OPUS等,但对于PSTN,使用SIP_TRUNK方式对接的语音编码,目前三大运营商,电信、联通和移动,仅支持G711A、G711U、G729等编码。RTC采样率都是16K、48K,PSTN一般为8K。

组包间隔,语音数据包发送的时候需要以一定的时间间隔来周期进行发送,比如说像QQ支持20毫秒、40毫秒、60毫秒的间隔发送,PSTN基本上是20毫秒。

语音质量,对于VOIP会有很多相应的语音的优化手段,但是PSTN是专用网络,网络质量相对高,丢包较少,优化的手段也比较少。

RTC除了1对1绝大多数场景是支持多人,比如说纯视频、纯语音通话可以支持客户端混音和服务端混音,但是PSTN手机端基本上是1V1。多人会议是多个人,但是手机端是不支持同时接收多路码进行混音的,必须要混好成一路后,才能下发给手机。显然这些都是两者之间的差异。

02

融合方法:寻找共性,适配差异

上面是差异的地方,有没有相同的地方呢?PSTN经过长时间的发展,目前演进到了IMS网络架构,可以把专用网络的信令流和数据流通过SIP_TRUNK的方式在Internet上面传输,这就是一个相同的地方。这个地方存在的突破口,存在可以融合的点。剩下要对差异的部分进行适配,即对音频码流和信令协议进行适配。

我们融合的方式的实现有两种,第一种是让QQ客户端去适配PSTN的差异,第二种是让PSTN去适配VOIP的差异。首先PSTN是国际通用的标准,让它适应VOIP众多的编码和私有协议,那么现在的手机设备肯定要更新升级,这显然不大现实。另外一种就是让QQ去适应PSTN的差异。QQ同样有历史包袱,他发展了那么多年,如果支持RTP和SIP改动也很大,开发周期也是非常漫长的。即然这两种方法都不行,我们就想到新增一个中间模块去分别适配VOIP和PSTN的差异。这个模块我们称之为适配层,可以放到Internet上,让VOIP和PSTN协议互转和码流互转。适配层有两个主要功能,一个是对信令的适配,还有一个是对码流的适配。

03

最终系统架构图

最上面一部分是实时音视频对外提供的OpenSdk,主要是封装了RTC一些基本操作步骤和能力,它目前支持安卓、IOS、windows、web SDK,基本上是全终端。客户端信令发向后台互动直播系统,首先经过信令处理模块App,通过多个Info模块进行机器调度分配。由于我们整个过程都是要动态自适应调整,会有一个流控模块,主要用于通话过程中音频质量的实时调节。最后信令会转到一个信令适配模块,我们称之为会控。而码流的适配、编码的转换,需要另一个适配模块混音。因为手机端不具备多路混音的能力,所以我们必须在服务端进行混音,这样将多人的码流混成一路发给手机端,手机端就能听到多个人的声音了。

上图中下面的部分是进入PSTN网络,会控把QQ私有协议转换成内部私有协议,通过PSTN策略进行一系列的分配策略,再通过处理信令的sip_server将内部私有协议转换成标准的SIP协议和运营商的SIP_SERVER相通,同理将对应的码流通过混音和proxy转成标准rtp码流和运营商媒体Svr相通。

重点说一下混音,从QQ的私有协议转到标准的RTP协议还算比较容易,但编码转换就要复杂很多。因为手机端不具备混音的能力,所以我们这部分不像VOIP客户端可以客户端混音,手机端必须要在服务端混好后才能下发一路码流给手机端。我们是采用服务端混音,如有多个VOIP进行互相通话的时候会同时发多路音频流,由外网传输到混音后台,首先会选路操作。选路是指在多个说话的人里面最多选几路语音流来进行混音操作,比如说QQ语音通话最多选六路。主要原因,第一个是说话的人多了大家听不清楚,第二个就是选择的语音流路数越多越消耗服务器资源,这样一台服务器就支持不了多少人了。选路之后,就要进行解码,解码完再进行重采样,进行混音和编码,然后再通过Proxy进行传输。最后会传输到运营商的媒体SVR,进入到运营商网络,通过用户最近的基站下发到手机端,这样就实现了手机端也可听到多路语音的功能。

三、系统优化

01

语音质量增强

语音通话中,提高语音质量是优化核心体验较为重要的一环。手机端的语音增强手段比较有限,因为它在运营商的封闭专用网络中,相对外网质量较好,少抖动和少丢包。但在VOIP端直接使用公网,所以要做的语音质量优化比较多。比如说语音采样之后,会进行回音消除和降噪。为了避免抖动会引入jitterbuffer,jitterbuffer会缓存音频包,它有一定大小,如果在缓存范围外的丢包,则要通过PLC进行补包。还有为了节省带宽我们会做VAD,如果VOIP端长期不说话的时候,我们可以不发完整的静音包,可以会发特殊的EOS包。网络质量是随时动态变化的,所以我们要进行自适应调节,以2秒为一个单位来,实时统计一下当前网络的延时、丢包、抖动等情况,综合调节客户端的采样率和码率。

02

优化语音延迟

实时音视频,低延时是重中之重。在外网传输,延时大部分引入有很多是在媒体SVR的分配上面。如在不同运营商的延时会有10到25毫秒延时,而且不同的运营商某些城市可能会有丢包,不同的机房网络延时差不多是20到35毫秒,如果直接外网,易抖动、质量不稳定。对于这些问题,我们可能通过调度分配来解决,我们尽量将媒体SVR分配到同一运营商,尽量分配到同机房。对于有条件的地方可以直接专线相连接。

03

优化网络丢包

抗网络丢包有两种方法,第一种是ARQ自动重传。我们每一个媒体节点都是采用UDP来传输且每一个媒体节点都会缓存一定数量的音频包,每个音频包里面会有一个序号,接收客户端收包时会根据包中的序列号判断是否是连续的,如果不是则有丢包,此时会去它的前一个媒体节点问一下,缓存中有没有这个包,有的话就直接重发一次,没有的话,它就再向前一个节点问一下,如果所有中间节点都没有就会一直问到发送端,发送端再把这个包再传一次。ARQ明显缺点就是会增加延时。

第二种是FEC,发送端在发音频包的时候,可以多发几个冗余包。接收到如果发现音频包丢了,而冗余包没有丢,则会尝试使用冗余包把音频包恢复。增加FEC也是动态的,当网络质量不好会多加一些冗余包,反之则会少加一些。

04

提高可用性

只要是大规模的应用或系统,这是必不可少的要解决的问题,解决这个问题简单来说就两个方面,第一个是增加冗余资源,第二是实现自动切换。机器冗余可以多运营商部署、多机房部署,多地部署,自动切换则是死机时可以自动切换、IDC异常时可以自动屏蔽出问题的IDC、自动屏蔽出问题的资源等方式。

四、总结

综上所述,融合系统的本质是一个寻找共性,适配差异的过程。本文给大家做融合类系统提供一个参考思路。如今这套融合系统已经上线公司内多个业务,目前整体服务稳定,当然还有很多需要优化的地方,如存在系统耦合模块较多、整体复杂性较高、查找问题耗时长等问题。这提醒我们仍旧需要继续努力,不断优化和迭代,将整体系统做到更好。

腾讯云通信

一直致力于

让每个企业

都享受智慧服务带来的改变

END

未来可期

长按扫码关注腾讯云通信官方微信公众号

以获取更多更专业的云通信知识

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-03-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯云通信 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
颜学伟:实时音视频与PSTN结合的解决办法
6月29日,音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题,针对腾讯云音视频及融合通信产品的技术全面剖析,为大家带来纯干货的技术分享。下面是颜学伟老师关于实时音频与传统PSTN语音业务如何融合在一起,以及融合过程中的碰到的难点和解决方案的分享。
腾讯云开发者社区技术沙龙
2019/07/04
3.1K1
颜学伟:实时音视频与PSTN结合的解决办法
新知 | RT-ONE™&TRTC赋能实时音视频场景创新
今年腾讯云音视频发布了“三合一”的RT-ONE™网络。该网络整合了腾讯云实时通信网络(TRTC)、即时通信网络(IM)以及流媒体分发网络(CDN)三张网络,为业界最完整的音视频通信PaaS平台构建基座,面向教育、零售、泛娱乐等行业需求提供服务。本次新知系列的第一堂课,我们邀请到了腾讯云音视频的技术导师 —— 刘连响,为大家详解RT-ONE™并分享RT-ONE™&TRTC赋能实时音视频场景的一些创新。 接下来的5周,每周四晚上7:30,我们都会在腾讯云音视频视频号、开源中国、InfoQ、51CTO、云
腾讯云音视频
2021/11/22
2.2K6
实时音视频-腾讯云实时音视频(TRTC)
腾讯实时音视频(Tencent Real-Time Communication,TRTC)拥有QQ十几年来在音视频技术上的积累,致力于帮助企业快速搭建低成本、高品质音视频通讯能力的完整解决方案。
用户3570397
2019/08/06
10.6K0
实时音视频技术的演进与应用
本次分享我们邀请到了来自腾讯云实时音视频TRTC后台的研发负责人薛笛,他向我们分享了腾讯云TRTC在架构升级和产品实践中的经验。仔细讲解了混音引擎最初的制造源、在整个优化过程中发现的问题以及解决方法,为后来做腾讯会议和云呼叫中心打下了一个良好的基础。
LiveVideoStack
2021/05/08
1.7K0
实时音视频技术的演进与应用
如何实现WebRTC协议与SIP协议互通
目前在国内需要WebRTC协议与SIP协议互通的场景主要集中在应用程序(App/Web)对接企业呼叫中心系统客服坐席、音视频会议对接PSTN/SIP音视频通话、企业内部App移动工作台(智能办公电话)、CRM系统集成电话呼叫功能、智能硬件(如:智能门禁设备、电梯救援设备、智能陪伴机器人)对接PSTN通话等落点电话场景。
qzlink.com
2020/08/04
8.5K0
如何实现WebRTC协议与SIP协议互通
微信团队分享:微信每日亿次实时音视频聊天背后的技术解密
2012 年 7 月,微信 4.2 版本首次加入了实时音视频聊天功能,如今已发展了 5 年,在面对亿级微信用户复杂多变的网络和设备环境,微信多媒体团队在每个技术细节上不断地深耕细作,为微信用户提供了高质量的视频通话。
JackJiang
2018/08/29
6.2K1
实时音视频 TRTC 常见问题汇总---咨询问题篇
TRTC 是腾讯云基于 QQ 十多年来在音视频通话技术上积累,结合腾讯浏览服务 TBS WebRTC 能力与腾讯实时音视频 SDK ,为客户提供多平台互通高品质可定制化的 实时音视频互通服务 解决方案。 (1)您可以通过“crtl+F”(win)、“command+F”(mac)搜索关键字。 (2)若没有您想要的问答,欢迎在评论区提问、留言和交流,笔者会定期解答疑惑。 (3)最新产品动态与变更以官网文档为准。
TRTC小百科
2021/09/16
8.9K2
拿下公司技术突破奖,腾讯 RTC 实时音视频技术内幕揭秘!
近些年来,随着移动宽带的不断提速,音视频应用的受欢迎程度也越来越高。尤其受上半年疫情的影响,更多原本线下的业务也被迫搬到了线上,这就更进一步的推动了以低延时见长的实时音视频产品的快速增长,腾讯实时音视频(Tencent-RTC,下文简称为 TRTC)正是在这个大背景下取得了新一轮的技术突破,并因此获得了腾讯公司级技术突破奖的。 本文将围绕三个主要的技术突破点,对该项目的阶段性成绩和其中涉及的技术细节进行一个全面的描述和总结。 什么是RTC? RTC 是 Real Time Communication 的英
腾讯即时通信IM
2020/11/03
3.1K0
日均超30亿分钟!腾讯实时音视频技术低延时的秘密
新冠肺炎疫情的突发,让全球远程办公、在线教育、在线协作、远程面试等领域需求急剧增加,这也让支撑远程通信的实时音视频技术成为焦点。由腾讯实时音视频(Tencent Real-Time Communication,TRTC)为基础支撑的腾讯内外众多产品业务如腾讯会议、企业微信群直播、腾讯课堂、VIPKID等均出现爆发式增长。 随着各地有序复工复产,TRTC 也为包括金融行业远程面审、保险远程业务、法院视频庭审、人社局远程面试、长三角教师云招聘、上海市重大产业项目云签约等重要项目发挥了重要作用。数据显示,目前TRTC 平台的客户端上行时长超过 30 亿分钟/天,每天并发在线达到千万级。 本文主要针对 TRTC 技术解读系列中低延时实现技术的解析。
smiling
2020/04/08
1.2K0
日均超30亿分钟!腾讯实时音视频技术低延时的秘密
干货|一文读懂腾讯会议在复杂网络下如何保证高清音频
导读 | 一场突如其来的疫情,让数以亿计的白领只能居家办公,云视频会议系统突然成为最重要的办公软件。腾讯会议在2019年12月25日正式上线后,短短两个月时间内积累千万日活。除了时机,腾讯会议产品又为什么能脱颖而出呢?产品力是个不得不提的因素,腾讯多媒体实验室高级研究员王晓海在【腾讯技术开放日·云视频会议专场】中,对腾讯会议在复杂网络情况下如何保证高清音质进行了分享。 点击视频,查看直播回放 一、VoIP和PSTN的前世今生 PSTN(PublicSwitch Telephone Network公共交
腾讯多媒体实验室
2020/04/13
4.2K1
腾讯实时音视频TRTC百万级用户并发解决方案
今年我们经历了一个特殊时期,导致大家必须很长的时间段内在家中,大量的企业也选择让员工在家中远程办公、学校选择让老师和学生在通过远程教学的方式进行学习。
shixin
2020/02/11
2.1K0
当相亲遇上实时音视频会是怎样的碰撞?
还有你想不到的,就是来自你妈妈最真挚的爱——翻看你朋友圈的自拍,选一张上好的,并在公园的相亲角准备把你给“拍卖”了。
smiling
2020/04/29
9050
当相亲遇上实时音视频会是怎样的碰撞?
实时音视频入门学习:开源工程WebRTC的技术原理和使用浅析
本文由ELab技术团队分享,原题“浅谈WebRTC技术原理与应用”,有修订和改动。
JackJiang
2022/01/10
1.8K0
实时音视频入门学习:开源工程WebRTC的技术原理和使用浅析
字节跳动《实时音视频通讯技术》学习笔记之RTC概述及技术简介
因为这种产品主要是面向用户的,不同用户使用的设备的差别比较大。根据不同设备需要做不同的优化。这就是为什么我们说支持设备差异性大。
Regan Yue
2021/09/16
5K0
字节跳动《实时音视频通讯技术》学习笔记之RTC概述及技术简介
专访腾讯音视频实验室刘晓宇:服务8亿QQ用户的音视频通讯技术如何用到直播中
1999年,当时还叫OICQ的聊天软件发布了一个新版本,语音通话功能被正式加入,随后,视频通话也被加入。18年后的今天,QQ的月活跃用户已经超过8亿,一个更惊人的数字是,最多的时候,QQ用户每天的音视频通话时长达12亿分钟。 在QQ发展过程中,其背后的音视频通信技术也经历了对外采购,到成立QQ音视频技术中心,自研引擎,再发展壮大为腾讯音视频实验室,开放自研的SPEAR音视频引擎的过程。现在,随着全民直播时代的到来,腾讯又研发并开放了一体化的直播解决方案,并将腾讯直播SDK应用于斗鱼、虎牙、快手等顶级的直播
腾讯多媒体实验室
2023/03/07
1.4K0
专访腾讯音视频实验室刘晓宇:服务8亿QQ用户的音视频通讯技术如何用到直播中
日均超30亿分钟!腾讯实时音视频技术低延时的秘密
新冠肺炎疫情的突发,让全球远程办公、在线教育、在线协作、远程面试等领域需求急剧增加,这也让支撑远程通信的实时音视频技术成为焦点。由 腾讯实时音视频(Tencent Real-Time Communication,TRTC) 为基础支撑的腾讯内外众多产品业务如腾讯会议、企业微信群直播、腾讯课堂、VIPKID等均出现爆发式增长。 随着各地有序复工复产,TRTC 也为包括金融行业远程面审、保险远程业务、法院视频庭审、人社局远程面试、长三角教师云招聘、上海市重大产业项目云签约等重要项目发挥了重要作用。数据显示,
腾讯即时通信IM
2020/06/19
1K0
技术福利:最全实时音视频开发要用到的开源工程汇总
实时音视频的开发学习有很多可以参考的开源项目。一个实时音视频应用共包括几个环节:采集、编码、前后处理、传输、解码、缓冲、渲染等很多环节。每一个细分环节,还有更细分的技术模块。比如,前后处理环节有美颜、滤镜、回声消除、噪声抑制等,采集有麦克风阵列等,编解码有VP8、VP9、H.264、H.265等。 
JackJiang
2018/08/29
7.2K1
B端运营级视频服务技术平台搭建
大家好,我是来自北京二六三企业通信有限公司的李志涛,主要负责公司音视频业务线的开发工作。
LiveVideoStack
2021/09/01
1.4K0
B端运营级视频服务技术平台搭建
实时音视频 TRTC 常见问题汇总---咨询问题篇
支持的平台包括 iOS、Android、Windows(C++)、Windows(C#)、Mac、Web、Electron、微信小程序、Flutter,更多详情请参见 平台支持。
腾讯视频云-Zachary
2019/11/01
13.3K0
实时音视频 TRTC 常见问题汇总---咨询问题篇
了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年(2017年),WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,或许门槛如此之高的实时音视频技术终有白菜化的那一天。
JackJiang
2018/08/29
2.9K0
推荐阅读
相关推荐
颜学伟:实时音视频与PSTN结合的解决办法
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档