国内设计网站公司,百度推广助手,山东企业网站建设费用,做摘抄的网站什么是 WebRTC #xff1f;
WebRTC#xff08;Web Real-Time Communication#xff09;是 Google于2010以6829万美元从 Global IP Solutions 公司购买#xff0c;并于2024年01月10日将其开源#xff0c;旨在建立一个互联网浏览器间的实时通信的平台#xff0c;让 WebRTC…什么是 WebRTC
WebRTCWeb Real-Time Communication是 Google于2010以6829万美元从 Global IP Solutions 公司购买并于2024年01月10日将其开源旨在建立一个互联网浏览器间的实时通信的平台让 WebRTC技术成为 H5标准之一。我们看官网https://webrtc.org的介绍 本文福利 免费领取C音视频学习资料包学习路线大纲、技术视频/代码内容包括音视频开发面试题FFmpeg webRTC rtmp hls rtsp ffplay 编解码推拉流srs↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓ 其中
Web Real-Time Communications (WEBRTC) W3C 组织定义浏览器 API。Real-Time Communication in Web-browsers (RTCWEB) IETF 标准组织定义其所需的协议数据安全性等手段。 简单来说WebRTC 是一个可以在 Web 应用程序中实现音频视频和数据的实时通信的开源项目。在实时通信中音视频的采集和处理是一个很复杂的过程。比如音视频流的编解码、降噪和回声消除等但是在 WebRTC 中这一切都交由浏览器的底层封装来完成。我们可以直接拿到优化后的媒体流然后将其输出到本地屏幕和扬声器或者转发给其对等端。
点对点音视频的难点
抛开低延迟、流畅性、回声消除和海量并发这些难点不讲单纯从功能来看打通通讯双方的两端让彼此能正常视频及通话主要存在两个问题
1网络打通问题--无公网IP无法直接通信
当今互联网到处存在着一些中间件(MIddleBoxes)如NAT和防火墙导致两个(不在同一内网)中的客户端无法直接通信。这些问题即便是到了IPV6时代也会存在因为即使不需要NAT但还有其他中间件如防火墙阻挡了链接的建立。
当今部署的中间件大多都是在C/S架构上设计的其中相对隐匿的客户机主动向周知的服务端(拥有静态IP地址和DNS名称)发起链接请求。大多数中间件实现了一种非对称的通讯模型即内网中的主机可以初始化对外的链接而外网的主机却不能初始化对内网的链接除非经过中间件管理员特殊配置。在中间件为常见的NAPT的情况下内网中的客户端没有单独的公网IP地址而是通过NAPT转换和其他同一内网用户共享一个公网IP。
这种内网主机隐藏在中间件后的不可访问性对于一些客户端软件如浏览器来说并不是一个问题因为其只需要初始化对外的链接从某方面来看反而还对隐私保护有好处。然而在P2P应用中内网主机客户端需要对另外的终端Peer直接建立链接但是发起者和响应者可能在不同的中间件后面两者都没有公网IP地址。而外部对NAT公网IP和端口主动的链接或数据都会因内网未请求被丢弃掉。对于WebRTC来说首先要解决的是如果跨越NAT实现内网主机直接通讯的问题。 2媒体格式编码问题--媒体格式编码多样不统一
对于需要音视频通信的双方彼此要了解对方支持的媒体格式才能正常地对流媒体编解码。比如PeerA端可支持VP8、H264多种编码格式而PeerB端支持VP9、H264要保证二端都正确的编解码最简单的办法就是取它们的交集H264。有一个专门的协议称为SDPSession Description Protoco可用于描述上述这类信息在WebRTC中参与视频通讯的双方必须先交换SDP信息这样双方才能知根知底而交换SDP的过程也称为“媒体协商”
SDP(Session Description Protocol) 是一种会话描述协议基于文本其本身并不属于传输协议需要依赖其它的传输协议比如 SIP 和 HTTP来交换必要的媒体信息用于两个会话实体之间的媒体协商。SDP(会话描述协议)定义了一个标准用于定义两个通常端与端之间媒体通常是流媒体交换的参数。IETF已将其发布为RFC 4566。SDP通常嵌入或封装在另一个协议中最广泛使用的应用程序位于大多数IP电话应用程序的SIP协议内部。简单地说SDP协议是媒体端到端对其接收规范和能力的声明典型的声明会告诉我们
1哪个IP地址准备好接收传入的媒体流
2哪个端口号正在侦听传入的媒体流
3端点希望接收的媒体类型通常是音频
4端点希望在哪个协议中交换信息通常为RTP
5端点能够解码的压缩编码编解码器
在一个典型的会话设置过程中我们会看到两个端点参与一个会话其中每个端点发送一个SDP以通知另一个端点其规范和功能。SDP本身不提供任何媒体但仅限于协商一组兼容的媒体交换参数媒体流本身由不同的通道和协议处理。
一个 SDP 的握手由一个 offer 和一个 answer 组成
WebRTC通话原理
点对点的双方为了实现实时音视频通信 WebRTC需要解决媒体协商和网络协商问题这里要引入信令服务器(Signaling Server)和STUN server Signaling Server
需要通信的双方之间建立WebRTC连接需要一个信令服务器来实现双方通过网络进行连接。信令服务器的作用是作为一个中间人帮助双方在尽可能少的暴露隐私的情况下建立连接。WebRTC并没有提供信令传递机制信令的传递和交换需要服务器参与这个角色就是信令服务器。WebRTC信令指建立、控制和终止通信会话的过程以及业务本身的需求来看需要交换几个信息媒体信息网络信息具体业务。
一、媒体信息
需要媒体数据来确定呼叫者和被呼叫者共有的编解码器和媒体类型。如果尝试启动通信会话的端具有不同的分辨率和编解码器配置则会话不太可能成功。通过使用会话描述协议SDP格式的提供和应答在对等方之间交换媒体配置信息的信令这些信息是通过SDP协议描述出来通过信令服务器中转的。
二、网络信息
两个WebRTC客户端如何发现对方的通过信令服务器交互双方在Internet上的位置IP地址和端口以便呼叫者可以找到被呼叫者。
三、具体业务
会话控制信息确定何时初始化、关闭和修改通信会话比如加入房间离开房间禁言媒体流订阅发布等功能需要信令服务器来控制。 STUN server
STUNSession Traversal Utilities for NATNAT会话穿越应用程序是一种网络协议它允许位于NAT或多重NAT后的客户端找出自己的公网地址查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间建立UDP通信。该协议由RFC 5389定义。STUN 是 C/S 模式的协议可以简单理解为由客户端发送 STUN 请求STUN 服务响应告知由 NAT 分配给主机的 IP 地址和端口号。一旦拥有了ip和端口点对点通信的双方就能直连通信了。注以上的响应同时还使得STUN客户端能够确定正在使用的NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。 专有名词介绍
Signaling Server 信令服务器负责处理通信双方的信息交互包括媒体信息网络信息业务信息。
STUN serverSTUN的全称是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) 即穿越NAT的简单UDP传输是一个轻量级的协议。可以简单理解为由客户端发送 STUN 请求STUN 服务响应告知由 NAT 分配给主机的 IP 地址和端口号。
SDPSession Description Protocol 为了连接到对端用户我们必须要对其他用户的设备情况有所了解比如音频视频的编码解码器、使用何种编码格式、使用何种网络、设备的数据处理能力而 SDP 为我们提供了这些功能
ICEInteractive Connectivity Establishment 通信的两侧可能会处于不同的网络环境中有时会存在好几层的访问控制、防火墙、路由跳转所以我们需要一种方法在复杂的网络环境中找到对方并且连接到相应的目标。WebRTC 使用了集成了 STUN、TURN 的 ICE 来进行双方的数据通信。
offer、answer一个 SDP 的握手由一个 offer 和一个 answer 组成一方发送offer另一方接收到offer后发送answer。
WebRTC音视频通信流程 在同一房间的双方通过WebRTC建立音视频通信主要分为四个阶段
一加入房间、呼叫对方对方应答
1ClientA登录后连接信令服务器选择进入某个房间
1ClientB登录后连接信令服务器选择进入某个房间12不分先后
3ClientA 在此房间中看到ClientB在线选择呼叫ClientB
4ClientB选择同意接听 34中的ClientA和ClientB可以互换
二交换SDP发送/接收offer发送/接收answer
1ClientA 执行getUserMedia() -new RTCPeerConnection-Peer.addStream-createOffer
2ClientB 执行getUserMedia() -new RTCPeerConnection-Peer.addStream12并行执行
3ClientA通过信令服务器中转offer给ClientB
4ClientB收到offer后setRemoteDescription-createAnswer并通过信令服务器中转answer给ClientA
5ClientA收到answer后setRemoteDescription
三交换ICE candidate
1ClientA 向STUN Server请求ICE请求可能在之前某个时候已经发出STUN Server返回ICE candidate
2ClientB 向STUN Server请求ICE请求可能在之前某个时候已经发出STUN Server返回ICE candidate
3ClientA通过信令服务器中转ICE candidate到达ClientBClientB通过信令服务器中转ICE candidate到达ClientA
4ClientA收到B的ICE canditateaddIceCandidate
5ClientB收到A的ICE canditateaddIceCandidate
四开始音视频通信
1ClientA addStream 展示对方远程音视频流
2ClientA addStream 展示对方远程音视频流 本文福利 免费领取C音视频学习资料包学习路线大纲、技术视频/代码内容包括音视频开发面试题FFmpeg webRTC rtmp hls rtsp ffplay 编解码推拉流srs↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓
