Understanding the PSTN

All the signaling standards and communication methods discussed in the previous section typically focus around the connection to one, massive voice network known as the public switched telephone network (PSTN). If you have ever made a call from a home telephone, you have experienced the results of the traditional telephony network. This network is not unlike many of the data networks of today. Its primary purpose is to establish worldwide pathways allowing people to easily connect, converse, and disconnect.


The Pieces of the PSTN

When the phone system was originally created, individual phones were wired together to allow people to communicate. If you wanted to connect with more than one person, you would need multiple phones. As you can imagine, this solution was short lived as a more scalable system was found. The modern PSTN is now a worldwide network (much like the Internet) built from the following pieces, as shown in Figure 1.13:

• Analog telephone: Able to connect directly to the PSTN and is the most common device on the PSTN. Converts audio into electrical signals.

• Local loop: The link between the customer premises (such as a home or business) and the telecommunications service provider.

• Central office (CO) switch: Provides services to the devices on the local loop. These services include signaling, digit collection, call routing, setup, and teardown.

• Trunk: Provides a connection between switches. These switches could be CO or private.

• Private switch: Allows a business to operate a “miniature PSTN” inside its company. This provides efficiency and cost savings because each phone in the company does not require a direct connection to the CO switch.

• Digital telephone: Typically connects to a PBX system. Converts audio into binary 1s and 0s, which allows more efficient communication than analog.

Many believe the PSTN will eventually be absorbed into the Internet. While this may be true, advances must be made on the Internet to ensure proper quality of service (QoS) guarantees for voice calls.


Understanding PBX and Key Systems

Many businesses have hundreds or even thousands of phones they support in the organization. If the company purchased a direct PSTN connection for each one of these phones, the cost would be astronomical. Instead, most organizations choose to use a private branch exchange (PBX) or key system internally to manage in-house phones. These systems allow internal users to make phone calls inside the office without using any PSTN resources. Calls to the PSTN will forward out the company’s PSTN trunk link (refer to Figure 1.13).

When you first look at a PBX system, it looks like a large box full of cards. Each one of these cards has a specific function:

• Line cards: Provide the connection between telephone handsets and the PBX system.

• Trunk cards: Provide connections from the PBX system to the PSTN or other PBX systems.

• Control complex: Provides the intelligence behind the PBX system; all call setup, routing, and management functions are contained in the control complex.

If you look at a PBX from a network equipment mindset, “single point of failure” might be one of the first thoughts that jump into your mind. While this may be true, most PBX systems offer 99.999 percent uptime with a lifespan of 7 to 10 years. That’s a hard tatistic to beat in just about any industry.

Key systems are geared around small business environments (typically less than 50 users). As technology has advanced, the line between key systems and PBXs has begun to blur; however, key systems typically support fewer features and have a “shared line” feel. For example, you might see a key system installed in a small insurance office where users all have four lines assigned to their phone. If Joe were to use line 1, the line would appear busy for all users at the insurance office.


Connections to and Between the PSTN

When you want to connect to the PSTN, you have a variety of options. Home users and small offices can connect using analog ports. Each two-wire analog connection has the ability to support a single call. For home users, a single, analog connection to the PSTN may be sufficient. For small offices, the number of incoming analog connections directly relates to the office size and average call volume. As businesses grow, you can consolidate the multiple analog connections into one or more digital T1 or E1 connections, as shown in Figure 1.14.



Within the PSTN itself lies a network of networks, similar to the Internet, connecting offices from multiple telephony providers together into a massive, worldwide network. In order for all the telephony providers of the world to communicate together, a common signaling protocol must be used, similar to the way TCP/IP operates in the data realm. The voice signaling protocol used around the world is Signaling System 7 (SS7).

SS7 is an out-of-band (CCS-style) signaling method used to communicate call setup, routing, billing, and informational messages between telephone company COs around the world. When a user makes a call, the first CO to receive the call performs an SS7 lookup to locate the number. Once the destination is found, SS7 is responsible for routing the call through the voice network to the destination and providing all informational signaling (such as ring back) to the calling device.


PSTN Numbering Plans

Just as data networks use IP addressing to organize and locate resources, voice networks use a numbering plan to organize and locate telephones all around the world. Organizations managing their own, internal telephony systems can develop any internal number scheme that best fits the company needs (similar to private IP addressing). However, when connecting to the PSTN, you must use a valid, E.164 standard address for your telephone system. E.164 is an international numbering plan created by the International Telecommunication Union (ITU). Each number in the E.164 numbering plan contains the following components:

• Country code
• National destination code
• Subscriber number

As an example, the North American Numbering Plan (NANP) uses the E.164 standard to break numbers down into the following components:

• Country code
• Area code
• Central office or exchange code
• Station code

