尽管Apple在2017年的WWDC上宣布加入WebRTC支持但仍然没有看到Apple在支持WebRTC上更深入的举动，尤其是其不只支持VP8更加强了这种担忧
对于那些运行具有较旧WebRTC实施的应用程序的人，我建议您尽可能升级到最新规范因为iOS的下一个版本默认禁用旧版API。特别是最好避免使用传统的addStream API，这使得操作流中的轨道变得更加困难
第一步是将所需的“playsinline”属性添加 到您的视频标签，这允许视频开始在iOS上播放所以这：
现在，您可以发送对等连接中最低可用原始分辨率的任何内容并让接收器的浏览器缩小视频，但是对于在网格/ SFU场景中具有较低速度的互联网的用户您将面临使下载带宽饱和的风险。
我通过限制发送视频的比特率来解决这个问题这是一个相当快速和低端的妥协办法。另一个需要更多工作的解决方案是在将应用程序中的视频流传递給对等连接之前对其进行缩减尽管这会导致客户端的设备花费一些CPU周期。
-
虽然W3C规范明确规定要实施对VP8视频编解码器（以及H.264编解码器）的支持但苹果迄今为止选择不支持它。遗憾的是这不是技术问题，因为libwebrtc包含VP8支持而Webkit主动禁用它。
所以在这个时候我在各种场景中实現最佳互操作性的建议是：
我说最好的互操作，因为虽然这会让你走很远的路但它不会一帆风顺。例如Chrome for Android尚不支持软件H.264编码。在我的测试中许多（但不是全部）Android手机都采用硬件H.264编碼，但那些缺少硬件编码的手机在Chrome中不能用于Android
如前所述，iOS不支持旧版WebRTC API但是，并非所有浏览器实现都完全支持当前规范在撰写本文时，一个很好的事例是创建一个仅发送音频/视频对等连接iOS不支持旧版 RTCPeerConnection.createOffer（）选项offerToReceiveAudio
其他更深奥的错误和限制
当然，你可以点击的其他一些极端案例似乎有点超出了这篇文章的范围但是，一个优秀的资源应该是Webkit问题队列你可以只针对与WebRTC相关的问题进行过滤：
它仍然缺少一些功能（如上面提到的扬声器选择），而且在我的测试中它的稳定性不如GoogleChrome中更成熟的实现。
还有一些主要的错误- 捕获音频在iOS 12 Beta发布周期的大部汾时间内完全被破坏（谢天谢地他们最终修复了Beta 8）。
苹果对WebRTC作为平台的长期承诺尚不清楚特别是因为除了基本支持之外，他们还没有發布有关它的更多信息例如，前面提到的缺乏VP8的支持对于他们遵守W3C规范的意图是令人不安的
在考虑浏览器原生实现与本地应用程序时，这些是值得考虑的事情目前，我持谨慎乐观的态度并希望他们对WebRTC的支持将继续下去，并扩展到iOS上的其他非Safari浏览器
}
点击联系发帖人
