Configuring CM Express to Support Endpoints

In this section we explore three methods of configuring endpoints on a CM Express system: configuring optional settings, rebooting IP Phones, and troubleshooting and verifying the configuration.


Providing Firmware

IP Phone firmware files ship with the CM Express software or can be downloaded from cisco.com. For the router to serve the firmware to the phones, the tftp-server fiashifilename command is used. You must enter this command for every firmware file needed. Some phones require more than one file to be loaded—for example, the 791 IG requires six separate files.

Telephony Service Configuration

Manual setup of the CM Express system is done using the CLI. From the global config, the command telephony-service enables config-telephony mode. This prompt is where your first steps of defining the max-ephones and max-ephone-dn settings (described earlier) would take place.

Phone Firmware Loads

The firmware files that were copied into Flash and made available to the phones via TFTP must be associated with the phones; this is done using the load model firmware-file command. Filenames are case sensitive, and the file extension should not be included in the command. (Tip: Use the Cut-and-Paste function of your terminal client to prevent annoying typos!) For Java-based phones, it is only necessary to load the TERMnn.x-y-x-w.loads or SCCPnn.x-y-x-w.loads firmware filename (without the .loads extension), although the other files must be available via TFTP.

Defining Source IP and Port

The CM Express software uses SCCP to communicate with the phones. (SIP signaling is also possible but is not covered in this document.) The command ip source-address ip-address [port port] defines the IP address of the router that will be used as the source for SCCP messages. The default SCCP TCP port is 2000 and does not normally need to be changed, but the option is available if the situation should require it.

Autoregistration

The autoregistration function is enabled by default; this allows a phone to be discovered and registered to an available ephone slot (provided the ip source-address command is configured). The command no auto-reg-ephone prevents a phone from registering unless its MAC address is explicitly configured already. CM Express records the MACs of all phones that attempt to register but are blocked by autoregistration being disabled; use the show ephone
attempted-registrations command to see the list and the clear telephony-service ephone attempted-registrations command to see and clear the list.


Location Customization

CM Express supports phone display language, time display, and ring cadence localization. The user-locale languagecode command will change the language displayed on all 7940 and 7960 phones; the 7920 is not affected and must be configured with its individual language capability local to the phone. The network-locale language-code command will change the call progress tones and ring cadence (again with the exception of the 7920).

Following are language codes supported for User Locale:

• DE: Germany
• DK: Denmark
• ES: Spain
• FR: France
• IT: Italy
• NL: Netherlands
• NO: Norway
• PT: Portugal
• RU: Russian Federation
• SE: Sweden
• US: United States (default)
• JA:Japan

Following are language codes supported for Network Locale:

• AT: Austria
• CA: Canada
• CH: Switzerland
• DE: Germany
• DK: Denmark
• ES: Spain
• FR: France
• GB: United Kingdom
• IT: Italy
• JA: Japan
• NL: Netherlands
• NO: Norway
• PT: Portugal
• RU: Russian Federation
• SE: Sweden
• US: United States (default)

To change the time display format, use the time-format {12 I 24} command. To change the date format, use date-format {mm-dd-yy I dd-mm-yy I yy-dd-mm I yy-mm-dd}.


To change the time display format, use the time-format {12 I 24} command. To change the date format, use date-format {mm-dd-yy I dd-mm-yy I yy-dd-mm I yy-mm-dd}.


Rebooting IP Phones

There are two commands available to reboot IP Phones, each with a slightly different behavior. The reset command causes a hard reboot of the phone and invokes DHCP and TFTP. Use reset when changing firmware, user/network locales, or URLs. The reset command can be executed to reset a single phone at the config-ephone prompt, or at the config-telephony prompt to reset one or more phones. The full syntax is reset {all [time-interval] I cancel I mac-address Isequence-all}. The command options work as follows:

There are two commands available to reboot IP Phones, each with a slightly different behavior. The reset command causes a hard reboot of the phone and invokes DHCP and TFTP. Use reset when changing firmware, user/network locales, or URLs. The reset command can be executed to reset a single phone at the config-ephone prompt, or at the config-telephony prompt to reset one or more phones. The full syntax is reset {all [time-interval] I cancel I mac-address Isequence-all}. The command options work as follows:

• all: Resets all phones.
• time-interval: Changes the interval between the router resetting the phones in sequence (default = 15sec).
• cancel: Stops the reset process.
• mac-address: Resets a specific phone.
• sequence-all: The router waits for one phone to reset and reregister before resetting the next phone to prevent the phones from overloading the TFTP server. This can be time consuming; the router waits 4 minutes as a timeout before resetting the next phone, whether or not the reregistration of the previous has finished.

