unity 4.2.1 Busy signal after the message

[znaqvi]

Sometime when I get the message in my inbox and I check I will hear the busy signal at the end for about 2 to 3 seconds.

Like to find out where would I troubleshoot this problem ?

TIA,

[Tommer Catlin]

Sounds like there is a timing issue. Have you tested this with different types of calls? See if there is a difference between an external PSTN call to Unity or just internal IP phone to IP phone.

If the voice gateway is hanging up, and Unity is still online recording the message, it is possible the TSP ports are not passing the "hangup" sequence in a timely manner.

But check to see if there is a difference between external and internal voicemails left. If they are same, I would have to say it is Unity or TSP ports.

Check your TSP versions... upgrade to the newest if you can. Sometimes also, a simple reboot helps.

[znaqvi]

Actually Unity is integrated with two sytems NEC and CCM, the problem is between NEC phones to NEC, IP Phone to NEC phone, and the same issue was calling in from PSTN to NEC phone.

Thanks,

[Tommer Catlin]

So you traversing a voice gateway somewhere.

PSTN ---pbx----->voice gateway---->CCM----->TSP--->Unity

Correct?

I would look in your voice gateway that it is handling the calls correctly. You may have a T1 out of sync between the PBX and your voice gateway. Try and restart the MGCP or H323 session that controls the gateway between the PBX. Im sure CCM is controlling this gateway. Maybe a reset will resync the T1 between Voice gateway and PBX.(NEC)

[znaqvi]

PSTN --- NEC --- Unity

There is no gateway involved and in the above scenario and we still get the busy signal I suspect the problem is in Unity

[Tommer Catlin]

so how do you have the NEC integrated with Unity then? PIMG? Dialogic card?

[znaqvi]

Dialogic

[Tommer Catlin]

So your dialogic card could be acting funny. I know these have firmwares that can be upgraded. Im trying to recall if I had this problem with 4.0x... But I still think that the dialogic card is not getting the hangup sequence in time from the switch to notify Unity to stop recording, hence the busy tone at the end. You could run the Learn tones to adjust the patterns Unity is "suppose" to understand for a disconnect. If Learn Tones does not do it, reboot, try it again. These cards are not bullet proof either. If this problem just started, you could have a bad port or bad card. I have seen cards "half fail" or if there was a 12 port card, 3 ports would flake out on me.

When leaving a message, have the UTIM monitor up so you can see the call setup, tear down, etc for vm. It might flag something obvious for you to adjust.

[eschulz]

Since you're only getting a few seconds of the tone, Dialogic is likely detecting it and correctly signalling the disconnect. I don't think LearnTones would help here. The few seconds of tone is about how long it takes for Dialogic to identify the tone. On PBXes where we expect to have to rely on tone disconnect, Unity will be configured to trim out those last few seconds. However, with NEC we expect better than that. The PBX should be using loop-current disconnect signalling which should cause the line to disconnect instantly. You best bet would be to dig into the NEC and determine whether it is sending loop-current disconnect signalling. If it isn't, it should. If it is, then there's a problem with Dialogic not detecting it.

-Eric

[znaqvi]

I also found the following like about Enabling Cisco Unity to Trim Disconnect Tones:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/integuid/nec24sr/itnc24se.htm#wp1260499

I'm going to try this first.

Thanks,

[eschulz]

That is fine if you know your PBX is never sending loop-disconnect. However, it will be a problem if you are getting loop-disconnect intermittently (maybe lines from one of the NEC line cards are sending it while others are not?). With Trim Disconnect Tones enabled all messages will get trimmed, even ones that disconnected immediately. This means you could end up loosing the last 4 seconds or so of someone?s recording.

Also, in general using loop-disconnect is better because if for whatever reason (some hic-up on the line) a disconnect is missed, the Dialogic board can still failback to detecting the tone for that call. However, if a tone disconnect is missed, there is no failback. Unity will leave the line offhook until the conversation progresses through to a hangup state. This isn't really a huge risk when things are working right but it is one reason why loop-disconnect is preferred whenever it is available.

-Eric

[Tommer Catlin]

I don't have Unity in front of me this second, but I thought you could customize the Learn Tones and play with the settings to customize it from there. Otherwise, there may be an updated INI file for your NEC. (UTIM). But if this problem just started, then I would not worry about the ini file and look at the connection between the two.

[znaqvi]

So here is what I did:

I modified the .ini file

TrimDisconnectTonesOnRecordings=1

rebooted the server.

Now when I get the new message the Busy signal is gone; however, Unity the also cutting about second or two of a message at the end.

Thanks,

[Tommer Catlin]

Re-run Learn Tones and test again. I have had to re-run that Learn Tones a bunch of times to get some intigrations to work correctly.

[znaqvi]

That is what I'm going to do tonight.

Thanks,