Again, we have tested delay. It matters a lot. As long as you only want to observe, it's not much of a problem. If you want to participate, it's a big problem.
Another thing we know is that engineers think it doesn't matter as much as it does. This is a well observed phenomenon. Its why there are SO many bad systems around, not being used very much. You will find in many cases that a videoconference is run with the audio system shut off, and a regular PSTN conference bridge used instead: the lack of lip sync is not as bad as the delay of normal videoconference system's audio subsystem, and its delay is not inherent in the audio processing, it's deliberately delaying the audio to match the video. While there is no inherent reason we can't get VoIP to work, the practicalities are pretty impressive, even Cisco can't get it to work well in WebEx. This is more of a network engineering issue than a VoIP mechanism problem. On a well engineered IP network, VoIP works better than PSTN. The Internet, not being particularly well engineered in the large for the things that VoIP cares about, is problematic. My main office phone is VoIP from my home office to our PBX. I have the best Internet package my cable company offers for residential use. It works well most of the time, but definitely not anywhere near as reliable as the PSTN. YMMV. I do wonder why WebEx doesn't have a SIP AoR available to connect to: VoIP to them means PC audio system. It's easier to get a good VoIP experience on a VoIP phone than on a PC. The PC has the advantage that most clients have wideband codecs, which is a good thing. If all you want is one way, VoIP is okay. When you need two way, it's hard. We do have some advantages that may make it more likely to work: we have lots of bandwidth at our end, as well as very well engineered paths into the Tier 1 networks. That's half of the problem. The other half is not so easily fixed. The usual way systems overcome network problems is more buffering. Buffering causes delay, and we're back to the big problem. We should strive to support VoIP, but we cannot rely on it. Brian > -----Original Message----- > From: vmeet-boun...@ietf.org [mailto:vmeet-boun...@ietf.org] On Behalf > Of Dave CROCKER > Sent: Thursday, May 14, 2009 1:43 PM > To: John Leslie > Cc: dcroc...@bbiw.net; vmeet@ietf.org > Subject: Re: [vmeet] Supporting interim meetings > > > > John Leslie wrote: > > 1) Right now, a phone bridge is essentially state-of-the-art for > > audio. Most everything else flunks Brian's 150 msec test. > > This raises two different questions: > > 1. Is passing that test really mandatory? > > 2. Is it true that no VOIP capabilities pass it today? > > I suspect the issue here is going to be about statistics. How often is > there a > (serious) problem, not whether there is one. People can be pretty > adaptable, > and cell phone have taught us all to be particularly forgiving of poor > voice > channel characteristics. There are limits, but they are not > necessarily as > strict as the discussion on this list seems to suggest. > > > > 2) Advance availability of charts is egregiously poorly enforced. > > Where it is enforced it leads to charts which only exist in the > > presenter's imagination. Preparation of slides is the best exercise > > for most presenters to organize their thoughts -- and, alas, the > > last minute is when it, almost by definition, happens. > > > 3) Best Practices simply don't get followed, unless somebody is > > constantly nagging. > > On both of these point, we should note that the community does, in > fact, follow > certain rigid requirements. I-D submissions deadlines, meeting > registration > deadlines, etc. When a requirement is enforced, we conform. We are > sloppy > about enforcement only when the requirement isn't rigid. When the > consequences > of non-conformance are clear and firm, we tend to conform quite > readily. > > > >>> I think we could get away with a relatively modest initial > >>> requirement. Say, 30 people? That will limit applicability for > the > >>> larger and more active working groups. > >> ... > >> > >> Careful about predicting future participation based on the past, > >> especially if travel issues are now motivating more to stay at home. > > This is certainly an important point, but it's the best we have to base > our > estimate on, now. > > > > Agreed; but it's a reasonable starting point... > > > >>> 1. Meeting management - > >>> a) Ability to queue up participants, as if at a microphone > >>> For meetings of a group that can easily be 20-40 people, > >>> with relatively little history of group collaboration, the job of > >>> meeting management is vastly easier when there is some functional > >>> help for coordinating who wants to speak next. > >> It may also be necessary for basic fairness. Folk can get mighty > >> unhappy if it seems to them that they are being treated as second > >> class citizens in the microphone queue relative to others. > > > > I regard this as very important; but I'm not happy with any > > automated functions I've seen in a telepresence package. A simple > > plaintext list of folks who have asked to speak (and not given up > > their place or spoken) is what all participants should have. > > I don't understand what you are specifying. How would it work and how > would > that be easy to use? > > > > I consider this important enough that someone should have the role > > of maintaining it if we can't get it automated. > > Again, in terms of broad-based, on-going use I believe we cannot settle > for hack > solutions. Let's be careful that we do not do the online equivalent of > requiring each speaker bring their own public address megaphone. > > The more manual the mechanism, the more hassle will be its use. To get > work done > on the scale we are seeking, we cannot have the tools impose hassle, > IMO. And > just because one or another of us is willing to put up with that hassle > does not > make it reasonable to impose on everyone else. > > > >>> b) Ability to shift who is presenting > >> While I agree this is necessary, I am not sure that we require tools > >> to support this. Charts in advance work pretty well in practice. But > >> not at the expense of limiting participation if the bandwidth > >> requirements are too high. > > > > It is a weakness of many of the available tools that they expect > > every participant to have the same available bandwidth. This simply > > isn't the world we live in. Anyone without sufficient bandwidth to > > support a real-time display should be able to turn that bandwidth > > demand off. > > > > As a general rule, we shouldn't be designing for the lowest > > (bandwidth) common denominator. > > The lowest common denominator is 9.6kbps, or worse. We aren't > designing for that. > > But a rule of egalitarian access is that is pushes for a norm that is > considerably below what is available to some. > > > >>> 3. Shared slide presentation > >>> Shipping powerpoint files around is tolerable only for special > >>> cases, I believe. > >> I disagree. I think shipping charts around in advance has benefits > >> too. > > > > When they actually _get_ shipped, I agree. > > > >> Doing everythig at the very last second (especially for a meeting > >> that is schedule far out in advance) does not necessarily result in > >> good meetings and/or good presentations. And it can actually be > quite > >> useful to skim a presentation in advance before a talk begins. > > > > But last-minute changes, even changes _during_ the presentation > > are the nature of the beast. I agree with Dave. > > There was some push-back about the suggestion for including a white- > board > function. > > I have certainly been in meetings where text was created > collaboratively and in > real-time. Charter-bashing is perhaps the most common example. > > Whether that is through a "shared whiteboard" or simple broadcast > powerpoint > revisions is secondary, IMO. But we need to be able to have materials > changeable in realtime through collaborative efforts. > > > > My own concerns: > > > > 1) Participants need to figure out who's speaking. There are many > ways > > to help them, but it deserves to be high among our concerns. > > Good point. Yes. > > > > 2) Snapshots of slides and/or whiteboards can help keep folks on the > > same page. Things change during meetings, and it's very easy for > > human memories to diverge. > > I'm not clear what capability you are suggesting, beyond what's already > been listed. > > > > 3) There really should be a "record" of a meeting. This is, > admittedly, > > an art form; but folks don't want to listen to an audio recording > > or even read a transcript of every word spoken. It very likely > would > > be helpful if such a record could be visible in real-time to some > > participants. (I don't claim to be particularly good at doing > this, > > but there _are_ folks who are good at it.) > > We currently have a jabber transcript, with a scribe, and a separate > note taker. > Are you suggesting something beyond these? > > > > 4) Every meeting should create "action items" that someone is > responsible > > for following-up on. (Some are group items; some private.) These > > deserve far more visibility than they usually get. > > What sort of tool is involved in this, different from what is already > in use? > > > > 5) Separate applications is very likely better than one integrated > > application. Webex drives me crazy by taking over organization of > > the screen. I don't want anything else interacting with my Jabber > > application. > > Interesting point. The tradeoff is that tools that aren't integrated > each > require separate registration and management. > > > > 6) VoIP-as-we-know-it doesn't meld well with POTS conferencing. Until > > VoIP can have consistent delay -- ideally Brian's 150 msec, but > > definitely under 500 msec -- we'll probably have to do without it. > > The lengthy discussion about these details was facinating, but too many > people > have had entirely too many, acceptable experiences with group > conversations that > were a mix of telephone and voip. > > > > 7) Learning curve is way too high for most telepresence packages. > > Folks simply _won't_ learn how to use them effectively. Formal > > Concern about the learning curve is certainly warranted. However we > need to be > careful about firm, pre-hoc assertions of what is and is not acceptable > in terms > of what the human factors folk call usability. > > > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > 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
