Outside callers don't receive opening greeting

[sgamer]

When external users call in to voicemail they should be getting the default Opening Greeting (i.e. Hello, Unity messaging system...) but all they get is silence. When pressing the "messages" button on IP Phones that are NOT registered in Unity I get the default Opening Greeting. Oddly, everything else works in both situations such as pressing * for signin and 0 to transfer to the operator. At that point, the prompts are heard by both users.<br><br>Why does the opening greeting play for IP Phones but not for external callers?<br><br>

[kechambe]

I bet you have an IOS gateway...

Do you have a router (2600, 3600, etc) with more than 1 ethernet interface? If so, you need to bind the voice to one physical or loopback interface with the 'h323-gateway voip bind srcaddr' command.

Does the Unity have more than 1 NIC? If so, disable one of them.

Try adding the 'voice-rtp send recv' command on the ISO gateway. Also, depending on the ISO your running the command could be hidden.

If you don’t have an IOS gateway or that doesn’t solve the problem let us know.

Keith


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

[sgamer]

An update to the problem is that it started working just after I sent this message last night but failed again this morning. I just called it and am getting dead air while the greeting should be playing. Again, if a valid key such as *, etc. is pressed, it does go to signin and the voice prompts are heard from that point. It should also be noted that there are no known problems when calls go to subscribers voicemail which suggests (at least to me) that the router/gateway isn't the problem. It is an intermittent problem but fails way more than it succeeds.

The response to your questions are as follows:

Client has 2 fastethernet interfaces:
interface FastEthernet0/0
ip address 172.20.1.1 255.255.255.0
h323-gateway voip bind srcaddr 172.20.1.1
!
interface FastEthernet0/1
ip address 172.20.2.1 255.255.255.0

The Unity server has only one NIC (The customer looked in the network properties and saw only one NIC).

'voice-rtp send recv' is present in the config.

[#4]

In the "dead air" condition, if the caller can get a prompt to play by hitting a DTMF, then it doesn't sound like there is a gateway config issue. It doesn't even really sound like the traditional one-way audio conditions we commonly see. With those cases, you usually don't get any audio, even after pressing DTMFs.

This might be a good candidate for traces and TAC.

In the meantime, I would look into things like...

1.Does this ever happen when Unity's port 1 is free?

2.If there is a call on Unity's port 1, and another caller calls Unity's port one (and the call rolls to port 2) , what happens?

3.Has there been any modification to the routing rules?

4.Can the problem be reproduced with an IP phone who's extension is NOT a Unity subscriber?

Steve Olivier
Software Engineer
Cisco Systems

[sgamer]

Thanks and here are responses to your questions:

1) I believe it doesn't matter which port the call comes in on. I'll check that again.

2) I believe the same thing. Again, I'll check for sure.

3) No modification of the routing rules.

4) The problem doesn't exist for an IP phone that is not a subscriber.

[#6]

A couple of other things...

Open the CallViewer and record the "Dialed Number" "Calling Number" and "Forwarding Number" when the caller hears silence AND when the caller hears the correct opening greeting.

Is the data the same? Different? I would expect the Dialed Number to change depending upon which Unity port lands on. That shouldn't cause problems, but the more data we have, the better.

Just for my clarification, when the caller hears silence, and then presses the * key, does the greeting start from the beginning, or does it cut in from the middle?

Is this a dual-switch intgration?

Steve Olivier
Software Engineer
Cisco Systems

[sgamer]

I should also mention that there is no forwarding number in either case.

[#8]

Have you upgraded your key recently?

Check that you have "TAPI" as the integration type on the key using KeyDump in the Unity program group. If this is something like "none" we will strip the calling and called information out of the integration information on purpose (i.e. we disable integration features if they haven't been purchased). If that's the case we can get you an upgrade code pretty quick.


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

[sgamer]

Hi Jeff,

It is set for TAPI and everything else looks like it should.

[sgamer]

I'm not sure where to post this but wanted to let you all know that this issue is more or less resolved. While getting conference calls to work with outside callers we noticed that g711 wasn't configured on the VOIP dial peers for the customer DID's (Software based transcoders support g711 only). Even though the CM regions were set to g711 for all relevant partitions and Unity is setup to support g711 and g729, the problem went away when we made this change. I did run across another issue trying to upgrade to the 126 patch but I'll repost that. Thanks to all for your help.

[sgamer]

I'll have to check the call viewer for the number information. When callers do not recieve the Opening Greeting and press the '*' to signin, they never hear any part of the Opening Greeting. They do hear the appropriate prompts after that such as the Signin prompt or Operator prompt.

[#12]

Do you have a DTMF ID assigned to the opening greeting call handler?

Steve Olivier
Software Engineer
Cisco Systems

[sgamer]

Do you mean a number configured for "Extention (optional)"?

[#14]

Yes.

Steve Olivier
Software Engineer
Cisco Systems

[sgamer]

No it wasn't but I coded it with the 4 digit extention of the voicemail DID and it didn't help.