Intent to Implement and Ship: Simulcast with PeerConnection AddTranceiver API in WebRTC

[Amit Hilbuch]

Contact emails

ami...@chromium.org

orp...@chromium.org

Explainer

Simulcast capability allows a client to send multiple encodings (layers) of the same video source.

This scenario is most relevant in group/conference calls utilizing a central routing server (aka Selective Forwarding Unit or SFU).

The SFU allows a diverse set of clients to interact, each maximizing their experience without negatively affecting one another.

Simulcast is already supported in WebRTC by munging the SDP.

This forms part of the RTCPeerConnection API, and allows applications to use Simulcast in WebRTC directly by calling the addTransceiver() API, without munging or hacking the platform.

Design doc/Spec

http://w3c.github.io/webrtc-pc/#simulcast-functionality

https://tools.ietf.org/html/draft-ietf-mmusic-rid-15

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-13

Summary

This intent to implement and ship covers spec-compliant Simulcast.

With addTransceiver(), users supply multiple send encodings for a single source and use the rid attribute of RTCRtpCodingParameters to uniquely identify them.

This has no effect outside of the Simulcast scenario.

Motivation

This is part of the “WebRTC 1.0 complete” effort - giving support for all the relevant features of the WebRTC-PC specification.

This enables the users to explicitly request simulcast for video sources, without needing to manipulate the SDP in the peer-to-peer negotiation.

Risks

Interoperability and Compatibility

This improves interoperability as Simulcast is currently achieved in a non-standard way.

All browsers agreed to complete the WebRTC 1.0 specification, so there shouldn’t be any long term interoperability issues.

Compatibility is maintained for the legacy scenario. Users can still munge the SDP to use simulcast without being spec-compliant.

Edge: Public support for implementing WebRTC 1.0

Firefox: Shipped simulcast. Public support for implementing WebRTC 1.0

Safari: Public support for implementing WebRTC 1.0

Web / Framework developers: Positive, simulcast support is a much requested feature.

Ergonomics

RIDs and layers are used when creating RTCRtpSender and in calls to RTCRtpSender.getParameters() and RTCRtpSender.setParameters()

Activation

There shouldn’t be any activation issues.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

WPT tests check the specification of layers with the rid attribute:

Existing WPT tests as part of the webrtc suite:

• RTCRtpParameters-encodings.html - checks that supplied rid values propagates to the sender, and is returned via getParameters().

• RTCRtpSender-getParameters.html - checks that rid property is returned empty in non-simulcast scenario.

• RTCRtpSender-setParameters.html - checks that rid values cannot be modified after layers are created.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4699744823672832

Requesting approval to ship?

Yes.

[Philip Jägenstedt]

Amit, I think this feature "shallow" in the sense that it's just a more convenient way to achieve the same SDP sent over the network. If so it sounds like a great web developer convenience (nobody loves SDP, I've heard) and not adding any new network behavior, making it fairly high value and low risk. If that's not right, please correct me.

For testing this, are all of the effects of this feature really testable using web-platform-tests? Is there a way to test cross-browser what the resulting SDP is when using this API? If not, do you have a sense for what the minimum additional infrastructure in web-platform-test would be to support testing this?

Given that Firefox has already shipped this and Edge is switching to Chromium, the interop risk would be that this isn't implemented in WebKit. I've poked https://bugs.webkit.org/show_bug.cgi?id=173262 and +Youenn Fablet here in case there are any issues to raise around this.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANJD8SaLTwp0NYqcquJ3tFXmLiSb56rWcsiy0o3cCczpuZ3gHg%40mail.gmail.com.

[i...@aliax.net]

Thanks for the update, Amit. Just a question:

> With addTransceiver(), users supply multiple send encodings for a single source and use the rid attribute of RTCRtpCodingParameters to uniquely identify them.

Would it also work if, instead of passing the desired encodings within the addTransceiver() method, I do it later by calling rtpSender.setParameters()? That's how I usually enable simulcast in Firefox.

[safaribro...@gmail.com]

On Tuesday, February 26, 2019 at 5:47:00 AM UTC-8, Philip Jägenstedt wrote:

Amit, I think this feature "shallow" in the sense that it's just a more convenient way to achieve the same SDP sent over the network. If so it sounds like a great web developer convenience (nobody loves SDP, I've heard) and not adding any new network behavior, making it fairly high value and low risk. If that's not right, please correct me.

For testing this, are all of the effects of this feature really testable using web-platform-tests? Is there a way to test cross-browser what the resulting SDP is when using this API? If not, do you have a sense for what the minimum additional infrastructure in web-platform-test would be to support testing this?

Given that Firefox has already shipped this and Edge is switching to Chromium, the interop risk would be that this isn't implemented in WebKit. I've poked https://bugs.webkit.org/show_bug.cgi?id=173262 and +Youenn Fablet here in case there are any issues to raise around this.

It is nice to see this feature coming in Chrome.

WebKit plan is to align with the spec as well.

[youenn fablet]

Le mardi 26 février 2019 05:47:00 UTC-8, Philip Jägenstedt a écrit :

Amit, I think this feature "shallow" in the sense that it's just a more convenient way to achieve the same SDP sent over the network. If so it sounds like a great web developer convenience (nobody loves SDP, I've heard) and not adding any new network behavior, making it fairly high value and low risk. If that's not right, please correct me.

For testing this, are all of the effects of this feature really testable using web-platform-tests? Is there a way to test cross-browser what the resulting SDP is when using this API? If not, do you have a sense for what the minimum additional infrastructure in web-platform-test would be to support testing this?

Given that Firefox has already shipped this and Edge is switching to Chromium, the interop risk would be that this isn't implemented in WebKit. I've poked https://bugs.webkit.org/show_bug.cgi?id=173262 and +Youenn Fablet here in case there are any issues to raise around this.

It is nice to see this feature coming in Chrome.

WebKit is also planning to support this.

[Joe Medley]

Amit,

Do you have a tracking bug for the Status entry? I need it at least.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[ami...@chromium.org]

Responding to the queries:

Tracking bug for this release:

https://bugs.chromium.org/p/chromium/issues/approval?id=936047

This feature is "shallow", it's a more convenient and spec-compliant way of achieving simulcast which is possible today through SDP munging and "proprietary" (non-spec-compliant) application logic. It does not add new network activity in terms of the media that gets sent.

However, it is not a way to achieve the same SDP. It generates different SDP which is spec-compliant that triggers the same behavior. But users should be oblivious to the SDP in this case and shouldn't need to inspect or modify it.

Testability: all of the new effects of this feature are testable using web-platform-tests, i.e. the ergonomics around interacting with the layers and configuring the peer connection.

The actual video being sent is not testable, nor should it be tested with WPT (IMHO), rather with other mechanisms/frameworks.

A really important aspect in spec-compliant simulcast is that it assumes that an SFU is used to mediate between all the participants in the group call. Two peers do not need simulcast, as they can directly negotiate the optimal parameters for their connection.

What this means is that two browsers cannot communicate directly via this API and they must use a mediator. We do not need to test the cross browser behavior. We can test that the SDP generated by each implementation fulfills the spec requirements when going through the same API setup (i.e. addTransceiver with multiple layers).

> > With addTransceiver(), users supply multiple send encodings for a single source and use the rid attribute of RTCRtpCodingParameters to uniquely identify them.

> Would it also work if, instead of passing the desired encodings within the addTransceiver() method, I do it later by calling rtpSender.setParameters()? That's how I usually enable simulcast in Firefox.

According to the spec (link above), the simulcast envelope cannot be changed once it is determined. Nor can the RIDs identifying the layers change.

You must specify the number of layers by creating multiple layers using addTransciever() and should specify the RID values. You can later use get/setParameters later to change characteristics and configure the layers, such as specifying the scale-resolution-down-by flags, or setting layers as active/inactive.

You cannot add or remove layers (thus changing the envelope) or change the layer RIDs after creation.

Layers can be disabled by using the active attribute and get removed if they are rejected by the other party (the SFU) or if Simulcast is rejected altogether (in which case you will be left with a single layer on the transceiver).

Thanks for all the interest. Looking forward to feedback.

[Philip Jägenstedt]