For example, the NANP number 1-602-555-1212 breaks down as shown in Figure 1.15.


Even though the NANP defines specific categories of numbers that the E.164 standard does not include, the number still falls under the three broad categories, also shown in Figure 1.15.

The Evolution: Digital Connections

Analog signaling was a massive improvement over tin cans and string, but still posed plenty of problems of its own. First, an analog electrical signal experiences degradation (signal fading) over long distances. To increase the distance the analog signal could travel, the phone company had to install repeaters (shown in Figure 1.6) to regenerate the signal as it became weak.


Unfortunately, as the analog signal was regenerated, the repeater device was unable to differentiate between the voice traveling over the wire and line noise. Each time the repeater regenerated the voice, it amplified the line noise as well. Thus, the more times a phone company regenerated a signal, the more distorted and difficult to understand the signal became.

The second difficulty encountered with analog connections was the sheer number of wires the phone company had to run to support a large geographical area or a business with a large number of phones. Because each phone required two wires, the bundles of wire became massive and difficult to maintain (imagine the hassle of a single pair of wires in the bundle breaking). A solution to send multiple calls over a single wire was needed. A digital connection is that solution.


Converting Analog to Digital Signals

Simply put, digital signals use numbers to represent levels of voice instead of using a combination of electrical signals. When someone talks about “digitizing voice,” they are speaking about the process of changing analog voice signals into a series of numbers (shown in Figure 1.7), which you can use to put the voice back together at the other end of the line.


To convert an analog signal into digital format, the converting device goes through a four-step process:

1. Sample the signal.
2. Quantize the signal.
3. Encode the quantized value into binary format.
4. Optionally compress the sample to save bandwidth.

The following sections describe each part of the process in turn.


Sample the Signal

To convert an analog waveform into a numeric value, the digitizing device must sample it many times as the analog signal changes, as shown in Figure 1.8. This sampling process is known as pulse-amplitude modulation (PAM).


In 1927, Dr. Harry Nyquist, an engineer at Bell Laboratories at the time, found that by sampling a signal at twice the number as the highest electrical frequency of the signal per second, he could regenerate the voice with acceptable audio quality levels. Human speech typically uses frequencies up to 9000 Hz, which would result in 18,000 samples each second. Sending this many samples per second would result in a large bandwidth requirement for each voice call, so Nyquist cut the sampling frequency range for human voice to 4000 Hz (resulting in 8000 digital samples per second). Although limiting the frequency range like this did cut down on the quality of voice, this frequency range is sufficient to allow you to identify the remote caller and sense their mood.


Sending Multiple Calls over a Single Line

Now, let’s come back to the original problems of analog connections:

• The signal degrades over long distances.
• You can’t send multiple calls over a single line (resulting in massive cabling requirements).

Digitizing voice solves the first problem because you can easily transmit a numeric value any distance a cable can run without any degradation or line noise. Time-division multiplexing (TDM) solves the second problem.

TDM allows voice networks to carry multiple conversations at the same time over a single, four-wire path. Because the multiple conversations have been digitized, the numeric values are transmitted in specific time slots (thus the “time-division”) that differentiate the separate conversations. Figure 1.10 illustrates three separate voice conversations sent over a digital connection.

Introducing the Cisco Smart Business Communications System

The Cisco SBCS is a unified communications appliance aimed squarely at the small-business market. These all-in-one devices support data, voice, video, AA, voice mail, security, and wireless for up to 50 users. They leverage UC500 Series devices, including PoE switches, to provide the expansion capability to scale to the maximum endpoint capacity. Many connectivity modules for WAN, Internet, and PSTN options are available, and a simple-to-use graphical interface configuration tool makes it cost effective for small businesses to take advantage of Cisco's Unified Communications products.


Hardware Components

The core of the SBCS is the UC 500 Series for Small Business. This multiservice appliance incorporates routing, firewall, VPN, IPS, PoE switchports, WAN and PSTN connectivity options, and wireless options. The SBCS incorporates CME 4.2 and CUE 3.1.1, with the features found on larger ISR hardware. The Catalyst 520 switch allows for expansion of the system to support more endpoints than the UC500 core unit supports.

For more complex wireless deployments, the Cisco Mobility Express Solution with the Cisco 521 Wireless Express Access Point and the Cisco 526 Wireless Express Mobility Controller provide scalable, manageable, and secure wireless connectivity for both data and voice endpoints.

The SBCS supports a wide range of Cisco IP phones, including video and wireless capabilities. Specialized applications, both from Cisco and third-party vendors, can integrate with the SBCS to further leverage the productivity gains offered by unified communications.

