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.
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
