<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1498" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>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. ;)</DIV>
<DIV>&nbsp;</DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We can only hope it gets better I guess.</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=rratliff@cisco.com href="mailto:rratliff@cisco.com">Ryan Ratliff</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=lelio@uoguelph.ca 
  href="mailto:lelio@uoguelph.ca">Lelio Fulgenzi</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=cisco-voip@puck.nether.net 
  href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, April 20, 2005 9:28 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [cisco-voip] CFwdAll on 
  4.x</DIV>
  <DIV><BR></DIV>SQL replication has nothing to do with CFA being broke per the 
  FN.&nbsp;&nbsp;&nbsp; <BR>This specific problem only exists in 4.x as 
  well.<BR><BR>I think I've sent emails before on how to troubleshoot CFA issues 
  in&nbsp; <BR>4.x and those cover the basics of how it works, but the whole 
  thing&nbsp; <BR>breaks down to communication issues between the publisher and 
  the&nbsp; <BR>(randomly selected) server with the role of the SSAPI 
  master.&nbsp; The&nbsp; <BR>publisher will have a TCP connection on port 7727 
  to this server and&nbsp; <BR>that SSAPI master server is the one responsible 
  for passing out&nbsp; <BR>database change notifications to the CCM process on 
  each node in the&nbsp; <BR>cluster (via SDL).&nbsp; Currently there is a nasty 
  bug at the TCP layer in&nbsp; <BR>CM that prevents Aupair (database layer 
  monitor) from detecting when&nbsp; <BR>that connection is lost.<BR><BR>Most 
  often simply restarting Aupair on the publisher will fix the&nbsp; <BR>problem 
  (assuming you are indeed hitting the bug mentioned in the FN).&nbsp;&nbsp; 
  <BR>Since the CFA process has about 8 steps (from phone hitting the 
  softkey&nbsp; <BR>to intercept tables being updated on all nodes in the 
  cluster) a&nbsp; <BR>breakdown anywhere can have frighteningly similar 
  symptoms.&nbsp; In some&nbsp; <BR>cases a restart of one (or even all) CCM 
  services is necessary to&nbsp; <BR>recover the SDL links.<BR><BR>The fix will 
  first be showing up in 4.0(2a)sr2.&nbsp; Shortly after that it&nbsp; <BR>will 
  be in engineering specials for 4.1(2) and 4.1(3).&nbsp;&nbsp; Don't 
  bother&nbsp; <BR>asking for it though until you see 4.0(2a)SR2 on CCO.&nbsp; 
  Personally I'd&nbsp; <BR>give it an extra week before opening a TAC case 
  asking for the ES since&nbsp; <BR>those are only built on certain 
  days.<BR><BR>On a semi-related note, please make sure your customers (or 
  other&nbsp; <BR>admins) aren't restarting CM by deactivating and then 
  re-activating the&nbsp; <BR>service.&nbsp; Doing that changes the CTI node ID 
  and will break SDL&nbsp; <BR>communication with that server and all the other 
  servers in the cluster&nbsp; <BR>until they are all rebooted.&nbsp;&nbsp; It's 
  just bad, mmkay?<BR><BR>-Ryan<BR>On Apr 20, 2005, at 8:02 AM, Lelio Fulgenzi 
  wrote:<BR><BR>We've had this problem since 3.2. It was a bone of contention at 
  one of&nbsp; <BR>the CIPTUG open MICs where I brought it up about 3.3 and 
  Cisco said it&nbsp; <BR>was fixed in 4.x. Then at least one person running 
  each of the latest&nbsp; <BR>codes, i.e 3.3.4, 4.0.1, 4.0.2 each said they 
  were still running into&nbsp; <BR>the problem.<BR><BR>The database syncing is 
  a serious problem, and I had really hoped that&nbsp; <BR>it would be taken 
  care of by now. :(<BR><BR>We run in a 'high redundant' or whatever its called 
  state on our server&nbsp; <BR>farm switches, which allows failover from one 
  supervisor to another&nbsp; <BR>extremely quickly. That switchover is enough 
  to cause the 'unexpected'&nbsp; <BR>interruption and force us to have to 
  restart the cluster. The restart&nbsp; <BR>of the DBL didn't always help 
  us.<BR>&nbsp; <BR>I think the worst part, was there was no true way to see if 
  the&nbsp; <BR>databases were properly synced or not. DBLhelper was suggested a 
  few&nbsp; <BR>times, but that only seems to check for the existance of 
  the&nbsp; <BR>relationship one way (or something like that).<BR>&nbsp; <BR>Oh 
  well.....<BR><BR><BR>----- Original Message -----<BR>&nbsp; From: King, 
  Jesse<BR>To: <A 
  href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Sent: 
  Wednesday, April 20, 2005 7:38 AM<BR>Subject: [cisco-voip] CFwdAll on 
  4.x<BR><BR><BR>I had this about a month ago. FYI<BR><BR><A 
  href="http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/">http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/</A> 
  <BR>products_field_notice09186a0080440e6d.shtml<BR><BR>Message Type : Field 
  Notice <BR><BR><BR>&nbsp; Title: Cisco Field Notice: Call Forwarding Failure 
  After a Cisco&nbsp; <BR>CallManager 4.x Unexpected Shutdown<BR><BR>&nbsp; 
  URL:<BR><A 
  href="http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/">http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/</A> 
  <BR>products_field_notice09186a0080440e6d.shtml<BR><BR>Posted: April 19, 
  2005<BR><BR>Summary:<BR>IP Phone users are no longer able to enable or disable 
  Call Forward All&nbsp; <BR>(CFA) following an unexpected shutdown<BR>of any 
  Cisco CallManager servers in a cluster. 
  <BR><BR>_______________________________________________<BR>cisco-voip mailing 
  list<BR><A 
  href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A 
  href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>_______________________________________________<BR>cisco-voip 
  mailing list<BR><A 
  href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A 
  href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR></BLOCKQUOTE></BODY></HTML>