The SBCS comes in two form factors: A desktop or wall-mount unit for installations of up to 16 users and a rack-mount unit for 32-48-user deployments; the smaller units support ISDN BRI PSTN, FXO, and FXS connections, and the larger units add support for Tl and El interfaces, both PRI and CAS.


Security Features

The SBCS supports the Cisco IOS firewall, Easy VPN Server and Remote, NAT, and 802. lx authentication.


Wireless Features

The smaller SBCS can be ordered with an integrated wireless AP, or external 521 Series wireless APs can be connected. The larger SBCS models do not support internal APs. The standalone administrative capability of the Cisco Configuration Assistant will support up to three connected APs. For support of up to 12 APs, the use of a Cisco 526 Wireless Express Mobility Controller for every 6 APs is required. The SBCS systems provide full support for wireless security, including WPA and WPA2, LEAP, PEAP, WEP, as well as voice VLANs with QoS.


Cisco Configuration Assistant

The CCA is a powerful and simple GUI tool for administering the UC500 Series platforms. This tool is used to deploy, configure, and maintain the SBCS devices, allowing control of the following:

• Switching
• Telephony
• Wireless
• Security
• Network services
• Internet connectivity

The GUI tool provides a network map view, showing the devices discovered in the system, as well as a front-panel view of the SBCS system, showing ports and their status. The CCA even allows drag-and-drop upgrades to IOS software, phone firmware, and language files.


For those who miss the CLI, it is still possible to do all administrative tasks from the command line if you so desire.

Implementing Basic Voice Features

A business phone system is expected to provide the following features:

• Music on Hold
• Call Forward
• Call Transfer
• Call Park
• Intercom
• Paging
• Call Pickup
• Call Blocking
• Directory Services

The next sections describe the configuration of these basic business telephony features in CM Express.


Music on Hold

No one likes to be on hold, but having something to listen to makes it a little better and can even relay useful information to the listener. Configuring Music on Hold (MOH) in CM Express is simple. First copy a .wav file to Flash (avoiding copyright issues by using royalty-free recordings). Next, issue the command moh wavefilename.wav in config-telephony mode. By default, the router will multicast the stream to 239.23.4.10:2000; if you need to change this default multicast address (typically you do not), issue the command multicast moh ip-address port port-number.


Call Forward

The user can configure call-forwarding of all calls using the phone softkey. Using the CLI, you can configure different call-forwarding options at the config-ephone-dn prompt:

• call-forward all directory-number: Forwards all calls to the specified directory number.

• call-forward busy directory-number: Forwards calls to the specified number if the user is on the phone.

• call-forward noan directory-number timeout seconds: Forwards calls to the specified directory number if the user does not answer the phone before the specified timeout.

• call-forward maxlength length: Restricts the number of digits specified for the call-forwarding number; this prevents call forwarding to an international long-distance number, for example.

Call Transfer

Users can transfer calls with the Transfer softkey; the administrator can configure how this transfer happens using the transfer-system {blind I full-blind I full-consult llocal-consult} config-telephony command. The command options are as follows:

• Blind: Calls are transferred immediately using a Cisco-proprietary method.

• Full-blind: Calls are transferred immediately using the H.450.2 standard.

• Full-consult: Calls are transferred with consultation (meaning the user must speak to the target of the transfer before the call is released); uses the H.450.2 standard.

• Local-consult: Uses a proprietary transfer method; not commonly used.

Call Park

Call park allows a user to hold a call but retrieve it from another location by dialing the call park extension. A call-park extension is a "floating" ephone-dn that is not assigned to any ephone. Multiple calls can be parked at a single extension and are retrieved by dialling the extension; calls are picked up in the order in which they were parked. The syntax is relatively complex and specifies several options:

• park-slot [reserved-for extension-number] [timeout seconds limit count] [notify extension-number [only]] [recall] [transfer extension-number][alternate extension-number][retry seconds limit count].

• reserved-for: (Optional) Indicates that this slot is a private park slot for the phone with the specified extension number as its primary line. All lines on that phone can use this park slot.

• timeout seconds: (Optional) Sets the Call Park reminder timeout interval, in seconds. The range is from 0 to 65535. When the interval expires, the Call Park reminder sends a 1-second ring and displays a message on the LCD panel of the Cisco IP Phone that parked the call and to any extension that is specified with the notify keyword. By default, the reminder ring is sent only to the phone that parked the call. If the timeout keyword is not used, no reminder ring is sent to the extension that parked the call.

• limit count: (Optional) Sets a limit for the number of reminder timeouts and reminder rings for a parked call. For example, a limit of 10 sends 10 reminder rings to the phone at intervals that are specified by the timeout keyword. When a limit is set, a call parked at this slot is disconnected after the limit has been reached. The limit range is from 1 to 65535 reminders.
  

