Home > Articles > Cisco Network Technology > IP Communications/VoIP > Cisco CallManager Express VoIP Call Processing Features

Cisco CallManager Express VoIP Call Processing Features

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jul 15, 2005.

Chapter Description

In this chapter, you'll read about some of the more popular Cisco CME phone and call processing features. You will see examples of how these features can be configured and combined to provide a rich and flexible set of functions. You will also see how to configure call transfer and forwarding functions in a variety of network scenarios.

This chapter covers the following topics:

  • IP phones and lines
  • Shared lines
  • Hunt groups
  • Intercoms
  • Paging
  • Line overlays
  • Call pickup
  • Softkey customization
  • Call transfer and forward

This chapter describes the primary call processing features of Cisco CallManager Express (CME) and shows how you can combine them to produce an extensive set of call handling behaviors. It includes a basic discussion of the advantages of IP telephony for the small office and relates these to the more traditional time-division multiplexing (TDM) or analog-based telephone systems historically used in the small private branch exchange (PBX) and Key System marketplace.

This chapter explains the terminology and Cisco IOS commands (command-line interface [CLI]) used to configure IP phones, extension lines, shared lines, overlays, intercom, paging, call park and pickup, hunt groups, and other forms of call coverage. One of the key perspectives to understanding Cisco CME is that it is built on top of a Cisco IOS router. This means that the same modular feature approach that dominates the general Cisco IOS command-line organization is carried forward into the Cisco CME structure. The result is that individual component features are designed to be as modular and flexible as possible. It also means that it is often possible to combine features to produce some fairly complex operations. Some of these combinations are not obvious from a quick glance at the CLI. This chapter is intended to help you understand and use some of the available flexibility.

The sample configurations in this chapter are presented using the Cisco IOS CLI. Many of the configurations described can also be generated using the web browser graphical user interface (GUI). In both cases, the configurations generated are stored identically in the router's nonvolatile memory in CLI format. The CLI presentation is more compact and easier to grasp than an equivalent series of GUI screen shots. The CLI presentation also shows the integration of some Cisco CME-specific functions with the CLI commands for related but generic Cisco IOS router functions, because the generic Cisco IOS commands usually don't have a GUI equivalent. The CLI format is also convenient for many readers who may already be very familiar with the Cisco IOS CLI. The GUI is more extensively covered in Chapter 13, "Cisco IPC Express General Administration and Initial System Setup," and Chapter 14, "Configuring and Managing Cisco IPC Express Systems."

The objective of this chapter is to give you a broad understanding of the options that Cisco CME provides. It's not meant to be an exhaustive manual on how to configure a Cisco CME system to meet every possible combination of network design circumstances you might encounter. System configuration is covered in Chapter 14. For the more sophisticated configurations, consult the detailed Cisco IOS feature and Cisco CME administration documentation available online at Cisco.com.

The less-complex configurations are generally simple to build, even using the CLI. At the same time, the broad range and component-level adaptability of the Cisco IOS software platform is available if required to deal with the complexity of real-life network situations. Hopefully by reading this chapter, you will at least have a good idea of what you're looking for when you decide to tackle the extensive Cisco IOS, voice over IP (VoIP), and Cisco CME documentation that's available online.

IP Phones and IP Phone Lines

IP phones may appear to be very similar in appearance to the digital phones used with a TDM-based PBX, at least on initial inspection. IP phones do behave in very similar ways for basic call operations. When you lift the handset, you hear dial tone. When an incoming call arrives, the phone rings. Phone users expect this behavior, which makes the introduction of IP phone technology as a replacement for traditional TDM-based telephony relatively painless for the vast majority of (nontechnical) phone users. In the case of traditional TDM-based telephony, the basis of the phone user interface is rooted in the physical structure of the typical digital TDM PBX. This in turn has its roots in the analog PBX systems that preceded it.

With IP telephony, some conscious and deliberate effort has gone into replicating the traditional phone user interface, because many of the historic engineering considerations that dictated design in the TDM PBX world are no longer applicable. This is well illustrated by considering the idea of "phone extensions" or "phone lines" for IP phones. In an analog PBX or Key System, the number of twisted-pair cables connected to the phone determines how many lines the phone has access to. If you want more phone lines, you have to add more wires. This is still mostly true for digital TDM phones. An example is a Basic Rate Inerface (BRI) phone with a twisted-pair cable carrying 2B + D—that is, two bearer channels (audio) plus one data channel (signaling).

For an IP phone, there is no direct relationship between the physical wiring and the number of lines that an IP phone supports. IP phones based on 100-Mbps Ethernet connections can theoretically support hundreds of phone lines. How many lines an IP phone supports is instead determined solely by the design of the phone user interface, not the physical connectivity to the system equipment cabinet. The user interface might be a traditional looking one that has a dedicated physical button for each line the phone supports. Alternatively, the IP phone might simply have a touch screen. In this case, the number of square inches available on the display may determine the maximum number of lines accessible to the user. Other variations on user interface design might include the use of pull-down menus or scroll bars to select a phone line. The extreme example of this is the PC softphone. A softphone is simply an application program running on a PC where you select a phone line from the PC display with a mouse click.

The next section describes how Cisco CME deals with phones and phone lines.

Cisco CME Ephone and Ephone-dn

In the Cisco CME product, an IP phone device is called an ephone (short for Ethernet phone). The phone lines that are associated with the ephone are called ephone-dn (Ethernet phone directory number [DN]). An ephone-dn is made up of the following two subcomponents:

  • Virtual voice port
  • Dial peer

The virtual voice port is the nearest direct equivalent to a physical phone line in a Cisco CME system. The virtual voice port is the object that maintains the call state (on-hook or off-hook). The dial peer is the object that determines the phone number associated with the virtual voice port. A dial peer can do many additional things besides control the virtual voice port's phone number, such as apply translations to called and calling numbers. A virtual voice port can be associated with multiple dial peers and, therefore, can have multiple phone numbers associated with it.

Figure 5-1 shows that ephone-dn 7 creates, or is associated with, virtual voice port 50/0/7 and a plain old telephone service (POTS) dial peer that references virtual voice port 50/0/7. The dial peer contains the voice port's phone number. It is used for call-routing purposes for incoming calls. The virtual voice port contains the station ID that sets the caller ID properties (name and number) for the ephone-dn (used for outgoing calls).

Figure 1

Figure 5-1 Ephone-dn Components: Voice Port and Dial Peer

The terms dial peer and voice port are inherited from the Cisco IOS router voice infrastructure functions that have historically been used for applications such as VoIP gateways in toll-bypass networks (using protocols such as H.323, Session Initiation Protocol [SIP], and Media Gateway Control Protocol [MGCP]). In the router voice gateway context, a voice port typically refers to an interface that connects to the Public Switched Telephone Network (PSTN) (or PBX), but it also includes interfaces that directly connect to analog telephones. The behavior and usage of a virtual voice port is similar in many ways to a physical voice port used to connect to an analog telephone (specifically, a Foreign Exchange Station [FXS]). As a result of this similarity, you will see virtual voice ports called eFXS voice ports. In this terminology, the term eFXS means ephone-dn virtual FXS voice port.

You can configure a virtual voice port to have one or two subchannels. Each subchannel can accept a single voice call. This arrangement is similar to the two bearer channels present on an ISDN BRI voice port. An ephone-dn that is configured in dual-line mode creates a virtual voice port that can handle two simultaneous calls. The primary use of the dual-line option is to provide a simple way to handle features such as call waiting. The dual-line option also provides a way to support the second call instance required by features, such as third-party conferencing and call transfer with consultation.

When you select the dual-line option, the Cisco IP phone provides a rocker button or (blue) navigation bar that is used as a scroll key to select between two call instances presented on the IP phone display. For example, in the case of call waiting, the phone display shows you the active (connected) call and the waiting (ringing) call. You can press the hold softkey to place the active call on hold, use the navigation bar to scroll the IP phone display, and then select the answer softkey for the waiting call.

