CICD - Descriptions Flashcards

Question

CUCM - SIP Phone registration

Answer 1

1. Phone obtains the Power (PoE or AC adapter). 2. Phone loads its locally stored firmware image. 3. Phone learns the Voice VLAN ID via CDP from the switch. 4. Phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address. 5. Phone contacts the TFTP server and requests the Certificate Trust List file (only if the cluster is secured). 6. Phone contacts the TFTP server and requests its SEP.cnf.xml configuration file. 7. If the SIP Phone has not been provisioned before boot time, the SIP Phone downloads the default configuration XMLDefault.cnf.xml file from the TFTP server. 8. The SIP phone requests a firmware upgrade (Load ID file), if one was specified in the configuration file. This process allows the phone to upgrade the firmware image automatically when required for a new version of CUCM. 9. Phone downloads the SIP dial rules configured for that phone. 10. Phone Establish connection with the primary CUCM and the TFTP server end to end. 11. Phone Registers with the primary CUCM server listed in its configuration file. 12. Phone downloads the appropriate localization files from TFTP. 13. Phone downloads the softkey configurations from TFTP. 14. Phone downloads custom ringtones (if any) from TFTP.

Answer 2

So far the focus has been on Skinny, the Skinny Client Control Protocol. Let's look at SIP now, because you could have your phones running this SIP firmware. The first few steps are the same. We have our Skinny Client Control Protocol and our SIP phones that need to gain access to that configuration file. So we are going through the power-on process, we're going through the fact that we need to download our configured file or we need to download the default file and then go through the process of resending information back to the Communications Manager which reconfigures the file. Now the phone sends it back with the appropriate MAC address, so we went through that process. Now, where we vary, is that the SIP phone tries to download a certificate trust list file, that's a CTL file. And it contains a set of certificates, so it's really from the security standpoint. And it's only used when the Communications Manager Cluster Security has been enabled, so if you didn't turn on security in your cluster then that step is skipped. Now your SIP phone again is going to request its config file from the TFTP server. If it's new, the file is not going to be found, so we are going to download the default file from the TFTP server then that file contains the system-wide config parameters, and we will now locate the Communications Manager for that SIP phone. Auto-registration kicks in, now the file contains the auto-registration name and then we go through the process of finding the Communications Manager and finishing the boot sequence, even though it still doesn't have a legitimate directory number and nothing has been configured yet. Now the SIP phone loads its load file. This is one that we specified in the default config file, so that default config file does contains some good information for your phones to boot up. So the SIP phone now attempts to obtain the new image at that point from the TFTP server, so hopefully at that point we've downloaded it so the SIP phone gets all of its information and now a connection is established with the Communications Manager server. Because within that file we have the IP address listed. After that the phone can register with the Communications Manager server with the highest priority. Again remember we can list three. So the first one we attempt to register with it and once that has happened then the SIP phone is going to need to get some information, it still doesn't have a directory number yet. So, we need to identify the special auto-registration name that's been used, and create an entry in the database for the new phone, so that we can generate the appropriate MAC address config file and now we accept that registration with an acknowledgement. We notify the phone to come get that new file and now the phone will automatically reset and reboot once it gets that file. Now the SIP phone will load the config file and it's now ready to go at that point, so it's quite a process that these phones go through, especially initially in order to get registered and get all of the pertinent information set up on the device so that it is ready now to make calls.

Answer 3

The file contains a list of CUCM server, in order, that the phone should register with. It lists the TCP ports it should use for SCCP communication. It also lists the firmware version for each device model and the service URLs that each device should be using. The CUCM server sends other configurations, such as DNs, softkeys, and speed dials, via SCCP messages in the last phase of the registration process. The configuration files for SIP phones are generally larger than the equivalent files for SCCP phones. This is because SIP phones have no equivalent mechanism for configuring items that are set by SCCP messages on SCCP phones; these items must be included in the configuration file downloaded from TFTP.

Answer 4

Now let's pretend that your IP phone is brand new, out of the box and you're plugging it in for the first time. What is the expected behaviour? It's going to take a little bit longer to boot up, it's going to go through several iterations, you will see it on screen. Because what has to happen is the IP phone is going to look for a specific file from the TFTP server, and that specific file contains the MAC address. But because we've got this brand spanking new phone that doesn't have a TFTP server file just yet, we have to download the XMLDefault.cnf.xml file. Now the IP phone obtains its list of Communications Managers, and it then attempts to auto-register to the primary server. And in that process that's where you're going to see things can slowdown, just a bit. Because it's going to try to register with the Communications Manager. It then has to create its unique file, because that unique file is going to be what we're going to leverage every time that phone reboots. And that's going to make things happen quicker too, but it's going to return information including the MAC address as part of that config file. So, the IP phone with this MAC address, downloads this configuration file that it now has, specific to that phone and it's going to contain the information for that IP phone to register with its Communications Manager. And again it's going to see IP addresses here. So these IP addresses will give them a direct connection back to the Communications Manager server that is going to be hosting that IP phone for you.

Answer 5

The Device Defaults page lists all the supported endpoints (with separate entries for SCCP and SIP as necessary), and the firmware load, device pool, and phone button template each endpoint uses by default. This allows an administrator to set useful system-wide defaults for any newly registered device of each type.

Answer 6

