Telecom Architectures: August 2009

Saturday, August 29, 2009

Voice Port-Tuning Commands

Voice port fine-tuning commands adjust timing, delay, impedance parameters, input gain, and output attenuation. Once these adjustments are made, you can fine-tune volume control, how the number pads are dialed, and how long a voice port will wait before hanging up a signal.

Concepts of Delay and Echo

The most challenging part of designing a VoIP network is the transmission of real-time traffic. Voice communication is sensitive to delays and echo. Speech patterns become awkward and indistinguishable if there is too much delay in the voice traffic. Minimize delay as much as you can to get the voice traffic as close to real time as possible. In today's voice trafficking, two different kinds of delay must be handled: fixed delay and variable delay. The various delay points are illustrated in Figure 1.

Figure 1: Voice Packet Delay

Echo is the reflection of voice traffic back to the source of that traffic. A certain amount of echo is acceptable and desirable because it assures the source that voice traffic has been generated and sent. Too much echo is disruptive because the speaker will not be able to discern between his voice and the echo.

Fixed delay is the amount of time the signal needs to transverse the medium, such as copper, fiber, or microwave. This time is fixed because the laws of physics dictate how fast the data signals will go on particular media. Acceptable levels for most users are below 150ms one-way per ITU G.114. Fixed delays are composed of CODEC delays, packetization delays, and serialization.

CODEC induced delay Compression/decompression of a voice packet from analog to digital format and vice versa. It ranges from 0.75ms to 30ms, depending on the CODEC used.
Packetization delay Time it takes the equipment to actually produce a data packet. Should be under 30ms.
Serialization Time it takes to clock a voice or data frame onto a network interface. Affected by the frame size and line speed.

Variable delays are synonymous with jitter and are caused by queuing variances during the transmission of a packet through the network. As the packets are transferred out of the queue, there can be a delay between voice packets that sounds like stuttering speech. QoS features can be used to alleviate the effects of jitter by prioritizing the voice traffic over other traffic. You can curb delay using several methods.

Queuing Time it takes for a packet to exit the output queue of the device that is routing the data. Measured from the time the data is generated into the input queue to when it is released by the output queue.
Network switching Delay across the public network such as a Frame Relay or ATM network.
De-jitter Voice traffic works best if there is a constant flow of packets. Jitter must be minimized to improve the quality of the conversation. De-jitter buffers are utilized on the receiving end to adjust the variable delays into a fixed delay.

The command that adjusts the Cisco de-jitter buffering is playout-delay. The playout-delay command was configured under the voice-port configuration mode before IOS release 12.1(5)T. Release 12.1(5)T and later implement the command under the dial-peer configuration mode. The following steps are used to configure playout delay:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port (Cisco 175x/1760 and MC3810)

Determine the mode in which the jitter buffer will operate for calls on this voice port.
- Adaptive Adjusts the jitter buffer size and amount of playout delay based on current network conditions. This is the default setting.
- Fixed Defines the jitter buffer size as fixed so that the playout delay does not adjust. A constant playout delay is added.
```
router(config-voiceport)# playout-delay mode {adaptive| fixed]
```

Tune the playout buffer to accommodate packet jitter caused by switches in the WAN:

router(config-voiceport)# playout-delay {nominal value| maximum value 
    | minimum {default | low | high}}

Fine-Tuning FXS/FXO Ports

Special parameters can be adjusted to fine-tune the ports, minimizing issues of delay and echo. In most cases, the default parameters for FXO/FXS ports will be sufficient, but special values can be set for the following parameters:

Input gain
Output attenuation
Echo-cancel coverage
Nonlinear processing
Initial digit timeouts
Interdigit timeouts
Timing other than timeouts

To change any of these parameters, follow these steps:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure:

router# (config)voice-port nm-module/vic-module/port-number

Specify the amount of receiver gain on the interface in decibels. Value can be (–6) to 14:
```
router(config-voiceport)# input gain value
```
Specify the amount of transmit attenuation on the interface in decibels. Value can be 0 to 14:
```
router(config-voiceport)# output attenuation value
```
Enable echo-cancellation for voice signals sent out of the interface and received back on the same interface. Excessive echo can cause disruption to normal conversation patterns.
```
router(config-voiceport)# echo-cancel enable
```
Adjust the size of the echo-cancel coverage time in milliseconds. Values are 16, 24, or 32:
```
router(config-voiceport)# echo-cancel coverage value
```
Enable "nonlinear" processing, which shuts off any signal if no speech is detected on the near end. This is used in conjunction with echo cancellation:
```
router(config-voiceport)# non-linear
```
Configure how long the system will wait for the first digit to be input by the user after an off-hook state is detected. This value can be anywhere between 0 and 120 seconds:
```
router(config-voiceport)# timeouts initial seconds
```
Configure how long the system will wait for subsequent digits after the initial digit is received. This value can be anywhere between 0 and 120 seconds:
```
router(config-voiceport)# timeouts interdigit seconds
```
Specify how long the digital signal lasts for DTMF digit signals. The range is from 50 to 100 milliseconds, with a default of 100 milliseconds:
```
router(config-voiceport)# timing digit milliseconds
```
Specify the delay between digit signals for DTMF digit signals. Range is from 50 to 100 milliseconds, the default being 100 milliseconds:
```
router(config-voiceport)# timing inter-digit milliseconds
```
Configure the length of pulse signal. This command is for FXO ports only using pulse signals. The range is 10 to 20 milliseconds and the default is 20 milliseconds:
```
router(config-voiceport)# timing pulse-digit milliseconds
```
Configure length of delay between digit signals. This command is for FXO ports only using pulse signals. The range is from 100 to 1000 milliseconds and the default is 500 milliseconds:
```
router(config-voiceport)# timing pulse-inter-digit milliseconds
```

Fine-Tuning E&M Ports

E&M ports may require fine-tuning. The following steps are used to fine-tune E&M ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure:

