对于web来说，所有的音视频处理都由浏览器直接完成
在浏览器中启用丰富的电话会议体验要求浏览器能够访问系统硬件以捕获音频和视频 - 无需第三方插件或自定义驱动程序，只需一个简单且一致的API。但是，原始音频和视频流本身也不够：必须处理每个流以提高质量，同步，并且输出比特率必须适应客户端之间连续波动的带宽和延迟。
在接收端，过程相反，客户端必须实时解码流，并能够适应网络抖动和延迟延迟。简而言之，捕获和处理音频和视频是一个复杂的问题。然而，好消息是WebRTC为浏览器带来了功能齐全的音频和视频引擎（图18-1），它代表我们处理所有信号处理等等。
处理所获取的音频流以进行降噪和回声消除，然后使用优化的窄带或宽带音频编解码器之一自动编码。最后，一个特殊的错误隐藏算法用于隐藏网络抖动和数据包丢失的负面影响 - 这只是亮点！视频引擎通过优化图像质量，选择最佳压缩和编解码器设置，应用抖动和数据包丢失隐藏等来执行类似的处理。
所有处理都是由浏览器直接完成的，更重要的是，浏览器动态调整其处理流水线，以考虑音频和视频流的不断变化的参数以及网络条件。完成所有这些工作后，Web应用程序将接收优化的媒体流，然后可以将其输出到本地屏幕和扬声器，转发给其对等端，或使用HTML5媒体API之一进行后处理！
从浏览器请求音频和视频时，请特别注意流的大小和质量。虽然硬件可能能够捕获高清质量流，但CPU和带宽必须能够跟上！当前的WebRTC实现使用Opus和VP8编解码器：
Opus编解码器用于音频，支持恒定和可变比特率编码，需要6-510 Kbit / s的带宽。好消息是编解码器可以无缝切换并适应可变带宽。
用于视频编码的VP8编解码器还需要100-2,000 + Kbit / s的带宽，比特率取决于流的质量：
- 在30 FPS时为720p：1.0~2.0 Mbps
- 360p，30 FPS：0.5~1.0 Mbps
- 180p，30 FPS：0.1~0.5 Mbps
因此，单方HD呼叫可能需要高达2.5+ Mbps的网络带宽。添加更多的对等体，质量必须降低以考虑额外的带宽和CPU，GPU和内存处理要求。
- createOffer
生成SDP描述
v=0
o=- 4809135116782128887 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 6ReMVBFmnh4JhjzqjNO2AVBc26Ktg0R5jCFB
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
通过反馈保护音频配置文件
媒体流的候选IP，端口和协议
Opus编解码器和基本配置
- ice 状态 iceGatheringState 该属性报告本地对等方的候选收集过程的状态 new 该对象刚刚创建，尚未发生网络连接。
gathering ICE代理正在收集当地候选人。
complete ICE代理已完成收集过程。
- iceConnectionState 属性报告对等连接的状态 new ICE代理正在收集候选人和/或等待提供远程候选人。
checking ICE代理已经在至少一个组件上接收了远程候选者，并且正在检查候选对但尚未找到连接。除了检查，它可能还在收集。
connected ICE代理已找到所有组件的可用连接，但仍在检查其他候选对以查看是否存在更好的连接。它可能还在收集。
completed ICE代理已完成收集和检查，并找到所有组件的连接。
failed ICE代理已完成检查所有候选对，但未能找到至少一个组件的连接。可能已找到某些组件的连接。
disconnected // 可以监测某个对等连接是否下线 一个或多个组件的活动检查失败。这比失败更具侵略性，并且可能在片状网络上间歇性地触发（并且在没有动作的情况下自行解决）。
closed ICE代理已关闭，不再响应STUN请求。
- chrome://webrtc-internals/ 谷歌浏览器提供了一个简单而实用的工具来调查任何WebRTC连接的整个工作流程和状态