作者：Anatoli Davidson（原文链接）
翻译：刘通
M57
概述
WebRTC M57，目前已经登录Chrome测试版中，并且Android和iOS本地库已经包括超过40种新的功能，超过60个bug被修复，以及各种稳定性和其他方面的改进。正如之前的几个版本，我们建议开发者运行各个版本的Chrome，并且及时上报遇到的问题。请大家阅读这个网页，其中有链接将你引导到不同的bug上传页面。任何反馈对我们来说都是十分重要的。
各个版本的Chrome发布日期可以在这里看到。
重要的声明
默认RTCRtpMuxPolicy现在是“强制”
默认RTCRtpMuxPolicy从之前的“可协商”变成了“强制要求”，以符合标准的要求。这意味着，默认地，与不支持RTCP复用的端点进行的请求/应答协商将不会成功。如果你的应用不支持RTCP复用，你可以通过清楚地将策略设置为“可协商”来获得老版本的性能，尽管此功能可能在之后的版本更新中被取消掉。更多细节请点击这里查看。
getUserMedia中报错机制的改变
getUserMedia现在将会在接入音频捕捉设备完成之后报告成功/失败，而不是在之前报告。这可能会导致getUserMedia的完成时间有小幅度的延长，不过这样可以反馈出返回的音轨是否表示一个不活跃或者根本不存在的音频源。
弃用传统的VoE API
在2015年9月，我们曾经声明低层的音频引擎API（VoEBase，VoENetwork等等）会被弃用。现在，这些WebRTC本地库中的传统API的大部分使用量已经被替代。
M57是最后一个声明传统VoE API的一个版本，我们会开始一点一点的将它们移出ToT。我们知道会有一些用户受到此项改变的影响，但是为了确保与堆栈其他部分的互动速度，我们必须迈出这一步，做出改变。因为这些API从来没有得到官方支持过，所以不幸的是也没有确切的替代品。如果想要搭建一个应用享受WebRTC的好处并且不想遇到性能问题的话，那么你应该使用PeerConnection API。
特征
回声监测的数据现在可以在chrome://webrtc-internals中查看
现在新加了一个音频处理部分来监测回声，其可以用来查看是不是有硬件或者软件回声消除模块没有正常工作。回声的可能性由0（没有回声）到1（极大可能发生回声）表示，如果这个数值高于0.5的话，就说明存在回声问题。此数值可以在chrome://webrtc-internals中查看，可以使用GetStats来询问。详情查看6525和6796.
Mac上的H.264 VideoToolbox硬件解码器
macOS本地的应用现在可以享受H.264硬件编解码器的好处了。
AppRTCMobile现在支持蓝牙设备
我们已经在我们的示例应用中加入了对蓝牙音频的支持，允许用户列举连接的蓝夜设备，并且选择他们作为全双工音频设备。测试应用支持耳机配置文件，但是还不支持A2DP。更多细节查看6649。
DTMF支持多种速率
DTMF，也就是“电话-事件”（telephone-event）现在要求时间戳速率与一系列所支持的音频编解码器相匹配。
默认情况下，安卓的Chrome启用H.264编码
安卓版Chrome现在支持WebRTC使用H.264硬件编码，以配合之前版本就已经支持的H.264硬件解码，支持高通公司和Exynos的芯片。因为没有软件编码，只用上述芯片才会支持；一些特定设备因为过差的编码表现而被列入黑名单。需要注意H.264仍然需要与SDP进行协商来达到任何的效果。
注意：所有变更细节，请务必点击此处在原文后半部分中进行查看。