router# (config)voice-port nm-module/vic-module/port-number

Specify the amount of receiver gain on the interface in decibels. Value can be (–6) to 14:
```
router# (config-voiceport)input gain value
```
Specify the amount of transmit attenuation on the interface in decibels. Value can be 0 to 14:
```
router# (config-voiceport)output attenuation value
```
Enable echo-cancellation for voice signals sent out of the interface and received back on the same interface.
```
router# (config-voiceport)echo-cancel enable
```
Adjust the size of the echo-cancel coverage in milliseconds. Values are 16, 24, or 32:
```
router# (config-voiceport)echo-cancel coverage value
```
Enable nonlinear processing, which shuts off any signal if no speech is detected on the near end. This is used in conjunction with echo cancellation:
```
router# (config-voiceport)non-linear
```
Configure how long the system will wait for the first digit to be input by the user after an off-hook state is detected. This value can be anywhere between 0 and 120 seconds:
```
router# (config-voiceport)timeouts initial seconds
```
Configure how long the system will wait for subsequent digits after the initial digit is received. This value can be anywhere between 0 and 120 seconds:
```
router# (config-voiceport)timeouts interdigit seconds
```
Specify how long the digit signal will last for DTMF digit signals. The range is from 50 to 100 milliseconds:
```
router# (config-voiceport)timing digit milliseconds
```
Specify the delay between digit signals for DTMF digit signals. The range is from 50 to 500 milliseconds:
```
router#(config-voiceport)timing inter-digit milliseconds
```
Specify the pulse-dialing rate. This is used for pulse dialing only. The range is from 10 to 20 pulses per second:
```
router# (config-voiceport)timing pulse pulse-per-second
```
Configure the delay between digit signals. This is used for pulse dialing only. The range is from 100 to 1000 milliseconds:
```
router# (config-voiceport)timing pulse-inter-digit milliseconds
```
Configure the delay signal time for delay dial signaling. The range is from 100 to 5000 milliseconds:
```
router#(config-voiceport)timing delay-duration milliseconds
```
Configure the minimum time for outgoing seizure to out-dial address. The range is from 20 to 2000 milliseconds:
```
router# (config-voiceport)timing delay-duration milliseconds
```
Specify the time between generations of "wink-like" pulses. The range is from 0 to 5000 milliseconds:
```
router# (config-voiceport)timing delay-pulse min-delay milliseconds
```
Specify the minimum amount of time between the off-hook signal and the call being completely cleared. The range is from 200 to 2000 milliseconds:
```
router# (config-voiceport)timing clear-wait milliseconds
```
Specify the delay signal time for delay dial signaling. The range is from 100 to 5000 milliseconds:
```
router(config-voiceport)timing delay-duration milliseconds
```
Configure the maximum wink-wait duration. The range is from 100 to 400 milliseconds:
```
router(config-voiceport)# timing wink-duration milliseconds
```
Configure the maximum wink-wait duration for wink-start signal. The range is from 100 to 5000 milliseconds:
```
router(config-voiceport)# timing wink-wait milliseconds
```

Some added features always need to be adjusted for the DID ports. Contrary to the default settings of the FXO/FXS ports, in most cases DID ports require fine-tuning adjustments. Follow these steps to fine-tune DID ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure:

router(config)# voice-port nm-module/vic-module/port-number

This command sets the maximum time to wait for wink signaling after an outgoing seizure is sent. This is optional for wink-start ports only:
```
router(config-voiceport)# timing wait-wink milliseconds
```
This command sets the maximum time to wait before sending wink signals after an incoming seizure is detected. This is optional for wink-start ports only:
```
router(config-voiceport)# timing wink-wait milliseconds
```
This command sets the duration of a wink-start signal. This is optional for wink-start ports only:
```
router(config-voiceport)# timing wink-duration milliseconds
```
This command sets the duration of the delay signal. This is optional for delay dial ports only:
```
router(config-voiceport)# timing delay-duration milliseconds
```
This command sets the delay interval after an incoming seizure is detected. This is optional for delay dial ports only:
```
router(config-voiceport)# timing delay-start milliseconds
```

Wednesday, August 26, 2009

Configuring Voice Ports

We have now discussed the basic hardware installation for VNMs and VICs. The next step is to configure the cards on the Cisco router IOS. Voice card configuration is covered in the following sections. Some basic configuration parameters must be set in order for a voice port to operate. To configure a voice port, complete the following steps.

Enter Privileged Exec mode:
```
router> enable
```
Check the DSP voice channel activity with the following command:
```
router# show voice dsp
```
Enter Global Configuration mode:
```
router# configure terminal
```
Enter Voice Card Configuration mode. On the router, the slot must be 0:
```
router(config)# voice-card slot
```

Enter the CODEC type for the voice card:

router(config-voicecard)# CODEC {med | high}

This series of steps sets the CODEC compression technique, which is either high or medium complexity. High complexity can handle fewer calls per DSP. This is due to the higher CPU utilization required for high CODEC complexity operation. High and medium complexity CODECs:

High complexity Specifies two voice channels encoded in any of the following formats: G.711ulaw, G.711alaw, G.723.1 (r5.3), G.723.1 Annex A (r5.3), G.723.1 (r6.3), G.723.1 Annex A (r6.3), G.726 (r16), G.726 (r24), G.726 (r32), G.728, G.729, G.729 Annex B, and fax relay.
Medium (default) complexity Specifies four voice channels encoded in any of the following formats: G.711ulaw, G.711alaw, G.726 (r16), G.726 (r24), G.726 (r32), G.729 Annex A, G.729 Annex B with Annex A, and fax relay.

Configuring FXO or FXS Voice Ports

All these parameters have default settings, and FXS and FXO port default configuration values are adequate for most situations. Therefore, user intervention is rarely needed. The following settings are mandatory to any FXS/FXO port configuration:

Signal type
Call progress tone
Ring frequency
Ring number
Dial type (FXO only)
PLAR connection mode
Music threshold
Description
Voice activity detection (VAD)
Comfort noise

Follow these steps to complete a basic setup for all FXS/FXO voice ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global configuration mode:
```
router# configure terminal
```

Identify which port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port   (Cisco 175x/1760 and MC3810)

Select the appropriate signaling for the start of a call:

router(config-voiceport)# signal [loop-start|ground-start]

Select the appropriate country codes for call progression signaling. The default is northamerica:
```
router(config-voiceport)# cptone country-code
```
Configure the voice port connection mode type. If the connection will be to a PBX, use the tie-line option. If the connection will be for private line automatic ringdown (PLAR), use the plar option. If the connection will be for PLAR off-premises extension (OPX), use the plar-opx option.
```
router(config-voiceport)# connection {tie-line | plar | plar-opx} string
```
Assign the appropriate out-dialing dial type (FXO only):
```
router(config-voiceport# dial-type{dtmf | pulse}
```
Configure the frequency in Hertz of ringing for the system that is attached on a Cisco 1750, 2600, and 3600 series router (FXS only):
```
router(config-voiceport)# ring frequency [25| 50]
router(config-voiceport)# ring frequency [20| 30] 
```
Configure the maximum number of rings allowed before answering a call (FXO only):
```
router(config-voiceport)# ring number number
```
Specify an existing pattern for ring tone or define a new one (FXS only). Each pattern specifies a ring-pulse time and a ring-interval time:
```
router(config-voiceport)# ring cadence {[pattern01 | pattern02 … pattern12]
[define pulse interval]}
```
Specify the termination impedance, which needs to match the specifications of the PBX it is attaching to:
```
router(config-voiceport)# impedance [600c|600r|900c|complex1|complex2]
```
Configure the threshold in decibels for hold music:
```
router(config-voiceport)# music-threshold number
```
(Optional) Configure a text string to the configuration that describes the connection for this voice port:
```
router(config-voiceport)# description string
```
Configure background noise generation for the comfort of a user when there is no noise:
```
router(config-voiceport)# comfort-noise
```
(Optional) Enable voice activity detection:
```
router(config-voiceport)# vad
```

Configuring E&M Ports

E&M default settings are usually not sufficient to enable voice transmissions over IP. This is because E&M ports are designed to connect directly to a PBX and therefore must match the particular PBX's specifications. The following settings are mandatory to implement an E&M port:

Signal type
Call progress tone
Operation
Type
Impedance

The following commands complete a basic setup for all E&M voice ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify which port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port (Cisco 175x/1760 and MC3810)

Select the appropriate signaling for the interface:

router(config-voiceport)# signal [wink-start|immediate|delay-dial]

Select the appropriate country codes for call progression signaling. The default is us. The northamerica keyword is for the Cisco MC3810 multiservice concentrator for versions prior to Cisco IOS Release 12.0(4)T and for ISDN PRI:
```
router(config-voiceport)# cptone country code
```

Define cabling scheme operation:

router(config-voiceport)# operation [2-wire|4-wire]

Select the appropriate E&M interface type:

router(config-voiceport)# type [1|2|3|5]

Specify the termination impedance, which needs to match the specifications of the PBX the port is attaching to:
```
router(config-voiceport)# impedance [600c|600r|900c|complex1|complex2]
```

Some optional configurations for the E&M port are not required for operation. As with the FXS/FXO ports, the following configurations are used for optimization and usability:

Connection mode
Music threshold
Description
Comfort tone (VAD-activated only)

Use the following commands to adjust any of these optional configuration parameters for E&M ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify which port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port (Cisco 175x/1760 and MC3810)

Specify that the port configured for PLAR

router(config-voiceport)# connection plar string

Define the threshold in decibels for hold music:

router(config-voiceport)# music-threshold number

Specify a description field for port:

router(config-voiceport)# description string

Set comfort noise to generate background noise for the user when there is no sound on the line:
```
router(config-voiceport)# comfort-noise
```

Sunday, August 23, 2009

Quality of Service

Voice traffic and data traffic have different characteristics. Unlike data traffic, voice traffic occurs in real time and is delay-sensitive. Voice packets tend to be smaller than data packets. When voice and data networks are merged, it is important to deliver an acceptable QoS for the voice traffic.

Voice traffic must be prioritized to minimize delay and jitter. Delay is the amount of time between the original transmission of the voice information and the final processing by the receiving station. Jitter is the variation in the delay between successive voice packets. Packet loss due to network errors or congestion will impact jitter. QoS depends on the ability to control these two factors that impact voice quality.

QoS tools can be divided into three categories:

Classification Voice packets can be classified or marked with a specific priority to enhance QoS.
Queuing Use separate queues for voice and date to ensure consistency and QoS for voice.
Provisioning Circuits carrying voice traffic should be provisioned with enough bandwidth or capacity to minimize delay and jitter.

The increasing deployment of VoIP can be attributed to the improvements made in QoS. QoS is a set of ideas, procedures, practices, and numerous protocols that provide for reliable and efficient transportation across data networks.

What Is Quality of Service?

QoS is simply a set of tools to ensure that a minimum level of service will be provided to certain traffic. Many protocols and applications are not critically sensitive to network congestion. File Transfer Protocol (FTP), for example, has a rather large tolerance for network delay or bandwidth limitation.

Applications such as voice and video are particularly sensitive to network delay. If voice packets take too long to reach their destination, the resulting speech sounds choppy or distorted. QoS can be used to assure services to these applications. Critical business applications can also use QoS.

Applications for Quality of Service

When would a network engineer consider designing QoS into a network? Here are a few reasons to deploy QoS in a network topology:

To prioritize certain mission-critical applications in the network.
To maximize the use of the current network investment in infrastructure.
To provide better performance for delay-sensitive applications such as voice and video.
To respond to changes in network traffic flows.

