Cisco Unified Communication Manager Part-3

After doing the initial configuration of Cisco Unified Communication Manager, Now we will move to Basic end point configuration (IP Phone). There are mandatory and optional configuration details that must be set system-wide in preparation for adding Cisco IP Phones. It is advisable to only use default system-wide setting values for these elements if they are applicable to the deployment. Call manager group, region, and location are required configuration parameters that default to values that most people almost never use. The device pool and region are mandatory, but they have default values. Default values that do not work can be can be copied, renamed, and reconfigured. Name all configuration elements in a way that allows the administrator to clearly define where the element is and what the element’s function is. A device pool named DXB-CMG could be used for a CM_group for the Dubai office. Following system-level configurations that will be applied to endpoints

• CUCM Group
• Regions
• Locations
• Date/Time Group
• Phone NTP Reference
• Device Pool
• Partition
• Calling Search Space

CUCM Group: The first CUCM in the list (top) serves as the primary CUCM for that group, the next member of the list (from the top) serves as the secondary CUCM, and the third server in the list is the last in the list (bottom). If the primary CUCM in the CUCM group is not available, the device tries to register with the second CUCM server listed in the CUCM group. The Cisco IP Phone always maintains an active TCP port 2000 (SCCP) connection open to the current active CUCM and current backup CUCM servers. Keep lives are sent every 30 seconds to the current active and current backup CUCM servers to guarantee reachability.

Regions: Regions are used to specify the audio and video codecs utilized between two devices on a call-by-call basis that is used per call within and between regions. The configured audio codec determines the type of audio compression used per audio call

 

Locations: Use locations to implement call admission control (CAC) in a centralized call-processing system. CAC enables the administrator to limit the number of audio and video calls that can traverse the WAN. WAN bandwidth is limited by the amount of bandwidth that is available for audio and video calls as configured in the priority queue (PQ) of the QoS configuration. In a centralized call-processing system, a single CUCM cluster provides call processing for all locations on the IP telephony network. The CUCM cluster usually resides at the main location, but Cisco IP Phones and gateways to the public switched telephone network (PSTN) are distributed among two or more buildings. IP WAN links connect the remote locations to the main location.

 

Date/Time Group: Installation of CUCM automatically configures a default date/time group that is called CMLocal. CMLocal synchronizes to the active date and time of the operating system on the Publisher server, which is automatically replicated to all Subscriber servers. CMLocal should be treated in the same way as other defaults. I suggest setting the default CMLocal date/time group to the most widely used time zone in your deployment, but try to not use this date/time group. Copy the default configuration, rename the date/time group, and change the configuration elements. A large, national, centralized call-processing deployment of CUCM would require at least four date/time groups to represent the time zones across the country.

 

Device Pool: Device pools define sets of common characteristics for devices. We call above configured option into Device pool and assign Device pool to IP Phone, Gateways, Gatekeeper and Trunks. Once we assign Device pool to a device then CUCM Group, location, Regions, Date/Time Group, Media Resource List and SRTS configurations are associated to that device (IP phone) through Device Pool. So changes in Device Pool will automatically reflect to devices which are associated to Device Pool. In a centralize deployment, we recommend to have dedicated Device pool for respective sites/locations.

 

 

Partition: Partitions are the method that Call Manager uses to group destinations. These destinations lie  either within the IP telephony network, or externally in the public networks. The definition of Partitions and Calling Search Spaces are closely related and allow restrictions to be placed on where users can dial.

 

Call Search Space: A calling search space comprises an ordered list of route partitions that are typically assigned to devices. Calling search spaces determine the partitions that calling devices search when they are attempting to complete a call. A calling search space can be assign to IP Phone, Device Pool, Gateways, Gatekeeper and Trunks

 

Add IP Phone in CUCM: Device > phone > add New > then select the Phone Type in drop down menu Like Cisco 7945 and then click on Next and select Device Protocol SCCP from the list.

  Device> Phone > Phone List

Cisco Unified Communication Manager Part-2

We are going to cover step by step configuration & integration of Cisco Unified Communication Manager with others Cisco Unified Communication portfolio products.

CUCM Initial Configuration

Once the CUCM installation has been completed, some initial configuration has to be done in the preparation of endpoint provisioning.

Network settings: Basic network settings including Network Time Protocol (NTP), Domain Name System (DNS), and DHCP should be addressed before initial endpoint deployment.

