• 呼叫系统使用webRTC网页软电话到底好不好?


    webRTC作为一个新的互联网技术,在通信系统中得到越来越广泛的应用。

    不管是用电脑,还是手机,不用安装任何软件,打开网页,直接语音/视频,简单方便,是不是很美好?

    在呼叫中心领域,webRTC的一个重要特点在于网页集成软电话,生产实施时部署非常简单。

    坐席可以不再依赖语音网关、SIP话机及各种软电话,使用电脑麦克风,打开网页,即可进行呼叫。

    最关键是免费,特别适用于基于B/S架构的呼叫中心系统。

    我们的系统,在最新版本中,已经开发支持,有少量客户在使用,没有太多反馈。

    当然,懂的人知道,没有反馈,实际上就是最好的反馈。

    那么,webRTC技术这么优秀,是不是所有客户都要开通webRTC网页软电话功能呢?

    那也不是的。

    任何事物都有两面性,webRTC也不例外。

    想起去年底有一个朋友,他们也是做呼叫中心的,接了一个大项目,使用webRTC技术,碰到了技术难点,跟我们探讨。

    那个时候webRTC对我们而言还处于规划阶段,没有实质性投入。

    我们做了一些简单研究,提出了一些改进建议。

    虽然有所改善,但问题还是不能得到彻底解决,朋友最终还是说服客户更换技术方案,放弃使用webRTC。

    新技术,相比成熟稳定的技术,总是需要学费与代价的。

    webRTC设计的初衷是解决IP终端到IP终端的通信,而呼叫中心业务一般都需要平台参与控制,特别是IP呼叫中心最终需要将呼叫落地到传统PSTN网络,因此,webRTC在呼叫中心领域的应用,缺点也非常明显。

    比如,webRTC对算力的要求更高。

    呼叫的控制与媒体流的传输,都与标准通信协议不同,需要服务器额外的开销,而且这种开销不可忽视,单机高并发高性能应用场景需要做出权衡取舍。

    再比如,兼容性问题。

    首先有webRTC升级前后标准的兼容性问题:浏览器升个级,也许以前能用,新版本就用不起来了。

    还有与通信系统其它组件配合的兼容性问题。比如,令人头痛的编解码问题:目前并不支持g.729/g.723,使用webRTC,要么使用g.711编解码,带来成倍的带宽开销;要么使用opus编解码,则需要转码,不仅音质会降低,而且需要额外的算力开销。

    当然,这也与webRTC的出身阵营有关。

    webRTC是互联网大厂/标准组织主推的技术,相比较电信联盟ITU而言,互联网技术更加开放,简单易懂、入门门槛低、易用性/扩展性强、更新迭代快,而电信联盟的技术标准一般技术门槛高、严谨、复杂、专业性强、稳定性高、前后兼容性好。

    简单、方便、成本低,顺应人的本性,所以我相信,互联网技术会越来越流行。

    上一个互联网打败电信联盟标准的案例是SIP vs H.323/MGCP/H.248。

    当然,通信/互联网ICT也越来越趋于融合。算力/带宽越来越便宜,用的人越来越多,再大的兼容性问题都不会永远是问题。

    最后,也许不是问题的问题,全球化的逆进程,谁都不知道未来会发展到何种程度。

    就像不会科学上网就访问不了google一样。

    就像华为海外手机就预装不了全家桶。

    webRTC也许哪天也会碰到类似问题。

    不管如何,webRTC作为符合人性的技术,大概率会越来越流行,就算不是这个“webRTC”,也会是另一个“webRTC”。欢迎和博主交流。

  • 相关阅读:
    linux的三剑客
    Linux 【进程】
    Python使用pymysql和xlrd2将Excel数据导入MySQL数据库
    R语言ggplot2可视化:使用ggpubr包的ggmaplot函数可视化MA图(MA-plot)、font.label参数设置图中标签字体类型、字体大小
    Mac 禁用一些高占用cup的进程
    基于SpringBoot+Vue+uniapp的考试系统的详细设计和实现(源码+lw+部署文档+讲解等)
    java-异常
    使用 `spring-statemachine-redis` 实现状态机
    cocosCreator 之 3.x使用NodePool对象池和封装
    Nginx负载均衡
  • 原文地址:https://blog.csdn.net/weixi_kelaile520/article/details/126053530