The scenario you outline may be one. I call that SSRC rewriting for Last N
Simulcast through SSRC rewriting (that you describe) is the one that concerns us currently.
On Sat 2 Feb 2019 at 12:51, Bernard Aboba <bernard.aboba@xxxxxxxxx> wrote:
Emil said:"I want to second that as it is a particularly major problem: not allowing SSRC rewriting makes the entire framework unusable with SFU implementation I represent as well as every other SFU I am familiar with."[BA] Can you articulate why you consider SSRC rewriting essential to SFU operation?I can think of one scenario where SSRC rewriting does seem to be *required* - Massive Online Courses (MOOCs). In these scenarios, there can be hundreds or even thousands of students, most of whom never speak during class, and teachers, who send media frequently. MOOCs can be implemented via streaming media instead of RTP, but this complicates the interactive aspect.So there are implementations of MOOCs that use RTP, and I believe that SSRC rewriting is an important part of the design of these systems. For example, there are currently limitations in browsers as to the number of transceivers that can be active, so that providing a transceiver for each of the participants in the conference could conceivably cause the browser to run out of memory.This is circumvented by not exposing participants to the SSRCs of all of the users. For example, the SFU may only allocate SSRCs for the professor and the "last N" students who have asked questions, so that a participant will only be aware of those SSRCs plus their own, instead of potentially needing to deal with the SSRCs of all the participants in the conference. This also has the effect of limiting the transceivers needed, most of which are in "recv-only" mode from the perspective of the course participants.When students wish to ask a question, permission is requested to access their devices (but not before). Then once the student is speaking, their SSRC is translated, so that participants do not necessary see a new SSRC but only the SSRC of "the current speaking student". Also, the SFU will typically consume the RTCP packets from students who are sending.On Sat, Feb 2, 2019 at 4:19 AM Emil Ivov <emcho@xxxxxxxxx> wrote:I want to second that as it is a particularly major problem: not allowing SSRC rewriting makes the entire framework unusable with SFU implementation I represent as well as every other SFU I am familiar with.I am also not sure that I agree with “SSRC rewriting could not be allowed” is a conclusion that ever had any consensus in PERC, regardless of what WG leadership is trying to make everyone believe.--On Sat 2 Feb 2019 at 06:21, Bernard Aboba <bernard.aboba@xxxxxxxxx> wrote:Richard said:"Again, the answer is clear here, but the document should be clearer. The working group discussed SSRC rewriting several times, and concluded that SSRC rewriting could not be allowed in this system. This decision is reflected, e.g., in the fact that the Double transform does not allow modification of SSRCs."[BA] Not being able to rewrite SSRCs has some major implications with respect to requirements on PERC endpoints. Typically today's MDD will switch between the simulcast streams provided by an endpoint, forwarding only a single stream to other participants, based on the bandwidth, resolution and framerates. If rewriting of SSRCs is not possible, do PERC endpoints need to be able to receive simulcast? If PERC endpoints do need to be able to receive simulcast, what are the requirements for endpoints? For example, should endpoints expect the MDD to use RID header extensions to identify the incoming simulcast streams?Receiving of simulcast is tricky because the endpoint is receiving multiple streams with different sequence number spaces which may contain holes because of reordering or loss. This not only complicates the application of RTX, RED and FEC, but also the operation of the endpoint. As a result, as noted in the WEBRTC specification Section 5.4.1, support for reception of simulcast is optional. I am aware of two ORTC implementations that have attempted to support simulcast reception, neither of which is robust in scenarios with considerable loss and/or reordering. And neither implementation supports the RID header extension on received simulcast streams.On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@xxxxxxxxx> wrote:_______________________________________________On 01/02/2019 17:18, Richard Barnes wrote:
So I would propose we add something like the following to this definition:
"In the context of WebRTC, where control of a session is divided between a _javascript_ application and a browser, the browser acts as the Trusted Endpoint for purposes of this framework (just as it acts as the endpoint for DTLS-SRTP in one-to-one calls).
If we decide to adopt perc (big if) in webrtc, shouldn't this be defined within the https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17 doc ?
Optimally, we would not rely on trust in any entities other than the browser. However, this is unfortunately not possible if we wish to have a functional system. Other network elements fall into two categories: those which can be authenticated by the browser and thus can be granted permissions to access sensitive resources, and those which cannot be authenticated and thus are untrusted.
WebRTC already IdP as trusted for identity purposes, so it should be up to the RTCWEB group to decide what is a trusted endpoint and what is not in webrtc. As Bernard is stating, we could decide that there are other key management solutions trusted (even in JS or WASM), as for for example is being done in EME:
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption
Best regards
Sergio
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc
sent from my mobile
sent from my mobile
