PSA: Unified Plan M71 Experiment; M72 Target - Applications May Break! Please Update Your Code

[hb...@webrtc.org]

"Unified Plan" is the standards conformant SDP format. "Plan B" is the SDP format that is currently the default in Chrome. Firefox speaks Unified Plan already, and it is available behind a flag in the latest Safari Technology Preview.

Chrome's default SDP format is about to change to Unified Plan. In many cases, this will cause backwards compatibility issues with clients running Plan B. The SDP is incompatibly different when multiple tracks of the same kind are on offer (multiple tracks per m= section). Other assumptions, such as local and remote track IDs matching, may be Plan B-only and generally not valid anymore.

Developers need to test their code in Plan B, Unified Plan and Plan B <-> Unified Plan scenarios to see if they are impacted by the switch and prepare accordingly.

In M71 Canary/Dev (now) we are experimenting with making Unified Plan the default. Clients in these release channels will on startup randomly be configured to use Plan B or Unified Plan as the default. In this version, a deprecation warning was added to setLocalDescription/setRemoteDescription to warn against Plan B style SDP that is incompatible in Unified Plan.

M72 is the current target for making Unified Plan the default behavior (beta December 2018, stable January 2019).

See the transition plan page for up-to-date information.

Applications are able to explicitly set which SDP format to use by passing {sdpSemantics:'unified-plan'} or {sdpSemantics:'plan-b'} to the RTCPeerConnection constructor. This will continue to be possible until Plan B is deprecated and removed some time in the future.

As of M69 (stable September 2018), Unified Plan applications have access to the RTCRtpTransceiver APIs. This is a large chunk of WebRTC 1.0 that is heavily tied to the Unified Plan SDP format.

What application developers need to do is:

1. Determine if the switch affects you, such as if you get a deprecation warning in M71+, you parse or modify Plan B style SDP or you rely on local and remote track IDs matching. Test your application between clients of different sdpSemantics and browsers. If you're unaffected, you don't have to do anything.

2. Fix your application. Either make sure you are able to handle both Plan B and Unified Plan or explicitly set the SDP format to Unified Plan (sdpSemantics:'unified-plan') to avoid surprises when the switch happens.

3. If you are not able to transition to Unified Plan before the switch you can explicitly set the SDP format to Plan B (sdpSemantics:'plan-b') and your application won't break when the switch occurs, but note that Plan B will not be supported indefinitely and you should make plans to switch as soon as possible.

For more details on Plan B and Unified Plan differences and how to prepare for the switch, see "Unified Plan" Transition Guide (JavaScript).

[Alexey]

How Simulcast will work with Chrome+Unified plan?
Currently in Chrome 70, code which works in FireFox (which sets 3 encoders in RTPSender settings before first createOffer call) fails with something like “cannot change read-only property” in sender.setParameters.

Do you have any working code example?
Or simulcast is not available in Chrome 70+Unified Plan?

[hb...@webrtc.org]

Take a look at the native transition guide too: Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API.

It has a section on simulcast: Simulcast will be supported with addTransceiver()'s sendEncodings and RTCRtpSender.getParameters()/setParameters() as part of the RTCRtpTransceiver APIs, but this is not supported yet through the APIs. In the meantime, you can continue to modify the SDP in the same way that is currently done in Plan B.

[sham...@webrtc.org]

Hi Alexey,

Setting up simulcast in Chrome with Unified Plan is done how it is currently done today by munging the SDP. This is specified in greater detail in the Native Transition Guide (from this PSA). You cannot setup simulcast through the means of the JavaScript web API. Future support will be added for this  by specifying multiple sendEncodings with addTransceiver.

-Seth

[Harald Alvestrand]

For info: This experiment went live on Thursday/Friday. So anything WebRTC that's not working today that was working on Wednesday may be due to Unified Plan.

--

---
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-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/dcf7ee62-de1b-4dff-9e6a-6f7c695ee2c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philipp Hancke]

The experiment will only affect M71+, not M69 (still stable) or M70 (currently rolling out)?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVFJ2Ccw%3DadVbneMVM0k9pEFFMYvMTy%2B9%3DLR92y-wAuhog%40mail.gmail.com.

[Harald Alvestrand]

This experiment will only affect users on the Canary and Dev channels.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKi%2BHs0ApKgHbTfC1hpW8jS3t7ApsCm5HcyyYKNUmLx-XcQ%40mail.gmail.com.

[anil kumar d]

Am currently testing it in canary version 72 and facing few issues w.r.t to creating peerconnection with this new attribute(sdpSemantics).. We have some constraints which we are setting it while creating peerconnection like googDscp, googIPv6, DtlsSrtpKeyAgreement. If i pass "sdpSemantics:'plan-b'" as part of that constraints list it is not picking it. Default 'unified-plan' is set. if i don't set other constraints and set only "sdpSemantics:'plan-b'" this works. Can someone clarify on this ??

[gui...@webrtc.org]

On Tuesday, November 6, 2018 at 8:55:01 AM UTC+1, anil kumar d wrote:

Am currently testing it in canary version 72 and facing few issues w.r.t to creating peerconnection with this new attribute(sdpSemantics).. We have some constraints which we are setting it while creating peerconnection like googDscp, googIPv6, DtlsSrtpKeyAgreement. If i pass "sdpSemantics:'plan-b'" as part of that constraints list it is not picking it. Default 'unified-plan' is set. if i don't set other constraints and set only "sdpSemantics:'plan-b'" this works. Can someone clarify on this ??

