IETF
avtext@jabber.ietf.org
Wednesday, November 12, 2014< ^ >
Jonathan Lennox has set the subject to: AVTExt working group
Room Configuration
Room Occupants

GMT+0
[00:49:46] csp joins the room
[01:13:38] Jonathan Lennox joins the room
[01:16:57] Parthasarathi Ravindran joins the room
[01:17:36] csp leaves the room
[01:17:50] Emil Ivov joins the room
[01:20:41] Meetecho joins the room
[01:21:21] Parthasarathi Ravindran leaves the room
[01:23:33] <Emil Ivov> Thanks Harald :)
[01:24:59] hta joins the room
[01:25:40] <hta> Good <appropriate timezone-dependent time of day>. I will be your jabber scribe today.
[01:25:52] <hta> Please prefix all comments intended for the mike with MIC:
[01:25:59] <hta> s/scribe/relay/
[01:26:13] csp joins the room
[01:28:32] <csp> I came in late: I’ve read splicing before, and can read it again if it’s useful
[01:29:30] <csp> ok
[01:29:57] Parthasarathi Ravindran joins the room
[01:32:20] <Emil Ivov> Looks good!
[01:39:06] <Emil Ivov> mic: did we decide if we are implementing ACKs for unsolicited PAUSE messages?
[01:40:31] Mary Barnes joins the room
[01:43:24] Mary Barnes leaves the room
[01:45:08] <Emil Ivov> mic: did we decide if we are implementing ACKs for unsolicited PAUSE messages?
[01:45:20] <Emil Ivov> argh
[01:45:20] Parthasarathi Ravindran leaves the room
[01:45:53] <Jonathan Lennox> Emil: I assume this was not actually for the mic?
[01:46:16] <Emil Ivov> mic: TMMBRs have ACKs (implicit) so +1 for ACKs with an existing message.
[01:48:00] hta thinks you're in the rough, Emil
[01:48:59] hta would call TMMBR/TMMBN a request/decision, not a negotiation....
[01:49:22] <Emil Ivov> mic: no objection to not adding ACKs then
[01:51:03] <csp> +1 to Stephan
[01:53:52] <Emil Ivov> mic: one reason to recommend that in text is because implementors would not necessarily have all the use cases in mind
[01:54:15] <Emil Ivov> mic: it wasn't immediately obviously to the authors either
[01:54:39] <csp> Why not retransmit every RTCP interval?
[01:55:07] <Emil Ivov> because it is important to get this one as quickly as possible
[01:55:10] <Emil Ivov> otherwise it is pointless
[01:55:24] <csp> AVPF allows this, no?
[01:56:26] <Emil Ivov> csp: AVPF allows what, sorry?
[01:56:52] <csp> AVPF allows to be sent rapidly initially, then send each interval thereafter
[01:56:59] hta is assuming that comments without mic: are just Emil and Colin discussing between themselves.
[01:57:43] <Emil Ivov> csp: my point is that if the second transmission is 5 seconds later then there's no point.
[01:57:47] <Emil Ivov> hta: yes, not for mic
[01:58:40] <csp> emil: so, tune the reporting interval down. you have the hooks to do this in RTCP already, especially with AVPF and T_rr_interval
[01:59:28] <Emil Ivov> csp: sure. I am not asking for a new mechanism. I am just asking for the text to tell implementors this needs to happen (and potentially why)
[02:00:04] <csp> sure, no objection to some guidelines around that.
[02:10:45] <hta> Meeting over.
[02:10:46] <Emil Ivov> hta: thanks very much for relaying!
[02:10:53] <csp> thanks all
[02:10:58] Jonathan Lennox leaves the room
[02:11:31] csp leaves the room
[02:11:49] John Doe joins the room
[02:11:56] hta leaves the room
[02:12:12] Meetecho leaves the room
[02:12:16] John Doe leaves the room
[02:56:07] hta joins the room
[03:05:57] hta leaves the room
[03:32:04] Emil Ivov leaves the room
[03:57:46] Jonathan Lennox joins the room
[04:11:45] Jonathan Lennox leaves the room
[07:27:55] hta joins the room
[07:28:16] hta leaves the room