Alternatively, call waiting can be supported simply by using an IP phone that has two (or more) physical line buttons. In this case, you configure each button with a separate phone line instance (ephone-dn). Instead of configuring a single ephone-dn in dual-line mode, you configure two ephone-dns with the same phone number using the default ephone-dn single-line mode (and the no huntstop option, which you'll learn more about later, in the section "Cisco IOS Voice Dial Peer Hunting"). This provides a simpler and more traditional multiline user interface. You perform navigation between two simultaneous calls by simply pressing one of the line buttons to select the desired call. The previously active call is automatically placed on hold. This mode of operation is often called one button, one call.

The most basic elements of the Cisco CME configuration are the ephone and ephone-dn. You bind the ephone-dn elements you have created to the configured ephone entries using the button command within the ephone command submode. Example 5-1 shows a very simple example.

Example 5-1 Simple Ephone-dn Configuration

router#show running-config
ephone-dn 4 dual-line
  number 1001

ephone 7
  mac-address 000d.aa45.3f6e
  button 1:4

Example 5-1 shows a single IP phone (ephone 7) that is uniquely identified by its Ethernet MAC address (000d.aa45.3f6e). You can find the Ethernet MAC address on a sticker on the underside of your Cisco IP phone or from the phone's shipping carton label. In many cases, the MAC address can be autodiscovered after the phone is plugged into your Cisco CME router's LAN network. Example 5-1 also shows a dual-line ephone directory number (ephone-dn 4). This ephone-dn has telephone extension number 1001. Ephone-dn 4 is then associated or bound to the first line button of ephone 7 using the button command (button 1:4).

Example 5-2 shows a slightly expanded view of the CLI configuration in Example 5-1.

Example 5-2Å@Expanded Ephone-dn Configuration

router#show running-config
tftp-server flash:P00303020214.bin

ip dhcp pool cme
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
option 150 ip 192.168.0.1

interface FastEthernet0/1
 ip address 192.168.0.1 255.255.255.0
duplex auto
speed auto

telephony-service
 ip source-address 192.168.0.1
 load 7960-7940 P00303020214
 max-ephones 24
 max-dn 24
 create cnf-files

ephone-dn 4 dual-line
 number 1001

ephone 7
 mac-address 000d.aa45.3f6e
 button 1:4

The configuration shown in Example 5-2 is all that's needed to register your first IP phone provisioned with a single line button and to produce dial tone when you lift the handset. The only assumptions made here are that the phone is a Cisco 7960 IP Phone, that the phone firmware desired is the file P00303020214.bin, and that the firmware file is loaded into the router's Flash memory.

The tftp-server, ip dhcp pool, and interface FastEthernet 0/1 commands shown are standard Cisco IOS CLI router commands that are outside the scope of this book, but you are most likely familiar with their basic function in the IP world. These commands are included just to provide a context for the Cisco CME-specific commands ephone, ephone-dn, and telephony-service.

Cisco CME also has a telephony-service setup command that you can use to bring up a set of phones and provide basic service. This command includes automatic creation of the Dynamic Host Configuration Protocol (DHCP) pool CLI entry if you need it.

Using a PBX Versus a Key System

The Cisco CME product addresses phone systems in the roughly 1-to-240-phone marketplace. This product spans the range from a small, independent, four-person professional services office (perhaps running on a Cisco 2801 router) to a mid-sized company to a large branch office of a multinational enterprise (running on a Cisco 3845 router). This marketplace has traditionally been addressed by a range of simple Key Systems (with perhaps two PSTN trunk lines and four extensions) to hybrid and small PBX systems (with multiple T1 Primary Rate Interface [PRI] digital PSTN interface trunks). Within this market space, the phone user interface expectations include simple one-extension per-phone configurations (usually with call waiting) to direct PSTN trunk appearance presence on all phones (any phone can answer any PSTN call).

The next sections describe typical deployments for PBX systems and Key Systems.

PBX Usage: One Phone Line and One Phone

In a typical PBX-like deployment, you expect to see digital PSTN trunk lines, with direct inward dial (DID) for direct access to individual phone extensions and one or more receptionists. The receptionist answers calls to the company's primary public phone number and transfers these calls to the individual phone users. Each phone user has his or her own private extension number (and probably also a personal voice mailbox to handle busy or unanswered calls). In this arrangement, each IP phone normally has only a single phone number associated with it. You saw a sample configuration for the one-phone-to-one-extension case in Example 5-1.

You are likely to see a few exceptions to the one-phone-to-one-extension rule, such as in the case of a company executive who has an assistant. In this case, the assistant's phone usually has two extension numbers—one shared with the executive (to allow the assistant to answer the executive's calls) and one personal extension for calls intended for the assistant. This configuration is shown in Example 5-3.

Example 5-3 Two Extension Numbers Per Phone

router#show running-config
ephone-dn 4 dual-line
 number 1001
 name Boss

ephone-dn 5 dual-line
 number 1002
 name Assistant

ephone 7
 mac-address 000d.aa45.3f6e
 button 1:4