When deploying QoS, analyze the traffic flowing through the bottleneck, determine the importance of each protocol and application, and determine a strategy to prioritize the access to the bandwidth. QoS allows control over bandwidth, latency, and jitter and minimizes packet loss within the network by prioritizing. Bandwidth is the measure of capacity on the network or a specific link. Latency is the delay of a packet traversing the network, and jitter is the change of latency over a given period of time.

Deploying certain types of QoS techniques can control these three parameters. QoS is not widely deployed within many networks. With the push for applications such as multicast, streaming multimedia, and VoIP, the need for QoS is more apparent, especially since these applications are susceptible to jitter and delay. Poor performance is immediately noticed by the end-user. However, QoS is not the magic solution to every congestion problem; it may very well be that upgrading the bandwidth of a congested link is the proper solution to the problem.

Levels of QoS

QoS can be divided into three different levels, also referred to as service models. These service models describe a set of end-to-end QoS capabilities. End-to-end QoS is the network's ability to provide a specific level of service to network traffic from one end of the network to the other. The three service levels are best-effort service, integrated service, and differentiated service.

Best-Effort Service

Best-effort service is when the network will make every possible attempt to deliver a packet to its destination. With best-effort service, there are no guarantees that the packet will ever reach its intended destination. An application can send data in any amount, whenever it needs to, without requesting permission or notifying the network.

Integrated Service

The integrated service model provides applications with a guaranteed level of service by negotiating network parameters end to end. Applications request the level of service necessary for them to operate properly and rely on the QoS mechanism to reserve the necessary network resources prior to the beginning of transmission. The application will not send traffic until it receives confirmation that the network can handle the load and provide the requested QoS end to end. To accomplish this task, the network uses a process called admission control.

Cisco IOS uses RSVP and intelligent queuing. RSVP is currently in the process of being standardized by the IETF in one of its working groups. Intelligent queuing includes technologies such as Weighted Fair Queuing and Weighted Random Early Detection (WRED).

RSVP works in conjunction with the routing protocols to determine the best path through the network that will provide the QoS required. RSVP routers create dynamic access lists to provide the QoS requested to ensure that packets are delivered at the prescribed minimum quality parameters.

Differentiated Service

Differentiated service includes a set of classification tools and queuing mechanisms to provide certain protocols or applications with a certain priority over other network traffic. Differentiated services rely on edge routers to perform the classification of the types of packets traversing a network. Network traffic can be classified by network address, protocols and ports, ingress interfaces, or whatever classification that can be accomplished through the use of a standard or extended access list.

Why QoS Is Essential in VOIP Networks

The challenge facing a converged infrastructure is to provide the efficiency of a packet-switched network with the reliability of a legacy network. This is the role that QoS fills.

QoS, through a variety of methods, gives reliability and availability to a converged infrastructure and still affords it the same benefits of efficient utilization of resources by providing the following:

Managed response times
Jitter (variation in delay) control
Prioritization of delay-sensitive traffic
Congestion management
Congestion avoidance
Support and enforcement of dedicated bandwidth requirements
Management and recovery of packet loss

With QoS, converged infrastructures can provide end users with a convenient, low-cost, scalable, and above all, reliable solution for the majority of their communications. Without QoS, a converged infrastructure would be comparable to anarchy, with little to no reliability, convenience, or scalability—to a level where a single FTP session could shut down your entire VoIP infrastructure.

Thursday, August 20, 2009

Installing VNMs and VICs

The types of router chassis described in this section demonstrate how VNMs, VICs, and additional voice port adapters are installed on the various platforms. We chose a sampling of Cisco routers to structure our discussion, but the concepts and processes are similar for all Cisco routers, with a few minor adjustments.

E-1/T-1 Voice Connectivity

Digital E-1 and T-1 connectivity allows Cisco series routers and switches to provide E-1 or T-1 voice connectivity to PBXs or to a CO. T-1 voice connections are available for various routers and switches, including, but not limited to Cisco 1700, 2600, 3600, 3700, MC3810, 7200, 7500, AS5300, AS5800, and Catalyst 4000 and 6000 series equipment.

The 1700, 2600, 3600, 7200, and 7500 series routers are capable of VoFR and VoIP. The MC3810 (now end of sale) supports VoFR, VoATM, and VoIP. The AS5300 is able to perform VoIP, VoHDLC, or VoFR functions.

The 7200, 7500 series, and AS5300 series are primarily used as tandem switch points from T-1 tie lines to PBXs and the PSTN to the internal IP network. An example of the use of tandem switch points is receiving a voice call on one VoIP interface and switching it back out another VoIP interface to its final destination. The 1700, 2600, and 3600 routers series can perform this function because support for voice T-1/E-1 interfaces with up to two T-1/E-1 circuits per card has been added. The T-1/E-1 enhanced voice port adapter is used in the 7200 and 7500 series routers and can support up to two T-1s per card. The AS5300 series access switch uses the T-1 carrier card that can support up to four T-1s.

The 7200, 7500, and AS5850 can terminate T-1s for voice traffic into the WAN and forward the signals and transmissions to the 1700, 2600, 3600, and AS5300 series routers for complete processing. The 7200 Series offers a four- or six-slot configuration, with interfaces including ATM, Synchronous Optical Network Technologies (SONET), ISDN BRI, ISDN PRI, T-1, E-1, T3, and E3. Its multi-service interchange (MIX) allows the 7200 to support digital voice as well as gateway functionality through the use of two different trunk interfaces, the high-capacity and medium-capacity T-1/E-1 trunk interface cards. The primary difference between the two cards is that the high-capacity card includes an on-board DSP card for compression. The 7200 Series can support up to 120 voice calls, depending on the module configuration used. This router also supports analog voice applications through the use of voice interface cards (VICs).

1700 Series Router Configurations