Network and feature services: CUCM servers run network services (automatically activated) and feature services (activated by the administrator). After installation, network services should be checked and desired feature services should be activated. A CUCM cluster can consist of up to 20 servers. Each server can fulfill different tasks, such as running a TFTP or DHCP server, being the database publisher, processing calls (subscribers), and providing media resources. Depending on the usage of a server, different services have to be activated on the system.

There are two types of services on CUCM servers

Network services: Network services are automatically activated and are required for the operation of the server. Network services cannot be activated or deactivated by the administrator, but they can be stopped, started, or restarted from the Cisco Unified Serviceability web interface. Choose Tools > Control Center > Network Services.

Network services are the operating system services that CUCM relies on. Network services are summarized as follows:

•  Performance and monitoring services: Cisco CallManager Serviceability RTMT,Cisco RTMT Reporter
•  Backup and restore services: Cisco DRF Master, Cisco DRF Local System Services:       Cisco CallManager Serviceability, Cisco CDP, Cisco Trace Collection Service
•  Platform services: Cisco Database, Cisco Tomcat, SNMP Master Agent
• DB services: Cisco Database Layer Monitor
• Simple Object Access Protocol (SOAP) services: SOAP Real Time Service APIs and so on
• CM services: Cisco CallManager Personal Directory, Cisco Extension Mobility Application,    Cisco CallManager Cisco IP Phone Services
• CDR services: Cisco CDR Repository Manager, CDR Agent
•  Admin services: Cisco CallManager Admin

Feature services: Feature services can be activated or deactivated on a per-server basis to assign specific tasks or functions (call processing, TFTP, DHCP) to a certain server. Feature services can be activated and deactivated by the administrator from the Cisco Unified Serviceability web interface (Tools > Service Activation). Feature services can be started, stopped, or restarted from the Cisco Unified Serviceability web interface (Tools > Control Center > Feature Services).

Feature services are the CUCM-related services that run on top of the operating system and database. Feature services are summarized as follows

• Database and admin services: Cisco AXL Web Service, Cisco Bulk Provisioning Service, Cisco     TAPS Service
• Performance and monitoring services: Cisco Serviceability Reporter, Cisco CallManager SNMP Service
• CM services: Cisco CallManager, Cisco TFTP, Cisco CTIManager, Cisco Extension Mobility
• Computer Telephony Integration (CTI) services: Cisco CallManager Attendant Console Server, Cisco IP Manager Assistant, Cisco WebDialer Web Service
• CDR services: Cisco SOAP, including CDRonDemand Service, Cisco CAR Scheduler, Cisco CAR Web Service
• Security services: Cisco CTL Provider, Cisco Certificate Proxy Function
• Directory services: Cisco DirSync
• Voice quality reporter services: Cisco Extended Functions

Enterprise parameters: CUCM has some cluster-wide configuration settings called enterprise parameters. Some enterprise parameters will be modified in most deployments

Service parameters: CUCM services have configurable parameters that are set on a per-CUCM server. Some service parameter default values will be modified in a standard deployment.

 

Let's start with Cisco Unified CM  Administration configuration menu. following snapshot showing the configuration option available in each menu bar.

 

 

I will start with overview of each option and then we will move to configuration part to get to know how to use these options in different deployment and scenario.

 

SYSTEM Menu

 

Server: Use the server configuration to specify the address of the server where Cisco Unified Communications Manager is installed. If your network uses Domain Name System (DNS) services, you can specify the host name of the server. If your network does not use DNS services then you must specify the IP address of the server

Cisco Unified CM: Use Cisco Unified Communications Manager configuration to specify the ports and other properties for each Cisco Unified Communications Manager that is installed in the same cluster. A cluster comprises a set of Cisco Unified Communications Managers that enables redundancy. For the first node in a Cisco Unified Communications Manager cluster, the server gets automatically added as part of the installation. To add additional Cisco Unified Communications Managers to a cluster, the administrator must configure a server (by using Server Configuration) and then add the Cisco Unified Communications Manager (by using Cisco Unified Communications Manager Configuration). This procedure repeats for each Cisco Unified Communications Manager that is in the cluster

Cisco Unified CM Group: A Cisco Unified Communications Manager Group specifies a prioritized list of up to three Cisco Unified Communications Managers. The first Cisco Unified Communications Manager in the list serves as the primary Cisco Unified Communications Manager for that group, and the other members of the group serve as secondary and tertiary (backup) Cisco Unified Communications Managers. Cisco Unified CM Groups provide important features for your system:

