基于WebRTC的多人音视频通信方法与流程

基于webrtc的多人音视频通信方法
技术领域
1.本公开的实施例一般涉及视频通信领域，并且更具体地，涉及基于webrtc的多人音视频通信方法、装置、设备和计算机可读存储介质。


背景技术：

2.目前，多人实时音视频解决方案，市场上主流使用视频推流拉流技术，但是，在主流的推流拉流技术中，主流的推送协议rtmp协议中，视频必须是h264编码，音频必须是aac或mp3编码，且多以flv格式封包。
3.rtmp是目前最主流的流媒体传输协议，对cdn支持良好，实现难度较低，是大多数的直播平台的选择。但rtmp不支持浏览器，且adobe已不再更新，因此直播服务要支持浏览器时，需要另外的推送协议支持。


技术实现要素：

4.根据本公开的实施例，提供了一种基于webrtc的多人音视频通信方案。
5.在本公开的第一方面，提供了一种基于webrtc的多人音视频通信方法。该方法包括：
6.获取每个客户端的网络信息；
7.基于所述网络信息，通过信令服务器连接各个客户端；
8.连接建立完成后，通过webrtc完成多个客户端间的音视频通信。
9.进一步地，所述获取每个客户端设备的网络信息包括：
10.每个客户端分别建立一个rtcpeerconnection对象；
11.基于所述rtcpeerconnection对象，通过stun服务器获取对应的网络信息。
12.进一步地，还包括：
13.所述信令服务器通过双工通信的技术构建。
14.进一步地，所述通过webrtc完成多个客户端间的音视频通信包括：
15.主叫客户端通过rtcpeerconnection的createoffer方法，获取本地音视频编码、分辨率信息，并通过信令服务器发送至被叫客户端；
16.所述被叫客户端接收到所述主叫客户端发送的信息后，通过rtcpeerconnection的createanswer方法，获取本地音视频编码、分辨率信息，并通过信令服务器发送至所述主叫客户端，完成多个客户端间的音视频通信。
17.进一步地，所述网络信息包括外网ip和端口信息。
18.进一步地，还包括：
19.通过rtcpeerconnection的setromotedescription方法，设置音视频的设备信息。
20.进一步地，还包括：
21.通过setlocaldescription方法，将本地音视频编码、分辨率信息添加到rtcpeerconnection中。
22.在本公开的第二方面，提供了一种基于webrtc的多人音视频通信装置。该装置包括：
23.获取模块，用于获取每个客户端的网络信息；
24.连接模块，用于基于所述网络信息，通过信令服务器连接各个客户端；
25.通信模块，用于连接建立完成后，通过webrtc完成多个客户端间的音视频通信。
26.在本公开的第三方面，提供了一种电子设备。该电子设备包括：存储器和处理器，所述存储器上存储有计算机程序，所述处理器执行所述程序时实现如以上所述的方法。
27.在本公开的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如根据本公开的第一方面的方法。
28.本技术实施例提供的基于webrtc的多人音视频通信方法，通过获取每个客户端的网络信息；基于所述网络信息，通过信令服务器连接各个客户端；连接建立完成后，通过webrtc完成多个客户端间的音视频通信，适用于视频会议、直播连麦、对讲机和语音电话，并且支持浏览器，同时具有低延迟性。
29.应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。
附图说明
30.结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：
31.图1示出了能够在其中实现本公开的实施例的示例性运行环境的示意图；
32.图2示出了根据本公开的实施例的基于webrtc的多人音视频通信方法的流程图；
33.图3示出了根据本公开的实施例的基于webrtc的多人音视频通信装置的方框图；
34.图4示出了能够实施本公开的实施例的示例性电子设备的方框图。
具体实施方式
35.为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例，都属于本公开保护的范围。
36.另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
37.图1示出了能够在其中实现本公开的实施例的示例性运行环境100的示意图。在运行环境100中包括客户端101、信令服务器102、客户端103和stun服务器(turn)104。
38.其中，stun服务器104用于获取客户端101、103的外网地址以及端口信息；
39.信令服务器102用于中转客户端之间的传输信息(stun服务器在国内并不稳定，为了保证服务的稳定性，在通信建立的过程中，需依赖信令服务器102进行中转)。
40.在一些实施例中，信令服务器102可通过双工通信的技术构建，如websocket。
41.将信令服务器与webrtc相互结合具有更好的扩展性,信令服务器作为webrtc数据webrtc数据传输的桥梁,可传输媒体数据，也可传输文件、消息、找等数据方便扩展。
42.应该理解，图1中的客户端、和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的客户端和服务器。特别地，在目标数据不需要从远程获取的情况下，上述系统架构可以不包括网络，而只包括客户端或服务器。
43.图2示出了根据本公开实施例的基于webrtc的多人音视频通信方法200的流程图。包括：
44.s210，获取每个客户端的网络信息。
45.其中，所述网络信息包括外网地址和端口信息。
46.在一些实施例中，通过nat技术获取各客户端之间的外网地址。在实际应用中计算机大多位于nat之后，仅有少数主机拥有外网地址。因此，在本公开中采用可穿透nat技术(stun、trun)获取当前主机的外网地址和端口，即使用webrtc技术获取当前主机的外网地址和端口(webrtc默认使用stun服务器获取当前主机的外网地址和端口)。
47.具体地，每个客户端(待建立通信客户端)分别建立一个rtcpeerconnection对象，rtcpeerconnection对象向stun服务器获取自己的外网ip和端口。
48.s220，基于所述网络信息，通过信令服务器连接各个客户端；连接建立完成后，通过webrtc完成多个客户端间的音视频通信。
49.在一些实施例中，主要客户端(发起通信客户端)，将自身的网络信息经过信令服务器中转后转发至被叫客户端；
50.被叫客户端接收到主叫客户端的网络信息后创建一个rtcpeerconnection对象，将接收的信息通过addicecandidate添加到对象中，同时通过信令服务器向主叫客户端转发自身的外网地址和端口。完成主叫客户端和被叫客户端之间的连接，即通过信令服务器连接各个客户端。
51.主叫客户端通过rtcpeerconnection的createoffer方法，获取本地音视频编码、分辨率信息，通过setlocaldescription添加到rtcpeerconnection中，并将上述信息经过信令服务器中转后发送至被叫客户端；
52.被叫客户端接收到主叫客户端发送的信息后，使用rtcpeerconnection对象的setromotedescription()保存。
53.具体地，主叫客户端向信令服务器发送创建房间消息：
54.{
55."type":"room",
56."content":{
57."event":"_create_room"
58."data":
59.},
60."fromid":"xxx",
61."classify":1
62.}
63.被叫客户端端向信令服务器发送加入房间消息：
64.{
65."type":"room",
66."content":{
67."event":"_join_room"
68.},
69."toid":
70."fromid":"xxx",
71."classify":1
72.}
73.在房间中的客户端(主叫客户端和已加入房间的客户端)均会被叫客户端发送的加入房间消息，此时，房间中的客户端执行如下步骤：
74.(1).获取流媒体
75.(2).创建peerconnection
76.(3).添加流到peerconnection
77.(4).生成offer提议
78.(5).设置本地描述
79.(6).发送offer至新被叫客户端
80.可通过如下方式发送offer消息至被叫客户端：
81.{
82."type":"single",
83."content":{
84."event":"_offer",
[0085]“data":{
[0086]“sdp":sdp
[0087]
}
[0088]
},
[0089]
"toid":"ciid",
[0090]
"fromid":"xxx",
[0091]
"classify":1
[0092]
}
[0093]
被叫客户端收到offer消息后，执行如下步骤：
[0094]
(1).获取流媒体
[0095]
(2).创建peerconnection
[0096]
(3).设置远端描述
[0097]
(4).生成answer应答
[0098]
(5).发送answer至房间内的客户端a
[0099]
(6).设置远端描述
[0100]
可通过如下方式发送answer值房间内的客户端：
[0101]
{
[0102]
"type":"single",
[0103]
"content":{
[0104]
"event":"_answer",
[0105]
"data":{
[0106]
"sdp":sdp
[0107]
}
[0108]
},
[0109]
"toid":"ciid",
[0110]
"fromid":"xxx",
[0111]
"classify":1
[0112]
}
[0113]
进一步地，主叫客户端通过如下方式发送本地的candidate至被叫客户端：
[0114]
{
[0115]
"type":"room",
[0116]
"content":{
[0117]
"event":"_ice_candidate",
[0118]
"data":{
[0119]
"candidate":candidate
[0120]
}
[0121]
},
[0122]
"toid":"房间id",
[0123]
"fromid":"xxx",
[0124]
"classify":1
[0125]
}
[0126]
被叫客户端通过如下方式发送本地candidate至主叫客户端：
[0127]
{
[0128]
"type":"room",
[0129]
"content":{
[0130]
"event":"_ice_candidate",
[0131]
"data":{
[0132]
"candidate":candidate
[0133]
}
[0134]
},
[0135]
"toid":"房间id",
[0136]
"fromid":"xxx",
[0137]
"classify":1
[0138]
}
[0139]
此时，主叫客户端和被叫客户端分别添加远端发送的candidate，完主叫客户端和被叫客户端的连接。即，主叫客户端通过rtcpeerconnection的createoffer方法，获取本地
音视频编码、分辨率信息，并通过信令服务器发送至被叫客户端；
[0140]
被叫客户端接收到主叫客户端发送的信息后，通过rtcpeerconnection的createanswer方法，获取本地音视频编码、分辨率信息，并通过信令服务器发送至所述主叫客户端，完成多个客户端间的音视频通信。
[0141]
在一些实施例中，通过rtcpeerconnection的setromotedescription方法，设置音视频的设备信息。
[0142]
在一些实施例中，通过setlocaldescription方法，将本地音视频编码、分辨率信息添加到rtcpeerconnection中。
[0143]
根据本公开的实施例，实现了以下技术效果：
[0144]
本发明基于webrtc技术作为传输架构，性能及延迟相对较好，webrtc技术在传输方式上，是以端对端的媒体数据进行传输的，对服务器的性能以及带宽依赖相对较小。不仅适用于视频会议、直播连麦、对讲机还适用于语音电话，并且支持浏览器。
[0145]
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本公开并不受所描述的动作顺序的限制，因为依据本公开，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本公开所必须的。
[0146]
以上是关于方法实施例的介绍，以下通过装置实施例，对本公开所述方案进行进一步说明。
[0147]
图3示出了根据本公开的实施例的基于webrtc的多人音视频通信装置300的方框图。如图3所示，装置300包括：
[0148]
获取模块310，用于获取每个客户端的网络信息；
[0149]
连接模块320，用于基于所述网络信息，通过信令服务器连接各个客户端；
[0150]
通信模块330，用于连接建立完成后，通过webrtc完成多个客户端间的音视频通信。
[0151]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，所述描述的模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0152]
图4示出了可以用来实施本公开的实施例的电子设备400的示意性框图。如图所示，设备400包括中央处理单元(cpu)401，其可以根据存储在只读存储器(rom)402中的计算机程序指令或者从存储单元408加载到随机访问存储器(ram)403中的计算机程序指令，来执行各种适当的动作和处理。在ram 403中，还可以存储设备400操作所需的各种程序和数据。cpu 401、rom 402以及ram 403通过总线404彼此相连。输入/输出(i/o)接口405也连接至总线404。
[0153]
设备400中的多个部件连接至i/o接口405，包括：输入单元406，例如键盘、鼠标等；输出单元407，例如各种类型的显示器、扬声器等；存储单元408，例如磁盘、光盘等；以及通信单元409，例如网卡、调制解调器、无线通信收发机等。通信单元409允许设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
[0154]
处理单元401执行上文所描述的各个方法和处理，例如方法200。例如，在一些实施例中，方法200可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单
元408。在一些实施例中，计算机程序的部分或者全部可以经由rom 402和/或通信单元409而被载入和/或安装到设备400上。当计算机程序加载到ram 403并由cpu401执行时，可以执行上文描述的方法200的一个或多个步骤。备选地，在其他实施例中，cpu401可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法200。
[0155]
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)等等。
[0156]
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
[0157]
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
[0158]
以上描述仅为本技术的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本技术中所涉及的申请范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述申请构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本技术中申请的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。