• notify extension-number: (Optional) Sends a reminder ring to the specified extension in addition to the reminder ring that is sent to the phone that parked the call.

• only: (Optional) Sends a reminder ring only to the extension that is specified with the notify keyword and does not send a reminder ring to the phone that parked the call. This option allows all reminder rings for parked calls to be sent to the phone of a receptionist or an attendant, for example.

• recall: (Optional) Returns the call to the phone that parked it after the timeout limits expire.

• transfer: (Optional) Returns the call to the specified number after the timeout limits expire.

• alternate: (Optional) Returns the call to a specified second target number if the recall or transfer target phone is in use on any of its extensions (ringing or in conversation).

• retry seconds: (Optional) Sets the delay before another attempt to recall or transfer a parked call, in seconds. The range is from 0 to 65535. The number of attempts is set by the limit keyword.

The following example creates four call-park slots. Ephone-dn 10 and 11 can be used by any extension. A call parked in these slots will stay parked for 100 seconds and will send a notification every 10 seconds to the extension that parked it. If the 100-second limit elapses, the parked call is automatically transferred to 5309; if 5309 is busy or does not answer, it goes to 5310. Ephone-dn 12 and 13 are reserved for 5301 and 5302, respectively. After a call has been parked for 100 seconds, it will be disconnected.


Intercom

An intercom is a one-way audio speed-dial. Commonly used by an executive to an admin assistant, it allows the user to press a phone button and be directly connected to another user. The destination phone answers the call in muted speakerphone mode so that privacy is maintained. Any user could dial the intercom if the extension is known. To make it impossible for anyone to dial the intercom (except those phones configured to do so), the extension number of the intercom can include the A, B, C, or D character. These characters were at one time part of the touchtone dialpad, but because they are no longer on the phone itself, users cannot dial them; it is still possible to configure them in an ephone-dn, however. The following configuration shows a typical intercom configuration, using the B digit as part of the intercom extension number:


Paging

Audio paging builds a one-way audio path from the speaker to a single phone, a group of phones, or combined groups of phones. A paging group is created by configuring a dummy ephone-dn with the paging command and associating that ephone-dn with one or more ephones using the paging-dn command. When a user dials the paging extension, all configured phones answer the call in muted speakerphone mode. The default transport is unicast, which limits paging to a maximum of 10 targets; multicast is also supported. The command syntax to create the ephone-dn is the following:

Router(config-ephone-dn)# paging [ip multicast-address port udp-port]

The following shows the syntax for associating an ephone to the paging ephone-dn. Note the unicast keyword, which will override the multicast configuration if the phone is not reachable by multicast:

Router(config-ephone)# paging-dn paging-dn-tag [unicast]

The following example sets up a single paging group:


Call Pickup

There are three variations of call pickup:

• Directed call pickup: Any extension can pick up a call that is on hold on another directory number, without belonging to a pickup group.

• Group pickup: A user can pick up a call for another group if the user knows the group extension. If only one pickup group is defined, users need only press the Pickup softkey, whether or not they are a member of a pickup group.

• Local group pickup: Users can pick up a ringing extension in their own group using the Pickup softkey plus the star key (*).

An ephone-dn is assigned to a pickup group with the command pickup-group number. The numbers are arbitrary, but the leading characters must be unique to each group; for example, the group numbers 81 and 817 will both be interpreted

If the ringing extension is in the user's group, pressing the Pickup softkey will redirect the call to the user's phone. If the ringing extension is in another group, the user must press the GPickup softkey and enter the group number of the ringing extension.


Call Blocking

Call blocking prevents unauthorized use of phones, typically to specific number patterns or times of day. You can define up to 32 patterns of digits to block and apply a time schedule to restrict calls to whatever schedule suits your needs. Call blocking applies to all IP Phones (except analog FXS phones), but phones can be exempted from call blocking individually. An override function exists, configurable with a PIN for authorized users.

The schedule can be configured by day or by date using the following config-telephony commands:

a f t e r - h o u r s day day s t a r t - t i m e stop-time
a f t e r - h o u r s date month date s t a r t - t i m e stop-time

When the after-hours schedule is in place, use the block command to activate call blocking:

a f t e r - h o u r s block pattern tag pattern [7-24]

The patterns use the same syntax as dial plan patterns. Using the 7-24 keyword blocks the configured pattern 24 hours a day, 7 days a week, and disables the override PIN functionality.

The following configuration sets up a call blocking plan for all calls outside of normal business hours of 8:00 a.m. to 5:00 p.m., Monday through Sunday, and the holidays for New Year's day, the Fourth of July, and Christmas day:



Exempting a phone from after-hours blocking is easily configured with the after-hours exempt command at the configephone prompt. Adding a PIN is equally simple at the same prompt with pin pin-number.

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)