• Redundancy—this feature enables you to designate a primary and backup Cisco Unified Communications Managers for each group.

• Call processing load balancing—this feature enables you to distribute the control of devices across multiple Cisco Unified Communications Managers.

Phone NTP Reference: You can configure phone Network Time Protocol (NTP) references in Cisco Unified Communications Manager Administration to ensure that a phone that is running gets its date and time from the NTP server. After you add the phone NTP reference to Cisco Unified Communications Manager Administration, you must add it to a date/time group. In the date/time group, you prioritize the phone NTP references, starting with the first server that you want the phone to contact.

Date/Time Group Configuration: Use Date/Time Groups to define time zones for the various devices that are connected to Cisco Unified Communications Manager. Each device exists as a member of only one device pool, and each device pool has only one assigned Date/Time Group.

Presence Group Configuration: When you configure Presence in Cisco Unified Communications Manager Administration, an interested party, known as a watcher, can monitor the real-time status of a directory number or SIP URI, a presence entity, from the device of the watcher. Cisco Unified Communications Manager controls which destinations a watcher can monitor with presence groups. A presence group contains watchers and the destinations that can be monitored by the watchers in the group. To allow watchers in one group to monitor directory numbers in other groups, you specify permission settings to allow or block (disallow) the presence request. Presence authorization works with the presence groups that are configured to ensure that a watcher has permission to monitor the status of a destination.

Region Configuration: we use regions to specify the bandwidth that is used for audio and video calls within a region and between existing regions.

Device Pool Configuration: Device pools define sets of common characteristics for devices. The device pool structure supports the separation of user and location information. The device pool contains only device and location-related information. Like Region, Date/Time Group, CM Group and SRST information for respective site or location. Ensure that each device is associated with a device pool and with a common device configuration for user-oriented information

Device Mobility: Device mobility groups represent the highest level geographic entities in your network. Depending upon the network size and scope, your device mobility groups could represent countries, regions, states or provinces, cities, or other entities. For example, an enterprise with a worldwide network might choose device mobility groups that represent individual countries, whereas an enterprise with a national or regional network might define device mobility groups that represent states, provinces, or cities

DHCP: You can configuration Cisco Unified Communication Manager as DHCP as well to assign the IP addresses to IP Phones.

LDAP: We can this option to integrate the Unified CM with external Directory services server like Windows Activity directory services to use ADS user credential for unified Communication services. So users don’t have to memories separate credential for each service.

Location: Use locations to implement call admission control in a centralized call-processing system. Call admission control enables you to regulate audio quality and video availability by limiting the amount of bandwidth that is available for audio and video calls over links between the locations.

Physical Location: Physical locations provide a means of distinguishing the parameters that relate to a specific geographical location from other parameters. For example, a media resources server may serve a specific office or campus within the enterprise. When a device roams to another office or campus and reregisters with Cisco Unified Communications Manager, you want to have the media resources server at the roaming location serve the device. By defining the physical location according to availability of media services, you can assure efficient and cost-effective reassignment of services as devices move from one physical location to another.

SRST: A survivable remote site telephony (SRST) reference comprises the gateway that can provide limited Cisco Unified Communications Manager functionality when all other Cisco Unified Communications Manager servers for a device are unreachable. Typically assigned to device pools, SRST references determine the gateways where calling devices search when they attempt to complete a call if Cisco Unified Communications Manager is unavailable

MLPP: An MLPP domain specifies the collection of devices and resources that are associated with an MLPP subscriber. When an MLPP subscriber that belongs to a particular domain places a precedence call to another MLPP subscriber that belongs to the same domain, MLPP service can preempt the existing call that the called MLPP subscriber is on for a higher precedence call. MLPP service availability does not go across different domains.

Enterprise Parameters: Enterprise parameters provide default settings that apply to all devices and services in the same cluster. (A cluster comprises a set of Cisco Unified Communications Managers that share the same database.)

Service parameters: Service parameters for Cisco Unified Communications Manager allow you to configure different services on selected servers. You can view a list of parameters and their descriptions by clicking the question mark button in the Service Parameter Configuration window. You can view the list with a particular parameter at the top by clicking that parameter.

Security Profile: Security Profile includes security-related settings such as device security mode, SIP Trunk, CUMA server, CAPF settings, digest authentication settings (only for phones that are running SIP), and encrypted configuration file settings.

