6th March 2017
It's fair to say that Wireless Presentation Systems, systems that allow meeting attendees to wirelessly stream what's on their screen to a large display, have exploded in popularity over the last 3-4 years.
It’s hard to pinpoint a single reason for this explosion. More likely is a combination of various factors including (but not limited to):
What’s clear is that these systems, which at first where installed on a smaller scale (like an organisation’s main meeting rooms) are now being deployed en-masse right now.
As a result, those involved in the deployment, be they IT Managers, Heads of AV or Integrators, are now, more than ever having to give deep thought and consideration to scalability, i.e. what will the effect be on my network if and when I start to add an increasing number of wireless presentation systems to that network?
With that in mind, here are 3 key considerations for deploying wireless presentation systems and assessing their ability to scale.
One of the main considerations here is how your wireless presentation system deals with Network Address Translators (NAT) which can hinder or block some communication and collaboration protocols.
Here is an example of NAT at work, courtesy of Alex Castrounis at Innnoarchitect.
Suppose you’re at a coffee shop and join their WiFi, your computer will be assigned an IP address that exists only behind their NAT, say 184.108.40.206. To the outside world, however, your IP address may actually be 220.127.116.11.
The outside world will therefore see your requests as coming from 18.104.22.168, but the NAT device will ensure responses to your requests are sent to 22.214.171.124 through the use of mapping tables.
Given the involvement of a NAT device, how do I know my mom’s IP address to send audio and video data to, and likewise, how does she know what IP address to send audio and video back to?
So, when researching wireless presentation systems, ask if they can reliably avoid server relayed media. The upside here is reduction in latency, increase in quality and less load on the server.
Key question to ask here is 'Is this system an adaptive network solution that can adjust to changing network conditions? For example, does it respond to bandwidth availability or can it detect and avoid network congestion?
With a plethora of media types and endpoints on the network, another important question to ask is if the wireless presentation system in question can support the negotiation of that media and endpoints.
This is important for a number of reasons: if it does, it helps produce an efficient amount of bandwidth and delivers the best possible voice and video communication. It's worth noting that the APIs and signalling inherent in a system running on the WebRTC framework, can negotiate the size and format for each endpoint individually.
When evaluating wireless presentation systems for their ability to scale, it boils down to two main issues: Routing & Bandwidth.
For these reasons, with Montage we’ve chosen to put WebRTC at the core of our wireless presentation system. We believe this approach makes us more scalable than existing bandwidth-hungry solutions that are TCP focused.
In addition, with Montage we’ve gone beyond what WebRTC offers and have built support for hardware encode and decode for Linux….and it’s this that’s at the heart of the Montage hardware solution.
To see Montage in action and discuss our approach to scalable wireless presentation systems, you can get in touch here.
You may also be interested in 5 Must Have Features of a Wireless Presentation System