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 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.