Application Server: You can use the Application Server in Cisco Unified Communications Manager Administration to maintain associations between the Cisco Unified Communications Manager and off-cluster, external applications, such as Cisco Unity Connection and Cisco Unified Presence, and to synchronize Cisco Unified Communications Manager systems and other applications.

Licensing: You can install the license and get the license unit report to display the total license capacity and the number of licenses in use. This tool generates a report that lists the total number of available licenses. The license unit report also displays the software license version that is installed on the Cisco Unified Communications Manager.
 

Call Routing Menu

AAR GROUP: Automated alternate routing (AAR) provides a mechanism to reroute calls through the PSTN or other network by using an alternate number when Cisco Unified Communications Manager blocks a call due to insufficient location bandwidth. With automated alternate routing, the caller does not need to hang up and redial the called party. The AAR group represents the dialing area where the line/directory number (DN), the Cisco voice mail port, and the gateway are located.

Dial Rule: The administrator uses dial rules configuration to add and sort the priority of dialing rules. Dial rules for applications such as Cisco Unified Communications Manager Assistant automatically strip numbers from or add numbers to telephone numbers that a user dials. For example, the dial rules automatically add the digit 9 in front of a 7-digit telephone number to provide access to an outside line.

Route Filter: Route filters, along with route patterns/hunt pilots, use dialed-digit strings to determine how a call is handled. Route filters only apply when you configure a pattern that contains the at (@) wildcard. When the route pattern/hunt pilot contains the @ wildcard, Cisco Unified Communications Manager routes calls according to the numbering plan that is specified in the Numbering Plan drop-down list box. The route filter window that Cisco Unified Communications Manager displays varies according to the numbering plan that you select.

Route Hunt:  Route hunt having key role in Unified communication Manager dial-plan configuration in form of Line-group, Hint-List, Hint-Pilot, Route Group, Route List and Route Pattern.

SIP Route Pattern: Cisco Unified Communications Manager uses SIP route patterns to route or block both internal and external calls

Class of Control: Partition and Calling Search Space important part of class of control. A partition contains a list of route patterns (directory number (DN) and route patterns). Partitions facilitate call routing by dividing the route plan into logical subsets that are based on organization, location, and call type A calling search space comprises an ordered list of route partitions that are typically assigned to devices. Calling search spaces determine the partitions that calling devices search when they are attempting to complete a call

Translation Pattern: Cisco Unified Communications Manager uses translation patterns to manipulate dialed digits before it routes a call. In some cases, the system does not use the dialed number. In other cases, the public switched telephone network (PSTN) does not recognize the dialed number.

Meet-Me Number: Meet-Me conferences require an allocation of directory numbers. Cisco Unified Communications Manager Administration provides the Meet-Me conference directory number range to users, so they can access the feature.

Cisco Unified Communication Manager Part-1

Cisco Unified Communication Manager Part-1

 A Cisco Unified Communications (UC) deployment relies on Cisco Unified Communications Manager (CUCM) formerly known as Cisco Call Manager for call processing, device control, call routing, mobility services, phone/system feature administration, and dial plan administration. CUCM plays core part in a UC deployment to provide the essential call-routing functions necessary to deploy voicemail, unified messaging, presence, video to the desktop, videoconferencing and TelePresence. CUCM (Cisco Unified Communications Manager) uses SIP or SCCP to communicate with Cisco IP Phones for call setup and teardown tasks. All supplementary services (call hold, park, transfer, conference) are transported as call-signaling events.

A CUCM cluster can have up to 20 servers in it. The cluster consists of one publisher server, which maintains the read/write copy of the CUCM’s database. The publisher replicates the database as a read-only database to up to eight subscriber servers in the CUCM cluster. Each cluster has a restriction of four subscriber servers that can perform active call processing. Additional subscriber servers are dedicated standby servers in case the active subscriber server is not available. The additional 11 servers in the cluster are responsible for various services, including TFTP and media resources (conferencing, music on hold, transcoding).

The database in Cisco Communication Manager cluster replicates the configuration information in a hub-and-spoke topology (one publisher, up to eight subscribers). CUCM nodes also use a second communication method to replicate some runtime data (call forwarding, message waiting indicators, hunt login status) using a master-master replication technology referred to as user-facing features (UFF). UFF provides a full-mesh replication topology allowing dynamic registration of active call information that changes much more frequently than the database changes.

The data in the CUCM database is divided into two types, which are described below.

 

