Sponsored By

What are the Requirements for B2B Video and Telepresence?What are the Requirements for B2B Video and Telepresence?

First and foremost we need network connectivity to ensure bandwidth and to create end-to-end Quality of Service (QoS).

John Bartlett

April 20, 2009

5 Min Read
No Jitter logo in a gray background | No Jitter

First and foremost we need network connectivity to ensure bandwidth and to create end-to-end Quality of Service (QoS).

Everyone I talk to seems to agree that business-to-business (B2B) video and telepresence is a good idea. Last week I posted some thoughts on why we don't have it today. But let's look forward and assume we can get B2B video working over the next few years. What are the requirements for a good business to business video service? I'll give you my thoughts, but if I am missing the boat, please give me yours as well.Connectivity, Bandwidth and QoS: First and foremost we need network connectivity to ensure bandwidth and to create end-to-end Quality of Service (QoS). Connection through the Internet does not provide either a guarantee of bandwidth or consistent QoS. So any proposed solution must demonstrate a well designed path that both guarantees bandwidth and recognizes class markings and treats high priority streams with the right forwarding behavior so that low packet loss and low jitter can be achieved.

Although most enterprises and service providers agree on using the DiffServ standard for Class of Service (CoS) support, there is no standard implementation of DiffServ. Enterprises use their own discretion on how many classes to implement, how they assign applications to those classes, and what markings they use. Thus, when we try to connect the video streams from two enterprises, we may find one end marking the traffic as AF41 and the other end marking the traffic as CS4. Our B2B connection must resolve this mismatch and re-mark traffic as it crosses the network so that it will be properly treated by the receiving enterprise network. Or we must establish an international standard for the markings for specific application types.

Security: The next critical issue is security, which I break into two camps, network security and call security. Network security means properly securing the enterprise network so that the enterprise can remain confident that its data will not be compromised by allowing video traffic to flow in and out of the network. Enterprises have invested significantly in both process and infrastructure to ensure network security, and many are very reluctant to allow new traffic types in or out of their protected domain.

To address this issue we need a well defined security architecture that both allows video traffic to cross in and out of the network and ensures that only video traffic is allowed through.

Call security has to do with ensuring that the video calls placed between enterprises are not being monitored by third parties, so that the content of conversations or meetings can be kept private. This is an interesting issue, because we have very little of this kind of security on our telephones today. Yet in my conversations with enterprises about B2B video conferencing, this issue constantly comes up. Many enterprises want to limit the video endpoints that can make calls, limit the companies to which calls can be placed, and ensure that no one can call into the company without prior approval. So these concerns will also need to be addressed.

Ensuring that a third party is not monitoring the call can likely be addressed through encryption. Most video conferencing systems have standards-based encryption built-in already today. Concerns about using 3rd party service providers and bridges at those service providers need to be addressed as well through process, trusted relationships and possibly additional encryption.

Resource Reservations: Video conferencing can consume large bites of network resources such as bridge systems and network bandwidth. My guess is that at least for the first few years, these resources will need to be reserved for many situations because it will not be cost effective to provide sufficient resources for peak demand, thus creating a scheduling problem during peak usage hours.

To make a B2B video conferencing system work, the network bandwidth resources and the bridge resources will need to be scheduled in advance during those peak hours, especially for scheduled meetings. Ad hoc calls can just receive a busy signal and be deferred, but prescheduled meetings need to have guaranteed resources. How will these resources be scheduled? Who schedules them? Is this a service provided by the service providers, or by the video managed services, or by the individual enterprises?

Video Managed Services Cooperation: Many telepresence systems today are supported by a managed services provider to ensure the equipment is properly set up, the images are framed correctly, and in many cases to start the calls so attendees need only show up in the right room at the right time. For a B2B call, two or more managed service providers may be involved because different enterprises have contracted with different vendors. What is the process for managing the combined call? Who provides the bridging resources? Which set-up and fault management policy is used?

Just as the WAN service providers will be required to interconnect, the managed service providers will need to work out how to connect at an application level to best serve their customers through cooperation with other service providers.

Equipment compatibility: While most video conferencing products today are using H.264 compression, and video streams are supported over RTP on IP streams, there are numerous incompatible ways to set up calls. Long-time vendors of enterprise video conferencing equipment support the H.323 and SIP protocols, and interoperate. Desktop solutions often use a server-based setup model with other protocols. Integration with unified conferencing solutions usually requires SIP, but may have other hooks as well to make the systems properly display presence.

At the telepresence level we have all the same issues just mentioned, plus the incompatibles of how multiple codecs are multiplexed onto the network, or not multiplexed. And incompatibilities of how rooms are designed, matching of screen layouts between different screen-counts, and other issues related to camera angles and options when the room is not fully utilized. We probably have to hold off on this issue and try to get a reliable, one-screen to one-screen B2B solution in place first.

What is on your list of requirements for B2B video collaboration?First and foremost we need network connectivity to ensure bandwidth and to create end-to-end Quality of Service (QoS).

About the Author

John Bartlett

John Bartlett is a principal with Bartlett Consulting LLC, where he provides technical, financial, and management leadership for creation or transition of Unified Collaboration (UC) solutions for large enterprises. John discovers the challenges in each enterprise, bringing disparate company teams together to find and execute the best strategy using Agile-based methodology to support quick wins and rapid, flexible change. John offers deep technical support both in collaboration solutions and IP network design for real-time traffic with global enterprises world-wide.

 

John served for 8 years as a Sr. Director in Business Development for Professional & Managed Services at Polycom. In this role he delivered, defined and created collaboration services and worked with enterprises to help them shorten time-to-value, increase the quality and efficiency of their UC collaboration delivery and increase their collaboration ROI.

 

Before joining Polycom, John worked as an independent consultant for 15 years, assessing customer networks for support of video applications and other application performance issues. John engaged with many enterprises and vendors to analyze network performance problems, design network solutions, and support network deployments.

 

John has 37 years of experience in the semiconductor, computer and communications fields in marketing, sales, engineering, manufacturing and consulting roles. He has contributed to microprocessor, computer and network equipment design for over 40 products.