前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >webrtc笔记(2): 1对1实时视频/语音通讯原理概述

webrtc笔记(2): 1对1实时视频/语音通讯原理概述

作者头像
菩提树下的杨过
发布2019-07-10 14:32:20
1.8K0
发布2019-07-10 14:32:20
举报

开始正文之前,先思考1个问题:2个处于不同网络环境的(具备摄像头/麦克风多媒体设备的)浏览器,要实现点对点的实时视频/语音通讯,难点在哪?

至少得先搞定下面2个问题:

1、彼此要了解对方支持的媒体格式、支持的最大分辨率等媒体信息

比如:peerA端可支持MPEG-1/2、H264多种编码格式,而peerB端支持MPEG-4、H264,要保证二端都正确的编解码,最简单的办法就是取它们的交集H264

就象2个不同国家的人交流,1个只会讲英文、中文,另1个只会讲德语、英文,他俩肯定要能相互正常沟通,肯定会用双方都懂的英文来交流一样。

注:有一个专门的协议 ,称为Session Description Protocol (SDP),可用于描述上述这类信息,在webrtc中,参与视频通讯的双方必须先交换SDP信息,这样双方才能知根知底,而交换SDP的过程,也称为"媒体协商"。

2、彼此要了解对方的网络情况,这样才有可能找到一条相互通讯的链路

类似的道理,在复杂的网络环境中,要建立二个端的连接,得有一条双方都能访问的链路。

如上图,peerA端具体有公网ip以及192网段的内网环境,而peerB没有公网,只有192、198二个内网地址,从图中可知,它俩可以使用公用的192网段来通讯。webrtc通讯过程中,这些网络相关的信息,也得相互交换,找出共同的交集,这个过程也称为“网络协商”。

顺着这个思路再琢磨一下,刚开始前,这2个端还没建立连接,既然连都没连上,又如何交换“媒体信息”、“网络信息”?

这时候就该所谓的信令服务器signal server出场了:

如上图,2个浏览器端的上层,可以抽象出一层信令服务器(可以是1台或多台,看实际应用的情况,如果2端的浏览器都能访问某个公共的网络环境,比如公网,可以让它们都连到这台公用的信令服务器上;如果没有公共的网络环境,可以在2端各搭一组服务器,即signal serverA、signal serverB,但是这二组信令服务器之间要能互通),借助信令服务器,就可以实现上面提到的SDP信息及网络信息交换。

交换SDP的过程,大致如上图:

1、Amy(1个假想的人名),把自身的SDP信息,通过setLocalDescription方法保存起来,然后通过offer方法,发给信令服务器。

2、信息服务器把Amy的SDP向前传递到另1端的Bob(另1个假想的人名),Bob会先调用setRemoteDescripition把Amy的SDP保存下来。

3、然后Bob调用setLocalDescription方法保存自己的SDP,然后再通过answer方法,把自己的SDP通过信令服务器发给Amy

4、Amy收到Bob的SDP后,调用setRemoteDescription保存起来,这样双方就完成了SDP交换,然后找出其中的交集,如果能达成一致,就可以建立p2p连接,开始通讯了。

但是现实往往是残酷的,在中国的网络环境中,据一些统计数据显示,至少1半的网络是无法直接穿透打通的(我个人认为根本原因是:IP4地址资源在互联网发展早期绝大多数都被国外占用了,轮到中国这些发展中国家使用时IP地址严重不足,所以大多数电脑都不具备公网ip,只能通过路由器、交换机做NAT转换,而相当一部分NAT是对称型的,基本上没法空透),这种情况下只能借助上一节讲到的turn服务器中转。

另外,在视频对话框中,通常会有房间(或群)的概念,用于做一些业务上的隔离,这部分逻辑也是在signal server中实现的,综合考虑peer端、信令服务器、stun/turn服务器后,整个1对1实时视频通讯的时序图如下:

主要过程如下:

1、双方先调用getUserMedia打开本机摄像头

2、向信令服务器发送加入房间apply_join请求

3、信令服务器通知本人加入成功(joined),同时向其它人广播加入消息(other_joined)

4、二端开始创建peerConnection连接

5、peerB端创建offer,同时将SDP保存到本机(setLocalDescription),并通过信令服务器传递到peerA

6、peerB在setLocalDescription后,会异步触发“候选网络链路”收集,大致是通过Stun确定自己所有的NAT映射出口,如果Stun返回NAT是“对称型”的,基本上就没法穿透了,会再通过Turn拿到中继reply地址,并通过信令服务器,将网络候选链路信息发到peerA(即:开始网络协商)

7、peerA收到的peerB的SDP后,开始回应(createAnswer),仍然通过信令服务器,将SDP发送到peerB

8、同时peerA也会开始网络候选链路的收集,并将自己的网络信息,通过信令服务器,发到peerB(即:网络协商)

这样peerA,peerB就相互交换了媒体信息及网络信息,如果能达到一致(即:找到交集),就可以开始通讯了

基于以上原理,做了一个demo示例程序,见:https://github.com/yjmyzz/webrtc-samples

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019-07-07 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
NAT 网关
NAT 网关(NAT Gateway)提供 IP 地址转换服务,为腾讯云内资源提供高性能的 Internet 访问服务。通过 NAT 网关,在腾讯云上的资源可以更安全的访问 Internet,保护私有网络信息不直接暴露公网;您也可以通过 NAT 网关实现海量的公网访问,最大支持1000万以上的并发连接数;NAT 网关还支持 IP 级流量管控,可实时查看流量数据,帮助您快速定位异常流量,排查网络故障。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档