LGTM1, great to hear that this is also planned for WebKit, and that it's enabling things for web developers that previously required SDP munging.

On Tue, Feb 26, 2019 at 8:22 PM <ami...@chromium.org> wrote:

Responding to the queries:

Tracking bug for this release:

https://bugs.chromium.org/p/chromium/issues/approval?id=936047

This feature is "shallow", it's a more convenient and spec-compliant way of achieving simulcast which is possible today through SDP munging and "proprietary" (non-spec-compliant) application logic. It does not add new network activity in terms of the media that gets sent.

However, it is not a way to achieve the same SDP. It generates different SDP which is spec-compliant that triggers the same behavior. But users should be oblivious to the SDP in this case and shouldn't need to inspect or modify it.

Testability: all of the new effects of this feature are testable using web-platform-tests, i.e. the ergonomics around interacting with the layers and configuring the peer connection.

The actual video being sent is not testable, nor should it be tested with WPT (IMHO), rather with other mechanisms/frameworks.

A really important aspect in spec-compliant simulcast is that it assumes that an SFU is used to mediate between all the participants in the group call. Two peers do not need simulcast, as they can directly negotiate the optimal parameters for their connection.

What this means is that two browsers cannot communicate directly via this API and they must use a mediator. We do not need to test the cross browser behavior. We can test that the SDP generated by each implementation fulfills the spec requirements when going through the same API setup (i.e. addTransceiver with multiple layers).

That sounds good, thanks! The resulting SDP sounds like right layer to stop testing at. I know there are some tests in wpt/webrtc/ that use offer.sdp to validate things, is that the case for these tests as well? After grepping and skimming my best guess is no, but there are helpers and indirection involved.

Especially if there are differences with what Firefox does/allows, expanding the tests to cover those discrepancies could be valuable. But this is not a test review thread, the coverage may already be good.

[aside with API owner hat off]

While network activity like what video is sent is in principle testable in WPT just like fetch (HTTP) and WebSockets, I have no illusions that all of WebRTC's network behavior could be comprehensively tested in a cross-browser manner, since unlike HTTP, the network behavior is still being tweaked release-to-release.

I certainly agree that browser-to-browser behavior need in principle not be tested if the behavior of each browser is rigorously tested individually against mock network activity that looks like other browsers. In any case https://kiteboard.herokuapp.com/dashboard is browser-to-browser, so there is a place to add such tests if one wants to.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3cbc713c-0a65-46ec-b1b3-a27cc27eeda7%40chromium.org.

[Philipp Hancke]

I've tested in 74.0.3718.0 (which may or may not work) using this fiddle:

  https://jsfiddle.net/1p86L5xw/

The resulting SDP does show

  a=simulcast:send 0,1,2

which is different from the foo,bar,baz rids I request?

Further there are no a=ssrc: lines. Is that working as intended?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANJD8SaLTwp0NYqcquJ3tFXmLiSb56rWcsiy0o3cCczpuZ3gHg%40mail.gmail.com.

[ami...@chromium.org]

Thanks Philip J,

I've added a WPT for the simulcast SDP to the change that will make this all work.

Philipp H, thanks for your feedback as well.

This hasn't fully landed, there is a pending CL for hooking up the RIDs that you specify.

What you should be seeing is "a=simulcast:send 0;1;2" with ';' and not ','.

These are auto-generated RIDs for the layers that were supplied without RID values (because the RIDs you provided did not propagate to WebRTC).

There is a WPT for this scenario exactly and works as you expect. You can check it out in the review link below, and also get an indication for when this actually lands which will be after API owners approval (they are not mere rubber stamps).

https://chromium-review.googlesource.com/c/chromium/src/+/1483352

As for SSRCs. They should not be signaled at all in unified plan, but i realize that they are for many scenarios because the signaling is somewhat compatible, and that's ok.

However, when Simulcast is used, specifying SSRCs and RIDs introduces a conflicting source of identifiers, and harms the scenario as there is no way to correlate a RID to an SSRC in the SDP (at least not a spec-compliant way).

They are therefore not signaled at all in spec-compliant simulcast.

On Monday, February 25, 2019 at 3:40:06 PM UTC-8, Amit Hilbuch wrote:

[Henrik Boström]

Ping API owners for more LGTMs than Philip J's. This feature is on track and there is consensus among all major browsers.

[Daniel Bratell]

LGTM2

The API owner meetings are currently on Thursdays and on those we normally catch up on all outstanding requests that haven't been handled here on the mailing list during the week but feel free to ping if you think the responses are not coming. It happens that all of us thinks that we are waiting for some update on the intent/spec/tests while the intent author wants more feedback.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3bbacbde-0acc-4de0-a251-5be04d1a765a%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Philipp Hancke]

Am Do., 28. Feb. 2019 um 10:31 Uhr schrieb Henrik Boström <hb...@chromium.org>:

Ping API owners for more LGTMs than Philip J's. This feature is on track and there is consensus among all major browsers.

https://github.com/w3c/webrtc-pc/issues/1174#issuecomment-468307765 was just reopenend.

It seems there have been very different opinions about what was agreed upon.

It is a q quite odd to include a=ssrc lines on unified plan sdp without simulcast with the rationale that not enough endpoints support the mid extension but then drop them on simulcast sdp with the rationale that all other endpoints must support rid.

 

[ami...@chromium.org]

Thanks for your comment on this, and for reopening the issue on github so we can discuss further in the larger WG.

The logic for simulcast SDP is a bit different. Because the spec indicates use of a 'new' SDP construct (i.e. a=simulcast & a=rid in negotiation), i believe it is a fair assumption that the change that needs to be made to support this new construct should also contain support for mid and rid. I also believe it to be a fair assumption that endpoints that already recognize a=simulcast and a=rid which are candidates for using this scenario without requiring any changes, should also support mid and rid.

That being said, this change does not remove the ability to do simulcast in unified plan without support for mid and rid. applications for endpoints that do not support these headers can continue munging the SDP to send multiple encoding layers and will continue to work as before.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Iñaki Baz Castillo]

El jue., 28 feb. 2019 17:55, 'Philipp Hancke' via blink-dev <blin...@chromium.org> escribió:

It is a q quite odd to include a=ssrc lines on unified plan sdp without simulcast with the rationale that not enough endpoints support the mid extension but then drop them on simulcast sdp with the rationale that all other endpoints must support rid.

The difference is that those endpoints that support receiving simulcast are typically SFU servers rather tha common "endpoints". If they support Chrome "legacy" simulcast they should also support standard simulcast already (Firefox). So I don't know where the problem is. SFUs must support mid and rid.

[Chris Harrelson]

LGTM3

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALiegfkAHy-XOa2HWf%3DzdY0p70yWWDngsbLVTYUJw6tF2D%3DysA%40mail.gmail.com.

[bra...@opera.com]

I wasn't aware of the spec issue when posting my LGTM. Should we hold back until it's been resolved? Amit, what do you say?

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[ami...@chromium.org]

I do not think we should hold off, the implementation follows the spec.

There is a discussion in webrtc-pc on if SSRCs should be added to the negotiation.

I think that if we decide to make a behavioral change there, it can be addressed outside of this process, as it will live entirely in the webrtc codebase and have no impact or change to any chrome or web APIs (the results will only be visible in the generated SDP). This would be analogous to a bug-fix.

Thanks to all and especially to the API owners for your time, feedback and approval.

[Daniel Bratell]

Ok, looking forward to happy web developers!

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3bf7963a-356e-4916-8f9b-cfbc768e7667%40chromium.org.

[bernar...@gmail.com]

On Thursday, February 28, 2019 at 1:18:52 PM UTC-8, ami...@chromium.org wrote:

I do not think we should hold off, the implementation follows the spec.

[BA]  The WEBRTC APIs have maintained a mechanism for obtaining SSRCs since the object model was first added several years ago.  This was done so as to maintain backward compatibility with existing conferencing systems.  In order to ease the implementation burden and assist in meeting the March 2020 charter deadline, Taylor Brandstetter of Google requested that the instead of surfacing SSRCs within the object model, that they be surfaced in the SDP instead  His proposal accepted by the WG, on the understanding that Google would implement its own proposal.  Firefox has already shipped SSRC support in SDP as agreed upon.  The history is detailed in Github Issue https://github.com/w3c/webrtc-pc/issues/1174. 

