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: 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?
