Transitioning Native PeerConnection to WebRTC 1.0

[steve...@webrtc.org]

You can stop reading if you do not use the PeerConnection C++, Java, or Objective-C APIs. The transition plan for WebRTC 1.0 in Chrome is different and will be announced separately.

The WebRTC specification has evolved over the last few years and with that we have a different SDP format (Unified Plan) and new APIs (RtpTransceivers among them) along with the removal of old APIs (AddStream et al.).

There’s new functionality with the new API and the Unified Plan SDP format:

• Early media: after an offer is sent, the calling side can receive media before receiving the answer

• Support for multiple or no media streams for a given track

• With sender objects you can control media with sender.setParameters()

• With transceiver objects, you can more directly control certain aspects of SDP generation.

To keep the native API small and current, we’ll be deprecating the non-standard “Plan B” style SDP and the APIs that have been removed from the standard. We realize that this will be a big change that affects a lot of you, so we want to get your feedback about the transition plan before we charge on ahead. Here’s our plan so far.

New RTCConfiguration Option: SdpSemantics

There will be a new configuration option for PeerConnection which will enable compatibility with Unified Plan SDP and new APIs. There are two options for SdpSemantics:

• PlanB: PeerConnection will continue behaving as it does now.

• UnifiedPlan: PeerConnection will create and set Unified Plan offers/answers. PeerConnection will fail to set Plan B offers/answers with more than one audio or more than one video track. Some APIs will stop working and others will become available (see below).

The chosen SdpSemantics should be specified in RTCConfiguration when creating the

PeerConnection and cannot be changed on the fly.

Added APIs

The following APIs will be available to PeerConnections configured with UnifiedPlan semantics:

• AddTransceiver()

• GetTransceivers()

• RtpTransceiver object

• OnTrack event with RtpTransceiver

Removed APIs

The following APIs are still available to PeerConnections configured with PlanB semantics but are not available with UnifiedPlan semantics and will be removed in the future:

• AddStream(): replaced by AddTrack()

• RemoveStream(): replaced by RemoveTrack()

• local_streams(): replaced by GetSenders()

• remote_streams(): replaced by GetReceivers()

• CreateSender(): replaced by AddTransceiver()

We’re putting together a migration guide to help you transition your application to the new APIs and will release it shortly.

Timeline

The following is the transition plan we’d like to propose along with approximate dates at which the various changes will happen to the head of the WebRTC repository:

• End of April 2018: “Unified Plan” and the new APIs stabilizes. We encourage everyone to switch to UnifiedPlan semantics and the new APIs.

• July 2018: Default SdpSemantics changes to UnifiedPlan. APIs listed under “Removed APIs” (except CreateSender) are removed at the same time.

• No earlier than end of year 2018: PlanB semantics removed and UnifiedPlan becomes the only option.

We’d like to hear any thoughts or concerns you have about the proposed transition plan and timeline. Once “Unified Plan” is ready for general consumption (this month), we’ll describe in more detail the changes and outline the finalized transition plan based on the sentiment we gather here.

Thanks on behalf of the WebRTC API team.

[Philipp Hancke]

Timeline

The following is the transition plan we’d like to propose along with approximate dates at which the various changes will happen to the head of the WebRTC repository:

• End of April 2018: “Unified Plan” and the new APIs stabilizes. We encourage everyone to switch to UnifiedPlan semantics and the new APIs.

• July 2018: Default SdpSemantics changes to UnifiedPlan. APIs listed under “Removed APIs” (except CreateSender) are removed at the same time.

• No earlier than end of year 2018: PlanB semantics removed and UnifiedPlan becomes the only option.

We’d like to hear any thoughts or concerns you have about the proposed transition plan and timeline. Once “Unified Plan” is ready for general consumption (this month), we’ll describe in more detail the changes and outline the finalized transition plan based on the sentiment we gather here.

i assume the removal will affect Chrome as well? Then this timeline seems a bit optimistic.

How is chrome's proprietary vp8 simulcast covered?

[Emil Ivov]

On Thursday, April 12, 2018 at 1:46:45 PM UTC-5, steve...@webrtc.org wrote:

• No earlier than end of year 2018: PlanB semantics removed and UnifiedPlan becomes the only option.

Please don't do this.

 

It would be great to first get feature parity with Unified and make sure that things like Simulcast are equally well supported before we start talking about removing Plan B semantics.

Right now I am not even sure that there's a "standard" way of achieving Chrome's current behaviour with Unified.

[Harald Alvestrand]

We'll certainly keep Plan B around until the number of users is low enough that we can delete it without much impact. We'll also continue adding support for standard ways of achieving what was previously done with SDP mangling - we just landed Get/SetParameters on RTPSenders, for instance.

Emil, do you see the option of running applications with the explicit "plan B flag" as reasonable for those applications that don't work with Unified Plan yet?

What I feel least certain about in the Chrome plan (and the reason it's not published yet) is the day for flipping the default - after that date, apps that depend on Plan B without having explicitly asked for Plan B will start breaking. But the benefit is that (hopefully) we'll have no new code written that expects Plan B to be the default.

Harald

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2d15e40a-ddfc-4f22-a1f2-ea842d8162bc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andriy Tylychko]

deprecating/removing APIs please update samples as the first thing. PeerConnection sample still uses `AddStream()`, `local_streams()` and others)

[Harald Alvestrand]

We intend to keep those APIs in Chrome until usage has declined quite a bit more.

The Chrome implementation of these functions no longer uses the corresponding C++ APIs.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b0ce77fa-7090-4038-9fd4-3229730a2e73%40googlegroups.com.

[steve...@webrtc.org]

Thanks for pointing to the out of date example. It's now been updated as of https://webrtc-review.googlesource.com/c/src/+/70341 which landed a couple days ago.

On the mobile side, AppRTC was updated to the new APIs a month ago. Here are the changes: iOS | Android

A more complete migration guide with code examples will be sent out soon.

[Andriy Tylychko]

Thanks. Just had a chance to check it, noticed `cricket::VideoSource` is still used, I thought it's deprecated: https://groups.google.com/d/msg/discuss-webrtc/aWXpi7-V_Yc/x7EqljTWCQAJ. 

Also, when I checked this implementation of `VideoSource` didn't work for me on Windows with Logitech "HD Pro Webcam C920" which I believe is one of the most popular. It asserted on DirectShow filter `Pause()` call if I remember correctly.