The Call Forward All is invoked before the AAR. So the Site A phone doesn't call Site B phone then get forwarded. So this is what I think is happening. What it does is it sends the request to CCM, it sees the CFA, then processes that with the CFA CSS. The call then is setup but more than likely is going against a Site B Gw (this is dependant on the CSS applied above). Since the Site B is congested it then tries to use AAR, this is assuming the site B gateway is added as an AAR group. That AAR group is probably 91 prefix, at least that's the most common NANP way to do it. This appends this to the CFA number, which probably already had a 91xxxxxxxxxx. So the call is probably going out with 9191xxxxxxxxxx. Now of course CFA might not even work with AAR at all, which might be the other scenario since AAR groups append to External Phone Masks and I've read nothing about CFA. Another scenario might be the Gateway doesn't have an AAR group assigned.
Assuming my guess on how CFA and AAR is right, then there should be a simple way to test this. Just change the CFA on the phone to not include the AAR group prefix. Sure this won't work for normal calling but it will let us test AAR correctly. If that ultimately is the issue then you can use a AAR-CSS on the phone with a pattern in that CSS to account for the 91 overlap. Again this is just theory on my part.
I'm going to lab this out today because frankly I'm not entirely sure what it will do other than it will definitely process the CFA and not the AAR to the phone. I will let you know my results.
Ok heres the deal with this. Some of my assumptions were wrong from the last post.
After you hit CCM and it processes the CFA, then it looks up the pattern in it's CFA CSS. This pattern then checks it's route list and selects the gateway. The site B gateway is going to be probably the first gateway in your route list, assuming Location has been set on the gateway then the call will fail. But if you add a second gateway, say from the site A, then the call will use that and succeed. AAR never gets invoked, but the Location setting is what affects the failover in the route list.
So in my testing I was able to get a busy signal on my CFA call if I only had site B gateway in my routelist and a location set. As soon as I added site A gateway as a secondary on my routelist the call would go through on site A gw. If I removed the Location setting from site B gw then site B would be the 1st selected gw on my CFA call. So with well crafted CSS for CFA and Route Lists with redundancy you can do this correctly. Unfortunately since it's by Route List level and not pattern then this makes it harder to make best routing decisions for a large complex rollout.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...