IETF
perc@jabber.ietf.org
Friday, July 22, 2016< ^ >
m&m has set the subject to: PERC @ IETF 95 (Buenos Aires)  Agenda: https://datatracker.ietf.org/meeting/95/agenda/perc/
Room Configuration
Room Occupants

GMT+0
[07:41:23] Meetecho joins the room
[07:55:09] Sean Turner joins the room
[07:55:11] Nils Ohlmeier joins the room
[07:55:17] Suhas Nandakumar joins the room
[08:02:50] Olle E. Johansson at IETF Berlin (GMT+1 DST) joins the room
[08:03:08] Deb Cooley joins the room
[08:03:35] Olle E. Johansson at IETF Berlin (GMT+1 DST) has set the subject to: PERC @ IETF96 | Agenda: https://www.ietf.org/proceedings/96/agenda/agenda-96-perc
[08:03:43] Olle E. Johansson at IETF Berlin (GMT+1 DST) is now known as oej
[08:03:53] Nils Ohlmeier leaves the room
[08:03:55] Randell Jesup joins the room
[08:04:11] oej is now known as oej SCRIBE
[08:05:32] Bernard Aboba joins the room
[08:05:39] Nils Ohlmeier joins the room
[08:05:48] <oej SCRIBE> Slide: Milestones & Documents
[08:05:55] <oej SCRIBE> Richard Barnes (chair) speaking
[08:06:05] <oej SCRIBE> Slide: Agenda
[08:06:08] <Bernard Aboba> Richard:  Have adopted documents.  Drafts welcome on integration with SIP and WebRTC.
[08:06:12] <oej SCRIBE> Adam Roach speaking
[08:06:18] <Bernard Aboba> Richard:  Agenda Bash.
[08:06:36] <Bernard Aboba> Cullen:  Assumed I was presenting, so I have slides.
[08:07:01] <Bernard Aboba> Richard:  Will add a brief 10 minute slot on SSRC immutability.
[08:07:02] Maire Reavy joins the room
[08:07:20] m&m joins the room
[08:08:39] Vincent Roca joins the room
[08:08:41] bergtau joins the room
[08:08:46] <Bernard Aboba> Richard: Should we pick the tempo back up with respect to virtual interims?
[08:09:06] <Bernard Aboba> David Benham: Framework discussion.
[08:09:18] <Bernard Aboba> (draft-ietf-perc-private-media-framework)
[08:09:56] <Bernard Aboba> David: In Buenos Aires we adopted 3 working group drafts, including framework draft.  Everyone has ready it, right?
[08:10:12] <Bernard Aboba> David:  Differences in -01.
[08:10:51] <Bernard Aboba> David:  Reduced acronyms.
[08:11:24] <oej SCRIBE> Notes on Etherpad - please help out and keep and eye on it. http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-perc?useMonospaceFont=true
[08:11:57] Jonathan Lennox joins the room
[08:12:42] <Nils Ohlmeier> Did other people also lost video and slides from the room?
[08:13:29] <Bernard Aboba> David: Outer SRTP master keys created by each endpoint. A conference-wide encryption key used to encrypt endpoint
[08:13:37] <Bernard Aboba> "Outer" master key.
[08:14:12] <Jonathan Lennox> Nils: as I understand it Meetecho should have a button to restart your streams.
[08:14:47] <Nils Ohlmeier> Jonathan: yeah clicking like 10 times on the refresh got me at least the slides back :)
[08:14:52] <Meetecho> yes, audio can be restarted with a button in the upper left (speaker icon circled by two arrows)
[08:15:04] <Sean Turner> nope - working fine here
[08:15:06] <Meetecho> video streams by hovering on the stream and clicking the half crcled icon
[08:15:20] <Meetecho> no need to click i tten times, though, just give it some time :D
[08:15:33] <Meetecho> (unless it takes way too much time, that is...)
[08:16:44] <Bernard Aboba> David: Constraints to rfc7667 topology mapping:  TOPO-PtP-translator or SFM w/single common SSRC space
[08:18:01] <Bernard Aboba> David: Add a list of RTP header extensions that should/must not be E2E encrypted?
[08:20:05] George joins the room
[08:20:07] <Bernard Aboba> David; Possibly add ability to transmit-only (one way)
[08:21:08] Deb Cooley leaves the room
[08:22:02] Deb Cooley joins the room
[08:22:04] <Bernard Aboba> EKR:  What is the use case?
[08:22:21] <Bernard Aboba> Cullen:  An announcement server that says "Cullen Jennings joined the conference".
[08:22:58] <Bernard Aboba> Jonathan:  How strong is this requirement?  Are you willing to drop it?
[08:23:06] <Bernard Aboba> David:  Someone brought it up on the list.
[08:24:27] <Bernard Aboba> Roni:  This bullet raises an issue which is not discussed.  You say MDD is not trusted content.  But this says it's not trusted with the media distribution.
[08:25:16] <Bernard Aboba> EKR:  I am assuming this is an E2E requirement.  So you need different directional traffic keys.  You extract different keys in each direction anyway, but this requires extracting 4 keys:  RTP and RTCP in each direction.
[08:25:40] <Bernard Aboba> EKR:  Could require surgery in EKT.
[08:26:20] <Bernard Aboba> Cullen:  EKT doesn't support this but we could do it.  Use case when someone joins a conference, can be delivered out of band, so we don't need to deliver through the audio channel.  I do not see a strong need for this, personally.
[08:27:31] <Bernard Aboba> Paul:  Explains how it could be added to EKT.
[08:27:53] Randell Jesup leaves the room
[08:28:01] <Bernard Aboba> Adam:  We already have hop-by-hop keys.
[08:28:25] <Bernard Aboba> Mo Zanaty:  One of the suggestions was to allow mixing of PERC and non-PERC media.
[08:29:18] <Bernard Aboba> Mo Zanaty:  Difficult for endpoint receiver to know whether it is trusted or not.
[08:29:33] <Bernard Aboba> David:  Started a section on identity trust.
[08:30:08] <Bernard Aboba> Emil on SSRCs and immutability.
[08:30:41] George leaves the room
[08:30:45] <Bernard Aboba> Emil: Currently, PERC says that an MDD cannot rewrite SSRCs.  There has been a lot of discussion around this.
[08:31:06] <Sean Turner> emil protesting the pink box ;)
[08:31:23] <Bernard Aboba> Emil: For me, this is quite problematc.  SSRC overwrites are used for active speaker switching (one SSRC as main speaker).
[08:31:49] <Bernard Aboba> Emil:  There is also simulcast.  Sender sends multiple layers, but receiver gets a single stream.
[08:32:27] <Bernard Aboba> Emil:  I am specifically concerned about simulcast case.  Only way to make it work with WebRTC (SSRC overwriting).
[08:33:13] <Bernard Aboba> Emil:  There is also RID-based approach.  Not clearly specified yet.
[08:33:54] <Bernard Aboba> Emil:  No motivation in SFU to add support for RID.  Why do it if you already have simulcast?
[08:34:33] <Bernard Aboba> Emil: Supporting PERC in SFU requires two branches of code - one to support WebRTC, and a separate branch for PERC (incompatible with WebRTC).
[08:34:54] <Bernard Aboba> Emil:  These arguments are against making RID the only way to use PERC.
[08:35:35] <Bernard Aboba> Emil:  Change is not to prohibit use of RID or to prohibit simulcast reception.
[08:36:18] <Bernard Aboba> Peter Thatcher:  RIDS are just there so you don't have to signal SSRCs.  So it's a red herring. Real question is whether endpoint can receive simulcast or not.
[08:36:37] <Bernard Aboba> Peter Thatcher:  Receiving simulcast a small part of total work....
[08:36:48] <Bernard Aboba> Emil Ivov:  There is so much work, so why not add more??
[08:37:15] <Bernard Aboba> Peter Thatcher: In a future version of WebRTC that supports PERC can we also support simulcast?
[08:37:25] Simon Pietro Romano joins the room
[08:37:55] <Bernard Aboba> Peter:  ORTC already supports reception of simulcast (with two implementations)
[08:38:09] <Bernard Aboba> Adam:  RID work is more mature than PERC.
[08:38:38] Vincent Roca leaves the room
[08:39:26] <Bernard Aboba> Richard:  Would anyone like to address benefits of immutable SSRCs?
[08:39:57] <Bernard Aboba> Colin Perkins: An architectural comment. Architecturally, we could implement this in either way.
[08:40:25] <Bernard Aboba> Colin Perkins: The discussion to have is where we want the complexity?  A simpler middle box or more complexity in receivers?  It is a design philosophy.
[08:41:01] Lorenzo Miniero joins the room
[08:41:44] <Bernard Aboba> Colin:  Technical point.  Does collision logic work?
[08:41:58] Nils Ohlmeier leaves the room
[08:42:17] <Bernard Aboba> Mo:  It can. This is how it would have to work to have a common SSRC space.
[08:42:28] <Bernard Aboba> Colin:  Not as simple as carrying the original SSRC.
[08:42:54] Nils Ohlmeier joins the room
[08:44:03] <Bernard Aboba> Mo:  What I thought was your original main point. For each participant there is a single decoder pipeline.
[08:44:32] <Bernard Aboba> Mo:  If it is simulcast reception you have a new decoder pipeline for each resolution.
[08:45:01] <Bernard Aboba> Mo:  This is why some architectures choose to receive different qualities (but not multiple streams).
[08:46:05] <Bernard Aboba> Emil: At WebRTC client level there is no support for receiving multiple streams, so that is why the SFU rewrites.
[08:46:36] <Bernard Aboba> Mo:  Since WebRTC browsers do not support this, you are worried about this??
[08:46:56] <Bernard Aboba> Emil:  Maintaining two ways of supporting simulcast also is not thrilling to me.
[08:47:40] George joins the room
[08:47:40] <Bernard Aboba> Cullen:  How does this work for audio?
[08:47:48] oej SCRIBE leaves the room
[08:48:01] <Bernard Aboba> Emil:  It is not needed for audio.
[08:48:06] Olle E. Johansson at IETF Berlin (GMT+1 DST) joins the room
[08:48:23] <Lorenzo Miniero> Emil is not saying there's no support for receiving multiple streams: just that it is not fast and effective enough to make it transparent and immediate in the client experience
[08:48:37] <Lorenzo Miniero> SSRC overwriting does
[08:49:30] <Bernard Aboba> Cullen:  If the middle box can switch SSRCs, can take packets from one...
[08:49:37] <Bernard Aboba> Emil:  Can send the original SSRC in the packet...
[08:50:43] Ben Campbell joins the room
[08:50:55] <Bernard Aboba> Jonathan:  Emil is saying that he is going to need to maintain this mechanism until everyone endpoint that only supports the original way is decommissioned.  And he does not want to maintain two code bases for this.
[08:51:10] <Bernard Aboba> Emil:  Don't agree that there is a security vulnerability.
[08:52:01] <Bernard Aboba> Jonathan:  Emil wants a different RTP topology than translator or single SSRC space.  So this gets into the framework discussion.  There are use cases in a conference where you want to send the same source twice.
[08:52:28] <Bernard Aboba> Jonathan:  You need to either have multiple MIDs for a source or SSRC rewriting to get that use case to work.
[08:53:38] <Bernard Aboba> Miguel:  Bottlenecks are in the browser side.  I agree with Emil.  Nowadays we need to rewrite SSRC.
[08:54:00] <Bernard Aboba> Miguel:  Why must SSRC be immutable?  I do not understand why.
[08:54:12] <Bernard Aboba> Roni Even:  This is more than just a topology discussion.
[08:54:38] <Bernard Aboba> Roni Even:  You prefer that middle box is smarter because you cannot depend on the endpoint.  I think that is the right way to go.
[08:56:07] <Bernard Aboba> Roni Even: If we say middle box is not trusted for what it will distribute then I understand why you are doing this.
[08:56:19] <Bernard Aboba> Paul:   You will get original SSRC value.
[08:56:55] <Bernard Aboba> Paul:  You still get original sequence number value.
[08:57:14] <Bernard Aboba> Paul:  How does endpoint react to that?  Does it use original value or modified one?
[08:58:26] <Bernard Aboba> Richard:  Summarizes tradeoffs.
[08:58:33] <Bernard Aboba> Cullen:  Some issues around collisions.
[08:59:15] <Lorenzo Miniero> hummm for relaxing
[08:59:16] <Simon Pietro Romano> hummmmm
[08:59:17] <Bernard Aboba> Richard;  If you are in favor of keeping requirement for immutability, please hum.
[08:59:25] <Simon Pietro Romano> ...relaxing
[08:59:30] <Bernard Aboba> If you are in favor or relaxing, please hum.
[08:59:40] <Bernard Aboba> We do not have consensus right now.
[08:59:53] <Bernard Aboba> Richard: We will take it to the list.
[08:59:56] <Maire Reavy> relaxing
[09:00:16] <Bernard Aboba> Cullen:  Emil should write a draft.
[09:00:44] <Bernard Aboba> Richard:  Emil, are you willing to do the work?
[09:00:57] <Bernard Aboba> Emil: Are you asking me to define PERC with SSRC mutablity?
[09:01:03] <Bernard Aboba> Richard:  What are the processing rules?
[09:01:39] <Bernard Aboba> Cullen:  All the things we need to put into various documents to make this work.
[09:01:52] Deb Cooley leaves the room
[09:02:51] <Bernard Aboba> Emil: I have addressed the security concerns.
[09:02:57] <Bernard Aboba> Richard: We need to wrap this up.
[09:03:19] <Bernard Aboba> Roni:  You have to do the same for SSRC as for sequence number.
[09:03:30] <Bernard Aboba> Colin:  Would be useful to produce a draft that lists the concerns.
[09:03:37] <Bernard Aboba> Richard:  Are you volunteering?
[09:03:39] <Bernard Aboba> Colin: No.
[09:04:30] <Bernard Aboba> Cullen presenting draft-ietf-perc-double
[09:05:35] <Bernard Aboba> We have a hand wavy part of the draft.  The mixer can insert some header extensions... but others we might not allow.
[09:06:23] <Sean Turner> please use mic :)
[09:06:23] <Bernard Aboba> Cullen:  Client will insert client-mixer level.  Do you want MDD to copy values.
[09:06:30] <Bernard Aboba> Jonathan:  It isn't mixing, so no.
[09:07:25] <Bernard Aboba> Jonathan:  MID is required for this to work.
[09:07:45] <Bernard Aboba> Cullen:  CVO does not make sense for middle box to change, coupled to original video.
[09:08:01] Randell Jesup joins the room
[09:08:49] Suhas Nandakumar leaves the room
[09:09:04] <Bernard Aboba> Clue Capture ID is in YES category
[09:09:11] <Bernard Aboba> Emil:  Abs-send-time
[09:09:34] <Bernard Aboba> Peter Thatcher:  Why do you need MID?
[09:10:06] <Bernard Aboba> Jonathan:  MIDs are chosen by the offerer.
[09:10:31] <Bernard Aboba> Peter:  congestion control stuff.
[09:11:05] Ben Campbell leaves the room
[09:11:06] Ben Campbell joins the room
[09:11:30] <Bernard Aboba> Jonathan:  No E2E confidentiality of header extensions.... because I designed that so badly.
[09:12:03] <Bernard Aboba> Cullen:  We can reconstruct the headers that the original person sent.
[09:12:37] <Bernard Aboba> Richrard: YES means mixer is allowed to change it.
[09:12:53] <Bernard Aboba> Harald:  Is there an extension for which there is a security concern?
[09:13:00] <Bernard Aboba> Cullen:  Didn't look like it to us....
[09:13:32] Ben Campbell leaves the room
[09:13:39] <Bernard Aboba> Roni:  Client-Mixer (Mixer needs to see it, but shouldn't change the value).
[09:13:51] <Bernard Aboba> Cullen:  Endpoint shouldn't be using it, so what is the problem?
[09:13:53] Ben Campbell joins the room
[09:15:07] <Bernard Aboba> Cullen:  Any other issues?
[09:15:36] <Bernard Aboba> Jonathan Lennox:  I think in Emil's architecture if you rewrite SSRCs, you will need to rewrite timestamps.
[09:15:50] <Bernard Aboba> Cullen:  Changes to this draft are minimal to support Emil's plan.
[09:16:43] sftcd joins the room
[09:16:49] Kathleen Moriarty joins the room
[09:17:28] <Bernard Aboba> Paul Jones, presenting draft-jones-perc-dtls-tunnel
[09:17:28] sftcd leaves the room
[09:17:30] Kathleen Moriarty leaves the room
[09:17:52] <Bernard Aboba> Paul:  Using DTLS presents NAT/FW traversal challenges.
[09:18:26] <Bernard Aboba> Paul: Current protocol coupled to messages changing in DTLS 1.3.
[09:18:41] <Bernard Aboba> Paul:  A TLS or WebRTC data channel could address the above concerns.
[09:21:33] <Bernard Aboba> Paul;  suboptions for data channels
[09:22:36] <Bernard Aboba> EKR:  Why are we not using the web?
[09:23:07] <Bernard Aboba> EKR:  You seem to be assuming that DTLS packets being tunneled are going over same channel as control info to MDD.  Why?
[09:25:09] <Bernard Aboba> Paul: Coupling DTLS/SRTP with control traffic.  There is convenience in that.
[09:25:30] <Bernard Aboba> EKR: You could use HTTP REST for the control channel.  Would make system much easier.
[09:29:52] <Bernard Aboba> Richard:  Not clear to me that passing transport messages via HTTP makes sense.
[09:31:13] <Bernard Aboba> EKR: Web services interface.
[09:31:54] <Bernard Aboba> EKR:  Messages 2 and 3, use REST.
[09:32:22] bergtau leaves the room: Disconnected: closed
[09:32:48] <Bernard Aboba> Cullen: Having two protocols could create issues when load balancing sends the protocols to different destinations.
[09:36:16] bergtau joins the room
[09:38:25] Yana Stamcheva joins the room
[09:39:29] <Bernard Aboba> Cullen on draft-ietf-perc-srtp-ekt-diet
[09:41:31] <Bernard Aboba> Cullen:  There are legacy EKT implementations... but not clear we have to worry about conflicting with them.
[09:43:05] <Jonathan Lennox> Me, off-mic: do you need a registry?
[09:43:40] Ben Campbell leaves the room
[09:43:41] Ben Campbell joins the room
[09:45:00] Lorenzo Miniero leaves the room
[09:45:03] Bernard Aboba leaves the room
[09:45:06] Maire Reavy leaves the room
[09:45:06] Nils Ohlmeier leaves the room
[09:45:39] Jonathan Lennox leaves the room
[09:46:00] Simon Pietro Romano leaves the room
[09:46:01] Randell Jesup leaves the room
[09:46:39] Yana Stamcheva leaves the room
[09:46:54] Sean Turner leaves the room
[09:47:20] Ben Campbell leaves the room
[09:47:51] Olle E. Johansson at IETF Berlin (GMT+1 DST) leaves the room
[09:48:22] Olle E. Johansson at IETF Berlin (GMT+1 DST) joins the room
[09:48:35] Olle E. Johansson at IETF Berlin (GMT+1 DST) leaves the room
[09:53:30] Olle E. Johansson at IETF Berlin (GMT+1 DST) joins the room
[09:56:20] bergtau leaves the room: Disconnected: closed
[09:56:37] Olle E. Johansson at IETF Berlin (GMT+1 DST) leaves the room
[09:57:22] George leaves the room
[10:01:14] George joins the room
[10:02:13] m&m leaves the room: Disconnected: closed
[10:02:17] Meetecho leaves the room
[10:06:49] George leaves the room
[10:20:02] George joins the room
[10:23:09] Olle E. Johansson at IETF Berlin (GMT+1 DST) joins the room
[10:23:54] m&m joins the room
[10:24:22] Ben Campbell joins the room
[10:25:38] George leaves the room
[10:27:38] George joins the room
[10:28:27] m&m leaves the room
[10:34:43] George joins the room
[10:36:08] Ben Campbell leaves the room
[10:38:15] George leaves the room
[11:27:49] Olle E. Johansson at IETF Berlin (GMT+1 DST) leaves the room
[11:46:11] George leaves the room
[11:53:51] George joins the room
[11:59:26] George leaves the room
[12:24:04] George joins the room
[12:29:38] George leaves the room
[12:39:19] George joins the room
[12:44:54] George leaves the room
[13:53:30] George joins the room
[14:53:54] George leaves the room
[15:13:23] George joins the room
[15:51:14] George leaves the room
[18:36:46] George joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!