将本地PeerConnection转变到WebRTC 1.0

webrtc版本变迁很快，越发展越标准化，部分老旧的API和标准将不会再支持，我们虽然使用了2016年左右的版本开发的系统，但web端使用的chrome，因此要是chrome废弃了以前的一些标准后，还是需要迁移到新版的API，毕竟新版本的是标准，实现多路流更加便捷和高效，再次记录下，以下为正文，转自webrtc中文网https://webrtc.org.cn/transitioning-to-1-0/

作者：steve…@webrtc.org（原文链接）

翻译：刘通

原标题：Transitioning Native PeerConnection to WebRTC 1.0

如果你没有使用PeerConnection C++，Java，或者Objective-C的API的话，那么你可以跳过本篇文章。Chrome中WebRTC 1.0的搬移计划有所不同，并将另行公布。

WebRTC规范在过去几年中一直在发展，因此我们有了不同的SDP格式（Unified Plan），各种新的API（其中包括RtpTransceivers），并且删除了部分老旧API（AddStream等）。

新API和Unified Plan SDP格式提供了这些新功能：

         # 早期媒体：当offer发送之后，主叫方可以在接收到应答之前接收媒体

         # 对于指定轨道，支持多个媒体流或不存在媒体流

         # 使用发送方对象，你可以使用sender.setParameters()控制媒体

         # 使用接收方对象，你可以更直接地控制SDP生成的某些指定方面

为了保持原生API体积小且保持最新，我们将会弃用非标准的“备用方案（Plan B）”风格的SDP以及已经从标准中移除的API。我们意识到这将是一个影响很多的人重大改变，因此我们希望在执行之前获得你对此项转移计划的反馈。下面是我们目前的计划。

新的RTCConfiguration选项：SdpSemantics

PeerConnection将有一个新的配置选项，可以与Unified Plan SDP和新的API兼容。 SdpSemantics有两个选项：

         # PlanB：PeerConnection会像现在一样

         # UnifiedPlan：PeerConnection将创建并设置Unified Plan请求/应答。PeerConnection将无法为多个音频或多个视频轨道设置Plan B请求/应答。一些API将无法工作，其他API会变可用（见下文）。

在创建PeerConnection时应该在RTCConfiguration中指定所选的SdpSemantics，并且不能在运行中更改。

新添加的API

配置了UnifiedPlan语意的PeerConnection将可以使用一下API：

         # AddTransceiver()

         # GetTransceivers()

         # RtpTransceiver对象

         # 有RtpTransceiver的OnTrack事件

被移除的API

对于使用PlanB语义配置的PeerConnections，以下API仍然可用，但不适用于UnifiedPlan语义，并且将在未来删除：

         # AddStream()：被AddTrack()取代

         # RemoveStream()：被RemoveTrack()取代

         # local_streams()：被GetSenders()取代

         # remote_streams()：被GetReceivers()取代

         # CreateSender()：被AddTransceiver()取代

我们正在制定一份迁移指南，帮助你将你的应用程序转换为新的API，并很快发布。

时间线

以下是我们想要提出的搬移计划，以及WebRTC库中将要发生改变的大致时间：

         # 2018年4月底：“Unified Plan”和新API达到稳定。我鼓励每个人都换用UnifiedPlan和新的API。

         # 2018年7月：默认的SdpSemantics更改为UnifiedPlan。同时移除“删除名单”（CreateSender除外）中列出的API。

         # 不早于2018年底：删除PlanB语境，UnifiedPlan成为唯一选择。

我们希望听到你对我们提出的转移计划和时间表的任何想法或疑虑。一旦“Unified Plan”准备好面对正常使用量（本月），我们将更详细地描述这些变化，并根据我们在此收集的意见提出最终的改变机会。

最后感谢WebRTC API团队。