The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Unified CME 8.6 enhances the bulk registration feature for Cisco Unified SIP IP phones by optimizing the two main transactions involved in bulk registration process and minimizing the number of required messages to be sent to the phones. The bulk registration process involves the following two main transactions:
Register—Register transaction handles per line REGISTER messages coming to Cisco Unified CME and provisions phone DNs by creating dialpeers and various phone data structures.
Phone Status Update—Phone status update transaction sends back device information using REFER and NOTIFY messages.
In Cisco Unified CME 8.6, the bulk registration process consists of only one REGISTER message per phone instead of one REGISTER message per phone per line, thus reducing any negative impact on your router’s performance. For information on configuring bulk registration, see Configure Bulk Registration for SIP IP Phones.
The show voice register pool command displays the registration method a phone uses: per line, bulk-in progress, or bulk-completed. The per line option indicates that the phone is using the per line registration process. The bulk-in progress option indicates that the phone is using the bulk registration process but the registration process is not complete yet. The bulk-completed option indicates that the phone is registered using the bulk registration process and the registration process is complete. For information on verifying the phone registration process, see Verify Phone Registration Type and Status.
 Note |
The bulk registration feature in Cisco Unified CME 8.6 optimizes line registration on SIP phones and is a phone interop feature. The bulk registration feature is not related to the bulk command under voice register global configuration mode. |
In earlier versions of Cisco Unified CME, the registration process was very lengthy and several SIP messages were exchanged between the end points and Cisco Unified CME to properly provision the phone.
Table 1 lists the number of messages required to register an eight-button Cisco Unified SIP IP phone, where all of the eight buttons can be configurd as a shared line with message waiting indicator (MWI) notification enabled, to Cisco Unified CME.
|
Transactions |
Method |
Messages Per Transaction |
Number of Transactions |
Total number of messages (per line) |
Total number of messages (bulk) |
|---|---|---|---|---|---|
|
Register |
REGISTER |
2 |
8 |
24 |
3 |
|
Phone Status Update |
REFER remotecc NOTIFY (mwi, service-control) |
2 2 |
3 8 |
6 16 |
2 |
|
Subscription |
SUBSCRIBE (sharedline) |
4 |
8 |
32 |
32 |
|
Total |
78 |
37 |
You can see from the preceding table that more than 70 messages are required to register one 8-button IP phone. If there is a simultaneous registration of more phones, the amount of messages can be overwhelming and can have a negative impact on the performance of the router.
With the enhanced bulk registration process, the two main transactions (Register and Phone Status Update) are optimized to minimize the number of messages required to complete the phone registration process. Table 1 shows that the total number of messages required for bulk registration is only 37.
The following is an example of the REGISTER message:
REGISTER sip:28.18.88.1 SIP/2.0 Via: SIP/2.0/TCP 28.18.88.33:44332;branch=z9hG4bK53f227fc From: <sip:6010@28.18.88.1>;tag=001b2a893698027db8ea0454-26b9fb0c To: <sip:6010@28.18.88.1> Call-ID: 001b2a89-3698011e-280209a4-567e339c@28.18.88.33 Max-Forwards: 70 Date: Wed, 03 Mar 2010 01:18:34 GMT CSeq: 240 REGISTER User-Agent: Cisco-CP7970G/8.4.0 Contact: <sip:6010@28.18.88.33:44332;transport=tcp > ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-001b2a893698 >
";+u.sip!model.ccm.cisco.com="30006" Supported: replaces,join,norefersub,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,
X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-3.0.0,X-cisco-xsi-7.0.1 Reason: SIP;cause=200;text="cisco-alarm:23 Name=SEP001B2A893698 Load=SIP70.8-4-2-30S Last=reset-restart" Expires: 3600 Content-Type: multipart/mixed; boundary=uniqueBoundary Mime-Version: 1.0 Content-Length: 982 --uniqueBoundary Content-Type: application/x-cisco-remotecc-request+xml Content-Disposition: session;handling=optional > < x-cisco-remotecc-request > <bulkregisterreq > < contact all="true" > < register > < /register > < /contact > < /bulkregisterreq > < /x-cisco-remotecc-request > --uniqueBoundary Content-Type: application/x-cisco-remotecc-request+xml Content-Disposition: session;handling=optional > < x-cisco-remotecc-request > < optionsind > < combine max="6" > < remotecc > < status > < /status > < /remotecc > < service-control > < /service-control > < /combine > < dialog usage="hook status" > < unot > < /unot > < sub > < /sub > < /dialog > < dialog usage="shared line" > < unot > < /unot > < sub > < /sub > < /dialog > < presence usage="blf speed dial" > < unot > < /unot > < sub > < /sub > < /presence > < joinreq > < /joinreq > < /optionsind > < /x-cisco-remotecc-request > --uniqueBoundary-- The following is an example of a response to the preceding REGISTER message:
SIP/2.0 200 OK Date: Wed, 03 Mar 2010 01:18:41 GMT From: < sip:6010@28.18.88.1 > ;tag=001b2a893698027db8ea0454-26b9fb0c Content-Length: 603 To: < sip:6010@28.18.88.1 > ;tag=E2556C-6C1 Contact: < sip:6010@28.18.88.33:44332;transport=tcp > ;expires=3600;x-cisco-newreg Expires: 3600 Content-Type: multipart/mixed;boundary=uniqueBoundary Call-ID: 001b2a89-3698011e-280209a4-567e339c@28.18.88.33 Via: SIP/2.0/TCP 28.18.88.33:44332;branch=z9hG4bK53f227fc Server: Cisco-SIPGateway/IOS-12.x CSeq: 240 REGISTER Mime-Version: 1.0 > < x-cisco-remotecc-response > < response > < code > 200 < /code > < optionsind > < combine max="6" > < remotecc >
< status/ > < /remotecc > < service-control/ > < /combine > < dialog usage="shared line" > < sub/ > < /dialog >
< presence usage="blf speed dial" > < sub/ > < /presence > < /optionsind > < /response > < /x-cisco-remotecc-response > Cisco Unified IP phones use the option indication to negotiate supported options with Cisco Unified CME via remotecc request. Cisco Unified CME selects an option or options that it wishes to support and return it in the response. Cisco Unified CME ignores items (elements, attributes, and values) that it fails to understand. A new phone option, combine, is defined to optimize phone status update. This option combines remotecc status information (cfwdall, privacy, dnd, bulk mwi) and service-control. The following is an example of a combined status update:
<optionsind>
<combine max="5">
<remotecc><status/></remotecc>
<service-control/>
</combine>
</optionsind>
The following is another example of a combined status update:
<optionsind>
<combine max="4">
<remotecc><status/></remotecc>
<service-control/>
</combine>
</optionsind>
To minimize the data size, Cisco Unified CME and the phone agree ahead of time on a default value to apply updates. Therefore, during initial registration, Cisco Unified CME will not send the value if it matches the agreed upon default. Table 1 captures the existing status information and applicable default value.
|
Status |
Default |
Initialization |
|---|---|---|
|
CallForwardAll Update |
No default |
Always send regardless of the value |
|
Privacyrequest |
Disabled |
Only send if the value is not equal to the default |
|
DnDupdate |
Disabled |
Only send if value is not equal to the default |
|
Bulkupdate (MWI) |
No default |
Always send regardless of value |
During bulk registration, Cisco Unified CME uses a single REFER message to send combined phone status update message for phone status updates such as cfwdallupdate, privacyrequet, DnDupdate, and Bulkupdate (MWI) instead of sending phone status in individual NOTIFY or REFER message to the phone. The following is an example of the single REFER message sent by Cisco Unified CME to the phone:
REFER sip:6010@28.18.88.33:44332 SIP/2.0
Content-Id: <1483336>
From: <sip:28.18.88.1>;tag=E256D4-2316
Timestamp: 1267579121
Content-Length: 934
User-Agent: Cisco-SIPGateway/IOS-12.x
Require: norefersub
Refer-To: cid:1483336
To: <sip:6010@28.18.88.33>
Contact: <sip:28.18.88.1:5060>
Referred-By: <sip:28.18.88.1>
Content-Type: multipart/mixed;boundary=uniqueBoundary
Call-ID: 89CBE590-259911DF-80589501-4E753388@28.18.88.1
Via: SIP/2.0/UDP 28.18.88.1:5060;branch=z9hG4bKA22639
CSeq: 101 REFER
Max-Forwards: 70
Mime-Version: 1.0
--uniqueBoundary
Content-Type: application/x-cisco-remotecc-request+xml
<x-cisco-remotecc-request>
<cfwdallupdate><fwdaddress></fwdaddress><tovoicemail>off</tovoicemail></cfwdallupdate></x-cisco-remotecc-request>
--uniqueBoundary
Content-Type: application/x-cisco-remotecc-request+xml
<x-cisco-remotecc-request>
<privacyreq><status>true</status></privacyreq>
</x-cisco-remotecc-request>
--uniqueBoundary
Content-Type: application/x-cisco-remotecc-request+xml
<x-cisco-remotecc-request>
<bulkupdate>
<contact all="true"><mwi>no</mwi></contact>
<contact line=" 1"><mwi>yes</mwi></contact>
<contact line=" 3"><mwi>yes</mwi></contact>
</bulkupdate>
</x-cisco-remotecc-request>
--uniqueBoundary
Content-Type: text/plain
action=check-version
RegisterCallId={001b2a89-3698011e-280209a4-567e339c@28.18.88.33}
ConfigVersionStamp={0106514225374329}
DialplanVersionStamp={}
SoftkeyVersionStamp={0106514225374329}
--uniqueBoundary--
Note |
Cisco Unified IP phones use the TCP for registration refresh. TCP socket has a default keepalive time out session of 60 minutes. If registration refresh to Cisco Unified CME does not takes place within an hour (60 minutes), the TCP connection will be removed. This will make the phones restart instead of refresh. To stop the phones from restarting, adjust the registrar expire timer under voice service voip or set the timer connection aging under sip-ua to a value greater than what the phone uses for registration refreshes. For example, if the phone does a registration refresh every 60 minutes, then setting up a timer connection aging to 100 minutes will guarantee that the TCP keeps the connection open. Or you can set the registrar expire maximum value to less than 3600. |
Differentiated Services Code Point (DSCP) packet marking is used to specify the class of service for each packet. Cisco Unified IP Phones get their DSCP information from the configuration file that is downloaded to the device.
In earlier versions of Cisco Unified CME, the DSCP value is predefined. In Cisco Unified CME 7.1 and later versions, you can configure the DSCP value for different types of network traffic. Cisco Unified CME downloads the configured DSCP value to SCCP and SIP phones in their configuration files and all control messages and flow-through RTP streams are marked with the configured DSCP value. This allows you to set different DSCP values, for example, for video streams and audio streams.
For configuration information, see Set Up Cisco Unified CME for SCCP Phones or Set Up Cisco Unified CME for SIP Phones.
In Cisco Unified CME 4.3 and later versions, the max-ephones command is enhanced to set the maximum number of SCCP phones that can register to Cisco Unified CME, without limiting the number that can be configured. In previous versions of Cisco Unified CME, the max-ephones command defined the maximum number of phones that could be both configured and registered.
This enhancement expands the maximum number of phones that can be configured to 1000. The maximum number of phones that can register to Cisco Unified CME has not changed; it is dependent on the number of phones supported by the hardware platform and is limited by the max-ephones command.
This enhancement supports features, such as Extension Assigner, that require you to configure more phones than can register. For example, if you set the max-ephones command to 50 and configure 100 ephones, only 50 phones can register to Cisco Unified CME, one at a time in random order. The remaining 50 phones cannot register and an error message displays for each rejected phone. This enhancement also allows you to assign ephone tags that match the extension number of the phone, for extensions up to 1000.
If you reduce the value of the max-ephones command, currently registered phones are not forced to unregister until a reboot. If the number of registered phones, however, is already equal to or more than the max-ephones value, no additional phones can register to Cisco Unified CME. If you increase the value of the max-ephones command, the previously rejected ephones are able to register immediately until the new limit is reached.
Note |
For Cisco Integrated Services Router 4351, you can set the max-ephones value to 3925. For Cisco Integrated Services Router 4331, you can set the max-ephones value to 2921. For Cisco Integrated Services Router 4321, you can set the max-ephones value to 2901. For Cisco Integrated Services Router 4400 series, you can set the max-ephones value to 4451. |
Although SIP phones can synchronize to a Cisco Unified CME router, the router can lose its clock after a reboot causing phones to display the wrong time. SIP phones registered to a Cisco Unified CME router can synchronize to a Network Time Protocol (NTP) server. Synchronizing to an NTP server ensures that SIP phones maintain the correct time. For configuration information, see Set Network Time Protocol for SIP Phones.
In Cisco Unified CME 4.0 and later versions, you can use an external TFTP server to off load the TFTP server function on the Cisco Unified CME router. Using flash memory or slot 0 memory on the Cisco Unified CME router allows you to use different configuration files for each phone type or for each phone, permitting you to specify different user locales and network locales for different phones. Before Cisco Unified CME 4.0, you could specify only a single default user and network locale for a Cisco Unified CME system.
You can specify one of the following four locations to store configuration files:
Note |
When the storage location you selected is flash memory and the file system type on this device is Class B (LEFS), you must check the free space on the device periodically and use the squeeze command to free the space used up by deleted files. Unless you use the squeeze command, the space used by the moved or deleted configuration files cannot be used by other files. Rewriting flash memory space during the squeeze operation may take several minutes. We recommend that you use this command during scheduled maintenance periods or off-peak hours. |
You can then specify one of the following ways to create configuration files:
For configuration information, see Define Per-Phone Configuration Files and Alternate Location for SCCP Phones.
Legacy IP phones access the TFTP server to download firmware and configuration files but Cisco Unified CME 8.8 enhances download support for SIP phone firmware, scripts, midlets, and configuration files using the HTTP File-Fetch Server (HFS) infrastructure.
In Cisco Unified CME 8.8 and later versions, SIP phones use an HTTP server as the primary download service when it is configured and access a TFTP server as a secondary or fallback option when the HTTP server fails.
Note |
When the HFS download service is not configured, SIP phones automatically access the TFTP server. |
The following scenario shows a successful download sequence using an HTTP server:
An IP phone initiates TCP connection to port 6970. A connection is established and an internal request for a file is sent to the HTTP server. The phone receives the HTTP response status code of 200, signifying that the download is successful.
The following scenario shows a download sequence that begins with an IP phone using an HTTP server to download files and ends with a TFTP server as a fallback option when the initial download attempt fails:
An IP phone initiates TCP connection to port 6970 but is unable to establish a connection. The phone contacts the TFTP server and sends an internal request for a file. The file is successfully downloaded from the TFTP server.
The following scenario shows how a download sequence that starts with an HTTP server does not always fall back to the TFTP server when the initial download attempt fails:
An IP phone initiates TCP connection to port 6970. A connection is established and an internal request for a file is sent to the HTTP server. The phone receives the HTTP response status code of 404, signifying that the file requested could not be found. Because the file cannot be found, the request is not sent to the TFTP server.
Note |
The configuration files are shared by the HTTP and TFTP servers. However, the firmware files are different for each server. |
For more information on Phone Firmware Files, see Install and Upgrade Cisco Unified CME Software.
For more information on Per-Phone Configuration Files, see Per-Phone Configuration Files.
For more information on Configuration Files for Phones in Cisco Unified CME, see Generate Configuration Files for Phones.
To enable the HFS download service, the underlying HTTP server must be enabled first because the HFS infrastructure is built on top of an existing IOS HTTP server.
Router(config)# ip http server This HFS infrastructure enables multiple HTTP services to co-exist. The HFS download service runs on custom port 6970 but can also share default port 80 with other services. Other HTTP services run on other non-standard ports like 1234.
Router(config)# ip http server
Router(config)# ip http port1234 The HFS download service starts when the following is configured in telephony-service configuration mode.
For the default port:
Router(config-telephony)# hfs enable For the custom port:
Router(config-telephony)# hfs enable port 6970 Note |
If the entered custom HFS port clashes with the underlying IP HTTP port, an error message is displayed and the command is disallowed. |
In the following example, port 6970 is configured as the IP HTTP port. When the HFS port is configured with the same value, an error message is displayed to show that the port is already in use.
Router (config)# ip http port 6970
.
.
Router (config)# telephony-service
Router (config-telephony)# hfs enable port 6970 Error Message Invalid port number or port in use by other application
Explanation The HFS port number is already in use by the underlying IP HTTP server.
Recommended Action Use an HFS port that is different from the underlying IP HTTP port.
Note |
Because IP phones are hardcoded to use port 6970 to connect to Cisco Unified CME, you must search for other applications running on port 6970 and assign them with ports different from 6970 to prevent a failure in connecting to Cisco Unified CME. |
For configuration information, see Enable HFS Download Service for SIP Phones.
File binding and fetching using the HTTP server can be classified into two:
Explicit binding – The create profile command triggers the system to generate the configuration and firmware files and store them in RAM or a flash memory. The system asks the new internal application programming interfaces (APIs) implemented by the HFS download service to bind the filename and alias that an IP phone wants to access to their corresponding URL.
Loose binding – The HFS download service enables the Cisco Unified CME system to configure a home path from where any requested firmware file that has no explicit binding can be searched and fetched. The files can be stored on any device (such as flash memory or NVRAM) under a root directory or a suitable subdirectory.
No matter how the system is configured, if there is no explicit binding, the files will go to the home path.
An advantage of the HFS service over the TFTP service is that only the absolute path where the firmware files are located needs to be configured in telephony-service configuration mode.
For example:
Router(config-telephony)# hfs home-path flash:/cme/loads/In contrast, the TFTP service requires that each file be explicitly bound to its URL using the following tftp-server command:
tftp-server flash: SCCP70.8-3-3-14S.loadsThe method is inefficient because this step must be repeated for each file that needs to be fetched using the TFTP server.
For information on verifying HFS file bindings, see Example for Verifying the HFS File Bindings of Cisco Unified SIP IP Phone Configuration and Firmware Files.
For information on how to configure the home path, see Configure HFS Home Path for SIP Phone Firmware Files.
Installing and configuring locale files in Cisco Unified CME when using an HTTP server is the same as when using a TFTP server.
For configuration information, see Use the Locale Installer in Cisco Unified CME 7.0(1) and Later Versions.
Like any access interface, the HFS download service can open router files that should only be accessed by authorized persons. Security issues are made more severe by the fact that the HFS download service is HTTP based, enabling anyone with a simple web browser to access sensitive files, such as configuration or image files, by entering a random string of words.
However, the HFS security problem is restricted to the loose binding operation, where the administrator provides an HFS home path in which the phone firmware and other related files are stored.
In the case where a unique directory path (where only the phone firmware files are stored) is used as the HFS home path
(config-telephony)# hfs home-path flash:/cme/loads/only those files that are in flash:/cme/loads/ can be accessed.
But when it is the root directory path that is used as the HFS home path
(config-telephony)# hfs home-path flash:/there is a risk of making configuration files and system images, which are stored in the root directory shared with the phone firmware files, accessible to unauthorized persons.
The following are two recommendations on how to make firmware files inaccessible to unauthorized persons:
Create a unique directory, which is not shared by any other application or used for any other purpose, fpr IP phone firmware files. Using a root directory as the HFS home path is not recommended.
Use the ip http access-class command to specify the access list that should be used to restrict access to the HTTP server. Before the HTTP server accepts a connection, it checks the access list. If the check fails, the HTTP server does not accept the request for a connection.
A second Cisco Unified CME router can be configured to provide call-control services if the primary Cisco Unified CME router fails. The secondary Cisco Unified CME router provides uninterrupted services until the primary router becomes operational again.
When a phone registers to the primary router, it receives a configuration file from the primary router. Along with other information, the configuration file contains the IP addresses of the primary and secondary Cisco Unified CME routers. The phone uses these addresses to initiate a keepalive (KA) message to each router. The phone sends a KA message after every KA interval (30 seconds by default) to the router with which it is registered and after every two KA intervals (60 seconds by default) to the other router. The KA interval can be adjusted.
If the primary router fails, a phone will not receive an acknowledgment (ACK) to its KA message to the primary router. If the phone does not get an ACK from the primary router for three consecutive KAs, it registers with the secondary Cisco Unified CME router.
During the time that the phone is registered to the secondary router, it keeps sending a KA probe to the primary router to see if it has come back up, now every 60 seconds by default or two times the normal KA interval. After the primary Cisco Unified CME router returns to normal operation, the phone starts receiving ACKs for its probes. After the phone receives ACKs from the primary router for three consecutive probes, it switches back to the primary router and re-registers with it. The re-registration of phones with the primary router is also called rehoming.
The physical setup for redundant Cisco Unified CME routers is as follows. The FXO line from the PSTN is split using a splitter. From the splitter, one line goes to the primary Cisco Unified CME router and the other line goes to the secondary Cisco Unified CME router. When a call comes in on the FXO line, it is presented to both the primary and secondary Cisco Unified CME routers. The primary router is configured by default to answer the call immediately. The secondary Cisco Unified CME router is configured to answer the call after three rings. If the primary router is operational, it answers the call immediately and changes the call state so that the secondary router does not try to answer it. If the primary router is unavailable and does not answer the call, the secondary router sees the new call coming in and answers after three rings.
The secondary Cisco Unified CME router should be connected in some way on the LAN, either through the same switch or through another switch that may or may not be connected to the primary Cisco Unified CME router directly. As long as both routers and the phones are connected on the LAN with the appropriate configurations in place, the phones can register to whichever router is active.
Configure primary and secondary Cisco Unified CME routers identically, with the exception that the FXO voice port from the PSTN on the secondary router should be configured to answer after more rings than the primary router, as previously explained. The same command is used on both routers to specify the IP addresses of the primary and secondary routers.
For configuration information, see Configure Redundant Router for SCCP Phones.
Restriction |
|
A secondary Cisco Unified CME router can be configured to provide call-control services if the primary Cisco Unified CME router fails. The secondary Cisco Unified CME router provides uninterrupted services until the primary router becomes operational again.
When a SIP phone registers to the primary router, it receives a configuration file from the primary router. Along with other information, the configuration file contains the IP addresses of the primary and secondary Cisco Unified CME routers. The phone uses these addresses to initiate a keepalive (KA) message to the secondary CME router. The phone sends a REGISTER message to the primary router for registration and a keepalive REGISTER message with Expires=0, to the secondary router during the keepalive interval (every 120 seconds by default). The keepalive interval can be configured (Range is 120 to 65535).
If primary router fails, a SIP phone (on registration refresh) will not receive a successful response for its REGISTER message. On unsuccessful response from primary router, phone registers with the secondary router. When the phone is registered to the secondary router, phone sends keepalive REGISTER (Expires=0) messages to the primary router.
After the primary Cisco Unified CME router returns to normal operation, the phone sends a "token-registration" to the primary router seeking permission to move registration of the phone from the standby secondary router to the primary router. To obtain a token, the SIP phones sends a Out-of-Dialog REFER message to the primary router for registration. The primary router accepts the token by responding with a 202 Accepted response. When the SIP phones receive the token (202 Accepted response) from the primary router, the phones will immediately de-register from the secondary router by sending a REGISTER message with Expires=0 for each line and registers back to the primary router. The re-registration of phones with the primary router is called rehoming.
No signaling or media preservation is done for any active calls on Unified CME. Hence during failover on primary CME, calls would remain in active state. But media would not be present for those calls. The SIP phones will not register to the secondary router until the active call is disconnected.
The secondary Cisco Unified CME router is connected directly to the same SIP trunk as the primary Cisco Unified CME router. As long as both routers and the phones are connected on the LAN with the appropriate configurations in place, the phones can register to whichever router is active. You should configure the primary and secondary Cisco Unified CME routers identically. The same command is used on both routers to specify the IP addresses of the primary and secondary routers.
For configuration information, see Configure Redundant Router for SIP Phones.
Restriction |
|
The following system-level timeout parameters have default values that are generally adequate:
For configuration information, see Modify Defaults for Timeouts for SCCP Phones.
Internet Protocol version 6 (IPv6), which is the latest version of the Internet Protocol (IP) that uses packets to exchange data, voice, and video traffic over digital networks, increases the number of network address bits from 32 bits in IPv4 to 128 bits. IPv6 support in Cisco Unified CME allows the network to behave transparently in a dual-stack (IPv4 and IPv6) environment and provides additional IP address space to SCCP phones and devices that are connected to the network. For information on configuring DHCP for IPv6, see Network Parameters.
Before Cisco Unified CME 8.0, SCCP supported IPv4 addresses (4 bytes) only. With Cisco Unified CME 8.0, the SCCP version is upgraded to store IPv6 address (16 bytes) also.
The following SCCP phones and devices are supported on IPv6: 7911, 7931, 7941G, 7941GE, 7961G, 7961GE, 7970G, 7971G, 7971G-GE, 7942, 7962, 7945, 7965, 7975, SCCP analogue gateway, Xcoder, and Hardware Conference devices. For more information on configuring SCCP IP phones for IPv6 source address, see Configure IPv6 Source Address for SCCP IP Phones.
Note |
You must disable Alternative Network Address Transport (ANAT) globally for SIP lines if you have a Cisco Unified CME with a dual-stack SIP trunk and enable ANAT at dial-peer level for the SIP trunk. |
Cisco Unified CME 8.0 can interact with and support any SCCP devices that support IPv4 only or both IPv4 and IPv6 (dual-stack). In dual-stack mode, two IP addresses are assigned to an interface, one is an IPv4 address and the other is an IPv6 address. Both IPv4 and IPv6 stacks are enabled on the voice gateways so that applications can interact with both versions of IP addresses. To support devices that use IPv4 only, IPv6 only, or both IPv4 and IPv6 (dual-stack) addresses, you must ensure that the Cisco Unified CME has both IPv4 address and IPv6 address enabled. For more information, see Configure IP Phones in IPv4, IPv6, or Dual Stack Mode.
Media transport modes, such as flow around and flow through, are used to transport media packets across endpoints. Media flow around enables media packets to pass directly between the endpoints, without the intervention of the IP-IP Gateway (IPIPGW). Media flow through enables media packets to pass through the endpoints, without the intervention of the IPIPGW.
Table 1 lists media flow-through and flow-around scenarios between endpoints that support IPv4, IPv6, and dual- stack. When both endpoints are IPv4 only or IPv6 only, the call flows around. When one endpoint is IPv4 and the other is IPv6, calls flow through. When one endpoint is dual-stack and the other IPv4 or IPv6 the calls flow around. When both endpoints are dual-stack calls flow around or follows the preference (preferred IP address version) selected by protocol mode in dual-stack.
|
IP Versions |
IPv4 Only |
IPv6 Only |
Dual-Stack |
|---|---|---|---|
|
IPv4 Only |
Flow Around 1 |
Flow Through |
Flow Around |
|
IPv6 Only |
Flow Through |
Flow Around |
Flow Around/IPv6 |
|
Dual-Stack |
Flow Around/IPv4 |
Flow Around/IPv6 |
Flow Around/Preference |
Cisco Unified CME 8.5 and later versions support the media flow around functionality for SIP to SIP trunk calls on Cisco Unified CME, allowing less consumption of resources on Cisco Unified CME.
The media flow around feature eliminates the need to terminate RTP and re-originate on Cisco Unified CME. This reduces media switching latency and increases the call handling capacity for a Cisco Unified CME SIP trunk.
Media flow around is supported in the following scenarios:
Single Number Reach (SNR) Push—If an SNR call on a SIP trunk is pushed over to a mobile user over another SIP trunk, the resulting connection is a SIP-SIP trunk call connection. If both SIP trunks are configured for media flow around, the media is allowed to flow around Cisco Unified CME for the resulting call.
Call Forward—If a SIP trunk call is forwarded over another SIP trunk and both the SIP trunks are configured for media flow around, media flows around Cisco Unified CME for the resulting SIP-SIP trunk call. Media flow around is supported for all types of call forwarding, such as call forward night-service, call forward all, call forward busy, and call forward no-answer.
Call Transfer—If a SIP trunk call is transferred over another SIP trunk and both SIP trunks are configured for media flow around, media flows around Cisco Unified CME for the resulting SIP-SIP trunk call. Media flow around is supported on both SIP-line-initiated call transfer and SCCP-line-initiated call transfers. It is supported for all types of call transfers, such as blind transfer, consult transfer, and full consult transfer.
Media is forced to flow through on different types of call flows including the SIP to SIP trunk call with asymmetric flow mode configurations or symmetric flow through configuration. In asymmetric flow mode configurations, one SIP leg is configured in the media flow around mode and another SIP leg is configured in the media flow through mode. In such cases, media is forced to flow through Cisco Unified CME.
Media is forced to flow through Cisco Unified CME for the following types of call flows:
Any calls involving a SIP endpoint, a SCCP endpoint, PSTN trunks (BRI/PRI/FXO), or FXO circuits.
SIP to SIP trunk call with either asymmetric flow mode configurations or symmetric flow through configurations.
SIP to SIP trunk call that requires transcoding services on Cisco Unified CME.
SIP to SIP trunk calls that require DTMF interworking with RFC2833 on one side, and SIP-Notify on the other side.
SNR pullback to SCCP— When an SNR call is pulled back from a mobile phone to the local SCCP SNR extension, the call is connected to the SCCP SNR extension. Media is required to flow through Cisco Unified CME because one of the calls is from a SCCP SNR extension, which is local to Cisco Unified CME.
In Cisco Unified CME 8.5, the media flow around feature is turned on or turned off using the media command in voice service voip, dial-peer voip, and voice class media configuration modes. The configuration specified under voice class media configuration mode takes precedence over the configuration in dial-peer configuration mode. If the media configuration is not specified under voice class media or dial-peer configuration mode, then the global configuration specified under voice service voip takes precedence. For more information, see Enable Media Flow Mode on SIP Trunks.
Cisco Unified CME 8.5 and later versions support overlap dialing on SCCP and SIP IP phones such as 7942, 7945, 7962, 7965, 7970, 7971, and 7975.
In earlier versions of Cisco Unified CME, overlap dialing was not supported over PRI/BRI trunks for calls originating from SCCP or SIP IP phones. Dialing was always converted into enbloc dialing based on the dial-peer configuration and the dial-peer mapping application. Once dialpeer matching took place, no further dialing was possible and no overlap digit were sent over ISDN trunk, even though overlap dialing was supported over ISDN trunks.
SCCP IP phones currently support overlap dialing, but digits are converted to enbloc digits when it reaches Cisco Unified CME. Overlap dialing is supported on SIP IP phones using the KeyPad Markup Language (KPML) method.
With overlap dialing support, the dialed digits from the SIP or SCCP IP phones are passed across to the PRI/BRI trunks as overlap digits and not as enbloc digits, enabling overlap dialing on the PRI/BRI trunks as well.
For information on how to configure SCCP and SIP IP phones for overlap dialing, see Configure Overlap Dialing on SCCP IP Phones and Configure Overlap Dialing on SIP Phones.
Before Cisco Unified CME 9.0, a Cisco Unified SIP IP phone receives NOTIFY messages that convey shared line and presence events from the Cisco Unified CME only by subscribing to such events. To subscribe, the IP phone sends a SUBSCRIBE message to the Cisco Unified CME with the type of event for which it wants to be notified. The Cisco Unified CME sends a NOTIFY message to alert the subscribed IP phone or subscriber of event updates.
In Unsolicited Notify, the Cisco Unified CME acquires the required information from the router configuration to create the implicit subscription and adds subscribers without a subscription request from Cisco Unified SIP IP phones. The Cisco Unified CME sends out NOTIFY messages to the IP phones for shared line or presence updates.
In Cisco Unified CME 9.0 and later versions, the Unsolicited Notify mechanism reduces network traffic particularly during Cisco Unified SIP IP phone registration using the bulk registration method. Through this registration method, the preferred notification method of the IP phone is embedded in the registration message.
Note |
Configuring TCP as the transport layer protocol under voice register pool configuration mode enables bulk registration with negotiation for the Unsolicited Notify mechanism. |
The Unsolicited Notify mechanism supports backward compatibility with all existing Cisco Unified SIP IP phone features. This mechanism is also the defacto notify mechanism in newer IP phone and Cisco Unified CME features, such as SNR Mobility.
From the end-user perspective, the following are the only two discernible differences between the SUBSCRIBE/NOTIFY and the Unsolicited Notify mechanisms:
Restriction |
|
Unified CME and Unified SRST routers have multiple interfaces that are used for signaling and data packet transfers. The two types of interfaces available on a Cisco router include the physical interface and the virtual interface. The types of physical interfaces available on a router depends on its interface processors or port adapters. Virtual interfaces are software-based interfaces that you create in the memory of the networking device using Cisco IOS commands. When you need to configure a virtual interface for connectivity, you can use the Loopback Interface for Unified CME and Unified SRST.
The following interfaces are supported on Unified CME and Unified SRST:
Gigabit Ethernet Interface (IEEE 802.3z) (interface gigabitethernet )
Loopback Interface (interface loopback )
Fast Ethernet Interface (interface fastethernet )
The remaining Cisco IOS interfaces are not validated on Unified CME and Unified SRST. Hence, Unified CME and Unified SRST do not claim support for these interfaces. For more information on the Cisco IOS Interface commands, see Cisco IOS Interface and Hardware Component Command Reference.
For physical interfaces such as interface gigabitethernet and interface fastethernet , subinterfaces are supported. In a subinterface, virtual interfaces are created by dividing a physical interface into multiple logical interfaces. For Cisco routers, a subinterface uses the parent physical interface for sending and receiving data. Virtual interfaces (For example, interface loopback ) do not support subinterfaces.
A subinterface for interface gigabitethernet is configured as follows:
Router(config)#interface gigabitEthernet 0/0.1
Router(config-subif)#exit
Router(config)#exitRestriction |
|
Cisco Unified CME 8.0 or later version.
IPv6 CEF must be enabled for dual-stack configuration.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
telephony-service Example: |
Enters telephony-service configuration mode. |
|
Step 4 |
protocol mode {ipv4 | ipv6 | dual-stack [preference {ipv4 | ipv6 }]} Example: |
Allows SCCP phones to interact with phones on IPv6 voice gateways. You can configure phones for IPv4 addresses, IPv6 address es, or for a dual-stack mode
|
|
Step 5 |
end Example: |
Returns to privileged EXEC mode. |
telephony-service
protocol mode dual-stack preference ipv6
....
ip source-address 10.10.2.1 port 2000
ip source-address 2000:A0A:201:0:F:35FF:FF2C:697D
Restriction |
|
Cisco Unified CME 8.0 or a later version.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
telephony-service Example: |
Enters the telephony-service configuration mode. |
|
Step 4 |
ip source-address {ipv4 address | ipv6 address } port port [secondary {ipv4 address | ipv6 address } [rehome seconds ]] [strict-match ] Example: |
Allows to configure an IPv4 or IPv6 address as an IP source-address for phones to communicate with a Cisco Unified CME router.
The use of this parameter is a phone behavior and is subject to change, based on the phone type and phone firmware version.
|
|
Step 5 |
end Example: |
Returns to privileged EXEC mode. |
|
Step 1 |
The following example shows a list of success messages that are printed during Cisco IOS boot up. These messages confirm whether IPv6 has been enabled on interfaces (for example, EDSP0.1 to EDSP0.5) specific to exchanging RTP packets with SCCP endpoints. Example: |
|
Step 2 |
Use the show ephone socket command to verify if IPv4 only, IPv6 only, or dual-stack (IPv4/IPv6) is configured in Cisco Unified CME. In the following example, SCCP TCP listening socket (skinny_tcp_listen_socket fd) values 0 and 1 verify dual-stack configuration. When IPv6 only is configured, the show ephone socket command displays SCCP TCP listening socket values as (-1) and (0). The listening socket is closed if the value is (-1). When IPv4 only is configured, the show ephone socket command displays SCCP TCP listening socket values as (0) and (-1). Example: |
|
Step 3 |
Use the show ephone summary command to verify the IPv6 or IPv4 addresses configured for ephones. The following example displays IPv6 and IPv4 addresses for different ephones: Example: |
To configure bulk registration for registering a block of phone numbers with an external registrar so that calls can be routed to Cisco Unified CME from a SIP network, perform the following steps.
Numbers that match the number pattern defined by using the bulk command can register with the external registrar. The block of numbers that is registered can include any phone that is attached to Cisco Unified CME or any analog phone that is directly attached to an FXS port on a Cisco Unified CME router.
Note |
Use the no reg command to specify that an individual directory number should not register with the external registrar. For configuration information, see Disable SIP Proxy Registration for a Directory Number. |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
|
|
Step 2 |
configure terminal Example: |
|
|
Step 3 |
voice register global Example: |
|
|
Step 4 |
mode cme Example: |
|
|
Step 5 |
bulk number Example: |
|
|
Step 6 |
exit Example: |
|
|
Step 7 |
sip-ua Example: |
|
|
Step 8 |
registrar {dns : address | ipv4 : destination-address } expires seconds [tcp ] [secondary ] no registrar [secondary ] Example: |
|
|
Step 9 |
end Example: |
|
The following example shows that all phone numbers that match the pattern “408555...” can register with a SIP proxy server (IP address 1.5.49.240):
voice register global
mode cme
bulk 408555….
sip-ua
registrar ipv4:1.5.49.240| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
|
|
Step 2 |
configure terminal Example: |
|
|
Step 3 |
voice register pool tag Example: |
|
|
Step 4 |
session-transport {tcp | udp } Example: |
|
|
Step 5 |
number tag dn tag Example: |
|
|
Step 6 |
end Example: |
|
You can verify phone registration type and status using the show voice register pool command. The following example shows that the Cisco Unified IP phone 7970 used the bulk registration method and completed the registration process:
Router#sh voice register pool 20 Pool Tag 20Config: Mac address is 001B.2A89.3698 Type is 7970 Number list 1 : DN 20 Number list 2 : DN 2 Number list 3 : DN 24 Number list 4 : DN 4 Number list 5 : DN 6 Number list 6 : DN 7 Number list 7 : DN 17 Number list 8 : DN 23 Proxy Ip address is 0.0.0.0 Current Phone load version is Cisco-CP7970G/9.0.1 DTMF Relay is enabled, rtp-nte, sip-notify Call Waiting is enabled DnD is disabled Video is disabled Camera is disabled Busy trigger per button value is 0 speed-dial blf 1 6779 label 6779_device speed-dial blf 2 3555 label 3555_remote speed-dial blf 3 6130 label 6130 speed-dial blf 4 3222 label 3222_remote_dev fastdial 1 1234 keep-conference is enabled username johndoe password cisco template is 1 kpml signal is enabled Lpcor Type is none Transport type is tcp service-control mechanism is supported Registration method: bulk - completed registration Call ID is 001b2a89-3698017e-68646967-126b902e@28.18.88.33 Privacy is configured: init status: ON, current status: ON Privacy button is enabled active primary line is: 6010To identify filenames and the location of phone firmware for phone types to be connected, specify the port for phone registration, and specify the number of phones and directory numbers to be supported, perform the following steps.
Restriction |
DSCP requires Cisco Unified CME 7.1 or a later version. If DSCP is configured for the gateway interface using the service-policy command or for the dial peer using the ip qos dscp command, the value set with those commands takes precedence over the DSCP value configured in this procedure. |
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
|
||
|
Step 2 |
configure terminal Example: |
|
||
|
Step 3 |
tftp-server device : filename Example: |
|
||
|
Step 4 |
telephony-service Example: |
|
||
|
Step 5 |
load phone-type firmware-file Example: |
|
||
|
Step 6 |
max-ephones max-phones Example: |
|
||
|
Step 7 |
max-dn max-directory -numbers [preference preference-order ] [no-reg primary | both ] Example: |
|
||
|
Step 8 |
ip source-address ip-address [port port ] [any-match | strict-match ] Example: |
|
||
|
Step 9 |
ip qos dscp {{number | af | cs | default | ef } {media | service | signaling | video }} Example: |
|
||
|
Step 10 |
end Example: |
|
The following example shows different DSCP settings for media, signaling, video, and services enabled with the ip qos dscp command:
telephony-service
load 7960-7940 P00308000500
max-ephones 100
max-dn 240
ip source-address 10.10.10.1 port 2000
ip qos dscp af11 media
ip qos dscp cs2 signal
ip qos dscp af43 video
ip qos dscp 25 service
cnf-file location flash:
.
.
To specify the format of the date and time that appears on all SCCP phones in Cisco Unified CME, perform the following steps.
Note |
For certain phones, such as the Cisco Unified IP Phones 7906, 7911, 7931, 7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971, and 7975, you must configure the time-zone command to ensure that the correct time stamp appears on the phone display. This command is not required for Cisco Unified IP Phone 7902G, 7905G, 7912G, 7920, 7921, 7935, 7936, 7940, 7960, or 7985G. |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
telephony-service Example: |
Enters telephony-service configuration mode. |
|
Step 4 |
date-format {dd-mm-yy | mm-dd-yy |yy-dd-mm | yy-mm-dd } Example: |
(Optional) Sets the date format for phone display.
|
|
Step 5 |
time-format {12 | 24} Example: |
(Optional) Selects a 12-hour or 24-hour clock for the time display format on phone display.
|
|
Step 6 |
time-zone number Example: |
Sets time zone for SCCP phones.
|
|
Step 7 |
end Example: |
Returns to privileged EXEC mode. |
Cisco Unified CME 4.0 or a later version.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
|
|
Step 2 |
configure terminal Example: |
|
|
Step 3 |
telephony-service Example: |
|
|
Step 4 |
no auto-reg-ephone Example: |
|
|
Step 5 |
end Example: |
|
Restriction |
|
To define a location other than system:/its for storing configuration files for per-phone and per-phone type configuration files, perform the following steps.
Cisco Unified CME 4.0 or a later version.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
telephony-service Example: |
Enters telephony-service configuration mode. |
|
Step 4 |
cnf-file location {flash: | slot0: | tftp tftp-url} Example: |
Specifies a location other than system:/its for storing phone configuration files.
|
|
Step 5 |
cnf-file {perphonetype | perphone } Example: |
Specifies whether to use a separate file for each type of phone or for each individual phone.
|
|
Step 6 |
end Example: |
Returns to privileged EXEC mode. |
The following example selects flash memory as the configuration file storage location and per-phone as the type of configuration files that the system generates:
telephony-service cnf-file location flash: cnf-file perphoneIf you changed the configuration file storage location, use the option 150 ip command to update the address. See Change the TFTP Address on a DHCP Server.
To configure values for system-level intervals for which default values are typically adequate, perform the following steps.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
telephony-service Example: |
Enters telephony-service configuration mode. |
|
Step 4 |
timeouts busy seconds Example: |
(Optional) Sets the length of time after which calls that are transferred to busy destinations are disconnected.
|
|
Step 5 |
timeouts interdigit seconds Example: |
(Optional) Configures the interdigit timeout value for all Cisco Unified IP phones attached to the router.
|
|
Step 6 |
timeouts ringing seconds Example: |
(Optional) Sets the duration, in seconds, for which the Cisco Unified CME system allows ringing to continue if a call is not answered. Range is 5 to 60000. Default is 180. |
|
Step 7 |
keepalive seconds Example: |
(Optional) Sets the time interval, in seconds, between keepalive messages that are sent to the router by Cisco Unified IP phones.
|
|
Step 8 |
end Example: |
Returns to privileged EXEC mode. |
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
||
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 3 |
telephony-service Example: |
Enters telephony-service configuration mode. |
||
|
Step 4 |
ip source-address ip-address [port port] [secondary ip-address [rehome seconds]] [any-match | strict-match] Example: |
Identifies the IP address and port number that the primary Unified CME router uses for IP phone registration.
|
||
|
Step 5 |
exit Example: |
Exits telephony-service configuration mode. |
||
|
Step 6 |
voice-port slot-number / port Example: |
Enters voice-port configuration mode for the FXO voice port for DID calls from the PSTN. |
||
|
Step 7 |
signal ground-start Example: |
Specifies ground-start signaling for a voice port. |
||
|
Step 8 |
incoming alerting ring-only Example: |
Instructs the FXO ground-start voice port to detect incoming calls by detecting incoming ring signals. |
||
|
Step 9 |
ring number number Example: |
(Required only for the secondary router) Sets the maximum number of rings to be detected before answering an incoming call over an FXO voice port.
|
||
|
Step 10 |
end Example: |
Returns to privileged EXEC mode. |
Cisco Unified CME 11.6 or a later version.
Auto-register configuration is recommended only on the primary router.
XML interface for secondary backup router is configured. See Configure the XML Interface for the Secondary Backup Router.
Note |
It is recommended to configure the XML interface for a seamless failover from primary to secondary Cisco Unified CME. Else, there is delay in the phones getting registered to secondary Cisco Unified CME due to mismatch in the configuration version timestamp. |
Ensure that you configure version stamp synchronization on the primary router. See Configure Version Stamp Synchronization on the Primary Router.
Note |
It is recommended to configure version stamp synchronization for a seamless failover from primary to secondary Cisco Unified CME. Else, there is delay in the phones getting registered to secondary Cisco Unified CME. |
Restriction |
|
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
voice register global Example: |
Enters voice register global configuration mode. |
|
Step 4 |
source-address ip-address [port port] [secondary ip-address] Example: |
Identifies the IP address and port number that the Cisco Unified CME router uses for IP phone registration.
|
|
Step 5 |
keepalive seconds Example: |
Sets the length of the time interval between successive keepalive messages from the SIP phones to Cisco Unified CME router. Default is 120 seconds. |
|
Step 6 |
end Example: |
Returns to privileged EXEC mode. |
To configure the primary router to enable automatic synchronization of 'version stamp' with secondary backup router, perform the following steps.
 Tip |
All phone-related configurations are tagged with a 'version stamp' that indicates when the last configuration change was made. |
XML interface for secondary backup router is configured. See Configure the XML Interface for the Secondary Backup Router.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
telephony-service Example: |
|
|
Step 4 |
standby username username password password Example: |
Defines an authorized user.
|
|
Step 5 |
end Example: |
Returns to privileged EXEC mode. |
To configure the secondary backup router to activate the XML interface required to receive "version stamp" configuration change information from the primary router, perform the following steps.
Restriction |
|
The XML interface, provided through the Cisco IOS XML Infrastructure (IXI), must be configured. See Configuring the XML API.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
telephony-service Example: |
|
|
Step 4 |
xml user user-name password password privilege-level Example: |
Defines an authorized user.
|
|
Step 5 |
end Example: |
Returns to privileged EXEC mode. |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
|
|
Step 2 |
configure terminal Example: |
|
|
Step 3 |
telephony-service Example: |
|
|
Step 4 |
overlap-signal Example: |
|
|
Step 5 |
exit Example: |
|
|
Step 6 |
ephone phone-tag Example: |
|
|
Step 7 |
overlap-signal Example: |
|
|
Step 8 |
exit Example: |
|
|
Step 9 |
ephone-template template-tag Example: |
|
|
Step 10 |
overlap-signal Example: |
|
|
Step 11 |
end Example: |
|
To identify filenames and location of phone firmware for phone types to be connected, to specify the port for phone registration, and to specify the number of phones and directory numbers to be supported, perform the following steps.
Note |
If your Cisco Unified CME system supports SCCP and SIP phones, do not connect your SIP phones to your network until after you have verified the configuration profile for the SIP phone. |
Note |
From Cisco IOS XE Amsterdam 17.2.1r onwards, cme-app mode was added for ISR4321 routers. This mode allows configuration of up to 200 phones for routers that are dedicated to CME use only. The cme or cme-app modes configure SIP phones and features for standalone call control use. |
Restriction |
|
Cisco CME 3.4 or a later version.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
|
|
Step 2 |
configure terminal Example: |
|
|
Step 3 |
voice register global Example: |
|
|
Step 4 |
mode [cme | cme-app] Example: |
|
|
Step 5 |
source-address ip-address [port port ] Example: |
|
|
Step 6 |
load phone-type firmware-file Example: |
|
|
Step 7 |
tftp-path {flash : | slot0: | tftp:// url } Example: |
|
|
Step 8 |
max-pool max-phones Example: |
|
|
Step 9 |
max-dn max-directory-numbers Example: |
|
|
Step 10 |
authenticate [all ][realm string ] Example: |
|
|
Step 11 |
ip qos dscp {{number | af | cs | default | ef } {media | service | signaling | video }} Example: |
|
|
Step 12 |
end Example: |
|
To identify filenames and location of phone firmware for phone types to be connected, to specify the port for phone registration, and to specify the number of phones and directory numbers to be supported, perform the following steps.
Note |
If your Cisco Unified CME system supports SCCP and SIP phones, do not connect your SIP phones to your network until after you have verified the configuration profile for the SIP phone. |
Note |
From Cisco IOS XE Amsterdam 17.2.1r onwards, cme-app mode was added for ISR4321 routers. This mode allows configuration of up to 200 phones for routers that are dedicated to CME use only. The cme or cme-app modes configure SIP phones and features for standalone call control use. |
Restriction |
|
Cisco CME 3.4 or a later version.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
|
|
Step 2 |
configure terminal Example: |
|
|
Step 3 |
voice register global Example: |
|
|
Step 4 |
mode [cme | cme-app] Example: |
|
|
Step 5 |
source-address ip-address [port port ] Example: |
|
|
Step 6 |
load phone-type firmware-file Example: |
|
|
Step 7 |
tftp-path {flash : | slot0: | tftp:// url } Example: |
|
|
Step 8 |
max-pool max-phones Example: |
|
|
Step 9 |
max-dn max-directory-numbers Example: |
|
|
Step 10 |
authenticate [all ][realm string ] Example: |
|
|
Step 11 |
ip qos dscp {{number | af | cs | default | ef } {media | service | signaling | video }} Example: |
|
|
Step 12 |
end Example: |
|
Cisco CME 3.4 or a later version.
mode cme command is enabled.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
voice register global Example: |
Enters voice register global configuration mode to set parameters for all supported SIP phones in Cisco Unified CME. |
|
Step 4 |
timezone number Example: |
Selects the time zone used for SIP phones in Cisco Unified CME.
|
|
Step 5 |
date-format [d/m/y | m/d/y | y-d-m |y/d/m | y/m/d | yy-m-d ] Example: |
(Optional) Selects the date display format on SIP phones in Cisco Unified CME.
|
|
Step 6 |
time-format {12 | 24 } Example: |
(Optional) Selects the time display format on SIP phones in Cisco Unified CME.
|
|
Step 7 |
dst auto-adjust Example: |
(Optional) Enables automatic adjustment of Daylight Saving Time on SIP phones in Cisco Unified CME.
|
|
Step 8 |
dst {start | stop } month [day day-of-month | week week-number | day day-of-week] time hour:minutes Example: |
(Optional) Sets the time period for Daylight Saving Time on SIP phones in Cisco Unified CME.
|
|
Step 9 |
end Example: |
Returns to privileged EXEC mode. |
To enable Network Time Protocol (NTP) for certain phones, such as the Cisco Unified IP Phones 7911G, 7941G, 7941GE, 7961G, 7961GE, 7970G, and 7971GE, connected to Cisco Unified CME running SIP, perform the following steps.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
voice register global Example: |
Enters voice register global configuration mode to set global parameters for all supported SIP phones in a Cisco Unified CME environment. |
|
Step 4 |
ntp-server ip-address [mode {anycast | directedbroadcast | multicast | unicast }] Example: |
Synchronizes clock on this router with the specified NTP server. |
|
Step 5 |
end Example: |
Returns to privileged EXEC mode. |
Restriction |
|
Cisco Unified CME 8.8 or a later version.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
|
||
|
Step 2 |
configure terminal Example: |
|
||
|
Step 3 |
ip http server Example: |
|
||
|
Step 4 |
ip http port number Example: |
|
||
|
Step 5 |
voice register global Example: |
|
||
|
Step 6 |
mode cme Example: |
|
||
|
Step 7 |
load phone-type firmware-file Example: |
|
||
|
Step 8 |
create profile Example: |
|
||
|
Step 9 |
exit Example: |
|
||
|
Step 10 |
telephony-service Example: |
|
||
|
Step 11 |
hfs enable [port port-number ] Example: |
|
||
|
Step 12 |
end Example: |
|
The debug cme-hfs command can be used to troubleshoot an attempt to download Cisco Unified SIP IP phone configuration and firmware files using the HFS service.
To configure a home path where any requested Cisco Unified SIP IP Phone firmware file that has no explicit binding can be searched and fetched using the HFS download service, perform the following steps.
Restriction |
|
Cisco Unified CME 8.8 or a later version.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
|
||
|
Step 2 |
configure terminal Example: |
|
||
|
Step 3 |
ip http server Example: |
|
||
|
Step 4 |
ip http port number Example: |
|
||
|
Step 5 |
telephony-service Example: |
|
||
|
Step 6 |
hfs enable [port port-number ] Example: |
|
||
|
Step 7 |
hfs home-path path Example: |
|
||
|
Step 8 |
end Example: |
|
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
|
||
|
Step 2 |
configure terminal Example: |
|
||
|
Step 3 |
voice register global Example: |
|
||
|
Step 4 |
application application-name Example: |
(Optional) Changes the default application for all dial peers associated with the SIP phones in Cisco Unified CME to the specified application.
|
||
|
Step 5 |
end Example: |
|
Restriction |
|
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
voice service voip Example: |
Enters voice service voip configuration mode. |
|
Step 4 |
media [flow around | flow through ] Example: |
Enables global media setting for VoIP calls.
|
|
Step 5 |
exit Example: |
Exits voice service voip configuration mode. |
|
Step 6 |
dial-peer voice tag voip Example: |
Enters dial-peer configuration mode to define a VoIP dial peer for the voice-mail system.
|
|
Step 7 |
media {[flow-around | flow-through] forking} Example: |
Enables media settings for voice dial-peer.
|
|
Step 8 |
exit Example: |
Exits voip dial-peer configuration mode. |
|
Step 9 |
voice class media tag Example: |
Enters voice class media configuration mode.
|
|
Step 10 |
media {[flow-around | flow-through ] forking } Example: |
Enables media settings for voice dial-peer.
|
|
Step 11 |
end Example: |
Returns to privileged EXEC mode. |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
|
|
Step 2 |
configure terminal Example: |
|
|
Step 3 |
voice register global Example: |
|
|
Step 4 |
overlap-signal Example: |
|
|
Step 5 |
exit Example: |
|
|
Step 6 |
voice register pool pool-tag Example: |
|
|
Step 7 |
overlap-signal Example: |
|
|
Step 8 |
exit Example: |
|
|
Step 9 |
voice register template template tag Example: |
|
|
Step 10 |
overlap-signal Example: |
|
|
Step 11 |
end Example: |
|
The following example shows TCP and UDP configured for various phones. Notice that in Bulk Registration (TCP), only the primary directory number is displayed, while in Line Registration (UDP), all directory numbers are displayed.
Router# show sip-ua status registrarLine destination expires(sec) contacttransport call-id peer============================================================1001 21.1.1.138 112 21.1.1.138TCP 239665429027943@21.1.1.138 400151009 21.1.1.138 118 21.1.1.138UDP 239671730027945@21.1.1.138 400191010 21.1.1.138 118 21.1.1.138UDP 239671745127945@21.1.1.138 40021!ip source-route!!ip cefno ip dhcp use vrf connectedip dhcp excluded-address 10.10.10.1 10.10.10.9ip dhcp excluded-address 192.168.2.1ipv6 unicast-routingipv6 cefntp server 223.255.254.254multilink bundle-name authenticatedisdn switch-type primary-5ess!voice service voip allow-connections h323 to h323allow-connections h323 to sipallow-connections sip to h323allow-connections sip to sipfax protocol cisco sipregistrar server expires max 1200 min 300!!!voice register dn 1number 2016allow watchname SIP-7961GElabel SIP2016!voice register dn 2number 2017!!voice logout-profile 1!voice logout-profile 2number 2001 type normalspeed-dial 1 2004 label "7960-1" !interface GigabitEthernet0/0ip address 10.10.10.2 255.255.255.0duplex autospeed autoipv6 address 2000:A0A:201:0:F:35FF:FF2C:697D/64ipv6 enableinterface GigabitEthernet0/1ip address 40.10.30.1 255.255.255.0shutdownduplex autospeed autoipv6 address 2000::1/64ipv6 address 2000::2/64ipv6 address 2000::A/64ipv6 address 3000::1/64ipv6 address 4000::1/64ipv6 address 9000::1/64ipv6 address F000::1/64ipv6 enable!i!!!ip http server!ipv6 route 2001:20:20:20::/64 2000:A0A:201:0:F:35FF:FF2C:5ipv6 route 2001:50:50:50::/64 2000:A0A:201:0:F:35FF:FF2C:5!tftp-server flash:P00308000500.bintftp-server flash:P00308000500.loadsp-server flash:cvm70sccp.8-5-2FT1-18.sbn!!voice-port 0/0/0:23!!mgcp fax t38 ecm!sccp local GigabitEthernet0/0sccp ccm 10.10.10.2 identifier 1 version 7.0 sccp ccm 2000:A0A:201:0:F:35FF:FF2C:697D identifier 2 version 7.0 sccp!!gateway timer receive-rtp 1200!sip-ua protocol mode dual-stack preference ipv6!!telephony-serviceprotocol mode dual-stack preference ipv6sdspfarm conference mute-on 111 mute-off 222sdspfarm units 2sdspfarm transcode sessions 20sdspfarm tag 1 xcodersdspfarm tag 2 conferenceconference hardwareno auto-reg-ephoneem logout 0:0 0:0 0:0 max-ephones 52max-dn 192ip source-address 10.10.10.2 port 2000ip source-address 2000:A0A:201:0:F:35FF:FF2C:697Dservice phone settingsAccess 1service phone spanTOPCPort 0timeouts transfer-recall 15system message MOTO-CME1url directories http://10.10.10.2:80/localdirectorycnf-file location flash:cnf-file perphoneload 7914 S00103020003load 7911 SCCP11.8-5-2FT1-18Sload 7970 SCCP70.8-5-2FT1-18Stime-zone 5max-conferences 4 gain -6call-forward pattern .Tweb admin system name cisco password ciscoweb admin customer name admin password admintransfer-system full-consultThe following example shows the system-level configuration for a Cisco Unified CME that can support up to 500 directory numbers on 100 phones. It sets up TFTP file sharing for phone firmware files for Cisco Unified IP Phones 7905, 7912, 7914, 7920, 7940, and 7960 and it loads those files.
tftp-server flash:ATA030100SCCP040211A.zup! ATA 186/188 firmwaretftp-server flash:CP7902080001SCCP051117A.sbin! 7902 firmwaretftp-server flash:CP7905080001SCCP051117A.sbin! 7905 firmwaretftp-server flash:CP7912080001SCCP051117A.sbin! 7912 firmwaretftp-server flash:cmterm_7920.4.0-02-00.bin! 7914 firmwaretftp-server flash:P00503010100.bin! 7920 firmwaretftp-server flash:S00104000100.sbn! 7935 firmwaretftp-server flash:cmterm_7936.3-3-5-0.bin! 7936 firmwaretftp-server flash:P0030702T023.bintftp-server flash:P0030702T023.loadstftp-server flash:P0030702T023.sb2! 7960/40 firmware!telephony-service max-ephones 100 max-dn 500 load ata ATA030100SCCP040211A load 7902 CP7902080001SCCP051117A load 7905 CP7905080001SCCP051117A load 7912 CP7912080001SCCP051117A load 7914 S00104000100 load 7920 cmterm_7920.4.0-02-00 load 7935 P00503010100 load 7936 cmterm_7936.3-3-5-0 load 7960-7940 P0030702T023 ip source-address 10.16.32.144 port 2000 create cnf-files version-stamp Jan 01 2002 00:00:00 transfer-system full-consult Cisco Unified IP Phone 7911, 7941, 7941-GE, 7961, 7961-GE, 7970, and 7971 require multiple files to be shared using TFTP. The following configuration example adds support for these phones. tftp-server flash:SCCP11.7-2-1-0S.loadstftp-server flash:term11.default.loadstftp-server flash:apps11.1-0-0-72.sbntftp-server flash:cnu11.3-0-0-81.sbntftp-server flash:cvm11.7-2-0-66.sbntftp-server flash:dsp11.1-0-0-73.sbntftp-server flash:jar11.7-2-0-66.sbn! 7911 firmware!tftp-server flash:TERM41.7-0-3-0S.loadstftp-server flash:TERM41.DEFAULT.loadstftp-server flash:TERM61.DEFAULT.loadstftp-server flash:CVM41.2-0-2-26.sbntftp-server flash:cnu41.2-7-6-26.sbntftp-server flash:Jar41.2-9-2-26.sbn! 7941/41-GE, 7961/61-GE firmware!tftp-server flash:TERM70.7-0-1-0s.LOADStftp-server flash:TERM70.DEFAULT.loadstftp-server flash:TERM71.DEFAULT.loadstftp-server flash:CVM70.2-0-2-26.sbn tftp-server flash:cnu70.2-7-6-26.sbn tftp-server flash:Jar70.2-9-2-26.sbn! 7970/71 firmware!telephony-service load 7911 SCCP11.7-2-1-0S load 7941 TERM41.7-0-3-0S load 7961 TERM41.7-0-3-0S load 7941GE TERM41.7-0-3-0S load 7961GE TERM41.7-0-3-0S load 7970 TERM70.7-0-1-0s load 7971 TERM70.7-0-1-0s create cnf-files version-stamp Jan 01 2002 00:00:00...The following example shows how to disable automatic ephone registration, display a log of attempted registrations, and then clear the log:
Router(config)# telephony-service
Router(config-telephony)# no auto-reg-ephone
Router(config-telephony)# exit
Router(config)# exit
Router# show ephone attempted-registrations
Attempting Mac address:
Num Mac Address DateTime DeviceType
-----------------------------------------------------------------------------
1 C863.8475.5417 22:52:05 UTC Thu Apr 28 2005 SCCP Gateway (AN)
2 C863.8475.5408 22:52:05 UTC Thu Apr 28 2005 SCCP Gateway (AN)
.....
25 000D.28D7.7222 22:26:32 UTC Thu Apr 28 2005 Telecaster 7960
26 000D.BDB7.A9EA 22:25:59 UTC Thu Apr 28 2005 Telecaster 7960
...
47 C863.94A8.D40F 22:52:17 UTC Thu Apr 28 2005 SCCP Gateway (AN)
48 C863.94A8.D411 22:52:18 UTC Thu Apr 28 2005 SCCP Gateway (AN)
49 C863.94A8.D400 22:52:15 UTC Thu Apr 28 2005 SCCP Gateway (AN)
Router# clear telephony-service ephone-attempted-registrations
The following example shows how to enable the HFS download service:
Router(config)# ip http server
Router(config)# ip http port 1234
Router (config)# telephony-service
Router(config-telephony)# hfs enable port 65500
The following example shows how a new directory called phone-load can be created under the root directory of the flash memory and set as the hfs home-path:
cassini-c2801#mkdir flash:phone-loads
Create directory filename [phone-loads]?
Created dir flash:phone-loads
cassini-c2801#sh flash:
-#- --length-- -----date/time------ path
1 13932728 Mar 22 2007 15:57:38 +00:00 c2801-ipbase-mz.124-1c.bin
2 33510140 Sep 18 2010 01:21:56 +00:00 rootfs9951.9-0-3.sebn
3 143604 Sep 18 2010 01:22:20 +00:00 sboot9951.111909R1-9-0-3.sebn
4 1249 Sep 18 2010 01:22:40 +00:00 sip9951.9-0-3.loads
5 66996 Sep 18 2010 01:23:00 +00:00 skern9951.022809R2-9-0-3.sebn
6 10724 Sep 18 2010 00:59:48 +00:00 dkern9951.100609R2-9-0-3.sebn
7 1507064 Sep 18 2010 01:00:24 +00:00 kern9951.9-0-3.sebn
8 0 Jan 5 2011 02:03:46 +00:00 phone-loads
14819328 bytes available (49192960 bytes used)
cassini-c2801#conf t
Enter configuration commands, one per line. End with CNTL/Z.
cassini-c2801(config)#tele
cassini-c2801(config)#telephony-service
cassini-c2801(config-telephony)#hfs hom
cassini-c2801(config-telephony)#hfs home-path flash:?
WORD
cassini-c2801(config-telephony)#hfs home-path flash:phone-loads
cassini-c2801(config-telephony)#The following is a sample output from the show voice register hfs command:
Router(config)#show voice register hfs
Fetch Service Enabled = Y
App enabled port = 6970
Use default port = N
Registered session-id = 19
Default home path = flash:/
Ongoing fetches from home = 0
HTTP File Server Bindings
No. of bindings = 11
No. of url table entries = 9No. of alias table entries = 9
The following example is configured on the primary Cisco Unified CME router. It establishes the router at 10.5.2.78 as a secondary router. The voice port 3/0/0 is the FXO port for incoming calls from the PSTN. It is set to use ground-start signaling and to detect incoming calls by counting incoming ring signals.
telephony-service ip source-address 10.0.0.1 port 2000 secondary 10.5.2.78 voice-port 3/0/0 signal ground-start incoming alerting ring-only The secondary Cisco Unified CME router is configured with the same commands, except that the ring number command is set to 3 instead of using the default of 1.
telephony-service ip source-address 10.0.0.1 port 2000 secondary 10.5.2.78 voice-port 3/0/0 signal ground-start incoming alerting ring-only ring number 3The following example is configured on the primary Cisco Unified CME router. It establishes the router at 10.6.50.6 as a secondary router with keepalive value set to 200 seconds.
Note |
For the synchronization to happen, additional configurations are needed. These configurations such as IXI, HTTP, and telephony-service are provided in the output. |
voice register global
source-address 10.6.21.4 port 6000 secondary 10.6.50.6
keepalive 200
ip http server
ixi transport http
response size 8
no shutdown
request outstanding 2
request timeout 30
ixi application cme
no shutdown
response timeout -1
telephony-service
ip source-address 10.6.21.4 secondary 10.6.50.6
standby user cisco password cisco123The secondary Cisco Unified CME router is configured with the same commands:
voice register global
source-address 10.6.21.4 port 6000 secondary 10.6.50.6
keepalive 200
ip http server
ixi transport http
response size 8
no shutdown
request outstanding 2
request timeout 30
ixi application cme
no shutdown
response timeout -1
telephony-service
ip source-address 10.6.50.6
xml user cisco password cisco123 15The following example shows media flow-around enabled in voice service voip, voice class media, and dial peer configuration modes:
Router# show running config
!
!
voice service voip
ip address trusted list
ipv4 20.20.20.1
media flow-around
allow-connections sip to sip
vpn-group 1
vpn-gateway 1 https://9.10.60.254/SSLVPNphone
vpn-trustpoint 1 trustpoint cme_cert root
vpn-hash-algorithm sha-1
vpn-profile 1
keepalive 50
auto-network-detect enable
host-id-check disable
vpn-profile 2
mtu 1300
authen-method both
password-persistent enable
host-id-check enable
vpn-profile 4
fail-connect-time 50
sip
!
voice class media 10
media flow-around
!
!
!
dspfarm profile 1 conference
codec g711ulaw
maximum sessions 2
associate application SCCP
!
dial-peer voice 222 voip
media flow-around
!
dial-peer voice 10 voip
media flow-around
!
dial-peer voice 101 voip
endThe following example shows the overlap-signal command configured in telephony-service configuration mode, ephone template 10, and ephone 10:
The following example shows the overlap-signal command configured in telephony-service configuration mode, ephone template 10, and ephone 10:
Router# show running config
!
!
telephony-service
max-ephones 25
max-dn 15
load 7906 SCCP11.8-5-3S.loads
load 7911 SCCP11.8-5-3S.loads
load 7921 CP7921G-1.3.3.LOADS
load 7941 SCCP41.8-5-3S.loads
load 7942 SCCP42.8-5-3S.loads
load 7961 SCCP41.8-5-3S.loads
load 7962 SCCP42.8-5-3S.loads
max-conferences 12 gain -6
web admin system name cisco password cisco
transfer-system full-consult
create cnf-files version-stamp Jan 01 2002 00:00:00
overlap-signal
!
ephone-template 1
button-layout 1 line
button-layout 3-6 blf-speed-dial
!
ephone-template 9
feature-button 1 Endcall
feature-button 3 Mobility
!
!
ephone-template 10
feature-button 1 Park
feature-button 2 MeetMe
feature-button 3 CallBack
button-layout 1 line
button-layout 2-4 speed-dial
button-layout 5-6 blf-speed-dial
overlap-signal
!
ephone 10
device-security-mode none
mac-address 02EA.EAEA.0010
overlap-signal
The following example shows the overlap-signal configured in voice register global configuration mode and voice register pool 10:
Router# show running config
!
!
!
voice service voip
ip address trusted list
ipv4 20.20.20.1
media flow-around
allow-connections sip to sip
!
voice class media 10
media flow-around
!
!
voice register global
max-pool 10
overlap-signal
!
voice register pool 5
overlap-signal
!
!
!
After configuring system-level parameters, you are ready to configure phones for making basic calls in Cisco Unified CME.
To use Extension Assigner to assign extension numbers to the phones in your Cisco Unified CME, see Create Phone Configurations Using Extension Assigner.
Otherwise, see Configure Phones to Make Basic Call.
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to https://cfnng.cisco.com/. An account on Cisco.com is not required.|
Feature Name |
Cisco Unified CME Versions |
Feature Information |
|---|---|---|
|
Redundant Router for SIP Phones |
11.6 |
Introduces redundant router support for SIP phones. |
|
Unsolicited Notify for Shared Line and Presence Events for Cisco Unified SIP IP Phones |
9.0 |
Allows the Unsolicited Notify mechanism to reduce network traffic during Cisco Unified SIP IP phone registration using the bulk registration method. |
|
HFS Download Support for IP Phone Firmware and Configuration Files |
8.8 |
Provides download support for SIP and SCCP IP phone firmware, scripts, midlets, and configuration files using the HTTP File-Fetch Server (HFS) infrastructure. |
|
Bulk Registration |
8.6/3.4 |
Introduces bulk registration support for SIP phones. Introduces bulk registration for registering a block of phone numbers with an external registrar. |
|
Media Flow Around for SIP-SIP Trunks |
8.5 |
Introduces the media flow around feature, which eliminates the need to terminate RTP and re-originate on Cisco Unified CME, reducing media switching latency and increasing the call handling capacity for Cisco Unified CME SIP trunk. |
|
Overlap Dialing for SCCP and SIP Phones |
8.5 |
Allows the dialed digits from the SIP or SCCP IP phones to pass across the PRI/BRI trunks as overlap digits and not as enbloc digits, enabling overlap dialing on the PRI/BRI trunks. |
|
DSCP |
7.1 |
Supports DSCP packet marking for Cisco Unified IP Phones to specify the class of service for each packet. |
|
Maximum Ephones |
7.0/4.3 |
The max-ephones command sets the maximum number of SCCP phones that can register to Cisco Unified CME, without limiting the number that can be configured. Maximum number of phones that can be configured is 1000. |
|
Network Time Protocol for SIP Phones |
4.1 |
Allows SIP phones to synchronize to an NTP server. |
|
Blocking Automatic Registration |
4.0 |
Blocks IP phones that are not explicitly configured in Cisco Unified CME from registering. |
|
Per-Phone Configuration Files and Alternate Location |
4.0 |
Defines a location other than system for storing configuration files and specifies the type of configuration files to generate. |
|
Redundant Router for SCCP Phones |
4.0 |
Introduces redundant router capability. |
|
SIP phones in Cisco Unified CME |
3.4 |
Introduces support for SIP endpoints directly connected to Cisco Unified CME. |
Feedback