ephone 8
 mac-address 000d.bb46.2e5a
 button 1:5 2:4

In Example 5-3, ephone 7 is the executive's phone, with extension 1001 on line button 1. Ephone 8 is the assistant's phone, with the assistant's personal extension 1002 on button 1 and the executive's extension 1001 shared on button 2. When a call arrives for 1001, both phones ring, and either phone can answer the call. When a call arrives for 1002, only the assistant's phone rings. When the executive is using extension 1001, the assistant's phone is unable to access the line. However, the display on the IP phone indicates that that line is in use so that the assistant knows that the executive is busy with a call.

Key System: One Phone Line and Many Phones

In the typical PBX environment described in the preceding section, an analysis of call traffic often shows that there are more internal extension-to-extension calls than external PSTN-to-extension calls. A result of this is the need for the one-person-to-one-phone-number configuration.

In a small four-person office, extension-to-extension calls may be nonexistent. It's often easier to walk over and speak to a coworker than it is to phone him or her. In this environment, calls are predominantly PSTN-to-extension. Furthermore, incoming PSTN calls are the lifeblood of the small company, because each call can potentially be from a customer.

In this environment, often there is no need for personal extension numbers. What is important in this case is that somebody always promptly answers the incoming PSTN calls. A small four-person company, however, often cannot afford to hire a dedicated telephone receptionist. Example 5-4 gives a sample configuration for this type of environment.

Example 5-4Å@PSTN Lines on All Phones

router#show running-config
ephone-dn 1
 number 4085550101
 no huntstop
 preference 0

ephone-dn 2
 number 4085550101
 preference 1

ephone 1
 mac-address 000d.aa45.3f6e
 button 1:1 2:2

ephone 2
 mac-address 000d.bb46.2e5a
 button 1:1 2:2

ephone 3
 mac-address 000d.cc47.1d49
 button 1:1 2:2

ephone 4
 mac-address 000d.dd48.0c38
 button 1:1 2:2

In Example 5-4, you see that ephone-dn 1 and ephone-dn 2 both have the same phone number. The phone number configured is the small company's (fictitious) public PSTN phone number. This is the number that is displayed on the IP phones and also the PSTN number that customers dial to reach the company. You can configure the Cisco CME router's PSTN interface to direct incoming PSTN calls to the first ephone-dn (for example, connection plar opx configured on an Foreign Exchange Office [FXO] port connected to the PSTN). If ephone-dn 1 is busy, calls automatically roll over to ephone-dn 2. To make this happen, you configure the ephone-dn with the same number, and then set explicit preference values to indicate the order for selection between the ephone-dns. The lower-preference 0 value attached to ephone-dn 1 indicates that ephone-dn 1 should be selected first. Also note that the no huntstop command gives the Cisco CME system permission to try to find an alternative destination for the incoming call if the first ephone-dn is busy. (You'll read more about huntstop in the section "Cisco IOS Voice Dial Peer Hunting.")

Note how easy it is to expand this basic two-by-four configuration to include more PSTN trunks and more IP phones. There is no specific limit on how many IP phones can share a single IP phone line. There is a limit on how many phone lines can be directly assigned to each IP phone. This limit is set by the number of available line buttons on the IP phone. For example, a Cisco 7960 IP Phone has six buttons, so you cannot directly assign more than six PSTN lines using the simple configuration method shown in Example 5-4. However, you can attach up to 60 lines to a 7960 IP Phone using a configuration option called overlay-dn. (You'll read more about this in the section "Using Overlay-dn.")

You can see from the examples that the simple binding arrangement between IP phone and IP phone lines creates a significant amount of flexibility. This allows the Cisco CME to support multiple styles of phone usage to meet different end-customer expectations. The PBX and Key System configuration styles are not mutually exclusive. You can combine configuration styles by simply adjusting the IP phone-to-IP phone line bindings as needed.

The one phone line and many phones configuration model applies much more broadly than just the four-person Key System example given here. Even within a larger company's phone system, there are cases in which the one phone line and many phones model is appropriate. One example is for a company loading dock, where you might have several hundred square feet of loading/unloading storage space in a shipping and receiving department. In this situation, you may find it desirable to place multiple phones so that they are spread out across a wide physical area. In addition, any phone can be used to place and receive calls on the same line.

2. Implementing Shared Lines and Hunt Groups | Next Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020