Static Configuration Data
Static configuration data is created as part of the configuration of the CUCM cluster. Read/write access to this data is provided in the publisher server only. Subscriber servers have a local read-only copy of the database that is replicated downstream from the publisher. If the publisher becomes unavailable, the subscriber server’s replicated  data can be used to process calls locally. Database replication is unidirectional, from the publisher to the subscribers. Only call detail records (CDR) and call management records (CMR) are replicated from the subscriber servers to the publisher. All other configuration information is downloaded from the publisher. CDRs contain call detail fields such as calling party, called party, start time, stop time, call duration, and chargeback (if applicable). The CDRs provided by CUCM are standard for a phone switch/PBX. CMRs provide QoS details regarding the number of packets transmitted and received, maximum jitter, average jitter, mean opinion score (MoS) rating of the call, and so on. CMRs are useful for troubleshooting QoS issues (packet loss, delay, and jitter) that could affect voice quality.

User-Facing Features

The publisher is the only server in the CUCM cluster with a read/write copy of the database, and all configuration changes should be made on the publisher. The publisher then replicates these changes to the read-only subscriber databases. Call-processing redundancy can be provided by subscriber servers, but the single-publisher model represents a single point of failure from the perspective of providing moves, adds, and changes (MAC). The publisher was also the only server in the cluster responsible for call forwarding, extension mobility login, and message-waiting indicator changes in versions of CUCM before CUCM 6.0. CUCM treats a small portion of the database as dynamic configuration data. Read/write access to dynamic configuration data is provided on all servers, allowing certain information to be modified if the publisher server is unavailable. The dynamic information that can be changed during a publisher outage is referred to as user-facing features (UFF). UFF data is replicated between all servers in the cluster.

CUCM Call-Processing Redundancy

A CUCM cluster is a group of physical servers working as a single IP PBX system. A cluster can contain up to 20 servers, of which a maximum of eight servers can run the Cisco CallManager service performing call processing in a cluster. Any additional servers above the eight can be used to provide added functionality to support the telephony deployment (for example, TFTP servers, media resources such as conference bridges, music on hold [MOH], MTP, annunciator, and transcoding) and/or support third-party integrations for add-on applications through APIs. CUCM call-processing redundancy is implemented by grouping servers running the Cisco CallManager service into CM groups. A CM group is a prioritized list of up to three call-processing servers.

The following rules apply for the CM groups:

·         Many CM groups can exist in the same cluster.

·          Each call-processing server can be assigned to more than one CM group.

·          Each device has an assigned CM group that will determine the primary, secondary, and tertiary servers to which it can register.

 

Cisco IP Phones register with their primary server. When idle, the Cisco IP Phones and CUCM exchange keepalives to ensure that reachability between the devices is maintained. Cisco IP Phones running SCCP establish a TCP session with their primary and secondary servers and exchange TCP keepalives every 30 seconds by default. When the connection to the primary server is lost (no keepalives received for three keepalives), the Cisco IP Phone registers to the secondary server and establishes a TCP connection with the tertiary call-processing server. The Cisco IP Phone continuously tries to reestablish a connection with the primary server. If the Cisco IP Phone is successful in reaching the primary server when registered to the secondary, the IP Phone waits 120 seconds for the default connection monitor duration timer to expire before reregistering with the primary server. The connection monitor duration alleviates the side effects of an oscillating/flapping WAN link, where the WAN is continuously going up and down. The connection monitor duration is a device pool configuration parameter. A 1:1 CUCM call-processing redundancy deployment design guarantees that Cisco IP Phone registrations will never overwhelm the backup servers if there are concurrent primary server failures on different primary servers. The 1:1 design has an increased server count compared to other redundancy design models. This design is not the most cost-effective, but it offers the highest level of fault tolerance.

 

Each cluster must also provide a TFTP service running on a CUCM server. The TFTP service is responsible for delivering IP phone configurations, firmware (Load ID)  upgrades to telephones, and files such as backgrounds and ringtones. The server running the TFTP service might experience significant load in a large cluster. Depending on the number of devices that a server is supporting, you can run the TFTP service on a dedicated server, on the database publisher server, or on any other server in the cluster.

Cluster redundancy model leveraging Cisco 7845 Media Convergence Servers (MCS) or Cisco Unified Computing System. Each 7845/UCS server can accommodate up to a maximum of 7500 Cisco IP Phones. We are going to cover three different scenarios. Scenario one includes three servers, but only two servers would be required if the cluster had fewer than 1250 phones (1000 phones for the 7835 model server). A cluster consisting of 1250 to 7500 phones would require a server dedicated to maintaining the publisher and TFTP functionality.

