The call routing was designed in a way that when they dial any 7614XXXX extension, it hits a TP (7614XXXX )and gets translated to 60447614XXXX. For testing we dialed several 7614XXXX numbers and they all went fine to corresponding 60447614XXXX except when they dialed 76146920. As soon as they dial that number you will see on the display that it’s going to an outside mobile number.

I had to dig into traces where I found for some reason it is not even hitting the Translation pattern at all and was getting intercepted by a pattern 76146920 with a Time of Day routing on it which had that mobile number setup during a certain period of time. But when I checked, there was no such TOD routing setup on this extension,  moreover there was no such extension 76146920 which exist in the system. I ran some CLI commands to find if there are any database entries for this extension and found none. Customer told me that they use to have extensions like 7614XXXX before they migrated all extensions to 60447614XXXX which means may be previously someone did setup a CFA on this extension which is still stuck in it’s database.

|VoiceMailPilotNumber=
|RouteBlockFlag=BlockThisPattern <———block
|RouteBlockCause=1
|AlertingName=
|UnicodeDisplayName=
|DisplayNameLocale=33
|InterceptPartition=Internal
|InterceptPattern=76146920

cfa     = 755XXXXXX <———– Mobile number

This is what I did to resolve the issue:

• Created an internal extension 76146920 and put it in Internal Partition
• Assigned the extension to a dummy phone
• Put a Call Forward ALL on the extension to some internal number
• Made a test call which now hits this newly created DN and goes to that CFA internal extension
• Removed CFA and saved
• Deleted the DN 76146920
• Made a test call and this time it was ringing the phone 604476146920

This was just a one off issue and Cisco TAC later confirmed that old versions of CCM may come across these kind of issues. This is rare but I thought to share it for the benefit of everyone.

This sort of error normally comes when you have one of the following conditions:

• Too many unassigned directory numbers in Call manager i.e. not assigned to any phone or any extension mobility profile
• No Extension assigned to the phone
• The Busy Trigger and maximum calls on the line are not correct (normally you configure max calls: 4 and busy trigger: 2)

For this particular issue I found no extension was assigned to it so I assigned an unassigned DN and the issue was resolved.

The UCCX server was version 7.0 windows Box.

Make sure these steps are completed:

• Make sure that you type the user ID correctly. User IDs are case sensitive
• Verify that you use the correct Cisco CallManager password
• Verify Phone is associated RMCM user
• Make sure that the RM JTAPI user ID is configured as a member of the Standard CTI Enabled user group
• Make sure user exist in RMCM user list at UCCX server as an agent
• Can user ping UCCX and CCM hostnames/IP addresses
• If the problem is still not resolved, try to stop and restart the Cisco Desktop Sync Server service on all servers
• Install latest Cisco Agent Desktop on user PC
• Restart CRS Engine / Node manager

You may also need to do a manual Re-synch from Cisco Desktop Administrator.

Go into Start > Programs > Cisco > Desktop > Admin

Select Call center 1 and then from top bar go into Setup > Synchronize Directory Services.

Also, from top menu go into Desktop Administrator > Side A > A window will pop up.

username : admin password: leave blank  > hit login

Then go into Services Configuration > Synchronize Directory Service and then on right click ‘Synchronize’

If all goes well, you will not receive any error and that would be good news BUT if you get something like below then we would need to carry out some more steps:

If you get this error after manually trying to synch Dir services then that means you are hitting Bug CSCtg58421.

*Snip*

CSCtg58421 – Update to user ID while logged into CAD does not update CRS Engine

Symptom:

CDAUI2082 At least one error has occurred during the manual synchronization of directory services.

Conditions:

When a user ID is updated either through CUCM or Active Directory, the CRS Engine still holds this in memory and causes a sync issue since both IDs are still present.

Workaround:

User ID should only be updated when the agent is logged out of CAD. If the user ID is updated while the user is logged in a CRS/CCX engine restart is required to clear the memory of the old user ID.

This will require a reboot of whole UCCX cluster and a restart of CTI manager service on all Call managers.

This will only work if users who are sharing the number are logged in using Extension mobility.

You can configure it here under extension number by going into each phone:

If the box is checked, missed calls will be logged and if it is not checked then missed calls won’t be logged.

