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

["Roni Even" <[e-mail]>]

Hi,
Coming late but I support this work and will be involved by reviewing the work.
As for CLUE support it should be in the background but the important topic to address is what RTP topology we are addressing here and later see what it will mean to CLUE.

The RTP topology work describes multiple topologies and not all of them are supported by an MCU that will support CLUE.

Roni Even

> -----Original Message-----
> From: dispatch [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 13 April, 2015 4:50 PM
> To: [e-mail]
> Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP
> Conferencing (PERC)
> 
> 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.
> 
> 	Thanks,
> 	Paul
> 
> >> 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.
> >
> >
> > I do note that this consideration of integration is mentioned in this
> > paragraph under Non-Goals:
> >
> > "The WG is not chartered to extend any signaling system used to
> > establish the RTP based conferences. It will however, need to consider
> > in its architecture how the solution may integrate with these systems."
> >
> > But, I guess one could be more explicit and require the WG to consider
> > how one integrate into WebRTC, SIP and CLUE so that the framework is
> > functional for these systems.
> >
> > When it comes to the key-management function, I think there exists an
> > assumption here. That is that signalling and its nodes can't be
> > trusted, only possible be used as a transport for key-management
> > system information. But that will require that the communication fails
> > if someone strips or modify such information.
> >
> > Does this help clarify the situation.
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Services, Media and Network features, Ericsson Research EAB/TXM
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  [phone]
> > Färögatan 6                 | Mobile [phone]
> > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > ----------------------------------------------------------------------
> >
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch