cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
800
Views
0
Helpful
21
Replies

Message length

admin_2
Level 3
Level 3

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>

21 Replies 21

Not applicable

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)

Not applicable

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

Not applicable

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)

Not applicable

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.

Not applicable

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

Not applicable

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

Not applicable

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)

Not applicable

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

Not applicable

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)

Not applicable

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

Not applicable

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)

Not applicable

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

Not applicable

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)

Not applicable

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: