Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Unity Loop Problem 1

Status
Not open for further replies.

VoIPGuyNSC

Technical User
May 17, 2006
138
US
Got a weird one here folks. So buckle up tight. Its going to be a wild ride.

Here's the scenario. CCM 4.1 and Unity 4.0(5).

InternalUser 1's phone is CFWDALL to VM.
InternalUser 2 calls the pilot number for the AutoAttendant and dials the extension of InternalUser 1 (or uses the Directory Handler - doesn't matter). The call transfer is configured as release to switch. After a brief moment, InternalUser 1's greeting is heard as normal and all is well.

NOW...same configuration, but:

EXTERNALUSER calls in from the PSTN and the AutoAttendant answers. External user either enters the extension of InternalUser 1 or uses the Directory Handler. We hear the nice Cisco lady say, "Please wait while I transfer your call" and the phone hangs up. The call viewer in Unity looks identical for both scenarios with the exception of the original call into the AutoAttendant (The external call shows the ANI and the internal call shows the DN). Can't see anything in the routing rules which would cause this either.

I'm clueless on this one folks. Would appreciate any feedback.

John Lever
Telecommunications
Richland School District Two
 
Anything to do with CSS/ paritions? how does the call route to Unity
 
The original call to the AutoAttendant? Via the extension specified under the Call Handler profile and a pilot number. The gateway in question is in the same Partition as the InternalUser 1, not that that should make any difference. But you have given me food for thought. I'll explore that route.

John Lever
Telecommunications
Richland School District Two
 
We had an issue where calls vai CTI were hitting an app and because the CSS/ Parition were incorrect when making an O/G call from the App via CTI ports they are looping back again into the app
 
More info: The problem only appears to happen at sites registering with the subscriber CM server. The Publisher and Unity are on-site and subscriber is remote. Call transfers from Unity to DNs registered on the publisher work perfectly. Call transfers from Unity to DNs registered on the subscriber fail. And they only fail when the DNs are CFWDALL back to VM. This must be a timing issue. It just CAN'T be a configuration problem.

John Lever
Telecommunications
Richland School District Two
 
No, but I did reset the subscriber and now its working. :) For giggles, though, I had never configured the voicemail dn in the Cisco Messaging Interface app, so I did that as well, but I doubt that really did anything.

John Lever
Telecommunications
Richland School District Two
 
CMI is used for non-Unity configurations. I disable CMI if I have unity.
As for your original problem, what is the link speed between Subscriber and Publisher? Cisco recommends almost a DEDICATED T-1 for SQL replication.
 
100Mb Metro-E. From what I can infer from my coworkers, this happened once before, approximately 6 months ago and the solution was the same.

John Lever
Telecommunications
Richland School District Two
 
If/when this happens again, use DBhelper to check your SQL instance to see if it is a SQL problem. That's what it sounds like.
 
I'll do that. Thanks for the tip!

John Lever
Telecommunications
Richland School District Two
 
Time for an update. This problem has reared its ugly head again and I remembered to check the SQL replication this time with dblhelper. All was perfectly well. I restarted the subscriber CM server again and once the phones registered to the publisher and then back again to the subscriber when it came back up, all was well again for about a day. The problems seems to be sporadic. Sometimes it works and sometimes it doesn't. This is very strange. In addition, one time today we got the "Please wait while we transfer your call" message and the hold music indefinitely. It never transfered. Normally, we get the message and we hear the hold music only for a second or so and then the ringing extension.

My only thought of why the call would simply disconnect is that of timing. If Unity releases the call before CM can establish it.

I guess its time to turn on some debugging.

John Lever
Telecommunications
Richland School District Two
 
Ah ha!

Event viewer on Unity:
=======================
Cisco Unity's telephony component has encountered a serious error.

EXPLANATION:
No reponse was received on port 1 while performing a blind transfer. This is a serious failure, and most likely parties involved in the call will be disconnected. In some cases, further calls on this port will not be handled correctly.


TECHNICAL DETAILS:
Thread 0x000012F0 had a failure on port 1 in method CAvMiuLine::Transfer(eMIU_XFER_RELEASE)

DESCRIPTION: Timed-out waiting for LINECALLSTATE_IDLE after lineBlindTransfer.
DETAILS:
HCALL: 0x00010310
CallState: LINECALLSTATE_CONNECTED
DestAddress: XXXXX.
CALLINFO:
CallerID: xxxxxxxxxx
CalledID: XXXXX
RedirectingID: Unknown
Origin: Internal
Reason: Direct
Trunk: 0.

John Lever
Telecommunications
Richland School District Two
 
I had an issue where the publisher was caching info and writting to the subsriber and causing sproradic problems.
Cisco recomended rebooting the publisher and not the subsciber.
 
It sounds like you have a possible SQL replication issue with the servers or your subscriber loses connectivity with the main site.
First things first. Just because DBhelper says all is good does NOT always mean all is good. Dbhelper is not a foolproof tool.

In addition if your network delay between publisher and subscriber is >40ms you have a big problem. CISCO requires <40ms ping times between the two servers at ALL times. If you have more than 40ms delay at any given time (even for a few seconds at a time) you can have all kinds of weird issues happen. The only permanent fix is to get your network CISCO specs.

Hope this helps you out.
 
The problem has been resolved. It was not SQL replication or latency issues. Our network is 100Mb and 1000Mb Metro-E and private fiber between remote sites. The problem was a flaw in the TSP in our installation of Unity 4.0(5). Once the TSP was updated to at least 8.1(2), the problem cleared right up. I would like to say that I was sharp enough to figure this one out on my own, but afraid not. This one required a TAC case at which point the engineer quickly recognized this as a known problem and pointed me to the solution.

I appreciate everyone's feedback. I certainly was beginning to think we might have some replication issues. Fortunately, that doesn't seem to have been the case.

John Lever
Telecommunications
Richland School District Two
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top