Videoconferencing Options Depend on Organization Size

Carl Weinschenk
Slide Show

Best Practices for Teleconferencing with Employees Working Remotely

The proliferation of teleconferencing--much of it ad hoc and on devices that the organization is unaware of--can lead to bandwidth challenges. Carl Weinschenk spoke to Stu Aaron, video communications company Blue Jeans Networks’ chief commercial officer, and Alagu Periyannan, the company’s co-founder and CTO. They told Weinschenk that good planning will enable IT to adequately support users.

Weinschenk: You suggest that there are options available for organizations who want to ensure that they have enough bandwidth for the growth of videoconferencing and teleconferencing. Can you elaborate?

Periyannan: Most people are connecting to us via the Internet. Once the action is on their own network, they have several approaches. Several companies are connecting into us with the VoIP element on separate VLANs. The advantage of a VLAN that separates VoIP and video traffic is that they have different QoS.

Weinschenk: Is there another common approach?

Periyannan: The second approach revolves around use of the WAN. Some customers’ preferences are to not use a separate VLAN on the WAN link but instead to segment traffic on the same link between voice, data and the video. So what they have is a firewall as well as packet shaping devices--such as Packeteer’s--that allow voice and video to be prioritized over data. Voice and video calls get higher cueing priorities and data takes what’s left. HTTP tends to be greedy. It takes as much bandwidth as possible. This makes sure that it stays in certain boundaries.

Weinschenk:  Which is more common?

Periyannan: It depends on [the] WAN provider. If they do provide a VLAN, people often prefer to do that. If there is a single common link, the VLAN capabilities may not be there and you take the other approach.

Very large enterprises, Fortune 1,000 companies, have many more resources at their command in terms of things like MPLS. Service providers like ours can directly connect to MPLS networks as well.

Weinschenk: So you are geared toward enterprise and smaller non-Fortune type companies?

Aaron: Remember that even a Fortune-size company has people connecting over the Internet from home. One of the key benefits of a cloud offering is that companies do not have to pay top dollar for high-speed WANs or MPLS networks, but still can have high quality. That certainly is good for mid markets and SMBs and they have flocked to solutions like these.

Periyannan: Companies like ours are doing things akin to CDNs in that we have distributed infrastructures with multiple ISPs that can be optimized across the globe to reach certain networks. We’re finding some Fortune 50 companies don’t have the capability to do what we are doing.

Akamai, Limelight and other traditional CDNs’ task is to deliver content in one direction to individual users, to consumers and people accessing websites and all that. We think that what we are doing is the equivalent of those CDNs, but designed for bidirectional, real-time delivery. We do global load balancing and each of those locations peer with multiple backbones and optimize the network and the path people take to us. It helps make sure every person comes in through the most optimized network path.

Aaron: A lot of intellectual property is fundamentally focused on how to build global video CDNs from scratch so they functionally look like a single global bridge. Everything is one hop away.

Weinschenk: So will the CDN-like thing you are building eventually meld with traditional CDNs?

Periyannan: The use case is very different between a content and interactive CDN. Content delivery CDNs’ job is to deliver Web images and videos in one direction so they can use caching. Interactive CDNs can’t cache content because they are real time and demand low latency … They have much more stringent requirements than traditional CDNs.

The second reason they won’t meld together is the transport protocols used in the case of most CDNs is HTTP. That’s what is used for images, photos and Web pages in the communications space. Interactive CDNs use the old granddaddy, H.323, and protocols such as Google’s XMPP. In our case, support for proprietary protocols such as Skype.  

Weinschenk: So they will stay separate?

Periyannan: We believe there are significant differences in protocol and latency characteristics and that they are different animals. The commonality of the two is that they sometimes are in the same countries and geo-locations. To that extent, we are working with companies such as Level 3, NTT, Global Crossing and Telia to interconnect ourselves with these networks.

Aaron: Physical networks and POPs can leverage the same underlying pipes and can take advantage of some service providers that can offer both types of CDNs.

Weinschenk: So they are discrete networks, but may show up in the same places?

Periyannan: We look at them as backbone networks and eyeball networks. Eyeball networks are providers such as Comcast, AT&T and Verizon. The backbone networks are those such as NTT, Level 3 and Global Crossing. Those are the companies that form the backbone of the Internet. The two overlap somewhat.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.