Outbound calls do not work with 9.@

[mgvogt11]

We have a 9.@ route pattern that is not allowing us to dial outbound on a non-ios mgcp gateway(6608). If we put a # sign at the end of the route pattern and dial a number with the # sign at the end it will dial outbound. What am I missing?

CCM 3.3 2

6608 blade with 1 PRI registered with Call Manager

[dgahm]

Is it possible you are not waiting long enough? The default setting for the interdigit timeout is 15 seconds. When possible matches still exist the timer will have to expire before the call is placed, unless you use the # to terminate dialing.

If you are in an area with 7 digit local dialing you should set your route filters so that local area codes are not a possible match. Local calls will then go immediately.

[mgvogt11]

We get a fast busy. For some strange reason the # sign in the route pattern is allowing me to dial out. No # sign you get a fast busy.

Could it be a bad load for the 6608?

[mciarfello]

If the route pattern has a #, it expects the user to dial a #, right?

I'm sure many people like the 9.@, but I like to manually specify the route patterns (9.[2-9]XXXXXX), etc. That way, you don't have to deal with route filters.

[mgvogt11]

We have tried that one as well without the pound sign. All we get is a fast busy. We are using a phone in its own partition and calling search space. It will only work if we put a # sign at the end. Is this a bug?

D00403030015 = Device Load we are using for this gateway.

[mciarfello]

Besides looking at a trace file and seeing what's going on, you might take a "stab in the dark" and try putting your route patterns to where you think they should be and restart the Callmanager Service. Do it off hours, of course.

Sounds like something may be getting confused within your route patterns or CallManager is confused. Restarting will clear up the second option.

[jbond_c24]

9.@ is as generic as it gets. To get around interdigit timeout use specific routes.

9.1XXXXXXXXXX and 9.[2-9]XXXXXX for ten digit dialing use 9.[2-9]XXXXXXXXX.

As far as matching up the # sign...there is a callmanager service parameter that states strip # from final called party #. It is defaulted to true.

Hope this helps

[mgvogt11]

That is fantastic but it we can only make calls outbound if the # sign is included in the route pattern and then it forces you to press the # sign when you dial a number. We have used all of the suggested route patterns.

We do not want our users to have to press #. Why do we get a fast busy when there is no # sign at the end of the route pattern, no matter what the route pattern is?

[walad]

go to CCM Administration>Service>Service Parameters

select Server*>Your CCM server(pull down menu)

Service*>Cisco CallManager(pull down menu)

find T302 Timer (msec)*:15000(Default)

change it to 3000 (3 sec.)

this should do the trick for the line to get through after 3 sec. without pressing #

[mgvogt11]

That is a good point but we already have that set to 3000. We have opened a TAC case on this but I will still appreciate any new ideas. I will post the solution when we eventually find it.

[mgvogt11]

***SOLUTION**

After running some traces on the Call Manager we noticed the route pattern looking at multiple route patterns that did not exist. When making a change to the route pattern the DB did not update the change. We could simply reboot the call manager and it would work but any changes to the route patterns would make the problem reoccur.

The solution was to run Engineering Service Pack 13 to resolve the route pattern issue but we ran Engineering Service Pack 54. I ran this on the publisher and then the subscriber after hours. Then installed the jtapi plugin on Unity and our ICD servers. This has resolved the problem. We do not need a # sign at the end of the route pattern to make an outbound call.

[mciarfello]

Glad the reboot worked.

I also remember having to reboot when I was messing around with the voicemail ports. I hope this problem is known to the developers at Cisco and is seen as an important issue to fix. Traditional telecom managers who are trying out IPT don't like to hear about reboots fixing problems. At least the ones I dealt with.

[mgvogt11]

The reboot never fixed the problem it was the workaround. Once you made a change to the route pattern again the problem re-occured.

You must run engineering special 54 to correct the problem completely. The file you need is (ciscocm.3-3-2-es54.exe). The TAC engineer posted this for me. It is a known bug.

Rebooting is a microsoft word for solution.