在Chrome、Firefox、Edge和其他iOS上的WebRTC

从iOS 14.3开始，现在可以使用Chrome或替代Safari的WebRTC兼容浏览器，与iPad或iPhone进行音频和视频通话。这是一个伟大的改进，将帮助我们在移动设备上构建Web应用。

简介

能够在我的iPad上使用我最喜欢的浏览器来连接我的WebRTC应用是我非常期待的事情。这并不是为了我个人的使用，而是因为让终端用户用他们喜欢的浏览器来连接我的网络应用，而不是强迫他们使用一个他们并不真正使用的浏览器，这更容易。

我一直在等待，虽然我一直在关注互联网上所有的WebRTC新闻，但我错过了公告……它已经工作了几个月，而我却没有意识到这种兼容性

这就是为什么，我试图把我从那个故事里学到的东西总结到那个帖子里。

被错过的主要原因

事实上，这有两个主要原因：首先，苹果公司没有真正公开宣布这一兼容性，并由社区转达；其次，我阻止我的应用程序从iOS上没有兼容的浏览器中使用的方式是一种 “永远被阻止 “的策略。

关于公开声明，我在官方网站上搜索了一下，但iOS 14.3的声明在这一点上真的很轻：什么都没有宣布。我发现了一些社区发出的公开信号，但我错过了它们：我没有注意到来自Twitter上的Lee Martin提到了这一点。然后在4月21日最新的Kranky Geek活动中又提到了它，但我又错过了。我忘了看Twilio的Donal Toomey的直播：。最后，我通过最近在我的iPad上测试WebRTC API发现了其兼容性，并对结果感到惊讶……

事实上，在重新阅读了Webkit博客后，我找到了提到它的帖子。这篇文章与MediaRecorder API的支持有关，但文章的结尾是专门针对.NET的。我想我以前读过，但没有理解其影响，因为没有提到其他浏览器……

然后，解释我不知道的第二个原因是，当使用iPad或iPhone时，我选择在我的WebRTC应用程序上阻止任何浏览器的连接，除了Safari。仅仅是因为我知道它不工作。这样做，我确信永远不会有用户使用这样的浏览器，因此可以控制我所支持的浏览器列表，避免在生产中出现尚未 “合格 “的浏览器的任何问题：我对这种能力很有信心。我可以选择另一种策略，即检查WebRTC API的可用性，并在不可用的情况下进行阻止。但在我们的案例中，这很复杂： getUserMedia API是可用的，但总是返回notAllowedError错误……而且还有RTCPeerConnection API、RTCDataChannel API等，难道我必须检查我的Web应用所提供的所有WebRTC API，以允许或不允许一些细微的功能？但是，使用这样的策略可以让最终用户在WebRTC API可用后立即使用这个新的兼容浏览器。但是，如果终端用户在你还没来得及鉴定这个新案例之前就连接到你的应用程序，你可以肯定他们会向你的支持团队报告问题。

IOS上的WebRTC…

在安卓设备上，要在常用的浏览器上开发和支持WebRTC网络应用，这从来都不是一个大的挑战。唯一的例外是在5.0之前的系统中使用默认的Android浏览器或WebView。但在今天支持的安卓版本中，Chrome、Firefox、Edge和许多其他浏览器都与WebRTC兼容，在这些平台上开发并不那么复杂。

IOS上的情况就不一样了。

这个故事是由包括Alex Gouillard博士在内的一些人的壮举开始的，他们绝对希望在Safari浏览器中实现WebRTC。早在2015年，他们就开始着手在Webkit的一个分叉中加入对WebRTC的支持（基于OpenWebRTC/GStreamer）。最后，在2016年底，苹果公司决定将WebRTC实施到它自己的Webkit端口（使用谷歌libWebRTC）。

苹果开始发布兼容MacOS 10.11 El Capitan的Safari 11版本，事实上，开发者有机会在 Safari technology Preview 32 测试它。

在移动和平板电脑上，苹果开始在与2017年9月19日发布的iOS 11相关的Safari 11版本中引入对WebRTC的支持。在此之前，没有办法在iPad和iPhone的任何浏览器中支持WebRTC。唯一的可能性是建立一个嵌入WebRTC栈的本地iOS应用程序。

从iOS 11开始，可以在Safari浏览器上开发WebRTC应用，但由于工作良好且与其他浏览器兼容的情况有限，所以真的很复杂。

