×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Message length

Unanswered Question
May 16th, 2001
User Badges:
  • Bronze, 100 points or more

We have several subscribers that will not accept a message from an outside caller that is longer that approx. 12 seconds. The setting is currently set to 180 seconds. Increasing or decreasing the setting does not change the symptoms. Messages from subscriber to subscriber is working properly. <br><br>Is this a known problem? We are running Exch 5.5 SP3 and Unity v2.4.6.102.<br><br>Help!!<br><br>Thanks,<br>MIKEC<br><br>

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Anonymous (not verified) Sat, 05/19/2001 - 09:02
User Badges:

No, this is not a known problem and I'm kinda skeptical it's a bug... sounds like a configuration issue or some sort of problem with your switch handling calls from the outside or something along those lines.

Which value is set to 180 seconds? by default the message length for outside callers leaving messages is 300 seconds... subscribers leaving subscribers messages have a different message length which is configured in their Class of Service pages.

so on the subscriber's pages in the SA, on the "messages" the field that says "Taking messages from outside callers", the value is 180? If that's the case, I doubt Unity is the source of your problem. What's the next thing you hear? If it just says "thank you" and moves on to the after message edit menu then it's not Unity cutting the user off because we think their maximum record time as been reached (we'll tell you that specifically).

Can you leave a message as an unidientified user (i.e. an outside caller) from an internal line and it'll still cut you off at 12 seconds or does this only happen when you're calling in from the outside?



Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous (not verified) Mon, 05/21/2001 - 06:25
User Badges:

It seems to have something to do with the sensitivity of the Dialogic cards. It only happens when an outside caller calls into 2 of our PBXs. These PBXs are trunked to the main site (where the voice mail server lines) via T1 links. When I duplicate the problem, I cna hear a distinct drop in volume when the call rings-no-answer and transferrs to vmail. As long as I speak-up the system doesn't cut me off but if I speak too quietly the system will interrupt the message and I have to touch 5 to append to the message. I have set the Dialogic quiet parameter to quiet50.prm but it didn't help very much.

I think it's a PBX issue unless you thing there is something else I can adjust.

Thanks,
MIKEC

Anonymous (not verified) Mon, 05/21/2001 - 07:48
User Badges:

If you've got it cranked down to -50db that's as quiet as Dialogic can go... there isn't anything else I know of you can adjust on our side to get it lower than that and I don't think you'd want to even if you could (we'd never be able to tell when someone stopped talking).

I think you're right to pursue the PBX end of the house...

Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous (not verified) Thu, 05/24/2001 - 00:51
User Badges:

This may sound dumb but, if the sound is to quiet, why would you add attenution to the line? Wouldn't that make the volume go lower? I would decrase the attenuation on the dialogic card and that would raise the power (volume) of the signal out of the dialogic board.

Please let me know if I am off base or not.

Richmon Schumann MCP/CCNA/CCDA
Cox Communications Inc.

Anonymous (not verified) Thu, 05/24/2001 - 01:08
User Badges:

The quiet parameters they are speaking of don't adjust volume on the Dialogic card. Those parameters will adjust what Dialogic considers to be "silence". Since there is never really true silence on the line, there is a threshold of noise that Dialogic will consider to be "silence". If a call's noise level falls below this level of "silence" for too long, Dialogic will consider the call disconnected.

The parameters lower that threshold so the call would have to be really, really quiet to fall below the new lower threshold.

Steve Olivier
Software Engineer
Cisco Systems

Anonymous (not verified) Thu, 05/24/2001 - 10:34
User Badges:

The PBX vendor (Avaya) thinks I'm full of horse-hockey. Their response to this problem is "it wasn't happening with Audix (our old vmail system) so it's not our problem". Since my original post, I have determined that it is happening with ALL of our remote PBXs. Our old Audix system is still up and running (not utilized at all) and I cannot duplicate the problem with that system. This problem SUCKS and our users are beginning to use the same word for Unity. I need to fix this ASAP.

I have opened a case with TAC but it took about three days to get a response and that was only after hanging on hold for a couple of hours. What's the freakin' deal with TAC support??? I always have superb support for Cisco's networking products via TAC and can't understand that lack of support for Unity.

When I applied the quiet50.prm setting to the dialogic configuration, I followed the instructions as listed in the Unity help file. These instructions did not inducate that I should cold start the vmail server - I only stopped Unity and then the Dialogic service, made the change, and then started the Dialogic service and then Unity. I did not notice ANY difference at all. In order for these changes to take effect, should the server be cold-started???

Sorry for the rant....
MIKEC

Anonymous (not verified) Thu, 05/24/2001 - 11:03
User Badges:

I always restart the box when you do this... I believe it's necessary. If you're taking that much heat on the problem it seems to me you'd go the safe route and reboot the box (any particular reason you didn't?).

The Quiet parameters do work... we use them all the time.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous (not verified) Thu, 05/24/2001 - 11:13
User Badges:

The reason I didn't reboot the server is because I had a small window to make this change. I was told that a cold-boot of the server takes nearly an hour because it validates every mailbox on the system when it restarts from scratch. I couldn't afford to wait this long so I followed the instructions.

I plan to cold-boot the server late tonight.......

MIKEC

Anonymous (not verified) Thu, 05/24/2001 - 11:16
User Badges:

unless you have a BUNCH of users (i.e. many thousands) I don't think the startup is going to take that long. We load the subscriber and call handler cache off the disk and we compare the universal number for each with the one in Exchange to determine if there have been changes on that user's record in Exchnage since the lat time we checked. If there's been relatively small numbers of changes, this should go through pretty quickly.

the first time we come up after install and we initialy build the cache, it can take a while. But just doing a reboot shouldn't take nearly as long.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous (not verified) Fri, 05/25/2001 - 05:30
User Badges:

I cold-booted the server last night and the problem still exists......

Anonymous (not verified) Fri, 05/25/2001 - 07:14
User Badges:

The best I can tell you is TAC should get you setup with some MIU traces to determine WHY the calls are terminating. It sounds, though, based on your statement that if you speak loudly the problem isn't there that it's volume related. If you're down to -50db as the silence threshold I'm finding it real hard to believe the voice energy coming in from any source is lower than that and still audible on the phone at all... -50 is pretty darn quiet. Perhaps something else is at play. Those traces will at least prove what the terminating reason is.

Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous (not verified) Fri, 05/25/2001 - 09:34
User Badges:

Just to set some expectations here...don't get mad at me Jeff.

The MIU traces won't tell why the call disconnected. The MIU "sees" a disconnect even from Dialogic if it was a detected configured disconnect tone, silence, or a DTMF. Unity won't get a disconnect reason, just a disconnect event (and we have had a long battle with this one here). There is a spot to fill a disconnect reason in the TAPI disconnect event message, but no one we deal with uses it!!!

As far as the disconnect goes, the MIU will tell you when, but not why.

To find out why, the debug Dialogic TSP needs to be run. The returns from the Dialogic debug TSP only make sense to some one that is intimate with Dialogic API. There are only a few engineers at Seattle Cisco that know that stuff. I can say whole-heartedly, I am not one of them.

So, if approaching TAC with the reason for WHY the disconnect happened, head for Dialogic debugs, not MIU.

Steve Olivier
Software Engineer
Cisco Systems

Anonymous (not verified) Sat, 05/26/2001 - 07:20
User Badges:

Hmmm... it must have been the debug TSP stuff Erich was looking at for us at with that Mitel site Mark was on a while back then... turned out we were getting tones back in some cases on calls from the outside which was resulting in termination after we had banged our head on the db level for days one end... I had thought these were nicely wrapped up MIU traces. Learn something new every day.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous (not verified) Tue, 05/29/2001 - 04:43
User Badges:

uhhhhhhh......so what's the verdict???

Anonymous (not verified) Tue, 05/29/2001 - 07:05
User Badges:

For setting up logs to determine the reason for a disconnect, the Dialogic debug TSP will be needed. MIU traces will not tell why the call disconnected. TAC should be able to help out with getting this set up.

Steve Olivier
Software Engineer
Cisco Systems

Anonymous (not verified) Tue, 05/29/2001 - 07:12
User Badges:

Is this type of "disconnect" the same problem that i am experiencing? I am not being disconnected, the call is being interrupted by Unity because it can't hear anyone speaking. The caller is asked to send the message or touch 5 to append to the message. The call is NOT being disconnected.

Anonymous (not verified) Tue, 05/29/2001 - 07:42
User Badges:

My apologies. I don't quite know why I started thinking this was a disconnect issue. I tend to wander from time to time.

The MIU traces will show that we recieved a "max-silence" event from Dialogic. That will confirm the behavior that the customer is experiencing, but doesn't do a whole lot to resolve the problem.

It sounds like there is an open issue with TAC on this? This is starting to sound like something that TAC should actively be involved in and monitor.

Steve Olivier
Software Engineer
Cisco Systems

Anonymous (not verified) Tue, 05/29/2001 - 08:27
User Badges:

There is a TAC case for this problem (B457081) but there is NO discussion like this. They are pushing this to my PBX vendor and my PBX vendor is pushing it to Unity...

Anonymous (not verified) Tue, 05/29/2001 - 08:54
User Badges:

As far as configurable parameters on Unity, TAC doesn't have much to configure. That silence paramter is pretty much all we have to work with.

Has the issue been approached to PBX support like this...

When extensions on the remote switch call extensions on the local switch, people on the local switch complain that they cannot hear people on the remote switch. If there is a noticable drop in dB when a remote extension calls a local extension, that certainly seems like a legit issue to bring to the PBX folks.

It might be useful to attack the problem with a voice mail system out of the picture. I am assuming there is a way to adjust the gain on the connecting T1 trunks from system to system.

We can certainly have TAC gather debugs and traces, I am just afraid they are going to tell us what we already know.

Steve Olivier
Software Engineer
Cisco Systems

Anonymous (not verified) Tue, 05/29/2001 - 09:07
User Badges:

We first approached it as a vmail problem and called Cisco. When we found that the quiet parameter is basically the only thing to configure we contacted Avaya (PBX vendor) and asked them to crank up the gain. When Avaya heard that we were experiencing the problem on the vmail system, they asked if Audix, our old vmail system, had the same problem. The answer is no. They said it was "stupid to increase the gain on the T1 links in order to compensate for an apparent defficiency in the Unity/Dialogic solution". Actually, at first they said it was not possible to increase the gain on the T1 and Now they say it is possible. They are currently looking into how to increase the gain and we are using voice-to-voice calls to test instead of voice-to-vmail.

In the mean time I'm stuck in the middle...Thanks for your support.

Anonymous (not verified) Tue, 05/29/2001 - 00:34
User Badges:

Some comments on this issue:

1. There is one other thing you can do from the Unity side to make it more receptive to quiet calls. You can increase the pause-off times on System->Configuration->Recordings in the SA. This won't lower the silence threshold any further, but it will extend the number of seconds of (perceived) silence before Unity cuts the user off. This can help out in situations where the voice is occasionally lound enough to break the threshold. If you increase the Long & Short recording parameters to 5 or 6 seconds, it may make somewhat of a difference.

2. Since the lines are analog at the point they hit the Unity, you should be able to clip on with some sort of signal monitoring equipment which can provide you with details about the noise level of a local PBX call vs. a remote PBX call. This way you'll know for sure that there is or isn't a gain control problem, and you'll have some idea of how much adjustment is necessary to level everything off.

3. Keep in mind that whenever you are adjusting the Dialogic quiet parameters, those settings get applied to the board during Dialogic initialization. You ought to be able to get away with stopping Unity, stopping Dialogic services & restarting, then restarting Unity -- but it's always cleaner to power down and reboot if you can spare the time.

Actions

This Discussion