The restart command causes a soft (warm) reboot and is useful for minor configuration changes, such as buttons, lines, and speed-dial modifications. This command can also be executed either at the config-ephone prompt or at the configtelephony prompt. The syntax is restart {all [time-interval] I mac-address}, with the command parameters the same as
the reset command.


Troubleshooting Endpoints

Check the following when troubleshooting:

• Verify IP addressing: Use the Settings button on the phone to check the configuration of the IP phone. The TFTP Server IP should be the CM Express router.
  

• Verify the files in flash memory: Verify that the correct firmware files are in the flash memory of the Cisco Unified Communications Manager Express router using the show flash command.

• Debug the TFTP server: Use debug tftp events to ensure that the Cisco Unified Communications Manager Express router is correctly providing the firmware and XML files.

• Verify the firmware installation of the phones: Use the debug ephone register command to verify which firmware is being installed.

• Verify that the locale is correct: Use the show telephony-service tftp-bindings command to view the files that the TFTP server is providing.

• Verify the phone setup: Use the show ephone command to view the status of the ephones and whether they are registered correctly.

• Review the configuration: Use the show running-config command to verify the ephone-dn configuration.

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.

Preparing the Infrastructure to Support Unified Communications

In this section, the best practices components for preparing the network to properly support Unified Communications are explored. Topics covered include the following:

• Voice VLANs

• DHCP

• NTP

• Power over Ethernet

• IP Phone firmware and configuration filesPrivate Line Automatic Ringdown (PLAR)

Voice VLANs

VLANs provide a logical separation of Layer 3 traffic and are created at Layer 2 (the network switch). A voice VLAN (VVLAN, also called an Auxiliary VLAN) is an additional VLAN for the exclusive use of VoIP and video traffic. The benefits of using a VVLAN include isolation from the broadcast traffic data VLANs, a measure of additional security, and simpler deployment because you do not have to renumber the IP address scheme of the whole network to add VoIP endpoints. (Each VLAN is a new, separate subnet.)

Most Cisco IP Phones are actually 3-port switches. The port that connects to the network switch can act as an 802. lq trunk, allowing both voice and data traffic to be multiplexed in their respective VLANs on the single cable to the network switch. The second port connects the desktop PC to the phone (and thus to the network over the trunk on the first port), and the third port is an internal one for the voice traffic generated and received by the phone.

On many Cisco switches, the port connecting the phone does not need to be a trunk; it can be an access port instead. The switch is capable of sending the VVLAN ID using CDP messages, and the phone then sends frames from itself tagged with the learned VVLAN ID and forwards frames from the attached PC untagged. These untagged frames will be tagged with the access VLAN ID configured on the switch port when they are processed by the switch.


The phone adds a QoS marking to its own frames, using the 802. lq frame header Class of Service (CoS) field. The phone marks its frames as CoS 5 by default. This is the recommended setting, but it can be modified.

The following is a typical switchport configuration for an attached IP Phone in VVLAN 100 and the PC in VLAN 50:

DHCP

It is recommended that you use DHCP for IP Phone addressing. Create a separate subnet for the Voice VLAN and add the Option 150 parameter to identify the TFTP server IP address. This can be done on an existing DHCP server, or a new one can be added if necessary; Cisco routers have DHCP server capability. The following configuration is a typical example of router-based DHCP to support IP Phones:


If you choose to use a DHCP server that resides on a different network, you will need to add the ip helper-address command on the Voice VLAN interface of the router so that it will forward DHCP broadcasts from the phones to the DHCP server.


Network Time Protocol

Clock synchronization is important in VoIP systems for accurate Call Detail Records (used for billing), easier troubleshooting and debugging, and for good voice performance. Network Time Protocol (NTP) is used on all Cisco devices to sync the system clock to a master clock. IP Phones get their time from the call agent (CM, CM Business Edition, CM Express, or SBCS). The call agent(s) are configured to get their time from a master clock, usually a highly accurate atomic or radio clock external to the network.


Cisco IP Phone Firmware and XML Configuration Files

Cisco IP Phones need the following three separate files to function:

• The firmware file: This file is loaded into nonvolatile memory and is persistent across reboots. To make the firmware files available to the phones, use the router command tftp-server flash:firmware-file-name. The command load phone-type firmware-file is also required to associate the model of IP phone with the appropriate firmware file.
  

• SEPAAAABBBBCCCC.cnf.xml: This is the device-specific XML configuration file (AAAABBBBCCCC is the MAC address of the phone), which specifies the IP address, port, firmware, locale, directory URL, and many other pieces of information. This file is created when the IP Phone has been added to the configuration.

• XMLDefault.cnf.xml: This is the XML configuration file that devices use if their specific SEP file is not available (typically if they have not registered before or if they have been factory reset).

These files are downloaded by the phone during its boot process.


Power over Ethernet

