SCCP Station Devices

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.

Cisco IP Phones

The Cisco IP Phone family includes the following models:

In addition, the family of phone products includes the following:

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.

Figure 3-11. Cisco IP Phone Family

 

Cisco IP Phone 7902G

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.

Cisco IP Phone 7905G

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.

Cisco IP Phone 7912G

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.

Cisco Wireless IP Phone 7920

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

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:

In addition to the capabilities in the preceding list, Cisco IP Phones 7961G and 7941G also provide a high resolution display (320 x 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:

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.

Cisco IP Phone 7914 Expansion Module

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.

Cisco IP Phone Conference Station 7936

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:

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.

Cisco IP Phone 7985G

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 callscamera with lens cap, large 8.4" LCD display, speakerphone with a headset jack, keypad, and handsetintegrated 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

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.

Cisco IP Phone Registration

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.

SDL Message Queues in CallManager

CallManager has internal Signal Distribution Layer (SDL) message queues that determine the priority of SCCP messages such as KeepAlives, phone registration, call processing functions, and so on. The messages are divided into priority queues to help manage the load on CallManager nodes when the system is operating at capacity. The queues help ensure that higher-priority messages, such as KeepAlives, are processed by CallManager before lower-priority messages such as database updates. For example, when a CallManager system is newly installed, all phones in the system try to register. Such an influx of station registration messages can cause problems such as delayed dial tone if they are not properly prioritized. Because off-hook notifications are processed in a higher-priority queue than initial station registration requests, users who have phones that are already registered will not experience delayed dial tone when they go off-hook to place a call due to the pending station registration requests which are managed in a lower-priority queue. Users of phones that have not yet registered with any CallManager (and therefore are not even operational) will not likely notice the slightly longer delay for registration due to the registration messages being processed in the lower queue.

Five queues exist:

  • High This queue handles messages related to timeout events, internal CallManager KeepAlives, certain gatekeeper events, and internal process creation, among other events.

  • Normal This queue manages messages for call processing functions, key presses, on-hook and off-hook notifications, among other events.

  • Low This queue handles messages for station device registration (except the initial station registration request message), among other events.

  • Lowest This queue handles initial station registration request messages during device registration, among other events.

  • Database updates This queue, added in CallManager release 4.1(2), manages database messages, such as requests and updates.

Because phones register at the same time that calls are in progress on a CallManager node, registration messages are handled by CallManager in a lower-priority queue to give higher priority to the active calls and not delay call processing activity. Registrations proceed at the maximum rate that they can be processed, but they will not have an excessive impact on users' call activity. The priority of SDL messages such as device registration is statically configured in CallManager.

In the case of a fallback situation, phone registration can take a longer period of time to occur than during initial device registration or failover device registration. The service parameter Maximum Phone Fallback Queue Depth controls the number of messages allowed to queue for the CallManager node that is coming back online after a failover. You'll notice that although the range for this parameter is 1 to 500, the default value is 10. The value is kept low to preserve CallManager performance and make sure that phones that are successfully registered to a working CallManager do not sever that connection until they can be assured of registering to a new working node without excessive delay.

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.

Figure 3-12. Cisco IP Phone Initialization

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:

  1. The phone requests an IP address from the DHCP service.

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

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

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

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

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

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

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

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

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

Note

If the phone encounters a TFTP timeout, the phone alternates between TFTP Server 1 and TFTP Server 2. The phone continues using the selected server as long as it is available. If the phone resets, the initial TFTP attempt is to TFTP Server 1.

 

Cisco IP Phone Security

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:

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.

Configuration

The following phone configuration options affect the degree of security enjoyed by IP phones:

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

 

Gratuitous ARP Field

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.

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

PC Voice VLAN Access 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.

Note

The PC Port and PC Voice VLAN Access fields are not available on Cisco IP Phone 7912 models.

 

Settings Access Field

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 and Configuration File Security

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:

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:

Media Privacy

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.

What Is Salt?

One of the problems that occur in Cipher Block Chaining (CBC) mode symmetric encryption (which is used in CallManager for TLS) is that for the first block of data, you need to have something that already went through the cipher. The salt is simply a block of random information that acts as that first block. It is random so that it is more difficult to precompute crypto attacks based on known plain text. (For example, in e-mail, there is always a From and a To block at the first of the packets.) In the case of the media streams, the salt performs the same type of function in that it increases the difficulty of crypto analysis of the SRTP stream. It is not part of the actual key that the encryptor uses, but acts as additional data.

 

Call Signaling

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 Services

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.

Overview of Cisco IP Phone Services

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.

Phone-Supported XML Objects

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- x 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. (01 are treated as 0, and 23 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:

Related

Категории