At Thu Mar 01 04:42:41 CET 2012 on node 10.254.33.20, the following HardwareFailure events generated:
hwStringMatch : Mar  1 04:42:10 AKDEUC00 daemon 4 Director Agent: LSIESG_AlertIndication 500605B0024A5360 BBU disabled; changing WB virtual disks to WT Sev: 3.
AppID : Cisco Syslog Agent
ClusterID :
NodeID : AKDEUC00
TimeStamp : Thu Mar 01 04:42:10 CET 2012

If you are concerned about this error then don’t be. This is a cosmetic error and documented in Bug id CSCti17353 .

 Bug Details

“IBM Servers battery learn cycle negatively impacts CCM performance”

Symptom:

CCM Tracing stops for a period of time (over 4 seconds observed) leading dropped or reordered calls.
IO wait utilization of the CPU increases unexpectedly.  System Event Logs (messages) contains the following logs shortly after the unexpected IO event.

Aug 2 15:48:08 lg-sub-1 daemon 5 Director Agent: LSIESG_AlertIndication 500605B00177F4C0 Battery relearn started Sev: 2.
Aug 2 15:48:13 lg-sub-1 daemon 4 Director Agent: LSIESG_AlertIndication 500605B00177F4C0 BBU disabled; changing WB virtual disks to WT Sev: 3.

Conditions:

On MCS-78X5-I3 platforms with LSI Raid controllers the system will run a Battery Backup Unit learning cycle every 60 days. The system can experience sudden IO
performance drop at the beginning of this cycle and this could impact Callmanager’s call processing performance. During this cycle the Raid Controller’s Caching policy is changed from WriteBack to Write Through.

Workaround:

None to avoid the BBU learning cycle.

After this ddts is applied…

The event reported above is an informational (sev 4) event: daemon 4

Director Agent:
LSIESG_AlertIndication 500605B0027DA6E0 BBU disabled; changing WB virtual disks

The event will occur once a month (at 4:42am) during the battery recharging cycle. That cycle is a scheduled event to recharge the raid battery. During that time, raid cache write-back is disabled as part of normal course to ensure proper IO. This is not an issue.

This is how you can route out an incoming call out of the gateway.

Let suppose the mainline number coming into the gateway is ’881456′. The following setup will route the call out of the gateway to PSTN.

voice translation-rule 10
rule 1 /881456/ /901139886666/
!
voice translation-profile RedirectPSTN
translate called 10
!
dial-peer voice 10 pots
description Incoming Dial Peer
translation-profile incoming RedirectPSTN
incoming called-number 881456
direct-inward-dial
port 0/0/0:15
!
dial-peer voice 20 pots
description Outbound Dial Peer
destination-pattern 9T
port 0/0/0:15
!

Call comes in and match incoming-called number dialpeer 10 and then it will match the incoming translation profile. The translation profile will translate the number to another PSTN number with prefix ’9′. This will match dialpeer 20 and will send the call out to PSTN.

There is no straight forward answer if you google it so I thought to compile this post for a quick reference.

You can do this from Bulk Administration.

Just browse to Bulk Admin > Phones > Update Phones > Query and then if you want to search all of them just hit ‘Find’.

This will bring all the phones in the system.

Scroll down and hit Next you will see a screen similar to this:

Don’t change anything else and run the job. Click Submit.

There you go, it will log out all the extensions. You can check the status of it from Scheduler.

AppleSyncNotifier.exe – Entry Point Not Found

” The procedure entry point sqlite3_wal_checkpoint could not be located in the dynamic link library SQLite3.dll”

This is what I did to resolve the issue:

COPY the file SQLite3.dll from the C:\Program Files\Common Files\Apple\Apple Application Support folder  and PASTE it in C:\Program Files\Common Files\Apple\Mobile Device Support folder

After the iOS5 was launched yesterday I was a bit reluctant to do the upgrade as I had issues in past with my iphone 3G during iOS upgrades. Over the weekend it just struck my mind that I should go ahead and do the upgrade (hate that moment). I downloaded iOS5 and when it came to install part, an error popped up saying I don’t have enough space for the backup. It asked me for 6GB of space in my C drive while I only had 2GB free. The warning was if I continue, I will lose all my media etc. I tried my best to change the location to my external 1TB HDD but for some reason this iOS was looking for space in C. Anyways, I moved my downloads and few other folder to make some space for it before going ahead with the install part. So a very important point – you must have enough space in your C drive before you can do iOS5 upgrade. I don’t know if there are any tweaks which can solve this issue but I tried few and none of them worked till I released space in C drive.

During the install part it backs up your iPhone data and then validates from Apple site. Different users have come across different errors. I came across a very strange one and that was Error 1611. My iphone hung in recovery mode and I could not do anything.  Searched that error on Apple site which left me more worried. Let me share with you what Apple says about that error:

Error 1611: This error may indicate a hardware issue with your device. Follow the steps in this article. Also attempt to restore while connected with a known-good 30-pin Dock Connector cable, computer, and network to isolate this issue to the device. The MAC address being missing or the IMEI being the default value (00 499901 064000 0) can also confirm a hardware issue. Out-of-date or incorrectly configured proxy or security software, such as FoxyProxy, can cause error 1611. To troubleshoot third-party security software, follow these steps.

I followed the basic restore procedure but after every failed attempt it came back with a new error like 1603, 1604, 9 etc. My iphone was stuck in recovery mode and I could not do anything. The ‘Restore’ procedure I followed is here at Apple Site.

This ‘Restore procedure’ did not resolve my issue and I thought this is it, I can never see my iPhone again. Searched through different forums and most of them said it is a hardware error and it will brick the iphone. Regarding Error 1611 there was a story on BBC where a user had to buy another phone. Few users suggested that anyone who came across Error 1611 will not be able to see their iphone again!

Don’t get panic! after hours of trying different things I finally resolved the issue by going through the following procedure:

1. Uninstall itunes from Programs/Features in Control Panel
2. Unintsall ‘Apple application support’
3. Remove Apple registries if possible using software like CCleaner
4. Restart your computer
5. Disconnect all USB devices except your mouse/keyboard
6. Download latest itunes (10.5 at the time of writing)
7. Install the itunes – don’t worry you won’t lose anything
8. Log out from your itunes account if you are already logged in
9. Log back in
10. Turn off all your firewalls, antivirus, Anti-melware etc (sometimes Apple have issues connecting to certain ports if you have third party firewall/AV installed)
11. Make sure ‘Apple Mobile Device’ service is started (check from Services.msc)
12. Run itunes
13. Use a different USB port of your PC/laptop (if available) to connect your iPhone directly to computer (Do not use a USB hub/port on monitor)
14. Click on the device and hit on Restore

itunes will now successfully restore your iphone to factory default settings and after that will look for last Backup. I always keep latest backups so I had my backup ready to be restored. After like 30-35 minutes everything was restored and I could see my iphone again with new iOS 5.

I know this could get very painful and the whole purpose of writing this blog entry was to help those who are stuck in this issue. As this is my very own personal experience I cannot gurantee that this will resolve your problem but I really hope it does.

Their initial design was to send all UK calls from US over a SIP trunk to break out from a UK gateway for LCR (least cost routing). For some reason they stopped using that trunk and configured local dial peers on US gateways for international calls. All sites were working fine as they were going through one route pattern (for international calls), one route list (Local Route Group) except one site. This site was getting an ‘unallocated/unassigned number’ when calling an international number (UK inour case). This was a bit suprising as all sites were using same settings on Route Pattern, Route List , Route Group etc.

I thought to first find out if our dialled number is hitting the gateway as it is without any change. Did a CCAPI INOUT to find out as follows: (The X mark in Calling/Called number can be any digit)
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_supported_data: data_mode=0×10082
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructTDUsrContainer: usrContainer[0x6408896C], magic[FACE0FFF]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x6408896C, tagID=6, dataSize=16, instID=-1,modifier=2
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x65C89E68], nxtElem[0x0], magic[0xFACE0FFF] tagID[6], dataLen[16], modif[2]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x65C89E68] instID[-1] into container[0x6408896C]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x6408896C, tagID=22, dataSize=12, instID=-1,modifier=4
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x638DCC78], nxtElem[0x0], magic[0xFACE0FFF] tagID[22], dataLen[12], modif[4]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x638DCC78] instID[-1] into container[0x6408896C]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:

02:05:19: cc_api_call_setup_ind:

02:05:19:  cisco-username=Sharon Sidd
02:05:19: —– ccCallInfo IE subfields —–

02:05:19:  cisco-ani=585XXX50X0
02:05:19:  cisco-anitype=1
02:05:19:  cisco-aniplan=1
02:05:19:  cisco-anipi=0
02:05:19:  cisco-anisi=1

02:05:19:  dest=90114411898X1XXX    <<<< As you can see Call manager handed over the same number which was dialled

02:05:19:  cisco-desttype=0
02:05:19:  cisco-destplan=0
02:05:19:  cisco-rdn=

