作者：Jeremy Noring（原文链接）
翻译：刘通
原标题：WebRTC pro-tips
根据我过去几年的工作和学习经验，我列出了创建WebRTC产品的时候一些小技巧（下文中排练无先后顺序）。
常规提示
# 使用adapter.js—这会让你避免很多的痛苦。否则，你就必须要处理非常非常多的因为浏览器差别而产生的错误，这不值得你浪费时间。
# 如果你使用了插件，那么你需要给navigator.mediaDevices.getUserMedia，navigator.mediaDevices.enumerateDevices，RTCPeerConnection，MediaStream以及MediaStreamTrack写兼容性保障代码。长远来说，这么做会减少以后的工作量。
# 不要兼容旧版本的Chrome和Firefox。对于Firefox来说，通常来说我只支持对心的LTS版本（现在是52）。对于Chrome来说，我会允许最近4个版本使用。这些浏览器的旧版本会给你带来各种各样的麻烦。
SFU/MCU
如果你的通话是为了很多人一同参与准备的，那么你一定需要SFU或者MCU。提示如下：
# 确保你的SFU/MCU支持bundle和rtcp_mux。
# 如果只有音频或者只有视频，确保你的SFU/MCU支持这么做。
# 留意信令通道。这是一个非标准通道，功能是实现WebRTC通话的设立。你一定不能讨厌这个协议，它使用来在客户端和服务器之间进行正常数据交换的。乱七八糟的格式 = 地狱般的debug。
# 确保你的SFU/MCU至少支持VP8，VP9以及Opus编解码器。如果也支持H.264的话更好。其他一些奇怪的编解码器就没什么关系了。
# 如果你需要进行录制，一定要仔细测试这个功能。特别是针对丢包和延时。
# 如果你使用了SFU，那么一定要保证SFU能实现RTCP终端。很多简单的实现只是简单地从源头将RTCP数据传递给所有的接收端（反向也一样），但是这种做法在很多复杂的情况中是大错特错的。
# 我建议你通过网络模拟丢包和延时仔细的测试你的任何解决方案。MCU处理数据的能力会因为网络质量不同而产生巨大差别。
一个悲伤的现实：某些情况你必须进行中继，因为在很多情况中并不能建立端到端连接，或者端到端连接不够好。TURN是完成这个任务的标准做法：
# 如果你不用TURN服务器，那么你的产品在任何企业网络中都会无法使用。
# 确保你的TURN监听着TCP 443端口。这会让你提取TCP 443，这个对企业兼容性来说是必需的。
# 如果你使用的是SFU或者MCU，可以考虑在你的软件中使用TURN，然后强迫每个人都通过TURN进行中继。这么做会让某些事情变简单。
Debug
# https://test.webrtc.org 对于测试WebRTC连接来说是一个非常棒的网站。这里可以查看代码。
# chrome://webrtc-internals也非常的有用。但不是所有浏览器都能用。你可以在这篇文章中获取弥补方法。
# 永远要在Chrome Canary和Firefox Developer中测试你的服务。这么做的话你可以在它给你产生困扰之前就发现你系统中的不兼容问题。
