[12:07:04] --- csp has joined [12:07:50] --- csp has left [12:08:02] --- csp has joined [12:16:04] --- csp has left [12:16:04] --- suzukisn has joined [12:16:09] --- csp has joined [12:16:12] --- suzukisn has left [12:16:39] --- TomTaylor has joined [12:16:56] --- jesup has joined [12:17:17] Hi Colin, Tom [12:17:22] Hi [12:17:33] Roni is summarizing the sstatus for DTLS-SRTP [12:17:41] --- alfredh has joined [12:17:45] Audio is working well here [12:18:02] no problems here (20 miles away) [12:18:21] Dan Wing on DTLS-SRTP [12:18:28] Key Transport [12:18:37] Overview chart [12:19:22] Next chart - GDOI-SRTP ... [12:19:42] Sorry I missed meeting Dan on Tuesday (not sure he was there) [12:19:54] Don't recall [12:20:38] Chart: changes in -01 [12:20:57] ... first scenario chart [12:21:14] pt-multipoint [12:21:38] next chart: with video switching [12:22:30] nex: new multicast scenario [12:22:53] next new scenario: voicemail storaGE AND RETRIEVAL [12:23:32] VM device stores both the audio and the associated key [12:23:55] --- suzukisn has joined [12:24:04] Dave Oran says fundamentally useless [12:24:44] --- ysuzuki has joined [12:25:14] SPEECHSC worked through this. Scenario is not realistic [12:25:57] Conclusion -- interest? [12:26:36] --- magnus has joined [12:26:53] Roni to the mike: summarizing interesting points [12:29:58] Eric Rescorla: question of whether this can be extended to DTLS, TLS. Discussion -- sorry my ears didn't sort it out [12:30:14] Magnus: why SRTP not mandatory [12:30:25] The issue [12:31:23] Wide variety of deployment situations/environments [12:31:34] Eric and Dan were discussing using an EKT-type keying mechanism, among other things [12:32:01] Next slide: why this document [12:33:15] Next slide: status and open issues [12:34:15] --- Lars has joined [12:34:34] Half a dozen or so people have read document [12:34:48] For the previous discussion, re: voicemail, if message playback is done on the encrypted packets you have a problem because the sequence numbers/etc should change; you may not be able to simply replay encrypted packets in the more complex uses. The VM server *could* decrypt and then re-encrypt to send to reader [12:35:43] At least pointers to the best practices, etc would be good [12:35:52] Security AD comments -- Roni explaining further scope [12:37:13] AD: Should be saying: Here's how how an RTP system can upgrade itself to SRTP. To him that is negotiation [12:37:29] Roni and Magnus respond [12:38:11] Dave Oran: two different topics, how to do SRTP is a second document [12:38:22] Agree with Dave Oran's first poin [12:38:23] t [12:39:14] While Dave speaks, Hannes comes to mike [12:39:15] Good comment [12:41:27] Hannes: concerned: how many "How to" books are going to be written? [12:41:54] Stephan in line behind Hannes [12:42:12] --- petithug has joined [12:42:42] Discussing "Why not SRTP" -- Magnus currently speaking, [12:42:44] Hannes: are you suggesting we should write "when to use SRTP" rather than "why SRTP not mandatory"? [12:43:23] Stephan Wenger: as he read it, this doc is addressed to security people. Message is needed. [12:43:58] Roni: do people see this as a WG item? [12:44:18] Many hands in favour, no objections [12:44:31] yes here too [12:44:35] :-) [12:44:37] and here :-) [12:44:46] Joerg Ott coming up. [12:45:00] RTCP guidelines [12:46:03] First pass [12:46:07] Good idea to try to capture them [12:46:23] Chart: Why RTCP guidelines? [12:47:26] Tom: if I have a comment I'd like you to pass on to the room, i'll prefix with "Comment:" [12:48:18] Chart: RTCP capabilities [12:48:30] OK Randell [12:49:35] Next chart feedback loop [12:50:33] Comment: codec choices should be via negotiation or switching negotiated payload types [12:50:53] whenever makes sense, pass it along [12:51:40] Right, I don't see how rtcp is used in choosing codecs (you don't need to forward this) [12:51:44] Next chart limitations [12:52:05] Negotiate as many codecs as possible, then switch between them freely based on RTCP feedback [12:52:14] For faster typing, can just prefix with ccc [12:52:29] Aha, *based* on. Now I understand what he meant by that. [12:52:39] ok [12:52:46] --- ldondeti has joined [12:53:14] Also in reality we are getting more codecs that actually variate rate and packetization within the same payload type. [12:53:22] On RTCP guidelines. Done the security stuff [12:53:38] Right, rtcp feedback used as input to algorithm [12:53:40] Chart: questions [12:54:20] been there, done that... :-) [12:55:03] Lots of fun issues there, huh? :-) [12:55:46] Dave O: can you carry RTP in same tfc class as RTCP [12:56:02] Stephan in line behind [12:56:27] Ccc: with rtp-rtcp-mux, it's even more likely they'll be in the same class (not guaranteed) [12:56:42] don't need to forward that [12:56:49] --- ldondeti has left [12:57:03] thanks [12:57:32] Chart: general guidelines [12:58:02] Agreed, not guaranteed (even if you do mark them the same when you send them; intermediate nodes may remark them) [12:58:55] Witness RTCP-XR from tuesday.... :-( [12:59:24] Next chart: where to go [13:00:01] Roni: who read? 8 or so [13:00:20] Roni remarks on questions on list re timing and synch [13:00:27] Should [13:00:28] Ccc: we recommend that people not make a protocol/application depend on *ever* getting their RTCP packets through to the other end [13:00:44] Stephan [13:01:05] ... would split if he were author [13:01:35] One target those who really need to learn about RTp [13:01:56] had to step away - did that comment get through? [13:01:57] Second: when and how appropriate to use RTCP [13:02:12] Not yet -- still dealing with S's [13:02:16] thanks [13:02:32] jesup: it's in my notes [13:02:34] --- cabo has joined [13:03:03] Joerg: [13:03:11] Agreed [13:03:28] Johansson [13:04:16] As a serious hack, I once (temporarily) stuck rtcp into a header extension [13:04:19] --- Lars has left [13:04:22] Need discussion on when useful to do extensions [13:04:40] Final presentation: SEED [13:04:46] Magnus/Joerg: thanks for presenting! [13:05:04] First chart: review [13:05:14] I hade to some work for this document. [13:05:26] Changes since -00 [13:05:54] Changes cont'd [13:06:02] Next step [13:06:18] Eric Rescorla [13:06:34] Asking if theyt considered adding counter mode as well [13:06:43] galois counter mode [13:06:57] csp: I think you may find my list comments on 3984bis of interest. Big can of worms. [13:07:04] Good question... :-) [13:07:15] Because they had seed... [13:08:13] --- petithug has left [13:08:14] jesup: yep... still digesting them. Not simple. [13:08:56] Hannes approaching the mike [13:09:33] Roni summarizes: want to see logic for selecting crypto suite [13:09:56] Windup -- Roni -- -30- [13:10:44] --- TomTaylor has left [13:11:16] --- suzukisn has left [13:12:06] stepped away, back now [13:12:13] looks like it's over [13:15:23] csp: yeah. I chatted with Roni until he had to leave on Tuesday. SOunds like the big conferencing people generally don't like/implement sprop-parameter-sets, and don't like/implement (sometimes) packetization-mode 1 [13:15:39] --- Dan York has joined [13:16:04] He more-or-less said, if you want to interoperate, use mode 0, and use in-media parameter sets [13:19:16] Thanks Tom [13:19:22] --- ysuzuki has left [13:20:49] Oh, tom's already gone. See you all on the list, I guess. I may even stick my toe into the whole SVC mess, and watch Thomas and Stephen bite it off while fighting with each other. ;-) [13:26:15] --- Dan York has left: Computer went to sleep [13:28:47] I'm going to drop off, since I'll be looking at other screens and testing real code. (Been too long...) Thanks all. [13:32:07] --- magnus has left [13:33:45] --- csp has left [13:48:20] --- jesup has left [14:00:08] --- cabo has left [14:03:06] --- Dan York has joined [14:07:22] --- cabo has joined [14:08:45] --- cabo has left [14:12:13] --- Dan York has left [14:13:56] --- alfredh has left