cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
316
Views
0
Helpful
10
Replies

Skipping Greeting

admin_2
Level 3
Level 3

One of my installations that is running CM3.0.8, TSP .32 and Unity .126 is having the following issue:<br><br>"I dialed my number 4 times. The first time a got my greeting, the other times I got the a system message saying "please leave a message after the tone". I also went in an re-recorded my greeting, but it did not help."<br><br>Has anyone run into this and, if so, how can I fix it?<br><br>

10 Replies 10

Not applicable

Was this system originally installed with 2.4.6 102 and TSP 1.0.0.28? Did you make the routing rules change to fix the problem with calls being reported as forwarding when they hit port 2 or higher even though it was a direct call?

if so, please follow the release not instructions for reapplying the default routing rules to the system using ConfigMgr.exe... sounds like that's probably the case here.


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

We did upgrade from 2.4.6.102 and 1.0.0.28 to the latest greatest but I didn't make any routing changes that I recall. Per your response, I ran "ConfigMgr" for the first time. Where do I look for information regarding changing the default rules?

Previously, the only thing I changed outside of the "System Administrator" was in the "Rule Editor." Cisco TAC told me to change the Default "Call Handler" from "PortID==1" to "PortID==*" if that has anything to do with anything.

Not applicable

yes, that change TAC had you do was a temporary work around for a problem in TSP 1.0.0.28 that's fixed with build 126 of Unity and 1.0.0.32 TSP.

When you Run ConfigMgr.exe, select to run the routing rules and browse to \commserver\localize\DefaultConfiguration\ENU\DefaultRules.DCS.

Once you do that you need to restart Unity and the rules should be back to default.

This should be covered in the release notes for 126 or 1.0.0.32... if not, let me know and I'll go bark at someone about it.


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

I checked into this further and the original fix was to replace the Reason==1 with Reason--*. The current setting is Reason==1. Isn't that what it should be for CM 3.0.8, Unity 2.4.6.126 and TSP 1.0.0.32?

Not applicable

yes, that is what it should be.

I'd still like you to apply the default routing rules before going any further with this one. Any site that has touched the rule editor may have inadvertantly arranged the order of the rules (they are all stored in one file even though they're shown in two sets on the SA). Generally I want every site that made that change any any time to reapply the default routing rules when they upgrade to 1.0.0.32 and 126... it removes all doubt and makes sure we don't waste time chasing a problem that's already fixed.


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

I ran the default rules, shutdown Unity and then rebooted the server but the problem is still there. An update to the problem is that it only happens when dialing in from the PSTN. IP phone to IP phone works everytime we've tried it. I opened a TAC case in the meantime but we don't seem to be getting anywhere. Do you have any other suggestions?

Not applicable

Check the Unity CallViewer.exe when a call is made from the PSTN. What shows up for the calling party when this call is made? I seem to remember hearing something similar to this one before.

Steve Olivier
Software Engineer
Cisco Systems

This appears to be an issue with the G.729 recorded messages, CallManager, IOS gateways and the Unitys transcoding.

The current workaround it to set the record codec to mulaw with the setrecordformat utility. This utility resides in the \commserver\utilities directory. Effected users will need to rerecord their greetings. Also, your Unity will still be able to accept both G.711 and G.729 calls without incident.

I will do more testing on this issue this weekend and post any findings I have.

Keith


Keith Chambers
Customer Support Engineer
Cisco Systems
kechambe@cisco.com

A problem that may be related (I reposted) is that while the skipped greeting is fixed, long messages left for users seriously degrade starting 10 to 15 seconds into the message. This lasts for about 10 seconds and then it clears up and is fine. Last night the TAC had us download "g711 quiet prompts" to install. I really don't know what this is going to do for us but the file is corrupted and I'm currently waiting for a callback. Suggestions are always welcome...

Not applicable

Ah... now there's a good clue.

I'll betcha the gateway is sending us a digit or something which causes the greeting to be skipped... The statusmonitor.exe application should show this happening if you watch the call flow.


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

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: