WebRTC的优点:
WebRTC技术的诞生,有一个很重要的原因在于,在浏览器实现实时音视频通话,需要依赖相关插件或程序,而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新,因此插件带来的安全风险也相对较大。
在WebRTC诞生之前,开发实时音视频应用的成本是非常高,需要考虑的技术问题很多,如音视频的编解码,数据传输延时、丢包、网络抖动、回音处理和消除等,如果要兼容浏览器端的实时音视频通信,还需要额外安装插件。当然,可以考虑使用第三方成熟技术,比如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions),支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS,如Yahoo,AOL,IBM,SKYPE,QQ等。
WebRTC项目的愿景:实时通信web化,让WebRTC成为互联网音视频实时通信的规范,让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信,必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景:
两个不同网络环境的(具备摄像头/麦克风多媒体设备的)客户端(浏览器或APP),要实现点对点的实时音视频对话,难点在哪里?
要实现P2P通信,首先需要了解彼此是否都支持相同的媒体能力,WebRTC默认使用V8编解码器,如果要连接的对方不支持V8解码,如果没有媒体协商过程。那么即使连接成功,把视频数据发给对方,对方也无法播放
比如:Peer-A端可支持VP8、H264多种编码格式,而Peer-B端支持VP9、H264,要保证二端都正确的编解码,最简单的办法就是取它们的交集H264
有一个专门的协议 ,称为Session Description Protocol (SDP),可用于描述上述这类信息,在WebRTC中,参与视频通讯的双方必须先交换SDP信息,这样双方才能知根知底,而交换SDP的过程,也称为"媒体协商"。
交换数据会通过一个中间服务来完成,在这里,我们称之为信令服务器
在建立P2P连接时,需要交换的信息有:
最理想的场景
然而,在大多数情况下,两个对等端都是各自处于某个局域网之中,相互之间隔着NAT与防火墙
NAT(Network Address Translation)即为网路地址转换协议
局域网-->公网
公网-->局域网
可以借助STUN服务器,穿越NAT
在NAT四种主要类型中有三种是可以使用STUN穿透:完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT(又称为双向NAT)则不能使用STUN穿透,这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说,路由器只会接受之前连线过的节点所建立的连线。
可以点对点连接的情况与需要中转的情况(数据来源于Google)
不过在国内大部分局域网无法穿越。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)