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(_at_)unina(_dot_)it> 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.
signature.asc
Description: OpenPGP digital signature