精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

I had a chance to talk with Marc Hambley from BT Conferencing last week, and he described the architecture of their Business-to-Business (B2B) video conferencing service (thanks Marc!). B2B video conferencing allows enterprises to easily set up video conferencing calls between different companies, which in the past have been difficult and fraught with delay and technical issues.
Today the solution provided by BT-Conferencing, called the Global Video Exchange (GVE) is focused on the Cisco Telepresence solutions. The transport architecture is certainly compatible with other forms of video conferencing, but BT is not saying if/when they will support other vendors’ systems.

Design & Purpose
The goal of this offering is to support fully QoS enabled, guaranteed bandwidth connections between disparate enterprises for video (telepresence) calls. Many enterprises today are successfully doing video calls across the Internet, which does not support QoS. But at the high end of the market there is no question that a prioritized network provides a more consistent, high quality video experience, and this is what most enterprises using telepresence suites want to accomplish.

I think about video conferencing design as broken into two components, signaling and transport. Transport is responsible for getting the real-time audio and video streams from one endpoint to the other with low loss, jitter and delay. Signaling is responsible for setting up the calls, checking on policies, initiating call tracking or billing if appropriate, pointing the transport components to the right place, and tearing down calls when complete. Let's look at these two functions in the BT design.

Transport
Within an enterprise, video traffic is carried in a QoS class, on the converged enterprise network. In some cases video traffic is carried on a separate overlay network that parallels the enterprise network, but most enterprises are converged or are migrating to a converged approach. The enterprise network usually includes an MPLS-VPN supported by a service provider that interconnects the disparate locations of the company. The MPLS-VPN is a secure network, protected by firewalls from the rest of the world.

To get from one enterprise to another, video traffic has to cross the MPLS-VPN boundary. The session border controller (SBC) is the key component that allows video traffic to cross this boundary, without compromising the security of the enterprise network. In the BT GVE there is an SBC for this purpose. Each enterprise network wishing to participate in B2B video is connected to this SBC as shown in Figure 1 below.

Figure 1: BT Global Video Exchange Hub Architecture

The SBC translates the source and destination IP address for each packet passing through so the IP addressing will be correct for the destination network. This overcomes the potential address conflict of enterprise networks all using similar private (e.g. RFC 1918) address spaces. A packet flowing from an enterprise endpoint to the CMTS will have the endpoint source address and the enterprise port on the SBC as a destination address. The SBC will change the source address to the IP address of its BT-hub network port (the port connected to the CMTS) and the destination address to the address of the CMTS. Packets flowing from the CMTS towards the enterprise endpoint will be translated in a similar way in the opposite direction.

The SBC is also responsible for mapping the QoS markings of packets. Some enterprises carry video traffic in the EF class, while others may use CS4 or AF41. As packets pass through the SBC their markings are modified as necessary to match the destination network standard.

Unlike some of their competitors, BT-Conferencing supports connections from carriers other than their own BT network. In Figure 1 we see three example enterprises, each being supported by a separate carrier, all connected to this centralized SBC. The SBC, under direction from the signaling plane (call manager), will open up a path for a specific video conferencing call between the enterprise MPLS-VPN and the CMTS. The CMTS acts as a meet-me bridge to terminate each endpoint connection and provide both point-to-point and multipoint video conferencing capabilities.

[NextPage]

BT actually deploys two hubs using this same architecture, one in Denver and one in London, as shown in Figure 2 below. Each hub has the same compliment of equipment, and each hub can support B2B video calls for connected customers. North American based companies connect to the Denver hub, while European customers connect to the London hub. An internal (BT) link connects the two hubs allowing B2B calls to be set up between customers on each continent.

Figure 2: BT Conferencing GVE Dual-Hub Design

Signaling & Call Setup
The signaling infrastructure for the BT-Conferencing GVE is based on the Cisco Call Manager and the SIP protocol. Each video conferencing endpoint is assigned an E.164 address (telephone number) that is globally unique. E.164 addresses are assigned by the ITU, and are allocated to telephony providers worldwide.

The enterprise Cisco Telepresence deployment has a call manager for call signaling within the enterprise, and perhaps also to support a VoIP deployment. A video call from the telepresence system to an internal (enterprise) endpoint is handled by the enterprise call manager. However, when a call is placed to an external (B2B) video endpoint, the internal call manager does not recognize the E.164 address. It is programmed to forward unknown endpoint calls to the call manager within the BT GVE (see Figure 3 below).

Figure 3: BT-Conferencing GVE Signaling Design

The GVE Call manager is programmed with a set of policies, determined by each enterprise participating in the GVE. These policies determine if an individual call is appropriate and can be set up. The GVE Call Manager checks the policies for the calling party and the called party for each B2B call, and only establishes the call if its parameters are allowed by both policies.

If the policy check allows the call, the call manager then directs the SBC to open the right ports to allow the audio and video signals to cross the SBC boundary. The call manager also provides the SBC with the target IP address for the destination device, in most cases the CMTS bridge. Once all parties are connected to the bridge, the conference begins.

Other Players?
I’ll take a look at other B2B video conferencing service providers over the coming weeks as I am able to get the information, so we can get a look at how they compare, how they might interconnect, if and when they might support legacy (H.323) video deployments, and how this market may evolve going forward.

（責(zé)任編輯：企業(yè)網(wǎng) 來源：企業(yè)網(wǎng)D1Net ）