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

+1, SSRC rewriting is pretty much fundamental to all SFUs out there.

Lorenzo

Il 2 febbraio 2019 10:19:06 CET, Emil Ivov <emcho@jitsi.org> ha scritto:
>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

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.