Callmanager 4.1 External Call Forwarding Problem

[dmitriev]

After upgrade Callmanger 3.3(4) to 4.1(3) users cant make external forwarding calls (OffNet To OffNet Transfer).

Value of "Block OffNet To OffNet Transfer" parameter in Service parameters(Feature - General) set to FALSE.

What I can do?

[joemar]

Couple of things to look at and discuss:

1-Can users call forward internally? If so, check the calling search space applied to the call forward all on the phones.

2-If they can't call forward all at all, then check SQL enterprise manager to see if replication is OK between the publisher and subscribers. If the pub is down or replication isn't working then call forwarding will fail.

Joe

[dmitriev]

The situation is next:

1. Users can forward calls internally.

It works if they set forward all from one IP Phone to other IP Phone (OnNet to OnNet call).

But It dosnt work if they set forward all from IP Phone to external (PSTN) Phone AND incoming call to this IP Phone is external (offNet to offNet forwarded call):

A External Phone from PSTN (offNet) -> B IP Phone (onNet) --> C External Phone PSTN (offNet)

Dosnt work.

Gateway debug cause code = 0x29. (But why? Not clearly, because with CCM 3.4 this problem was absent)

2. SQL replications from publisher to subscriber is successful. (No errors)

[joemar]

So, it looks like the call is making it to the gateway but is being disconnected. Cause code 29 is:

This cause indicates a facility requested cannot be provided by the network.

or

This cause indicates that a user in a special business group (i.e. Centrex) dialed an undefined code.

Can you confirm the CSS on the CFA is set to use a partition that doesn't add/delete digits that need to be sent. Also, are you prefixing the CFA number with a 9 or whatever your access code your using.

[jefflingle]

Check ou this bug: CSCee09717

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee09717

I'm running 4.01 and have the problem, i have the work around setup for now.

[dmitriev]

"Partitions" and "Calling Search Spaces" is not used in our dial rules.

But internal dial plan has "#" as first dial digit (all internal numbers begins with #4xxx).

External dial plan is normal and has no special symbols (pattern of external numbers is xxxxx for example: 36431)

Here is a part of CCM log file (../trace/CCM/..) that is made in problem period (IPPhone #4031 is set to forward all incoming calls to external PSTN phone number 37027):

09/27/2005 10:17:07.470 CCM|ForwardManager - wait_SsDataInd - Key= 0x0, party= 16781020, BCC= 7|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|ForwardManager - findCallBySsParty - Found entry for party= 16781020, callkey= 0xBB |<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|ForwardManager - findInterceptTableEntry(ssKey) - Found Intercept table entry for dn= #4031:, InterceptKey= 0x27,0x27|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - awaitingCallResponse_SsDataInd - BASIC_CALL_RELEASE - Stopping Forwarding on origination Release. party= 16781020, callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|ForwardManager - wait_ForwardStopInd - Stop Forwarding - Pid=(1,34,187), forwardKey= 0x27, callkey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|ForwardManager - removeActiveCallTableEntry - mInterceptKeyToActiveCallIndexMap - Removed entry forwardKey= 0x27, callkey= 0xBB |<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|ForwardManager - removeActiveCallTableEntry - mPartyToActiveCallIndexMap - Removed entry Origparty= 16781020, callkey= 0xBB |<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|ForwardManager - removeActiveCallTableEntry - mForwardActiveCallTable - Removed call entry for Origparty= 16781020, Destparty= 0, callkey= 0xBB |<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|ForwardManager - findInterceptTableEntry(ssKey) - Found Intercept table entry for dn= #4031:, InterceptKey= 0x27,0x27|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - awaitingStopConfirmation_ForwardStopConf - callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - unregisterRejectInterceptRequest - callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - unregisterRejectInterceptRequest - Unregistered Rejection Intercept- party= 16781020, callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - cleanupFwdLoopPreventionTables - mFwdToTable[#4031], mFwdLoopPreventionTable[#4031] = 1, callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - cleanupFwdLoopPreventionTables - decrement mFwdLoopPreventionTable[#4031] = 0, callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - cleanupFwdLoopPreventionTables - remove mFwdLoopPreventionTable[#4031], callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

09/27/2005 10:17:07.470 CCM|Forwarding - cleanupFwdLoopPreventionTables - remove mFwdToTable, callKey= 0xBB|<:CALLMANAGER-CLUSTER><:10.39.6.16><:0><:><:>

That message (and problem) appear only when incoming call is from external phone.

If a incoming call is from internal phone (from #4xxx to #4031 for example) all working perfect and we have got no problem.