02:05:19:  cisco-rdntype=-1
02:05:19:  cisco-rdnplan=-1
02:05:19:  cisco-rdnpi=-1
02:05:19:  cisco-rdnsi=-1
02:05:19:  cisco-redirectreason=-1

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: (vdbPtr=0x6428E260, callInfo={called=90114411898X1XXX,called_oct3=0×80,calling=585XXX50X0,calling_oct3=0×11,calling_oct3a=0×81,calling_xlated=false,subscriber_type_str=Unknown,fdest=1,peer_tag=50, prog_ind=0,callingIE_present 1, src_route_label=, tgt_route_label= clid_transparent=0},callID=0x6408BD24)
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind:
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: type 0 , prot 1
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
02:05:19: ccCheckClipClir: calling number is: “585XXX50X0″, calling oct3a is: 0×81
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
02:05:19: Calling Party number is User Provided
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
02:05:19: Leaving ccCheckClipClir
calling number is: “585XXX50X0″
calling oct3 is:  0×11
calling oct3a is: 0×81

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: (vdbPtr=0x6428E260, callInfo={called=90114411898X1XXX, calling=585XXX50X0, fdest=1 peer_tag=50}, callID=0x6408BD24)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: Increment call volume: 0
02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: current call volume: 1
02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry’s incoming TRUE.

02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incoming is FALSE

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: profileTable[0x653738A0], numBuckets[11], numEntries[0]

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: Invoking necessary profileTable updaters…

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: Updating profileTable[0x653738A0] with objects in container[0x6408896C]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[5] for the tag[6]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x653738A0], tdObject[0x65C89E68]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[0] for the tag[22]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x653738A0], tdObject[0x638DCC78]

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager:

02:05:19: ccTDUtilDumpAllElemInProfileTab: profileTable[0x653738A0], numBuckets[11], numEntries[2]

02:05:19: Bucket { 0 } ——>0x638DCC78[0x0,t-22,l-12,d-0x638DCC98,m-4,u-7519,g-FACE0FFF]

02:05:19:

02:05:19: Bucket { 5 } ——>0x65C89E68[0x0,t-6,l-16,d-0x65C89E88,m-2,u-7519,g-FACE0FFF]

02:05:19:

.
.
.
.
.

02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: cid(207), st(SSA_CS_MAPPING),oldst(0), ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: src route label=, tgt route label= tg_label_flag 0×0
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: finalDest cllng(585XXX50X0), clled(90114411898X1XXX) tgt_route_label()tg_label_flag 0×0
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: cid(207), st(SSA_CS_CALL_SETTING),oldst(0), ev(24)dpMatchPeersMoreArg result= 0
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaDebugPeers: ssaSetupPeer cid(207) peer list: tag(1) called number (90114411898X1XXX) tag(104) called number (90114411898X1XXX) tag(105) called number (90114411898X1XXX)
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaSetupPeer: dialpeer tags in rotary= 1  104  105
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaSetupPeer: cid(207), destPat(90114411898X1XXX), matched(1), prefix(), peer(64A70EFC), peer->encapType (1)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallProceeding: (callID=0xCF, prog_ind=0×0)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest: (Inbound call = 0xCF, outbound peer =1, dest=,
params=0×64392138 mode=0, *callID=0×64392708, prog_ind = 0callingIE_present 1)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest:

02:05:19: ccCallSetupRequest numbering_type 0×80
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest:
02:05:19: ccCallSetupRequest: calling number is:585XXX50X0

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest: calling oct3a is:0×81

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: (vdbPtr=0x64852F88, dest=, callParams={called=90114411898X1XXX,called_oct3=0×80, calling=585XXX50X0,calling_oct3=0×11, calling_oct3a= 0×81, calling_xlated=false,  subscriber_type_str=Unknown, fdest=1, voice_peer_tag=1},mode=0×0, appl_call_id=, callingIE_present=1)

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
02:05:19: ccIFCallSetupRequestPrivate: src route label  tgt route label tg_label_flag 0×0

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:  vdbPtr type = 6

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: (vdbPtr=0x64852F88, dest=, callParams={called=90114411898X1XXX, called_oct3 0×80,  calling=585XXX50X0,calling_oct3 0×11, calling_oct3a 0×81, calling_xlated=false,  fdest=1, voice_peer_tag=1}, mode=0×0, xltrc=-5)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
02:05:19: //208/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: not incoming entry
02:05:19: //208/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry’s incoming FALSE.
02:05:19: //208/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incoming is FALSE
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_set_voice_port_value:
02:05:19: CC_IF_TELEPHONY: echo =0, playout = 0

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccSaveDialpeerTag: (callID=0xCF, dialpeer_tag=1)
02:05:19: //208/xxxxxxxxxxxx/CCAPI/ccCallSetContext: (callID=0xD0, context=0x638F184C)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallReportDigits: (callID=0xCF, enable=0×0)
02:05:19: //-1/xxxxxxxxxxxx/CCA

