Re: The abysmal state of interoperability for the m-section of SDP

Silvia said:

"To support older versions of browsers, we now have to maintain an ever
growing matrix of combinations of browser versions so we can indicate
to a user who is joining a call whether they will have
interoperability issues with the other peer - specifically we have to
tell them whether screensharing is available to them or not."

[BA] Are you encountering any incompatibilities with respect to the Screen Capture<https://w3c.github.io/mediacapture-screen-share/> specification?
Or is this just a problem with Webrtc-PC?

Also, are you using addTransceiver or addTrack/setParameters?
________________________________
From: Harald Alvestrand <harald@alvestrand.no>
Sent: Monday, August 26, 2019 11:46 AM
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>; public-webrtc <public-webrtc@w3.org>
Subject: Re: The abysmal state of interoperability for the m-section of SDP

Thanks for the report!

I assume that the individual issues have been filed in the respective
browsers' bug trackers - it would also be great if you could have a look
to see if there are web platform tests that test the behaviors that
cause non-interoperability; both things help us check the browsers
against the spec to see that they are in sync - and where they aren't,
which one is doing it wrong. (It might be the spec!)

Thanks for trying this out and reporting the results!


Den 25.08.2019 07:28, skrev Silvia Pfeiffer:
> Hi all,
>
> This is a bit of a rant, but I thought it would be important to share
> how painful it is right now to work across browsers with WebRTC and
> where I'd like to see some improvements.
>
> We are an avid user of multiple parallel media streams between peers
> in a video call. We often send one or more screenshares at the same
> time as the video call itself. This makes it possible to look at a
> person while sharing the screen, something I've always found bizarre
> in most traditional video conferencing applications. We can't have
> that in a telehealth application where the clinician needs to always
> be able to see a patient.
>
> In the past, we had no interoperability between Firefox and Chrome
> because Chrome supported Plan B (which incidentally worked really
> well) and Firefox did Unified Plan. We waited patiently for Chrome to
> support Unified Plan and rejoiced when it came. But we were out of
> luck. Moving to Unified Plan with Chrome didn't make sense for us,
> because Firefox decided to make secondary streams not use the ID that
> is passed in, but use something else altogether. So we held back,
> because we still couldn't make it work interoperably. (Thanks Firefox
> for not following the standard.)
>
> Now, Safari has decided to jump to Unified Plan - rejoice! Oh, but
> wait! Instead of offering backwards compatibility, it removed Plan B.
> What!? We now face the bizarre issue that our iOS app (developed
> before Safari supported WebRTC) is now not able to interoperate with a
> modern Safari. Awesome, thanks.
>
> Anyway, we soldier on. We have moved to Unified Plan and fortunately,
> Safari and Chrome are interoperable. Yay! But Firefox continues to
> plague us.
>
> To support older versions of browsers, we now have to maintain an ever
> growing matrix of combinations of browser versions so we can indicate
> to a user who is joining a call whether they will have
> interoperability issues with the other peer - specifically we have to
> tell them whether screensharing is available to them or not. It would
> be really nice if the complexity of WebRTC interoperability would
> reduce over time, not continuously increase.
>
> So much for news from the coalface... please get interoperable Unified
> Plan sorted - we have waited for more than 5 years for this already!
>
> Kind Regards,
> Silvia.
> ---
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.coviu.com%2F&amp;data=02%7C01%7CBernard.Aboba%40microsoft.com%7Cbf47106685b34e85931308d72a55f496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637024420983982234&amp;sdata=yyRBlMCaQ8KNJEZ0bKDuZWAURGQ4w6p4njVwUndzitg%3D&amp;reserved=0
>