I then tried using Anthony Caragol's Call Forwarding Script just to double check and see if maybe SEFAUtil wasn't reporting something correctly but it reported the same thing:
I thought that this was odd, so I decided to reproduce the issue and pull a trace from the FE pool. Doing so I saw that the call rang the user, then was responded with a PRAC and the forwarding user's identity:
Looking at the closest traces yielded nothing so I decided to also trace from the SBA that the user was registered to. This showed that a Added P-Asserted-Identity from EPID ashirey@clientdomain.com was being sent. Meaning that an endpoint was causing the call forwarding. Now this also was not unheard of however I found it strange that her client was showing no call forwarding and it was and endpoint. So I asked the user to log off of her client and then wait 1 minute then sign back in an re-test. This also yielded the same behavior and same message in the trace.
SOLUTION:
I was starting to run out of ideas and so I had one last thought, why not have the user that was receiving the forwarded calls also sign out. After having both users sign out and remain signed out for 5 minutes, then signing back in, the call forwarding was finally disabled.
So when in doubt while troubleshooting call forwarding have all the users sign out that are involved.
No comments:
Post a Comment