The consequences of reopening this issue are potentially severe.  The alternative to surfacing the SSRCs in SDP is to surface them in the object model as per the original design.  However, at this point with Firefox having already shipped SDP support based on Google's proposal, going the object model route would require additional work that will undoubtedly push schedules out. 

The WebRTC WG Charter expires in March 2020.  By that time it is expected that the WG will demonstrate API as well as protocol interop.  One of the last impediments to reaching PR is demonstrating API and protocol interop with simulcast.  Given the tightness of the charter deadlines, requiring major additional work such as adding SSRCs back to the object model, or requiring conferencing system updates in order to demonstrate protocol interop increases the chance that the WG will fail to reach its milestones.  After 8+ years of operation, the W3C (and many of the WG participants) are eager to wrap things up. 

[Philip Jägenstedt]

Amit, is the plan to expose SSRC in the SDP like Firefox do?

And does the spec actually require anything on this point, are there tests that are passing in Firefox and failing in Chrome or vice versa? If there's not, can they be added?

[Harald Alvestrand]

It's been pointed out in private conversation that there doesn't exist a spec for how to expose SSRC information and RID information at the same time in the SDP. Perhaps we will have to write one.

Personally,  I think this should be a standalone IETF spec ("how to live with SSRC and RID signalling at the same time"), rather than attempting to patch this into one of the others.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfjqqQUrxPFCN4g2dkDzVngOkz5-tLJ8zAfs%3DNDuU9uxA%40mail.gmail.com.

[ami...@chromium.org]

For crispy clarity:

> Is the plan to expose SSRC in the SDP like Firefox do?

Currently, the plan is not to expose SSRCs because they collide with RIDs.

There will be a virtual interim meeting later this month, we will discuss the issue further then with the broader group.

> Does the spec require anything on this point?

The spec only requires RIDs.

> Are there any WPT tests that are passing on FF and failing in chrome?

No, there aren't.

> Can they be added? 

i don't think one should be added, because WPT should validate the spec, and the spec does not require SSRCs.

I did add WPT tests to validate that the SDP will contain the spec-required RIDs and Simulcast lines. These will be merged soon and i expect them to pass on both FF and Chrome.

> [BA, paraphrased by me] We need to be done by March 2020 including simulcast with interop.

Let's sync about this and any remaining work. 

I do not think that simulcast will be an issue, Firefox and Chrome can interop because the SFU is required. the SFU should ignore a=ssrc lines in the presence of RIDs and Simulcast. So as long as both implementations follow the spec, we should be good to go, even if one implementation adds SSRCs.

If push comes to shove, we will do what is needed to meet the deadline.

`a=rid:1 send ssrc=1234` is a very reasonable compromise that we might want to pursue spec-wise. It might even already comply with ietf, if we register ssrc as a RID restriction.

<disclaimer>

You may or may not know that i am new to webrtc and chromium. i do not know the full history and do not have all of the context. i will make mistakes, and i will also (unintentionally) do things that go against previous decisions, because i may not be aware of them.

</disclaimer>

<productive-and-respectful-rant>

I have heard about all of these implementations and SFUs that do not support MIDs, RIDs, or anything that wasn't around in the 19th century.

