04-13-2011 08:10 AM - edited 03-19-2019 02:43 AM
In UNITY , a subscriber is set up that when a caller presses zero, caller input is set to “Attempt Transfer” to another subscriber. The called subscriber is forwarded to VM and the subscriber to which the call is being transferred is also forwarded to voice mail. It takes 20 seconds before the caller gets a message from the “transferred to” subscriber. Most callers won’t wait that long. Do I have something mis-configured? Any way, to reduce the time that a caller is waiting? I have other subscribers set to "attempt transfer to operator" and had both phones call forwarded to VM and it only took 5 seconds.
Solved! Go to Solution.
05-05-2011 12:33 PM
Hey Mary,
No worries my friend
My guess would be that something that should have been reset during the
changes for the 601 overlap were finally updated during the UPS repair window.
The nice thing is that it's all working well now so you can move onto putting
out some other "fires"
Cheers!
Rob
05-05-2011 12:39 PM
It looks like you were having DB issues also, perhaphs, the CUCM service was not reflecting the changes on the DB and the reboot force it to come back.
Good to know it is working now!
HTH
--espereir
04-13-2011 09:17 AM
Hey Mary,
Hope life is treating you well my friend
The first thing that comes to mind is that 15 seconds is the default
setting for the IDT (inter digit timeout) in CUCM. So maybe the number
that you are trying to route to via Caller input 0 has an overlapping DN set somewhere
in the system (either CUCM or Unity). It just seems strange that it takes 5 seconds for all
the other users that you have set up this way, but this one is 20 seconds. The normal 5 plus
15 exactly. That would be the first place I would look.
Cheers!
Rob
04-14-2011 07:11 AM
Good catch Rob, +5 on this one!
--espereir
04-20-2011 11:57 AM
04-13-2011 09:33 AM
Rob is right, you might one to create a translation pattern with an unique number in CUCM translating to the number that you want (for the translation pattern I recomend using # or * as part of the number, that way the pattern will be unique). Then, assing the unique number to the attempt transfer option.
In addition, if this does not fix the issue, is it possible to get the output of the Port Status Monitor so we can check where the call is routed within Unity?
HTH
--espereir
04-21-2011 05:45 AM
Hi Mary,
I think this does prove that there is some existing Number Plan Overlap
in either the Page or VMPilot partitions, so just be careful moving forward
I would still try to address this overlap so it doesn't bite you somewhere down the road.
Cheers!
Rob
04-25-2011 05:53 AM
Rob, you were absolutely correct in warning me to be careful! The changes caused major problems. The VM kept ringng busy - would take several attempts to get in. I undid the change and will start over looking at problem this morning. Thanks!!
04-24-2011 10:56 PM
Mary,
If you want, you can send us a dial plan report (CSV format) and we can check if there are any overlapping patterns; another trobleshooting option will be to setup a dummy phone with the exact same configuration as the VM port (same MRGL, CSS, etc...) and test the number.
We can help you with your dialplan if you attach the CSV.
HTH
--espereir
04-25-2011 06:52 AM
Hi Espereir,
I know this is going to sound stupid but to get dial plan report, I assumed that I would go to Call Routing -> Dial Plan Installer -> then I selected Dial Plan and "is not empty". But I have no records. Is that possible or am I in the wrong option?? Also, to display everything in a particular option, I have found that with our last upgrade, the only way is to select :"is not empty". Is that true? Thanks!!
04-25-2011 07:06 AM
I believe it is under Dial Plan >> Route Plan Report, and there you will have a dropdown, select CSV and upload it to NetPro.
HTH
--espereir
04-25-2011 08:20 AM
04-25-2011 08:47 AM
Hi Mary,
I do not see any overlapping extensions; could you please provide a screenshot of the affected user transfer settings and include the extensions (and please rephrase the call flow).
HTH
--espereir
04-25-2011 08:47 AM
Hi Mary,
I thought I might jump back in to add a note to the great tips from our friend
espereir (+5 "E")
The flaw that I see here is that you have the VM Pilot and
VM Port 1 as 601. This is not correct I would change the
VM Port 1 to a new 6xx number and adjust the Hunt list/Line group
accordingly.
Cheers!
Rob
04-25-2011 08:54 AM
Rob is right, (I missed that one , +5 4 Rob), you should change either the VM Pilot or the VM port number to something else since that is causing the overlap, the easiest way is to change the first VMPort number to something else (perhaps 617); the elegant way will be to change the VMPilot to 600, but you will need to edit the VM Profile settings for this to take effect on the phones.
601 | VMPorts | Device | CiscoVM1-VI1 | VM Ports | |
601 | VMPilot | Hunt Pilot | VMHL | Voice Mail Hunt List |
HTH
--espereir
04-28-2011 07:35 AM
Thank you Rob & Espereir,
I informed the Cisco Tac Support Engineer of what you found and they recommend a re-do of the Unity and Call Manger integration to remove the overlap.
That is scheduled for 5:00 p.m. (after hours) today. Does this sound reasonable? Thanks for all your help. As always, you nailed it.
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