Introduction to VoIP Networks (Cisco VoIP Implementations)

Upon completion of this section, you will know the primary advantages and benefits of packet telephony networks, the main components of packet telephony networks, the definition of analog and digital interfaces, and the stages of a phone call. The final part of this section helps you understand the meaning of distributed and centralized call control and the differences between these two types of call control.

Benefits of Packet Telephony Networks

Many believe that the biggest benefit of packet telephony is toll bypass, or simply long-distance cost savings. However, because the cost of a long-distance call to most parts of the world has decreased substantially, this is not even one of the top three reasons for migrating to packet telephony networks in the North American market.

The main benefits of packet telephony networks are as follows:

■ More efficient use of bandwidth and equipment, and lower transmission costs—Packet telephony networks do not use a dedicated 64-kbps channel (DS0) for each VoIP phone call. VoIP calls share the network bandwidth with other applications, and each voice call can use less bandwidth than 64 kbps. Packet telephony networks do not use expensive circuit-switching equipment such as T1 multiplexers, which helps to reduce equipment and operation costs.

■ Consolidated network expenses—In a converged network, the data applications, voice, video, and conferencing applications do not have separate and distinct hardware, software, and supporting personnel. They all operate over a common infrastructure and use a single group of employees for configuration and support. This introduces a significant cost saving.


■ Improved employee productivity—Cisco IP phones are more than just simple phones. With IP phones, you can access user directories. Furthermore, you can access databases through extensible markup language (XML). Therefore, you can utilize the Cisco IP phone as a sophisticated communication device that allows users to run applications from their IP phones. In short, Cisco IP Phones enhance the user experience by bringing informational resources to the end user.

■ Access to new communications devices—Unlike the traditional analog and PBX phones, IP phones can communicate with a number of devices such as computers (computer telephony applications), networking devices, personal digital assistants, and so on, through IP connectivity.

Despite the stated benefits of packet telephony networks, when an organization decides to migrate to packet telephony, it will have to make an initial investment, which will probably not have an attractive short-term return on investment (ROI). Also, if the existing telephony equipment is not fully depreciated, there will be more reluctance to migrating to packet telephony at this time. Finally, it is not easy to consolidate and train the different groups of personnel who used to separately support the data and telephone equipment and networks.

Packet Telephony Components

A packet telephony network must perform several mandatory functions, and it can perform many optional ones. This requires existence and proper operation of various components. Some devices can perform multiple functions simultaneously; for example, for a small deployment a gateway can also act as a gatekeeper. The following is a list of the major components of a packet telephony network, but not all of the components are always present and utilized:

■ Phones—There might be analog phones, PBX phones, IP phones, Cisco IP Communicator, and so on. Please note that non-IP phones require the existence of IP gateway(s).

■ Gateways—Gateways interconnect and allow communication among devices that are not all necessarily accessible from within the IP network. For instance, a call from inside an IP network to a friend or relative’s residential analog phone line must go through at least one gateway. If a call from an analog phone, on a router’s FXS port for example, must go through a Wide Area Network (WAN) connection such as a Frame-Relay virtual circuit to get to a remote office, it will also have to go through a gateway. Connectivity of IP networks to Private Branch Exchange (PBX) systems is also accomplished through gateways.

■ Multipoint control units (MCU)—An MCU is a conference hardware component. MCU is comprised of a Multipoint Controller and an optional Multipoint Processor that combines the received streams from conference participants and returns the result to all the conference participants.

■ Application and database servers—These servers are available for each of the required and optional applications within the IP/packet telephony network. For instance, TFTP servers save and serve IP phone operating systems and configuration files, and certain application servers provide XML-based services to IP phones.

■ Gatekeepers—You can obtain two distinct and independent services from gatekeepers:

1. Call routing, which is essentially resolving a name or phone number to an IP address, and

2. CAC, which grants permission for a call setup attempt.

■ Call agents—In a centralized call control model, call routing, address translation, call setup, and so on are handled by call agents (CA) rather than the end devices or gateways. For example, Media Gateway Control Protocol (MGCP) is a centralized model that requires the existence of CAs. Outside the context of MGCP, the Call Agents are often referred to as Common Components.

■ Video end points—To make video calls or conferences, you must have video end points. Naturally, for video conferencing, the MCU must also have video capabilities.