Power over Ethernet (PoE) is a desirable option because it eliminates the cost and clutter of power bricks for the IP Phones. There are two methods of PoE delivery:

• Cisco prestandard (inline power)

• 802.3af standard

Extra care should be taken to ensure the following:

• RJ-45 cabling is tested and meets the required standard.

• The IP Phone and the switch have a common PoE delivery method.

• The PoE switch has a suitable UPS backup to provide power continuance in the event of a power failure.

Alternatively, each IP Phone may be powered by its own cable and transformer, or a variety of power injectors are available.

The Cisco prestandard PoE method works as follows:

1. The switch sends a special tone, called a Fast Link Pulse (FLP), out of the port. The FLP goes to the powered device, in this case an IP phone.

2. When unpowered, the PoE device has a physical link between the pin on which the FLP arrives and a pin that goes back to the switch. This creates a circuit, resulting in the FLP arriving back at the switch. Non-PoE devices will not have this link; the switch will therefore never receive the FLP from a device that does not require PoE.

3. When the switch receives the returning FLP, it applies power to the line.

4. The link comes up within 5 seconds.

5. The powered device (IP phone) boots.

6. Using CDP, the IP Phone tells the switch exactly how much power it needs. (Power requirements vary from device to device.)

The 802.3af PoE standard works slightly differently. The standard requires that all eight pins in the RJ-45 cable be present and punched down. The following describes the 802.3af PoE negotiation steps:

1. The switch applies constant DC power to all ports that may require PoE.

2. An 802.3af-compliant device will apply 25 ohms resistance across the DC circuit.

3. The switch detects the resistance and applies low-power PoE to the link.

4. The powered device (the phone) boots.

5. The phone uses CDP to specify its power needs.

Internet Telephony Service Providers

As VoIP technology matured and stabilized, telephone service providers began extending VoIP connectivity to their customers, allowing for simple, flexible connection alternatives to traditional TDM links. Internet Telephony Service Providers (ITSP) connections are typically much less expensive, available in smaller bandwidth increments than Tl or PRI links, and can route nonvoice data traffic concurrently. QoS configuration is supported (and in fact is required for proper VoIP operation). Most ITSP links use SIP, but H.323 is an option. The gateway configuration is relatively simple, with the creation of a VoIP dial peer pointing at the provider with the parameters they supply. PSTN calls are routed to the provider, who then routes calls to their PSTN connection, usually with a toll-minimizing route that dramatically reduces long-distance costs to the customer.


Understanding Call Setup and Digit Manipulation

Successfully completing a phone call requires that the correct digits are sent to the terminating device, whether on the VoIP network or the PSTN. PSTN calls are typically more complex because of the varying local and international requirements for the number of digits required to route the call. Over and above this basic requirement are the additional complexities imposed by requirements of the business: we may want to change our ANI number, add or strip access codes, compensate for undesirable default behavior, or build specialized functionality for our particular purposes. This section deals with digit manipulation and troubleshooting.

Translation rules use regular expression syntax, which can be quite complex. The following table defines the characters used, and examples follow.

Connecting a VoIP System to a Service Provider Network

A VoIP system that can place calls only to other devices on the IP network is only marginally useful; we still need to place calls out to the PSTN, and to do so we need to connect to a phone service provider, whether via traditional TDM links or ITSP connections. The device that acts as the interface to the PSTN is the voice gateway; it provides the physical connection and logical translation between two or more different network technologies.

Understanding Gateways, Voice Ports, and Dial Peers

The following sections establish some terms of reference.

Gateways
In the Cisco Unified Communications architecture, a gateway is typically a voice-enabled router with an appropriate voice port installed and configured. Gateways can have both analog and digital voice port connections, including analog FXO, FXS, and E&M or digital T l / E l or PRI interfaces.

Call Legs
A call leg is the inbound or outbound call path as it passes through the gateway. As the call comes into the gateway, it is associated with an inbound port. (This is the inbound call leg.) As the call is sent out another gateway port, this creates the outbound call leg. There will be inbound and outbound call legs at each gateway router.

Dial Peers
A dial peer is a pointer to an endpoint, identified by an address (a pattern of digits). Cisco gateways support two types of dial peers: POTS and VoIP. POTS dial peers are addressed with PSTN phone numbers, and VoIP dial peers are addressed by IP addresses. Dial peers identify the source and destination endpoints of call legs; an inbound call leg is matched to a dial peer, and the outbound call leg is routed to a destination dial peer. Depending on the direction of the call, the dial peers may be POTS inbound and VoIP outbound, vice versa, or possibly both VoIP. It is unlikely but not impossible that the

inbound and outbound dial peers would both be POTS. Each dial peer also defines attributes such as the codec to use, QoS settings, and other feature settings. Dial peers are configured in the gateway IOS, using either the CLI or GUI interface.

The partial output that follows shows a simple POTS dial peer configuration:


The number assigned to dial peers is arbitrary, although dial peer 0 exists by default and cannot be deleted. The keyword pots creates a POTS dial peer; the keyword voip would create a VoIP dial peer. The destination-pattern command identifies that the attached device (phone or PBX) terminates calls to the specified number (or a range of numbers if connecting to a PBX). The port command identifies the physical hardware connection the dial peer will use to reach the destination pattern.

The destination-pattern command associates a phone number with a dial peer. The specified pattern can be a specific phone number (as above, 8675309) or an expression that defines a range of numbers. The router uses the patterns to decide which dial peer (and associated physical port) it should route a call to. The following table briefly explains destination-pattern syntax.


Configuring VoIP dial peers is equally simple. Examine the following configuration:


In this example, the destination pattern is any four-digit number starting with "4." A new command, session-target, is used to identify the IP (version 4 in this case) address of the gateway or call agent that will terminate the call. If the IP address is on a router, it should be a loopback IP so that the address is always available even if a physical interface fails. The preceding configuration creates an H.323 dial peer (in contrast to a SIP dial-peer).


Routers attempt to match dial peers for the inbound call leg according to the following rules:

1. Look for the incoming called-number command in a dial peer that matches the called number or DNIS string of the inbound leg.

2. Look for the answer-address command in a dial peer that matches the calling number or ANI string of the inbound call leg.

3. Look for the destination-pattern command in a dial peer that matches the calling number or ANI string of the inbound call leg.

4. Look for the POTS dial peer port command that matches the voice port of the incoming call (POTS dial peers only).

5. If all of the above fail to match, match against Default Dial Peer 0 as a last resort.

The default dial peer 0 config for inbound POTS calls includes the following:

• no ivr application

When a router is matching the dialed digits against the patterns in the configured dial peers, it attempts to find the longest match. This occurs on a digit-by-digit basis. Each successive digit may validate some patterns while eliminating others until a single pattern represents the longest match between the dialed digits and the destination pattern, at which point the call is routed to the outbound dial peer configured with that matching pattern.

Consider the following configuration:


Given this configuration, the following example dialed numbers illustrate how the patterns match dialed digits:

• The dialed number 867-5309 will match dial peer 40 (exact 7-digit match)

• The dialed number 867-4309 will match dial peer 30 (first four digits match)

• The dialed number 867-3309 will match dial peer 20 (first four digits match)

• The dialed number 876-5309 will match dial peer 10 (no other exact match, so the ".T" pattern matches)

Introducing VoIP Signaling Protocols

VoIP signaling protocols are responsible for call setup, maintenance, and teardown. A number of different protocols are in use—some standards-based, others proprietary, and each with advantages and disadvantages. The following sections introduce the signaling protocols you should know about, including SCCP, H.323, MGCP, and SIP.


VoIP Signaling Protocols

VoIP signaling protocols handle the call setup, maintenance, and teardown functions of VoIP calls. It is important to keep in mind that the signaling functions are an entirely separate packet stream from the actual voice bearer path (RTP). The signaling protocol in use must pass the supervisory, informational, and address information expected in any telephony system.

VoIP signaling protocols are either peer-to-peer or client-server; in the case of peer-to-peer protocols, the endpoints have the intelligence to perform the call-control signaling themselves, Client-server protocols send event notifications to the call agent (the Unified CM server) and receive instructions on what actions to perform in response. The following table summarizes the characteristics of the four signaling protocols dealt with here.


H.323
H.323 is not itself a protocol; it is an umbrella standard that defines several other related protocols for specific tasks. Originally conceived as a multimedia signaling protocol to emulate traditional telephony functionality in IP LAN environments, it is a long-established and stable protocol very suitable for intervendor compatibility. H.323 is supported by all Cisco voice gateways and CM platforms as well as some third-party video endpoints.


MGCP

Media Gateway Control Protocol is a lightweight client/server protocol for PSTN gateways and some clients. It is simple to configure and allows the call agent to control the MGCP gateway, eliminating the need for expensive gateways with intelligence and complex configurations. The gateway reports events such as a trunk going off-hook, and the call agent instructs the gateway on what to do; the gateway has no local dial plan because all call routing decisions are made at the call agent and relayed to the MGCP gateway. MGCP is not as widely implemented as SIP or H.323. MGCP is not supported by Unified CM Express or the Smart Business Communication System.


SIP

Session Initiation Protocol is an IETF standard that uses peer-to-peer signaling. It is very similar in structure and syntax to HTTP, and because it is text-based, it is relatively simple to debug and troubleshoot. SIP can use multiple transport layer protocols and can support security and proxy functions. SIP is an evolving standard that currently provides basic telephony functionality; further developments and extensions to the standard will soon make it feature-comparable with SCCP. One of its most important capabilities is creating SIP trunks to IP Telephony service providers, replacing or enhancing traditional TDM PSTN connections.


SCCP

Skinny Client Control Protocol is a Cisco-proprietary signaling protocol used in a client-server manner between Unified CM and Cisco IP Phones (and some Cisco gateways). SCCP uses TCP connections to the Unified CM to set up, maintain, and tear down voice and video calls. It is referred to as a stimulus protocol, meaning that it sends messages in response to events such as a phone going off-hook or a digit being dialed. SCCP is the default signaling protocol for all Cisco IP phones, although many also support SIP; SIP does not yet support the full feature set available to SCCP phones. All Cisco Unified Communications call agents (CM, CM Express, and the 500 Series) and some gateways support SCCP.

Understanding VoIP

The elements of traditional telephony—status, address and supervisory signaling, digitization, and so on—must have functional parallels in the VoIP world for systems to function as people expect them to, and more importantly, for VoIP to interact with the PSTN properly.

This section examines packetizing digital voice, signaling, and transport protocols, the components of a VoIP network, and the factors that can cause problems in VoIP networks and how they can be mitigated.


Understanding Packetization

IP networks move data around in small pieces known as packets. Because we know how to digitize our voice, it now becomes just another binary payload to move around in a packet. VoIP uses Digital Signal Processors (DSP) for the codec functions. The digitized voice is then packaged in an appropriate protocol structure to move it through the IP infrastructure.


DSPs

DSPs are specialized chips that perform high-speed codec functions. DSPs are found in the IP phones to encode the analog speech of the user and to decode the digitized contents of the packets arriving from the other end of the call. DSPs are also used on IOS gateways at the interface to PSTN circuits, to change from a digital circuit to packetized voice, or from an analog circuit to packetized voice. DSPs also change from one codec to another, allow conferencing and call park, and other telephony features. DSPs are a vital component of a VoIP system. Different chip types have varying capacities, but the general rule is that you want as many DSP resources available to you as possible. The DSP calculator on cisco.com will help you calculate what you must have.


Real-Time Transport Protocol (RTP)

RTP was developed to better serve real-time traffic such as voice and video. Voice payloads are encapsulated by RTP, then by UDP, then by IP. A Layer 2 header of the correct format is applied; the type obviously depends on the link technology in use by each router interface. A single voice call generates two one-way RTP/UDP/IP packet streams. UDP provides multiplexing and checksum capability; RTP provides payload identification, timestamps, and sequence numbering.

Payload identification allows us to treat voice traffic differently from video, for example, simply by looking for the RTP header label, simplifying our configuration tasks. Timestamping and sequence numbering allows VoIP devices to reorder RTP packets that arrived out of sequence and play them back with the same timing in which they were recorded, eliminating delays or jerkiness. There is no provision for retransmission of a lost RTP packet.

Each RTP stream is accompanied by a Real-Time Transport Control Protocol (RTCP) stream. RTCP monitors the quality of the RTP stream, allowing devices to record events such as packet count, delay, loss, and jitter (delay variation).

A single voice packet by default contains a payload of 20 msec of voice (either uncompressed or compressed). Because sampling is occurring at 8000 times per second, 20 msec gives us 160 samples. If we divide 8000 by 160, we see that we are generating 50 packets with 160 bytes of payload, per second, for a one-way voice stream.

If we use compression, we can squeeze the 160-byte payload down to 20 bytes using the G.729 codec. We still have 160 samples, still 20 msec of audio, but reduced payload size.

Codecs

The codecs supported by Cisco include the following:
• G.711 (64kbps)—Toll-quality voice, uncompressed.
• G.729 (8kbps)

• Annex A variant: less processor-intensive, allows more voice channels encoded per DSP chip; lower audio quality than G.729
• Annex B variant: Allows the use of Voice Activity Detection and Comfort Noise Generation;
can be applied to G.729 or G.729-A


The values for bandwidth shown do not include the Layer 3 and Layer 2 overhead; the actual bandwidth used by a single (one-way) voice stream can be significantly larger. The following tables summarize the additional overhead added by packetization and Layer 2 encapsulation (assume 50 packets per second (pps):


When using G.729, the RTP/UDP/IP header of 40 bytes is twice the size of the 20B voice payload. This consumes significant bandwidth just for header transmission on a slow link. The recommended solution is to use Compressed RTP (cRTP) on slow WAN links. cRTP reduces the RTP/UDP/IP header to 2 bytes without checksums or 4 bytes with checksums. The effect of using cRTP is illustrated in the following table. (Note: Ethernet is not included because it is not classified as a slow link.)

Voice Activity Detection (VAD)

Phone conversations on average include about 35% silence. In Cisco Unified Communications, by default silence is packetized and transmitted, consuming the same bandwidth as speech. In situations where bandwidth is very scarce, the VAD feature can be enabled, causing the voice stream to be stopped during periods of silence. The theory here is that the bandwidth otherwise used for silence can be reclaimed for voice or data transmission. VAD also adds Comfort Noise Generation (CNG), which fills in the dead silence created by the stopped voice flow with white noise. VAD should not be taken into account during the network design bandwidth allocation process because its effectiveness varies with background noise and speech patterns. VAD is also made ineffective by Music on Hold and fax features. In reality, VAD typically causes more problems than it solves, and it is usually wiser to add the necessary bandwidth.


Additional DSP Functions

In addition to digitizing voice, DSP resources are used for the following:

• Conferencing: DSPs mix the audio streams from the conference participants and transmit the mix (minus their own) to each participant.

• Transcoding and Media Termination Points (MTP): A transcoder changes a packetized audio stream from one codec to another, perhaps for transit across a slow WAN link. MTPs provide a point for the stream to be terminated while other services are set up.

• Echo Cancellation: DSPs provide the calculation power needed to analyze the audio stream and filter out the repetitive patterns that indicate echo. Echo is a chief cause of perceived poor voice quality; echo cancellation is an important function.

Introduction to Digital Circuits

Digital circuits have the chief advantage of allowing a much higher density of calls on a given physical connection; an analog circuit can handle only one call at a time, whereas a digital circuit can handle many.

There are two main types of digital circuits: Common Channel Signaling (CCS) and Channel Associated Signaling (CAS). CAS circuits are available in two speeds: Tl at 1.544Mbs supports 24 calls, and El at 2.048Mbs supports 30 calls. (For these values, we are assuming the calls are not compressed; more on this later). CCS circuits are designated as PRI T l , PRI E l , and BRI. A PRI Tl can support 23 calls, a PRI El 30, and a BRI only 2.

The use of a digital circuit by definition implies that the voice signal must be digitized; the conversion from analog to digital is performed by a codec. The following sections discuss the conversion of analog to digital.


Digitizing Analog Signals

There are four steps in the process of digitizing analog sound:

1. Sample the analog sound at regular intervals
2. Quantize the sample
3. Encode the value into a binary expression
4. Optionally compress the sample

Sampling could be done any number of times per second; the more samples taken per second, the higher the audio quality, but the amount of digital data produced is much larger. Nyquist's theorem states that the sampling interval should be 2x the highest frequency of the sample to produce acceptable audio quality during playback. Because the highest frequency in human speech that we want to reproduce in telephony is around 4000 Hz, the sampling rate for standard tollquality digital voice is 8000 intervals per second. By contrast, CD music audio, which must encode both much higher and much lower frequencies, samples at about 192,000 times per second.


Quantizing refers to making a digital approximation of an analog waveform. Imagine drawing an arc on a chessboard; if you had to define the arc using only the square it was in for each row (segment) and column (interval), you would end up with a stepped pattern that was sort of close to the original arc but not exact. This is exactly the process that happens with quantization: the codec chooses a segment value that is as close as possible to the analog value at the interval it was sampled, but it cannot be exact. To make the quantization more accurate, each sample is divided into 16 intervals that are adjusted to more closely match the sampled wave. Furthermore, the segments are actually more fine-grained at the origin than at the high and low ranges. This is because most of the human speech we are trying to capture accurately is in this center range of the scale; there are fewer sounds at the very highest and lowest values.


Encoding the signal is a simple process. We have a single 8-bit code word to identify whether the analog signal was a positive or negative voltage, what value the signal was quantized to (which segment), and finally, which interval is represented by the code word. The first bit identifies either positive voltage (1) or negative (0). The next three bits represent the segment. There are eight segments in the positive range and eight segments on the negative range, so three bits provide the necessary encoding for the quantization. The last four bits identify the interval. A code word example is shown next:

1 0 0 1 1 1 0 0

In this case, the first 1 indicates a positive voltage; the next digits of 001 indicate this is the first segment (on the positive side), and 1100 indicates the twelfth interval.

The code word is 8 bits; we generate a code word 8000 times per second (the sample rate). This gives us a bitrate output of 8 x 8000 = 64,000 bps (64 kbps). The process we just described is known as Pulse Code Modulation (PCM) and is the standard for uncompressed digital voice in telephony. One voice stream thus requires 64k of bandwidth for transport.

Compression is not a required step, but it is often done to save bandwidth in VoIP environments. The two main types of compression we are concerned with are the following:

• Adaptive Differential PCM (ADPCM): This method does not send entire code words, but instead sends a smaller code that represents the difference between this word and the last one sent. This is not commonly used today, because it produces lower voice quality and compresses down only to about 16 kbps.
  

• Conjugate Structure Algebraic Code Excited Linear Prediction (CS_ACELP): As the name suggests, this is more complex compression. Based on a dictionary or codebook of known sounds made by a standardized American male voice, the digital sample is analyzed and compared to the dictionary. The dictionary code that is the closest to the sample is sent. The codebook is constantly learning. The output of this compression is typically 8 kbps—withvery little degradation of voice quality. This compression is widely used in VoIP.

Time Division Multiplexing (TDM)

TDM is the primary technology used in traditional digital voice; it is also extensively used in data circuits. The basic premise is to take pieces of multiple streams of digital data and interleave them on a single transmission medium.


T1 Circuits

On a Tl circuit, there are up to 24 channels available for voice. 64k from conversation 1 is loaded into the first Tl channel, then 64k from the conversation 2 is loaded into the second channel, and so on. If not enough conversations exist to fill the available channels, they are padded with null values. The 24 channels are grouped together as a frame. Depending on the implementation, either 12 frames are grouped together as a larger frame (called SuperFrame or SF), or 24 frames are grouped together (called Extended SuperFrame or ESF). T l s are typically full duplex, with two wires sending and the other two wires receiving.


E1 Circuits

An El is very similar to a T l . There are 32 channels, of which 30 can be used for voice. (The other two are used for framing and signaling, respectively.) The 32 channels are grouped together as a frame, and 16 frames are grouped together as a multiframe. El circuits are common in Europe and Mexico, with some El services becoming available in the United States.


Channel Associated Signaling (CAS)—T1

Although the 64 k channels of a Tl are intended to carry digitized voice, we must also be able to transmit signaling information, such as on-hook and off-hook, addressing, and so forth. In CAS circuits, the least significant bit of each channel in every sixth frame is "stolen" to generate signaling bit strings. SF implementation takes 12 frames and creates a SuperFrame. Using one bit per channel in every sixth frame gives two 12-bit signaling strings (known as A and B) per SuperFrame. The A and B strings are used to signal basic status, addressing, and supervisory messages. In ESF, 24 channels are in an Extended SuperFrame, which gives A, B, C, and D signaling strings. These can be used to signal more advanced supervisory functions.

Because CAS takes one bit from each channel in every sixth frame, it is known as Robbed Bit Signaling (RBS). Using RBS means that a slight degradation occurs in voice quality because every sixth frame has only 7 instead of 8 bits to represent the sample; however, this is not generally a perceptible degradation.


Channel Associated Signaling (CAS)—T1

El signaling is slightly different. In an El CAS circuit, the first channel (channel 0 or timeslot 1) is reserved for framing information. The 17th channel (channel 16 or timeslot 17) contains signaling information—no bits are robbed from the individual channels. Timeslots 2-16 and 18-32 carry the voice data. Each channel has specific bits in timeslot 17 for signaling. This means that although El CAS does not use RBS, it is still considered CAS; however, the signaling is outof-band in its own timeslot.


Common Channel Signaling (CCS)

CCS provides for a completely out-of-band signaling channel. This is the function of the D channel in an ISDN PRI or BRI implementation. The full 64 k of bandwidth per channel is available for voice; instead of generating ABCD bits, a protocol known as Q.931 is used out-of-band in a separate channel for signaling. An ISDN PRI Tl provides 23 voice channels of 64 k each (called Bearer or B channels) and one 64 k D (for Data) channel (timeslot 24) for signaling. An ISDN PRI El provides 30 B channels and 1 D channel (timeslot 17); an ISDN BRI circuit provides two 64 k B channels and one D channel of 16 k.

Introduction to Analog Circuits

Analog (in contrast to digital) circuits are still the most common telephone connections worldwide. The phone line to a North American home is most commonly an analog loop circuit, although more and more digital phone services are being installed. Cisco gateways must connect to various analog services to place calls to the PSTN; the analog circuits that Cisco supports are Foreign Exchange Station (FXS), Foreign Exchange Office (FXO), and Earth and Magneto (E&M). This section examines the components of an analog telephone and the signaling methods used by analog circuits.


Components of an Analog Phone

An analog phone includes the following components:

• Receiver: The handset speaker

• Transmitter: The handset microphone

• 2-wire/4-wire hybrid: Converts 2-wire from the CO to 4-wire in the phone

• Dialer (tone/pulse): The dialing keypad or rotary dial

• Switch hook: The switch that closes/opens the circuit (off-hook/on-hook)

• Ringer: Sounds to indicate inbound call

Foreign Exchange Station

An FXS port connects directly to an analog phone or fax machine. Switches (including CO switches and PBXs) and Cisco gateways will have FXS ports to connect an analog phone. The switch or FXS gateway port must provide power, call progress tones, and dial tone to the analog device. An FXS port on a gateway is also the direct connection to the VoIP network and consequently also contains a coder-decoder (Codec) to convert the analog signal to digital for packetization. Alternatively, a Cisco Analog Telephony Adapter can serve as a remote FXS-to-Ethernet converter to connect an analog station to the VoIP network.

Foreign Exchange Office

An FXO port connects to the PSTN CO switch. If you want to connect your gateway router to the phone company over standard analog lines (that you could plug your analog phone into), you use FXO ports. These ports allow the gateway to place and receive calls to/from the PSTN. FXO ports also include a codec.


Loop-start signaling is commonly associated with local loop circuits (such as an analog line to the PSTN); it is seldom seen on trunk connections. A local loop is a two-wire service that uses very simple electrical signaling; remember that this technology has been in use and substantially unchanged for 100 years!

Following is the loop-start process:

1. A phone that is on-hook breaks the electrical circuit; we say opens the circuit. No electricity can flow because of the open circuit.

2. When the receiver is lifted, the circuit closes and electricity flows. This current is -48V DC. The CO switch that is connected to the local loop detects the current flow and interprets this as an attempt to place a call—we say "seize a circuit." The CO switch plays dial tone down the line to the phone as an indication that it is prepared to collect digits.

3. If the phone is on-hook and the CO switch has a call inbound for it, the CO switch applies 90V AC current to the open circuit; because it is AC, the current can be applied even on the open circuit. By the way, this is why you should not have an analog phone near the bath. The DC voltage won't do much, but you will definitely know it if the phone rings and you get zapped by the AC voltage.

Loop-start works very well for homes or other lightly used circuits, but if it is in constant use, a problem known as glare can occur; this refers to both ends of the circuit being seized at the same time, so that you pick up the phone and there is a caller on the line at the same moment, by coincidence.


Ground-Start Signaling

Ground-start signaling is an adaptation of loop-start. Instead of the circuit being closed only at the phone end, both ends of the circuit have the capability to detect current, and both ends can request and confirm the use of the circuit. This is achieved by both ends being able to ground one of the wires in the circuit. These wires (or leads) are referred to as Tip and Ring. These terms date back to the use of 1/4-inch jacks with a positive contact at the tip and a negative conductor in the ring. The advantage is that it makes glare much less likely, and consequently ground-start is appropriate for trunk connections that are heavily used. However, it is very rare to see a ground-start trunk in a VoIP network or indeed in any new trunk deployment.

The ground-start process as it occurs on a trunk between a PBX and the CO switch is described next; refer to the diagram for each step:

1. The PBX has a call that it must send to the PSTN. It signals to the CO switch that there is an inbound call by grounding the ring lead.

2. The CO senses the ring lead as grounded and grounds the tip lead to signal the PBX that it is ready to receive the call.

3. The PBX senses the tip ground and closes the loop between tip and ring in response; the PBX also removes the ring ground.

4. The voice circuit is complete, and communication can begin.


E&M Signaling

Variously called "Ear and Mouth," "RecEive and TransMit," and "Earth and Magneto," E&M analog trunks were typically used to interconnect PBXs (tie-trunks). E&M connections have separate leads for signaling and voice; the signaling leads are known as the E and M leads.

In an E&M connection, one side is called the trunk side; this is usually the PBX side. The other side is called the signaling-unit side; this is the CO, channel-bank, or Cisco gateway E&M interface. The E lead is used to indicate to the trunk side that the signaling-unit side has gone off-hook; conversely, the M lead is used to indicate to the signaling-unit side that the trunk side has gone off-hook.

Five types of E&M signaling exist, numbered Type I through Type V. In a Cisco Gateway application, Types II and V can be connected back-to-back and Type I cannot be. Cisco does not support Type IV.

Three main techniques are employed in E&M circuit signaling:

• Wink Start: The terminating side (for example, a Cisco Gateway) uses a brief off-hook-on-hook "wink" to acknowledge that the originating side (for example, a PBX) has gone off-hook. Upon receipt of the wink, the originating side begins sending digits. When the far-end device answers the call, the terminating side goes off-hook and the voice circuit is then set up.

• Immediate Start: The originating side goes off-hook, waits a set time (perhaps 200ms), and then begins sending digits whether or not the terminating side is ready.

• Delay Dial: Assume that a PBX is placing a call outbound to the PSTN: First, the PBX goes off-hook. The CO then goes off-hook until it is ready to receive digits; it then goes on-hook. (This time period is the delay dial signal.) The PBX sends digits. When the far-end device answers the call, the CO goes off-hook (called Answer Supervision), and the voice circuit is then set up. The advantage of Delay Dial is that some equipment is not ready to receive digits instantly, even though it has sent the wink; the delay compensates for this.