Scenario one uses two servers for call-processing functionality. One server is the primary call-processing agent, while the other server is the backup call-processing agent. Instead of dedicating a server to a backup-only role, registration-based load sharing can occur between the two servers, and the two servers can back each other up (active/active load sharing). This configuration would need to be manually configured in the CM group that is assigned to the phones. Server A would be the primary for phones 1–3750 and the backup for phones 3751–7500, while server B would be the primary for phones 3751–7500 and the backup for phones 1–3750.

Scenario two leverages everything you covered in scenario one but has doubled the number of call-processing servers and has a dedicated TFTP server. The Cisco CUCM Solution recommends one dedicated TFTP server in a cluster of 7500 Cisco IP Phones. Notice that there are two active call-processing servers with two dedicated backup servers. Because each CUCM cluster can have up to four active call-processing servers running the CallManager service, a load-sharing configuration like that covered in scenario one can be used to get the full benefit of all four servers.

Scenario three leverages everything discussed in the two prior scenarios, but the number of call-processing servers has again doubled when compared against the last model covered. Load sharing cannot occur in this model because the CUCM is limited to four. Cisco has a super-clustering model where more than four active servers can be leveraged, but this is a model that involves Cisco Advanced Services design and tuning services. Two TFTP servers must be used in this model because of the number of phones.

Best practice is to enable the TFTP service on at least two servers in the CUCM cluster in all the models to provide TFTP redundancy. Although the 1:1 redundancy design model provides the highest level of redundancy, it might be excessive. It is unlikely that multiple server failures will occur at the same time, but beware of Murphy’s Law! If it can happen, it will. Because of the low probability of multiple simultaneous server outages and server cost, some environments choose to use a 2:1 redundancy design

CUCM Signaling and Media Paths

CUCM uses SIP or SCCP to communicate with Cisco IP Phones for call setup and teardown tasks. All supplementary services (call hold, park, transfer, conference) are transported as call-signaling events. When the called party picks up his ringing phone, CUCM completes the call setup phase, resulting in a media exchange that occurs directly between the Cisco IP Phones across the IP network using the Real-Time Transport Protocol (RTP). CUCM is not involved in any call processing after the call has been set up unless a softkey feature is initiated. The CUCM server could be unplugged from the network during the call and the calls would survive (call survivability/call preservation). The users on the active call would not be aware of the CUCM failure unless they attempted to use a feature on the phone during the call. All supplementary services will fail during the CUCM outage as indicated by the LCD screen message indicated on the IP Phone (CM Down, Features Disabled). CUCM is involved only in call setup, teardown, and the invocation of supplementary service features.

Basic IP Telephony Call

The following steps occur during a call from phone A to B:

1. The calling party at IP phone A picks up the handset (goes off hook), resulting in an SCCP or SIP message being   sent to CUCM, indicating that the device has gone off hook.

2. CUCM responds to this stimulus message with a response message that tells the device to play the dial tone file that is stored in the flash memory of the phone.

3. The calling party at phone A then hears dial tone and begins dialing the phone number of phone B (called party). SCCP phones send their digits to CUCM as they are pressed (digit by digit), whereas SIP phones send their dialed digits digit by digit or in one message (enbloc signaling), depending on the generation of Cisco IP Phone. Type B SIP-based Cisco phones use Keypad Markup Language (KPML) by default. KPML sends digits to CUCM in real time as they are dialed unless SIP dial rules are leveraged. SIP dial rules always send their digits enbloc regardless of whether the Cisco Phone is a Type A (7940, 7960) or Type B Phone (7970, 79x1, 79x2, 79x5, 7906). Type A Cisco Phones do not support KPML, resulting in enbloc signaling by default

4. Regardless of how the digits are collected, CUCM performs digit analysis against the dialed digits collected from the calling party.

5. When a match is found in the call-routing database, CUCM routes (steers) the call to the called party based on the call-routing configuration. If CUCM does not find a match, a reorder tone is sent to the calling party.

6. CUCM sends a signaling event to the calling party (phone A) to initiate ringback, so the user at phone A will hear the ringback tone. CUCM also signals the call to the called (destination) phone (ringdown). Additional information is provided to the phones to indicate the calling and called party name and number. (Phone A’s LCD will indicate the called party name and number, while phone B’s LCD will indicate the calling party name and number).