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

On a related note, RTCRtpSender.setStreams() is shipping in Chrome M76,
allowing you to update the stream association when recycling transceivers.

On Mon, Aug 26, 2019 at 10:27 AM Henrik Boström <hbos@google.com> wrote:

> 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/
>>>
>>>