CCIE Voice Study

Restoring a CUE module back to factory defaults isn't as easy as simply erasing startup-configuration and reloading. You need to take CUE offline, then explicitly perform a factory reset. The "erase startup-configuration" command only, from what I can tell, removes specific system configuration parameters (NTP is one setting that is removed); users, mailboxes and administrator credentials are only removed through factory default. Factory default also allows the initialization wizard to be run upon reload.

se-192-168-255-98.localdomain# offline
!!!WARNING!!!: If you are going offline to do a backup, it is recommended
that you save the current running configuration using the 'write' command,
prior to going to the offline ...

Click here to read the whole article

Dynamic Hunt Groups are a fantastic concept in CME that allow members of the telephone system to interactively join a hunt-group. To setup a dynamic hunt-group:

1. Define at least one member of a hunt-group with a wildcard (*)
2. Individually permit each ephone-dn that should be allowed to interactively join the hunt-group
3. Configure the system to allow feature access codes

The following configuration allows 2 x locally configured numbers to interactively join a hunt-group on the system using the standard FAC codes: *3 to join the group, and #3 to leave.

!
ephone-dn 1
  number 1000
  ephone-hunt login
!
ephone-dn 2
  number 1001
  ephone-hunt login
!

Click here to read the whole article

The Cisco literature has a lot of information about best practice for enabling the CME GUI (like enabling AAA). While all good, the following is an absolute bare minimum in getting the CME GUI up and running.

1. Download the CME GUI files for 7.0.1 from here http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp (you will need a valid service contract). Ensure you download the right GUI version, or you may have strange results.
2. FTP or TFTP the files to the CME router, and extract the tar ball
3. Enable the HTTP server on the CME router
4. Define a web administrator under telephony-service
5. Access the CME GUI at http://your-ip-address/ccme.html

The following configuration provides ...

Click here to read the whole article

The minimum configuration to enable the CUE module for use by your IP phones involves:

• configuring IP addressing on the service-engine; and
• if you are using IP unnumbered (as is often the case), configuring a static IP route so that the Cisco CME router can route traffic towards the CUE module.

The static route installation is the bit I almost always fail to remember!

!
interface Service-Engine1/0
 ip unnumbered GigabitEthernet0/0
 service-module ip address 192.168.255.98 255.255.255.0
 service-module ip default-gateway 192.168.255.99
!
ip route 192.168.255.98 255.255.255.255 service-Engine 1/0
!

Once the configuration has been applied, you can session to the service module from the locally ...

Click here to read the whole article

The default in Cisco CME is to permit auto registration - this allows ephones to automatically register wih the CME router. While this might make initial configuration simple, it presents both a security risk and a lack of control for the configuring engineer.

Auto registration can be disabled through the explicit prevention of auto registration under telephony service:

telephony service
  no auto-reg-ephone

To verify attempted (and failed) registrations, the IOS command "show ephone attempted-registrations" can be used:

CME_ROUTER#sh ephone attempted-registrations
Attempting Mac address:
Num Mac Address DateTime DeviceType
-----------------------------------------------------------------------------

Click here to read the whole article

Since multicast is used for the streaming of MoH locally (for on-net calls) from the Cisco CME device, we can use both telephony troubleshooting and IP multicast troubleshooting commands to verify and troubleshoot MoH. Firstly, observe the behaviour of multicast group 239.0.0.1 below.

The following output of "show ip mroute" is from a steady-state - there are no calls currently on hold. Observe that group 239.0.0.1 specifies Gig0/0 as an outgoing interface, however traffic is pruned, and will therefore not be sent until an IGMP request is received downstream.

CME_ROUTER#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,

Click here to read the whole article

The multicast MoH command under telephony service can be a cause for confusion. This command forces the Cisco CME device to generate multicast Music on Hold on the interfaces specified after the "route" argument.

The route argument is only required if the SCCP address bound under telephony service is different to the interface outbound towards the IP phones. This would be common, for example, if a loopback interface is used instead of the physical Ethernet interface.

When the outbound interface is also the SCCP source IP address:

telephony-service
  multicast moh 239.0.0.1 port 16834

When a loopback interface is used as the SCCP source IP address (for example, L0 = 172.16.1.1 and GigabitEthernet0/0 = 192.168.1.1):

telephony-service

Click here to read the whole article

In CME, by default when 2 x on-net callers dial one another and one party initiates a hold, the party holding will not receive music on hold. This can be resolved by using Multicast Music on Hold. When using Multicast MoH, the CME router will transmit the audio stream on the physical IP interfaces of the specified router. Under the multicast command (in telephony-service), if the SCCP bound address under telephony-service is not the physical interface (for example, if a loopback is used), the outbound interface towards the IP phones must be specified. If they are not on the next directed subnet, multicast routing must be enabled and PIM dense or sparse mode.

telephony-services
  moh music-on-hold.au
  multicast moh 239.1.1.10 port 16384 ...

Click here to read the whole article

The following provides a guideline to enabling basic hardware conferencing in CME. There are additional options that can be tweaked, however the following is enough to get you off the ground. This will create the DSP farm and associate to the CME device for usage. Then, you'll need to create the ephone-dn's for meet-me and ad hoc conferencing. In the example below, a single ad hoc conference is configured for illustrative purposes.

1. Prepare the DSP farm and services on the voice-card
2. Configure SCCP parameters for the related application (in this instance, conferencing)
3. Create the SCCP group and define the associate parameters, such as registration ID
4. Create the dspfarm profile group for conferencing
5. Enable the Skinny Client Control Protocol (SCCP)
6. Under ...

   Click here to read the whole article

The minimum elements required to enable a phone to register with a Cisco Unified Communications Manager Express (CME) device are as follows:

1. Configure basic IP addressing and ensure routing between Phone subnet(s) and CME source IP address (ideally a loopback)
2. Configure a valid time source on the router, or setup the router as an NTP master (stratum doesn't matter)
3. Initialize CME using the command 'telephony-service'
4. Configure a valid source-address under telephony service. I recommend using a loopback address, for the same reason you'd use a loopback as the router ID for a routing protocol (virtual loopback addresses are not reliant on environmental conditions).
5. Create CNF files under telephony-service
6. Configure a maximum number of ephones ...

   Click here to read the whole article

Under System => Enterprise Parameters, change the service URL to use IP address (if not using DNS - which is unlikely in the lab, unless the router is providing DNS functions!). Otherwise the phone displays a Host Not Found error. Ensure that a phone is subscribed to at least one service, or pressing services returns a no services configured error.

Click here to read the whole article

When DN ranges overlap between sites, numbers can be prefixed with a site code using translation patterns. i.e., lets say Site A uses 1XXX and Site B also uses 1XXX. To allow both sites to be members of the same CUCM cluster, the following steps can be taken:

1. Create 2 x new partitions for each set of numbers; i.e. Site A and Site B
2. Place the DNs for each site into its own local partition
3. Assign the appropriate CSS to either the line or the phone. Ensure that the Partition for Site B does not exist in the CSS for Site A, and vice-versa
4. Create a translation pattern in each Partition to allow inter-site calling

The translation pattern must have the following characteristics:

• [Site-Code].[Range] i.e. 91.XXXX
• Set with a CSS of the target ...

  Click here to read the whole article and view images

To enable DND visual display for BLF assigned to speed-dials, specify True for BLF Status Depicts DND (CallManager Service Parameters, System - Presence group). This applies both to line appearances and directory listings (if BLF on call lists is configured). The default configuration is that BLF does not display DND status.

Click here to read the whole article and view images

When the privacy button is configured with a phone enabled for privacy, shared line privacy can be interactively enabled or disabled by the user. When the phone has privacy disabled, this button has no effect.

Click here to read the whole article

1. Create a Partition (Call Routing > Class of Control > Partition). Name the partition something like PT-PLAR-DN#)
2. Create a Calling Search Space (Call Routing > Class of Control > CSS). Add the partition created in step # 1
3. Create a translation pattern (Call Routing > Translation Pattern).
   • Translation Pattern: Blank
   • Partition: Per step # 1
   • CSS: Per step # 2
   • Called Party Transformation Mask: DN automatically dialed
4. Assign phones or lines to PLAR CSS

Click here to read the whole article and view images

To enable Barge (not cBarge, which uses conference resources), the built-in bridge must be enabled. This is set globally (CallManager Service parameters) and overriden at the phone. The default is for the built-in bridge to be disabled.

From a user perspective, to activate the remote-in-use state, when a shared line is in use on Phone A, the line on Phone B will indicate that a call is in place. Assuming Single-line Barge or Single-line cBarge are disabled, pressing the shared line on Phone B activates the Remote in Use state (the default Single Line Barge setting is Off). Barge can then be selected. Privacy is important - if Privacy is enabled on Phone A, Barge can not be enabled.

Single line barge is controlled using CallManager Service Parameter, Single Button Barge/CBarge ...

Click here to read the whole article

The Privacy button allows the end user to toggle privacy on and off. If privacy is on, the Barge and cBarge keys can never be used, since the Remote-in-Use state cannot be selected. If the Phone Privacy setting is On (default), the Privacy button should be assigned to a phone button template if Barge is required, which in turn is assigned to a device (or UDP).

Click here to read the whole article and view images

When CallManager translates a number, the Dialed number displayed on the user's phone is translated according to rules on the translation pattern. By setting the Always Display Original Dialed Number parameter to True (in Service Parameters > CallManager > Device - General), the number displayed to the end user will always be the number dialed.

One particular application of this function is Manager/Assistant scenarios. Consider the scenario where the Assistant shares a line with the Manager, and the Manager has a private line on which to receive transferred calls. In this situation, if the Assistant fields a call for the manager and transfers the call to the Manager's private line, normally the private line would be visible to the Calling Party - the private line, is therefore, no ...

Click here to read the whole article and view images

The CSS for auto registration is set under the Device Pool (System > Device Pool > Default). Note that this setting only affects the phone - the line CSS does not inherit the CSS; this must be set manually. The logical AND applied to the line and phone means that line doesn't necessarily need to be set.

Click here to read the whole article and view images

Hold reversion notifies a user who has placed a call on hold that the call is still on hold. Hold reversion is a Clusterwide parameter, defined under the Call Manager service in Service Parameters.

To remind a user after 5 seconds, and then every 15 seconds thereafter, set Hold Reversion Duration to 5, and Hold Reversion Notification Interval to 15.

Click here to read the whole article and view images

Using translation patterns it is possible to mask DN A when it calls DN B so that it appears as DN C.

• Configure a translation pattern to match the number of digits used in the dial plan (i.e. 4 digits is XXXX)
• Configure the translation pattern in the CSS assigned to DN A
• Configure the "Calling Party Transform Mask" as the DN of Phone C
• Configure the CSS on the translation pattern with a CSS that includes DN B. Important: ensure DN B does not appear in the CSS of DN A, since this would be a most specific match (i.e. "1234" is more specific than "1XXX"); if this is the case, the translation pattern will never be matched, and the non-translated number will therefore be passed to the called party.

Note that Calling Name is still presented, ...

Click here to read the whole article and view images

BLF for Call Lists is controlled by the Enterprise Parameter "BLF for Call Lists" (default is false)

This parameter allows users to review BLF status for extensions in the call lists (per Presence group status rules). The SUBSCRIBE CSS on the Phone must be set (or under the user for EM). This allows users to get the same information in the Directories Lists, accessed via the Phone UI, as if a BLF was setup on the phone, or under the EM profile.

Click here to read the whole article

To setup basic BLF speed-dial on a fixed phone (no Extension Mobility):

• Assign the lines and phones to the Standard Presence Group (auto reg phones are assigned to this group by default)
• Assign the phones, or users when using EM, to a SUBSCRIBE Calling Search Space which includes the DN of the monitored extension (only the phone or EM user performing the monitoring matters; the monitored phone SUBSCRIBE CSS has no impact).
• Assign a BLF Speed Dial to one of the phones
• Reset

Et voila, the BLF speed dial is setup from Phone A to Phone B. Next is Directory-based BLF and Presence Authorization (intra- and inter-cluster).

Click here to read the whole article

Certificate Authority Proxy Function: Using the Manufacturer Installed Certificate

Note: You must ensure that the Cisco CTL Client is installed before proceeding with CAPF.

Certificate Authority Proxy Function must be enabled on the Publisher (Serviceability).

1. Activate the CAPF service on the Publisher
2. Find the phones in Device > Phones that should be enabled to use Authorization
3. Identify the desired phone
   1. Set Certificate Operation to "Install/Upgrade"
   2. Select a key size (512, 1024 or 2048) - recommend 512 in the lab, to reduce key generation times
4. Save and Reset

Debugging :: Set log size in Serviceability, Security Services, CAPF; Gather logs in RTMT

Click here to read the whole article