attempt transfer to another subscriber takes 20 seconds

[maryclegg]

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. 

[Rob Huffman]

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

[espereir]

Good catch Rob, +5 on this one!

--espereir

[maryclegg]

Thanks, Rob for your feedback.  I always appreciate how quickly you repsond.   The problem had to do with the Intercompany calling search space.  The VMPorts was listed second to last.  The Tech moved it up to third and it is working much better.  see attached.

[espereir]

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

[Rob Huffman]

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

[maryclegg]

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!!  

[espereir]

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

[maryclegg]

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!!

[espereir]

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

[maryclegg]

Hi Espereir,

I hope I have attached the correct file.  Thanks for all your attention.

[espereir]

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

[Rob Huffman]

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

[espereir]

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

[maryclegg]

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.