将本地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团队。