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

Hi Henrik, all,

You are correct - we also haven't moved away from track IDs, because we
still encounter too many old browsers. We will see if that makes full
interoperability possible. Of course this means our matrix becomes even
more convoluted.

Nothing like living on the edge! 😀

Incidentally, we only have half a developer on WebRTC in a team of 3
developers, so adapting, testing and reporting are limited to a minimum. We
are looking for a full or part time WebRTC developer to join our team in
Brisbane Australia, but you can imagine the local market with that
capability is quite limited.

We will soldier on - after all, we committed to living on the bleeding edge
of browser capabilities a long time ago. And please don't get me wrong -
WebRTC *is* powering our business, so kudos to this group and the browsers
for all your work on it!

Thanks for listening to my rant from the coal face. 😀 Well report back in.

Cheers,
Silvia.


On Mon., 26 Aug. 2019, 6:23 pm 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/
>>
>>
>>