The previous topic about Caller ID issues on Cisco FXO ports was of interest to many readers, and that's why I decided to write series of posts about Cisco Voice Gateways for beginners. I see in our classes that the Voice Gateways are always a kind of a "dark horse" to our students, especially when we talk about traditional telephony interfaces, so let's talk about these devices in more detail.
Why would someone use a voice gateway? The answer is very simple. You will need a voice in all cases when you want to connect your enterprise VoIP telephony solution to traditional telephony networks and devices such as analog phones, analog trunks, analog or digital PBXs and, of course, your local PSTN (Public Switch Telephony Network). A voice gateway is a hardware device which typically works as a bridge between traditional and VoIP telephony. But don't think that voice gateways are required only to integrate with a classic telephony systems. When you connect to your PSTN with a SIP trunk, a Cisco voice gateway will help you to solve an issue with NAT (Network Address Translation).So, a voice gateway is a device that bridges two different telephony networks together and functions as a translator between different types of networks. The standard purpose of voice gateways is to convert telephony traffic (both voice and signaling) from the traditional devices into IP packets for transporting over an IP network (such as your LAN).
A typical usage of the voice gateways are shown in the picture below. In this example, the voice gateways connects your company telephony solution to the PSTN:
Usually, Cisco voice gateways have two components which provides the translation of telephony traffic and connection to traditional networks (these requirements are not applied to CUBE gateways):
- a voice interface (port) card - it physically connects the the voice gateway to traditional telephony interfaces and emulate physical telephony switch connections so that voice calls and their associated signaling can be transferred intact between a packet network and a circuit-switched network or device.
- a DSP (Digital Signal Processor) module - a card with specialized microprocessors providing stream-to-packet signal processing functionality that includes voice compression, echo cancellation, and tone- and voice-activity detection. The DSP is always involved to a call that has two call legs - one leg on a traditional telephony interface and the second leg on a VoIP connection. The traditional leg must be terminated by hardware that performs coding/decoding and packetization of the stream. DSPs perform this termination function.
There are three connection options for Cisco voice gateways:
- Analog voice ports - they connect voice gateways in traditional or Plain Old Telephony Services (POTS) networks to analog two-wire or four-wire analog circuits in telephony networks. Cisco supports FXS, FXO and E&M analog voice ports.
- Digital voice ports - these ports connect an IP telephony network to the POTS PSTN or to a PBX via digital trunks, such as PRI common channel signaling (CCS), BRI, and T1 or E1 channel associated signaling (CAS). Digital T1 PRI trunks may also connect to certain legacy voice-mail systems.
- IP to IP voice gateways or Cisco Unified Border Element (CUBE) - such gateways are used to interconnect two VoIP networks and allows communications between endpoints distributed among them. A typical scenario is to connect your CUCM to the PSTN via a SIP trunk. The Cisco Unified Border Elements may implement filtering, address translation, and security-related functions.
Cisco voice gateways can use various signaling protocols, depending on the hardware platform. Signaling is the ability to generate and exchange the control information that will be used to establish, monitor, and release connections between two endpoints. Voice signaling requires the ability to provide supervisory, address, and alerting functionality between nodes. Protocol selection depends on site-specific requirements and the installed base of equipment. The signaling supported by Cisco voice gateways are below:
- H.323
- SIP
- MGCP
- SCCP
Gateways are usually deployed as edge devices on a network. Because they will interface with both the PSTN and the company WAN, they must have the appropriate hardware and utilize the appropriate protocol for that network. The figure represents a scenario in which three different types of gateways are deployed for VoIP and PSTN interconnections.
The scenario displays the unified communications network of a company that was recently formed as a result of a merger of three individual companies. In the past, each company had its own strategy in terms of how they connected to the PSTN. The Head Quarter (HQ) of the company is in San Jose, besides that there are two branch offices in Chicago and Denver:
- The San Jose HQ location uses a Cisco Unified Communications Manager environment with a MGCP-controlled voice gateway to connect to the PSTN.
- The Chicago branch location uses Cisco IP Phones registered at HQ's CUCM. There is also H.323-based voice gateway to connect to the PSTN in Chicago.
- The Denver location has a Cisco SIP proxy server (or any other third party IP based PBX) and SIP IP phones as well as a SIP-based unified communications gateway to connect to the local PSTN in Denver. Because the Denver location is a small office, it does not use the WAN for IP telephony traffic to the other locations. Therefore, its local VoIP network is connected only to the PSTN.
H.323 and SIP gateways are do not need a call control server because these protocols use peer-to-peer model of operations and can route the voice calls themselves. Therefore, they can be deployed on networks in which control server, such as Cisco Unified Communications Manager, are not present. These type of gateways never registers on CUCM.
MGCP and SCCP are streamlined protocols that follow a client/server model and therefore only work on a network in which a call control server (CUCM) is present. Cisco MGCP and SCCP voice gateways always register on CUCM. They do not have any call routing configurations and can't route the calls without a call control server.
No comments:
Post a Comment