■ DSP—Devices that convert analog signals to digital signals and vice versa use DSPs. Through utilization of different coding and decoding (codec) algorithms such as G.729, DSPs also allow you to compress voice signals and perhaps perform transcoding (converting one type of signal to another, such as G.711 to G.729). IP Phones, Gateways, and conference equipment such as MCUs use DSPs.

At this point, it is important to clarify the difference between two concepts: digital signal and VoIP. Today, in almost all cases, one of the early tasks performed in voice communication is digitizing analog voice. This is true regardless of whether the call stays within the PBX system, goes through the PSTN, or traverses through an IP network. Figure 1-1 shows a company that has two branches. The local (main) branch has IP phones, but the remote branch has only PBX phones. Even though all voice calls need digitization, calls that remain within the remote branch are not VoIP calls and need not be encapsulated in IP packets.

Figure 1-1 Packet Telephony Components Local Branch

Packet Telephony Components Local Branch

VoIP, on the other hand, in addition to digitizing voice, requires IP-based signaling (for call routing, admission control, setup, maintenance, status, teardown, and so on). Also, VoIP requires conversion of analog voice into IP packets and transport using IP-based protocols such as Realtime Transport Protocol (RTP). Many organizations might not be using VoIP (packet telephony) but have been enjoying the benefits of voice digitization technologies such as PBX and T1 lines. Converting analog voice signals to digital voice signals and back is almost always done. But VoIP signaling and VoIP encapsulation and transport happen only in packet telephony networks. In Figure 1-1, all phone calls made with the IP phones from the main local branch are IP dependent and need IP signaling, IP encapsulation, and transportation in addition to the initial digitization.

You might ask if a packet telephony network always includes and needs a gateway. The answer is this: If the IP phones need to make calls and receive them from PBX phones or the phones on the PSTN network, or if certain calls have to leave the LAN and go through a WAN to reach non-IP phones (such as analog or PBX phones) at remote locations, a gateway is definitely necessary. In Figure 1-1, a phone call made from an IP phone in the local branch to another IP phone within the local branch does not require the services of a voice gateway.

Analog Interfaces

A gateway can have many types of analog interfaces: FXS (Foreign Exchange Station), FXO (Foreign Exchange Office), and E&M (Earth and Magneto or Ear and Mouth).

An FX connection has a station and an office end. The office end (FXO) provides services such as battery, dial tone, digit collection, and ringing to the other end, namely the station (FXS).

The FXS interface of a gateway is meant for analog phones, fax machines, and modems. To those devices, the gateway acts like the PSTN central office (CO) switch.

The FXO interface of a gateway can connect to a regular phone jack to be connected to the PSTN CO switch. The FXO interface acts as a regular analog device such as a legacy analog phone, and it expects to receive battery, dial tone, digit collection, ringing, and other services from the other side, namely the PSTN CO switch. In many small branch offices, at least one FXO interface on a gateway is dedicated to and connected to the PSTN for emergency 911 call purposes.

The E&M connections traditionally provided PBX-to-PBX analog trunk connectivity. However, any two of gateways, PBX switches, or PSTN CO switches may be connected using an E&M connection with E&M interfaces present. Five different types of E&M types exist based on the circuitry, battery present, wiring, and signaling used.

Figure 1-2 shows a gateway with a fax machine plugged into its FXS interface. Its FXO interface is connected to the PSTN CO switch, and its E&M interface is connected to a PBX switch. The gateway has connectivity to the IP phones through the LAN switch, and it provides connectivity to the other branches through the IP backbone (WAN).

Figure 1-2 Gateway Analog Interfaces Local Branch

Gateway Analog Interfaces Local Branch

Digital Interfaces

Gateways can also connect to telco and PBX switches using digital interfaces. A gateway can have BRI or T1/E1 digital interfaces. Using a T1 connection is common in North America, whereas E1 lines are more common in Europe. You can configure the T1/E1 interface controller as an ISDN PRI or as Channelized T1/E1 and use channel associated signaling (CAS).

