Today's question: Is it even theoretically possible to guarantee access to all potential webinar participants (attendees and presenters alike), no matter what their security settings and local hardware/software configurations are?
I don't think this is achievable, but I have plenty of clients who want to stipulate it as a requirement for their web conferences and broadcasts.
There are several approaches taken by web conferencing vendors (using the term in its most inclusive sense for all types of web collaboration). The most common are:
- Downloadable client software. Examples: WebEx, GoToWebinar. Each participant must download a program from the internet and install it on their computer before joining the conference. Potential problems: Institutional security policies that prevent installing programs from the internet on office computers. Software that is not compatible with the target device's operating system.
- Access via web browser using Flash. Examples: Adobe Connect, omNovia. Participants must have Adobe Flash Player installed in their web browser. No client software gets installed - instead, the conferencing software runs as an internet Flash application. Potential problems: Institutional security policies that prohibit use of Flash on office computers. Outdated version of Flash Player on target computer. Incompatible newer version/beta version of Flash Player on target computer. Unavailability of Flash on iOS devices. User confusion over how to operate Flash authorizations for device access.
- Access via web browser using WebRTC. Examples: AnyMeeting, Venstream (both with qualifiers). Application programming varies, but software relies on WebRTC for the data transport mechanics. Potential problems: Incompatible browsers or browser versions on target computers. Incomplete WebRTC standards for video creating incompatibility or need for additional protocols such as Flash.
- Access via web browser using other technologies such as Java. Example: Microsoft Live Meeting Web Access (obsolete). Unusual these days, but still possible. Conferencing software runs as a Java applet in the web browser. Potential problems: Incorrect version of Java on the target computer.
Methods 1 and 2 are by far the most common methods at the moment, and they each fail when confronted with users in companies with stringent security measures for employee computers (most commonly Financial Institutions and Government Offices, but extending to some Research Facilities, Healthcare, and Data Consolidators).
Even if the basic methodology is supported on a participant's computer, they may not be able to access all or part of the web conference content because of institutional security settings affecting HTTP and TCP/IP ports. This is far too complicated to explain properly here, but suffice to say that data flows between the internet and user computers through gateways known as ports. Each potential port has a number associated with it and lots of confusing terminology like "HTTP tunneling on port 80 with fallback to alternate port 8088."
Web conference vendors decide which ports their software will communicate through, and this can be thwarted by company-wide security settings that workers have no knowledge of or control over. By they way, this is often the reason for an attendee angrily calling you to complain that your stupid conferencing software doesn't work and they know it isn't their security settings because they were able to join another conference just the other day. The different products may have communicated through different ports.
It gets worse than this… There is the potential for additional layers of data communications jiggery-pokery such as multicast distribution within a corporate network. It's all enough to make a web conferencing engineering team break down and cry.
The upshot is that as a meeting host, you may have to grit your teeth and accept the fact that there will always be some participant out there with just the wrong setup, who will be unable to get into your meeting.
But if I'm wrong, I would like to know about it. Is there any vendor who wants to add a comment here stating that their software has enough alternate failover connection methods that everybody everywhere can access their web meetings?