The softkey template controls what softkey button functions are available to the user; these are typically used for feature access (conference, transfer, park, Extension Mobility, and so on). Seven softkey templates are available by default, and you can create as many more as your design requires. The Phone Button template defines the behavior of the buttons to the right of the phone screen (for most models). Eighty (or more) are defined by default because there are unique templates for each supported phone type—and for most phones, a separate template for SCCP and SIP. The default templates typically provide two lines and as many speed dials as there are remaining buttons on a particular phone model; you can add and customize the templates to assign each button one of many different functions.

Answer 7

When you look at how you configure a phone in the Communications Manager, there's really two different areas. There's the actual device itself. That would include things like the calling search space it belongs to, AAR, all of your softkey templates and phone button templates, and what protocol it's using. Then there's the specific lines, so the directory numbers. The directory numbers may house different partitions and calling search spaces. They might have limitations on the maximum number of calls they can accept. There's an external phone number mask that we could associate with them. And we can associate these lines with one or more devices. So there's two different areas that we may need to configure on our IP phones.

Answer 8

When we get into the graphical user interface, the main administrative page of the Communications Manager, we have lots of options for our phones. We can set up those Date and Time groups, Presence capabilities, the Device Pool – we are going to love this because it's kind of a template that we can add to our phones – the Security Profile, the Softkey Templates, what our phone buttons look like, Common Phone Profiles, and then if we do have SIP Phone we'll go ahead and implement the needs of those SIP phones, under the SIP phones configuration. Here is list with some of the most important parameters: 1. Date/Time Group 2. Presence Group 3. Device Pool - Cisco Unified CM Group - Regions - Locations 4. Security Profile 5. Softkey Template 6. Phone Button Template 7. Common Phone Profile 8. SIP Phones - SIP Profile (SIP Phones Only) - Phone NTP Reference (SIP)

Answer 9

TFTP is a critical service for IP Phones. The Phone use TFTP to download their config files, firmware and other data. Without TFTP, the phones simply do not function properly. When you make a configuration change to a device, CUCM creates or modifies a config file for the device and uploads it to the TFTP server. TFTP service much therefore provided by one or more CUCM servers in the cluster. Note: A generic TFTP server will not have the integrated capability that a CUCM TFTP server does and will not correctly fulfill the role.

Answer 10

- Define the voice route path - POTS CALL LEGS - Matched Inbound and Outbound - VOIP CALL LEGS POTS DIAL-PEERS : traditional telephony connections, anything without an IP address (PORT) VOIP DIAL-PEERS : packet-based network connections (IP ADDRESSES)

Answer 11