The 1700 series modular access routers are designed for small- to medium-sized businesses. The 1700 family has several chassis for different applications, but the two that were designed specifically for voice applications are the 1751 and the 1760. These two modular chassis use the Cisco IOS along with various VICs to support analog and digital voice traffic over the IP network.

Cisco 1751 Modular Access Router

The Cisco 1751 is a standalone chassis that can support up to three voice interface slots. It comes in two models: a base model suited primarily for data, but with an easy upgrade path to voice, and a multiservice model (identified with a V) that includes all features for immediate integration of data and voice. Both models include three slots for data/voice interface cards as well as a 10/100 Ethernet port, a console port, and an auxiliary port. The 1700 series VICs are interchangeable with the Cisco 2600 and 3600 series routers.

The Cisco 1751 includes one PVDM-256K-4 (one DSP) that supports one analog VIC. If two analog VICs or one or more digital ISDN VICs are used, additional DSPs are required. The Cisco 1751 has two DSP slots to support additional voice channels. A PVDM is required to support VICs on the Cisco 1750 and 1760 routers. These two chassis require PVDMs to be placed on the motherboard, unlike the Cisco 2600, 3600, and 3700 routers, which have DSP support on the VNMs.

The Cisco 1760 Modular Access Router

The Cisco 1760 has four slots for VICs, and is available in two models. The base model is suited for data networking, but can be upgraded to support voice. The multi-service model (identified with a V) includes all features for immediate integration of data and voice. Both models include four slots for data/voice interface cards and a 10/100 Ethernet port.

The Cisco 1760 includes one PVDM-256K-4 (one DSP) that supports one analog VIC. If two analog VICs or one or more digital ISDN VICs are used, additional DSPs are required. The Cisco 1760 has two DSP slots to support additional voice channels.

3600 and 3700 Series Router Configurations

Cisco's 3600 and 3700 series routers come in a variety of base configurations that differ in the amount and/or type of standard network interfaces (RJ-45 ports, serial ports, and ISDN ports) that are available. The Cisco3600 and 3700 are designed primarily for traditional and power branch office solutions.

The 3600 series router comes in three varieties: the 3620, which has two network module slots; the 3640, which has four network module slots; and the 3660, which is equipped with six network module slots. The 3640 is end of sale as of this writing.

The 3700 series router comes in two varieties: the 3725, which has three integrated WIC slots and two network module slots, and the 3745, which has three integrated WIC slots and four network module slots. Currently, the built-in WICs do not support VICs.

Most Cisco 1700 VICs can be used for the 3600 and 3700 series except that a VNM is required in these higher-end routers.

Note

For 3700 platforms, the minimum IOS release is IOS 12.2(8) T for all network modules and VICs.

7500 Series Router Configurations

The 7500 series high-end routers support voice, video, and data. The Cisco 7500 series includes the Cisco 7505, the Cisco 7507, and the Cisco 7513 with 5, 7, and 13 slots, respectively. Cisco 7500 adapters include the two-port T-1 and E-1 high-capacity enhanced digital voice port adapter, the two-port T-1 and E-1 moderate-capacity enhanced digital voice port adapter, and the one-port T-1 and E-1 enhanced digital voice port adapters.

AS5350 and 5850 Universal Gateway Configuration

The Cisco AS5350 and AS5850 universal gateways provide from 2 to 96 T-1s or E-1s to support data, voice, wireless, and fax services on any port. The AS5350 is only one rack unit high and supports 216 voice, dial, or universal ports. The AS5350 is mainly intended for ISPs and enterprises, whereas the Cisco AS5850 was designed for large service providers. The AS5850 is 14 rack units high and supports 2688 voice or universal ports. Both chassis support hot-swappable cards and fans to minimize service interruption. The AS5350 supports two-, four-, or eight-T-1/E-1 configurations; the AS5850 supports up to four 24-port T-1 cards for a total of 96 T-1s.

Note

The minimum IOS release for the Cisco AS5850 platform is IOS 12.2(1)XB for the 24-channel T-1 card.

Monday, August 17, 2009

Cisco VoIP Hardware and Software

Up to this point, we has been focused on the underlying technologies and concepts that are integral to VoIP. We will now turn our attention to Cisco-specific information. Cisco offers a variety of hardware and software solutions for implementing VoIP. Its routers and switches can be adapted to support voice communications, usually with the addition of voice modules and software in many cases.

Voice Modules and Cards

Routers and switches use voice modules to transform and transport voice traffic across the IP network. They use Voice Interface Cards (VICs) to provide connectivity to telephone equipment. Voice Network Modules (VNMs) and VICs are configured using Cisco IOS VoIP commands. Digital signal processors are used in various Cisco voice-enabled routers in order to convert analog voice signals to digital for transmission across an IP network and to convert back to analog once the packet has arrived at the destination router. DSPs can be found as modules inserted onto the motherboard, as on the 1700 series routers, or as slots built onto a VNM that is placed in the router.

Voice Network Modules

VNMs convert analog voice into a digital form for transmission over the IP network. At least one VNM is needed to enable the router to handle voice traffic. VNMs come in several different models for the 2600/3600 series routers. Figure 1 shows several models of VNMs available for the 26XX and 36XX routers.

Figure 1: Voice Network Modules

Only VICs are supported in the carriers with a V in the name. The NM-1V is a one-slot VNM. You can install one VIC in the NM-1V to gain up to two voice ports. The NM-1V/2V does not support WAN interface cards (WICs). The NM-2V is a two-slot version of the VNM. You can install up to two VICs in the NM-2V, providing up to four voice ports. The NM-HDV high-density VNM. This network module consists of five slots, one for the voice WIC (VWIC) and four for the packet voice DSP modules (PVDM). You can install one VWIC in the NM-HDV, providing up to two voice ports. The VNMs are the housings for the actual voice interface cards that provide the necessary functionality and connectivity to achieve voice communications.

Voice Interface Cards

