×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Delayed Transfer from Unity AA

Unanswered Question
Dec 22nd, 2013
User Badges:

I have a basic Auto Attentant configured, and when inbound caller selects an option; say 1, they get a "wait while I transfer your call" and then the hold music.   This last for 15 seconds or so; then call gets transferred to the correct DN.


Looking for direction to remove the long delay.   Assuming this is a UNITY issue and not CM related, as transfer from handset to handset work just fine.


It's CUCM v9.1 and Unity v9.1


John         

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
brunellej Mon, 12/23/2013 - 13:08
User Badges:

Any ideas on how to resolve?   I was thinking it's a partition or call search problem; but everything is in the same.


John

Jose Pablo Vill... Mon, 12/23/2013 - 13:18
User Badges:
  • Cisco Employee,

MMM,

Sounds a little odd to me,

Wondering:

Unity integration to CUCM its SIP or SCCP?

Have you try to change the transfer option to "release to switch"

Does the issue happen transfering to another DN?

Is the DN unikeque in the system? [CUCM>route plan report> search for the dn in question]



Please Kudos/rate if this help!

brunellej Mon, 12/23/2013 - 13:34
User Badges:

It's integrated to CUCM via SCCP.   The AA are configured to "release to switch".


This only happens for called that go through Unity.   Calls between handset are fine.


Not sure what to look for in the route plan.   The calls come into the CUCM and route to DN 1000, which is the pilot number for the AA that is in question.


John

davrojas Mon, 12/23/2013 - 14:23
User Badges:
  • Bronze, 100 points or more

Hello John,


Based on the description you provided it seems the delay is happening on the CUCM side, the reason is that when Unity COnnection does a Release to Switch means that it does not keep the call any longer it just let's it go to it's destination, on the other hand CUCM needs to be able to handle this call.


To check this you would see in the Port Status Monitor output XFer followed by the HangUp event, therefore the call would no longer be in CUC.


-Regards,


Dav

Actions

This Discussion

Related Content