Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
CUCM supports RFC 3261–compliant third-party SIP phones. Support for third-party SIP
phone features varies greatly from Cisco SIP IP Phone features. Third-party phones have
only RFC 3261 SIP Version 2 support, whereas Cisco SIP Phones have many Cisco SCCP
features that have been rewritten to work in a native SIP protocol stack.
Two different types of third-party SIP phones can be added to CUCM. Third-party SIP
phones may be added as basic or advanced phones. Third-party SIP basic phones support
one line appearance and consume three DLUs. Third-party SIP advanced phones support
up to eight lines and video but consume six DLUs. Basic and advanced third-party SIP
phones offer the same telephony features.
Third-party SIP phones register with CUCM but do not use a MAC address–based device
ID. CUCM uses SIP digest authentication to identify a registering SIP third-party SIP
phone.
158 Chapter 7: Endpoints
Both CUCM and the third-party SIP phone have to be configured with a username and
password for digest authentication to work properly. CUCM refers to this item as a digest
user in which a user is associated with the phone in both the phone and user configuration
pages. The third-party device must also be configured with a matching username.
SIP standards and drafts supported by CUCM include the following:
■ RFC 3262: PRACK
■ RFC 3264: SDP offer/answer
■ RFC 3311: UPDATE
■ RFC 3515: REFER
■ RFC 3842: MWI Package
■ RFC 3891: Replaces Header
■ RFC 3892: Referred-by Mechanism
■ draft-levy-sip-diversion-08.txt: Diversion Header
■ draft-ietf-sip-privacy-04.txt: Remote-Party-Id Header
The following audio and video standards are supported for third-party SIP phones:
■ Audio:
—Audio codecs: G.711 mu-law, GSM Full-rate, G.723.1, G.711 A-law,
G.722, G.728, G.729
—RFC 2833: DTMF (Telephony-event)
■ Video:
—Video codecs: H.261, H.263, H.263+, H.263++, H.264
Cisco is working with key third-party vendors who are part of the Cisco Technology
Development Partner Program. These partners are developing solutions that leverage the
NOTE For more information about the support of these standards, see the Cisco SIP IP
Administrator Guide, Version 8.0 - Compliance with RFC 3261:
http://www.cisco.com/en/US/products/sw/voicesw/ps2156/products_administration_
guide_chapter09186a00807f47e3.html
SIP Third-Party IP Phone Support in CUCM 159
new CUCM and CUCM Express SIP capabilities. These vendors include Linksys,
IPCelerate, Research In Motion, IP blue, and Grandstream.
Cisco is also participating in an independent third-party testing and interoperability verification
process being offered by tekVizion. This independent service has been established
to enable third-party vendors to test and verify the interoperability of their endpoints with
CUCM and CUCM Express.
Third-party SIP phones support only a few features compared to Cisco IP Phones using
SCCP or SIP. The features that are not supported include but are not limited to the following:
■ MAC address registration
■ Phone buttons template
■ Soft key templates
■ Telephony features and applications such as the following:
—IP phone services
—CUCM Assistant
—Cisco Unified Video Advantage
—Call Pickup
—Barge
—Presence
SIP Third-Party Authentication
Digest authentication allows CUCM to act as a server to challenge the identity of a SIP
device when it sends a request to CUCM. When digest authentication is enabled for a
phone, CUCM challenges all SIP phone requests except keepalive messages. CUCM does
not support responding to challenges from SIP phones.
CUCM can challenge SIP devices connecting through a SIP trunk and can respond to
challenges received on its SIP trunk interface.
CUCM digest authentication is used to determine the identity of a third-party SIP phone.
The phones cannot be authenticated via MAC address like SCCP devices because thirdparty
SIP phones do not register by MAC address. Digest authentication is the industry
standard.
160 Chapter 7: Endpoints
CUCM can ignore the keyed hash that is provided in a digest authentication response and
check only if the provided username exists and is bound to a third-party SIP phone. This is
the default behavior. Alternatively, CUCM can be configured to check that the key that was
used at the third-party SIP phone to generate the keyed hash matches the locally configured
key (called digest credentials) at the end-user configuration in CUCM.
Third-party SIP phones cannot be configured by using the CUCM TFTP server. Instead,
they need to be configured using the native phone configuration mechanism, which is
usually a web page or a TFTP file. The device and line configuration in the CUCM database
must be manually synchronized with the native phone configuration (for example, extension
1002 on the phone and 1002 in CUCM). In addition, if the directory number of a line is
changed, it must be changed in both CUCM Administration and in the native phone
configuration mechanism.
Third-party SIP phones include their directory number in the registration message. They do
not send a MAC address. Third-party SIP phones identify themselves with digest authentication.
The SIP REGISTER message includes a header with a username and the keyed hash, as
shown in the following example:
Authorization: Digest
username=“3rdpsip”,realm=“ccmsipline”,nonce=“GBauADss2qoWr6k9y3hGGVDAqnLfoLk5”,
uri=“sip:172.18.197.224”,algorithm=MD5,response=“126c0643a4923359ab59d4f5349455
2e”
CUCM receives the registration message and searches for an endpoint that matches
the provided username in the SIP message (3rdpsip in the preceding example).
CUCM uses the digest credentials configured for that user to verify the keyed hash
(response=“126c0643a4923359ab59d4f53494552e in the preceding example).
CUCM searches for a third-party SIP phone that is associated with the end user and verifies
that the configured directory number matches the one provided by the third-party SIP phone
in its registration message. If the phone is found and the directory number is the same, the
third-party SIP phone registers with CUCM.
To add a third-party SIP phone in CUCM, follow these steps:
Step 1 Configure an end user in CUCM and specify the digest credentials.
NOTE CUCM must be explicitly configured to verify the keyed hash. By default,
CUCM searches only for the end-user name.
Review Questions 161
Step 2 Add the third-party SIP phone in CUCM and configure its directory
number.
Step 3 Associate the third-party SIP phone with the end user.
Step 4 Configure the third-party SIP phone with the IP address of the CUCM,
end-user ID, digest credentials, and directory number.
Wednesday, December 15, 2010
H.323 Endpoint Support Best CCSP Training Institute in New Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
H.323 phones support multiple lines and can be audio, video, or data networking endpoints.
H.323 terminals are synonymous with endpoints. The H.323 terminal language is
used in the H.323 standard. CUCM supports voice calls from H.323 terminals natively.
CUCM can also integrate with H.323 video endpoints using an H.323 gatekeeper. Cisco Unified
Communications IP Telephony, Part 2 explains the H.323 video integration in further
detail.
IP
Cisco SIP Phone Cisco TFTP CUCM
1. CTL File (If Present)
2. SEP<mac>.cnf.xml
3. XMLDefault.cnf.xml
4. Loads File
5. Dial Rules (Optional)
6. Establish Connection
7a. Register
7b. 200 OK
8. Localization Files
9. Soft Keys (Type-B Only)
10. Custom Ringers
156 Chapter 7: Endpoints
H.323 phones do not register with CUCM. H.323 devices are configured by IP address or
fully qualified domain name (FQDN). H.323 gateways always show up as unregistered in
CUCM. An unregistered Media Gateway Control Protocol (MGCP) is a bad thing, but
H.323 gateways will always show up as unregistered because of their point-to-point nature.
CUCM directs calls to the IP address of the H.323 gateway and accepts calls to the H.323
gateway over the H.225 call-control signaling TCP port 1720. There is no further integration
with either H.323 gateways or gatekeepers. Third-party H.323 devices (terminals, gateways,
and gatekeepers) can register with the gatekeeper or integrate directly with CUCM.
Configuration of H.323 devices must be performed on both CUCM and on the phone itself.
Dial plan configuration must be configured on each device. Third-party H.323 phones
consume two device license units (DLU) in CUCM.
The Cisco Unified IP Phone 7905 can be loaded with an H.323 firmware. If H.323 firmware
is loaded, the phone is treated like a third-party H.323 endpoint and needs to be configured
as a third-party H.323 phone, rather than as a Cisco Unified IP Phone 7905. The 7905 is an
EoS device.
Examples of H.323 endpoints include Microsoft NetMeeting and H.323 video devices from
Sony, Polycom, and Tanberg. H.323 endpoints often register with H.323 gatekeepers. H.323
gatekeepers contain dial plan elements and allow the devices to perform dynamic e.164
aliasing. Dynamic e.164 aliasing is a process in which the user specifies the phone number
that the device is in charge of. The gatekeeper dynamically loads a configuration based on
the device phone number specified.
H.323 endpoints support a small subset of features compared to Cisco IP Phones using
SCCP or SIP. The features that are not supported include, but are not limited to, the
following:
■ H.323 phones need to be configured by their IP address in CUCM rather than by a
MAC address-based device ID.
■ Phone button templates and soft key templates are not supported. Each device user
interface varies by vendor and product.
SIP Third-Party IP Phone Support in CUCM 157
■ Telephony features and applications such as the following:
—IP phone services
—CUCM Assistant
—Cisco Unified Video Advantage
—Call Pickup
—Barge
—Presence
The high-level configuration steps for H.323 phone implementation are as follows:
1. The H.323 phone is added to CUCM with its IP address and directory numbers
specified.
2. The H.323 phone is configured with the IP address of CUCM.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
H.323 phones support multiple lines and can be audio, video, or data networking endpoints.
H.323 terminals are synonymous with endpoints. The H.323 terminal language is
used in the H.323 standard. CUCM supports voice calls from H.323 terminals natively.
CUCM can also integrate with H.323 video endpoints using an H.323 gatekeeper. Cisco Unified
Communications IP Telephony, Part 2 explains the H.323 video integration in further
detail.
IP
Cisco SIP Phone Cisco TFTP CUCM
1. CTL File (If Present)
2. SEP<mac>.cnf.xml
3. XMLDefault.cnf.xml
4. Loads File
5. Dial Rules (Optional)
6. Establish Connection
7a. Register
7b. 200 OK
8. Localization Files
9. Soft Keys (Type-B Only)
10. Custom Ringers
156 Chapter 7: Endpoints
H.323 phones do not register with CUCM. H.323 devices are configured by IP address or
fully qualified domain name (FQDN). H.323 gateways always show up as unregistered in
CUCM. An unregistered Media Gateway Control Protocol (MGCP) is a bad thing, but
H.323 gateways will always show up as unregistered because of their point-to-point nature.
CUCM directs calls to the IP address of the H.323 gateway and accepts calls to the H.323
gateway over the H.225 call-control signaling TCP port 1720. There is no further integration
with either H.323 gateways or gatekeepers. Third-party H.323 devices (terminals, gateways,
and gatekeepers) can register with the gatekeeper or integrate directly with CUCM.
Configuration of H.323 devices must be performed on both CUCM and on the phone itself.
Dial plan configuration must be configured on each device. Third-party H.323 phones
consume two device license units (DLU) in CUCM.
The Cisco Unified IP Phone 7905 can be loaded with an H.323 firmware. If H.323 firmware
is loaded, the phone is treated like a third-party H.323 endpoint and needs to be configured
as a third-party H.323 phone, rather than as a Cisco Unified IP Phone 7905. The 7905 is an
EoS device.
Examples of H.323 endpoints include Microsoft NetMeeting and H.323 video devices from
Sony, Polycom, and Tanberg. H.323 endpoints often register with H.323 gatekeepers. H.323
gatekeepers contain dial plan elements and allow the devices to perform dynamic e.164
aliasing. Dynamic e.164 aliasing is a process in which the user specifies the phone number
that the device is in charge of. The gatekeeper dynamically loads a configuration based on
the device phone number specified.
H.323 endpoints support a small subset of features compared to Cisco IP Phones using
SCCP or SIP. The features that are not supported include, but are not limited to, the
following:
■ H.323 phones need to be configured by their IP address in CUCM rather than by a
MAC address-based device ID.
■ Phone button templates and soft key templates are not supported. Each device user
interface varies by vendor and product.
SIP Third-Party IP Phone Support in CUCM 157
■ Telephony features and applications such as the following:
—IP phone services
—CUCM Assistant
—Cisco Unified Video Advantage
—Call Pickup
—Barge
—Presence
The high-level configuration steps for H.323 phone implementation are as follows:
1. The H.323 phone is added to CUCM with its IP address and directory numbers
specified.
2. The H.323 phone is configured with the IP address of CUCM.
Cisco IP Phones: Boot Sequence Best CCNP Training Institute in New Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The Cisco IP Phone has a standard startup process consisting of several steps. The steps are
illustrated in Figure 7-2 and outlined as follows:
Step 1 PoE: The Cisco IP Phone obtains power from the switch. The switch
continuously sends a small voltage on the transmit pins. The voltage sent
by the switch is then looped back in hardware from the IP phone back
to the switch’s receiving pins. The switch has now detected an in-line
power-requiring device, and the Cisco switch generates the port’s default
power allocation. The default power allocation is 10 watts with Cisco
proprietary PoE and 15.4 watts with the IEEE 802.3af in-line power
specification. Type B Cisco phones support IEEE power and Cisco
power, but the IEEE specification did not exist when Cisco manufactured
the Type A phones. The 79x2 and 79x5 phones require IEEE or wall
power bricks. The Cisco power option does not supply enough power
to power these phones.
Step 2 Loading the stored phone image: The Cisco IP Phone has nonvolatile
flash memory where the phone’s firmware image is stored. At startup, the
phone runs a bootstrap loader that loads the phone image from flash
memory. Using this image, the phone initializes its software and
hardware.
Step 3 Configuring VLAN: A Cisco Catalyst switch uses CDP to inform the
Cisco IP Phone which voice VLAN the phone should use for all VoIP
traffic. An application-specific integrated circuit (ASIC) in the phone’s
hardware is used to create Ethernet 802.1q frames before transmitting the
traffic on the switch port. The ASIC also gives the phone 1p3q1t (one
priority queue, three normal queues, and one drop threshold) QoS
capabilities and allows the phone to act like a three-port switch. The
Cisco IP Phone does not support the weighted random early detection
(WRED) congestion-avoidance protocol. The one threshold is set to tail
drop (100 percent queue utilization).
152 Chapter 7: Endpoints
Step 4 Obtaining an IP address: Cisco IP Phones use DHCP by default to
obtain an IP address, subnet mask, default gateway, and TFTP server
(option 150). The phone sends out a Layer 2 broadcast to the Ethernet
layer 2 broadcast address of FF-FF-FF-FF-FF-FF. The DHCP server
receives this broadcast and returns an IP address lease from the DHCP
scope for the Cisco IP Phones, which contains an IP address, default
gateway, subnet mask, and TFTP server (option 150). If DHCP is not
used in the network, a static network configuration must be assigned to
each IP phone locally. If the DHCP server does not respond, the IP phone
will make use of the DHCP scope stored in NVRAM. DHCP information
will be in NVRAM only if the phone has previously obtained a lease
from the DHCP server.
Step 5 Requesting the configuration file and the profile file: The TFTP server
has configuration files. A configuration file includes parameters for
connecting to CUCM and information about which image load a
phone should be running.
The IP phone first requests its SEP<mac-address>.cnf.xml file from the
TFTP server. If the TFTP server does not respond, the IP phone falls back
to the last used configuration stored in NVRAM. If the TFTP server
responds, but the SEP<mac-address>.cnf.xml file is not found on the server,
the phone requests the XMLDefault.cnf.xml file. The XMLDefault.cnf.xml
file is used to request an auto-registration configuration. Auto registration
is disabled by default. CUCM dynamically generates a directory number
and configuration file for the IP phone if auto registration has been
provisioned.
If cryptographic features are enabled in CUCM, the phone then attempts to
download a certificate trust list (CTL) in addition to the phone configuration file.
Step 6 Registering: The configuration file includes a prioritized list of CUCM
servers that are configured in CUCM as a CallManager group. After
obtaining the file from the TFTP server, the phone attempts to register
with the highest-priority CUCM in the CallManager group using SCCP
over TCP port 2000.
Cisco IP Phones: Boot Sequence 153
Figure 7-2 Cisco IP Phone: SCCP Boot Process
The boot sequences for SIP phones are similar to those used for SCCP phones. There are
three main differences:
■ SEP<mac>.cnf.xml: The SIP phones get their entire configuration from the configuration
file. The SEP<mac-address>.cnf.xml file is much larger for SIP than for SCCP.
■ Dial plan file (optional): The Cisco SIP phones can download and use local dial plans.
Third-party SIP phones can be configured with local dial plans, but they cannot be
configured and downloaded from CUCM. Third-party phone configuration takes place
on the third-party device.
■ Soft key file: The SIP phones download their soft key sets in an XML soft key file,
whereas SCCP phones receive these soft key states as part of the SCCP call-control
signaling.
Steps 1 through 4 of the SCCP boot process are identical in both Cisco SIP Phones and
Cisco SCCP Phones. The steps in Figure 7-3 follow the step list that follows, but all the
steps of Figure 7-2 are also performed by the Cisco SIP Phones. Figure 7-2 illustrates a
high-level overview of the network integration of the Cisco IP Phone, and 7-3 illustrates the
details of the files and messages exchanged between the IP phone and the TFTP and CUCM
servers. The step list that follows assumes the SIP phone has obtained power, the voice
VLAN, and a DHCP scope from the DHCP server. Cisco SCCP and SIP Phones have a
similar boot and registration process. The primary differences have been highlighted in the
three previous bullet points.
V
IP
DHCP CUCM Cisco TFTP
2
3
4 5
6
1
154 Chapter 7: Endpoints
Step 1 The SIP phone boots and downloads a CTL file from the TFTP server.
The CTL file contains a set of X.509v3 certificates and is used only when
CUCM cluster security has been enabled. Cluster security is covered in
Cisco Unified Communications IP Telephony, Part 2.
Step 2 The SIP phone requests its SEP<mac-address>.cnf.xml file from the
Cisco TFTP server.
Step 3 If the SIP phone has not been provisioned before boot time, the SIP
phone downloads the default configuration file XMLDefault.cnf.xml
from the TFTP server. The default configuration file is used only if auto
registration has been enabled. Auto registration using SIP requires a file
containing a parameter called auto_registration_name. If this parameter
is blank, the SIP phone will not auto-register. If this parameter is not
blank, the SIP phone will attempt to auto-register.
Step 4 The SIP phone requests a firmware upgrade (Load ID file), if one was
specified in the configuration file. This process allows the phone to
upgrade the firmware image, allowing it to operate with future versions
of CUCM. Each version of CUCM updates the firmware of the Cisco IP
Phones so that they can properly communicate with CUCM. After the
image has been downloaded and authenticated with the Cisco self-signed
X.509v3 certificate, the SIP phone reboots to load the new image. This
process might require many reboots to incrementally upgrade the
firmware of the IP Phone.
Step 5 The Cisco IP Phone registers with the highest-priority CUCM server. The
default SIP configuration file indicates whether the SIP phone should
connect using User Datagram Protocol (UDP) port 5060 (default) or
TCP. The TCP transport layer IP is supported and configurable on Type
B phones only.
Booting for Type B Cisco IP Phones is slightly different from this procedure, which
describes the boot sequence of Type A Cisco IP Phones. Type B Cisco IP Phones first
download the SIPdefault.cnf file, which contains the default configuration parameters
shared by all SIP phones that use the TFTP server. The Cisco SIP Phone continues
requesting the SIP<mac>.cnf file to receive its individual configuration file.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The Cisco IP Phone has a standard startup process consisting of several steps. The steps are
illustrated in Figure 7-2 and outlined as follows:
Step 1 PoE: The Cisco IP Phone obtains power from the switch. The switch
continuously sends a small voltage on the transmit pins. The voltage sent
by the switch is then looped back in hardware from the IP phone back
to the switch’s receiving pins. The switch has now detected an in-line
power-requiring device, and the Cisco switch generates the port’s default
power allocation. The default power allocation is 10 watts with Cisco
proprietary PoE and 15.4 watts with the IEEE 802.3af in-line power
specification. Type B Cisco phones support IEEE power and Cisco
power, but the IEEE specification did not exist when Cisco manufactured
the Type A phones. The 79x2 and 79x5 phones require IEEE or wall
power bricks. The Cisco power option does not supply enough power
to power these phones.
Step 2 Loading the stored phone image: The Cisco IP Phone has nonvolatile
flash memory where the phone’s firmware image is stored. At startup, the
phone runs a bootstrap loader that loads the phone image from flash
memory. Using this image, the phone initializes its software and
hardware.
Step 3 Configuring VLAN: A Cisco Catalyst switch uses CDP to inform the
Cisco IP Phone which voice VLAN the phone should use for all VoIP
traffic. An application-specific integrated circuit (ASIC) in the phone’s
hardware is used to create Ethernet 802.1q frames before transmitting the
traffic on the switch port. The ASIC also gives the phone 1p3q1t (one
priority queue, three normal queues, and one drop threshold) QoS
capabilities and allows the phone to act like a three-port switch. The
Cisco IP Phone does not support the weighted random early detection
(WRED) congestion-avoidance protocol. The one threshold is set to tail
drop (100 percent queue utilization).
152 Chapter 7: Endpoints
Step 4 Obtaining an IP address: Cisco IP Phones use DHCP by default to
obtain an IP address, subnet mask, default gateway, and TFTP server
(option 150). The phone sends out a Layer 2 broadcast to the Ethernet
layer 2 broadcast address of FF-FF-FF-FF-FF-FF. The DHCP server
receives this broadcast and returns an IP address lease from the DHCP
scope for the Cisco IP Phones, which contains an IP address, default
gateway, subnet mask, and TFTP server (option 150). If DHCP is not
used in the network, a static network configuration must be assigned to
each IP phone locally. If the DHCP server does not respond, the IP phone
will make use of the DHCP scope stored in NVRAM. DHCP information
will be in NVRAM only if the phone has previously obtained a lease
from the DHCP server.
Step 5 Requesting the configuration file and the profile file: The TFTP server
has configuration files. A configuration file includes parameters for
connecting to CUCM and information about which image load a
phone should be running.
The IP phone first requests its SEP<mac-address>.cnf.xml file from the
TFTP server. If the TFTP server does not respond, the IP phone falls back
to the last used configuration stored in NVRAM. If the TFTP server
responds, but the SEP<mac-address>.cnf.xml file is not found on the server,
the phone requests the XMLDefault.cnf.xml file. The XMLDefault.cnf.xml
file is used to request an auto-registration configuration. Auto registration
is disabled by default. CUCM dynamically generates a directory number
and configuration file for the IP phone if auto registration has been
provisioned.
If cryptographic features are enabled in CUCM, the phone then attempts to
download a certificate trust list (CTL) in addition to the phone configuration file.
Step 6 Registering: The configuration file includes a prioritized list of CUCM
servers that are configured in CUCM as a CallManager group. After
obtaining the file from the TFTP server, the phone attempts to register
with the highest-priority CUCM in the CallManager group using SCCP
over TCP port 2000.
Cisco IP Phones: Boot Sequence 153
Figure 7-2 Cisco IP Phone: SCCP Boot Process
The boot sequences for SIP phones are similar to those used for SCCP phones. There are
three main differences:
■ SEP<mac>.cnf.xml: The SIP phones get their entire configuration from the configuration
file. The SEP<mac-address>.cnf.xml file is much larger for SIP than for SCCP.
■ Dial plan file (optional): The Cisco SIP phones can download and use local dial plans.
Third-party SIP phones can be configured with local dial plans, but they cannot be
configured and downloaded from CUCM. Third-party phone configuration takes place
on the third-party device.
■ Soft key file: The SIP phones download their soft key sets in an XML soft key file,
whereas SCCP phones receive these soft key states as part of the SCCP call-control
signaling.
Steps 1 through 4 of the SCCP boot process are identical in both Cisco SIP Phones and
Cisco SCCP Phones. The steps in Figure 7-3 follow the step list that follows, but all the
steps of Figure 7-2 are also performed by the Cisco SIP Phones. Figure 7-2 illustrates a
high-level overview of the network integration of the Cisco IP Phone, and 7-3 illustrates the
details of the files and messages exchanged between the IP phone and the TFTP and CUCM
servers. The step list that follows assumes the SIP phone has obtained power, the voice
VLAN, and a DHCP scope from the DHCP server. Cisco SCCP and SIP Phones have a
similar boot and registration process. The primary differences have been highlighted in the
three previous bullet points.
V
IP
DHCP CUCM Cisco TFTP
2
3
4 5
6
1
154 Chapter 7: Endpoints
Step 1 The SIP phone boots and downloads a CTL file from the TFTP server.
The CTL file contains a set of X.509v3 certificates and is used only when
CUCM cluster security has been enabled. Cluster security is covered in
Cisco Unified Communications IP Telephony, Part 2.
Step 2 The SIP phone requests its SEP<mac-address>.cnf.xml file from the
Cisco TFTP server.
Step 3 If the SIP phone has not been provisioned before boot time, the SIP
phone downloads the default configuration file XMLDefault.cnf.xml
from the TFTP server. The default configuration file is used only if auto
registration has been enabled. Auto registration using SIP requires a file
containing a parameter called auto_registration_name. If this parameter
is blank, the SIP phone will not auto-register. If this parameter is not
blank, the SIP phone will attempt to auto-register.
Step 4 The SIP phone requests a firmware upgrade (Load ID file), if one was
specified in the configuration file. This process allows the phone to
upgrade the firmware image, allowing it to operate with future versions
of CUCM. Each version of CUCM updates the firmware of the Cisco IP
Phones so that they can properly communicate with CUCM. After the
image has been downloaded and authenticated with the Cisco self-signed
X.509v3 certificate, the SIP phone reboots to load the new image. This
process might require many reboots to incrementally upgrade the
firmware of the IP Phone.
Step 5 The Cisco IP Phone registers with the highest-priority CUCM server. The
default SIP configuration file indicates whether the SIP phone should
connect using User Datagram Protocol (UDP) port 5060 (default) or
TCP. The TCP transport layer IP is supported and configurable on Type
B phones only.
Booting for Type B Cisco IP Phones is slightly different from this procedure, which
describes the boot sequence of Type A Cisco IP Phones. Type B Cisco IP Phones first
download the SIPdefault.cnf file, which contains the default configuration parameters
shared by all SIP phones that use the TFTP server. The Cisco SIP Phone continues
requesting the SIP<mac>.cnf file to receive its individual configuration file.
CUCM Endpoints Best CCNA Training Institute in New Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A variety of endpoints, from Cisco and third-party manufacturers, can be used with CUCM.
Endpoints include IP phones, analog gateways, and video endpoints.
CUCM has widespread support for the following protocols to be used for endpoints: SCCP,
SIP, and H.323. Figure 7-1 illustrates some of the various protocol options to connect to
CUCM.
Figure 7-1 CUCM Endpoints
■ Type A phones: These are the following Cisco Unified IP Phones: 7905, 7912, 7940,
and 7960.
■ Type B phones: These are the following Cisco Unified IP Phones: 7906, 7911, 7931,
7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971, and 7975.
Analog Station
Gateways
Cisco SCCP-Only
Phones
CUCM
Cisco Unified
IP Phones
Third-Party
H.323 Endpoints
Third-Party
SIP Endpoints
SCCP Video
Phones
SCCP
SIP
H.323
CUCM Endpoints 145
Cisco also offers software-based phones such as the older Cisco IP SoftPhone, Cisco IP
Communicator (CIPC), and Cisco Unified Personal Communicator (CUPC). CIPC is a
software-based version of the 7970 Cisco IP Phone. CIPC has always supported SCCP, and
SIP support was added with CIPC 2.1. The CUPC requires a Cisco Unified Presence Server
(CUPS) to register. The CUPS represents a UC client that operates as a phone, video device,
and instant messenger client. CUPC can be used to promote a voice call into an audioconference,
video call, or videoconference if the network has sufficient resources. All of
this can be done while using CUPC to instant message different people.
The Cisco Unified IP Phone 7902 and Cisco Unified IP Phone 7910 models support SCCP
only and are no longer being sold (End of Sale [EoS]).
The Cisco Unified IP Phone 7985 is a desktop video phone, whereas the Cisco Unified IP
Phone 7920 and 7921 models are wireless LAN (WiFi) phones. The Cisco Unified IP Phone
7935, 7936, and 7937 models are conference stations. The 7935 and 7936 endpoints support
SCCP only.
Third-party products are available for most of the supported protocols. Nokia supports the
Cisco Unified Mobile Communicator. Cisco Unified Mobile Communicator is a software
client that is used on Nokia dual-mode mobile phones, allowing cellular PDA phones to
register with CUCM. Tandberg and Sony produce various SCCP-enabled video endpoints,
and IP blue offers an SCCP-based software IP phone that emulates standard Cisco 79xx
phone lines. Many other third-party endpoints for SIP and H.323 can also be found on
the market.
Endpoint Features
The features supported on the Cisco IP Phones vary by the device protocol in which the
phone is running. The protocols can be categorized into three groups:
■ SCCP: SCCP is a Cisco proprietary protocol and is typically used only by Cisco IP
endpoints. Third-party companies such as Sony, Tandberg, and VTGO (IP blue) have
licensed SCCP. SCCP offers a rich set of telephony features that are supported on most
Cisco handsets.
■ Third-party SIP or H.323: CUCM supports standards-based SIP and H.323 endpoints.
The number of standardized telephony features, however, is limited when compared to
the feature richness of SCCP.
NOTE The Cisco Unified IP Phone 7902, 7905, 7910, 7912, and 7935 are End of Sale
(EoS). Cisco no longer sells these units, but it will continue to support them until the end
of life (EoL) date.
146 Chapter 7: Endpoints
■ SIP support for Cisco IP Phones: Cisco IP Phones using SIP support different
features depending on which Cisco IP Phone is used. Many additional features are
supported, compared to the SIP third-party phone support. Cisco SIP Type B phones
support similar features when compared to those supported with SCCP. The number of
features supported depends significantly on the Cisco IP Phone model being used.
Table 7-1 displays the support between various phone types and protocols. Third-party SIP
and H.323 endpoints can be used with any other IP telephony devices or systems, including
CUCM. Third-party SIP and H.323 are limited regarding the number of supported
telephony features, when compared to Cisco SIP or SCCP IP Phones.
The Cisco Unified IP Phone models 7940 and 7960 can be loaded with a special firmware
that provides RFC 3261 SIP support for third-party PBX systems. When these models
interact with CUCM, both SIP and SCCP implementations provide more features than the
phones operating on a third-party SIP proxy server. This option is used more by customers
who connect to other IP communication systems but want to take advantage of the superior
voice quality and look and feel of the Cisco IP Phones. Some Internet telephony service
providers (ITSP) offering standard SIP telephony services provide their customers with
preconfigured Cisco Unified IP Phone models 7940 or 7960 to be used to connect to their
SIP proxy servers.
The Cisco Unified IP Phone models 7905 and 7912 can also be loaded with an H.323
firmware to be used with third-party PBX vendors using H.323.
Cisco IP Phones with SIP support a different number of features depending on whether
the phone is a Type A or B model. Type A models include the 7905, 7912, 7940, and 7960.
Type A phones support a large number of features but many fewer features than SCCP. The
Table 7-1 Endpoint Support
Third-Party
SIP Cisco IP Phone SIP SCCP
Third-Party
H.323
Third-Party
PBX Support
Yes No No Yes
Feature
Support
Small Type A phones: Medium
Type B phones: High
Large Large
Supported
Phones
Third party Type A and B All Cisco phones
Third-party SCCP
phones
Third party
CUCM Endpoints 147
Type A phones also have a different screen appearance when compared to their SCCP
counterparts. Type B SIP phones support many more features than Type A SIP phones
but do not have feature parity with their SCCP counterparts.
Cisco IP Phone Models
Cisco IP Phones range from entry-level phones employing a single directory number, oneway
speakerphones, and no display to high-end phones with high-resolution, color, touchscreen
displays and Gigabit Ethernet connectivity. Differences in hardware capabilities
include the following:
■ Screen: Different models have screens with different resolution, size, color, and touchscreen
capabilities.
■ Codec support: All Cisco IP Phones support G.711 and G.729 codecs. Most of the
Cisco IP Phones support the Cisco wideband audio codec. All Type B phone models
support the Internet low-bandwidth codec (iLBC) at 15.2 kbps, and G.722 wideband
audio codec at 64 kbps. The G.722 audio codec requires a high-fidelity handset that
ships only with the 79x2 and 79x5 phone models. Other Type B phones require a highfidelity
handset upgrade to support the G.722 audio codec.
■ LAN: Most Cisco IP Phones have a PC port so that a PC can be connected to the
network without requiring its own switch port. Different phone models support
different speeds on the PC and switch port of the IP phone.
■ Phone buttons: The number of IP phone buttons differs per phone model.
■ Speakerphone and headset support: Most Cisco IP Phones offer speakerphone and
headset support.
■ Number of lines: The number of lines varies per phone model from one to eight.
Twenty-eight lines can be added to most of the phones with the purchase of two 7914
sidecar modules.
■ Other features: Some IP phones provide other special features such as video, WiFi
support, or dedicated support for use in conference rooms. The 7936 and 7937 phones
support external microphones to provide coverage to large conference rooms.
Entry-Level Cisco IP Phones
The Cisco Unified IP Phone models 7906 and 7911 fill the communication needs of cubicle,
retail, classroom, or manufacturing. These phones are satisfactory to users conducting low
to moderate telephone traffic without use of advanced features. Four dynamic soft keys
guide users through core business features and functions, while a pixel-based display combines
intuitive features, calling information, and Extensible Markup Language (XML) services
allowing IP phone service applications.
148 Chapter 7: Endpoints
The Type B entry-level phones mentioned support security features, including encrypted
signaling and media. Encrypted voice traffic and security concepts are covered in Cisco
Unified Communications IP Telephony, Part 2. All Type B entry-level phones support IEEE
802.3af Power over Ethernet (PoE), Cisco in-line power, or local power through an optional
power adapter.
Midrange Cisco IP Phones
Midrange Cisco Unified IP Phones (7940, 7941, 7942, 7960, 7961, and 7962 models)
address the communications needs of those that make frequent use of the phone system.
Users providing a majority of their business services through telephone communications
normally require a phone with more features than the entry-level phones. They provide a
high-quality speakerphone and four dynamic soft keys that guide users through call features
and functions. A built-in headset port and an integrated Ethernet switch are standard with
these phones. The phones also include audio controls for the full-duplex, high-quality,
hands-free speakerphone, handset, and headset.
All Type B phone models have LED-based line keys that allow call states to be represented
by different colors. These phones also support the iLBC and G.722 audio codecs.
High-End Cisco IP Phones
High-end Cisco Unified IP Phones include the 7945, 7965, 7970, 7971, and 7975 models.
These phones demonstrate the latest advances in Unified Communications technology,
including G.722 wideband audio support, backlit color display, and an integrated Gigabit
Ethernet chipset. They address the needs of executives and managers with significant
phone traffic.
All Cisco IP Phones include a display for easy access to communication information, date
and time display, calling party name and number, called party name and number, and presence
information. The Cisco IP Phones also accommodate XML applications that take advantage
of the display. The phones provide direct access to two to eight telephone lines (or a
combination of lines, speed dials, and direct access to telephony features), four or five
interactive soft keys that guide you through call features and functions, and an intuitive
four-way (plus Select key) navigation cluster. A hands-free speakerphone and handset
designed for high-fidelity wideband audio are standard, as is a built-in headset connection.
XML and presence are covered in more detail in later chapters.
NOTE For a detailed list of features per phone model, see the data sheets for the Cisco
Unified IP Phone 7900 series products.
CUCM Endpoints 149
Other Cisco IP Phones
Other Cisco Unified IP Phones and endpoints include the following models:
■ Cisco Unified IP Phone 7985: The 7985 is a personal desktop video phone for the
Cisco UC solution. The Cisco Unified IP Phone 7985 offers executives and managers
a productivity-enhancing video phone that enables instant, face-to-face communication
between physically disparate locations. The 7985 contains a video camera, LCD screen,
speaker, keypad, and handset incorporated into one easy-to-use unit.
■ Cisco Unified IP Conference Station 7936: This conference station combines
speakerphone conferencing technologies with Cisco voice communication technologies.
The 7936 is an IP-based, hands-free conference station. The new Cisco Unified IP
Conference Station 7937 is a Cisco-designed conference room solution that has a much
newer look and feel compared to the 7936 phone based on Polycom technology.
■ Cisco Unified Wireless IP Phone 7921: This phone provides a solution with an
intelligent wireless infrastructure. This wireless phone supports a host of calling
features and voice-quality enhancements. Because the Cisco Unified Wireless IP
Phone 7921 is designed to grow with system capabilities, features will keep pace with
new system enhancements. The 7921 is an 802.11g WLAN phone that supports XML
applications and extension mobility. The older 7920 WLAN phone did not support
XML applications or extension mobility and was limited to 802.11b wireless support.
■ Cisco Unified IP Phone 7931: The 7931 phone meets the communication needs of
retail, commercial, and manufacturing workers, and anyone with moderate telephone
traffic but specific call requirements. Dedicated hold, redial, and transfer keys facilitate
call handling in a retail environment. Illuminated mute and speakerphone keys give a
clear indication of speaker status. A pixel-based display with a white backlight makes
calling information easy to see and delivers a large number of physical buttons that can
be used for lines and speed dials.
Cisco IP Phones integrate seamlessly into a Cisco Unified network infrastructure. Cisco IP
Phones provide the following network-related features:
■ Cisco Discovery Protocol Version 2(CDP): Cisco IP Phones generate CDPv2
messages, common in most other Cisco network products. Cisco IP Phones listen for
CDP announcements sent out by Cisco Catalyst switches and desktop PCs. With CDP,
a Cisco Catalyst switch can configure the phone’s voice VLAN. CDP is also useful for
150 Chapter 7: Endpoints
tracking telephony devices when 911 is called. Cisco Emergency Responder is an
enhanced 911 server that finds mobile users in a dynamic work environment. The
Cisco Emergency Responder server is notified by CUCM when there is a new phone
registration in the cluster. Cisco Emergency Responder contacts the switches and
routers to physically find the device. CDP announcements from the IP phone and
IP Communicator make this discovery process viable. The Cisco Unified Video
Advantage client also uses CDP to associate the video-enabled PC to the IP phone.
Cisco Unified Video Advantage is covered later in this book.
■ DHCP: Cisco IP Phones can have static IP configurations entered at the IP phone or
dynamic IP addresses assigned from a DHCP server.
■ MAC address-based device identification: Cisco IP Phones are identified by the
burned-in MAC address of the IP phone. This allows the device to be moved between
subnets and simplifies DHCP configuration because no specific IP address is required
for an individual phone.
■ TFTP: Cisco IP Phone configurations are downloaded from the TFTP server component
in CUCM. CUCM dynamically generates device-specific configuration files and
makes them available for download at one or more TFTP servers. Cisco IP Phones
obtain the IP address of the TFTP server via DHCP (option 150) and load the appropriate
configuration file based on the MAC address. A phone with a MAC address of
012345012345 will request a configuration file of 012345012345.cnf.xml from the
TFTP server. All configuration files are based on the XML programming language.
■ PoE: Cisco IP Phones do not require wall power. The phones obtain power over
Ethernet from a PoE-compliant LAN switch. Various Cisco Catalyst switches provide
Power over Ethernet in different capacities. The older Catalyst switches with power
support provide Cisco power only, whereas the newer switches provide both IEEE
802.3af and Cisco power. PoE eliminates the need for extra power adapters and cabling
at user workspaces. It also allows power backup in a centralized location in situations
where the phone system must be operational during a power outage.
■ PC port: Cisco IP Phones allow PCs to be connected to a PC port at the IP phone and
then share the uplink toward the switch. The voice VLAN feature of Cisco Catalyst
switches separates the phone and PC traffic into different VLANs on a single access
port at the LAN switch.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A variety of endpoints, from Cisco and third-party manufacturers, can be used with CUCM.
Endpoints include IP phones, analog gateways, and video endpoints.
CUCM has widespread support for the following protocols to be used for endpoints: SCCP,
SIP, and H.323. Figure 7-1 illustrates some of the various protocol options to connect to
CUCM.
Figure 7-1 CUCM Endpoints
■ Type A phones: These are the following Cisco Unified IP Phones: 7905, 7912, 7940,
and 7960.
■ Type B phones: These are the following Cisco Unified IP Phones: 7906, 7911, 7931,
7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971, and 7975.
Analog Station
Gateways
Cisco SCCP-Only
Phones
CUCM
Cisco Unified
IP Phones
Third-Party
H.323 Endpoints
Third-Party
SIP Endpoints
SCCP Video
Phones
SCCP
SIP
H.323
CUCM Endpoints 145
Cisco also offers software-based phones such as the older Cisco IP SoftPhone, Cisco IP
Communicator (CIPC), and Cisco Unified Personal Communicator (CUPC). CIPC is a
software-based version of the 7970 Cisco IP Phone. CIPC has always supported SCCP, and
SIP support was added with CIPC 2.1. The CUPC requires a Cisco Unified Presence Server
(CUPS) to register. The CUPS represents a UC client that operates as a phone, video device,
and instant messenger client. CUPC can be used to promote a voice call into an audioconference,
video call, or videoconference if the network has sufficient resources. All of
this can be done while using CUPC to instant message different people.
The Cisco Unified IP Phone 7902 and Cisco Unified IP Phone 7910 models support SCCP
only and are no longer being sold (End of Sale [EoS]).
The Cisco Unified IP Phone 7985 is a desktop video phone, whereas the Cisco Unified IP
Phone 7920 and 7921 models are wireless LAN (WiFi) phones. The Cisco Unified IP Phone
7935, 7936, and 7937 models are conference stations. The 7935 and 7936 endpoints support
SCCP only.
Third-party products are available for most of the supported protocols. Nokia supports the
Cisco Unified Mobile Communicator. Cisco Unified Mobile Communicator is a software
client that is used on Nokia dual-mode mobile phones, allowing cellular PDA phones to
register with CUCM. Tandberg and Sony produce various SCCP-enabled video endpoints,
and IP blue offers an SCCP-based software IP phone that emulates standard Cisco 79xx
phone lines. Many other third-party endpoints for SIP and H.323 can also be found on
the market.
Endpoint Features
The features supported on the Cisco IP Phones vary by the device protocol in which the
phone is running. The protocols can be categorized into three groups:
■ SCCP: SCCP is a Cisco proprietary protocol and is typically used only by Cisco IP
endpoints. Third-party companies such as Sony, Tandberg, and VTGO (IP blue) have
licensed SCCP. SCCP offers a rich set of telephony features that are supported on most
Cisco handsets.
■ Third-party SIP or H.323: CUCM supports standards-based SIP and H.323 endpoints.
The number of standardized telephony features, however, is limited when compared to
the feature richness of SCCP.
NOTE The Cisco Unified IP Phone 7902, 7905, 7910, 7912, and 7935 are End of Sale
(EoS). Cisco no longer sells these units, but it will continue to support them until the end
of life (EoL) date.
146 Chapter 7: Endpoints
■ SIP support for Cisco IP Phones: Cisco IP Phones using SIP support different
features depending on which Cisco IP Phone is used. Many additional features are
supported, compared to the SIP third-party phone support. Cisco SIP Type B phones
support similar features when compared to those supported with SCCP. The number of
features supported depends significantly on the Cisco IP Phone model being used.
Table 7-1 displays the support between various phone types and protocols. Third-party SIP
and H.323 endpoints can be used with any other IP telephony devices or systems, including
CUCM. Third-party SIP and H.323 are limited regarding the number of supported
telephony features, when compared to Cisco SIP or SCCP IP Phones.
The Cisco Unified IP Phone models 7940 and 7960 can be loaded with a special firmware
that provides RFC 3261 SIP support for third-party PBX systems. When these models
interact with CUCM, both SIP and SCCP implementations provide more features than the
phones operating on a third-party SIP proxy server. This option is used more by customers
who connect to other IP communication systems but want to take advantage of the superior
voice quality and look and feel of the Cisco IP Phones. Some Internet telephony service
providers (ITSP) offering standard SIP telephony services provide their customers with
preconfigured Cisco Unified IP Phone models 7940 or 7960 to be used to connect to their
SIP proxy servers.
The Cisco Unified IP Phone models 7905 and 7912 can also be loaded with an H.323
firmware to be used with third-party PBX vendors using H.323.
Cisco IP Phones with SIP support a different number of features depending on whether
the phone is a Type A or B model. Type A models include the 7905, 7912, 7940, and 7960.
Type A phones support a large number of features but many fewer features than SCCP. The
Table 7-1 Endpoint Support
Third-Party
SIP Cisco IP Phone SIP SCCP
Third-Party
H.323
Third-Party
PBX Support
Yes No No Yes
Feature
Support
Small Type A phones: Medium
Type B phones: High
Large Large
Supported
Phones
Third party Type A and B All Cisco phones
Third-party SCCP
phones
Third party
CUCM Endpoints 147
Type A phones also have a different screen appearance when compared to their SCCP
counterparts. Type B SIP phones support many more features than Type A SIP phones
but do not have feature parity with their SCCP counterparts.
Cisco IP Phone Models
Cisco IP Phones range from entry-level phones employing a single directory number, oneway
speakerphones, and no display to high-end phones with high-resolution, color, touchscreen
displays and Gigabit Ethernet connectivity. Differences in hardware capabilities
include the following:
■ Screen: Different models have screens with different resolution, size, color, and touchscreen
capabilities.
■ Codec support: All Cisco IP Phones support G.711 and G.729 codecs. Most of the
Cisco IP Phones support the Cisco wideband audio codec. All Type B phone models
support the Internet low-bandwidth codec (iLBC) at 15.2 kbps, and G.722 wideband
audio codec at 64 kbps. The G.722 audio codec requires a high-fidelity handset that
ships only with the 79x2 and 79x5 phone models. Other Type B phones require a highfidelity
handset upgrade to support the G.722 audio codec.
■ LAN: Most Cisco IP Phones have a PC port so that a PC can be connected to the
network without requiring its own switch port. Different phone models support
different speeds on the PC and switch port of the IP phone.
■ Phone buttons: The number of IP phone buttons differs per phone model.
■ Speakerphone and headset support: Most Cisco IP Phones offer speakerphone and
headset support.
■ Number of lines: The number of lines varies per phone model from one to eight.
Twenty-eight lines can be added to most of the phones with the purchase of two 7914
sidecar modules.
■ Other features: Some IP phones provide other special features such as video, WiFi
support, or dedicated support for use in conference rooms. The 7936 and 7937 phones
support external microphones to provide coverage to large conference rooms.
Entry-Level Cisco IP Phones
The Cisco Unified IP Phone models 7906 and 7911 fill the communication needs of cubicle,
retail, classroom, or manufacturing. These phones are satisfactory to users conducting low
to moderate telephone traffic without use of advanced features. Four dynamic soft keys
guide users through core business features and functions, while a pixel-based display combines
intuitive features, calling information, and Extensible Markup Language (XML) services
allowing IP phone service applications.
148 Chapter 7: Endpoints
The Type B entry-level phones mentioned support security features, including encrypted
signaling and media. Encrypted voice traffic and security concepts are covered in Cisco
Unified Communications IP Telephony, Part 2. All Type B entry-level phones support IEEE
802.3af Power over Ethernet (PoE), Cisco in-line power, or local power through an optional
power adapter.
Midrange Cisco IP Phones
Midrange Cisco Unified IP Phones (7940, 7941, 7942, 7960, 7961, and 7962 models)
address the communications needs of those that make frequent use of the phone system.
Users providing a majority of their business services through telephone communications
normally require a phone with more features than the entry-level phones. They provide a
high-quality speakerphone and four dynamic soft keys that guide users through call features
and functions. A built-in headset port and an integrated Ethernet switch are standard with
these phones. The phones also include audio controls for the full-duplex, high-quality,
hands-free speakerphone, handset, and headset.
All Type B phone models have LED-based line keys that allow call states to be represented
by different colors. These phones also support the iLBC and G.722 audio codecs.
High-End Cisco IP Phones
High-end Cisco Unified IP Phones include the 7945, 7965, 7970, 7971, and 7975 models.
These phones demonstrate the latest advances in Unified Communications technology,
including G.722 wideband audio support, backlit color display, and an integrated Gigabit
Ethernet chipset. They address the needs of executives and managers with significant
phone traffic.
All Cisco IP Phones include a display for easy access to communication information, date
and time display, calling party name and number, called party name and number, and presence
information. The Cisco IP Phones also accommodate XML applications that take advantage
of the display. The phones provide direct access to two to eight telephone lines (or a
combination of lines, speed dials, and direct access to telephony features), four or five
interactive soft keys that guide you through call features and functions, and an intuitive
four-way (plus Select key) navigation cluster. A hands-free speakerphone and handset
designed for high-fidelity wideband audio are standard, as is a built-in headset connection.
XML and presence are covered in more detail in later chapters.
NOTE For a detailed list of features per phone model, see the data sheets for the Cisco
Unified IP Phone 7900 series products.
CUCM Endpoints 149
Other Cisco IP Phones
Other Cisco Unified IP Phones and endpoints include the following models:
■ Cisco Unified IP Phone 7985: The 7985 is a personal desktop video phone for the
Cisco UC solution. The Cisco Unified IP Phone 7985 offers executives and managers
a productivity-enhancing video phone that enables instant, face-to-face communication
between physically disparate locations. The 7985 contains a video camera, LCD screen,
speaker, keypad, and handset incorporated into one easy-to-use unit.
■ Cisco Unified IP Conference Station 7936: This conference station combines
speakerphone conferencing technologies with Cisco voice communication technologies.
The 7936 is an IP-based, hands-free conference station. The new Cisco Unified IP
Conference Station 7937 is a Cisco-designed conference room solution that has a much
newer look and feel compared to the 7936 phone based on Polycom technology.
■ Cisco Unified Wireless IP Phone 7921: This phone provides a solution with an
intelligent wireless infrastructure. This wireless phone supports a host of calling
features and voice-quality enhancements. Because the Cisco Unified Wireless IP
Phone 7921 is designed to grow with system capabilities, features will keep pace with
new system enhancements. The 7921 is an 802.11g WLAN phone that supports XML
applications and extension mobility. The older 7920 WLAN phone did not support
XML applications or extension mobility and was limited to 802.11b wireless support.
■ Cisco Unified IP Phone 7931: The 7931 phone meets the communication needs of
retail, commercial, and manufacturing workers, and anyone with moderate telephone
traffic but specific call requirements. Dedicated hold, redial, and transfer keys facilitate
call handling in a retail environment. Illuminated mute and speakerphone keys give a
clear indication of speaker status. A pixel-based display with a white backlight makes
calling information easy to see and delivers a large number of physical buttons that can
be used for lines and speed dials.
Cisco IP Phones integrate seamlessly into a Cisco Unified network infrastructure. Cisco IP
Phones provide the following network-related features:
■ Cisco Discovery Protocol Version 2(CDP): Cisco IP Phones generate CDPv2
messages, common in most other Cisco network products. Cisco IP Phones listen for
CDP announcements sent out by Cisco Catalyst switches and desktop PCs. With CDP,
a Cisco Catalyst switch can configure the phone’s voice VLAN. CDP is also useful for
150 Chapter 7: Endpoints
tracking telephony devices when 911 is called. Cisco Emergency Responder is an
enhanced 911 server that finds mobile users in a dynamic work environment. The
Cisco Emergency Responder server is notified by CUCM when there is a new phone
registration in the cluster. Cisco Emergency Responder contacts the switches and
routers to physically find the device. CDP announcements from the IP phone and
IP Communicator make this discovery process viable. The Cisco Unified Video
Advantage client also uses CDP to associate the video-enabled PC to the IP phone.
Cisco Unified Video Advantage is covered later in this book.
■ DHCP: Cisco IP Phones can have static IP configurations entered at the IP phone or
dynamic IP addresses assigned from a DHCP server.
■ MAC address-based device identification: Cisco IP Phones are identified by the
burned-in MAC address of the IP phone. This allows the device to be moved between
subnets and simplifies DHCP configuration because no specific IP address is required
for an individual phone.
■ TFTP: Cisco IP Phone configurations are downloaded from the TFTP server component
in CUCM. CUCM dynamically generates device-specific configuration files and
makes them available for download at one or more TFTP servers. Cisco IP Phones
obtain the IP address of the TFTP server via DHCP (option 150) and load the appropriate
configuration file based on the MAC address. A phone with a MAC address of
012345012345 will request a configuration file of 012345012345.cnf.xml from the
TFTP server. All configuration files are based on the XML programming language.
■ PoE: Cisco IP Phones do not require wall power. The phones obtain power over
Ethernet from a PoE-compliant LAN switch. Various Cisco Catalyst switches provide
Power over Ethernet in different capacities. The older Catalyst switches with power
support provide Cisco power only, whereas the newer switches provide both IEEE
802.3af and Cisco power. PoE eliminates the need for extra power adapters and cabling
at user workspaces. It also allows power backup in a centralized location in situations
where the phone system must be operational during a power outage.
■ PC port: Cisco IP Phones allow PCs to be connected to a PC port at the IP phone and
then share the uplink toward the switch. The voice VLAN feature of Cisco Catalyst
switches separates the phone and PC traffic into different VLANs on a single access
port at the LAN switch.
LDAPv3 Synchronization Configuration CCIE Training in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The LDAPv3 synchronization configuration procedure includes the following steps:
Step 1 Add CUCM directory user and assign administrator access rights in the
LDAPv3 directory (depends on LDAPv3 directory server).
Step 2 Activate the Cisco DirSync service.
Step 3 Configure the LDAPv3 system.
Step 4 Configure the LDAPv3 directory.
The synchronization is performed by a feature service called Cisco DirSync. DirSync has
to be activated on the publisher server.
The Cisco DirSync service has some configurable service parameters that you can configure
from the following CUCM Administration location: System > Service Parameters. Choose
the Cisco DirSync service from the appropriate server. The service parameters include the
maximum number of synchronization agreements, hosts (directory servers), and several
timers.
Navigate to System > LDAPv3 > LDAPv3 System to configure the LDAPv3 server type
(Microsoft Active Directory or other) and the LDAPv3 attribute that should be mapped to
the CUCM user ID. Check the Enable Synchronizing from LDAP Server check box, as
shown in Figure 6-16.
Figure 6-16 LDAPv3 System Configuration
LDAPv3 Synchronization Configuration 133
The LDAPv3 directory configuration is configured once per synchronization agreement
(session). Navigate to System > LDAPv3 > LDAPv3 Directory and click Add New to add
a new synchronization agreement. A warning will display indicating that all existing end
users who are not found in the LDAPv3 directory will be deleted. The LDAPv3 directory
will overwrite the CUCM user database. Figure 6-17 shows the LDAPv3 directory
configuration.
Figure 6-17 LDAPv3 Directory Configuration
Navigate to User Management > End User and check the LDAPv3 sync status to verify
LDAPv3 synchronization. Synchronized users are marked Active. Inactive users were
configured in CUCM, but not in LDAPv3. Inactive users will be deleted after a 24-hour
period. Microsoft refers to this 24-hour period as tombstoning. Tombstoning ensures that
misconfigurations do not immediately impact users. Users can no longer be added or
deleted from the CUCM database. Users can be synchronized only from the LDAPv3
server.
Click an active user to view that user’s configuration page. Username, personal, and organizational
settings cannot be modified; however, password, PIN, digest credentials, and PC
association can be changed.
Configure Unified CM directory
user (as configured in LDAP)
Configure LDAP server(s)
Configure user filed mappings
Configure synchronization schedule
Configure search base for
this synchronization agreement
134 Chapter 6: Managing User Accounts
LDAPv3 Authentication
When LDAPv3 authentication is enabled, CUCM performs the following tasks:
■ End-user passwords are authenticated against the corporate directory.
■ End-user passwords are managed in LDAPv3, not in CUCM.
■ End-user passwords are stored only in LDAPv3.
Application users are still authenticated against the CUCM database. Application-user
passwords are stored only in the CUCM database.
End-user PINs and other CUCM user settings are configured and stored in CUCM only.
Personal and organizational user settings such as phone number, manager, first, middle, and
last name are either managed and stored in LDAPv3 and replicated to CUCM (LDAPv3
synchronization) or managed and stored in CUCM only. (LDAPv3 synchronization is not
used.)
In Figure 6-18, LDAPv3 authentication is enabled. End users are authenticated against
the LDAPv3 directory, whereas application users are authenticated against the CUCM
database. Extension Mobility, Attendant Console, Cisco Agent Desktop, and Cisco Unified
Manager Assistant are examples of applications that require a PIN to be entered from the
end user. The PIN is authenticated against the CUCM database, not against the LDAPv3
server.
It is best practice to configure CUCM to query a Microsoft Active Directory (AD) Global
Catalog (GC) server for faster response times. Configure the LDAPv3 server information
in the LDAPv3 Authentication page to point to the IP address or hostname of a domain
controller that has the Global Catalog role enabled, and configure the LDAPv3 port as
3268. This will enable queries against a Microsoft Global Catalog server.
The use of Global Catalog for authentication becomes more efficient if the users belong
to multiple Microsoft AD domains. It allows CUCM to authenticate users immediately
without having to follow referrals. Point CUCM to a Global Catalog server and set the
LDAPv3 user search base to the top of the root domain.
Microsoft AD forests that encompass multiple trees require additional considerations. A
single LDAPv3 search base cannot cover multiple namespaces. CUCM must use a different
mechanism to authenticate users across discontiguous namespaces.
LDAPv3 Synchronization Configuration 135
Figure 6-18 LDAPv3 Authentication Overview
To support synchronization with an AD forest that has multiple trees, you must use the
UserPrincipalName (UPN) attribute as the user ID within CUCM. The CUCM LDAPv3
authentication configuration page does not allow the LDAPv3 Search Base field when the
User ID field uses the UPN. The LDAPv3 configuration page will display the note
“LDAPv3 user search base is formed using userid information.”
The user search base is derived from the UPN suffix of each user, as shown in Figure 6-19.
In this example, a Microsoft AD forest consists of two trees: avvid.info and vse.lab. Because
the same username may appear in both trees, CUCM has been configured to use the UPN
to uniquely identify users in its database during the synchronization and authentication processes.
A user named John Doe exists in both the avvid.info tree and the vse.lab tree. Figure 6-19
and the steps that follow illustrate the authentication process for the first user, whose UPN
is jdoe@avvid.info.
DirSync
DB
WWW
Corporate
Directory
(Microsoft AD,
Netscape/iPlanet)
User Data
Synchronization
CUCM Server
Embedded
Database
IMS
IPMA
IPCC
Express
Attendant
Console
Password
Authentication
Password
Authentication
End users: password
(includes CUCM
Administrators with MLA)
Application Users
(ac, jtapi, CCMAdministrator, ...)
End Users: PIN
(EM Login)
PIN
Authentication
136 Chapter 6: Managing User Accounts
Figure 6-19 LDAPv3 Authentication When Using Microsoft AD with Multiple Domains or Trees
1. The user authenticates to CUCM via HTTPS with its username (which corresponds to
the UPN) and password.
2. CUCM performs an LDAPv3 query against a Microsoft AD Global Catalog server. The
username is specified in the UPN (information before the @ sign). The LDAPv3 search
base is derived from the UPN suffix (information after the @ sign). In Figure 6-19, the
username is jdoe, and the LDAPv3 search base is “dc=avvid, dc=info”.
Microsoft AD identifies the correct Distinguished Name corresponding to the
username in the tree specified by the LDAPv3 query. In this case, “cn=jdoe, ou=Users,
dc=avvid, dc=info”.
3. Microsoft Active Directory responds via LDAPv3 to CUCM with the full
Distinguished Name for this user.
4. CUCM attempts an LDAPv3 bind with the Distinguished Name provided and the
password initially entered by the user. The authentication process then continues as in
the standard case.
Support for LDAPv3 authentication with Microsoft AD forests containing multiple trees
relies exclusively on the approach just described. Therefore, support is limited to deployments
where the UPN suffix of a user corresponds to the root domain of the tree where the
user resides. If the UPN suffix is disjointed from the actual namespace of the tree, it is not
possible to authenticate CUCM users against the entire Microsoft Active Directory forest. (It
is, however, still possible to use a different attribute as the user ID and limit the integration
to a single tree within the forest.)
dc=avvid, dc=info
avvid.info
ou=Users ou=other
bfoo jdoe
dc=vse, dc=lab
vse.lab
ou=Users ou=other
jsmith jdoe jbrown
John Doe
(avvid.info)
M
CUCM Active Directory
Global Catalog
Server
Response: full DN
John Doe
(vse.lab)
jdoe@vse.lab
********
jdoe@avvid.info
********
1
3
Search: jdoe
Base: dc=avvid, dc=info
Bind: full DN + ********
2
4
5
LDAPv3 Synchronization Configuration 137
LDAPv3 Authentication Configuration
The LDAPv3 synchronization configuration procedure includes the following steps:
Step 1 Add the CUCM directory user and assign administrator access rights in
the LDAPv3 directory.
Step 2 Configure LDAPv3 authentication. Navigate to System > LDAPv3 >
LDAPv3 Authentication to configure the CUCM directory user
configured in the LDAPv3 directory, the user search base, and the
LDAPv3 server(s). Check the Use LDAP Authentication for End Users
check box, as shown in Figure 6-20.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The LDAPv3 synchronization configuration procedure includes the following steps:
Step 1 Add CUCM directory user and assign administrator access rights in the
LDAPv3 directory (depends on LDAPv3 directory server).
Step 2 Activate the Cisco DirSync service.
Step 3 Configure the LDAPv3 system.
Step 4 Configure the LDAPv3 directory.
The synchronization is performed by a feature service called Cisco DirSync. DirSync has
to be activated on the publisher server.
The Cisco DirSync service has some configurable service parameters that you can configure
from the following CUCM Administration location: System > Service Parameters. Choose
the Cisco DirSync service from the appropriate server. The service parameters include the
maximum number of synchronization agreements, hosts (directory servers), and several
timers.
Navigate to System > LDAPv3 > LDAPv3 System to configure the LDAPv3 server type
(Microsoft Active Directory or other) and the LDAPv3 attribute that should be mapped to
the CUCM user ID. Check the Enable Synchronizing from LDAP Server check box, as
shown in Figure 6-16.
Figure 6-16 LDAPv3 System Configuration
LDAPv3 Synchronization Configuration 133
The LDAPv3 directory configuration is configured once per synchronization agreement
(session). Navigate to System > LDAPv3 > LDAPv3 Directory and click Add New to add
a new synchronization agreement. A warning will display indicating that all existing end
users who are not found in the LDAPv3 directory will be deleted. The LDAPv3 directory
will overwrite the CUCM user database. Figure 6-17 shows the LDAPv3 directory
configuration.
Figure 6-17 LDAPv3 Directory Configuration
Navigate to User Management > End User and check the LDAPv3 sync status to verify
LDAPv3 synchronization. Synchronized users are marked Active. Inactive users were
configured in CUCM, but not in LDAPv3. Inactive users will be deleted after a 24-hour
period. Microsoft refers to this 24-hour period as tombstoning. Tombstoning ensures that
misconfigurations do not immediately impact users. Users can no longer be added or
deleted from the CUCM database. Users can be synchronized only from the LDAPv3
server.
Click an active user to view that user’s configuration page. Username, personal, and organizational
settings cannot be modified; however, password, PIN, digest credentials, and PC
association can be changed.
Configure Unified CM directory
user (as configured in LDAP)
Configure LDAP server(s)
Configure user filed mappings
Configure synchronization schedule
Configure search base for
this synchronization agreement
134 Chapter 6: Managing User Accounts
LDAPv3 Authentication
When LDAPv3 authentication is enabled, CUCM performs the following tasks:
■ End-user passwords are authenticated against the corporate directory.
■ End-user passwords are managed in LDAPv3, not in CUCM.
■ End-user passwords are stored only in LDAPv3.
Application users are still authenticated against the CUCM database. Application-user
passwords are stored only in the CUCM database.
End-user PINs and other CUCM user settings are configured and stored in CUCM only.
Personal and organizational user settings such as phone number, manager, first, middle, and
last name are either managed and stored in LDAPv3 and replicated to CUCM (LDAPv3
synchronization) or managed and stored in CUCM only. (LDAPv3 synchronization is not
used.)
In Figure 6-18, LDAPv3 authentication is enabled. End users are authenticated against
the LDAPv3 directory, whereas application users are authenticated against the CUCM
database. Extension Mobility, Attendant Console, Cisco Agent Desktop, and Cisco Unified
Manager Assistant are examples of applications that require a PIN to be entered from the
end user. The PIN is authenticated against the CUCM database, not against the LDAPv3
server.
It is best practice to configure CUCM to query a Microsoft Active Directory (AD) Global
Catalog (GC) server for faster response times. Configure the LDAPv3 server information
in the LDAPv3 Authentication page to point to the IP address or hostname of a domain
controller that has the Global Catalog role enabled, and configure the LDAPv3 port as
3268. This will enable queries against a Microsoft Global Catalog server.
The use of Global Catalog for authentication becomes more efficient if the users belong
to multiple Microsoft AD domains. It allows CUCM to authenticate users immediately
without having to follow referrals. Point CUCM to a Global Catalog server and set the
LDAPv3 user search base to the top of the root domain.
Microsoft AD forests that encompass multiple trees require additional considerations. A
single LDAPv3 search base cannot cover multiple namespaces. CUCM must use a different
mechanism to authenticate users across discontiguous namespaces.
LDAPv3 Synchronization Configuration 135
Figure 6-18 LDAPv3 Authentication Overview
To support synchronization with an AD forest that has multiple trees, you must use the
UserPrincipalName (UPN) attribute as the user ID within CUCM. The CUCM LDAPv3
authentication configuration page does not allow the LDAPv3 Search Base field when the
User ID field uses the UPN. The LDAPv3 configuration page will display the note
“LDAPv3 user search base is formed using userid information.”
The user search base is derived from the UPN suffix of each user, as shown in Figure 6-19.
In this example, a Microsoft AD forest consists of two trees: avvid.info and vse.lab. Because
the same username may appear in both trees, CUCM has been configured to use the UPN
to uniquely identify users in its database during the synchronization and authentication processes.
A user named John Doe exists in both the avvid.info tree and the vse.lab tree. Figure 6-19
and the steps that follow illustrate the authentication process for the first user, whose UPN
is jdoe@avvid.info.
DirSync
DB
WWW
Corporate
Directory
(Microsoft AD,
Netscape/iPlanet)
User Data
Synchronization
CUCM Server
Embedded
Database
IMS
IPMA
IPCC
Express
Attendant
Console
Password
Authentication
Password
Authentication
End users: password
(includes CUCM
Administrators with MLA)
Application Users
(ac, jtapi, CCMAdministrator, ...)
End Users: PIN
(EM Login)
PIN
Authentication
136 Chapter 6: Managing User Accounts
Figure 6-19 LDAPv3 Authentication When Using Microsoft AD with Multiple Domains or Trees
1. The user authenticates to CUCM via HTTPS with its username (which corresponds to
the UPN) and password.
2. CUCM performs an LDAPv3 query against a Microsoft AD Global Catalog server. The
username is specified in the UPN (information before the @ sign). The LDAPv3 search
base is derived from the UPN suffix (information after the @ sign). In Figure 6-19, the
username is jdoe, and the LDAPv3 search base is “dc=avvid, dc=info”.
Microsoft AD identifies the correct Distinguished Name corresponding to the
username in the tree specified by the LDAPv3 query. In this case, “cn=jdoe, ou=Users,
dc=avvid, dc=info”.
3. Microsoft Active Directory responds via LDAPv3 to CUCM with the full
Distinguished Name for this user.
4. CUCM attempts an LDAPv3 bind with the Distinguished Name provided and the
password initially entered by the user. The authentication process then continues as in
the standard case.
Support for LDAPv3 authentication with Microsoft AD forests containing multiple trees
relies exclusively on the approach just described. Therefore, support is limited to deployments
where the UPN suffix of a user corresponds to the root domain of the tree where the
user resides. If the UPN suffix is disjointed from the actual namespace of the tree, it is not
possible to authenticate CUCM users against the entire Microsoft Active Directory forest. (It
is, however, still possible to use a different attribute as the user ID and limit the integration
to a single tree within the forest.)
dc=avvid, dc=info
avvid.info
ou=Users ou=other
bfoo jdoe
dc=vse, dc=lab
vse.lab
ou=Users ou=other
jsmith jdoe jbrown
John Doe
(avvid.info)
M
CUCM Active Directory
Global Catalog
Server
Response: full DN
John Doe
(vse.lab)
jdoe@vse.lab
********
jdoe@avvid.info
********
1
3
Search: jdoe
Base: dc=avvid, dc=info
Bind: full DN + ********
2
4
5
LDAPv3 Synchronization Configuration 137
LDAPv3 Authentication Configuration
The LDAPv3 synchronization configuration procedure includes the following steps:
Step 1 Add the CUCM directory user and assign administrator access rights in
the LDAPv3 directory.
Step 2 Configure LDAPv3 authentication. Navigate to System > LDAPv3 >
LDAPv3 Authentication to configure the CUCM directory user
configured in the LDAPv3 directory, the user search base, and the
LDAPv3 server(s). Check the Use LDAP Authentication for End Users
check box, as shown in Figure 6-20.
LDAPv3 Synchronization CCNP Training in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The Cisco Directory Synchronization (DirSync) process is used to synchronize a number
of user attributes. The process can be scheduled to run at different intervals or performed
manually. Users are provisioned on the corporate directory and replicated to the CUCM
LDAPv3 database when directory synchronization is used.
LDAPv3 synchronization disallows end-user additions or deletions from CUCM
Administration. End users are added and deleted only in the LDAPv3 directory.
Users and their pertinent personal and organizational data are replicated from LDAPv3 to
CUCM. Most replicated user parameters are read-only in CUCM Administration. User
passwords and CUCM settings must be configured from CUCM Administration.
CUCM authenticates user credentials against a corporate LDAPv3 directory when using
LDAPv3 authentication. End-user passwords are not stored in the CUCM database.
CUCM user data (associated devices, username, password, PIN, and so on) is stored in the
CUCM database. To avoid duplication of effort in the management of user accounts,
combine LDAPv3 authentication with LDAPv3 synchronization. LDAPv3 synchronization
will force the user authentication request to be processed against the LDAPv3 server.
NOTE Application users are not affected by LDAPv3 integration. They are always
configured from CUCM Administration, and their data is always stored in the CUCM
configuration database.
128 Chapter 6: Managing User Accounts
Synchronization Agreements
LDAPv3 synchronization is performed in one of the following ways:
■ Full synchronization is used with Microsoft Active Directory 2000 and 2003. All
records are replicated from the LDAPv3 directory to the CUCM database. Full synchronization
can cause considerable load in large deployments. Synchronization events
should be carefully planned in large deployments.
■ Incremental synchronization is a method used with all supported directory servers
other than Microsoft Active Directory. Only changes are propagated to the CUCM
database with the incremental synchronization mechanism. The incremental
synchronization method requires fewer resources than the full synchronization
method.
Synchronization agreements are pointers to a domain or subdomain within an LDAPv3
structure. Synchronization agreements have to use the same synchronization method.
Synchronization agreements between Microsoft Active Directory and other LDAPv3
servers on the same CUCM cluster are not supported.
One LDAPv3 username attribute (sAMAccountName, uid, mail, or telphoneNumber) has
to be mapped to the User ID field of a user in CUCM. This identifier must be unique across
all users.
Synchronization between a corporate LDAPv3 directory and CUCM eliminates the need to
reconfigure users who already exist in the LDAPv3 directory.
Figure 6-14 illustrates the authentication of users against the CUCM database and user
lookups from the Cisco IP Phone.
Table 6-3 shows the differences between end users and application users in the CUCM user
database.
Table 6-3 Directory Synchronization Parameters
End Users Application Users
Associated with a person Associated with an application
Interactive logins Noninteractive logins
User features and administrator logins Application authorization
Included in user directory Not included in user directory
Synchronized from LDAPv3 server No LDAPv3 synchronization
LDAPv3 Synchronization 129
Figure 6-14 LDAPv3 Synchronization
The sn attribute in the LDAPv3 server must be populated with data; otherwise, the record
will not be imported. If the primary attribute used during import of end-user accounts
matches any application user in the CUCM database, the user is skipped.
CUCM database fields provide a choice of directory attributes, but you can choose only a
single mapping for each synchronization agreement.
Synchronization Search Base
A synchronization agreement specifies a search base. A search base is an area of the
directory that is used for synchronization. The synchronization agreement specifies a
position in the directory tree where CUCM begins its search. The search level has access to
all levels lower in the tree, but not to higher levels in the tree.
DirSync
DB
WWW
Authentication
Authentication
Identity Management
System (IMS) Library
Web
Service
CUCM User Options,
Extension Mobility,
CUCM Administrators
IP Phone
User
Lookup
User
Lookup
Directories
Button
HTTPS HTTP
Corporate
Directory
(Microsoft AD,
Netscape/iPlanet)
User Data
Synchronization
LDAP(S)
CUCM Server
Embedded
Database
IMS
130 Chapter 6: Managing User Accounts
Users should be organized in a structure in the LDAPv3 directory. The existing structure
can be used to control the user groups that were imported. A single synchronization
agreement can specify the root of the domain, and all users of the domain are synchronized.
The search base does not normally point to the domain root.
In Figure 6-15, two synchronization agreements are represented. One synchronization
agreement specifies User Search Base 1 and imports users jsmith, jdoe, and jbloggs. These
users are in separate organizational unit (OU) containers under the Site 1 Users organizational
unit. User Search Base 2 represents a second synchronization agreement and imports
users jjones, bfoo, and tbrown. The CCMDirMgr account is not imported because it does
not reside within one of the two specified user search bases.
Figure 6-15 User Search Base
CUCM performs a bind to the LDAPv3 directory using the LDAPv3 Manager Distinguished
Name in the LDAPv3 directory configuration. The account used for the LDAPv3
Manager Distinguished Name must be available in the LDAPv3 directory for CUCM to
log in. It is recommended that you create a specific account with the permission to read
all user objects within the subtree that was specified by the user search base.
It is possible to control the import of accounts by limiting read permissions of the LDAPv3
Manager Distinguished Name account. For example, if the account is restricted to have read
access to ou=Eng but not to ou=Mktg, only the accounts located under the Eng OU will be
synchronized.
Synchronization agreements can specify multiple directory servers for redundancy purposes.
dc=vse, dc=lab
ou=Site 1 Users ou=Site 2 Users
jsmith jdoe jbloggs
ou=Eng ou=Mktg jjones bfoo tbrown
ou=Service Accts
CCM Dir Mgr
No Synchronization
Agreement for
Service Accounts
CCM Dir Mgr is
not imported
User Search
Base 1
User Search
Base 2
LDAPv3 Synchronization 131
Each synchronization agreement is configured with a synchronization start time and a
period configured in hours, days, weeks, or months. A synchronization agreement can be
configured to run only once.
The synchronization process is as follows:
1. At the beginning of the synchronization process, all existing CUCM end-user accounts
are deactivated.
2. If there were any differences in the LDAPv3 server, LDAPv3 user accounts that exist
in the CUCM user database are reactivated, and their settings are updated.
3. LDAPv3 user accounts that exist in LDAPv3 only are added to the CUCM database
and activated.
4. Deactivated accounts are purged from the CUCM database after 24 hours.
Synchronization Best Practices
The account that CUCM uses to read the LDAPv3 directory should be configured in the
following way:
■ Create a dedicated account used only for synchronization. Set LDAPv3 server
permissions for this account to read all user objects located below the user search bases
specified in the synchronization agreements.
■ The password of the account should be set to never expire.
Synchronization times should be configured during intervals when there are no office hours.
All overhead and management processes are scheduled during off-hours to minimize the
CPU load overhead incurred as a result of synchronization. Call-processing impact should
be limited during business hours.
Different start times should be set to reduce the load on the servers when multiple
synchronization agreements are configured.
Avoid a single point of failure by configuring at least two LDAPv3 servers, and use IP
addresses rather than hostnames to eliminate DNS reliance.
The connection between the CUCM publisher server and the directory server can be
secured by enabling Secure LDAPv3 (sLDAPv3) on CUCM and the LDAPv3 server.
sLDAPv3 enables LDAPv3 to be sent over a Secure Sockets Layer (SSL) encryption at
128-bit-level encryption.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The Cisco Directory Synchronization (DirSync) process is used to synchronize a number
of user attributes. The process can be scheduled to run at different intervals or performed
manually. Users are provisioned on the corporate directory and replicated to the CUCM
LDAPv3 database when directory synchronization is used.
LDAPv3 synchronization disallows end-user additions or deletions from CUCM
Administration. End users are added and deleted only in the LDAPv3 directory.
Users and their pertinent personal and organizational data are replicated from LDAPv3 to
CUCM. Most replicated user parameters are read-only in CUCM Administration. User
passwords and CUCM settings must be configured from CUCM Administration.
CUCM authenticates user credentials against a corporate LDAPv3 directory when using
LDAPv3 authentication. End-user passwords are not stored in the CUCM database.
CUCM user data (associated devices, username, password, PIN, and so on) is stored in the
CUCM database. To avoid duplication of effort in the management of user accounts,
combine LDAPv3 authentication with LDAPv3 synchronization. LDAPv3 synchronization
will force the user authentication request to be processed against the LDAPv3 server.
NOTE Application users are not affected by LDAPv3 integration. They are always
configured from CUCM Administration, and their data is always stored in the CUCM
configuration database.
128 Chapter 6: Managing User Accounts
Synchronization Agreements
LDAPv3 synchronization is performed in one of the following ways:
■ Full synchronization is used with Microsoft Active Directory 2000 and 2003. All
records are replicated from the LDAPv3 directory to the CUCM database. Full synchronization
can cause considerable load in large deployments. Synchronization events
should be carefully planned in large deployments.
■ Incremental synchronization is a method used with all supported directory servers
other than Microsoft Active Directory. Only changes are propagated to the CUCM
database with the incremental synchronization mechanism. The incremental
synchronization method requires fewer resources than the full synchronization
method.
Synchronization agreements are pointers to a domain or subdomain within an LDAPv3
structure. Synchronization agreements have to use the same synchronization method.
Synchronization agreements between Microsoft Active Directory and other LDAPv3
servers on the same CUCM cluster are not supported.
One LDAPv3 username attribute (sAMAccountName, uid, mail, or telphoneNumber) has
to be mapped to the User ID field of a user in CUCM. This identifier must be unique across
all users.
Synchronization between a corporate LDAPv3 directory and CUCM eliminates the need to
reconfigure users who already exist in the LDAPv3 directory.
Figure 6-14 illustrates the authentication of users against the CUCM database and user
lookups from the Cisco IP Phone.
Table 6-3 shows the differences between end users and application users in the CUCM user
database.
Table 6-3 Directory Synchronization Parameters
End Users Application Users
Associated with a person Associated with an application
Interactive logins Noninteractive logins
User features and administrator logins Application authorization
Included in user directory Not included in user directory
Synchronized from LDAPv3 server No LDAPv3 synchronization
LDAPv3 Synchronization 129
Figure 6-14 LDAPv3 Synchronization
The sn attribute in the LDAPv3 server must be populated with data; otherwise, the record
will not be imported. If the primary attribute used during import of end-user accounts
matches any application user in the CUCM database, the user is skipped.
CUCM database fields provide a choice of directory attributes, but you can choose only a
single mapping for each synchronization agreement.
Synchronization Search Base
A synchronization agreement specifies a search base. A search base is an area of the
directory that is used for synchronization. The synchronization agreement specifies a
position in the directory tree where CUCM begins its search. The search level has access to
all levels lower in the tree, but not to higher levels in the tree.
DirSync
DB
WWW
Authentication
Authentication
Identity Management
System (IMS) Library
Web
Service
CUCM User Options,
Extension Mobility,
CUCM Administrators
IP Phone
User
Lookup
User
Lookup
Directories
Button
HTTPS HTTP
Corporate
Directory
(Microsoft AD,
Netscape/iPlanet)
User Data
Synchronization
LDAP(S)
CUCM Server
Embedded
Database
IMS
130 Chapter 6: Managing User Accounts
Users should be organized in a structure in the LDAPv3 directory. The existing structure
can be used to control the user groups that were imported. A single synchronization
agreement can specify the root of the domain, and all users of the domain are synchronized.
The search base does not normally point to the domain root.
In Figure 6-15, two synchronization agreements are represented. One synchronization
agreement specifies User Search Base 1 and imports users jsmith, jdoe, and jbloggs. These
users are in separate organizational unit (OU) containers under the Site 1 Users organizational
unit. User Search Base 2 represents a second synchronization agreement and imports
users jjones, bfoo, and tbrown. The CCMDirMgr account is not imported because it does
not reside within one of the two specified user search bases.
Figure 6-15 User Search Base
CUCM performs a bind to the LDAPv3 directory using the LDAPv3 Manager Distinguished
Name in the LDAPv3 directory configuration. The account used for the LDAPv3
Manager Distinguished Name must be available in the LDAPv3 directory for CUCM to
log in. It is recommended that you create a specific account with the permission to read
all user objects within the subtree that was specified by the user search base.
It is possible to control the import of accounts by limiting read permissions of the LDAPv3
Manager Distinguished Name account. For example, if the account is restricted to have read
access to ou=Eng but not to ou=Mktg, only the accounts located under the Eng OU will be
synchronized.
Synchronization agreements can specify multiple directory servers for redundancy purposes.
dc=vse, dc=lab
ou=Site 1 Users ou=Site 2 Users
jsmith jdoe jbloggs
ou=Eng ou=Mktg jjones bfoo tbrown
ou=Service Accts
CCM Dir Mgr
No Synchronization
Agreement for
Service Accounts
CCM Dir Mgr is
not imported
User Search
Base 1
User Search
Base 2
LDAPv3 Synchronization 131
Each synchronization agreement is configured with a synchronization start time and a
period configured in hours, days, weeks, or months. A synchronization agreement can be
configured to run only once.
The synchronization process is as follows:
1. At the beginning of the synchronization process, all existing CUCM end-user accounts
are deactivated.
2. If there were any differences in the LDAPv3 server, LDAPv3 user accounts that exist
in the CUCM user database are reactivated, and their settings are updated.
3. LDAPv3 user accounts that exist in LDAPv3 only are added to the CUCM database
and activated.
4. Deactivated accounts are purged from the CUCM database after 24 hours.
Synchronization Best Practices
The account that CUCM uses to read the LDAPv3 directory should be configured in the
following way:
■ Create a dedicated account used only for synchronization. Set LDAPv3 server
permissions for this account to read all user objects located below the user search bases
specified in the synchronization agreements.
■ The password of the account should be set to never expire.
Synchronization times should be configured during intervals when there are no office hours.
All overhead and management processes are scheduled during off-hours to minimize the
CPU load overhead incurred as a result of synchronization. Call-processing impact should
be limited during business hours.
Different start times should be set to reduce the load on the servers when multiple
synchronization agreements are configured.
Avoid a single point of failure by configuring at least two LDAPv3 servers, and use IP
addresses rather than hostnames to eliminate DNS reliance.
The connection between the CUCM publisher server and the directory server can be
secured by enabling Secure LDAPv3 (sLDAPv3) on CUCM and the LDAPv3 server.
sLDAPv3 enables LDAPv3 to be sent over a Secure Sockets Layer (SSL) encryption at
128-bit-level encryption.
Lightweight Directory Access Protocol CCNA Training in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
LDAPv3 directories typically store data that does not change often, such as employee
information and user privileges on the corporate network. The information is stored in a
database that is optimized for a high number of read and search requests and occasional
write and update requests.
126 Chapter 6: Managing User Accounts
LDAPv3 Integration
Integration between voice applications and a corporate LDAPv3 directory is a common task
for many enterprise IT organizations.
LDAPv3 directory services are leveraged to enable user lookups from IP phones. Users can
dial a contact directly after looking up the number in the directory.
Another common task is to provision users automatically from the corporate directory into
the user database of CUCM. This method prevents having to add, remove, or modify core user
information manually each time a change occurs in the corporate directory.
Authentication of end users and CUCM administrators using the corporate directory
credentials is typically desired. LDAPv3 allows a single sign-in functionality to any
applications integrated with the LDAPv3 server. Single sign-in greatly reduces the number
of passwords that each user needs to maintain across different corporate applications.
Cisco Unified IP Phones access the LDAPv3 directory when the Directory button is pressed.
The IP phone responds to the Directory button click by sending an HTTP directory lookup
request to the Apache web server on CUCM. The response from CUCM contains
Extensible Markup Language (XML) user information objects that the phone displays to
the person using the phone.
Cisco Unified IP Phones perform user lookups against the embedded CUCM database
by default. The directory lookup can be configured to allow the IP phones to access a
corporate LDAPv3 directory. The phones would then send their HTTP user lookup requests
to an external web server that operates as a proxy to the LDAPv3 server. The user lookup
requests are translated into LDAPv3 queries against the corporate directory. The LDAPv3
response is then encapsulated in the appropriate XML objects and sent back to the phones
via HTTP.
CUCM supports the following directories:
■ Microsoft Active Directory (2000 and 2003)
■ Netscape Directory Server 4.x
■ iPlanet Directory Server 5.1
■ Sun ONE Directory Server 5.2
LDAPv3 Synchronization 127
CUCM supports two types of LDAPv3 integration, which can be enabled independently of
each other:
■ LDAPv3 synchronization: Allows user provisioning where personal and
organizational data is managed in an LDAPv3 directory and replicated to the
Cisco Unified CM IDS database.
■ LDAPv3 authentication: Allows user authentication against an LDAPv3 directory.
Passwords are managed in the central LDAPv3 server when LDAPv3 authentication is
turned on.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
LDAPv3 directories typically store data that does not change often, such as employee
information and user privileges on the corporate network. The information is stored in a
database that is optimized for a high number of read and search requests and occasional
write and update requests.
126 Chapter 6: Managing User Accounts
LDAPv3 Integration
Integration between voice applications and a corporate LDAPv3 directory is a common task
for many enterprise IT organizations.
LDAPv3 directory services are leveraged to enable user lookups from IP phones. Users can
dial a contact directly after looking up the number in the directory.
Another common task is to provision users automatically from the corporate directory into
the user database of CUCM. This method prevents having to add, remove, or modify core user
information manually each time a change occurs in the corporate directory.
Authentication of end users and CUCM administrators using the corporate directory
credentials is typically desired. LDAPv3 allows a single sign-in functionality to any
applications integrated with the LDAPv3 server. Single sign-in greatly reduces the number
of passwords that each user needs to maintain across different corporate applications.
Cisco Unified IP Phones access the LDAPv3 directory when the Directory button is pressed.
The IP phone responds to the Directory button click by sending an HTTP directory lookup
request to the Apache web server on CUCM. The response from CUCM contains
Extensible Markup Language (XML) user information objects that the phone displays to
the person using the phone.
Cisco Unified IP Phones perform user lookups against the embedded CUCM database
by default. The directory lookup can be configured to allow the IP phones to access a
corporate LDAPv3 directory. The phones would then send their HTTP user lookup requests
to an external web server that operates as a proxy to the LDAPv3 server. The user lookup
requests are translated into LDAPv3 queries against the corporate directory. The LDAPv3
response is then encapsulated in the appropriate XML objects and sent back to the phones
via HTTP.
CUCM supports the following directories:
■ Microsoft Active Directory (2000 and 2003)
■ Netscape Directory Server 4.x
■ iPlanet Directory Server 5.1
■ Sun ONE Directory Server 5.2
LDAPv3 Synchronization 127
CUCM supports two types of LDAPv3 integration, which can be enabled independently of
each other:
■ LDAPv3 synchronization: Allows user provisioning where personal and
organizational data is managed in an LDAPv3 directory and replicated to the
Cisco Unified CM IDS database.
■ LDAPv3 authentication: Allows user authentication against an LDAPv3 directory.
Passwords are managed in the central LDAPv3 server when LDAPv3 authentication is
turned on.
Subscribe to:
Posts (Atom)