[21:37:50] jkhii joins the room [22:04:08] billvs joins the room [22:09:05] suzukisn joins the room [22:09:09] suzukisn leaves the room [22:11:04] JonathanLennox joins the room [22:11:59] Ali C. Begen joins the room [22:12:45] I will relay Jabber questions if anyone's remote (is anyone?) [22:13:30] Cullen Jennings joins the room [22:13:35] csp joins the room [22:14:02] Colin: I am jabber relay today [22:14:34] okay - thanks! [22:15:09] as0-d91k joins the room [22:18:02] Wolfgang Beck joins the room [22:18:09] Let me know if you need me to track the slides currently being presented [22:19:11] Haibin Song joins the room [22:20:30] tony joins the room [22:25:52] just marking this point in time for the funny Robert rant on driving school [22:29:41] fwiw, for port mapping we need a keep-alive method and muxing would be the preferred one [22:30:26] Don't we already have consensus on mux for port mapping anyway? [22:31:01] suzukisn joins the room [22:31:03] we had it in the breakout session and yesterday's session but I believe the co-chairs will ask the list, too [22:31:12] I am all for it. [22:31:24] Right, of course. So this could provide additional evidence for the list consensus call [22:31:44] agree [22:32:15] Is RTCP not its own keepalive? [22:32:59] Prescient jabber relay! [22:33:15] (I.e. I sat down from the mic to say that and saw your comment) [22:33:19] what is the worst case rtcp reporting delay? [22:33:21] DWING-WXP0DB1C9E5F joins the room [22:34:17] Hmmm... you may need to keep-alive in both directions? Maybe. Worth thinking about. [22:34:55] if muxing is enabled, no need to worry about this, right? [22:35:31] It *might* still be an issue if you have unidirectional RTP and RTCP, with the return on a different path. [22:35:32] If there's a case where RTCP won't do keepalive in some direction, then it won't do it for the MUX case either...I haven't read Magnus's comment yet to understnd it [22:35:59] This is comment 6? [22:36:12] Yes [22:38:58] If we're using rtp-mux, then the RTCP interval should be used, surely? [22:39:59] i.e. if we agree that muxing is the right solution, then this issue goes away [22:41:47] You heard Roni's answer, yes? [22:43:07] Right - I think he missed the point. If we decide that rtp-mux is the right solution, then the entire paragraph suggesting 15 seconds can be removed, not just word-smithed. [22:45:42] Haibin Song leaves the room: Computer went to sleep [22:46:37] Wolfgang Beck leaves the room [22:47:38] wolfgang.beck01 joins the room [22:50:07] Not all codecs send comfort noise, right? Surely this bullet is just about such codecs. [22:50:41] (i.e. what Stephan just said) [22:58:25] when a receiver starts receiving a new SSRC, I believe it will eventually time ot on the previous one and flush the existing data, right? [22:58:42] Yes, unless you send RTCP for the old SSRC to keep it alive. [22:58:52] so the receive should probably know beforehand that multiple SSRCs could be sent [22:59:35] even if you send RTCP to keep it alive, I think the receiver should know what is going on, no? [23:00:07] A receiver is supposed to deal with this, since it's standard RTP. I agree that many implementations can't cope with it though. [23:00:20] :) good point [23:02:01] I've certainly heard rumors of RTP receivers which lock on to a single SSRC and forever discard any other SSRC on the session. I'm not sure I've seen one in the wild, though. [23:03:02] I support this becoming a WG draft. It's not critical to solve immediately, but is an issue that's been ongoing for some time, and does need to be resolved. [23:03:24] colin, want me to read that at mic [23:03:46] too late now - and Roni said something similar anyway. [23:03:48] too late , on my part : sorry [23:03:59] no problem [23:04:20] Roni had already closed the discussion when I saw Colin's comments [23:05:07] This is retransmission-supression? [23:05:13] Proxy RAMS [23:05:36] thx [23:06:50] Not sure what happened to retransmission-suppression [23:07:43] DWING-WXP0DB1C9E5F leaves the room [23:10:57] Architecturally, I’m unconvinced this is a good idea - I suspect there are some significant security issues that arise unless the end systems are upgraded to explicitly include the middlebox in the signalling exchange and security context, but much of the rationale is that this is supposed to work with legacy end systems. [23:11:28] if they will need to be updated, just upgrade them to RAMS. [23:11:41] why bother with this anyway? [23:12:03] thx Cullen [23:12:41] Mentally, reading jabber is about the most I can do by this point in the week :-) [23:12:50] Cullen Jennings leaves the room [23:13:00] :-) And thanks Jonathan too! [23:13:02] Ali C. Begen leaves the room [23:13:16] billvs leaves the room [23:13:38] jkhii leaves the room [23:14:34] csp leaves the room [23:15:23] as0-d91k leaves the room [23:16:09] JonathanLennox leaves the room [23:18:45] suzukisn leaves the room [23:27:01] tony leaves the room [23:31:13] wolfgang.beck01 leaves the room