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

[Adam Roach <[e-mail]>]

On 4/9/15 16:29, Ben Campbell wrote:
> For the record, I'd love to see this get chartered. I think the 
> charter is on the right track. It might be worth mentioning the drafts 
> in the charter as "inputs" to the work.
>
> Is anyone else interested in working on this?

We're definitely interested in implementing client functionality to 
support the requirements outlined in 
draft-jones-avtcore-private-media-reqts. I am willing to provide 
feedback on the work and to convey information back from our 
implementation team as the specifications progress.

On 4/10/15 09:37, Robert Sparks wrote:
> 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)?

I think that the expertise required to make PERC successful is somewhat 
different than that involved in extending SIP in a sensible fashion. I 
would prefer this WG talk about the nature of the information that needs 
to be exchanged in order to make the system work, and then have a 
separate effort that discusses how to encode it at the signaling layer. 
I suspect that the majority of this information will be conveyed in SDP 
for SIP and JSEP, and that the corresponding specification work would 
take place in MMUSIC. From that perspective, it would probably be good 
to mention MMUSIC in the "Collaboration" section of the charter.

Based on the architecture as proposed in the drafts, there will probably 
be one or more new interfaces that don't presently exist (e.g. to convey 
identity information from the key server to the participants). These 
aren't extensions to "any signaling system used to establish the RTP 
based conferences," and there aren't existing protocols that clearly 
handle them (as far as I know). I think the charter should be clear on 
whether development of protocols for these interfaces are in scope. If 
they're not, we should at least have some idea of where they *will* be 
developed.


On 4/13/15 08:49, Paul Kyzivat wrote:
> I *think* there will be a problem: that a mixer won't be able to 
> insert the clue capture-id into the RTP/RTCP.

One of the really important characteristics of the current proposals is 
that they allow the MCU (not really a mixer, more of a switcher) to 
read, add, modify, and remove RTP header extensions. There is a 
mechanism for end-to-end encryption of some extension headers if the 
endpoints require that property, but it's optional.

/a