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

[Christian Groves <[e-mail]>]

Hello Jonathon,

On 14/04/2015 1:11 AM, Jonathan Lennox wrote:
>
>> On Apr 13, 2015, at 9:49 AM, Paul Kyzivat <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> On 4/13/15 4:33 AM, Magnus Westerlund wrote:
>>> On 2015-04-10 16:37, Robert Sparks wrote:
>>>> So, I think this should get chartered.
>>>> I have a couple of charter-bashing questions/comments.
>>>>
>>>> It would be good to be clear what any interactions with the work in 
>>>> CLUE
>>>> might be.
>>>
>>> I hope someone more active than me can step in an give their view here.
>>> To me this should be possible to use with CLUE. I don't know if that
>>> will be possible without any extensions to the clue part.
>>
>> I *think* there will be a problem: that a mixer won't be able to 
>> insert the clue capture-id into the RTP/RTCP.
>>
>> Roni and Jonathan should be able to be more definitive about this.
>
> PERC will need the ability for the middleboxes to insert hop-by-hop 
> header extensions and RTCP SSRC values — BUNDLE will need this for the 
> mid values.
>
> Once we work out how to do this securely, the same mechanism should 
> work for capture-id for CLUE.

[CNG] Is this something we need to address in 
draft-ietf-clue-rtp-mapping, e.g. the captureID shouldn't be encrypted 
to facilitate switching? Any CLUE endpoint type may use the CaptureID 
header extension. I guess we don't want the situation where an endpoint 
encrypts the captureID and then a middlebox appends another captureID to 
switched RTP stream.

Regards, Christian