Safari通过LibWebRTC增加了对WebRTC的支持。但与谷歌和火狐相反，IOS 11只提供了一种视频编解码器，即H.264。注：即使2013年底在温哥华举行的IETF-88会议未能达成协议，建议有2个MTI（强制实施）音频和视频编解码器：视频为VP8和H.264，音频为Opus和G.711。但Safari决定提出其第一个版本，只使用H.264。宣布的理由是可以理解的：大多数手机都有符合H.264的硬件（解码器和编码器），但不符合VP8。

RTCPeerConnection 和 RTCDataChannel API 在iOS 11中可以在任何Web视图中使用，但对摄像头和麦克风的访问仅限于Safari。这一点对于开发者来说是无法理解的…

这一点很糟糕，因为很多情况都无法进入。首先，你不能在iOS上使用WebRTC来开发一个在Chrome、Firefox或任何其他浏览器上运行的Web应用，只有Safari是兼容的。第二，你不能在iOS上使用WebRTC来开发一个使用WKWebView的混合应用程序。最后，正如该问题中提到的，无法从电子邮件中的链接访问Web应用程序，因为它打开的Safari应用内版本的浏览器不兼容：不支持getUserMedia API。

这不是一个真正的好开始……

随着iOS 12，特别是iOS 12.2，有了一些改进。一些人说，从那个版本开始，WebRTC开始在Safari（移动或桌面）上 “可用 “了。但关于浏览器的支持，同样的限制仍然存在。一些主要的变化是引入了VP8视频编解码器，为支持Simulcast所做的工作以及对屏幕捕捉API的首次实验性支持。

随着iOS 13的推出，其中一个主要的bug得到了修复： WebRTC 现在在 SFSafariViewController 中可用，这意味着Safari应用内浏览器现在可以正确处理WebRTC请求。

去年，iOS 14已经发布。从我的角度来看，我看到Safari一点一点地缩小了差距，我不再害怕在Safari和其他浏览器之间测试场景。我的个人感觉是，Safari现在已经达到了WebRTC 1.0级别。至于其他浏览器，adapter.js有助于缩小目前的差距。

而我们在这里：iOS 14.3允许任何WebRTC浏览器访问设备…

iOS中的Chrome、Firefox、Edge和其他浏览器支持WebRTC
这一变化的后果是，你现在可以在运行iOS 14.3或更高版本的iPad或和iPhone上使用Chrome、Firefox、Edge或任何兼容WebRTC的浏览器来连接到你的WebRTC应用程序。它将发挥作用。

在写这篇文章的时候，我没有看到我管理的案例有问题。但我没有通过很多测试，因为我发现它能工作。

我通过查看SDP看到的是，从Chrome/Edge或Firefox，你只有2种视频编解码器：H.264作为第一等级，有几个配置文件，然后是VP8。因此，当从我的Chrome/Ipad呼叫我的Chrome/Mac时，使用的编解码器是H.264，而从我的Chrome/Mac呼叫我的Chrome/Ipad的结果是使用VP8。

在Chrome IOS中调试WebRTC

chrome://webrtc-internals不能从Chrome中访问。

在写这篇文章的时候，我发现最好的方法是使用chrome://inspect，它可以直接在iPad上显示任何标签的日志。

支持用户

在写这篇文章的时候，超过70%的iPhone用户可以用Safari的替代浏览器来使用WebRTC，因为他们使用的是最新版本的iOS。对于iPad用户来说，大约60%的用户拥有符合要求的iOS版本…

但是今天，Safari仍然在iOS的市场份额中占主导地位，约为90%。iOS上只有不到7%的用户使用Chrome。

因此，在2021年中期增加对其他浏览器的WebRTC支持，目标是10%左右的用户。

但是从体验和传递给用户的信息来看，支持iOS上的任何浏览器都是无价的。

经验之谈

以下是我的主要收获：

花更多的时间来阅读和理解公告：理解WebRTC的发展仍然很复杂，因为如果技术进步没有被普及，只有少数人能够理解其影响。但发布说明就在这里，只是要找时间来剥开它们。

我现在有了自己的样本，可以检查很多WebRTC的API。我希望这能帮助我轻松地测试新的浏览器版本以及新的系统，并看到其变化。根据我所做的工作的特点，继续改进它。