[cisco-voip] CFwdAll on 4.x

[Ryan Ratliff]

SQL replication has nothing to do with CFA being broke per the FN.    
This specific problem only exists in 4.x as well.

I think I've sent emails before on how to troubleshoot CFA issues in  
4.x and those cover the basics of how it works, but the whole thing  
breaks down to communication issues between the publisher and the  
(randomly selected) server with the role of the SSAPI master.  The  
publisher will have a TCP connection on port 7727 to this server and  
that SSAPI master server is the one responsible for passing out  
database change notifications to the CCM process on each node in the  
cluster (via SDL).  Currently there is a nasty bug at the TCP layer in  
CM that prevents Aupair (database layer monitor) from detecting when  
that connection is lost.

Most often simply restarting Aupair on the publisher will fix the  
problem (assuming you are indeed hitting the bug mentioned in the FN).   
Since the CFA process has about 8 steps (from phone hitting the softkey  
to intercept tables being updated on all nodes in the cluster) a  
breakdown anywhere can have frighteningly similar symptoms.  In some  
cases a restart of one (or even all) CCM services is necessary to  
recover the SDL links.

The fix will first be showing up in 4.0(2a)sr2.  Shortly after that it  
will be in engineering specials for 4.1(2) and 4.1(3).   Don't bother  
asking for it though until you see 4.0(2a)SR2 on CCO.  Personally I'd  
give it an extra week before opening a TAC case asking for the ES since  
those are only built on certain days.

On a semi-related note, please make sure your customers (or other  
admins) aren't restarting CM by deactivating and then re-activating the  
service.  Doing that changes the CTI node ID and will break SDL  
communication with that server and all the other servers in the cluster  
until they are all rebooted.   It's just bad, mmkay?

-Ryan
On Apr 20, 2005, at 8:02 AM, Lelio Fulgenzi wrote:

We've had this problem since 3.2. It was a bone of contention at one of  
the CIPTUG open MICs where I brought it up about 3.3 and Cisco said it  
was fixed in 4.x. Then at least one person running each of the latest  
codes, i.e 3.3.4, 4.0.1, 4.0.2 each said they were still running into  
the problem.
 
The database syncing is a serious problem, and I had really hoped that  
it would be taken care of by now. :(
 
We run in a 'high redundant' or whatever its called state on our server  
farm switches, which allows failover from one supervisor to another  
extremely quickly. That switchover is enough to cause the 'unexpected'  
interruption and force us to have to restart the cluster. The restart  
of the DBL didn't always help us.
   
I think the worst part, was there was no true way to see if the  
databases were properly synced or not. DBLhelper was suggested a few  
times, but that only seems to check for the existance of the  
relationship one way (or something like that).
   
Oh well.....
 
 
----- Original Message -----
  From: King, Jesse
To: cisco-voip at puck.nether.net
Sent: Wednesday, April 20, 2005 7:38 AM
Subject: [cisco-voip] CFwdAll on 4.x


I had this about a month ago. FYI

http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/ 
products_field_notice09186a0080440e6d.shtml

Message Type : Field Notice   
   

  Title: Cisco Field Notice: Call Forwarding Failure After a Cisco  
CallManager 4.x Unexpected Shutdown

  URL:
http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/ 
products_field_notice09186a0080440e6d.shtml

Posted: April 19, 2005

Summary:
IP Phone users are no longer able to enable or disable Call Forward All  
(CFA) following an unexpected shutdown
of any Cisco CallManager servers in a cluster.   

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip