Unity Connection Double Beep on Transfer

Unanswered Question
Apr 14th, 2010
User Badges:

We have a CUCMBE deployment with UC and Unity Connection 7.1 (3).  All inbound calls are forwarded directly to VM where a call handler references a business hours/after hours calendar.  Between 7:45 AM and 5 PM, all calls are immediately transferred back to an extension in UC that serves as a hunt pilot.  After business hours, calls immediately are diverted to the main number voicemail box.  All of this works exactly as planned.  The issue is that at the time of transfer two beeps are played.  Since the transfer happens immediately during business hours, callers are greeted with the double beep and then they hear ringback as the call cycles through the hunt group.  Since we only recently switched to this system, this double beep is a new phenomenon for the incoming callers and there have been numerous complaints.  When calling after hours, the callers immediately go to voicemail with any beeps or even a ringback.  This is fine and seems to indicate that the double beep is related to the transfer.


Is it possible, without using ToD routing in UC, to remove this double beep on transfer while maintaining the call handler functionality in Unity Connection?  As others have pointed out, the call handler method allows for use of the calendar and makes it easy enough that people can be trained to update the schedule.  We have used both Supervised Transfer and Release to Switch with the same double beep result.  I have checked through all of the parameters I could find in both Unity Connection and UC Manager.  I have even heard a transfer to a second call handler as a potential solution but ultimately I need to forward back to the hunt pilot so I am not sure how this would resolve it or even how to configure it.


I appreciate any assistance with this issue as it is not mission-critical but definitely something we would like to resolve.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
William Bell Wed, 04/14/2010 - 08:32
User Badges:
  • Purple, 4500 points or more

Unless I am mistaken, the double-beep you are referring to is likely coming from Tone On Hold (ToH). Which is what is played out (by default) if Music On Hold is disabled or fails to spawn for some reason. You can disable ToH using the Call Manager service parameter "Tone on Hold Timer". If the value is 200000, no hold tone plays; otherwise, the held device will play the hold tone in a cyclical fashion (based on the timer (in seconds) provided). Now, this will disable ToH for every call. This parameter doesn't affect SIP devices so if your CUC is integrated as SIP (not SCCP) then it may not help.


The other thing you could do is modify Unity Connection so that transferred calls are released to the switch (i.e. non-supervised transfer). This would avoid the problem altogether. What are you using to do the transfer action in Unity Connection? Look under "Transfer Action" and see if "Release to Switch" is selected.


If I am missing the mark, please provide some more details around the components/config objects in CUCM/CUC that you are using.


HTH.


Regards,

Bill

lukemorgan4 Wed, 04/14/2010 - 08:41
User Badges:

It definitely sounds like the Tone on Hold beeps.  I reset the parameter to 200000 and the double beep behavior is still there.  Do I need to restart the Call Manager service for this change to take effect?


The call handler transfer is currently set to Release to Switch.  I have tried Supervise Transfer with the same result.

William Bell Wed, 04/14/2010 - 09:21
User Badges:
  • Purple, 4500 points or more

I don't believe you need to restart the Call Manager service. You could test this with two IP phones in your environment (assuming they don't have a MoH audio server).


I haven't worked with CUCM-BE in a while. Is the Unity Connection portion integrated via SCCP in a line group or is it a SIP trunk? If SIP, then the ToH timeout parameter doesn't apply and you may have to look at doing something like an "empty" MoH audio source. Sounds lame I know but that is how I had to do it with SIP trunks in the past. Basically, you create a .wav file that is silent. Upload that file. Enable MoH and then use the bogus file as the audio source. The other option I have used was to configure Multicast MoH on the CUCM while not enabled multicast on the network. This essentially means the MoH audio stream can't go beyond the CUCM-BE subnet and (therefore) can't reach voice gateways or IP phones, etc. Yes, another goofy workaround. I am not aware of a better way. But, going back to your situation, if the CUC ports are SCCP ports then I would think that the ToH parameters would apply.


Oh, and I was wrong on the Release to Switch behavior. Apparently, CUC still puts the caller on hold while it dials the transfer-to destination. So, this would trigger ToH.


Sorry, I have nothing more useful at the present moment.


Regards,

Bill

lukemorgan4 Wed, 04/14/2010 - 16:09
User Badges:

I disabled the standard MoH we have in place and tried hold between two internal phones with the Tone on Hold setting set to 10.  As expected, I hear a double beep every 10 seconds.  I then changed this setting to 200000 to disable it and the beeps ended.  I then try the inbound call and still get the double beep on transfer from Unity Connection back to UC.  I will continue to look for a setting for this as configuring ToD just seems like an unreasonable alternative.

lukemorgan4 Wed, 04/14/2010 - 16:14
User Badges:

Also, this is an SCCP integration so the Tone on Hold should still be relevant.

lukemorgan4 Wed, 04/14/2010 - 16:38
User Badges:

I have resolved the issue.  For whatever reason, the Tone on Hold setting doesn't seem to work between UC and Unity Connection in the CUCMBE deployment.  Once I assigned a Media Resource Group List to the Device Pool the VM ports were in, the beeps stopped.  Fortunately, they are not replaced with the MoH either.  The line now transfers as designed and does not beep.

William Bell Wed, 04/14/2010 - 17:17
User Badges:
  • Purple, 4500 points or more

Excellent news. Thanks for posting the resolution. After your SCCP post I started doing a test in my lab (but I didn't have CUCM-BE just CUCM and CUC 7.1). You saved me some time


Regards,

Bill

Actions

This Discussion