Introducing Cisco Unified Communications Manager Express

Unified CM Express is a router-based call agent that scales up to 240 phones, depending on platform capacity. The system extends the benefits of Unified Communications to small businesses.

Unified CM Express supports a wide range of TP Phone, system, and trunk features, as well as voice-mail integration with Unity, Unity Express, and third-party systems using H.323 or analog DTMF signaling. For a complete feature list, refer to the Unified Communications Manager Express 4.2 Data Sheets on cisco.com.

Unified CM Express runs on the ISR platforms, including the 2800 and 3800 series, and on the 3700 series Multiservice Access Routers. The appropriate IOS IP Voice feature set, along with IP Phone licenses and firmware, and flash and RAM appropriate for the install are required. The optional GUI files may be installed for simplified configuration and administration but are not required.

Unified CM Express supports all current-generation IP Phones.


Defining Ephone and Ephone-DN

An ephone is an Ethernet phone, and an ephone-dn is an Ethernet phone directory number. In CM Express, an ephone is a logical configuration and settings for a physical phone, and the ephone-dn is a destination number that can be assigned to multiple ephones.

An ephone-dn always has a primary directory number, and it may have a secondary one as well. When you create an ephone-dn, you can specify it as single line (the default) or dual line. A single line can terminate one call; a dual line can terminate two calls at the same time. This is necessary for call waiting, consultative transfer, and conferencing features to work. When you create an ephone-dn, the router automatically creates POTS dial peers to match. The following configuration creates a dual-line ephone-dn with a primary and secondary number. The number 20 in the configuration is the tag, which is simply a unique identifier:


There is a maximum number of ephone-dns that a given platform will support; this is controlled by the hardware capacity and by licensing. The max-dn command must be set to create ephone-dns; the default is zero. Be aware that the router immediately reserves memory for the number of dns you specify, whether they are created or not; you should configure only what you will actually need.

An ephone is the logical configuration of a physical phone. Each ephone is given a tag to uniquely identify it. The MAC address of the phone ties it to the ephone configuration. CM Express will detect all phone models except the 7914 sidecar, which must be specified manually. Each different model of IP Phone has a different number of buttons, to which various functions can be applied; the top button is always numbered " 1 , " with the others following in numerical order. The button command allows you to specify which button does what. The following configuration creates a basic ephone for a 7960 with a 7914 sidecar; the button 1:20 command assigns button 1 the dn (5309) assigned to ephone-dn 20 from the previous example:


Types of ephone-dns

Six types of ephone-dns are configurable in CM Express:

• Single line: This ephone-dn creates a single virtual port. Although you can specify a secondary number, the phone can terminate only one call at a time, so it cannot support call waiting. It should be used when there is one phone button for each PSTN line that comes into the system. It is useful for things like paging, intercom, call-park slots, MoH feeds, and MWI.

• Dual line: The dual-line ephone-dn can support two call terminations at the same time and can have a primary and a secondary number. It should be used when a single button supports call features like call waiting, transfer, and conferencing. It should not be used for lines dedicated to intercom, paging, MoH feeds, MWI, or call park. It can be used in combination with single-line ephone-dns on the same phone.

• Dual number: This ephone-dn has a primary and secondary number, making it possible to dial two separate numbers to reach the phone. It can be either a single- or dual-line ephone-dn; it should be used when you want to have two numbers for the same button without using more than one ephone-dn.

• Shared ephone-dn: The same ephone-dn and number appears on two separate phones as a shared line, meaning that either phone can use the line, but once in use the other cannot then make calls on that line. The line will ring on all phones that share the ephone-dn, but only one can pick up. If the call is placed on hold, any one of the other phones sharing the line can pick it up.

• Multiple ephone-dns on one or more ephones: This configuration allows multiple calls to the same extension to be handled simultaneously on a single phone; for example, using three dual-line ephone-dns with the same number will terminate six calls on the phone. By using multiple ephone-dns on multiple phones, all the phones can answer the same number. This is not a shared line because the phones will ring in succession, and a call on hold can be answered only by the phone that placed it on hold. Controlling the hunting behavior (the order in which buttons or phones ring) is done with the preference and huntstop commands, as explained in the "Hunting Configuration" section that follows.
  

