Cisco Unity does not "hear" phone input

[PvanBreda]

I have a user that travels oversees regularly. He is complaining that when he is in the cisco unity system it does not pick up the option he is choosing on the phone.

I have been unable to reproduce the problem, but oviously I have not travelled oversees.

Anyone experienced a similar problem ? Is the a digit wait timer I can increase - because maybe the tones are delayed in transmission throught the different carrier networks.

Peter

[benng]

Hello Peter,

From the description is sounds like the Unity server was not able to pickup the DTMF tones when the user is calling from overseas.

You should first ensure that out-of-band DTMF relay is enabled between your Unity Server and your PSTN gateway:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps2237/products_tech_note09186a0080094607.shtml

However, there is also an rare possibility that the DTMF tones are already distorted as they enter your PSTN gateway (after travelling a long way through the global PSTN network), in that case, there's little we could do.

But, the good news is that most of the similar problems I have seen has to do with DTMF-relay not being configured properly on the gateway. So that is a good point to start.

-ben

[oksiazek]

More simply , put the command :dtmf-relay h245-alphanumeric on each voip dial-peer and it will work ...

Olivier

[PvanBreda]

Actually I already have this command on the IOS Gateway that supports out long distance megacom T1's.

The call though is coming in via one of 3 local T1's that are connected to a T1 blade on 2 different catalyst 6513's.

Is there a way to make sure dtmf relay is enabled on these.

What is curious is that I cannot reproduce the problem, It also apparently only happens after he has been transferred to a user and receives there voice mail after he has spoken with one user.

Thanks Peter

[benng]

Hello Peter,

Out-of-band DTMF relay is enabled by default for the 6608 gateways. We should be able to see the dtmf digits coming in from the CCM trace.

I agree the challenge here is to recreate the problem, I could first enable detailed CCM trace, then request users travelling overseas to write down details of any failures (time of occurance, calling/called number, call flow, etc)

If no users are going overseas in the near future, maybe we could ask any local contacts in those countries to make a few tests calls for us.

We could then go into the CCM trace to track the call and hopefully find out the root of the problem.

-ben