Hi,

Yup, we have the static route for 91919191 and 92929292 configured. Will have a look at the CVP Error log.

Thnx

Charl

One other thing to do... On the VXML gateway that you have targeted in your 91919191 static route, turn on 'debug voip application tcl' and 'debug voip application script' and 'debug voip dialpeer' Place a call and look at that gateway log. You should see the call arrive to the voip dial-peer you have assigned for incoming called-number 91919191, then you should see the ringtone.tcl script get executed.

I've got the same problem in Canada.

It works in my lab with an FXS card, so I know how to set this up - but not in Canada on a gateway with the carrier Bell Canada. Since the gateways are in production for pass through to a Nortel Symposium and under load, I could not easily run heavy debugs. But I could use a command to show the running applications - and the ringback.tcl was running. I can't recall the exact command.

Mike Oldham said it could be an issue with the bearer channel - not that I know what that is. ;-) But could some Telcos handle this differently?

Regards,

Geoff

ringback.tcl simply plays a .wav file. In that respect it is no different than what happens on the VXML gateway. I don't see how this could be telco dependent at all.

Are *all* callers not able to hear the ringtone, or is it sporadic? Are you routing the 91919191 calls to a single VXML gateway or load balancing to a bunch of VXML gateways?

janet

Janet,

Ah, that last question made me think.

There are 2 gateways at that site. I am routing the label through the CUPS SIP Proxy Server. There are two static routes on this pattern, 1 to each of the gateways.

If the incoming call is on one gateway and the label is being sent to the other gateway, we have a problem. Right?

Since the agents have auto-answer on headset through Call Manager set up, all the testing with normal conditions did not reveal this issue. It was only when I started testing what happens if an agent forgets to press the headset button that I noticed no ringback. I only made a few test calls, and did not hear the ringback on any calls - perhaps if I had made a number of calls I would have heard sporadic ringback.

Regards,

Geoff

Geoff,

No, it will not be a problem if the incoming call and the ringtone are on different GW's. The fact that you are seeing the ringtone execute when you look at running applications on the GW says that at least the 91919191 ringtone is routing there successfully. Several things:

1. Are you sure the ringtone.tcl file and ringback.wav files both exist in flash on both gateways?

2. Is "no ip routing" set on either of the gateways? This setting prevents prompts from being heard.

3. Is this a CMM by any chance? CMM's don't call flash "flash" and would cause the ringtone.tcl file to error.

4. Since you can't set verbose debugs for production, at least Set 'debug voip application error' to see if any errors appear in the GW log.

janet

OK, thanks Janet. That's a relief.

1. Yes. Both the .tcl and the .wav are in flash.

2. No. I just checked and I do not have "no ip routing". I know setting that is verboten.

3. No. These are 3845s

4. Will do.

Thanks.

Regards,

Geoff

Hi,

I had a relook at our configs and low and behold - we were missing the "local static routes" after i could have sworn i saw them there.

Added them in and now things are working fine.

Thnx for the pointers Janet

Good to see you have it working. I liked your comment "i could have sworn i saw them there". That's happened to me too. ;-)

Regards,

Geoff

Janet wrote:

>4. Since you can't set verbose debugs for production, at least Set 'debug voip application error' to see if any errors appear in the GW log.

Unbelievable. There is an error there, saying "no service ringtone configured". But there is the normal settings in the config for the ringtone service. What is going on?

Then I checked the flash and there is no ringtone.tcl but there is a RINGTONE.TCL!! I copied that file to flash:ringtone.tcl and then ringback started working.

All files like the CVP wav files and the tcl files were installed in flash as CAPITAL letters - like HANDOFF.TCL. Some of this was obviously working, but not all. I made copies to flash with the correct lower case names.

How this happened is as follows.

Initially I logged into the gateways and pulled all the mandatory CVP files from my TFTP server. Subsequently, the flash had to be increased to hold B-ACD and to hold (marketing) music for multicast from the gateway (actually does not work with SIP but that's another story).

The engineer who installed the flash used a PC and a card reader to copy the flash from the small one to a much bigger one, and the program must have capitalized some names. Not sure exactly how this all transpired.

Thanks for pointing me in the right direction, Janet.

Regards,

Geoff