On 04/14/2017 05:11 PM, Dave Crocker wrote: > On 4/14/2017 9:04 AM, Fernando Gont wrote: >> FWIW, for the developing world, remote participation has possibly always >> been a necessity. > > > Indeed. I hadn't understood how extensive this had become until seeing: > > https://tools.ietf.org/html/draft-elkins-ietf-remote-hubs-00#section-3 I haven't checked the I-D. However, no matter what it says, there's remote participation with meet echo, without hubs. For instance, I participated (and presented) remotely in two wgs during the Chicago IETF, without "attending" any hub. > However, there is a significant difference between their current mode of > integration with the 'main' venue site, versus what we will need to have > remote sites able to have nearly seamless participation in sessions. What I tried to note is that the situation for part of the participants is such that remote participation is already necessary. >From the pov of participants of North America or Europe, this *might* be different and the current situation might be a game changer. But for us in latin maerica, remote participation has always been a need, even if we managed to attend one or more meetings (that's kind of like "the exception to the rule"). > Some of this is functional, such as a single queue for everyone wanting > to speak, no matter where they are. Agreed. > Some of this is much more robust > performance and reliability (within obvious networking limitations.) > > I suspect the easiest bit will be improved usability design, since the > Meetecho folk tend to start with reasonable design and make improvements > quickly, as experience is gained. But yes, from some comments over the > last two meetings, there's probably room for that improvement. I must say that modulo issues with the network (which were probably local on my side), the experience was great, and I must say that the meetecho folks provided "online" help in a very timely manner (thanks!). There's room for improvements.. but in some cases they seem to be more about integration of local and remote participants, than with "bugs" in the tools themselves. e.g., as you've correctly noted, it would be great if there was a means for managing the mic queue, such that there's a single queue, that includes remote participants. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492