What i never heard (see #disclaimer), was specific names of these SFUs, their owners, or any stakeholders/users, and i have never seen numbers or data showing how much injustice we doing the world by trying to move towards what the WG has agreed to in the spec.

Nor have i heard anything about timelines or commitments to move these implementations forward to the 21st century, so that they can also support the spec.

It would really help if we had these numbers and commitments so that we can make progress towards improvement.

</productive-and-respectful-rant>

On Monday, March 4, 2019 at 3:10:40 AM UTC-8, Harald Alvestrand wrote:

It's been pointed out in private conversation that there doesn't exist a spec for how to expose SSRC information and RID information at the same time in the SDP. Perhaps we will have to write one.

Personally,  I think this should be a standalone IETF spec ("how to live with SSRC and RID signalling at the same time"), rather than attempting to patch this into one of the others.

On Mon, Mar 4, 2019 at 11:38 AM Philip Jägenstedt wrote:

On Mon, Mar 4, 2019 at 3:32 AM wrote:

On Thursday, February 28, 2019 at 1:18:52 PM UTC-8, ami...@chromium.org wrote:

I do not think we should hold off, the implementation follows the spec.

[BA]  The WEBRTC APIs have maintained a mechanism for obtaining SSRCs since the object model was first added several years ago.  This was done so as to maintain backward compatibility with existing conferencing systems.  In order to ease the implementation burden and assist in meeting the March 2020 charter deadline, Taylor Brandstetter of Google requested that the instead of surfacing SSRCs within the object model, that they be surfaced in the SDP instead  His proposal accepted by the WG, on the understanding that Google would implement its own proposal.  Firefox has already shipped SSRC support in SDP as agreed upon.  The history is detailed in Github Issue https://github.com/w3c/webrtc-pc/issues/1174. 

The consequences of reopening this issue are potentially severe.  The alternative to surfacing the SSRCs in SDP is to surface them in the object model as per the original design.  However, at this point with Firefox having already shipped SDP support based on Google's proposal, going the object model route would require additional work that will undoubtedly push schedules out. 

The WebRTC WG Charter expires in March 2020.  By that time it is expected that the WG will demonstrate API as well as protocol interop.  One of the last impediments to reaching PR is demonstrating API and protocol interop with simulcast.  Given the tightness of the charter deadlines, requiring major additional work such as adding SSRCs back to the object model, or requiring conferencing system updates in order to demonstrate protocol interop increases the chance that the WG will fail to reach its milestones.  After 8+ years of operation, the W3C (and many of the WG participants) are eager to wrap things up.

Amit, is the plan to expose SSRC in the SDP like Firefox do?

And does the spec actually require anything on this point, are there tests that are passing in Firefox and failing in Chrome or vice versa? If there's not, can they be added?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[nohl...@mozilla.com]

On Sunday, March 3, 2019 at 6:32:27 PM UTC-8, Bernard Aboba wrote:

On Thursday, February 28, 2019 at 1:18:52 PM UTC-8, ami...@chromium.org wrote:

I do not think we should hold off, the implementation follows the spec.

[BA]  The WEBRTC APIs have maintained a mechanism for obtaining SSRCs since the object model was first added several years ago.  This was done so as to maintain backward compatibility with existing conferencing systems.  In order to ease the implementation burden and assist in meeting the March 2020 charter deadline, Taylor Brandstetter of Google requested that the instead of surfacing SSRCs within the object model, that they be surfaced in the SDP instead  His proposal accepted by the WG, on the understanding that Google would implement its own proposal.  Firefox has already shipped SSRC support in SDP as agreed upon.  The history is detailed in Github Issue https://github.com/w3c/webrtc-pc/issues/1174. 

The consequences of reopening this issue are potentially severe.  The alternative to surfacing the SSRCs in SDP is to surface them in the object model as per the original design.  However, at this point with Firefox having already shipped SDP support based on Google's proposal, going the object model route would require additional work that will undoubtedly push schedules out.

It might be worth pointing out that Firefox has not shipped Simulcast support with SSRC's, because that is what was once agreed on. It was shipped in Firefox to enable backwards compatibility with Chrome's Plan-B implementation. Without SSRC's in the SDP Simulcast support for Firefox would have only been working among Firefox users.

In general I'm in favor of removing SSRC from SDP and webrtc.org code as much as we can (and replace them with MID and RID). So we are more then happy to remove SSRC's from simulcast SDP in Firefox to have browsers move forward the same way and help with interop.

 

Best regards

  Nils Ohlmeier

  Firefox Media Engineering Manager

[Iñaki Baz Castillo]

El mar., 5 mar. 2019 20:11, <nohl...@mozilla.com> escribió: 

In general I'm in favor of removing SSRC from SDP and webrtc.org code as much as we can (and replace them with MID and RID). So we are more then happy to remove SSRC's from simulcast SDP in Firefox to have browsers move forward the same way and help with interop.

Mee too. But take into account that FF still includes a=ssrc lines that signal the CNAME. Without those lines, how to signal it? 

https://github.com/w3c/webrtc-pc/issues/2114

[Harald Alvestrand]

The CNAME is supposed to be the same for all sources, so picking any CNAME from any RTCP packet would do the trick.

draft-ietf-rtcweb-rtp-usage-26 section 4.9 

"   Taking the discussion in Section 11 into account, a WebRTC Endpoint

   MUST NOT use more than one RTCP CNAME in the RTP sessions belonging

   to single RTCPeerConnection (that is, an RTCPeerConnection forms a

   synchronisation context).  RTP middleboxes MAY generate RTP packet

   streams associated with more than one RTCP CNAME, to allow them to

   avoid having to resynchronize media from multiple different endpoints

   part of a multi-party RTP session.

"

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALiegf%3DCr8x%3DXVWU9u%3DVeBgvh_MTdN14VF%3D0YWo-GFg9sdJYyQ%40mail.gmail.com.

[Iñaki Baz Castillo]

On Wed, 6 Mar 2019 at 08:47, Harald Alvestrand <h...@google.com> wrote:
>
> The CNAME is supposed to be the same for all sources, so picking any CNAME from any RTCP packet would do the trick.

Hi Harald, would you mind commenting in this issue?

https://github.com/w3c/webrtc-pc/issues/2114


--
Iñaki Baz Castillo
<i...@aliax.net>

[Òscar Divorra Escoda]

FWIW

In the thread, tracking bug is stated as :

https://bugs.chromium.org/p/chromium/issues/approval?id=936047

also in https://www.chromestatus.com/feature/4699744823672832

But seems not accessible (at least to me). It states "Permission denied" .

Is it going to open for general track ?

Thank you in advance.

Best,

     Òscar

[Harald Alvestrand]

The tracking bug https://bugs.chromium.org/p/chromium/issues/approval?id=936047 is an internal Google construct for tracking approval status, mostly a bureaucratic measure. We should find another bug for tracking development of the feature.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2f7d4ee0-d149-4f13-8fe1-2014bc3a8825%40chromium.org.

[Philipp Hancke]

Given that there doesn't seem to have been consensus at the last WG interim is this shipping?

Bugs like https://bugs.chromium.org/p/chromium/issues/detail?id=944821 break current behaviour even when not using the new API which makes this seems premature -- the workaround is to revert to plan-b sdpSemantics which is highly counterproductive.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVH1GJfEUxquJvVsKV3OPduKK_pm8SCw3bgrJf1MJWT5dg%40mail.gmail.com.

[ami...@chromium.org]

TL;DR: this is shipping.

I felt that there was consensus on the W3 WebRTC WG issues - there was no interest in reviving the ssrc property in encoding parameters - there was consensus on the API.

The issue of whether or not ssrcs should be signaled for backwards compatibility is an IETF issue, so it will need to be raised with that WG if there is interest. We heard that support for MID/RID demux already exists in some implementations.

It was also agreed (at least that was my understanding) that if W3 WebRTC WG is to demonstrate simulcast capability as part of 1.0 it needs to show different clients (ex: chrome + firefox) interacting with SFU (ex: janus/mediasoup) *without* signaling ssrcs at all, because they not in the spec. This should also hold for non-simulcast. We should be able to show that everything is working when the spec is implemented and not as a result of additional workarounds, which would not demonstrate interop (unless those workarounds become part of the spec).

On Wednesday, March 27, 2019 at 12:05:04 PM UTC-7, Philipp Hancke wrote:

Given that there doesn't seem to have been consensus at the last WG interim is this shipping?

Bugs like https://bugs.chromium.org/p/chromium/issues/detail?id=944821 break current behaviour even when not using the new API which makes this seems premature -- the workaround is to revert to plan-b sdpSemantics which is highly counterproductive.

There is no break when you are not using the new API. All existing code and applications still work as they did before, assuming that they used the system in a 'supported' manner (this is broad and includes munging to get simulcast).

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2f7d4ee0-d149-4f13-8fe1-2014bc3a8825%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.