Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

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@gmail.com> 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@gmail.com> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
>>
> --
sent from my mobile