Unity 5, System Transfer, Call disconnected if busy

Unanswered Question
Mar 5th, 2009

I am transferring via a "Caller System Transfer" to Call Manager extensions. They are non-Unity subscribers, hence the use of the system transfer. However, if the intended destination is busy, the caller is disconnected rather than hearing busy tone. This is not acceptable. Is there a configuration issue ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Brandon Buffin Thu, 03/05/2009 - 08:55

Here's one option:

1. Create another call handler and set the transfer to "Yes, ring this extension" and the Transfer Type to "Release to switch"

2. Set the caller input on your original call handler to "Attempt Transfer For" the Call Handler created above instead of "Caller System Transfer"

Hope this helps.


ajenks Thu, 03/05/2009 - 09:04

Thanks Brandon - but wouldn't that only be relevant if the transfer was to a single fixed extension ? I need the caller to be able key-in the extension number.

Is the issue I am experiencing with the disconnection normal ? I was hoping there was a "release to switch" type setting on the System Transfer that may help.

ajenks Thu, 03/05/2009 - 15:55

Event viewer shows :

Event Type: Warning

Event Source: CiscoUnity_TSP

Event Category: None

Event ID: 109

Date: 3/5/2009

Time: 2:35:59 PM

User: N/A

Computer: [removed]


Cisco Unity-SCCP TSP device 6 (Cisco Unity port 2): Failed blind transfer to [removed]. Busy tone detected.

If this is a persistent problem, it may indicate a problem on the Cisco Unity and/or CUCM servers. Verify that transfers are working.

Christopher McAlpin Thu, 03/05/2009 - 20:08

With Cisco Unity SCCP integrations, "Blind Transfers" are really "Wait for Ring" and then release transfers.

If your were transferring to an extension via a subscriber or call handler object, the warning would still be logged, but the conversation would route you back to the subscriber or call handler object that attempted the transfer and play the greeting.

Unfortunately the System Transfer conversation does not seem to be coded to handle this issue and drops the call.

One solution for you might be the following.

Forward all the phones that don't have mailboxes back to Unity on busy and play a greeting that says the line is busy and to try your call again later.

To accomplish this on the Unity side with out having to create a call handler for each phone (which is why you are using system transfer to begin with), you will create one call handler and give it an extension ID. For this example lets say you give it extension ID 1000.

Now you will use an extension remapping configuration file on Unity to remap all those extensions to 1000.

To do this go to the \Commserver\Intlib\ExtensionMapping\Forward directory.

There is a sample.txt file in there. Make a copy of this file and name it anything you want as long as it ends in .exm

Maybe call it ForwardRemap.exm

In the uncommented section of the file remap each extension that you choose to 1000.

You will have to restart Unity for the remap configuration file to take affect.

Now all those extensions will forward to Call Handler 1000 and play what ever you like.

ajenks Thu, 03/12/2009 - 13:00

Thanks for the reply Chis. I understand what you are saying.

If the call is transferred via the system transfer, is the call regarded as internal or external (by the destination extension) ? If it's internal then enabling this workaround would effectively disable the "callback" function because in theory those phones would never give busy (currently ALL DNs are set to give busy tone rather than voicemail etc. even if it's available and this is intentional). If it was regarded as external, then at least the "forward busy external" only could be used to preserve callback functionality.

It maybe that the intended destination extension is forwarded to an external line (cell phone etc.) and in event of this being busy I guess the call would still be dropped ?

Is this an issue specific to this version of Unity, or all versions ? Is there any chance in getting a fix / code change for this issue ?

The other issue I've got with applying this workaround is that it affects the behaviour of ALL calls to that extension (rather than just those going via the system transfer) because the change is on the DN itself. I know the users are not going to accept this because of the number of phones it affects.


This Discussion