InfoComm: The Nuts and Bolts of Using WebRTC in Pro AV
By Tim Kridel
Special to InfoComm International
WebRTC is one of the hottest topics in pro AV, with plenty of hand-wringing about whether it will commoditize video conferencing or grow the market by creating more endpoints that SIP and H.323 systems can connect to. Either way, it’s clear that there’s already enough customer interest that AV pros need to figure out how to support it.
“Everybody under the sun is asking about WebRTC these days, but the reality is that adoption is in the early stages,” says Ami Barzelay, Vidyo solutions architect, business development.
One fundamental difference between traditional SIP/H.323 video conferencing and WebRTC is that the latter uses a mesh architecture. That’s fine for one-on-one conferences, such as a financial advisor using WebRTC to provide white-glove service to a high-value client.
Mesh starts to cause problems when there are several participants because each one gets a separate video feed from everyone else. That adds up to a lot of bandwidth, which is an obvious problem on, say, a corporate LAN that’s already overloaded or when some participants are using mobile devices, where video can quickly drain a data bucket.
But mesh also shows how problems sometimes are opportunities. AV vendors and integrators can offer customers the option of using a traditional video conferencing bridge, which would collect the WebRTC participants’ feeds and send a single, consolidated stream down to each endpoint.
Some of those customers might already own a bridge. The integrator or vendor can add value in their eyes by showing how it can be extended to support WebRTC. Those that don’t own a bridge could be sold one, either as an on-premises solution or as a hosted service. Either way, mesh’s drawbacks are an example of why WebRTC won’t necessarily cannibalize sales of traditional video conferencing hardware, software and services.
“WebRTC is a subset of people who need to use video communications,” says Michal Raz, Vidyo vice president of business development. “There’s still going to be people with SIP, H.323 and other codecs.”
Some integrators agree.
“People will continue to buy Lync-optimized endpoints and 323/SIP endpoints, but a new market segment will likely emerge and begin to grow,” says Brad Johnston, Solutionz Conferencing COO.
Bridging the Differences
A bridge or some other piece of infrastructure also is required to connect one WebRTC user with another. Unlike traditional video conferencing systems, Lync or Skype, WebRTC―at least in its current form―doesn’t have address books, so users have no way of finding or connecting directly to one another. Something has to provide a meeting room for them to dial into or a way for others to dial out to them.
“You need some infrastructure to make it all work because people are going to meet somewhere,” says Simon Dudley, LifeSize video evangelist.
One example is LifeSize’s UVC suite, which includes a product that provides address books and recording for up to 25 concurrent WebRTC participants. Enterprises could install it on their own server in a VMware environment, or they could buy a standalone node.
“A lot of our resellers love selling a 1RU box,” Dudley says. “Now you can see why the video conferencing industry is excited by this. The number of people who can get involved goes through the roof. Instead of making money selling $100,000 meeting rooms, we start selling $20,000 pieces of infrastructure, but a lot more people get involved.”
Another way that AV pros can stay relevant in WebRTC is by helping customers overcome interoperability challenges.
“Not all WebRTC client implementations are going to be the same, so you want to look to the people who are already doing desktop video conferencing and [can] apply that knowledge to WebRTC.” Raz says. “One WebRTC client might not be able to talk to another WebRTC client because they use different signaling.”
WebRTC doesn’t require clients to use a specific type of signaling protocol, such as Jingle, because that would limit developers’ ability to innovate. When WebRTC is used for B2B or B2C communications, the enterprise’s session border controller (SBC) becomes a factor because they have their own protocols. So when helping a customer implement WebRTC, it’s important to see which protocols are used by its SBC vendor and its WebRTC client vendor.
“The integrator is going to have to follow whatever recommendations the vendor has,” Raz says.
One common issue with any standard is that if all vendors did was follow the standard, they wouldn’t have many market-differentiation opportunities aside from price. It’s possible that vendors will add more collaboration features to make their WebRTC solutions stand out from the pack. Whether that will create additional interoperability issues remains to be seen.
“The WebRTC standard itself is only going to be implemented by a limited number of vendors as it is a browser API and associated media plane functionality implemented in browsers,” says Andrew Hutton, chair of the International Multimedia Telecommunications Consortium’s WebRTC Interoperability Activity Group. “Therefore I don’t believe we will see the same type of proprietary extensions. The opportunities for differentiation come from building innovative applications based on the functionality provided by the browser, as we have seen with other Web technologies.”
Firewall Déjà Vu
WebRTC is the latest example of how AV, IT and telecom are converging.
“If integrators want to play in this space, they’re going to have to expand their knowledge base to the underlying network technologies, [such as] the firewall,” says Nick Hawkins, Polycom senior director of advanced technology for the APAC region. “There are technologies defined in WebRTC to enable firewall traversal — such as STUN, ICE and TURN — but they still need to be configured as part of the deployment.”
Years ago, firewalls were a challenge for traditional video conferencing systems until vendors developed traversal solutions. WebRTC benefits from that work.
“It was recognized as an issue due to all that past experience and addressed in the standard,” says Val Matula, Avaya Labs head of multimedia research. “The standard calls for a STUN TURN server to be positioned straddling a firewall or a network address translation (NAT) [node] inside and outside.
“It’s the function of the STUN TURN server to help negotiate a media path across a compliant firewall or border control device. Inside the browser, they specify that if you can’t make a direct connection, go back and ask the Web server where the STUN TURN server is that you [should] use to make the connection.”
If setting up the connection involves a straight shot through an SBC or firewall, the process takes only a second or two. If the STUN TURN server is involved, set up can take 5 to 15 seconds. To participants, that delay can be annoying or prompt them to try restarting the session.
The speed and latency of the network also affects the user experience. So like other examples of AV-IT convergence, WebRTC can mean that integrators will have to assess and upgrade the customer’s LAN, MAN or WAN — assuming that the IT department doesn’t want to take on that task.
“A ratty network is going to create a problem, as it does with all video,” says Solutionz’s Johnston. “You want to make sure you’ve got adequate bandwidth.”
If there isn’t, the user experience can suffer because WebRTC isn’t as flexible and forgiving as traditional video conferencing technologies.
“You get what you get on WebRTC,” Matula says. “[There’s] none of the sensing, auto adjusting and tradeoff between voice and video priority in terms of which packets are sent out. It assumes that you have a good enough channel to get the job done. If not, you’ll renegotiate the whole session down to a lower parameter.”
This article was reprinted with permission from InfoComm International and originally appeared here.