IETF
rtcweb@jabber.ietf.org
Monday, May 19, 2014< ^ >
martin.thomson has set the subject to: RTCWEB WG http://tools.ietf.org/wg/rtcweb/agenda
Room Configuration
Room Occupants

GMT+0
[00:01:00] Neustradamus joins the room
[02:17:09] Ted joins the room
[11:16:41] Ted leaves the room
[11:20:40] jlcJohn joins the room
[11:31:10] Ted joins the room
[11:48:57] <Ted> Hi John
[12:10:22] <jlcJohn> Hi Ted -- I've been playing with Hangout, which I haven't used in ages...
[12:16:20] sean.turner@jabber.psg.com joins the room
[12:25:42] sean.turner@jabber.psg.com leaves the room
[12:25:50] sean.turner@jabber.psg.com joins the room
[12:27:14] hta joins the room
[12:28:25] spencerdawkins joins the room
[12:29:50] <hta> yes
[12:31:24] csp joins the room
[12:31:34] <jlcJohn> Has anybody succeeded in joining the Hangout?
[12:31:46] <csp> No - times out for me
[12:32:30] <hta> Let me see what I can do. Please type your google account emails here.
[12:32:47] <csp> I’m using csp@csperkins.org <mailto:csp@csperkins.org>
[12:32:50] coopdanger joins the room
[12:33:11] coopdanger leaves the room
[12:33:42] <jlcJohn> I think I'm scribe1John@gmail.com
[12:34:00] Cullen Jennings joins the room
[12:34:22] <csp> Harald: incoming call, accepted, then timout
[12:34:27] mary.h.barnes joins the room
[12:34:56] <jlcJohn> I'm in
[12:35:15] <mary.h.barnes> Is anyone else that's remote finding the audio to be quite low?
[12:35:45] burn joins the room
[12:35:53] <jlcJohn> audio fine here...
[12:36:23] <csp> I’m in – works on VPN but not native. Firewall problem I guess.
[12:36:33] <mary.h.barnes> Thanks ... I guess it's my setup.
[12:36:39] <hta> csp, I can't chat at you either (from my google account). is it  a Google Apps for your Domain or a google account with a non-google address?
[12:36:47] <hta> aha.
[12:37:00] jesup joins the room
[12:37:47] <csp> Harald: It’s a google account with a non-Google address. I’m in now. Looks like it was a firewall problem.
[12:38:36] <jlcJohn> Where are the slides?
[12:39:02] <Cullen Jennings> https://datatracker.ietf.org/secr/proceedings/interim-2014-rtcweb-1/rtcweb/
[12:39:27] <Cullen Jennings> oops sosry
[12:39:29] <Cullen Jennings> try http://www.ietf.org/proceedings/interim/2014/05/19/rtcweb/proceedings.html
[12:39:38] <Cullen Jennings> the first link was the chair link but second should work
[12:40:27] <Cullen Jennings> on that page, we are on the lsides at link "RTP Usage"
[12:41:52] rbarnes joins the room
[12:42:01] <rbarnes > why is there a chair on the stage?  is that for the victim later?
[12:44:04] <jesup> I don't think this is a major issue.  RTCP is expressed in a fraction, which can be limited.  Typically RTCP uses well less than the 5% in video calls
[12:44:19] <rbarnes > jesup: do you want someone to relay that to the mic?
[12:45:31] <csp> This seems like a straight-forward text clarification, rather than a major issue.
[12:45:39] <jesup> rbarnes : not necessary
[12:46:38] <csp> Any chance of turning the camera so we can see the slides?
[12:47:48] <Cullen Jennings> huh - -we thougth the slides would be on a seperate display area for you
[12:48:10] <spencerdawkins> I was wondering how close this was coming to saying things that should be true for pretty much RTP/RTCP usage. Thanks for asking, Cullen.
[12:50:39] <hta> CSP, click on the little image that says "Ted". That's the slides.
[12:51:46] <csp> The one that was off the left-hand side of the iPad screen :-) got it, thanks
[12:53:10] <csp> Hangout threw me out: “You can’t join the video call because the moderator has ejected you”
[12:53:43] <hta> Reminder: If you want to be invited, you must give an email address associated with a Google account. A random email address CANNOT be invited.
[12:53:48] <hta> csp, I'll re-invite.
[12:54:23] <csp> HTA: “an error occurred”
[12:54:35] <hta> I saw you briefly.... has your VPN fallen over?
[12:54:55] <csp> I’ll reconnect it, hang on
[12:55:07] <jesup> mic: More reports is better for congestion control (RMCAT, etc)
[12:55:44] <jesup> rbarnes? ^
[12:56:34] <jesup> I'm ok with MAY
[12:56:55] <csp> bac in
[12:57:31] <rbarnes > jesup: sorry, missed that.  we should get a scribe/relay designed here.  stand by
[12:58:17] <Cullen Jennings> @jesup - do you want me to go back and get your commetn in on reporting ?
[12:59:39] <rbarnes > ok, apparently i'm the designated relay for the time being :)
[13:01:22] <jesup> I don't think it's necessary given where things ended up
[13:01:46] <Cullen Jennings> thanks
[13:07:22] sean.turner@jabber.psg.com leaves the room: Replaced by new connection
[13:07:22] sean.turner@jabber.psg.com joins the room
[13:07:29] <hta> chatroom? 7 for, 4 against FEC as MTI
[13:09:25] <jesup> To the FEC voters: I'd suggest indicating why you'd be sad if it there's no FEC (not simply "I want FEC", but real-world use cases why you need it in 1.0) if you want more support
[13:09:40] <jesup> Cullen Jennings: ^ for when people talk about that offline
[13:10:49] <jesup> Right now, I'm not sure why I should care for example.  FEC eats BW...  Perhaps for really-long-delay but high-bandwidth links....  Or normal-but-have-bandwidth-to-burn links
[13:12:52] <csp> HTA: We already state that RTCP is a MUST
[13:13:27] <hta> @csp, I wanted to trigger cullen's comment. He's been making it recently.
[13:14:44] <jesup> mic: a 30 second media failure will likely cause the users to give up on the call anyways....  Some semi-non-interactive uses may resume
[13:17:57] <burn> laughter was (a cisco person) raising his hand
[13:18:00] <jesup> mic: certainly will look at implementing circuit breakers unless we have problems in practice, but it's really a bit of a backstop to notify us of failed calls
[13:19:52] <jesup> (not needed at mic) - I'm fine with this moving forward, "required" or not
[13:23:32] RONI joins the room
[13:23:56] <RONI> i have no luck joing the hangout
[13:24:04] <RONI> joining
[13:24:23] <RONI> so is dan romanscanu
[13:24:56] sean.turner@jabber.psg.com leaves the room: Replaced by new connection
[13:25:06] sean.turner@jabber.psg.com joins the room
[13:27:30] <hta> Dan is in, according to the hangout. Roni, what's your google account name?
[13:27:35] <hta> reinviting seems to help.
[13:28:14] <jesup> Cullen Jennings: most of the "control surface" is W3 level issue; for us it would just mean a "MUST" might get downgraded or given a caveat, I presume
[13:28:23] <rbarnes > jesup: mic?
[13:28:25] <csp> cullen: we intend to have that control surface for the browser; if that’s not clear, please propose clarifications. We also need the inverse though: if someone sends the browser something unexpected, the browser needs to be robust and ignore that unexpected data.
[13:28:32] <RONI> even.roni@gmail.com
[13:30:21] <RONI> ok i am in
[13:30:30] sean.turner@jabber.psg.com leaves the room: Replaced by new connection
[13:30:30] sean.turner@jabber.psg.com joins the room
[13:31:34] sean.turner@jabber.psg.com leaves the room
[13:32:04] <Cullen Jennings> @csp: +1
[13:32:16] <jesup> Perhaps "in order to provide roughly equal reporting intervals for AVP and AVPF"
[13:32:18] rbarnes leaves the room
[13:32:42] <csp> jesup: can you send email with suggested wording change?
[13:32:55] <jesup> csp: sure
[13:33:05] <csp> thanks
[13:33:26] <jesup> Wow, Harald is both remote AND there in person.  Impressive. ;-)
[13:34:26] Ted leaves the room
[13:34:57] chr1sw3ndt joins the room
[13:48:13] chr1sw3ndt leaves the room
[13:51:44] sean.turner@jabber.psg.com joins the room
[13:52:55] rbarnes joins the room
[13:58:08] <rbarnes > are the slides posted anywhere?
[13:59:13] <RONI> <http://www.ietf.org/proceedings/interim/2014/05/19/rtcweb/proceedings.html>
<http://www.ietf.org/proceedings/interim/2014/05/19/rtcweb/proceedings.html>
<http://www.ietf.org/proceedings/interim/2014/05/19/rtcweb/proceedings.html>
[14:01:18] <rbarnes > thanks
[14:04:12] <jesup> mic: Is this drop, or is this simply which gets sent?
[14:04:21] <rbarnes > jesup: ack
[14:04:29] <jesup> mic: first hop is FREQUENTLY congested in residential
[14:04:40] <jesup> or rather, first and last hops
[14:06:29] <jesup> mic: unlike a router, we do have control of the sender codecs (even if a bit delayed).  Congestion control should handle the congestion.  This is *when* packet A gets sent relative to packet B
[14:06:50] <jesup> mic: congestion control handles the rest
[14:06:58] <rbarnes > jesup: sorry, we've got mic congestion here :)
[14:07:07] <jesup> Figured.  :-)
[14:07:19] <rbarnes > is roman audible?
[14:07:30] <jesup> Letting you get it all done in one go.  yes he is
[14:12:48] <spencerdawkins> I'm agreeing that senders know more about what to do than anything else on the path, so being smarter based on what a sender knows is  better ...
[14:13:45] <rbarnes > yeah, to my naïve ears, this seems like something that's entirely up to the sender
[14:14:37] <jesup> Cullen Jennings:  Burn them in an atomic fire
[14:14:46] <spencerdawkins> I suggest we pause for a moment of silence :-)
[14:15:21] <jesup> I'm good with it
[14:17:40] <Cullen Jennings> SOme of them have a reall y great feature where you have have two DSL conneciton and it sends alternating packets (on same 5 tuple) on alternating DSL connectiongs
[14:17:59] <Cullen Jennings> which garetees that half your packets have totally differnt delay / jitter than the toher half
[14:18:10] <Cullen Jennings> and often half your packets arrive out of ourder
[14:21:03] chr1sw3ndt joins the room
[14:22:31] sean.turner@jabber.psg.com leaves the room
[14:25:12] <Cullen Jennings> slides are at http://www.ietf.org/proceedings/interim/2014/05/19/rtcweb/slides/slides-interim-2014-rtcweb-1-2.pdf
[14:25:16] sean.turner@jabber.psg.com joins the room
[14:26:55] <jesup> Magnus++
[14:28:43] sean.turner@jabber.psg.com leaves the room: Replaced by new connection
[14:28:43] sean.turner@jabber.psg.com joins the room
[14:29:13] <jesup> mic: we have priority within individual DataChannels on the association.  If you want further distinction, use Magnus's solution.  Given the control flow (split media types vs combined) I think this is sufficient
[14:30:31] <rbarnes > jesup: ack
[14:32:24] <rbarnes > m=filetransfer
[14:36:34] <spencerdawkins> So, just trying to keep up here. Do you still need multiple DSCPs on a single 5-tuple? :D
[14:36:52] <rbarnes > spencer: that's actually a good question
[14:36:58] <rbarnes > if not, we can cancel DART :D
[14:41:48] <Cullen Jennings> yes - still need multiple DSCP on same 5 tuple
[14:47:08] <rbarnes > http://tools.ietf.org/html/rfc3093
[14:50:35] <burn> this is spencer dawkins speaking
[14:56:10] csp leaves the room
[14:58:29] <spencerdawkins> Cullen - thanks for the feedback!
[14:59:38] RONI leaves the room
[15:11:14] rbarnes leaves the room
[15:12:02] dcrocker joins the room
[15:14:36] rbarnes joins the room
[15:31:00] <sean.turner@jabber.psg.com> yeah we're kind of being slack wrt saying names before hand: it's been justin/martin/ekr/cullen mostly
[16:26:50] <jesup> mic: Per magnus, for audio-only Opus variable bitrate (music, etc) we may want to use RR/RS bandwidths, for example.  As for defaults: the resolution can change during the stream....  b=AS may be used for hardware codecs that can't handle bandwidths higher than XXX
[16:28:08] <jesup> rbarnes : ^
[16:29:27] <jesup> Cullen Jennings: ^ if rbarnes isn't in line for mic
[16:30:13] <rbarnes > jesup: ack
[16:30:55] <jesup> thanks
[16:31:16] <jesup> The hardware codec is a good reason to generate b= in a browser
[16:31:30] Cullen Jennings leaves the room
[16:31:30] <jesup> (doesn't need to go to mic)
[16:32:07] <jesup> mic: I think we may want to send it if we have a hardware codec limit
[16:32:28] <rbarnes > jesup: ack
[16:32:31] <jesup> thx
[16:33:05] Cullen Jennings joins the room
[16:33:05] <jesup> mic: yes
[16:33:05] Cullen Jennings leaves the room
[16:33:33] <jesup> mic: yes I do know a codec that is bandwidth limited to ~700Kbps
[16:34:29] <rbarnes > jesup: just shouted it, without the mic :)
[16:34:48] <jesup> thanks.
[16:38:15] rbarnes leaves the room
[17:11:20] rbarnes joins the room
[17:13:47] alfredh@jabber.org joins the room
[17:24:48] rbarnes leaves the room
[17:25:19] rbarnes joins the room
[17:32:31] rbarnes leaves the room
[17:33:17] <jlcJohn> "There is a problem connecting to this video call" isn't the most helpful message...
[17:36:44] alfredh@jabber.org leaves the room
[17:38:28] <dcrocker> yup
[17:41:47] <jlcJohn> We know lunch started late; so we kinda expect it to run late-- but we don't know how much...
[18:00:22] chr1sw3ndt leaves the room
[18:02:17] chr1sw3ndt joins the room
[18:08:02] <dcrocker> Is there an estimate of when the session will start?
[18:10:16] alfredh@jabber.org joins the room
[18:30:22] <hta> @dave it started on time
[18:33:02] <jlcJohn> HTA, I take it that means we don't need to look for it in the Hangout?
[18:33:36] <hta> jlc, talk to ted. It's a NEW hangout. I'm on stage...
[18:51:32] <dcrocker> I clicked the url provided for the afternoon session.  it didn't work.
[18:51:52] <dcrocker> apparently meeting managers aren't monitoring the jabber session???
[18:52:35] <dcrocker> the provided url still does not work.
[19:06:27] <mary.h.barnes> Are you using the same email address to which the invite was sent?  AFAICT, you must be logged into the gmail acct to which the invite was sent and click the link within that email.
[19:09:22] <dcrocker> yeah.  i went through that bit of discovery earlier today.
[19:16:58] <dcrocker> so, while i did switch to the correct login for the earlier session, somehow my browser switched me back to a different account.  having change to the proper login, the original url now seems to work.  of course, there is nothing displayed by google that showed what login it thought i was trying to use.../
[19:31:15] chr1sw3ndt leaves the room
[19:40:24] sean.turner@jabber.psg.com leaves the room
[19:46:46] chr1sw3ndt joins the room
[19:50:46] alfredh@jabber.org leaves the room
[20:04:41] mary.h.barnes leaves the room
[20:06:29] chr1sw3ndt leaves the room
[20:45:54] Ted joins the room
[20:46:10] Ted leaves the room
[21:15:40] dcrocker leaves the room
[21:30:44] burn leaves the room
[21:37:03] hta leaves the room
[21:59:21] spencerdawkins leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!