[cisco-voip] Callmanager CFWDAll

[Ed Leatherman]

We do have a similar configuration as far as distance is concerned, 2 of the
subs are not local. Near as I can tell though the problem yesterday was
cluster wide, or at least it was occuring both at the "remote" site and also
affecting phones registered to subs sitting right beside the publisher. We
were seeing #3 I guess, there were no error messages on the phones. Not
using any third party apps on the servers other than AV.

Some users were complaining that they could not set forwarding at all (i
experienced this on my desk phone as well). Others were able to but the
animated forwarding icon would not go away.

On 4/7/06, Wes Sisk <wsisk at cisco.com> wrote:
>
> Ed,
>
> we have seen a strong correlation between CFA failures and CM servers
> separated by some distance of network rather than CM's being connected to
> immediately adjacent switches.
>
> there are 3 primary steps to setting CFA:
> 1. phone tells primary CM it wants to set CFA
> 2. primary CM tells publisher to set CFA
> 3. publisher tells all CMs in the cluster CFA has been set.
>
> if 2 fails you get a database error on the ipphone
> if 3 fails you set CFA and receive no error but phone does not fwd.
>
> #2 is performed through DCOM - DBLHelper does not test this.  dtcping and
> rpcping from microsoft can test DCOM RPC's but that's about it.  Being RPC
> based the communication uses multiple random ephemereal ports and connects
> are established dynamically.
> #3 is performed through a TCP session from aupair.exe on a random port on
> the publisher to ccm.exe on port TCP:7727 of some random server in the
> cluster.  Usually when we see CFA failures we find out the random server is
> remote from the rest of the servers in the cluster.  Note if aupair.exedoes not detect any change notifications pending it may not establish this
> session to port 7727. I have seen this problem only once when someone used a
> 3rd party (not MS or Cisco) database management app on the SQL instance
> running on the CM publisher and it removed all triggers from the CCM
> database.
>
> /Wes
>
> Ed Leatherman wrote:
>
> Anyone having problems with CFWDAll not working every now and then? I've
> been having trouble with it ever since we upgraded to 4.0.. albeit they
> are getting less frequent as I apply various SR's. We just had a burp this
> morning with it and I had to reload DBL Mon this morning to fix it.. was
> relatively painless but kinda annoying to still be having these problems. So
> wondering if anyone else is having it happen. We're running 4.1(3)SR3a
> now.
>
> --
> Ed Leatherman
> IP Telephony Coordinator
> West Virginia University
> Telecommunications and Network Operations
>
> ------------------------------
>
> _______________________________________________
> cisco-voip mailing list
>
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>



--
Ed Leatherman
IP Telephony Coordinator
West Virginia University
Telecommunications and Network Operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20060407/0562fb71/attachment.html