This chapter describes the interaction between CallManager and station devices, including station functionality and the protocols they use to communicate with Cisco CallManager. The station protocol is part of the Protocol/Aggregation Layer within CallManager. CallManager contains several signaling layers, each of which has distinct functions. For example, the Call Control Layer handles all of the call signaling that controls call setup, teardown, and call routing; and the Protocol/Aggregation Layer handles all protocol-specific signaling required for specific devices.
This chapter discusses the following topics:
Definition of Station Devices—. Introduces the station device in the context of CallManager
Overview of Station Devices Supported by CallManager—. Differentiates users from stations and categorizes the station devices by protocol
Station Device Features—. Introduces the feature content offered to users of the station devices
SCCP Station Devices—. Describes the functionality of the devices that support the Skinny Client Control Protocol (SCCP) and provides an overview of the protocol that supports the devices
Cisco VT Advantage—. Describes the functionality of the PC-based Cisco VT Advantage that provides video functionality for Cisco IP Phones
Computer Telephony Interface (CTI) Devices—. Describes the interface support for devices that connect to CallManager through CTI, including CTI route points, CTI ports, and CTI-monitored/controlled IP phones
IP Phone Registration and Security—. Provide descriptions of how station devices use TFTP and ways to secure IP phones
H.323 Endpoint Devices—. Describes the H.323 endpoints and provides an overview of CallManager’s H.323 protocol support
Appendix C, “Protocol Details,” provides detailed information for signaling protocols such as SCCP, and application protocols like JTAPI and XML. After reviewing this chapter, refer to Appendix C for additional, related information.
Figure 3-1 shows the block structure of CallManager. The darker shading in Figure 3-1 highlights the software layers and blocks within CallManager that this chapter describes in detail. Other blocks are highlighted with lighter shading. They are part of the station signaling path, but are given lighter coverage.
The software in the Media Control Layer handles all media connections CallManager makes between devices. Whereas the Call Control Layer sets up all of the signaling connections between call endpoints and CallManager, the Media Control Layer directs the devices to establish streaming connections. The Media Control Layer can insert other media processing devices into a call and create appropriate streaming connections to those devices without the Call Control Layer knowing about them.
The blocks in the Protocol/Aggregation Layer control the media processing devices. They provide the device interface and handle all communication between the devices and CallManager.
A station device, as opposed to a gateway device, is any device that is characterized as a terminal endpoint. A terminal endpoint is a device or software application that provides real-time, two-way communication for a single user. The remainder of this chapter often refers to a station device simply as a station.
Software applications that act as station devices include the following:
Cisco applications
Third-party applications
Cisco Interactive Voice Response (IVR)
Auto attendant
Voice mail/unified messaging
A station device and a gateway device provide similar yet contrasting functionality. A gateway provides real-time, two-way communication between the packet-based network and other stations on either another packet-based network or a circuit-switched network. A gateway provides service for multiple users or provides access connections for simultaneous use by multiple users. A gateway can provide protocol support to terminate multiple stations attached to the gateway device or it can be used to interconnect CallManager with other packet network systems. Gateways can also be used to terminate trunks attached to the Public Switched Telephone Network (PSTN) or to a corporate switch, such as a Private Branch Exchange (PBX).
In contrast, a station usually supports a single user at a time, although one station can support multiple users who log in and out of the station at different times. Although a station can consist of multiple lines and might have the capability of terminating multiple connections, stations typically have only a single connection active at a time and provide only a single media stream to a user. Figure 3-2 shows examples of various stations and a sample gateway device.
CallManager supports numerous station device features, which are discussed by feature category. You’ll also learn about the architectural capabilities required to provide the feature functionality.
A user is a person or software application that uses a station to communicate with another user. For the purposes of this chapter, a user has a station with one or more directory numbers that can be dialed to communicate with the other user.
You assign each user a directory number, or more simply, a phone number, which users or software applications dial when they want to call each other or route calls to users. All stations have at least one directory number. A station can also have multiple directory numbers, one directory number per line.
Users communicate over a media path, typically audio, that is established between two stations during a call. CallManager allows devices with dissimilar signaling protocols to establish a connection and communicate. The protocol of the caller might be SCCP, for example, whereas the protocol of the destination might be H.323.
The line appearance model of the station devices applies to all station devices and encompasses the concept of multiple line appearances and shared line appearances. Each station device has one or more lines, and each line is associated with a specific directory number. A user dials a directory number to place a call. Each station has at least one line and associated directory number, but can also have multiple lines, each with a separate and unique directory number. The term multiple line appearances refers to when a single station has multiple directory numbers.
You can associate one directory number with one or more stations. The term shared line appearances refers to when the same directory number appears on multiple devices. With a shared line appearance, users can have stations in multiple places (main office, remote office, or home) with the same line appearance and can receive calls at any of these locations. When a user dials a directory number, CallManager rings all stations that have an appearance of that directory number. When a user dials a directory number, CallManager rings all stations that have an appearance of that directory number. The call can then be answered at any station with that line appearance.
Figure 3-3 shows three stations. Each station has a unique directory number. In addition, Station 3 has a second directory number that is a shared line with Station 2. This allows the station to answer calls directed to either Station 2 or Station 3 (directory number 1002 or 1003). When a caller dials directory number 1002, both Stations 2 and 3 indicate an incoming call, and the call can be answered at either station.
Every station feature that is call related involves one or more calls in progress. Each call is associated with a particular line on a specific station device, referred to as a line appearance. A line appearance on a station is where incoming calls arrive or outgoing calls originate. A line appearance can support an active call as well as calls that are on hold. An active call can be an arriving call, a call being initiated, or a call that has been connected and at least two parties in the call are exchanging media (voice media in the case of a voice call). When you invoke a feature on the currently connected call that causes the media to the far end of the connection to be suspended, the far end connection is placed on hold. This can be done by invoking the hold feature explicitly via the Hold softkey or indirectly by accepting a new incoming call or by initiating a transfer or conference, for example. An active call on a shared line appearance is active on one station and classified as remote-in-use on other stations with a shared line appearance. Remote-in-use shows you that the call is currently active on another phone with the same line appearance.
As of CallManager release 4.0, a line appearance on a station can support an active call and many calls that are on hold. The configuration for a line appearance includes two settings:
Maximum Number of Calls—. Enables you to control how many call instances can be present on the line appearance, including active, held, and remote-in-use
Busy Trigger—. Enables you to control when an incoming call will be rejected, triggering the call to be sent to the call forward busy destination, if configured
These two settings control the point at which no new incoming calls are allowed as well as the upper limit on the total calls for the line. Some station devices can handle more calls than other devices. The configuration of these fields establishes maximum settings, but the station may do less if it is not configured to support the maximum that is configured on another device. Because the configuration fields are set per line appearance, you can allow some phones to accept more calls than other phones in a shared line appearance. As more calls come into a directory number that is a shared line appearance, some stations might ring whereas others do not because some of the stations reach the configured busy trigger and do not accept new incoming calls.
Multiple stations can share a common line, meaning that there is a line with the same directory number on each of these stations. Stations that share a line can also have other lines that are present on the station independent of the shared line. The other lines each have a directory number that might be present on other stations. This means that a station can share one line with a particular group of stations and share other lines on the station with other groups of stations. For example, Station A shares line 1 (DN 1000) with Station B and Station C. Station C shares line 2 (DN 2000) with Station A and Station D. Station C also has a third line, DN 3000, which is not shared with any other station. You set up the directory numbers that appear on each station to meet the particular needs of the user for the particular station. The lines on a station that are shared lines provide some unique functionality to the stations that share the line. When a user places a call from a shared line on one particular station, the other stations that share the line see that a call is in progress. When the user receives an incoming call on the shared line, the call is presented to every station that has a line appearance with that directory number, and any of the stations can answer the incoming call. All calls, including active, held, and remote-in-use calls, are visible at the station with the shared line appearance unless the call initiator or receiver blocked the information with the privacy feature or the station has already exceeded the maximum number of configured calls. After the user places a call on hold, any station with the shared line appearance can retrieve the held call and resume the conversation. A new call can be initiated on a shared appearance line as long as the maximum number of calls configured for the directory number of the shared line has not been reached. The maximum number of calls that can be in progress for the shared line appearance applies to the combined total for the line, regardless of which station or stations have active calls in progress or which station put a particular call on hold.
Use up/down navigation control on the station or the Select softkey to select a particular a call on a line. In the case of shared line, the calls that you can select are the calls that are not active or locked by another device. A call is locked by another device when it is currently in the middle of a feature such as transfer or conference or if it is selected on another station. You select a particular call to take a particular action on the call, such as joining the selected call to another call.
Sharing the same line on multiple phones enables a group of users to spread the call volume when there are more calls than one person can handle. The calls ring on multiple stations. The following sections examine a few examples of the value of shared lines.
Shared lines can prove valuable for small teams that handle numerous incoming calls, such as a customer product group. Because the group typically takes an initial call requesting assistance, the shared line can deliver the call to all the phones in the small group that provides the needed support. Although not practical for a large support organization, which would be better handled by a call center application, the shared line can be leveraged in small teams that want all calls to ring at all available stations.
Consider a small support team of five people that provides technical assistance for a particular product in your organization. The support calls are not frequent, and there are seldom more active calls than the team can handle. Each member of the small team is trained to handle general product questions so it’s not important who takes the initial call. If there are detailed questions in a particular area, one member of the team has more detailed knowledge about the hardware, another has detailed knowledge about the software, and a third has specialized knowledge of the database. If you configure a shared line appearance on each phone of the support team, any available member of the support team will be able to take an incoming support call. If the call is for a general support question, the assistance will be provided by the initial support team member and requires no other action. If one team member takes a call and discovers that the caller needs another of the team members with a particular special knowledge, you can put the call on hold and ask the team member with that expertise to pick up the call. When you make the request, you indicate which call is to be retrieved by the call number assigned to the call when it arrived. When a call arrives and receives a call number, the call number does not change as other calls arrive and terminate on the line.
As shown in Figure 3-4, if the call is call number five, and while the call is on hold, calls three and four hang up, the calls are not renumbered, and call number five stays call number five. New calls will arrive and replace calls three and four that were terminated. As long as call five stays on the original line, even if it is held and retrieved repeatedly, it will stay call number five.
Shared line appearances can also add value for an executive assistant. If an executive needs support at all times, there might be a need for more than one assistant to be able to handle the calls. If the first assistant is currently busy on a call, the backup assistant will be able to see that the call needs to be answered and can take the call. Multiple assistants can have a line appearance of several executives on their phone and provide backup support for the other assistants. Shared lines make it possible to have one or more backup assistants and handle temporary overload situations and still be able to provide adequate coverage for the executive.
To provide backup coverage for multiple executives with a group of executive assistants, you can configure a shared line appearance of each of the executives on all of the phones of the assistants. As an example, assume that five executives each have their own assistant. Backup coverage by the other assistants if one particular assistant was on a call would provide improved coverage for each executive and allow the assistants to provide backup coverage for each other. As shown in Figure 3-5, the primary line for each assistant would be the number assigned to the assistant. The second line would be a shared line appearance of the executive that the assistant supported. The other four lines on the assistant phones would be shared lines of the other four executives. With this configuration, each assistant has access to incoming calls to any of the five executives.
Several key station features were introduced in CallManager releases 3.1 through 4.1. The sections that follow cover each of these features in more detail.
Stations can have more than one line configured, which also means that there is more than one directory numbered configured on the station. A visual indication is provided by default for incoming calls on the line on which the incoming call is ringing, but there is no audible difference to indicate which line is ringing unless the station is configured with a different ring for each line. The distinctive ring feature allows end users to configure the ring type for each line, if desired. If each line has a distinctive ring, the ring itself, in addition to the visual line indication, helps identify the line on which the incoming call is ringing. The option to change the ring settings for each line is provided in the settings menu on the phone (press the settings button).
When an incoming call arrives at a station, the station device notifies you of the incoming call audibly and visually by default. Audible and visual notification of incoming calls is configurable based on whether the station is currently in use or currently idle. If the phone is in use (for example, active on a call), you might or might not want the phone to audibly ring when another call arrives at your station. As shown in Figure 3-6 later in this chapter, the option to Change the Ring Settings for your phone in the Cisco CallManager User Options web page (CCMUser) allows users to set the ring behavior of the phone when it is idle and when it is in use; each condition can employ a different notification behavior. The following options are available when the phone is idle:
Ring normally
Ring once
Flash only
Do nothing
The following options are available when the phone is in use:
Ring normally
Ring once
Flash only
Beep only
Do nothing
Each line on a phone can have a different ring setting depending on whether the phone is idle or in use. Users can configure their own preferences via CCMUser if you have enabled the enterprise parameter Show Ring Settings (System > Enterprise Parameters). The parameter is disabled by default.
Sometimes you want to control whether your calling line identification is sent to the far-end device when you make an external call. In fact, in some states and countries, the ability to block calling information is required by law. Be sure to check local requirements to ensure you are providing this capability when needed.
When a call is placed from a station, the directory number of the line that was used to make the call is sent to the far-end device that is receiving the call. Transmission of this information is Calling Line Identification Presentation (CLIP). For some calls, users might want or need the ability to block CLIP from being transmitted. The ability to restrict the calling line identification presentation for a particular call is possible through Call Line Identification Restrictions (CLIR).
You set up the CLIR for either a gateway or for a route or translation pattern. By configuring CLIR for a gateway, the CLIR feature is enabled for all external calls that are made through that gateway. To control the CLIR on a call-by-call basis, you configure a particular route pattern or translation pattern that will apply CLIR for all calls that use the route pattern or translation pattern. For example, a route pattern of *679.@ could be defined with CLIR set for the route pattern. Using this route pattern, users can dial *679 and the destination number. Doing so would block transmission of the calling line identification to the far end (destination) of the call. For those calls that users don’t mind having CLIP sent, the normal 9.@ pattern can be used. Additional route patterns blocking CLIP for OnNet calls can also be configured, allowing users to block the calling information for both internal (OnNet) and external (OffNet) calls.
The Malicious Call Identification (MCID) feature enables users to mark the active call as malicious. When a call is flagged as malicious, several events occur:
An alarm record is generated and you can configure a text message to be delivered to you detailing the date, time, and physical identifier of the device in use by the victim of the malicious call
The call detail record (CDR) for the active call is flagged with a Malicious Call Trace (MCT) indication
For OffNet calls via ISDN PRI circuits on MGCP gateways, the OffNet PSTN is notified of the malicious call. This notification allows the OffNet system to take appropriate action, such as notifying legal authorities
The user can invoke MCT from any SCCP-based phone or SCCP-based gateway such as the VG248 and ATA-186. Chapter 4, “Trunk Devices,” offers more details on the OffNet PSTN notification of malicious calls. Chapter 7, “Call Detail Records,” addresses the CDR details for malicious calls.
To extend malicious call trace functionality to users, you must configure the MCID softkey on the softkey template. The user presses the MCID softkey during an offending call. An audible tone confirms that the call was registered as malicious and, for phones with a display, a visual indication of the calling line ID and caller’s name displays. After invoking MCID, the user can either continue with the call or hang up.
The barge and cBarge features allow you to add yourself to (that is, barge into) a call that is active on another station on a line that you share with a remote station. Privacy controls whether other users who share a line with you can see call information and have the ability to barge or cBarge into a call on your station. Barge utilizes the conferencing capability of the station device, whereas cBarge uses a conference bridge resource. Because the conferencing capability of the station device is more limited than the conference resource device, cBarge offers additional functionality than barge. Privacy controls the ability of others sharing the line to see the call or to barge into the call.
Privacy allows you to control the visibility of call information displayed at other stations that have a shared line appearance of a line on your station. It also controls the ability of someone at another station to be able to barge or cBarge into your conversation. You can configure a Privacy button and whether a tone plays to all parties when a user barges into the call. The privacy feature is configured at the device level via the Privacy field on the Phone Configuration page in Cisco CallManager Administration (Device > Phone) and at the system level via the clusterwide CallManager service parameter Privacy Setting. The Privacy Setting parameter is enabled by default, so if you want to disable privacy for certain stations, you can do so in the Phone Configuration page only for those stations that you do not want to have access to the privacy feature. The CallManager service parameter Party Entrance Tone controls whether a tone plays when a user barges into a call; it is enabled by default (Service > Service Parameters > select a server > Cisco CallManager). You must configure the Privacy button on a button template and assign that template to all phones you want to have the Privacy button.
The Privacy button enables you to toggle the privacy setting on or off and control the privacy treatment of all new calls to or from your station and any existing active call at your station. If you currently have an active call, press the Privacy button to invoke privacy so that no one will be able to barge into the call and the information about your calls will be removed from the display at all stations that have a shared line appearance with you. The privacy setting remains active until you press the Privacy button again. Even after the call has ended, privacy will apply to new calls until you toggle privacy off. The Privacy button has an icon to indicate on/off status. The status is maintained through phone reset as well as CallManager reset; however, in the case of a CallManager reset and the Publisher being down at the same time, the Privacy setting that was stored in the database prior to the Publisher crash is what will be reflected on the phone when the Publisher is restored. If the user changed the Privacy status during the Publisher and CallManager outage, the new setting will not be maintained when the Publisher and CallManager connection gets restored.
The barge feature enables you to add yourself into an active call on a shared line appearance, forming a three-party conference utilizing the barged station’s conference capability. To define terminology, the following parties are involved in a barged call:
The barger or barging station is the party pressing the Barge softkey to be added to a call that is active on one of the phone’s shared line appearances.
The barged station is the phone that has an active call on a shared line appearance.
The third party is in an active call with the barged station. The third party can be a station or a device external to the system if the call is connected through a gateway or it can be a conference bridge if the barged station is currently in a conference call.
As described in the previous section, if you are in an active call on a line that also appears on other stations, you control whether others who share the line appearance can barge into the call. If you do not want others to be able to barge into the call, you can use the Privacy button to prevent others from seeing the call information or barging into the call.
To barge into a call that is in progress on a shared line, you must first press the line button of the call you want to barge into and then use the navigation control to scroll to the specific call. After the active call is highlighted, press the Barge softkey to be added to the call in progress. If the Party Entrance Tone service parameter is enabled, a barge tone plays to the active participants in the call to alert them that someone has barged into the call. After you have been added to the call and a tone has announced your arrival, you should begin talking and announce your presence.
The Barge softkey adds you to the current call by using the conference capability of the station device. The station device is capable of supporting a three-way conference, so adding a third party to the existing conversation does not interrupt the active voice communication. If another user attempts to barge into the call, that barge attempt will not succeed and the barging party receives the message “Exceed Maximum Parties.” The cBarge function, described in the following section, is similar to barge, but it uses a separate conference bridge resource rather than the limited station conference capability. Because of this, more than three parties can be added to the conference. Although the station’s conference capability is limited, the advantage of barge over cBarge is that no additional conferencing resources are required and there is no momentary break in the conversation while the parties are moved to the conference device. Barge has some limitations:
Supported on Cisco IP Phone models 7940, 7941, 7960, 7961, 7970, and 7971 only.
G.711 is the only supported codec.
Both stations involved in the barge operation must support the barge feature.
The barged station must have the built-in bridge enabled.
The cBarge feature eliminates many of these limitations. See the following section, “cBarge,” for more information.
After you barge into an existing call, in addition to a barge tone (if configured) announcing your presence, the station line display updates to reflect the current call status. Only your display for the active call updates to reflect the barge; the active call display of the other two parties in the call does not change.
If you are the first party to hang up from the barged call, the other two parties are still connected to each other and hear no break in the voice stream. A “beep beep” tone announces your departure. If you barge into a call and the barged station disconnects, a momentary break in the voice stream occurs and then you and the remaining person in the call (the third party) will be connected and you can continue the conversation. Your line display updates to reflect the call as a call between you and the third party. If the barged station terminates the call, the call disconnects and all three parties are released.
After you barge into a call, the person at the barged station can initiate a feature such as hold, transfer, conference, or call park, that causes the barged call to be put on hold. In this case, you, the barging party, are disconnected from the call and the barged party’s feature request (for hold, and so on) proceeds normally. However, if the third party in the call initiates a feature that results in a hold, both you and the barged station remain in the call and the feature proceeds normally. Likewise, if you barge into a call and initiate a feature that results in a hold operation, both the barged station and the third party remain in the call and the feature proceeds normally. When a hold results in two parties remaining in the call while a feature is being initiated, no music is sent to the held parties, and they are still connected and can continue a conversation.
The conference barge (cBarge) feature allows you to add yourself to an active call on a shared line appearance, forming a multiple-party conversation utilizing a conference bridge shared resource device. As described in the previous section, if you are in an active call on a line that also appears on other stations, you control whether others that share the line appearance can barge into the call. If you do not want others to be able to barge into your calls, press the Privacy button.
To cBarge into an active call that is in progress on a shared line, press the line button of the call you want to cBarge into and then press the cBarge softkey to be added to the call in progress, forming a multiple-party conference. The active participants in the call hear a barge tone to signify that someone has been added to the call. After you have been added to the call and a tone has announced your arrival, you should begin talking and announce your presence.
Pressing the cBarge softkey adds you to the current call by using the conference resources that are defined for the system. The conference resource devices are capable of multiple-party conferences, up to the maximum number of participants that you configured for the conference resource device. Barging into the existing conversation causes a momentary interruption in the active voice communication while the call moves to the conference bridge. Other bargers who have the same shared line and try to barge into the same call will succeed in their cBarge attempt so long as there are available conference bridge resources and the total number of participants has not exceeded the maximum number allowed by the conference bridge device configuration. If the cBarge attempt does not succeed, the barger receives notification that the cBarge operation did not complete.
The same terminology used to describe the barge feature also describes the following cBarge scenarios. After you press the cBarge softkey to barge into an existing call, a barge tone announces your presence and the station line display updates to reflect the current call status. Your display and the display of the barged station updates to “To Conference” to reflect the cBarge operation. If possible, the third party’s display also reflects the cBarge operation (if the third party is OnNet using a Cisco IP Phone).
If you are the first party in the cBarged call to disconnect, the other two parties are removed from the conference bridge and reconnected as a direct connection between the formerly barged station and the third party. A momentary break in the voice stream occurs while the connection is changed. A “beep beep” tone announces your departure, and the displays of the barged station and the third party change to reflect the direct connection between the two devices. If you cBarged into a call and the barged station disconnects, a momentary break in the voice stream occurs, after which you and the remaining person in the call are connected directly and you can continue the conversation. Your line display updates to reflect the call as a call between you and the other party. If the third party in the call disconnects, a momentary break in the voice stream occurs, and then you and the barged station are connected and you can continue the conversation. Your line display and the barged station’s line display updates to reflect the call as a call between you and the barged station.
After you barged into a call via cBarge, either the person at the barged station or the third party can initiate a feature such as hold, transfer, conference, or call park. In this case, both you and the remaining party, either the barged station or the third party, remain in the call and the feature proceeds normally. Likewise, if you initiate a feature that results in a hold operation, both the barged station and the third party remain in the call, and the feature proceeds normally. When a hold results in two parties remaining in the call while a feature is being initiated, no music is sent to the held parties, and they are still connected and may continue a conversation.
The join feature allows you to select a number of calls in the same line appearance and join together with these calls in a conference. You will be a participant in the conference. Alternatively, the direct transfer feature offers the ability to connect two selected calls but not participate in the call, as described later in the “Direct Transfer” section. Both join and direct transfer are limited to calls that are in the same line appearance and cannot be used for calls on different lines.
Join makes it easy to form a conference between you and other calls that already appear on the same line appearance on your station. First, select the calls in progress at your station that you want to conference. To select the calls, use the phone’s navigation control to highlight the calls that you want to join, and then press the Select softkey for each call that you want to select. A check mark appears next to the selected call to indicate that it has been selected. You can select your currently active call and any other held calls that are not marked remote in use, meaning that they are active calls on another station. Second, press the Join softkey to connect you with the selected calls in a conference.
Tip
To save keystrokes when selecting calls, if no calls have been selected via the Select softkey, the currently active call and the currently highlighted call are the default selected calls for the feature. If you just want to join the currently active call and a single held call, for example, you just highlight the held call and press Join during an active call.
You can join individual calls as well as one existing conference call if you are the controller of the existing conference call. If you select two conference calls to be joined, the join operation will not succeed.
Note
A CallManager service parameter, Drop Ad Hoc Conference, determines how conferences such as those created with the join feature are terminated. See the section “Dropping Conference Participants” for more information.
Direct transfer enables you to join two calls from the same line appearance together into a single call. You will not be included in the call. If you want to form a conference in which you do participate, use the join feature described in the preceding section.
Direct transfer is an easy way to form a new call between two calls that already appear on your line appearance. First, use the navigation control on your phone to select the calls at your station that you want to connect together directly. Next, press the DirTrfr softkey to connect the selected calls together. The two parties will be connected to each other in a new call and will no longer be present on your station.
Generally, one of the two calls you plan to connect with another call is your currently active call. If that is the case, simply use the navigation control to highlight the other call and then press the DirTrfr softkey. You do not have to be in an active call to use direct transfer. You can scroll to any two held calls (so long as they are not marked remote in use, meaning that they are active at another station), select each one by highlighting the call, press the Select softkey, and then press the DirTrfr softkey to directly connect the two selected calls.
You can use direct transfer for individual calls as well as one existing conference call if you are the controller of the existing conference. In the case of a conference call, the individual call that you select will be added to the existing conference when you press the DirTrfr softkey and you will no longer be a part of the conference. If you select two conference calls to be directly transferred, the direct transfer will not succeed.
The immediate divert (iDivert) feature enables you to divert a call to voice mail. You must have a voice mailbox configured for the iDivert feature to work. The following types of calls can be used with the iDivert feature:
Incoming call that is currently ringing but not yet answered—. Press the iDivert softkey when you have an incoming call to immediately transfer the call to your voice mail.
Call on hold—. Highlight the held call and press the iDivert softkey to immediately transfer the held call to voice mail.
Active call—. Inform the caller that you are sending him or her to voice mail to leave a message, and then press the iDivert softkey to send the call to your voice mail.
Outbound call that you initiated—. After you are connected to the called party, you can request the information that you want to have in the form of a voice message, and then press the iDivert softkey to immediately transfer the person you called to your voice mailbox. If you make an outbound call, and are interrupted and have to put the person on hold, you may explain, prior to putting the person on hold, that you will either get back to the person right away or transfer the call to voice mail. If after you put the call on hold, you realize that you’ll be detained and not be able to resume the call, you can highlight the held call and press the iDivert softkey to transfer the call to voice mail.
The buttons along the right side of the station are considered line/feature buttons. Any line/feature buttons that are not configured for lines can be used for other functions, including speed dial numbers, or service URL buttons, which allow users to press a one-button shortcut to an XML service. You assign line/feature buttons via the phone button template assigned to users’ phones (Device > Device Settings > Phone Button Template).
After you have assigned a button template with a combination of lines, speed dial buttons, and service URLs, advise users that they can assign speed dials and/or service URLs via the Cisco CallManager User Options web page, as shown in Figure 3-6.
Configuring line/feature buttons for speed dial or service URLs provides users with access to the desired number or service with one quick button press. In addition to the line/feature buttons that you assign to the phone button template, the abbreviated dialing feature provides more speed dial buttons for a grand total of up to 99 speed dials, all configurable in the Cisco CallManager User Options web page. As shown in Figure 3-7, the speed dials are broken into two groups:
Speed dial settings on the phone—. These speed dials refer to speed dial buttons you have configured on the phone button template.
Speed dial settings not associated with a phone button—. These speed dials refer to speed dials associated with the abbreviated dialing feature (described in the section that follows).
Abbreviated dialing is described in the following section.
Abbreviated dialing allows you to dial a one- or two-digit index number that has been associated with a speed dial number. After you start dialing the index number, an AbbrDial softkey dynamically appears on the phone. Press the AbbrDial softkey to speed dial the number associated with the index number that was entered.
Users configure the speed dial numbers for abbreviated dialing in the Cisco CallManager User Options web page, as shown in Figure 3-7. The speed dials are numbered; the number is the index number that a user must dial prior to pressing the AbbrDial softkey. For example, using the speed dial settings shown in Figure 3-7, when Allen wants to order lunch at Joe’s Pizza, he dials 8 and then presses the AbbrDial softkey. CallManager automatically dials 9, the access code Allen’s company requires to call an OffNet destination, followed by the number: 214-555-1121.
To use abbreviated dialing, the phone must be on-hook. The AbbrDial softkey is not configurable on the softkey template. It appears dynamically when users begin entering a digit on the phone. However, the softkey only functions if the user has configured an associated speed dial number via the Cisco CallManager User Options web page.
Tip
Another way to access frequently called numbers is the IP phone service My Fast Dials. By using this service, you can create fast dials that you access through the services button or via a services URL button that has been configured on the phone button template. Because you can assign a specific IP phone service to a line/feature button that has been configured for service URL, you can access the My Fast Dials service with a single button press, and then select the fast dial of your choice by dialing a one- or two-digit index number for the entry that you want to call. Single-button access to a service is not limited to the My Fast Dials service, but this is probably one of the more frequently used service URLs that users will want to assign to a line button. You can learn more about My Fast Dials in the section “Cisco Personal Address Book” in Appendix A, “Feature List.”
You can drop conference participants from an Ad Hoc conference if you are the conference controller. An Ad Hoc conference is a type of conference in which a controlling station, the conference controller, manually adds conference participants one at a time. The conference controller can remove participants from a conference using two different Ad Hoc conference features:
Drop Last Party—. Enables you to drop the last party who joined the conference
Drop Any Party—. Enables you to drop a specific participant in the conference
A CallManager service parameter, Drop Ad Hoc Conference, determines how an Ad Hoc conference such as those created via the Confrn, Barge, and Join softkeys, terminates. The options are as follows:
Never—. The conference remains active a) after the conference controller hangs, and b) after all OnNet parties hang up. Choosing this option means that if OnNet parties conference in OffNet parties and then disconnect, the conference stays active between the OffNet parties, which could result in potential toll fraud.
When Conference Controller Leaves—. Terminate the conference when the conference controller hangs up or when the conference controller transfers, redirects, or parks the conference call and the retrieving party hangs up.
When No OnNet Parties Remain in the Conference—. Terminate the conference when there are no OnNet parties remaining in the conference.
You can learn more about Ad Hoc conferences in Chapter 5, “Media Processing,” and in the section “Conference/Confrn” in Appendix A.
During an active or held Ad Hoc conference, the conference controller can press the RmLstC softkey to drop the last party who joined the conference. You must configure the RmLstC softkey on the softkey template and assign the template to phones for it to be available (Device > Device Settings > Softkey Template). Alternatively, the ConfList softkey enables the conference controller to view a list of conference participants and drop the selected station, as discussed in the following section.
During an active Ad Hoc conference, conference participants (including the conference controller) can press the ConfList softkey to view the list of conference participants. Pressing the ConfList softkey invokes an application that runs as a service on the station and provides a list of conference participants. The conference controller can drop a participant by using the phone’s navigation control to scroll through the list to highlight a name/number and then pressing the Remove softkey to drop the highlighted participant from the conference. You can repeat this operation until all parties who you want to drop from the conference have been removed. The ConfList softkey is automatically available and requires no configuration.
You can specify, on a per-line basis, the types of information that users see when calls are forwarded to their stations. Each line on a station can display different forwarded call information based on the settings configured in the Forwarded Call Information Display area on the Directory Number Configuration page in CallManager Administration (Device > Phone > find and select a phone > click a line number).
To better understand the display capabilities that can be configured for each line on a station, the following explanations help to clarify some common terms.
Each line on your station that can be used for calls has an associated directory number. If you originate a call, the line that you use to place the call, for display purposes, is referred to as the calling line ID (CLID) or simply calling party number. There is also a display name associated with that line on your station, and it is referred to as the calling name ID (CNID) or simply the calling party name.
When you make a call by dialing the directory number of the person you want to reach, the number that you dial is referred to as the original dialed number (ODN). Because calls might be forwarded one or more times, the original dialed number might not be the actual number of the line that is answered when the call is completed. The final directory number used to extend the call when the call is actually completed is referred to as the redirected dialed number (RDN).
The following check boxes are provided on the Directory Number Configuration page in CallManager Administration. All can be enabled or disabled by selecting/deselecting the check box. These check boxes control the display of information for calls that have been forwarded to the phone. By default, for forwarded calls that arrive at your phone, you will see the original dialed number and the calling party name.
Caller name (also known as calling name ID [CNID])—. Enabled by default
Caller number (also known as calling line ID [CLID])—. Disabled by default
Redirected number (also known as redirected dialed number [RDN])—. Disabled by default
Dialed number (also known as original dialed number [ODN])—. Enabled by default
Consider the following example: A call arrives at John’s station on the line associated with directory number 4444. Delon Whetten originated the call on line 1111, and called Anne Smith at 2222. Anne had forwarded 2222 to Chris Pearce at 3333. Chris had forwarded 3333 to you at 4444. In this example, the calling party name is Delon, and the calling party number is 1111. The original dialed number is 2222. The redirected dialed number is 3333. When the phone arrives at John’s station, the information that displays depends on the display options that you configured for John’s station. Table 3-1 shows the information that displays for each of the display option combinations you can configure.
Table 3-1. Call Info Display
Caller Number Disabled Caller Name Enabled | Caller Number Enabled Caller Name Enabled | Caller Number Disabled Caller Name Disabled | ||
|---|---|---|---|---|
Dialed Number Enabled Redirected Number Disabled | Forward 1111 For 2222 | Forward Delon Whetten For Anne Smith | Forward Delon Whetten (1111) For Anne Smith (2222) | Forwarded For 2004 |
Dialed Number Enabled Redirected Number Enabled | Forward 1111 For 2222 By 3333 | Forward Delon Whetten For Anne Smith By Chris Pearce | Forward Delon Whetten (1111) For Anne Smith (2222) By Chris Pearce (3333) | Forwarded For 2222 By 3333 |
Dialed Number Disabled Redirected Number Enabled | Forward 1111 By 3333 | Forward Delon Whetten By Chris Pearce | Forward Delon Whetten (1111) By Chris Pearce (3333) | Forwarded By 3333 |
Dialed Number Disabled Redirected Number Disabled | Forward 1111 | Forward Delon Whetten | Forward Delon Whetten (1111) | Forwarded |
The Line Text Label field on the Directory Number Configuration page (Device > Phone > find and select a phone > click a line) enables you to configure a line with a text display rather than a directory number display.
For a station with only a few lines (perhaps a private line and a second line that is shared with another station), using the directory numbers for identification will probably suffice. For users who typically answer calls for multiple people and have numerous shared lines, however, the text display with names for each line is much more acceptable. If a line has an incoming call for John Alexander, a quick glance will let the user know that it is a call on John’s line. It is then much easier to quickly answer with a greeting such as “Hello, John Alexander’s office.”
The Alerting Name field enables you to configure the name that you want displayed on the calling station when a call is in the Alerting (ringing) state. For example, if you dial John Alexander at 214-555-1000, while the call is ringing at John’s phone, the display on your phone shows “To John Alexander (2145551000).” The QSIG protocol uses this field as part of the Identification Services, but this field applies to all calls and is a part of the caller ID information that CallManager sends. The alerting name may differ from the name that displays when the call is connected. If you do not configure an alerting name, only the phone number or “Name Not Available” might display on the calling phone.
Auto answer means that an incoming call is automatically answered at the station. A headset or speakerphone must be enabled and idle (not in use) for auto answer to occur. Two types of auto answer are available:
Auto answer with headset—. Provides hands-free operation with the use of a headset
Auto answer with speakerphone—. Provides a hands-free point-to-point intercom between two IP stations
These capabilities prove especially useful for users who receive many calls during the day and need hands-free operation. You can configure the auto answer functionality on the Directory Number Configuration page for any line on a station (Device > Phone > find and select a phone > click a line).
When auto answer with headset is enabled for a particular line on a station, the user hears a single beep (also called a zip tone) announcing the call, and then the call is automatically answered. If the user is currently in an active call, the new incoming call is not automatically answered. Auto answer with headset requires the use of a headset. The call is not automatically answered if the headset is not plugged into the back of the station and the HEADSET button enabled. Because the feature is designed so that calls will be answered automatically, auto answer with headset cannot be assigned to shared line appearances.
Auto answer with speakerphone provides a hands-free intercom between two stations. If a call is already active on the station when another incoming call arrives, auto answer will not occur and the call continues as a normal incoming call.
To allow a station to use intercom functionality to reach another station, you configure auto answer with speakerphone on a dedicated line on a station. The dedicated line has a directory number associated with it, for example 1111. Any user who dials 1111 is immediately connected to the station via the speaker. You should probably limit the number of people who could dial the intercom number, and you can achieve that limitation by defining a partition for 1111 and restricting the stations that have access to the 1111 partition in their calling search space. To provide single-button intercom capability, assign a speed dial to the line button on the stations that can access the intercom number, and the stations will be able to use the intercom line by simply pressing the speed dial button.
The media termination route points enable an application to answer a call, determine the appropriate action to take for the call, and then route the call based on that determination. To allow you to direct calls to an application and allow the applications to process the calls, you can define a route point associated with a directory number as a virtual station capable of receiving calls and taking action on the calls. You can provision calls to be sent to route points based on the appropriate criteria that qualify the calls that need processing by a particular application. The route point will receive the calls and allow the application to do whatever processing is required for the call. The call answered by the application can later be redirected to a CTI port or a station. The route point can receive multiple simultaneous calls, and therefore the media and port for the each new call is provided by the route point. The following features are available for your use in the application:
Answer
Multiple active calls
Redirect
Hold
Un-hold
Drop
With these features available to applications to take action on calls that are sent to the application, you can develop very powerful applications for special call handling at a route point. In a simple call distribution example, your application would do the following:
Answer a call answered at the route point.
Play an announcement that the call will be directed to the next available agent.
Place the call on hold.
Monitor the available agents and when one becomes available redirect the call to the available agent.
The route point provides a place to hang on to the call and direct the activities of the call to get it to the right destination.
Station devices that CallManager supports, as shown in Figure 3-8, include H.323 stations, voice mail/unified messaging, IP phones, Unicast conference devices, transcoders, and voice applications such as Cisco IP Communicator. Chapter 5 discusses conference devices and transcoders in detail. In addition to explaining the supported devices, this section differentiates a user from a station and categorizes station devices by protocol and then subdivides them by device capabilities.
The three basic protocols CallManager uses to communicate with station devices are as follows:
Skinny Client Control Protocol (SCCP)
H.323
Computer Telephony Integration (CTI)
The CTI interface provides Telephony Application Programming Interface (TAPI) and Java TAPI (JTAPI) application layer support. Although stations can reside on the other side of a gateway, the stations discussed in this chapter are limited to those that communicate directly with CallManager. Refer to Chapter 4 for gateway communication and protocols such as Media Gateway Control Protocol (MGCP).
CallManager provides call control on behalf of stations or gateways. In the case of stations, stations indicate requests for service to CallManager, and CallManager acts on the requests for service. The requests for service include such tasks as device initialization, device configuration information, call origination, call acceptance, call termination, call information, media statistics, and feature activation. CallManager provides the call control engine for the devices that are configured in the CallManager database via CallManager Administration.
The signaling from CallManager to the station is the call signaling path. The media path for the exchange of media between stations does not pass through CallManager. The stations stream media directly between the stations or directly from a station to a media processing device, such as a Unicast conferencing device or a transcoder.
SCCP is a lightweight, simple, stimulus protocol. The signaling path is a TCP/IP connection that the station establishes to CallManager. The station interface message set encompasses three basic areas:
Registration and station management
Call control
Media stream (audio) control
CallManager directs the establishment of the media connection, but the station and device to which the station is connected establish the media stream directly to each other. You can learn more about SCCP in Appendix C.
CTI provides a communication interface into CallManager. Both JTAPI and TAPI make use of CTI communication with CallManager. The CTI interface is specific to communication between the Cisco TAPI service provider and CallManager. The TAPI service provider is a layer external to CallManager that is used by TAPI applications to communicate with CallManager without requiring knowledge of the CTI interface.
Microsoft’s TAPI for Windows simplifies telephony application development. The interface abstracts the telephony services from the actual hardware and software infrastructure of CallManager. Applications developed with TAPI are more portable and less subject to change when the CallManager infrastructure changes.
JTAPI is a Java-based interface that provides similar abstraction for Java-based development. JTAPI also abstracts the application development from the CallManager infrastructure. JTAPI extends application portability to include not only independence from CallManager infrastructure, but also independence from any particular operating system.
Figure 3-9 shows the role of the CTI protocol in the application infrastructure of CallManager. You can learn more about the CTI protocol in Appendix C.
An H.323 endpoint is a device or software application that communicates with CallManager using the H.323 protocol specification. The Microsoft NetMeeting software application is an example of an H.323 endpoint.
The H.323 Recommendation from the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) contains a set of very complex protocols that work together under the H.323 protocol umbrella. These protocols (for example, H.225.0 and H.245) manage the connection and the media for a communication session. The frame structure for the multiplex layer allows for a vast multitude of services. However, the complexity is more extensive than is required for simple voice communications. H.323 stations must maintain state information for a call and thus are relatively complex. By contrast, SCCP provides both features and services for relatively low-cost user stations that require no protocol state processing.
Figure 3-10 shows the relationship of the protocols under the H.323 umbrella specification. You can learn more about the H.323 protocol in Appendix C.
The family of Cisco IP Phones has evolved from the 79xx series IP Phones to the expanded 79xxG series IP Phones. The G stands for global and indicates a phone with icons on the buttons rather than words. The interface to the full family of Cisco IP Phones uses the same SCCP. As the Cisco IP Phone family evolved to include the 79xxG series, SCCP expanded, but the interface is backward compatible to support the earlier 79xx series IP Phones.
The Cisco IP Phone family includes the following models:
Cisco IP Phone 7902G
Cisco IP Phone 7905G
Cisco IP Phone 7912G
Cisco IP Phone 7940G
Cisco IP Phone 7941G
Cisco IP Phone 7960G
Cisco IP Phone 7961G
Cisco IP Phone 7970G
Cisco IP Phone 7971G-GE
Cisco IP Phone 7985G
In addition, the family of phone products includes the following:
Wireless IP Phone 7920
IP Phone Expansion Module 7914
IP Conference Station 7936
The product set also extends to include the Cisco IP Communicator, Cisco ATA 186 with 10BASE-T uplink, Cisco ATA 188 with 10/100BASE-T uplink, and the analog phone gateways Cisco VG248. Figure 3-11 shows the Cisco IP Phone family as well as the Cisco IP Communicator.
The Cisco IP Phone 7902G is an entry-level business set that is good to use in areas with low telephone traffic and no need for application support (because there is no display). The phone provides a single line with a single directory number. With no display, there are fixed feature keys rather than softkeys to support redial, transfer, conference, and messages.
The Cisco IP Phone 7902G supports inline power and offers a visual message waiting indicator to indicate voice messages and a hold button. There is a speaker for call monitoring, but no microphone.
The Cisco IP Phone 7905G is a single-line, inline-powered set that you would most likely use in common areas with low to medium telephone traffic, such as a hallway, manufacturing floor, reception area, or office cubicle. The phone provides a pixel-based display with five lines of display text, softkeys, and the standard date/time/menu title. Like the Cisco IP Phone 7902G, the phone provides a dedicated hold key and a visual message waiting indicator. The phone has speaker capability for call monitoring, but no microphone.
The Cisco IP Phone 7912G is single-line, inline-powered phone best suited for low to medium telephone traffic, such as an office cubicle. The Cisco IP Phone 7912G offers a five-line pixel-based display, softkeys, the date/time/menu title. The Cisco IP Phone 7912G includes a 10/100BASE-T, two-port Ethernet switch, a dedicated hold button, and visual message waiting indicator. The phone has speaker capability for call monitoring, but no microphone.
The Cisco Wireless IP Phone 7920 is a wireless IEEE 802.11b IP Phone that supports up to six lines/speed dials. The pixel display provides feature access via the four-way navigation control and menu button, plus a hold and mute button and two softkeys for dynamically presented calling options. The voice encoding in the phone supports both G.711 and G.729A. Standard or extended Li-ion batteries are available.
Cisco IP Phones 7940G, 7941G, 7960G, 7961G, 7970G, and 7971G-GE offer a large display pane, multiple softkeys, and allow web-based applications to be launched from the services button. The user interaction for making calls, phone setup and configuration, and use of features is enhanced by the use of the large display and user-friendly interface. The Cisco IP Phones 79410 and 7941G provide two line/feature buttons, the Cisco IP Phones 7960G and 7961G provide six line/feature buttons, and the Cisco IP Phones 7970G and 7971G-GE provide eight line/feature buttons.
The Cisco IP Phones 7940G, 7941G, 7960G, 7961G, and 7970G all include the following:
Display area that provides visual information to the user based on the button selected.
A messages button, which provides access to voice mail.
A ? or i button, which provides help functionality.
A services button, which allows access to web-based applications to extend the capability of the phone.
A directories button, which provides access to the directory capabilities of the phone, which include calls received, calls placed, and calls missed. Personal and corporate directories can also be added to the directory functionality.
A settings button, which allows access to phone settings such as screen contrast, ring types, network phone configuration, and more.
Softkey buttons (four on the Cisco IP Phones 7940G, 7941G, 7960G, and 7961G and five on the Cisco IP Phones 7970G and 7971G-GE) provide access to call processing-related features.
Numeric keypad.
Navigation control via the two- or four-way rocker control.
Volume control.
Programmable line/feature buttons (eight on the Cisco IP Phones 7970G and 7971G-GE, six on the Cisco IP Phones 7960G and 7961G, and two on the Cisco IP Phones 7940G and 7941G).
SPEAKERPHONE, MUTE, and HEADSET buttons.
In addition to the capabilities in the preceding list, Cisco IP Phones 7961G and 7941G also provide a high resolution display (320 × 240), lighted line keys, IEEE standard 802.3af inline power, and support for Cisco legacy power. Cisco IP Phone 7971G-GE provides an internal 10/100/1000BASE-T two-port Ethernet switch with 802.1Q capability. Also, Cisco IP Phones 7970G and 7971G-GE include the following features:
High-resolution, large graphical display (320 × 234), supporting 12-bit color depth
Touch screen display
LED line lamps
Adjustable backlit display
The ? or i button, directories button, and services button each have an associated URL. Each URL identifies for the phones the location of an XML service accessed by the phone when the appropriate button is pressed. A set of default URLs come pre-installed with CallManager and are accessible via the Enterprise Parameters Configuration page (System > Enterprise Parameters). You can override the URL to allow the phone capabilities to be extended. The section “Cisco IP Phone Services” describes how you can use the services button to extend capabilities.
The Cisco IP Phone 7914 Expansion Module adds 14 illuminated buttons to Cisco IP Phone 7960, 7970, and 7971, or 28 additional buttons when two Cisco IP Phone 7914s are added. The Expansion Module has a large LCD display for directory numbers or speed dial names.
The Cisco IP Conference Station 7936 is an IP-based full-duplex hands-free conference station. In addition to basic calls, the conference set provides the following standard features:
Hold
Transfer
Mute
Call park
Pickup
You get 360-degree room coverage provided by a digitally tuned speaker and three microphones. An external microphone kit includes two optional microphones for additional coverage in larger rooms. The conference station is configured as easily as any other station.
The Cisco IP Phone 7985G is a SCCP-based personal desktop audio/video phone that, in addition to standard audio calls, offers all the components necessary for video calls—camera with lens cap, large 8.4″ LCD display, speakerphone with a headset jack, keypad, and handset—integrated into a single IP phone. The phone supports H.264, H.263+, H.263, and H.261 video standards, IEEE Power over Ethernet (PoE), automatic port configuration using Cisco Discovery Protocol (CDP), and includes a 2-port Ethernet switch for a co-located PC.
Video calls occur just like audio phone calls: the user simply dials the number and if the called party has a video-enabled endpoint, the call automatically proceeds as a video call. If the called party does not have video capabilities, the call occurs as an audio-only call. The Cisco IP Phone 7985G provides forward, conference, transfer, and hold capabilities on video calls, all through an intuitive and familiar Cisco IP Phone user interface.
Cisco IP Communicator is a software-based IP phone application that runs on a PC. IP Communicator has VPN client support and acts as a supplemental telephone when traveling, a telecommuting device, or a primary desktop telephone. The functionality is very similar to a Cisco IP Phone 7970G, although for IP Communicator you use a mouse for touch screen functionality of the Cisco IP Phone 7970G phone.
To function, IP phones must register with CallManager. The phones first determine a prioritized list of CallManager nodes with which to register. After a list of CallManager nodes is determined, the phone attempts to register with the first (primary) CallManager node. If registration succeeds, the primary CallManager node is responsible for handling the exchange of SCCP messages necessary for call control for the IP phone. The IP phone also establishes and maintains a connection to a secondary CallManager node, with which it registers in the event that the phone loses connectivity with the primary CallManager node.
The phone sends a KeepAlive message to the server with which it is currently registered. The interval between KeepAlive messages to the primary and secondary CallManager nodes is configurable via the Station KeepAlive Interval and Station and Backup Server KeepAlive Interval service parameters respectively (Service > Service Parameters > select a server > Cisco CallManager); the default interval is 30 seconds for the primary node and 60 seconds for the backup node. The phone detects connection problems with CallManager through KeepAlive or TCP/IP errors on call signaling traffic. If the phone cannot reestablish the connection to the primary CallManager node, the phone registers to the secondary CallManager (failover) and continues operation. The phone attempts to reconnect to the primary CallManager and if successful, the phone unregisters from the secondary CallManager and reregisters with the primary CallManager (fallback). This process is known as failover and fallback.
You can also configure a Cisco Survivable Remote Site Telephony (SRST) reference as the last device in the CallManager list. This proves especially useful in a remote site configuration where the phones and CallManager are connected over a WAN network. SRST provides users with fallback support for the IP phones that cannot access the primary, secondary, or tertiary CallManager in the CallManager because of CallManager failure or loss of connectivity across the WAN. For the remote sites attached to Cisco multiple-service routers across the WAN, SRST ensures that your remote users receive continuous (although minimal) service by providing call handling support directly from the SRST router.
The phone can use Domain Name Server (DNS) or Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) to determine initially the IP address of the prioritized list of CallManager nodes to which the phone can register. Although each of these services can ease implementation, they are not all required.
DNS, for example, is not required if CallManager nodes use IP addresses as their names in the Cisco CallManager Configuration page (System > Cisco CallManager); for networks not running DHCP, you can use static IP addressing. Figure 3-12 shows the interaction of the phone with DNS, DHCP, TFTP, and CallManager during the initial registration.
DHCP is a service provided with Microsoft Windows or the Cisco Network Registrar that automatically assigns IP addresses to devices on the network. Cisco IP Phones are DHCP-enabled by default. If DHCP is not in use, use the settings button on the phone to disable DHCP and manually configure the IP address of the phone and the TFTP server address. Disabling DHCP and manually configuring the IP addresses prevents mobility of the phone. Assuming DHCP, DNS, and TFTP services are running, the phone goes through the following sequence of events to register initially with a CallManager node:
The phone requests an IP address from the DHCP service.
As part of the DHCP response, the DHCP server returns the TFTP server address to the phone.
The TFTP address can include two TFTP servers for redundancy. If the phone encounters a TFTP timeout, it will try the other TFTP address. The phone supports redundancy through static configuration on the phone, through DHCP option 150, and through DNS resolution. IP phones have an order of preference that they use to select the address of the TFTP server. If the phone receives conflicting or confusing information from the DHCP server, the phone uses the following sequence to determine what information is valid:
You can configure the phone with a TFTP server address through the phone configuration. This manually configured address overrides the TFTP address sent by the DHCP server.
If a phone does not receive a TFTP server address from the DHCP server (either via Option 150 or Option 66), the phone will attempt to resolve the DNS name CiscoCM1. It is not necessary to name the TFTP server CiscoCM1, but you must enter a DNS name record to associate CiscoCM1 with the address or name of the TFTP server. This name can resolve to multiple addresses. The phone uses the first two addresses to populate the TFTP Server 1 and TFTP Server 2 fields.
The phone uses the site-specific Option 150. This option is a list of 32-bit IP addresses. The phone uses the first two addresses to populate the TFTP Server 1 and TFTP Server 2 fields.
The phone uses the value of Next-Server in the boot process. This DHCP configuration parameter has traditionally been used as the address of the TFTP server. When configuring BOOTP servers, this field is typically referred to as the address of the TFTP server. This information is returned in the siaddr field of the DHCP header.
The phone also accepts the Optional Server Name parameter. This DHCP configuration parameter is the DNS name of a TFTP server. This Optional Server Name field can contain a DNS name or a dotted-decimal IP address. Additionally, this name can resolve to multiple addresses. The phone uses the first two addresses to populate the TFTP Server 1 and TFTP Server 2 fields.
The phone accepts Option 066, which is the name of the boot server. Option 066 normally replaces the Optional Server Name field when option overloading occurs. This Optional Server Name field can contain a DNS name or a dotted-decimal IP address.
After the phone receives the TFTP address, the phone requests its configuration information from the TFTP server. The configuration information includes a prioritized list of up to three CallManager nodes. The configuration information is in the form of an Extensible Markup Language (XML) file. The XML file contains additional information, including the phone load version.
The phone establishes communication with the highest CallManager node in the prioritized list and sends a registration request. If the phone requested a configuration (.cnf) file and not an XML file, the phone also sends a version request and checks the phone load version. If the phone firmware version matches the current phone firmware version, the phone continues with the registration process. If the phone needs a new firmware version, the phone aborts the registration process and downloads a new version of the phone firmware from the TFTP server. After the phone loads the new firmware, the phone restarts the registration process. If the phone processed an XML file for the configuration information, the version has already been verified and is not requested from CallManager.
When the phone successfully registers, the DHCP and TFTP communications are not repeated unless the phone experiences a hard reset through a power off/on sequence or by a reset from CallManager Administration or experiences a TFTP timeout.
Cisco IP Phone models 7940G, 7941G, 7960G, 7961G, 7970G, and 7971G-GE work in concert with CallManager to provide additional levels of security over and above the security provided by the network infrastructure. Phone security targets three areas:
Configuration
Device identity and configuration file security
Media privacy
The basic functionality to provide the additional level of security includes Transport Layer Security (TLS), secure Real-Time Transport Protocol (SRTP), and authenticated configuration files for the phones. TLS provides call signaling integrity and privacy between CallManager and IP phones. The SRTP adds encryption to the media stream between phones to provide integrity and privacy at the voice stream level. Authentication at the configuration file level adds certificates to provide device identity security.
The following phone configuration options affect the degree of security enjoyed by IP phones:
Gratuitous ARP
PC Port
PC Voice VLAN Access
Settings Access
These fields appear on the Phone Configuration page in CallManager Administration (Device > Phone > find and select a phone). All are enabled by default.
Tip
To change these settings quickly for a number of devices, use BAT (Configure > Phones > Update Phones > Use query > run a query for the phone models you want to update settings for).
IP phones accept Gratuitous Address Resolution Packets (GARP). Because some devices announce their presence on the network with GARP, a false GARP message could be sent to the phone with a false claim to be the default router. To block this possibility, you can disable GARP via the Gratuitous ARP field.
Many IP phones have a PC port to which a user can attach a PC device. In lobby or conference rooms, you might not want PC devices to be attached to the phones. You can disable this capability via the PC Port field.
For a phone that does need PC connectivity enabled, you can configure the phone to isolate the VLAN from a PC attached to the phone by disabling the PC Voice VLAN Access field. Packets from the network come to the phone and are also sent to the PC port. Some of the packets are destined for the phone and some are destined for the PC. You can configure the phone for special handling of packets that are tagged with the voice VLAN. If you disable the PC Voice VLAN Access field, any packets received from the switch and tagged as VLAN will not be sent to the PC port. Any packets received from the PC port that are tagged with voice VLAN will be dropped. This field allows you to disable access to the voice VLAN from the device attached to the PC port of the phone.
You might want to control access from the phone to the phone’s own network configuration (settings button). You can restrict or disable access to network configuration at the phone by choosing Disabled or Restricted in the Settings Access field. The Restricted option means that only user preferences and volume settings can be changed; Disabled means that when the settings button is pressed, no options display at all and no volume settings can be changed.
Device identity security enables you to ensure that all CallManager devices in the system are legitimate devices and that the clients are connected to a legitimate CallManager node. If you have a device on the network that is not a legitimate device, you could have calls being made that are unauthorized or you could have excessive signal traffic directed at CallManager and interfering with normal call traffic signaling. If a software entity on your network masquerades as CallManager, some of your stations could be removed from the system without the knowledge of the user at those stations. Authentication between CallManager and the end device is designed to make hijacking of phone sessions significantly more difficult.
Phone models that support security request and receive a digitally signed Certificate Trust List (CTL) file from the TFTP server. The CTL file provides public keys for all CallManager nodes and the security tokens. The list provides the phone with the trusted list of CallManager servers. The phone examines the signature and verifies it using the security token information from the CTL file. The configuration files received by the phone from the TFTP server are signed and verified by the phone.
The phone establishes a TLS session with CallManager to begin the registration process. CallManager has a certificate that is included in the CTL and is used by the phones during TLS session establishment. The phone also has a certificate that it uses to authenticate the phone to CallManager. With mutual authentication, the TLS handshake establishes a secure connection, authenticating the certificates in CallManager and in the phone.
A number of factors contribute to the security mode you choose for your CallManager cluster, such as the phone devices in the network, the level of security that those phones can support, and the level of security required for your network. The Cluster Security Mode enterprise parameter (System > Enterprise Parameters) determines the security mode for the cluster. Two choices exist:
Nonsecure, which allows phones to register with no security
Mixed security, which disables auto-registration and allows the registration of both secure devices and nonsecure devices
Device security is controlled at the device and system levels. The device level takes priority. If the Device Security Mode field on the Phone Configuration page is set to Use System Default, the value specified in the Device Security Mode enterprise parameter determines the device security. Three options exist:
Authenticated (only device authentication and signaling authentication)
Encrypted (device authentication, signaling authentication, and encryption)
Nonsecure (no device authentication, signaling authentication, or encryption)
If signaling authentication is established between CallManager and both endpoints and both endpoints are capable of media encryption, media privacy is possible for the call between the phones. To ensure privacy of the media (voice data), the phones encrypt the media they exchange. To have encrypted media, both ends of the connection must be authenticated and you must have SRTP-capable endpoints. Any intermediate connection that does not support SRTP, such as a transcoder, media termination point (MTP), monitoring bridge, or intercluster call, excludes the call from encryption eligibility. These devices are described in more detail in Chapter 5.
CallManager enables encryption by creating the media session encryption key and salt (see the following sidebar for more information) for each call that requires encryption, and securely delivering the key and salt to each of the endpoints. After these keys and salt are securely delivered to the phones, the phones use the key pairs for the SRTP media session to protect the media. The encryption is established for each direction of the call. For a single voice call, there are two independently encrypted streams, one in each direction, for your voice conversation.
SCCP is a simple stimulus interface between the Cisco IP Phone and CallManager. The communication takes place over a TCP/IP connection that the phone establishes to CallManager on port 2000. Once established, the connection remains as long as the phone is capable of initiating or accepting calls. SCCP provides a means of receiving stimulus events from the phone such as off-hook, on-hook, and button press events, which include keypad digits, fixed keys, softkeys, and line keys. SCCP also provides a means of sending control information to the phone to drive the specific behavior required for the phone to provide the user with the correct information as calls are made and features are handled. You can review the details of SCCP in Appendix C.
Cisco IP Phone models 7905, 7912, 7920, 7940, 7941, 7960, 7961, 7970, and 7971 are capable of deploying customized IP phone services. The services make use of the keypad, softkeys, and display to interact with the user. The services are deployed using the HTTP protocol, which is available on standard web servers such as Microsoft Internet Information Server (IIS). Users access IP phone services by pressing the services button. The enterprise parameter URL Services specifies the web page that gets called when the services button is pressed.
When the user presses the services button, the display provides a list of services that have been subscribed to the phone. The user can select a menu item by either scrolling to it and pressing a softkey or by pressing the number associated with the menu item.
You add IP phone services to CallManager in the Cisco IP Phone Services Configuration page (Feature > Cisco IP Phone Services). After the service is made available in CallManager, users subscribe and unsubscribe to the list of available IP phone services in the Cisco CallManager User Options web page. After subscribing to a phone service, the user can access it by pressing the services button or a line/feature button that has been configured for a service URL. (See the section “Service URLs/Speed Dials” in this chapter.)
When the user selects an IP phone service, the phone uses its HTTP client to send the HTTP request to the web server that the URL address specifies. The phone is not a web browser and cannot parse HTML. The response to the HTTP request is either plain text or packaged in specifically defined XML wrappers. The phone receives the object returned by the web server and interacts with the user as specified by the text or XML data type supported by the phone. For example, a simple IP phone service might be a weather lookup. The user subscribes to the Weather service, presses services, and selects the Weather service. Text on the phone display prompts the user to use the phone’s keypad to enter a Zip code and press the Submit softkey. The phone’s HTTP client sends the HTTP request to the specified weather web server, which returns the requested information and the weather for the specified Zip code displays on the phone.
When progressing through the data page returned by the web server, the phone simply processes the text or XML data objects to update the display and process user input as directed. Table 3-2 lists the extent to which the XML objects are supported across the Cisco IP Phone models.
Table 3-2. XML Objects Supported by Cisco IP Phone Model
Phone Model XML Object | 7905/7912 | 7920 | 7940/7960 | 7941/7961/ 7970/7971/IP Communicator |
|---|---|---|---|---|
CiscoIPPhoneText | X | X | X | X |
CiscoIPPhoneMenu | X | X | X | X |
CiscoIPPhoneIconMenu | Icons ignored | X | X | X |
CiscoIPPhoneDirectory | X | X | X | |
CiscoIPPhoneInput | X | X | X | |
CiscoIPPhoneImage | X[*] | X | X | |
CiscoIPPhoneImageFile | X | |||
CiscoIPPhoneGraphicMenu | X[*] | X | X | |
CiscoIPPhoneGraphicFileMenu | X | |||
CiscoIPPhoneExecute | Forced to Priority 0 (execute immediately) | Forced to Priority 0 (execute immediately) | X | X |
CiscoIPPhoneError | X | X | X | X |
CiscoIPPhoneResponse | X | X | X | X |
[*] The Cisco IP Phone 7920 has only a 128- × 59-pixel display and 2 grayscales. If an image with 4 grayscales is sent to the phone, the phone splits the image into 2 grayscales. (0–1 are treated as 0, and 2–3 get treated as 1.) | ||||
Each of the XML data types supported by the phone is described in Appendix C. Data types are the building blocks of IP phone services. You need to learn about data types if you are planning to write your own IP phone services. If you intend to write your own IP phone services, please see Appendix C.
Tip
Consult the following resources if you plan to write IP phone services and applications:
The Cisco Press book Developing Cisco IP Phone Services, ISBN: 1-58705-060-9, by Darrick Deel, Mark Nelson, and Anne Smith
“Cisco IP Phone Services Application Development Notes” white paper: http://www.cisco.com/univercd/cc/td/doc/product/voice/vpdd/cdd/
The Cisco IP Phone Services Software Development Kit available at the following link or search Cisco.com for “Cisco IP phone services”: http://www.cisco.com/en/US/products/hw/phones/ps379/products_data_sheet09186a00800925a8.html
Hot Dispatch: http://www.hotdispatch.com/cisco-ip-telephony
Cisco Video Telephony (VT) Advantage extends the capability of Cisco IP Phone models 7940, 7941, 7960, 7961, 7970, and 7971 to include video telephony functionality. Cisco VT Advantage is a desktop video application for the PC that is co-located with a supported Cisco IP Phone model. VT Advantage enables you to use your PC to display the video. As you interface normally with your IP phone, the application is notified and sends (if your PC is equipped with a Cisco VT Camera) and receives video if both you and the other party in the call are video-enabled. With Cisco VT Advantage, video is as easy as making a phone call. To be able to send video from Cisco VT Advantage on your PC, you need a Cisco VT Camera. For added security, Cisco IP Phones only communicate with Cisco VT Advantage running on a PC that is co-located and connected through the PC port on the phone. Figure 3-13 shows the Cisco VT Advantage.
Cisco VT Advantage automatically establishes a video stream during a basic call to or from another video-enabled device, which could be another Cisco IP Phone with Cisco VT Advantage, an H.263-enabled endpoint, or an H.323 terminal, including most H.323 conferencing MCUs. VT Advantage is notified of the call activity and automatically establishes the video and pops up a window on your PC when video is established. The video stream is activated when the audio stream is active. If the audio stream is stopped while initiating a hold, transfer, or conference operation, the video stream stops as well. The video functionality mirrors the audio functionality. If you initiate a consultation transfer and the current call is placed on hold while you establish a call with the target of the transfer, if so equipped, a video connection is established during the consultation transfer, just like the audio. Bandwidth controls have been expanded to cover video, and Cisco VT Advantage is regulated by the bandwidth restrictions you configure. Cisco VT Advantage provides icons to give you visual state information to indicate Idle, Connected, Video Muted, or No IP Phone, and you can configure Cisco VT Advantage so that you are prompted before a video call connects.
This section describes CallManager’s application interface implementation and the underlying CTI. CTI is the internal interface to CallManager, on which the standard interfaces, such as TAPI and JTAPI, are supported. CTI communication from the application platform to CallManager is through TCP/IP.
The CTI application architecture provides a means of controlling call behavior from external applications. CallManager provides already developed applications and a development infrastructure to allow third-party application development.
Figure 3-14 shows the CallManager infrastructure that supports the applications. The applications run on the application platform and make use of the application services. Applications provide a high-level functionality that is usually specific to a particular need, such as IP Contact Center, voice messaging/unified messaging, and so on. The applications might have media termination functionality or might simply control stations that actually terminate the media. The application platform and services provide the application programming interface (API), call control protocols, administration and serviceability functionality, and directory and database interfaces.
Application layers that are external to CallManager allow an application to interface to CallManager. The two primary application service APIs supported by CallManager are TAPI and JTAPI. These two APIs enable developers to extend the capabilities of CallManager to meet specific enterprise needs. The choice of TAPI or JTAPI is based on the particular needs and preferences of your organization.
The Cisco architecture for both TAPI and JTAPI, shown in Figure 3-15, supports a redundant connection to CTIManager so that if one CTIManager is down, the application can still communicate with the other CTIManager and continue functioning.
Microsoft’s TAPI for Windows was initially used for first-party device control for devices that were co-resident, such as controlling modems. The application would initiate a modem connection from the software running on the personal computer to a destination provided by the application. TAPI was extended to include a telephony server for third-party remote control, such as PBX devices. The TAPI framework abstracts the telephony services from the CallManager infrastructure. The applications are more portable and insulated from the effect of changes in new CallManager releases.
Figure 3-16 illustrates the components that make up the TAPI architecture and reside in the PC running the telephony application. The TAPI architecture is an abstraction layer between the TAPI applications and the underlying hardware and transport protocols of CallManager. The TAPI application accesses the device-specific controls for communications and call processing through a dynamic link library (DLL). Each TAPI application is a separate process that communicates using TAPI with Tapi32.dll or Tapi3.dll, provided by Microsoft. Tapi32.dll and Tapi3.dll communicate with the TAPISRV.EXE process using a private remote-procedure call (RPC) interface. TAPISRV.EXE is a Microsoft process that runs as a Windows service. TAPISRV.EXE communicates with the telephony service provider (TSP) using Telephony Service Provider Interface (TSPI). The Cisco TAPI Service Provider (Cisco TSP) is a DLL that runs under the TAPISRV.EXE process. The Cisco TSP communicates with CallManager through a TCP/IP interface known as CTIQBE. The Quick Buffer Encoding (QBE, pronounced “cube”) format is based loosely on Microsoft’s TAPI buffer format. QBE defines C-language structures that can be byte-copied directly to or from an input/output stream. The Cisco TSP allows developers to create customized IP telephony applications for CallManager.
The Cisco TSP supports first-party call control or third-party call control. In first-party call control, the application terminates the audio stream. With third-party call control, the application controls the audio stream of some other audio stream-terminating device. The device can be a particular station or a group of stations for which the application is responsible. CallManager for TAPI currently supports 2.0 and 2.1.
CallManager supports many CTI-controlled/monitored devices and the number depends on the CallManager server size. Depending on the server size, CallManager can scale up to 2500 CTI devices per CallManager server, up to 2500 CTI devices per “provider,” and up to 10,000 CTI devices per CallManager cluster.
JTAPI provides similar functionality for Java-based applications development. JTAPI supports call control and primitive media support. Compared to TAPI, JTAPI is more operating system independent. CallManager for JTAPI currently supports JTAPI 1.2.
CallManager supports many CTI-controlled/monitored devices and the number depends on the CallManager server size. Depending on the server size, CallManager can scale up to 2500 CTI devices per CallManager server, up to 2500 CTI devices per “provider,” and up to 10,000 CTI devices per CallManager cluster.
See Appendix C for specific details of the following JTAPI packages:
CallManager also provides the following RTP Termination extensions:
Special CallManager device types (CTI ports) can be registered by applications.
Devices must be preprovisioned (no programmatic creation).
Codec and RTP parameters are selected by CallManager during call setup.
An application must implement an RTP stack, although Java Media Framework (JMF/JavaSound) is allowed for client applications.
The CTI layer within CallManager provides a generic interface to the application layer. The CTI layer is the means by which the CallManager-specific capabilities of the application layer are implemented.
Figure 3-17 shows the CTI functionality within CallManager. CTI communicates with the application platforms through the TCP/IP layer to provide the CTI functionality of CallManager. The CTI layer is an integral part of CallManager.
CTI interacts with the other CallManager components through the Signal Distribution Layer described in Chapter 1, “Cisco CallManager Architecture.” CTI works together with the station module to provide the signals from a CTI device. If a station device such as a Cisco IP Phone is being controlled by an application, CTI interacts with the station module in CallManager responsible for the particular station being controlled.
The application also needs information about activity at a selected station. CTI receives notification about station activity, known as events, from the station components for stations that the application is monitoring.
CTI also interacts with the supplementary services component to provide additional call control capabilities, such as transfer and conference. The CTI component can invoke supplementary services on behalf of stations being controlled or directly for CTI application devices. CTI also sends event notifications of supplementary service activity for selected stations being monitored by an application.
An H.323 endpoint is a station device that communicates with CallManager using the H.323 protocol specification. The H.323v4 protocol in CallManager supports gateways and endpoints, as well as Registration, Admission, and Status (RAS) protocol for communication with a gatekeeper. The gatekeeper provides address translation and controls access to the network for H.323 devices based on bandwidth availability.
Figure 3-18 shows the H.323 protocol components that CallManager supports.
The audio compression components known to CallManager are as follows:
Global System for Mobile Communications (GSM)
G.711
G.722
G.723
G.728
G.729
CallManager supports the capabilities negotiation for these audio compression types. CallManager provides the system control components for H.245 for media setup, H.225 for call control, and H.225 RAS for gatekeeper communication, if a device is configured for gatekeeper control. CallManager provides support for video and data. The video protocols supported include H.261 and H.263. Data support includes data application capability H.224 and T.120.
The H.323 umbrella specification encompasses several additional specifications. The particular implementation in CallManager includes H.225 and H.245 signaling for proper operation of the H.323 endpoint. It provides for call control, capability exchange, signaling of commands and indications, and messages to open and fully describe the content of logical channels for media streams. CallManager terminates the H.225 signaling originated by any H.323 device defined in the database and directed to CallManager. The call can terminate at any endpoint, gateway, or cluster accessible by CallManager, regardless of the protocol of the terminating device. Likewise, CallManager extends, by H.225 signaling, a call to any H.323 device defined in the database from any endpoint, gateway, or cluster accessible by CallManager, regardless of the protocol of the originating device. The H.225 and H.245 signaling is always between CallManager and the H.323 endpoint. As with other station protocols, the media streaming uses RTP for the media, and the media streaming is done directly between the two devices and does not go through CallManager.
Use CallManager Administration to configure all H.323 endpoint devices that communicate with CallManager. CallManager uses directory numbers for all endpoint access, including H.323 endpoints. You must also assign all configured H.323 endpoint devices a directory number. Other users use the directory number to extend a call to the H.323 endpoint. No advantage exists in having an H.323 endpoint under gatekeeper control as in the case of an H.323 gateway because these endpoints support a single call to or from a CallManager-controlled device. Refer to Chapter 4 for a detailed discussion of gatekeeper control for H.323 gateway devices.
H.323 endpoints can be configured as gatekeeper-controlled. If an endpoint is gatekeeper-controlled, the gatekeeper is identified as part of the H.323 device configuration. CallManager registers the H.323 endpoint with the gatekeeper when it initializes. The specified gatekeeper controls all calls made to or from the H.323 endpoint. The H.323 gatekeeper signaling is RAS, as defined in the H.323 protocol specification.
This chapter covered the concepts of endpoints, stations, and users. You learned about new features introduced in CallManager since release 3.1, such as multiple calls per line, shared lines, and barge/cBarge/privacy functionality. The enhanced IP phone services application development capability offers additional key development improvements. Of particular interest are the new phone models along with the new feature content, which provide additional opportunities for leveraging CallManager functionality.