. Indicates a single-digit placeholder. For example, 555…. matches any dialed string beginning with 555, plus at least four additional digits. [] Indicates a range of digits. A consecutive range indicated with a hyphen (-), or a nonconsecutive range with a comma (,). Hyphens and commas can be used in combination ie [5-7,9]. Note Only single-digit ranges are supported. ie [98-102] is invalid. () Indicates a pattern; for example, 408(555). It is used in conjunction with the symbol ?, %, or +. ? Indicates that the preceding digit occurred zero or one time. Enter ctrl-v before entering ? from your keyboard. % Indicates that the preceding digit occurred zero or more times. This functions the same as the “*” used in regular expression. + Indicates that the preceding digit occurred one or more times. T Indicates the interdigit timeout. The router pauses to collect additional dialed digits. Asterisk (*) and pound sign (#)--These characters on standard touch-tone dial pads can be used anywhere in the pattern. They can be used as the leading character (for example, *650), except on the Cisco 3600 series.Dollar sign ($)--Disables variable-length matching. It must be used at the end of the dial string.Circumflex symbol (^)--When used within brackets, allows you to eliminate a digit from considerationfor dial peer matching purposes. For example, a destination pattern including [^7] would not match any string beginning with 7.

Answer 12

With class of restriction, I like to equate it to having a lock and having a key ring with lots of keys on it. Because, we have an outgoing COR list, that's the lock, then we have an incoming COR list, this contains the keys to open the lock. So, the way it works is an outgoing COR list is actually a subset of your incoming COR list and if we match the call is routed. If the outgoing COR list is not a subset of the incoming COR list we're blocked.

Answer 13

CUCM - CUCME Partitions - Outgoing COR List = CADENAS Calling Search Spaces - Incoming COR list = KEYS

Answer 14

Partitions are a way that we can group together destinations with the same reachability. This means that I should put directory numbers, any route patterns, might even put translation patterns, voice mail ports, conferencing numbers - all of them would be associated within the same partition. So that's the way that we would group together all of these devices that have the same reachability but this is just half of the puzzle so we create the partitions and we also now need to add them to the Calling Search Space.

Answer 15

The Calling Search Space is the list of the accessible partitions. Once we have done that, we then apply it to a phone, a phone line, a gateway or even some applications. Now the device has to have a partition within that calling search space that allows them to reach a destination.

Answer 16

Calling Search Spaces have an order of partitions in them. There is a relevance to the order of the partitions that are listed and so what happens is we could have multiple identical entities that could exist in the call routing table. But in order to have this work they have to be in different partitions. That way you can again put those ordered partitions in there. One exception to the rule is your phone directory numbers. If two or more devices share the same directory number within the same partition then this particular directory number is a shared line and so you wouldn't have to have a separate partition for that. You actually couldn't have a separate partition for that and the way it works is we have best match is searched but if any equally qualified matches exist and we don't have any single best match then the order of the partition in the Calling Search Space of that device is the tie breaker because you have to list them one after another so whoever's first in that instance would be the choice that we would make.

Answer 17

By default, when you install the Communications Manager Solutions, you haven't got any partitions or Calling Search Spaces created, so basically there is a "None" partition and "None" Calling Search Space. Everybody is in it. Entities that have a Calling Search Space of none, can only access destinations that are in the partition of none. So in other words, if you want to restrict something, you could certainly set this up in this environment so that they now can't make any calls. One more thing - the partition "None" is a member of every Calling Search Space and it cannot be removed. Actually the "None" CSS and the "None" Partition cannot be edited. Why I'm telling you this - because if there is a device or end point in partition "None", it can be called directly from everyone!

Answer 18

A CM group defines a top-down ordered list of redundant call-processing servers to which the phones can register. The list can include a maximum of three servers (plus an optional Survivable Remote Site Telephony [SRST] reference). The first server in the list is the primary subscriber, the second is the backup, and the third is the tertiary. In normal operation, phones send primary registration messages to the primary, backup registration messages to the backup, and nothing to the tertiary. If the primary server fails or otherwise becomes unavailable, the phone sends a primary registration message to the backup server (and registers with it) and begins sending backup registration messages to the tertiary. The number of CM groups created depends on the number of subscribers in the cluster; the goal is to provide server redundancy to the phones while distributing phone registrations evenly as planned in the system design. A server may be listed in more than one CM group to provide an overlapping depth of coverage, as long as its performance capacity will not be exceeded in any foreseeable failure circumstance. This is simply another requirement of a good design.

Answer 19

As you just saw, we can select the appropriate bit rate for calls and, therefore, the bandwidth used by each call. Given that WAN bandwidth is assumed to be limited, we need to be able to limit the amount of bandwidth used by calls to a particular location. Location defines a maximum amount of bandwidth used by calls to a particular location; each call is tracked, and the bandwidth it uses is deducted from the total for that location. When the bandwidth remaining is not enough to support another call at a given bit rate, that call is dropped by default (but may be rerouted over the PSTN if AAR is correctly configured). This is one mechanism for Call Admission Control (CAC)

Answer 20

For Call Admission Control to work, there are two areas that we need to configure. One of them is Locations and the other is Regions. They kind of go in hand-in-hand to get this set up. Locations are assigned to each device. Every device has an identity as to where they're located. The next thing is calls are limited in and out of that location by permitting a certain bandwidth amount for those calls. Now here's the only "gotcha" with locations. Locations is topologically unaware. What does that mean to you and I? What that means is it's a hub-and-spoke topology. So in other words if I have a centralized location and I have all these branch offices, the centralized location is the hub. The branches are the spoke. There is nothing saying between those branch locations, how much bandwidth is available. You might want to use some other Call Admission Control mechanism if you have multiple branch locations and you can't handle this topology this way. You could even use RSVP, that is another Call Admission Control/quality of service mechanism that you could use to manage the amount of bandwidth between branch offices. But if it's okay that we go from the corporate to the branch locations, then locations will work just fine.

Answer 21

Region: A region is a virtual assignment that allows the system designer to control the bit rate for calls. For example, if we define two regions, called Vancouver_HQ_REG and Ottawa_BR_REG, we can set the bit rate for calls within the Vancouver region to 256 kbps, within the Ottawa region to 64 kbps, and between the two regions to 16 kbps. We are in effect selecting (or at least influencing) the codec to be used for these calls; the codec in turn generates a known bit rate, which in turn uses a predictable amount of bandwidth and provides a predictable voice quality. In general, it is assumed that WAN bandwidth is limited; selecting a lower bit rate reduces the amount of bandwidth per call at the expense of call quality.

Answer 22

Here's an example of defining our regions. Let's say that we are headquarters and within the headquarters we're going to speak G.711, I call it, but to branch one and two we are going to use G.729. Now again remember this is the highest amount of bandwidth really – that's what this is specifying it doesn't necessarily mean we have to speak G.729, but we can't go above that 20 kilobit per second payload option here. And you can see between branch one and headquarters and the branch two, you know, they vary. HQ - Branch1 - Branch2 HQ : G.711 - G.729 - G.729 Branch1 : G.729 - G.711 - G.729 Branch2 : G.729 - G.729 - G.711 So, this is a way that we can influence the codec that's going to be chosen for these locations. Now remember if we chose something like G.729 for example, that does compression, it's designed for human speech. I would not want to hear you auditioning for Music Idol across a G.729 link, it isn't going to sound that good, nor is music on hold. Music On Hold kind of gets destroyed, it sounds horrible. It's funny I always know when I'm on hold and someone has made that mistake in their network and I hear this music and I'm like, oh my gosh, they must be using G.729 to stream this out, because it sounds so horrible. Also be careful because faxes can be destroyed as they are transmitted across G.729. Fax machines and the fax transmission rates do not do well when they're attempted to be compressed, so we want to find an alternate way of sending that across. A lot of times we say if you are a fax and we recognize you, just use G.711, so we don't do any audio compression or attempt to do that on that poor fax trying to make it across.

Answer 23

As discussed earlier, it is recommended to use NTP for time synchronization of all devices. The problem is that NTP references Greenwich mean time, which makes the time displayed on devices “wrong” if they are not in the GMT time zone. Date/time groups allow us to offset the correct time learned via NTP to match the local time zone of the device. Date/Time Groups also allow us to display the time and date in the desired format, which can vary from place to place.

Answer 24

SIP phones need an NTP server address from which they can obtain the time using NTP. (This is not required for SCCP phones, which are configured to the correct time using SCCP signaling.) It is preferred that the NTP reference be local to the phones that need it.

Answer 25

Depending upon our deployment we have different types of Call Admission Control that are supported. In a centralized call processing deployment we talked about locations and how locations and regions go hand-in-hand. And then there's an RSVP-enabled location. With RSVP-enabled locations this is where we can actually make a reservation for the amount of bandwidth that is necessary to complete a call or a video call if necessary. In a distributed call processing deployment we are going to use H.323 gatekeepers. Now I haven't really talked much about gatekeepers yet in this course, but gatekeepers are a way that we can use a centralized router to control and to be the directory in a distributed solution. So in other words all the other gateways that we have set up in our topology that are distributed all over the place, they would point to this gatekeeper and the gatekeeper would know, "Oh that gateway knows about the 2000 through 2999 extensions and that gateway over there knows about the 8000 extensions...", so this gatekeeper would keep information about how to route calls, as well as how much bandwidth is available. So now the gatekeeper kind of keeps a tally and as phone calls are placed to a particular location it keeps track of how much bandwidth is being utilized and of course when somebody hangs up that bandwidth goes back into the pool. So in a distributed solution that H.323 gatekeeper provides that Call Admission Control functionality.

Answer 26

TRANSLATION PROFILE = showing person's name in place of extension number when someone is calling outside the company CALL PARTY TRANSFORMATION = Allows to deviate a 911 call to the emergency Phone number of the company

Answer 27

Shared Lines - Commonly used for hotline features. For example, use a second directory number as a shared line for the IT hotline. Barge and cBarge - Join an active call on a shared line. Call Pickup Groups - Pick up calls from a specific directory number; for example, to set up a Sales pickup group. Call Park and Directed Call Park - Pick an active call in a previously configured call park directory number range and allow users to pick up the call from other phones. Hunt Groups - Provides basic ACD functionality.

Answer 28

To setup shared line appearances it's fairly easy. We go into the IP phone and we give the same Directory Number to multiple devices that have the same line appearance, so now we have the ability to all hear that call ringing in and then whoever takes it first they now get that incoming call. There's only one little 'gotcha', if the same Directory Number is configured in different Route Partitions then the Directory Numbers are not shared.

Answer 29

Now with shared lines we may want to look at Barge and CBarge. In order to do this we go into the Service Parameters and we look at the Builtin Bridge Enable service parameter and we can activate that. That will really kind of turn on a phone bridge for barge. We also have Privacy Settings and they're activated by default. So kind of easy if you want to make it that way for somebody to come into another call and maybe help the person out or maybe takeover that call without transferring it or putting that caller on hold.

Answer 30

Now to add barge capabilities we need to add a softkey. So we'll go out to our softkey templates and we will add "Remote In Use" in all the different call states and we can add Barge and cBarge to that softkey template and of course when we're finished press Save, but remember as you go through the different call states you need to Save each one of those call states.

Answer 31

Once we've setup our softkey template if we want to allow our users to use barge or cBarge then we need to add that softkey template to our device or the Device Profile. Once we've done that we can also look at some of the built-in barge parameters and privacy parameters if we select Default that's what we have set in our Service Parameters and if we want to override that we can certainly do so. So in other words none of these calls are going to be private. No, we can go in on a case-by-case basis to the individual phone and set what those policies should be so we can override in other words what the system-wide defaults are.

Answer 32

When it comes to setting up Group Pickup generally we get into Call Routing and the Call Pickup Group configuration. We give the group a name and then we setup what the number is. So what's the number that you might have to dial to pickup a call from this group. And then we can say how the Call Pickup Group is notified. Is it an alert, is it an audible tone, a visual signal on the phone? We can also go in and specify the intercom parameters and then finally if we want to associate this group with other groups, we can select any other groups that have already been configured and add them to the list.

Answer 33

We need to setup a softkey template to allow the pickup options to take place. So we set in the on-hook and off-hook call states the different ways that we want to have users pickup a call. Is it Pickup, is it Group Pickup or oPickup, you want to add the appropriate buttons and then go ahead and apply that and make sure that we go back and then make that phone have that softkey template that we've made the changes to. And it is possible at that point that you may need to have that phone reset in order to grab the new softkey template configuration so that it now contains these Group Pickup options.

Answer 34

We'll need to assign a Directory Number to our pickup group environment so we'll add the desired Directory Number to the Call Pickup Group. We will set what the notification is, the audible alert settings for that group, and when we have audio alert settings they use the system default and we can go into the Service Parameter and modify that. So we have some options, we can say ring once or hear nothing or beeping; so we can choose that as a System Parameter and then we can have that be the default if we want to for our Pickup option.

Answer 35

To setup our Call Park or Directed Call Park we can configure a range. So we can say 101X for example that would give us a range from 1010 to 1019 for parking spots. We then need to look at the timers. There's some timers - by default, the information clears off the screen of the person who parked the call and then after 60 seconds if nobody retrieved the call it will ring back to the person who parked it so that you know, "Oh hey, nobody picked up that call. Let me take a message or send it off to voicemail." Directed Call Park is a little bit different because Directed Call Park doesn't use a softkey, we use the transfer softkey to direct the caller to a Directed Call Park number. Here's an example - let's say my parking number is 3030, so we would hit the Directed Park softkey and dial my number and now all you have to do is say you know, "Michele you have a call, Michele pick up your parking spot, Michele," you know so we don't have to announce the number in other words. Sometimes you like to do that in the environment, sometimes it makes it a little more secure and less information going out overhead through your intercom system.

Answer 36

Let's break each entity down now. The Hunt Pilot Number: This is the number that is going to be dialled and it's actually going to start the hunting process, so it's the main number. We can perform digit manipulation here, we can point directly to a Hunt List, so we don't have to go through the whole hierarchy, but I highly advise it, especially if you think things are going to change. It's much easier if you go through the whole approach than you do the shortcut, but you could point directly to the Hunt List.

Answer 37

Our Hunt Lists are a prioritized list of those Line Groups. Now we could have multiple Hunt Pilots pointing to us, we could have multiple Hunt Lists within the same line group and at this point we do not perform any digit manipulation that should've already taken place. Hunt Lists We're now kind of like a pointer in the Hunt List area. We're actually pointing to things and receiving things, so we're kind of that go between.

Answer 38

•Top Down—If you choose this distribution algorithm, Cisco Unified CM distributes a call to idle or available members starting from the first idle or available member of a line group to the last idle or available member. •Circular—If you choose this distribution algorithm, Cisco Unified CM distributes a call to idle or available members starting from the (n+1)th member of a route group, where the nth member is the next sequential member in the list who is either idle or busy but not "down." If the nth member is the last member of a route group, Cisco Unified CM distributes a call starting from the top of the route group. •Longest Idle Time—If you choose this distribution algorithm, Cisco Unified CM only distributes a call to idle members, starting from the longest idle member to the least idle member of a line group. •Broadcast—If you choose this distribution algorithm, Cisco Unified CM distributes a call to all idle or available members of a line group simultaneously. See the Note in the description of the Selected DN/Route Partition field for additional limitations in using the Broadcast distribution algorithm. The default value specifies Longest Idle Time

Answer 39

The Line Group is containing the people - the answering positions. This could be an IP phone extension or it could be a voicemail port. The same extension could be contained in multiple Line Groups and there is also a Ring No Answer Reversion. This is a time out value that specifies how long we're going to attempt to the ring a member of that Line Group, because again our goal here is not to let people just go on indefinitely. And we also want to put in a reasonable amount of time for the phone to ring, in case I stepped out for a second, then I hear my phone ring and I can run back and grab it, so I want to give people enough time to answer that call and then of course we also want it to attempt to move on if nobody does answer.

Answer 40

- Enabled via CallManager service parameters. Under System -> Service Parameters Select a server from the drop down box and then select the CallManager service Set the ‘CDR Enabled Flag’ to True - Needs to be enabled per server basis. - The default value specifies False

Answer 41

- Enabled via CallManager service parameters Under System -> Service Parameters Select a server from the drop down box and then select the CallManager service Set the ‘Call Diagnostics Enabled’ parameter to either: Enabled Only When CDR Enabled Flag is True (generate CMRs only when the CDR Enabled Flag service parameter is set to True). ---- or ---- Enabled Regardless of CDR Enabled Flag (generates CMRs without regard to the setting in the CDR Enabled Flag service parameter). - This is a clusterwide parameter. - The default value specifies Disabled.

Answer 42

With voice mail, we could setup a situation were we can send out kind of a broadcast message to everybody, it is a recorded version of it. With our Presence capabilities and our IPPM broadcast and response message, basically we do this, but we are doing this in text format. Here the end users can configure a message and send it out to everybody that they are allowed to. We can setup settings that allow users to create a message that can go out and we can control who that goes to, it is a maximum of 150 characters and that can be sent to some or all contacts in the contact lists. We're kind of controlling the situation here, not allowing them to, send it to everybody unless they are a responsible party and they are allowed to do that. And end users can then create a personal response message to avoid typing a text message each time they want to send a message. So, users can create up to 15 personal responses and the system Administrator can create an additional 10 predefined messages that they can then use to respond to any message.

Answer 43

Also, we have to have a tool that lets us script the auto attendant functionality and the call queuing functionality and it's called the Toolkit for Command Language or TCL script, we call it for short. Now these TCL scripts allow us to create the scripting in the flash memory of your router, so we're able to set up that call queuing, which allows calls to be placed into a queue in the order of their arrival. I'm sure you've been through this before where it tells you, "welcome to our company, if you know your party's extension dial it now", you finally get there and now it tells you that maybe it's busy right now and you're going to be holding in this queue and it even might give you a time, your call should be handled in the next five minutes or you're the next caller in the queue. That type of information is handled by the call queuing function. The Auto-Attendant function is the fact that I heard the main greeting and I was able to self navigate to the area that I need help with either placing an order or getting technical support. So, we do have this nice basic Automatic Call Distribution functionality with our Communications Manager Express if we need it.

Answer 44

There are four different types of hunt groups. Each type uses a different strategy to determine the first number that rings for successive calls to the pilot number, as described below. - Sequential Hunt Groups—Numbers always ring in the left-to-right order in which they are listed when the hunt group is defined. The first number in the list is always the first number to be tried when the pilot number is called. Maximum number of hops is not a configurable parameter for sequential hunt groups. - Peer Hunt Groups—The first number to ring is the number to the right of the directory number that was the last to ring when the pilot number was last called. Ringing proceeds in a circular manner, left to right, for the number of hops specified in the hunt group configuration. - Longest-Idle Hunt Groups—Calls go first to the number that has been idle the longest for the number of hops specified when the hunt group was defined. The longest-idle time is determined from the last time that a phone registered, reregistered, or went on-hook. - Parallel Hunt Groups (Call Blast)—Calls ring all numbers in the hunt group simultaneously.

Answer 45

The Bulk Administration Tool (BAT) enables administrators to perform database inserts, modifications, or deletions in bulk. This makes it feasible to add a great many phones, users, or other elements more quickly and with fewer errors; it also allows the administrator to schedule the operation to happen automatically and unattended. The BAT Export feature enables the administrator to pull selected records from the database and export them. The administrator can then modify the records and re-import them into the database, making bulk changes faster and more accurate. BAT can be used to add, modify, or delete almost any component in CUCM, including phones, users, forced authorization codes and client matter codes, user device profiles, the region matrix, gateway devices, and many others. The components of BAT include an Excel template that provides the required fields and formatting for the new unique data server-side templates that configure the common data and a set of web page interfaces for preparing and executing the many operations that BAT supports. The Excel template is downloaded from the CUCM server. The administrator then customizes the templates for the needs of this BAT operation, populates the required fields with the correct data, and uploads the resulting CSV file to the server.

Answer 46

Profiles allow for a one-time configuration of repetitive tasks; several types of profiles exist, and you can create many versions of each type to be applied to phones as needed.

Answer 47

A default phone security profile exists for each type of phone/protocol. These default profiles have security disabled; you can choose to configure the device as secured, set encrypted TFTP configuration files, and modify Certificate Authority Proxy settings.

Answer 48

The common phone profile includes settings that control the behavior of the phone, including the following: ``` DND settings (Do Not Disturb) Phone personalization capabilities VPN settings USB port behavior Video capabilities Power-save options ```

Answer 49

Phones can be added to CUCM in several ways: - Manual configuration: The administrator creates a new phone, configuring all settings in real time on the Phone Configuration page. - Auto-registration: The administrator configures CUCM to dynamically configure and add to the database any new IP phone that connects to the network. - Bulk Administration Tool (BAT): Using templates configured for the purpose by the administrator in CUCM, the administrator creates CSV files that contain all the required information to create multiple phones in one operation. - Auto Register Phone Tool (TAPS): An Interactive Voice Response (IVR) server enhances the auto-register and BAT functionality, providing an automated method of adding potentially thousands of phones at a time. A more sophisticated (but much more complex) strategy involves the use of the Auto Register Phone Tool (formerly known as the Tool for Auto Registered Phone Support, but which is still known as TAPS because it is a better acronym than ARPT). TAPS goes one step further in the automation of new IP phone deployments. This is a powerful way to deploy thousands of IP phones. With some minor tweaks and some training of the users, it requires minimal administrator involvement in the phone deployment. The downside is that it requires the IP-IVR hardware and software and a capable administrator to configure it and still involves either training users to set up their own phones or using administrators to perform repetitive simple tasks, which are not cost-effective uses of their time. - Self-provisioning: Operating in a manner similar to TAPS, self-provisioning is a new capability for CUCM 10.x. The IVR and CTI capabilities are now integral to the CUCM application, and no external server is required. Self-provisioning is conceptually almost exactly the same as TAPS, with the very significant difference being that all of the IVR capability has been integrated into the CUCM application. This means that we no longer need to go to the trouble and expense of building and configuring an external IVR; we just configure CM to do it for us. Self-provisioning utilizes UDTs and ULTs, giving us even better customization with much less effort because we can leverage the variables definitions in the Universal Device Template and Universal Line Template.

Answer 50

The credential policy defines preset passwords, end-user PINs, and application-user passwords. The default credential policy applies the application password specified at install to all application users. Administrators can define additional policies that can specify the allowed number of failed login attempts, minimum password length, minimum time between password changes, number of previous passwords stored, and the lifetime of the password. The policy can also check for weak passwords. A strong password - Contains three of the four characteristics: uppercase, lowercase, numbers, and symbols - Cannot use the same number or character more than three times consecutively - Cannot include the alias, username, or extension - Cannot include consecutive numbers or characters Similar rules exist for phone PINs: - Cannot use any number more than two times consecutively - Cannot include the user mailbox or extension, nor the reverse of them - Must contain at least three different numbers (for example, 121212 is invalid) - Cannot be the dial-by-name version of the user name (such as Mike = 6453) - Cannot contain repeated digit patterns, nor any patterns that are dialed in a straight line on the phone keypad (for example, 2580 or 357)

Answer 51

The following features use the end-user account login process, with either the username/password or PIN as the authentication: - Unified CM Administration web pages - User web pages (Self-Care Portal) - Serviceability - OS administration - Disaster recovery system - Cisco Extension Mobility - Cisco Unified Communications Manager Assistant - Directories - IP phone services - Data associated with user accounts User account information is divided into three categories, with fields for specific data in each category: 1. Personal and Organizational Settings: - UserID - First, Middle, Last Name - Manager UserID - Department - Phone Number, Mail ID 2. Password Information: Password 3. CUCM Configuration Settings: - PIN - SIP Digest Credentials - User Groups and Roles - Associated PCs, controlled devices, and DNs - Application and feature parameters (Extension Mobility, Presence Group, CAPF)

Answer 52

CUCM makes a clear distinction between end users and application users. The distinction is simple: End Users are typically people who type a username and password into a login screen (usually a web page) to access features or controls. An application user is typically an application that sends authentication information inline with a request to read or write information to a system (perhaps a third-party billing application accessing the CDR/CAR database, for example).

Answer 53

User locales allow different languages to be displayed on the IP phone and the user web pages. Additional locales are installed on the CUCM server; then specific locale files are downloaded to the phone via TFTP. This allows for the customization of the primary interfaces for users in a wide range of available locales/languages.

Answer 54

For users to be able to control their own devices (using the Self-Care Portal to up their own speed dials, services, and ring preferences, for example), the end-user account must be associated with the device. In CUCM, end users can be associated with IP phones, Cisco IP Communicator (CIPC), and Cisco Extension Mobility profiles. Because the end-user account must have a unique user attribute name in the CUCM database, it is possible to dial a user by name. Cisco Unified Presence Server (CUPS) tracks the availability status of a user and his communication capabilities (such as voice, video, and chat).

Answer 55

End users can be added to the CUCM database via three main methods: 1. Manual, one-at-a-time entry 2. Bulk import using the Bulk Administration Tool 3. LDAP synchronization (and optional authentication)

Answer 56

The CUCM database includes fields for comprehensive user information. Only some of these fields are required, including the following: - User ID - Last Name - Presence Group (defaults to Shared Presence Group) - Remote Destination Limit (defaults to 4) Given that the last two required fields are populated by default, it is clear that CUCM does not require much information to create a new user. The user ID must be unique, which implies that you should have a naming convention that accommodates many users with similar names. There are many optional fields on the End User Configuration page, including Password, PIN, First Name, Telephone Number, and Device Association. The more users you have, the more likely it is that these optional fields will be populated to implement features, improve searching and reporting, or improve security.

Answer 57

Instead of adding potentially hundreds or thousands of users one at a time, the administrator can add users in bulk using the Bulk Administration Tool. BAT allows the administrator to create and upload a CSV file with all the users’ information populated and insert the data into the database in an automated way. BAT is a fast way to add, remove, or modify database entries for many fields in the CUCM database.

Answer 58

CUCM supports integration with Lightweight Directory Access Protocol (LDAP). LDAP is a standards-based system that allows an organization to create a single, centralized directory information store. LDAP holds information about user accounts, passwords, and user privileges. The information centralized in LDAP is available to other applications, so that separate directories do not need to be maintained for each application. Using LDAP simplifies user administration, and makes using systems slightly easier for users because they only need to maintain their information and passwords in one place. NOTE : Only end users are replicated by LDAP sync. Application users are always and only maintained as local entries in the CUCM database. CUCM supports LDAP integration with several widely used LDAP systems, including the following: - Microsoft Active Directory 2000, 2003 and 2008 (support for AD 2012 only in CUCM 10.x and later) - Microsoft Active Directory Application Mode 2003 - Microsoft Lightweight Directory Services 2008 - iPlanet Directory Server 5.1 - Sun ONE Directory Server (5.2, 6.x) - Open LDAP (2.3.39, 2.4) CUCM can interact with LDAP in two ways: LDAP Synchronization populates the CUCM database with user attributes from LDAP, and (as an optional additional configuration) LDAP authentication redirects password authentication to the LDAP system. Typically, synchronization and authentication are enabled together. In either case, some information that now comes from LDAP is no longer configurable in CUCM; the fields actually become read-only in CUCM, because the information can only be edited in LDAP.

Answer 59

Implementing LDAP synchronization (LDAP sync) means that some user data (but not all) for LDAP-sourced end user accounts is maintained in LDAP and replicated to the CUCM database. When LDAP sync is enabled, LDAP-sourced user accounts must be created and maintained in LDAP and cannot be created or deleted in CUCM; the user attributes that LDAP holds become read-only in CUCM. However, some user attributes are not held in LDAP and are still configured in CUCM because those attributes exist only in the CUCM database. As of CUCM v9.x, local CUCM user accounts can coexist with LDAP-sourced accounts; in this case, CUCM maintains read-write access to all the attributes of local accounts, but LDAP-sourced accounts still have attributes that are read-only in CUCM and which must be managed in the LDAP system. It is important to understand that when using LDAP sync without LDAP authentication, the user passwords are still managed in the CUCM database. This means that, although a user account in LDAP is replicated to the CUCM database, the user password must be maintained separately in both the LDAP system and in CUCM. CUCM uses the DirSync service to perform LDAP sync. The synchronization can be configured to run just once, on demand, or on a regular schedule. The choice depends on the system environment and the frequency of changes to LDAP content; the need for up-to-date information must be balanced against the load on the servers and network if the sync is frequent or takes place during busy times. NOTE : If LDAP authentication is enabled and LDAP fails or is inaccessible, only local end-user accounts will be able to log in to the CUCM (in addition to any application user accounts including the primary Administrator account defined at install). This may cause drastic unified communications service interruption, depending on how users normally interact with the system. Of course, if LDAP has failed, it is likely to be a serious issue already, causing many applications to cease functioning.

Answer 60

LDAP authentication redirects password authentication requests from CUCM to the LDAP system. End-user account passwords are maintained in the LDAP system and are not configured, stored, or replicated to CUCM. Because one of the benefits (particularly to the end user) of LDAP is a centralized password system (making single sign-on possible), it is typical and desirable to implement LDAP authentication with LDAP sync.

Answer 61

A common misconception regarding CUCM LDAP integration is that all user data resides in LDAP. This is absolutely false. With LDAP sync, certain LDAP user attributes are held in the LDAP directory and are replicated to the CUCM database as read-only attributes. The balance of the user attributes in the CUCM database (fields such as associated devices, PINs, Extension Mobility profile, and so on) are still held and managed only in the CUCM database. There is a similar misconception with LDAP authentication: Remember that the LDAP password is not replicated to the CUCM database; rather, the authentication process is redirected to the LDAP system. When an LDAP authentication-enabled user logs in to CUCM, the username and password are sent to the LDAP system (the password in sent as an MD5 hash). The LDAP system compares the submitted hash with its own hash of the correct password, and if they match, then the LDAP system indicates to the CUCM that the user is successfully authenticated (and, obviously, if the hashes do not match, the authentication fails). The interaction of CUCM with LDAP varies with the type of LDAP implementation. The primary concern is how much data is replicated with each synchronization event. For example, Microsoft Active Directory performs a full sync of all records contained in the configuration every time; this can mean a very large amount of data is being synchronized, potentially causing network congestion and server performance issues. For this reason, sync intervals and scheduling should be carefully considered to minimize the performance impact. Synchronization with all other supported LDAP systems is incremental (for example, only the new or changed information is replicated), which typically greatly reduces the amount of data being replicated, thereby reducing the impact on the network and servers.

Answer 62

The user attribute field names that LDAP uses are most likely different from the equivalent attribute field names in the CUCM database. Therefore, the various LDAP attributes must be mapped to the appropriate CUCM database attribute. Creating an LDAP sync agreement involves identifying the one LDAP user attribute that will map to the CUCM user ID attribute. In a Microsoft Active Directory integration, for example, the LDAP attribute that will become the CUCM user ID can be any one of the following: - sAMAccountName - uid - mail - TelephoneNumber It does not matter which one is chosen, but for consistency and ease of use, the attribute that the users are already using to log in to other applications should be used. After the initial user ID mapping is selected, some other LDAP attributes should be manually mapped to CUCM database fields. Table 9-3 lists the fields in the CUCM database that map to the possible equivalent attribute in each type of supported LDAP database.

Answer 63

Keep these points in mind when planning and implementing an LDAP sync: - The data in the LDAP attribute that is mapped to the CUCM User ID field must be unique in the LDAP (and therefore CUCM) database. Some LDAP fields allow duplicate entries, but the CUCM user ID must be unique, so it is necessary to verify that the LDAP data is unique before the sync agreement is built. - The sn attribute (surname/last name) in LDAP must be populated with data; otherwise, the record will not be replicated to CUCM. - If the LDAP attribute that maps to the CUCM user ID attribute contains the same data as an existing application user in CUCM, that entry is skipped and not imported into the CUCM database.

Answer 64

An LDAP sync agreement defines what part of the LDAP directory will be searched for user accounts. Many LDAP systems have a highly organized structure, with different containers for different functions, departments, locations, or privileges. The synchronization agreement specifies at which point in the tree the search for user accounts will begin. CUCM has access to the container specified in the agreement, and all levels below that in the tree; it cannot search higher up the tree than the start point, nor can it search across to other branches in the tree that must be accessed by going higher than the starting point then back down. The agreement can specify the root of the domain, but although this is a simple agreement to create, it causes the entire LDAP structure to be searched, which may return unwanted accounts or simply too many accounts. CUCM can integrate with only one LDAP system, but within that system version 10.x can support up to 20 synchronization agreements. The total number of LDAP-sourced user accounts should not exceed 160,000. To be more precise - If the number of users is less than 80,000, up to 20 sync agreements are possible. - If the number of users is greater than 80,000 (to the maximum recommended 160,000), the number of sync agreements supported is 10.

Answer 65

The simplest way to verify that LDAP sync is working is to do a quick search of the end users on the CUCM. In the column under LDAP Sync Status, the LDAP-sourced users’ status will be listed as Active LDAP Synchronized User. Users that are locally maintained in the CUCM database will be listed as Enabled Local User. When you open the configuration page for an LDAP-synced user, you see that the User ID, Last Name, Middle Name, First Name, Telephone Number, Mail ID, Manager User ID, Department and a few other fields are not editable; this is because they are synced with LDAP and can only be edited in the LDAP system.

Answer 66

Verifying LDAP authentication can be achieved by opening a user configuration page and observing that the Password field is gone; this is because the password is maintained in LDAP, not locally in the CUCM database. A user can test the LDAP authentication by changing her password in LDAP and observing that CUCM requires the new password to log in. Note that the user PIN is always locally maintained in the CUCM database, as are all the other CUCM-specific attributes.