Convergence /

Getting down to business to business videoconferencing

Our biggest frustration in trying to set up a video conference between people who were not resident on a common network backbone was trying to dial from one secure enterprise network into another similarly configured, yet independently managed enterprise network. We believe that corporate IT folks who want to set up business-to-business videoconferencing between employees at their own company and business partners are likely to run into the same frustrations.

Say for example, an engineer on the Ford Motor company network wants to visually communicate, collaborate and conference with a station in an independent manufacturing facility using H.323 video (the internationally adopted standard for videoconferencing over IP networks), there would be only three choices for an IT manager to make that call work.

The first options involves using either an end point with H.320 signaling and ISDN end to end (end point to end point, assuming that both the facilities had ISDN drops to the videoconferencing systems), or use H.320 over ISDN between two H.323/H.320 gateways. H.323 would be protocol used for the IP leg to the ISDN interface. A gateway at the LAN/WAN interface would convert signaling from H.323 to H.320. Then you would need another gateway to convert the video back to H.323 for transmission over IP to the remote user. In our experience, the delay introduced by having two video network gateways in each stream would produce very low quality video. There are also a number of issues remaining to be solved around how a gateway receiving an incoming call resolves the appropriate IP address.

Another possible scenario is to have a broadband connection, such as T1, DSL or a cable modem, to the public Internet. Provided the parties wanted to meet at a time of day when the backbones of the public Internet are not congested, this topology would probably work. For a guaranteed QoS environment, the two companies would need to have access to the same backbone service provider, otherwise, their traffic would not be passed from one virtual private network to a competitor's.

A third architecture is to use the ISDN lines (possibly in place for H.320 videoconferencing today) with remote access servers at each facility. When a gatekeeper resolves a known IP address or the name of a collaborator in the corporate directory, it would dial across the public telephone infrastructure to the Remote Access Server or special switch, such as that designed by VIP Switch with QoS services, using 3BRI or partial T1, to a pre-assigned number. Currently, lack of synchronization of data between the circuits in such a call may cause high latency. Vendors we spoke with were skeptical that this option is viable due to the high tariffs for ISDN calls.

We believe that the long term solution to the question of inter-domain or inter-business videoconferencing will be resolved through new devices in the network service providers' infrastructure that will leverage SS7 (Signalling System 7) with relational databases and supplementary network services commonly found in the public telephone network today but otherwise absent in the IP world. Engineers developing standards for these gateways and services, globally referred to as "Megaco" in the IETF and H.248 in the ITU, are hard at work. Proprietary solutions will bridge the 2-3 year gap until these standards are sufficiently stable to warrant commercial deployments.

Until such services are available, we are not confident that business-to-business conferencing over IP will be available in secure environments or provide video and audio quality suitable for business applications.