[cisco-voip] CFwdAll on 4.x

[Lelio Fulgenzi]

Thanks for your thorough explanantion. The issue is that we have had CFA problems for a while - the fact that they are caused by different problems on different code levels means nothing to our users - they simply see the problem persisting. I can appreciate the complexity of the system and how many steps something takes and how many things can go wrong - the users don't (and shouldn't) - the expect the forwarding button to work as effeciently as it did on our 20year old PBX. ;)

To make matters worse, we spent many days on the TAC about the CFA issue and they were convinced it was an SQL replication issue and had us reinitialize the database sync using DBLHelper a few times and also restart the CallManager service on many occassions. By the sounds of what you are saying, that was likely making the matter worse.

We can only hope it gets better I guess.

  ----- Original Message ----- 
  From: Ryan Ratliff 
  To: Lelio Fulgenzi 
  Cc: cisco-voip at puck.nether.net 
  Sent: Wednesday, April 20, 2005 9:28 AM
  Subject: Re: [cisco-voip] CFwdAll on 4.x


  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20050420/1ba2eb38/attachment.html