One thought: In several countries, 4G mobile phones (including in "tethered hotspot" mode) give adequate bandwidth for a WebRTC call. If the corporate firewall can't be bothered to behave decently, the answer may be to .... pick up the phone. On 11/02/2015 10:44 AM, Michael Richardson wrote: > Simon Pietro Romano <spromano@xxxxxxxx> wrote: > > this was an unlucky case. The remote presenter had made the test and > > he had indeed reported that he could not make any video (from his work > > location), whereas he could do “good enough” audio, due to a slow (and > > firewalled) network connection. My personal feeling is that we should > > avoid this kind of situations and perhaps ask the presenters to either > > find a better connection or delegate some of the local participants, or > > simply throw in the towel. Though, I don’t think we (i.e., the Meetecho > > I agree: especially when the issue is a firewall outside of the presenter's > control, the presenter should be told to move somewhere else. > > Further: could the echo test produce a log of ports > attempted/succeeded/failed, and errors (ICMPs/etc) received? > It would be nice if we could make it easier to report the issue to "IT", > as presumably people are doing this kind of thing with the blessing of their > employer, and so they should get supported. > > It also seems that the decision to present remotely, and not to travel is > usually made 2-3 months in advance, and so really there is no excuse to not > having things working in that amount of time. > > (Of course, there are exceptions where people are unable to travel due to > last minute issues) > > -- Surveillance is pervasive. Go Dark.
Attachment:
signature.asc
Description: OpenPGP digital signature