VG-FRNA-MON-3725#PI/ccTDConstructTDUsrContainer: usrContainer[0x64082410], magic[FACE0FFF]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0×64082410, tagID=19, dataSize=4, instID=0,modifier=1
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x638FB624], nxtElem[0x0], magic[0xFACE0FFF] tagID[19], dataLen[4], modif[1]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x638FB624] instID[0] into container[0x64082410]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructMultiInstHolderObject: multiHolder[0x653B1B44], nxtElem[0x0], magic[0xFACE0FFF], tagID[19], dataLen[0], modif[-1], numInst[0]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtPushInstToMultiInstHolder: Successful in pushing instance object[0x638FB624] into holder[0x653B1B44]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: profileTable[0x6566213C], numBuckets[11], numEntries[0]
02:05:19: //208/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: Invoking necessary profileTable updaters…
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: Updating profileTable[0x6566213C] with objects in container[0x64082410]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[6] for the tag[19]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x6566213C], tdObject[0x653B1B44]
02:05:19: //208/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager:
02:05:19: ccTDUtilDumpAllElemInProfileTab: profileTable[0x6566213C], numBuckets[11], numEntries[1]
02:05:19: Bucket { 6 } ——>0x653B1B44[0x0,t-19,m-1,g-FACE0FFF 0x638FB624,i-0<t-19,l-4,d-0x638FB644,m-1,u-7519,g-FACE0FFF> ]
02:05:19:

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDUsrContainer: Container[0x64082410]

02:05:19: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8  callref = 0x00B0

Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0×1181, ’585XXX50X0′
Plan:ISDN, Type:International
Called Party Number i = 0×80, ’4411898X1XXX’    <<< Number got changed at the gateway
Plan:Unknown, Type:Unknown
Cause i = 0×8281 – Unallocated/unassigned number   <<< The error is coming from provider side

It appears though that call manager is sending the correct number ’901144….’ but for some reason the Q931 debugs were showing number going out as ’44……’ without the prefix ’011′. I checked the dialpeers and there was no stripping or forward-digits restriction on it. To remove any doubt concerning dial peers, I  created an explicit 9011 dial peer with prefix 011 and assign it preference 1. Even that didn’t work and my call was going out without 011 and failing.

Looking closely at Q931 debugs I found something interesting:

Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0×1181, ’585XXX50X0′
Plan:ISDN, Type:International
Called Party Number i = 0×80, ’4411898X1XXX’
Plan:Unknown, Type:Unknown
Cause i = 0×8281 – Unallocated/unassigned number

The outgoing called number had plan and type ‘Unknown’. Though the same settings were working fine for other sites I thought to explicitly assign proper type and plan and see if that makes any difference.

I created a seperate translation rule and Voice translation profile and included it in POTS dial peer.

!
voice translation-rule 5
rule 1 // // type any international plan any isdn
!

voice translation-profile PRI-INTL
translate calling 3
translate called 5
!

!
dial-peer voice 9011 pots
translation-profile outgoing PRI-INTL
preference 1
destination-pattern 9011T
progress_ind alert enable 8
progress_ind progress enable 8
progress_ind connect enable 8
port 2/0:23
prefix 011
!

Now when I dialled the number, it worked like a charm:

19:21:26: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8  callref = 0×0147
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0×1181, ’585XXX50X0′
Plan:ISDN, Type:International
Called Party Number i = 0×91, ’4411898X1XXX’
     Plan:ISDN, Type:International

19:21:26: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0×8147
Channel ID i = 0xA98397
Exclusive, Channel 23
19:21:28: ISDN Se2/0:23 Q931: RX <- ALERTING pd = 8  callref = 0×8147
Progress Ind i = 0×8488 – In-band info or appropriate now available
19:21:33: ISDN Se2/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0×0147
Cause i = 0×8090 – Normal call clearing
19:21:33: ISDN Se2/0:23 Q931: RX <- RELEASE pd = 8  callref = 0×8147
19:21:33: ISDN Se2/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0×0147

Provider was expecting proper type and plan and even though the call was still going without prefix ’011′ but it was working.