Wednesday, 22 July 2015

Think Globally, Act Locally...

When you receive a call, and check your Missed Call or Received Call list, and try to dial directly from the list, it will not work - because there's no Route Pattern for the number.

The solution to that is to Globalize Incoming numbers, ie., E.164 format (eg: +19721234567) and Localizing outgoing calls.

In the example below, I am showing a Subscriber number with 7 digit dialing. When you receive a Subscriber call from 972-123-4567, you will see in the Missed/Received Call list 1234567. So we are adding a +1972 to it and Globalizing the number. When the user has to callback, they can just choose the number and dial directly.

Please note that there is a misconception that you need to add 9 (8 or whatever Outside dialtone generation code) to be able to dial a Missed/Received Call list number. Also, it won't look right if the Missed/Received call list displays the numbers with a prefix, eg: 919721234567 or 91234567. So the proper way of doing it is by display an E.164 format number in the call list.

The below example is for MGCP Gateway. For H.323, there's additional digit manipulation to be done on CUCM as well as on the Gateway.

Taking care of Incoming Calls:

1. The first step is to prefix incoming number with either +CountryCode for National numbers and +CountryCode-NPA for Subscriber Numbers (ie., 7-digit numbers).

CCM Admin: Gateway > [Select the T1]


2. Next step is to create a partition PLUS_PT and a Calling Search Space PLUS_CSS and assign PLUS_PT partition to this CSS

3. Next create a Calling Party Transformation Pattern as shown below



4. Next step is to go to your Device Pool and assign the Calling Search Space: PLUS_CSS to the Calling Party Transformation CSS.. as shown below.




That's it. Now any subscriber call will be prefixed with +1972 in the call list. Next, our task is to enable these numbers to be dialed out.

Taking care of Outgoing Calls:

1. The first step is to create a Route List.. see below



2. Gateway Configuration (within Route List)




3. The next step is to create a Route Pattern for \+1972.[2-9]XXXXXX.. see below



That's it...










Friday, 17 July 2015

PostGRE SQL: Cisco XCP Message Archiver not starting

Problem: Cisco XCP Message Archiver won't start even if all PostGRE SQL setting in CUPS and the PostGRE SQL DB are correct.

Resolution:
There is a certain order in which you have to reset the services.

1. IM&P Admin: Messaging > Group Chat and Persistent Chat
2. Under Persistent Chat Database Assignment, Unassign the DB
3. Uncheck Enable Persistent Chat


4. IM&P Serviceability: Tools > Control Center-Network Services
    Select Server: IM&P
5. Restart Cisco XCP Router (note: will take some time)
6. IM&P ServiceabilityTools Control Center-Feature Services
       Select Server: IM&P
7. Start Cisco XCP Text Conference Manager
8. Start Cisco XCP Message Archiver


This should do it and the DB connectivity should come up



Thursday, 18 June 2015

CUCM 8.0.3 to 10.5.2 Migration thru PCD 10.5.3

Scenario:
Cluster with 5 servers running on MCS. Trying to migrate to 10.5 virtual environment via PCD. Doing a parallel migration.
- CUCM PUB
- CUCM SUB1
- CUCM SUB2
- CUCM SUB3
- CUCM SUB4
- IM&P

Problem Summary:
Migration task of CUCM 8.0.3 to 10.5.2 thru PCD is interrupted with a Critical Error on CUCM PUB (see below)



Cause:
- Orphaned Phone Button Template

Solution:
- Generic Solution: Follow the dump file collection steps shown below and determine the config that's causing the conflict and delete that item from your current cluster and re-run the PCD Migration task.

See detailed steps below...

Attempt 1: Day 1
OVAs & Images used:
CUCM OVA: cucm_10.5_vmv8_v1.8.ova
CUCM ISO: Bootable_UCSInstall_UCOS_10.5.2.10000-5.sgn.iso
CUP OVA: cucm_im_p_10.5_vmv8_v1.0.ova
CUP ISO: Bootable_UCSInstall_CUP_10.5.2.21900-4.sgn.sgn.iso

- Discovered current cluster
- Defined Migration Task by selecting the discovered cluster and creating the New Cluster with new Hostnames & IP addresses. PCD supposedly makes it 'easier' to migrate with hostname and IP address change.
- Executed Migration task
- First task in the list of 12 tasks went thru fine - which is to take a backup of all the servers in the cluster - took around 2hrs (consider WAN data transfer).
- Task 2 in the list was to install the new PUB and restore the data from current PUB (that was done part of Task 1)
- Installation failed with Critical error...
- Meanwhile PCD will show status of 'Running' for about 5hrs and then come up with a 'Failed' status (refer Bug: CSCu000851)

- Encountered an issue: VM was inadverdently moved from the ESXi Host as the rule to keep on the destined host was deleted by mistake.

Attempt 2: Day 2
- Deleted CUCM. Recreated CUCM VM and restarted Migration task
- Failed again with same error
- Tried to capture dump file to serial, but was returning 0 size file.

Attempt 3: Day 2
- DNS resolution wasn't done. Fixed that. (A & PTR records working now).
- Deleted CUCM VM and recreated it
- Executed Migration again
- Failed again - same error

Attempt 4: Day 3
- Tried with new image: 10.5(2)SU1: Bootable_UCSInstall_UCOS_10.5.2.11900-3.sgn.iso
- Also tried something different this time. Tried to edit the <VM>.vmx file, find 'ethernet0.virtualDev' (should be on line 42) and move it to the end of the file.. follow steps below or just open it in a text editor and cut (remove blank line) and paste at the bottom of the file..

Before


After


   - 
    cucm.ova.README.txt


- Deleted CUCM VM and recreated it
- Executed Migration again
- Failed again - same error

Attempt 5: Day 4
- Apparently there is a certain procedure to follow to dump the log files (see below). Followed these steps and got a 25Mb file.
- The log file has no extension. After you download it to your computer, rename it to .tar
- Open this using WinRAR and you will see a multiple folders and files..
- Navigate to...
\var\log\active\cm\trace\dbl\sdi\installdb_ru.log.err

- Found the below...

- Based on this.. went to the current CUCM and found this...note the hex value: 4ee12cca-....2110 in the URL - got that from the log file. See above


- The orphaned Phone Button Template for Android phones (which actually did have any dependencies) was causing the issue.
- Deleted the template as no device was attached to it

- Recreated CUCM VM (left network adapter setting as is, didn't modify <VM>.vmx file
- Recreated new migration task 
- Executed Migration task
- Voila!!! that worked.. 
- PCD has moved to the next Task: IM&P Install & Restore