Tracking this issue on https://crbug.com/907492.

 

[Philipp Hancke]

sdpSemantics is not part of the constraints (oddly; its nonstandard) but of the RTCConfiguration which is the first argument.

--

---
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-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ef0d691d-d0a2-477b-9725-f9bb9fd02249%40googlegroups.com.

[Harald Alvestrand]

In this holiday season, and with M72 rolling to beta just before the holidays, its seems appropriate to remind everyone of this important announcement.

If you use WebRTC, it WILL affect you.

--

---
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-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/dcf7ee62-de1b-4dff-9e6a-6f7c695ee2c5%40googlegroups.com.

[Roman Shpount]

I just wanted to make sure, that you are aware that Chrome 72 beta currently breaks all implementations that do no support MID, such as anything using Freeswitch to bridge WebRTC with PSTN? This is being tracked in https://crbug.com/901787 

As it stand right now, if unified plan is enabled, and chrome produces an audio only offer with mid attributes, then setting remote description without mid in the answer, this answer is rejected with an error "Failed to set remote answer sdp: The order of m-lines in answer doesn't match order in offer. Rejecting answer." This contradicts JSEP section 5.10, so it is not something required by unified plan and is an implementation bug.

From what I can see, a lot of applications are currently either breaking or forcing plan-B sdp semantics to work around this.

Is this going to be fixed before Chrome 72 is released?

Regards,

______________

Roman Shpount

[Harald Alvestrand]

This is https://bugs.chromium.org/p/webrtc/issues/detail?id=9540

Fixed in M73, should have been downintegrated to M72.

--

---
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-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c679b7da-5d96-4b5d-8d7f-ad1b07c066eb%40googlegroups.com.

[anil kumar d]

problem is.. if we set "sdpSemantics" as first argument it works but we cant set "RTCConfiguration". As part of constraints also we cant set it .. so how do we handle this now ?

[Roman Shpount]

This is still broken in the official beta release (72.0.3626.28). Canary also currently have an issue with ICE nomination which makes it impossible to fully validate this fix there. The only way to test this now seems to require building a version of Chromium. Is it possible to hold turning unified-plan for everybody until its implementation fixes are tested? If this issue is not fixed, the impact of this bug would be rather large and will disrupt a considerable number of services.

Regards,

______________

Roman Shpount

[Philipp Hancke]

Harald,

given quite a number of bugfixes which were merged into M72 pretty late: what is the rush?

Or to ask differently, what indications do you have that this is not going to be yet another disaster?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVEAA8veuV1bFt9qkiZX-wy7%3DzyZ7LjDuACQUnb0w_M%2BdQ%40mail.gmail.com.

[hb...@webrtc.org]

It looks like Beta still has not had a new release, but the next version of Beta should have it, the fix will be in 72. In the meantime it is available in Canary as of 73.0.3646.0. Roman, can you verify with a recent Canary?

[Roman Shpount]

The js-fiddle example does work with Canary but it looks like ice-lite support is broken there. For some reason when connecting to an ice-lite server, ICE nomination process fails. Because I am testing against the server which is using ice-lite and no mid in responses, I cannot verify that the fix is completely working (two way audio is established) with Canary.

I am planning to check if ice-lite issue was already reported and open a ticket if it is not.

[hb...@webrtc.org]

Thanks, keep us updated.

[i...@aliax.net]

El viernes, 4 de enero de 2019, 1:30:30 (UTC+1), Roman Shpount escribió:

The js-fiddle example does work with Canary but it looks like ice-lite support is broken there. For some reason when connecting to an ice-lite server, ICE nomination process fails. Because I am testing against the server which is using ice-lite and no mid in responses, I cannot verify that the fix is completely working (two way audio is established) with Canary.

I am planning to check if ice-lite issue was already reported and open a ticket if it is not.

Hi Roman.

OSX, Canary Version 73.0.3660.0 (Official Build) canary (64-bit). ICE-Lite is working fine for me. No issues so far.

[Roman Shpount]

Hi All,

I have retested with Chrome 72.0.3626.53 and unified plan seems to work correctly with no mid/bundle in the setRemoteDescription SDP. It looks like this specific issue was solved in this beta build.

It looks like Chrome Canary 73.0.3668.0 is broken with ICE nomination failing when a=setup:passive is present in the answer. We are putting together a js-fiddle to confirm and demonstrate the issue. Currently the issue can be seen when going to https://panel.turbobridge.com/webcall/ and placing the test call. This works on M72 but breaks on M73.

Thank You,

[gmemo...@gmail.com]

Is M72 still the target for unified plan? We are using lib-jitsi-meet, and their stable github repo is not updated yet with the unified plan change (although they have made the change: https://github.com/jitsi/lib-jitsi-meet/pull/830). So, wondering if M72 still is the target for unified plan. If so, when will the stable M72 start to roll out?

Thanks!!

[Harald Alvestrand]

Yes, M72 is still the target. It has now been turned on 100% in beta.

https://chromiumdash.appspot.com/schedule gives the target release dates.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/64eeb5db-0a15-4258-b18d-b1c61167253e%40googlegroups.com.

[Philipp Hancke]

M72 is the target for changing the *default* sdpSemantics. jitsi meet is opting out by setting sdpSemantics to plan-b so should not break.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/64eeb5db-0a15-4258-b18d-b1c61167253e%40googlegroups.com.