• Overlay ephone-dn: An overlay consists of two or more ephone-dns (up to 25) applied to the same button; all these ephone-dns must be either single or dual line. (You can't mix the types.) The call coverage is similar to a shared-line setup, except that a call to the number on one phone does not block the use of the same number on another phone. You can overlay up to 10 lines on a single button and then configure the same overlay set on 10 phones, with the result that all 10 phones could answer calls to the same number. The button command with the overlay separator creates the overlay set. The overlay separator can be o, which designates an overlay set without call waiting, or c, which designates call waiting. The command button lo30,31>32,33,34,35 c o n f j g u r e s ephone-dns 30, 31, 32, 33, 34, and 35 on button 1 without call waiting.

Voice over IP (VoIP)

Quality of Service

Quality of service (QoS) is possibly the single most important feature to deploy to ensure a successful VoIP system. This section defines and describes why QoS is needed and explains how to configure and deploy a QoS solution using both the Modular QoS Command Line (MQC) and AutoQoS.


QoS Definition

QoS is defined as
The ability of the network to provide better or "special" service to a set of users and applications at the expense of other users and applications.

Voice and video traffic is very sensitive to delayed packets, lost packets, and variable delay (jitter). The effects of these problems manifest as choppy audio, missing sounds, echo, or unacceptably long pauses in the conversation that cause overlap, or one talker interrupting the other. QoS configurations provide bandwidth guar antees while minimizing delay and jitter for priority traffic like VoIP. They do so not by creating additional bandwidth, but by controlling how the available bandwidth is used by the different applications and protocols on the network. In effect, this often means that data applications and protocols are restricted from accessing bandwidth when VoIP traffic needs it. This does not have much of an impact on the data traffic, however, because it is generally not as delay or drop-sensitive as VoIP traffic.

The areas that QoS can address to improve and guarantee voice quality are the following:

• Bandwidth

• Delay (including delay variation or jitter)

• Packet loss

Bandwidth

A VoIP call follows a single path from end to end. That path may include a variety of LAN and WAN links. The slowest link represents the available bandwidth for the entire path—often referred to as a bottleneck because of the congestion the slow link can cause.

If congestion is occurring, there are several ways to fix the problem:

• Increase the bandwidth: If bandwidth is unlimited, congestion cannot occur. Realistically, however, increasing bandwidth is costly and is usually unnecessary if QoS is applied instead.
• Queuing: QoS employs advanced queuing strategies, which classify different traffic types and organize the classes into queues that are emptied in order of priority. The queuing strategies commonly used in Cisco Unified Communications include the following:

• Weighted fair queuing (WFQ): WFQ dynamically assigns bandwidth to traffic flows as they arrive at the router interface. No configuration is necessary; the strategy is enabled by default on router links of Tl speed and below. This strategy is not appropriate for VoIP because it does not provide a bandwidth guarantee for the voice traffic, but instead allocates bandwidth fairly based on flow sizes (hence the name). VoIP needs a Priority queue (PQ) that guarantees it the bandwidth it needs, at the expense of all other traffic.
  

• Class-based weighted fair queuing (CBWFQ): CBWFQ extends the WFQ algorithm to include user-defined classes for traffic. Instead of the router dynamically interpreting traffic flows and building queues for them, the admin classifies the traffic and assigns it to queues of configurable size and bandwidth allocation. There is still no priority queue, however, so CBWFQ is not appropriate for VoIP.

• Low-latency queuing (LLQ): LLQ extends the CBWFQ system with the addition of a PQ. The PQ is typically reserved for voice traffic, and if any packets show up in the PQ, all packets in the queue are immediately sent while packets of other traffic types are held in their respective queues. This is the preferred queuing method for VoIP networks.

Compression: Several strategies are available to make the data that needs to be sent smaller so that it consumes less bandwidth:

• Payload compression: By compacting the contents of a packet, the total size is somewhat reduced. This compression method does not affect the headers, which makes it appropriate for links that require the header to be readable to route the packet correctly (Frame Relay and ATM as examples).

• Link compression: On point-to-point links where the header information is not needed to route the packet, link compression may be used.

• Header compression: By specifying the use of compressed RTP (cRTP), the Layer 3 and 4 headers of a VoIP packet are dramatically reduced, from 40 to as little as 2 bytes. TCP header compression is also available for non-VoIP traffic using TCP transport.

Compression takes time and CPU resources, adding delay; this must be factored in to the decision of what strategies are appropriate for a given link.