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

[Bernard Aboba <[e-mail]>]

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 <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc
>