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.

I initially thought it could be a network issue from switches to CUCME gateway as the config was looking fine to me. I did a show ephone summary and found all of them in ‘Unregistered’ status. Nothing changed really, the config was all ok and these phones were all working fine few minutes before. So what has gone wrong?

I started going through the config if anything has changed but nothing changed. Then I did show telephony service and found below:

=====================
Version 8.1
Max phoneload sccp version 17
Max dspfarm sccp version 18
Cisco Unified Communications Manager Express
For on-line documentation please see:

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

protocol mode default
ip source-address 172.16.49.250 port 2000
ip qos dscp:
ef (the MS 6 bits, 46, in ToS, 0xB8) for media
cs3 (the MS 6 bits, 24, in ToS, 0×60) for signal
af41 (the MS 6 bits, 34, in ToS, 0×88) for video
default (the MS 6 bits, 0, in ToS, 0×0) for serviceservice directed-pickup
no auto-reg-ephone
load 7937 apps37sccp.1-3-4-0
load 7942 SCCP42.8-5-4S
max-ephones 25
max-dn 200
max-conferences 8 gain -6
dspfarm units 0
dspfarm transcode sessions 0
conference software
.
.
.
.
.
.
.
web admin customer name Customer
edit DN through Web:  enabled.
edit TIME through web:  disabled.
Log (table parameters):
max-size: 150
retain-timer: 15
create cnf-files version-stamp 7960 Jul 29 2011 15:25:03
transfer-system full-consult
transfer-digit-collect new-call
local directory service: enabled.
Extension-assigner tag-type ephone-tag.
shutdown

Did you guys see what was wrong?

Somehow the telephony service went into shutdown state. I did a no shut on telephony service and they all start registering.

I looked into few CCSIP debugs (debug ccsip messages) and found that the ‘BYE’ message was actually coming from our end (Call manager/Gateway).

Platform information:

CCM: System version: 7.1.3.32900-4

CUBE-10#sh ver

Cisco IOS Software, 3800 Software (C3825-ADVIPSERVICESK9-M), Version 12.4(24)T4, RELEASE SOFTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Fri 03-Sep-10 09:15 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

CUBE-10 uptime is 27 weeks, 3 days, 44 minutes

voice-card 0
!
!
voice call send-alert
voice rtp send-recv
!
voice service voip
allow-connections sip to sip
fax protocol cisco
sip
options-ping 180
!
!
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711alaw

!

voice class sip-profiles 1
request INVITE sip-header Allow-Header modify “, UPDATE” “”

!

dial-peer voice 10 voip
description *** Outbound to GXXX – SIP Provider ***
translation-profile outgoing OUTBOUND
huntstop
destination-pattern 9T
voice-class codec 1
voice-class sip early-offer forced
voice-class sip profiles 1
session protocol sipv2
session target ipv4:10.0.222.69
dtmf-relay rtp-nte
fax-relay sg3-to-g3
no vad

!
!

gateway
timer receive-rtp 1200

!
sip-ua
retry invite 1
retry response 2
retry bye 2
retry cancel 1
retry options 1
timers trying 200
!

!

!

Debug Output:

Jul 11 12:17:54.579 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:079XXXXXXX@10.0.222.69:5060 SIP/2.0

Via: SIP/2.0/UDP 10.0.222.65:5060;branch=z9hG4bK100B17D
From: “anonymous” <sip:anonymous@10.0.222.65>;tag=B891B2E8-282
To: <sip:079XXXXXXX@10.0.222.69>;tag=3519367399-656588
Date: Mon, 11 Jul 2011 11:15:27 GMT
Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@10.0.222.65
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1310383074
CSeq: 128 BYE
Reason: Q.850;cause=16
Content-Length: 0

Jul 11 12:17:54.591 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.0.222.65:5060;branch=z9hG4bK100B17D
To: <sip:079XXXXXXX@10.0.222.69>;tag=3519367399-656588
From: “anonymous” <sip:anonymous@10.0.222.65>;tag=B891B2E8-282
Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@10.0.222.65
CSeq: 128 BYE

Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH

Contact: <sip:079XXXXXXX@10.0.222.69:5060>

Content-Leng

= = = =

This is what I have done to fix the problem:

I added these commands under sip-profile:

voice class sip-profiles 1
request INVITE sip-header Allow-Header modify “UPDATE,” “”      < < <  This was already there
request REINVITE sip-header Allow-Header modify ” UPDATE,” “”
response 200 sip-header Allow-Header modify “UPDATE,” “”
response 180 sip-header Allow-Header modify “UPDATE,” “”