BRI and PRI interfaces use common channel signaling (CCS), where a D (Delta) channel is dedicated to a messaging style of signaling, such as Q931 (or QSIG). You can configure a T1 controller to perform channel associated signaling (CAS) instead. T1 CAS does not dedicate a D channel to signaling. Each T1 CAS channel gives up a few data bits to perform signaling; therefore, T1 CAS is also referred to as robbed bit signaling. You can also configure an E1 interface to perform CAS, but because E1 CAS still dedicates a channel to signaling, data channels do not lose bits to signaling.

Table 1-2 lists and compares the BRI, PRI, and CT1/CE1 digital interfaces.

Table 1-2 Summary of Digital Interfaces

Interface

64 Kbps Data/ Voice Channels

Signaling

Framing Overhead

Total Bandwidth

BRI

2

16 kbps (D channel)

48 kbps

192 kbps

T1 CAS

24

In-band (robbed bits)

8 kbps

1544 kbps

T1 CCS


23

64 kbps (D Channel)

8 kbps

1544 kbps

E1 CAS

30

64 kbps

64 kbps

2048 kbps

E1 CCS

30

64 kbps (D Channel)

64 kbps

2048 kbps

Stages of a Phone Call

The three most popular VoIP signaling and control protocols are H.323, which is an ITU standard; Media Gateway Control Protocol (MGCP), which is an Internet Engineering Task Force (IETF) standard; and Session Initiation Protocol (SIP), also an IETF standard. Regardless of the signaling protocol used, a phone call has three main stages: call setup, call maintenance, and call teardown.

During call setup, the destination telephone number must be resolved to an IP address, where the call request message must be sent; this is called call routing. Call admission control (CAC) is an optional step that determines whether the network has sufficient bandwidth for the call. If bandwidth is inadequate, CAC sends a message to the initiator indicating that the call cannot get through because of insufficient resources. (The caller usually hears a fast busy tone.)

If call routing and CAC succeed, a call request message is sent toward the destination. If the destination is not busy and it accepts the call, some parameters for the call must be negotiated before voice communication begins. Following are a few of the important parameters that must be negotiated:

■ The IP addresses to be used as the destination and source of the VoIP packets between the call end points

■ The destination and source User Datagram Protocol (UDP) port numbers that the RTP uses at each call end point

■ The compression algorithm (codec) to be used for the call; for example, whether G.729, G.711, or another standard will be used

Call maintenance collects statistics such as packets exchanged, packets lost, end-to-end delay, and jitter during the VoIP call. The end points (devices such as IP phones) that collect this information can locally analyze this data and display the call quality information upon request, or they can submit the results to another device for centralized data analysis. Call teardown, which is usually due to either end point terminating the call, or to put it simply, hanging up, sends appropriate notification to the other end point and any control devices so that the resources can be made free for other calls and purposes.

Distributed Versus Centralized Call Control

Two major call control models exist: distributed call control and centralized call control. The H.323 and SIP protocols are classified as distributed, whereas the MGCP protocol is considered as a centralized call control VoIP signaling protocol.

In the distributed model, multiple devices are involved in setup, maintenance, teardown, and other aspects of call control. The voice-capable devices that perform these tasks have the intelligence and proper configuration to do so.

Figure 1-3 shows a simple case in which two analog phones are plugged into the FXS interfaces of two Cisco voice gateways that have connectivity over an IP network and use the H.323 signaling protocol (distributed model). From the time that the calling device goes off-hook to the time that the called device receives the ring, seven steps are illustrated within this distributed call control model:

I. The calling phone goes off-hook, and its voice gateway (R1) provides a dial tone and waits for digits.

2. The calling phone sends digits, and its voice gateway (R1) collects them.

3. The voice gateway (R1) determines whether it can route the call, or whether it has an IP destination configured for the collected digits. In this case, the voice gateway (R1) determines the other voice gateway (R2) as the destination. This is called call routing; the R1 is capable of doing that in the distributed model.

4. R1 sends a call setup message to R2 along with information such as the dialed number.

5. R2 receives the call setup message from R1 along with the information sent.

6. R2 determines whether it has a destination mapped to the called number. In this case, the called number maps to a local FXS interface. R2 takes care of this call routing in the distributed model.

7. If the determined FXS port on R2 is not busy and it is not configured to reject this call, R2 sends an AC ringing voltage to the FXS port, and the phone plugged into that interface rings. If the ringing phone on the FXS of R2 goes off-hook, the call is considered answered, and voice traffic starts flowing between the calling and called parties.

