- From: Henrik Boström <hbos@google.com>
- Date: Mon, 26 Aug 2019 10:27:31 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: public-webrtc <public-webrtc@w3.org>
- Message-ID: <CAEbRw2xVyYn+JqeU3Ptowabcc6r8URCLFg-xeLhjTF1VKefnsA@mail.gmail.com>
See also Jan-Ivar's blog post, Exploring RTCRtpTransceiver <https://blog.mozilla.org/webrtc/rtcrtptransceiver-explored/>, on how to correlate tracks using "transceiver.mid", if you don't want to look at stream IDs. On Mon, Aug 26, 2019 at 10:23 AM Henrik Boström <hbos@google.com> wrote: > > 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:28:06 UTC