The next step was to increase the Service Parameter “SIP Session Expire Timer” which you can find under Service Parameters > Call manager:

That was it, it fixed the issue and customer confirmed having a call for more than 3 hours.

These are the steps involved (considering Call manager Linux versions):

1 – Configure extension mobility service by going into Device > Device settings > Phone Services

The service URL is : http://call-manager-IP:8080/emapp/EMAppServlet?device=#DEVICENAME#

If you want to set it up as an Enterprise service then check that box “Enterprise Subscription” otherwise leave it. If you check that box, extension mobility service will appear globally for all phones and you won’t be able to find this service under phone Subscribe services in Step 2. If you don’t check that box then move to step 2

2 – Under phone, susbcribe this service as follows by dropping down the menu at top right corner and then going into “Subscribe/Unsubscribe Service”

3- Staying on the same phone page, scroll down and check the extension mobility check box otherwise no one will be able to login:

4 – Create a User device profile Device > Device Settings > Device profile. Any higher generation phone profile will work on lower one but that’s not true the other way around. So a Cisco 7960 device profile can be used to login oo a 7912 phone but a Cisco 7912 UDP won’t login on a Cisco 7960 phone.

5 – After creating UDP, the most important and sometimes missed step is to subscribe the Extension mobility service again like step 2 at UDP level

6 – Go into user from from User management > End user and add that device profile to it. Also select the primary extension at that user page.

Login and you should be good to go. Any issues, it would either be related to service not subscribed at UDP level or a UDP not associated with a user.

Web Link for EM:

There can be a situation where your Pub is down or inaccessible and users wants to login or logout. As EM service is dependent on Publisher they won’t be able to login/logout and will get “host not found”.

There is a workaround where users can login to their phones through a web link.

To login using URL:

http://<CUCM-SUB IP Address>/emapp/EMAppServlet?device=MACADDR&userid=USERID&seq=XXXXX

XXXXX = Pin

Example:

http://192.168.70.11/emapp/EMAppServlet?device=SEP001E4AF0F9E4&userid=ajon&seq=12345

To logout the user:

http://< CUCM-SUB IP Address>/emapp/EMAppServlet?device=SEP001646D97913&doLogout=true

The issue was first reported from US users trying to reach UK users over an Inter-cluster trunk (Non-GK). Both clusters had two call managers version 8.0.3. The whole issue started after US call managers were re-located and their IP addresses were changed. The ping response between two clusters was about 145ms which wasn’t too bad. I did a test call to a UK phone by connecting my IP communicator to US (due to time difference it was very difficult to get someone in US to make test calls). I did a CFA on UK phone to Voicemail and could see on my communicator that the call has connected but I didn’t hear the first 10 seconds of the voicemail.

I made a similar test by calling a UK phone but this time asked someone to answer it. The call was connected fine but we couldn’t hear each other for like 10 seconds. After 10 s it was all ok.

The issue was bit different when someone from UK to US would call. In that case call will connect 70% of the time with no issues but 30% of the time it will connect and drop.

I had to run through different CCM traces on both clusters to find below:

### Digit analysis for the call
04:42:47.464 |Digit analysis: match(pi=”2″, fqcn=”XXXXXX1409″, cn=”1409″,plv=”5″, pss=”PT_FRNA_INTERNAL:PT_FRNA_ROUTE”, TodFilteredPss=”PT_FRNA_INTERNAL:PT_FRNA_ROUTE”, dd=”303165″,dac=”0″)|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43
04:42:47.464 |Digit analysis: analysis results|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43
04:42:47.464 ||PretransformCallingPartyNumber=1409
|CallingPartyNumber=201409
|DialingPartition=PT_FRNA_INTERNAL
|DialingPattern=21XXXX
|FullyQualifiedCalledPartyNumber=303165

04:42:47.464 |DeviceManager::star_DmPidReq – RequestedName=dec100fa-40c7-ac1a-9dcb-50a73af41700 LookupName=dec100fa-40c7-ac1a-9dcb-50a73af41700|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43
04:42:47.464 |Digit analysis: wait_DmPidRes- Partition=[8a2bfaaa-13f0-4631-9c26-02a08a573cf7] Pattern=[21XXXX] Where=[],cmDeviceType=[AccessDevice], OutsideDialtone =[0], DeviceOverride=[0], PID=RouteListControl(2,100,73,10)|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43