Voice Interface Cards (VICs) are inserted in the VNM to provide the necessary interface and support for the desired type of voice configuration (FXS, FXO, or E&M). Figure 2 shows several VICs to give you an idea of what is available; this is not an exhaustive list, as Cisco continues to expand in this area.

Figure 2: Voice Interface Cards

One thing we would caution you about is that physically and outwardly, there is no difference between the FXS and FXO connectors; it can be easy to plug a telephone into what you think is an FXS port, but is actually an FXO port. Ensure that you are using the proper port type by checking the color and labels before attempting to connect.

VIC-2E/M The two-port E&M module VIC-2E/M connects an IP network directly to a PBX system. It can be configured for special settings associated with tie-line ports on most PBXs. E&M ports are color-coded brown.
VIC-2FXS The two-port FXS module VIC-2FXS connects to endpoint equipment such as a telephone, keypad, or fax. These ports provide ringing voltage, dial tone, and other endpoint specific functionality. FXS ports are color-coded gray.
VIC-2FXO The two-port FXO module VIC-2FXO connects to a PBX or PSTN. FXO ports are color-coded pink. Other types of FXO cards for use outside North America are capable of providing switching and signaling techniques used in other geographic regions such as VIC-2FXO-EU for use in Europe.
VWIC-2MFT-T-1 The two-port VWIC multiflex trunk interface card is a two-port card that can be used for voice, data, and integrated voice/data applications. The multiflex VWIC can support data-only applications as a WAN interface on the Cisco 1700, 2600, or 3600. It can also integrate voice and data with the Drop and Insert multiplexer functionality and/or configured to support packetized voice (VoIP) when in the digital T-1/E-1 network module.
Two-Port ISDN BRI Card Two two-port ISDN BRI VICs are available for the Cisco 1700, 2600, and Cisco 3600 series routers. These cards are available as ISDN BRI S/T or NT interfaces for terminating to an ISDN network.
Four-Port Analog DID/FXS VICs Two direct inward dial interface cards are available. One card is a two-port RJ-11 that supports DID only. These cards are used for providing DID service to extensions on a PBX so that users may transparently dial directly to extensions.

Saturday, August 15, 2009

Skinny Station Protocol

Skinny Station Protocol SSP is a Cisco proprietary communications protocol based on the industry standard Simple Gateway Control Protocol. Skinny Station Protocol enables communication between first generation IP telephone handsets/Gateways and CallManager servers. Products that support Skinny Station Protocol include the DT-24 and DE-30 gateways, the Catalyst 6000 8-Port T-1/E-1 voice service modules, as well as the Catalyst 6000 24 port FXS module. Skinny Station Protocol relies on the CallManager server to relay configuration and control information. It is built on TCP/IP and utilizes TCP ports 2000-2002.

Thursday, August 13, 2009

Media Gateway Control Protocol

MGCP (RFC 2705) is a relatively new protocol and as such, it is not as widely deployed as its H.323 and SIP predecessors. MGCP offers many key benefits and is growing in popularity, especially in Cisco CallManager deployments.

MGCP is a merger of the Simple Gateway Control Protocol (SGCP) and the Internet Protocol Device Control (IPDC). SGCP calls for a simplified design and a centralized intelligent call control. IPDC was designed to provide a medium to bridge VoIP networks and traditional telephony networks. MGCP is a media control protocol, suited for large-scale IP telephony deployment, and supports VoIP only.

MGCP incorporates media gateway controllers (MGCs) or call agents to perform all call connection and call control within an MGCP network. These MGCs signal to, and control, media gateways (MGs) to connect and control VoIP calls. All the information for making and completing a VoIP call is held in the MG.

MGs have very little intelligence and receive all their marching orders from the MGC; they cannot function without a controlling MGC. In a Cisco CallManager deployment, the MGC is often a CallManager server and the media gateway is a router used to connect to a dissimilar network. Examples of gateway applications are:

Trunking gateways Interfaces between the telephone network and a VoIP network. Manage a large number of digital circuits.
Voice over ATM gateways Interface to an ATM network.
Residential gateways Provide a traditional analog (RJ11) interface to a VoIP network. Examples of residential gateways include cable modem/cable set-top boxes, and broadband wireless devices.
Access gateways Provide a traditional analog (RJ11) or digital PBX interface to a VoIP network. Examples of access gateways include small-scale VoIP gateways.
Business gateways Provide a traditional digital PBX interface or an integrated "soft PBX" interface to a VoIP network.
Network access servers Can attach a modem to a telephone circuit and provide data access to the Internet. We expect that in the future, the same gateways will combine VoIP services and network access services.

When a gateway device detects that an end-user phone connection goes off-hook, it is directed by the MGC to provide a dial tone to the phone and receives the dialed digits and forwards them to the MGC for call processing.

MGCP Connections

In an MGCP connection, there are two basic types of logical devices: endpoints and connections. Endpoints are the physical, or logical interfaces that either initiate or terminate a VoIP connection. Endpoints are most often analog or digital ports in routers acting as gateway devices or digital interfaces into a PBX system.

Connections are temporary logical flows that are created to establish, maintain, and terminate a VoIP call. Once the call is complete, the connection is torn down and the resources that were allocated for that connection can be reused to support another connection. A one-to-one connection is really a point-to-point connection; a single endpoint signals to another single endpoint for the purposes of completing a single VoIP connection. Multipoint calls are used for conferencing and broadcast to multiple endpoints simultaneously.

MGCs manage connections in an MGCP network using the Session Description Protocol. SDP uses ASCII commands over IP/UDP to perform all call management functions. A series of eight connection messages is used by the MGC in order to control endpoints.

CreateConnection
ModifyConnection
DeleteConnection
NotificationRequest
Notify
AuditEndpoint
AuditConnection
RestartInProgress

Monday, August 10, 2009

Session Initiation Protocol

