Capturing the CTI port used by the previous call leg.
We use call redirect steps to transfer calls from one application (our top level IVR) to another application (our second level IVR). We use the trigger to direct these calls.
Customers can enter at either the first or second level, so our script uses logic to decide if the caller is External (outside the business), Internal (a 4 digit extension inside the business) or a Redirected Call (redirected from another applications CTI Control port) and provide the customer with a different experience.
So callers coming directly into the second application get the full “Thanks for calling your call will be recorded etc etc….”, but callers coming in from the top IVR don’t hear an introduction prompt and will jump straight into the menu options.
At the moment I’m using conditional rules to check the calling number and play the appropriate prompts. The logic works great, but I can't seem to get hold of the CTI control port of the previous call leg.
I was expecting the calling number on the second sequence to be the CTI control port number used by the first sequence (these can range from 175000 to 176999) but instead the calling number of the first leg is being passed over to the second leg– so for example, if I call from my desk the first sequence detects that it’s an internal call and the second leg does the same - instead the second leg should detect that it’s a redirected call.
Does anyone know how to achieve this?
Hope that makes sense! Any help would be much appreciated.
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...