- From: Henrik Boström <hbos@google.com>
- Date: Mon, 26 Aug 2019 10:23:40 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: public-webrtc <public-webrtc@w3.org>
- Message-ID: <CAEbRw2xN=T9Rdfd8oUJbC6mL9e1oyY=QSQ=aS9vjhmSB=ry90w@mail.gmail.com>
On Sun, Aug 25, 2019 at 7:31 AM Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > 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.) > Not use the ID that was passed in? Can you clarify what this refers to? On both Chrome and Firefox, I see the local stream ID reflected on the remote side, as expected: https://codepen.io/henbos/pen/QWLpmMK?editors=1010 Track IDs on the other hand should not be assumed to match <https://docs.google.com/document/d/1-ZfikoUtoJa9k-GZG1daN0BU3IjIanQ_JSscHxQesvU/edit?usp=sharing> . > > 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://www.coviu.com/ > >
Received on Monday, 26 August 2019 08:24:18 UTC