Figure 1-3 Call Setup Example for Distributed Call Control

Call Setup Example for Distributed Call Control

While the call is in progress, endpoints can monitor the quality of the call based on the number of packets sent, received, and dropped, and the amount of delay and jitter experienced. In the distributed model, the end points might have the intelligence and configuration to terminate a call if its quality is not acceptable.

If either phone on R1 or R2 hangs up (goes on-hook), the corresponding router sends a call termination message to its counterpart. Both routers release all resources that are dedicated to the call. Notice that in this distributed model example, the end-point gateways handled the call teardown in addition to the other tasks.

In the example used here, no call routing, call setup, call maintenance, or call teardown tasks depended on a centralized intelligent agent. The gateways at both ends had the intelligence and configuration to handle all the tasks involved in the end-to-end call. You must note, though, that if there were thousands of end devices, each would need the intelligence and configuration to be able to make and maintain calls to all other destinations (not necessarily at the same time). Naturally, a fully distributed model is not scalable; imagine if the telephone in your home needed the intelligence and configuration to be able to call every other phone number in the world, without the services of telco switches!

For large-scale deployments of H.323 or SIP, which are distributed call control protocols, special devices are added to offer a scalable and manageable solution. For example, the H.323 gatekeeper can be utilized to assist H.323 terminals or gateways with call routing. In SIP environments, special SIP servers such as Registrar, Location, Proxy, and Redirect can be utilized to facilitate scalability and manageability, among other benefits.

Centralized call control relieves the gateways and end points from being responsible for tasks such as call routing, call setup, CAC, and call teardown. MGCP end points do not have the intelligence and configuration to perform those tasks, and they are expected to receive those services from CAs. Analog voice digitization, encapsulation of digitized voice in IP packets, and transporting (sending) the IP packets from one end to the other remain the responsibility of the DSPs of the MGCP gateways and end points. Therefore, when the call is set up, VoIP packet flow does not involve the CA. When either end point terminates the call, the CA is notified, and the CA in turn notifies both parties to release resources and essentially wait until the next call is initiated.

Figure 1-4 shows a simple case in which two analog phones are plugged into the FXS interfaces of two Cisco voice gateways that have connectivity over an IP network and are configured to use the MGCP signaling protocol (centralized model), using the services of a CA. The sequence of events from the time that the calling phone goes off-hook to the time that the called phone rings is listed here:

1. The phone plugged into the FXS port of R1 goes off-hook. R1 detects this event (service request) and notifies the CA.

2. The CA instructs R1 to provide a dial tone on that FXS port, collect digits one at a time, and send them to the CA.

3. R1 provides a dial tone, collects dialed digits, and sends them to the CA one at a time.

4. The CA, using its call routing table and other information, determines that the call is for an FXS port on R2. It is assumed that R2 is also under the control of this CA, and that is why the CA had such detailed information about the R2 port and associated numbers. The CA must also determine if that FXS interface is free and whether the call is allowed. Note that the call routing capability of the CA not only determines that R2 is the destination end device, but it also informs which interface on R2 the call is for. In other words, neither R1 nor R2 have to know how to perform call routing tasks.

5. Upon successful call routing, availability, and restrictions checks, the CA notifies R2 of the incoming call for its FXS interface. R2 then sends an AC ringing voltage to the appropriate FXS port.

Figure 1-4 Call Setup Example for Centralized Call Control

Call Setup Example for Centralized Call Control

While the call is in progress, the end points (R1 and R2 in this example) collect and analyze the call statistics, such as packets sent and lost, and delay and jitter incurred (Theoretically, if the quality of the call is unacceptable, the CA is notified, and the CA instructs both parties to terminate the call.) If either phone hangs up, the gateway it is connected to (R1 or R2) notifies the CA of this event. The CA instructs both parties that call termination procedures must be performed and call resources must be released.

In the centralized call control model, the end points are not responsible for call control functions; therefore, they are simpler devices to build, configure, and maintain. On the other hand, the CA is a critical component within the centralized model and, to avoid a single point of failure, it requires deployment of fault-tolerance technologies. It is easier to manage a centralized model than to manage the distributed model, because only the CAs need to be configured and maintained. Implementing new services, features, and policies is also easier in the centralized model.

Next post:

Previous post: