I have a call handler instructing callers to dial a parties extension at any time. If I get to this call handler from an internal phone the call is transfered to the users extension, rings the phone and if no answer then goto voicemail - this is working correclty!! But when a caller calls from the outside they are transferred to the call handler, enter a valid extension, the extension rings 3 times and then the user is thrown back to the call handler - not the extensions voicemail box. <br><br>Any ideas on this? or how to even start troubleshooting it would be greatly appreciated.<br><br>
Can you provide the call information that shows up in the CallViewer.exe when this call forwards back to voice mail when the caller is internal? External? Can you also provide the "real" call information: the DN of the phone that was transferred to from the call handler, the DN of the internal phone used for testing, the caller ID of the external caller if available? Also, what are the Unity, CCM and TSP version numbers?
"5","Internal","Fwd(Ring no answer)","0","1","7090","7852283570","7090" "6","Internal","Fwd(Ring no answer)","0","1","7006","7852283570","7006"
This call was placed from an outside line and dialed 7006 when call handler picked up.
DN 7090 is a shared line that rings all IP phones in the office - it is configured to forward on a no answer to DN 7099 which is a CTI route point. The route point in turn forwards everything to the voice mail ports 8690. I have a call routing rule that sends anything forwarded from 7090 to go directly to the location specific call handler. This is where the problem starts for just EXTERNAL calls trying to dial an extension. External callers can navigate through the call handler to the directory handler and that works fine. But if a valid extension is dialed then the extension rings three times and then the call is sent back to the call handler.
Unity 3.1 Call Manager 3.1(2a) TSP ????? (not sure where to locate this)
I am going to check into this in-house. The TSP version number can be determined by the file properties on the \Winnt\System32\AvSkinny.TSP file. There's also instructions in the TSP release notes on how to determine the version number of the TSP.
Well, I am kinda scratching my head on this one, but can you try getting rid of the routing rule that sends anything forwarded from 7090 to go directly to the location specific call handler, and instead, placing 7090 into the Extension field on the call handler's profile page? It shouldn't make a difference doing it one way or the other, but who knows.
After looking at the routing rules again last nite I finally figured it out. The call routing rule I was using was a "Forwarded Call" rule. It was based on the "Calling Number". The calling number was set at the router where the calls came into. I looked at the log and the "caling number" stayed the same throughout the transfer. So when the call was transfered to the users extension and there was no answer the call then was transferred back to Unity with the SAME calling number - therefore the rule matched and again played the greeting for the call handler.
Thanks for your help and pointing me in the right direction.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...