### H225 set-up sent via ICT:
04:42:47.616 |Out Message — H225SetupMsg — Protocol= H225Protocol|*^*^*
04:42:47.616 |Ie – H225BearerCapabilityIe IEData= 04 03 80 90 A2 |*^*^*
04:42:47.616 |Ie – Q931DisplayIe IEData= 28 0B 43 68 61 64 20 48 61 69 6E 65 73 |*^*^*
04:42:47.616 |Ie – H225CallingPartyIe IEData= 6C 08 00 81 32 30 31 34 30 39 |*^*^*
04:42:47.616 |Ie – Q931CalledPartyIe IEData= 70 05 80 33 30 36 33 |*^*^*

### Connect received (call answered)
04:42:49.461 |In  Message — H225ConnectMsg — Protocol= H225Protocol|*^*^*
04:42:49.461 |Ie – H225BearerCapabilityIe — IEData= 04 03 80 90 A2 |*^*^*
04:42:49.461 |Ie – Q931DisplayIe — IEData= 28 0C 53 74 65 76 65 20 47 61 72 6E 65 72 |*^*^*
04:42:49.461 |Ie – Q931ConnectedNumIe — IEData= 4C 06 00 81 33 30 36 33 |*^*^*

### outgoing TCS sent after about 8 seconds:
04:42:57.260 |TranslateAndTransport(21728)::waitForSdlRsp_H245TcpConnectionInfo – received H245TcpConnectionInfo from H245Handler|0,0,0,0.0^*^*
04:42:57.264 |
H245ASN – TtPid=(21728) -Outgoing #195026  -value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

¬Also, the SDL logs indicate a significant delay in the TCS being sent out:
Line 135: 027643128| 2011/07/06 04:42:49.465| 002| SdlSig    | H245ConnectReq                        | wait                          | H245Handler(2,100,24,1)         | TranslateAndTransport(2,100,16,21728)| (2,100,23,21728).1-(*:*)                | [NP - PQ: 0]
Line 331: 027643324| 2011/07/06 04:42:57.259| 002| SdlSig    | H245TcpConnectionInfo                 | waitForSdlRsp                 | TranslateAndTransport(2,100,16,21728)| H245Handler(2,100,24,1)         | (0,0,0,0).0-(*:*)                       | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
Line 332: 027643325| 2011/07/06 04:42:57.259| 002| SdlSig    | TtControlChannelEstablished           | waitForTransportEstablishment | H245SessionManager(2,100,23,21728)| TranslateAndTransport(2,100,16,21728)| (0,0,0,0).0-(*:*)                       | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
Lin

This shows the H225 part of H323 is fine but H245 was taking time. I did reset of trunks, changed Call manager priorities etc but that didn’t help.

I then enabled ‘Outbound FastStart’ for all outbound calls from US to UK and enabled the same for inbound calls on UK trunk. This fixed the issue.

I had to provide a MTP resource under MRGL at US trunk as FastStart needs MTP.

US Cluster:

UK Cluster:

A little about how ‘Outbound FastStart’ works from Cisco:

Outbound Calls :

Enable Outbound FastStart   

Check this check box to enable the H.323 FastStart feature on outgoing calls.
By default, the check box remains unchecked for the H.323 gateway or trunk.
When you check the Enable Outbound FastStart check box, you must set the Media Termination Point Required, Media Resource Group Lists, and Codec for Outbound FastStart.

Inbound Calls:

Enable Outbound FastStart   

Check this check box to enable the H.323 FastStart call connections on incoming calls.
By default, the check box remains unchecked for the H.323 gateway.
For intercluster calls, you must check the Enable Inbound FastStart check box on Cisco CallManager servers in other clusters for the outbound FastStart feature to work.
If you updated Cisco CallManager 3.3(2) servers in other clusters with support patch B, do not enable inbound FastStart because 3.3(2)spB does not support the inbound FastStart feature over intercluster trunks

I tried it myself and I was getting as follows:

So it was Local agent not responding – I tried restarting the Cisco DRF Master and Local but that didn’t help.

This is what I did to resolve the issue:

• Log into Cisco Unified Communications Manager OS Administration page.
• Went into Security > Certificate Management.
• Do Find all
• At the bottom there was ipsec.pm – I clicked that and regenerated the file
• Found all ipsec-trust certificates and deleted them
• Then went into tomcat.pem and regenerated it as well
• Restarted the Cisco TOMCAT service (from CLI) and Cisco DRF Master / Local and TFTP from GUI

It was all working fine after that.