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]

Hi Mary,

You are most welcome

That sounds like a reasonable plan. I would have thought

that changing VM Port 1 to a new 6xx number and adjusting

the Hunt list/Line group would have worked, but re-doing the whole

integration is OK too..

Cheers!

Rob

[espereir]

You are really welcome Mary,

Redoing its OK, however you can change the VM Pilot to 600 and that will do the trick, why don´t you share this post with TAC since you have 3 options here:

1- Redoing the whole integration

2- Change the VM Profile to 600 and leave the VMPort numbers as they are configured

3- Change the first VM Port number to something else.

HTH

--espereir

[maryclegg]

Hi Espereir and Rob,

Tac took your suggestion and dod not do an integration but just corrected the overlap.  Unfortunately that did not fix the problem.  Here is their suggestion:

Problem Description

As I have understood it till now, the issue is, that there is a dead silence of 20 seconds before a message greeting is played after a call transfer.

Action Plan

To proceed, I believe you are hitting a bug with ID: CSCSi80906 which requires applying Unity 5.0(1) ES. 

The link to find the ES is :

http://www.cisco.com/cisco/software/release.html?mdfid=281063851&flowid=5411&softwareid=282074319&release=5.0%281%29ES88&rellifecycle=&relind=AVAILABLE&reltype=latest

We have not applied the patch yet.  We will possibly do next week.

If you want, you can give me your feedback.  Thanks again for all your help and your interest.  Have a great weekend. 

[Rob Huffman]

Hi Mary,

Here is the bug;

CSCsi80906            Bug Details

MM:when config'd delay in hearing greeting

Symptom: When Message Monitor is configured for a subscriber's phone, the caller hears a delay after the call is forwarded to Unity but before the caller hears the subscriber's greeting. Conditions: Unity 5.0(1) or later. Message Monitor is configured for the subscriber's phone. Workaround:  The delay can be reduced to 3-4 seconds by applying the latest Unity 5.0(1) ES, or by upgrading to Unity 7.0(1). However, there not a way to reduce the delay beyond this point. Additional Details: In Unity 7.0and later a new delay was introduced that could easily be mistaken forthis issue. Please see defect CSCsv80158 for details about this delay.An ES will be required to resolve this delay.

Status Terminated              Severity 4 - minor Last Modified In Last 7 Days         Product Cisco Unity Unified Messaging          Technology 1st Found-In 5.0(0.279)                    Fixed-In 7.0(0.78) 7.0(0.86) 5.0(1.0)ES25 5.0(1.0)ES30 5.0(1.0)ES31 5.0(1.0)ES32 5.0(1.0)ES33 5.0(1.0)ES34 5.0(1.0)ES35 5.0(1.0)ES38 5.0(1.0)ES39 5.0(1.0)ES48 5.0(1.0)ES50 5.0(1.0)ES51 5.0(1.0)ES52 5.0(1.0)ES53 5.0(1.0)ES55 5.0(1.0)ES56 5.0(1.0)ES57 5.0(1.0)ES58 5.0(1.0)ES59 5.0(1.0)ES61 5.0(1.0)ES62 5.0(1.0)ES63 5.0(1.0)ES64 5.0(1.0)ES65 5.0(1.0)ES66 5.0(1.0)ES67 5.0(1.0)ES68 5.0(1.0)ES69 5.0(1.0)ES70 5.0(1.0)ES71 5.0(1.0)ES72 5.0(1.0)ES73 5.0(1.0)ES74 5.0(1.0)ES75 5.0(1.0)ES76 5.0(1.0)ES78 5.0(1.0)ES80 5.0(1.0)ES81 5.0(1.0)ES82 5.0(1.0)ES83 5.0(1.0)ES89 5.0(1.0)ES85 5.0(1.0)ES86 5.0(1.0)ES87 5.0(1.0)ES88

Does this look like it fits your scenario?? Just curious because you didn't mention Message Monitor being configured

Which did you change last night, the VM Pilot # or VM Port 1?

It still sounds wonky to me, although I hate to doubt TAC as they've always been very helpful to me. What happens if the

phones in question aren't on Forward to VM but just using FNA or FB to VM? Are we sure they are not on Forward to each other?

Cheers!

Rob

[espereir]

I agree with Rob, have you checked if MM is enabled on the affected subscriber? If that is the case, the patch might help, however, if it is not, it might be something else.

In addition, could you please reproduce the callflow through DNA(Dialed Number Analyzer)? You will need to start this service and then go to https:///dna , here is a guide on how to do an analysis

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/dna/4_0_1/dnaan.html#wpmkr1081588

HTH

--espereir

[maryclegg]

Hi Rob and Espereir,

Sorry it has taken me so long to get back to you. it has been crazy here.  

We do not have Monitor Message and we did not load the patch - did not have time and probably won't do it now.  Anyway:

I was recreating the situation so that I could run the dialed number analyzer and found that the problem is fixed now. Monday night we had to shut down all the computer equipment for UPS repair including all the servers which also included the Call Manager & Unity servers and now since the CM restarted the problem no longer exists. This is the only thing I can think that would have fixed the problem. Was there something in the restart of the servers that could have fixed it?? The last thing TAC did was remove the overlap on 601 but the problem still existed.   See attached.

I really appreciate your help and interest.

I really appreciate your help and interest.

[Rob Huffman · Accepted solution]

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

[espereir · Accepted solution]

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