Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)

[Paul Kyzivat <[e-mail]>]

On 4/16/15 2:02 PM, Adam Roach wrote:
> On 4/14/15 08:59, Paul Kyzivat wrote:
>> On 4/13/15 8:27 PM, Christian Groves wrote:
>>> Hello,
>>>
>>> Please see below [CNG].
>>>
>>> Regards, Christian
>>>>> What is the motivation for declaring any extensions to signalling
>>>>> systems out of scope? (Not saying I see any that need to be
>>>>> created, but
>>>>> I'm surprised that it's not something that the group might need to
>>>>> investigate rather than making that call at chartering time)?
>>>>>
>>>> My reasons is to keep this WG focused on what it actually needs to
>>>> produce and not get completely tied up in discussion of exactly how one
>>>> will integrate this into ones signalling system. So I know people want
>>>> this in WebRTC and SIP based conferences. I haven't heard anyone saying
>>>> CLUE, but that is likely. These integrations are quite different,
>>>> especially in what pieces you will trust when it comes to client
>>>> software. Thus, my view was that WG working with signalling systems is
>>>> the ones that should provide any necessary integration towards the
>>>> framework.
>>> [CNG] I don't see CLUE being a lot different from normal SIP based
>>> conferences apart from the RTP header issue raised by Paul K. All CLUE
>>> is really doing is providing metadata to endpoints to allow them to
>>> select media captures more intelligently. If an endpoint is using
>>> private media there may be some consideration of "how much" CLUE
>>> metadata to provide to a 3rd party switch.
>>
>> You highlight an interesting point.
>>
>> If the goal is for the participants to conference without trusting the
>> intermediary that does the "switching", then they may also not trust
>> that intermediary to see the clue metadata that describes the media
>> and the participants. There might need to be a way for the
>> advertisements by the endpoints to be encrypted, so that the
>> intermediary can only collect them and pass them on to the other
>> endpoints.
>
>
> These are sent in RTP header extensions, right? RFC6904 lets you encrypt
> selected header extensions end-to-end. In the current PERC proposals,
> anything encrypted with RFC6904 would be visible to the participants,
> but not to the MCU.

No. The advertisements are send over a data channel. In a conference 
usage, they (and the RTP media) are sent to the mixer. Then the mixer 
can consolidate the advertisements it has received, and the 
corresponding media, in any manner it wants. The consolidated 
advertisements are sent out to the participants.

The mixer needs to respond to the advertisements. Doing so it indicates 
which media it wants to receive, which will affect what media it can 
offer. Superficially it is hard to conceive of how a mixer could do its 
job without being able to decode the advertisements it receives.

One possibility for a mixer is to "pass through" a merge of all the 
advertisements it receives to all the other participants - effectively 
treating them as blobs that are combined together. *In principle* it 
might be possible for the mixer to do this without being able to read 
the substance of those advertisements.

But that would certainly require some major redesign of the CLUE 
mechanisms. And even then it wouldn't work for more common usages such 
as where the mixer is making the decisions about switching sources based 
on voice activity.

	Thanks,
	Paul