On Fri, Mar 30, 2012 at 8:48 AM, Dave Cridland <d...@cridland.net> wrote: > On Fri Mar 30 14:01:52 2012, Yoav Nir wrote: >> >> I disagree that providing service to people connecting from PSTN or >> through a gateway from the "wrong" software (like Skype) needs have any >> effect on the service provided for the other remote participants. People >> might be excluded because they are behind a corporate firewall or because >> the particular solution we chose does not run on their favorite distribution >> of Linux or z/OS. >> >> > People can be excluded for a multitude of reasons. Arranging to have > working connectivity for the period of a meeting is far from an onerous > problem, in my opinion (as a remote participant), so I'd be fine with not > requiring PSTN connectivity. I'd also note that "pure" PSTN conferences I've > had have always been a disaster, anyway, with buzzing handsets and poor > audio quality. > > On the other hand, if the solution won't run on Linux purely because it's > some non-standard gloop, I *will* be very annoyed. We've currently at least > two standards-track protocols capable of negotiating an RTP stream, we > should be using them. > > > >> I also disagree with Brian's claim that 150ms is a limit for the kind of >> discussion that takes place in IETF working groups. It does apply to phone >> calls, but WG discussion tends not to be interrupt-driven. People politely >> wait their turn at the mike, with the chairs signaling the use of the >> "floor". Not having the ability to connect from work (when the IETF is in a >> suitable time zone) means having to take the day off or relying on cellular >> internet that seems to have higher latency anyways. > > > I think we can go higher than 150ms - my unsubstantiated guess would be as > high as 500ms - for the reasons you give, but there are frequent > conversations between the person at the mike and the person leading the > session (the draft presenter, chairman, whatever). Sometimes even > conversations between two people at the mike. > > The high bandwidth, low latency conversations are the only real reason to > have IETF meetings at all, so I think it's worth preserving. > > As I say, the somewhat formalized nature of these does allow for a higher > latency than would be need for natural conversation, but not *much* higher - > and I can tell you how frustrating it is to be a remote participant, and be > unable to engage in even slightly real-time conversations. > > As an example, in the xmppwg meeting on Wednesday, I was still listening to > Peter Saint-Andre voicing my words when I was reading on the chatroom Joe > Hildebrand's summarized response. After thirty more seconds, I could hear > the response. Peter had, by the time, left the mike, so my chance for a > counter-response was entirely lost, and in any case, the discussion had > moved on in the room already - I had actually lost my chance for a > reasonable counter-response by the time I heard Joe's voice. > > The number of times one hears "I think this is in relation to..." when > referring the the channelled comments from remote participants is quite > astonishing. It's even worse when the comments are assumed to be in response > to something the commenter hadn't even heard when they wrote the comment. > > If there's a single practical goal from vmeet, reducing the outbound audio > latency to a reasonable level should be it. > > Everything else, I can deal with, albeit through rough mechanical > labour-intensive ways - but these are ways that fundamentally work to > achieve the higher level goal. > > I don't (really) care (too much) that my comments are read out in an > American monotone (Peter didn't do a monotone, though he pointedly refused > to do a British accent). I don't care that I need to download slides and be > told what page we're on via XMPP. I'm entirely cool that the slides, the > chatroom, and the audio feed all run through wildly different systems. > > But I do care - hugely - that my comments can get there in a timely manner, > and help shape the conversation. That latter - shaping the conversation - is > the ultimate goal. >
I have carried my laptop up to the mike when channeling people precisely so that there could be some amount of interaction when their question was asked. This is pretty cumbersome and could certainly be improved by technology. Regards Marshall > Dave. > -- > Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html. > https://www.ietf.org/mailman/listinfo/vmeet _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