SIP (RFC2543) is a simple signaling protocol for Internet conferencing and telephony. Based on Simple Mail Transfer Protocol (SMTP) and HyperText Transfer Protocol (HTTP), SIP was developed by the Internet Engineering Task Force's (IETF's) Multiparty Multimedia Session Control (MMUSIC) working group. SIP specifies procedures for telephony and multimedia conferencing over the Internet. SIP is an application-layer protocol independent of lower layer protocols (TCP, UDP, ATM, X.25).

SIP is based on a client/server architecture in which the client initiates the calls. By conforming to these existing text-based Internet standards (SMTP and HTTP), troubleshooting and network debugging are facilitated. The protocol can be read without decoding the binary ASN.1 payload required in non-text-based protocols, such as H.323. SIP is widely supported and is not dependent on a single vendor's equipment or implementation.

SIP is a newer protocol than H.323 and does not have maturity and industry support at this time. However, because of its simplicity, scalability, modularity, and ease with which it integrates with other applications, this protocol is attractive for use in packetized voice architectures. Some of the key features that SIP offers are:

Address resolution, name mapping, and call redirection
Dynamic discovery of endpoint media capabilities using the Session Description Protocol (SDP)
Dynamic discovery of endpoint availability
Session origination and management between host and endpoints

Session Initiation Protocol Components

The SIP system contains two components: user agents and network servers. A user agent (UA) is an endpoint, which makes and receives SIP calls.

User agent client (UAC) Initiates SIP requests.
User agent server (UAS) Receives the requests from the UAC and returns responses for the user.

SIP clients can include:

IP telephones (UACs or UASs)
Gateways to provide conferencing and translation

There are three kinds of SIP servers:

Proxy server Determines the server to which the request should be forwarded. Request can actually transit many SIP servers to its destination. Responses return in reverse order.
Redirect server Notifies the calling party of the actual location of destination.
Registrar server Provides registration services for UACs at their current locations. Often deployed with proxy and redirect servers.

Figure 1 illustrates the interaction between SIP components.

Figure 1: SIP Components

Session Initiation Protocol Messages

SIP works on a simple premise of client/server operation. Clients or endpoints are identified by unique addresses. These addresses come in a format very similar to that of an e-mail address: user@domain.com.

SIP addresses are URLs: user@host
User: name, telephone (E-164 address), number
Host: domain, numeric network (IP) address

The users or clients register with SIP servers to provide location contact information.

SIP uses messages for call connection and control. There are two types of SIP messages: requests and responses. SIP messages are defined as follows:

Invite Used to invite a user to a call. Header fields contain:
- Addresses of the caller and the person being called
- Subject of the call
- Call priority
- Call routing requests
- Caller preferences for the user location
- Desired features of the response
Bye Used to terminate a connection between two users.
Register Conveys location information to a SIP server, allowing a user to tell the server how to map an incoming address into an outgoing address that will reach the user.
ACK Confirms reliable message exchanges.
Cancel Cancels impending requests.
Options Solicits information about the capabilities of the end being called, such as the difference between a plain old telephone handset and a fully-featured multimedia phone.

Saturday, August 8, 2009

H.323 Call Setup

After discovery, registration, and call placement are complete, the H.323 call moves into the call setup stage. At this stage, the gateways are communicating directly to set up the connection. An alternative is gatekeeper-routed call signaling, where all call setup messages traverse the gatekeeper. Figure 1 helps us conceptualize this process.

Figure 1: H.323 Call Setup

The call setup is based on the ITU-Q.931 (H.225 is a subset of Q.931), which provides a means to establish, maintain, and terminate network connections across an ISDN. This process comprises six distinct phases, as shown in Figure 1.

Gateway X sends an H.225 call-signaling setup message to Gateway Y to request a connection.
Gateway Y sends an H.225 message back to Gateway X, advising that it may proceed with the call.
Gateway Y sends an RAS message (ARQ) on the RAS channel to the gatekeeper to request permission to accept the call.
Gatekeeper confirms that the call can be accepted by sending a message (ACF) back to Gateway Y.
Gateway Y sends an H.225 message to Gateway X, alerting that the connection has been established.
Gateway Y sends an H.225 message to Gateway X, confirming call connection to establish the call.

Logical Channel Setup

After call setup, all communications travel over logical channels. The H.245 manages these logical channels. Multiple logical channels of varying types (video, audio, and data) are allowed for a single call.

The H.245 Logical Channel Signaling Entity (LCSE) opens a logical channel for each media stream. Channels may be unidirectional or bi-directional. Figure 2 helps us visualize how the H.323 utilizes virtual channels.

Figure 2: Media Channel Setup

The H.245 control channel is established between Gateway X and Gateway Y. Gateway X uses H.245 to identify its capabilities via a Terminal Capability Set (TCS) message to Gateway Y. The media channel setup flow is as follows:

Gateway X exchanges its capabilities with Gateway Y by sending an H.245 TCS message.
Gateway Y acknowledges Gateway X's capabilities by sending an H.245 TCS Acknowledge message.
Gateway Y exchanges its capabilities with Gateway X by sending an H.245 TCS message.
Gateway X acknowledges Gateway Y's capabilities by sending an H.245 TCS Acknowledge message.
Gateway X opens a media channel with Gateway Y by sending an H.245 Open Logical Channel (OLC) message and includes the transport address of the RTCP channel.
Gateway Y acknowledges the establishment of the logical channel with Gateway X by sending an H.245 OLC Acknowledge message, including:
- RTP transport addresses (used to send the RTP media stream) allocated by Gateway Y
- RTCP address previously received from Gateway X
Gateway Y opens a media channel with Gateway X by sending an H.245 OLC message and includes the transport address of the RTCP channel.
Gateway X acknowledges the establishment of the logical channel with Gateway Y by sending an H.245 OLC Acknowledge message and includes:
- RTP transport addresses (used to send the RTP media stream) allocated by Gateway X
- RTCP address previously received from Gateway Y

Figure 3 highlights this process:

Figure 3: Media Channel Setup Call Flow

Media Stream and Media Control Flows

RTP media streams are transported over UDP ports 16384 through 16384 + 4x (where x is the number of voice ports on the gateways). For example, a Cisco 3620 router with four E&M ports would use UDP ports 16384–16400 for RTP flows.

RTCP manages media streams in the H.323 call flow by supporting QoS feedback from receivers. The source may use this information to adapt encoding or buffering schemes. RTCP uses a dedicated logical channel for each RTP media stream. Figure 4 illustrates the steps in this stage of the H.323 call flow.

In the example shown in Figure 9.34, four actions are occurring:

Gateway X sends the RTP encapsulated media stream to Gateway Y.
Gateway Y sends the RTP encapsulated media stream back to Gateway X.
Gateway X sends the RTCP messages to Gateway Y.
Gateway Y sends the RTCP messages back to Gateway X.

Endpoints may seek changes in the amount of bandwidth initially requested and confirmed. The gatekeeper must be asked for bandwidth increases or decreases. Endpoints must comply with gatekeeper responses and requests. The bandwidth change flow is diagramed in Figure 5. This process consists of six stages:

Figure 5: Bandwidth Change Request.

The initiating gateway sends a bandwidth request (BRQ) to the gatekeeper to request the desired bandwidth.
The gatekeeper responds with a bandwidth confirmation (BCF) message for the requested bandwidth.
A logical channel is established between the two gateways with the specified bandwidth.
A BRQ is sent from the remote router to the gatekeeper to change the bandwidth of the connection.
The gatekeeper responds to the gateway with a BCF to confirm the new bandwidth.
The logical channel is re-established with the new bandwidth.

Call Termination

Call termination stops the media streams and closes the logical channels, and may be requested by any endpoint or gatekeeper. It ends the H.245 session, releases H.225/Q.931 connections, and provides disconnect confirmation to the gatekeeper via RAS. Figure 6 shows call termination flow and is described as follows:

Figure 6: Call Termination (H.245/H.225/Q.931/RAS)

Gateway Y initiates call termination by sending an H.245 End Session Command (ESC) message to Gateway X.
Gateway X releases the call endpoint and confirms with an H.245 ESC message to Gateway Y.
Gateway Y completes the call release by sending an H.245 Release Complete message to Gateway X.
Gateway X and Gateway Y disengage with the gatekeeper by sending a RAS DRQ message.
Gatekeeper disengages and confirms by sending DCF messages to both Gateway X and Gateway Y.

H.323 Endpoint-to-Endpoint Signaling

Assuming that endpoints (clients) know each other's IP addresses, the H.323 signaling is shown in Figure 7.

Figure 8: H.323 Endpoint-to-Endpoint Signaling

Thursday, August 6, 2009

H.323 Discovery and Registration | Cisco VOIP

The five stages of an H.323 call and details of each of these connections are listed.

Discovery and registration
Call setup
Call-signaling flows
Media stream and media control flows
Call termination

A lot happens within each of these stages; from the time the call is requested to the time it is terminated.

Device Discovery and Registration

The gatekeeper initiates a "discovery" process to determine the gatekeeper with which the endpoint must communicate, as shown in Figure 1. This discovery can be either a statically configured address or through multicast traffic. Once this is determined, the endpoint or gateway registers with the discovered gatekeeper.

Figure 1: H.323 Gatekeeper Call Control/Signaling: Discovery and Registration

Registration is used by the endpoints to identify a zone with which they can be associated (a zone is a collection of H.323 components managed by a single gatekeeper). H.323 can then inform the gatekeeper of the zones' transport address and alias address.

In Figure 1:

A H.323 gateway (or terminal) sends a request to register (RRQ) message using H.225 RAS on the RAS channel to the gatekeeper.
The gatekeeper confirms or denies the registration by sending a registration confirmation (RCF) or a "Reject registration" message back to the gateway.

Intra-zone Call Placement

Once the registration and discovery process is complete, we can place a call. Figure 2 shows Gateway X placing a intra-zone call to a terminal connected to Gateway Y, Gateway X sends an admission request (ARQ) message to the gatekeeper requesting permission to place a call to a phone number serviced by Gateway Y.

Figure 2: H.323 Gatekeeper Call Control/Signaling: Call Placement (Intra-zone)

In Figure 2:

Gateway X sends an ARQ message using H.225 RAS to the gatekeeper.
Gatekeeper requests direct call signaling by sending an admission confirmation (ACF) to Gateway X.
H.323 call setup is initiated.

Inter-zone Call Placement

The process of placing an inter-zone call is somewhat more complicated and resource–intensive, as the network is larger and divided into multiple zones. In Figure 3, Gatekeeper A controls Zone A, and Gatekeeper B controls Zone B. Gateway X (or Terminal X) is registered with Gatekeeper A, and Gateway Y is registered with Gatekeeper B.

Figure 3: H.323 Gatekeeper Call Control/Signaling: Call Placement (Inter-zone)

To place a call to Gateway Y terminal, Gateway X first sends an ARQ message to the gatekeeper requesting permission to make the call. Since Gateway Y is not registered with the gatekeeper in Zone A, we assume that the gateways (terminals) are already registered.

Figure 3 shows five distinct phases in an inter-zone call placement.

ARQ Gateway X requests a connection to Gateway Y from its local gatekeeper.
Location request (LRQ) Local gatekeeper for Gateway X does not know the IP address of Gateway Y and is requesting the address from Gateway Y's local gatekeeper.
Location confirm (LCF) Gateway Y's local gatekeeper responds to Gateway X's local gatekeeper with the IP address of Gateway Y.
ACF The local gatekeeper responds to Gateway X's request and provides the remote IP address of Gateway Y.
Call established The H.323 call is established between Gateway X and Gateway Y.