11-18-2008 08:26 AM - edited 03-18-2019 10:00 PM
This is something I have always just worked around, but was curious if anyone has a solution or can confirm/deny the issue.
In Unity call handlers(4 and 5 so far), when you want to transfer a caller to phone, pilot or external number, you should be able to pick "Yes, ring this extension" from the Call Transfer page and input a route pattern. I have had trouble with this from time to time where a call handler is unable to forward the call and sends to the subscriber greeting who is the owner of the call handler instead.
The solution or work around has often been to first send the caller to another call handler. I create what I call a Hand-Off call handler that then sends the call to the route pattern. This seems to work, but I am not sure why I cannot set directly to the extension/pattern without utilizing another Call Handler. Has anyone else run into this or solved it?
thanks
KK
Solved! Go to Solution.
11-18-2008 09:45 AM
I'm betting that in the cases where it does not do the transfer for you that call handler is the first object a call hits when it forwards into Unity (same is true in Connection).
When a call forwards into Unity it has an internal "do not transfer" flag set until it hits it's first object (call handler, subscriber, inerviewer, name lookup handler) at which point it's cleared. This is to prevent "call loops" where Unity furiously transfers calls to itself in a loop which can take down a system in a great big hurry.
So by "chaining" handlers togther as you've see the flag clears and then you can do a transfer.
The logic in Connection is a little different in that if the target transfer number does not match the forwarding number we're processing we will do the transfer - this was necessary for personal call transfer rule support.
As an aside, this behavior is discussed in some detail in the Audiotext Applications in Unity document out here:
11-18-2008 09:45 AM
I'm betting that in the cases where it does not do the transfer for you that call handler is the first object a call hits when it forwards into Unity (same is true in Connection).
When a call forwards into Unity it has an internal "do not transfer" flag set until it hits it's first object (call handler, subscriber, inerviewer, name lookup handler) at which point it's cleared. This is to prevent "call loops" where Unity furiously transfers calls to itself in a loop which can take down a system in a great big hurry.
So by "chaining" handlers togther as you've see the flag clears and then you can do a transfer.
The logic in Connection is a little different in that if the target transfer number does not match the forwarding number we're processing we will do the transfer - this was necessary for personal call transfer rule support.
As an aside, this behavior is discussed in some detail in the Audiotext Applications in Unity document out here:
11-18-2008 11:04 AM
Thanks so much for your helpful reply. That is exactly what I am witnessing. That document is excellent also.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide