PRI 4 digits to 10 digits. Problem?

chmorin

I'm not very familiar with the logistics between what I needed to do as far as gateway configurations when changing the number of digits the PRI sends in from 4 to 10 into the gateway.

Any calls from the outside to inside would result in the number not being valid. And any attempt to get dial tone from an internal phone resulted in a busy signal.

We eventually reverted back to 4 digits and after some research realized that we don't even need to change to 10. But I'm still wondering, what on earth did I need to change to get it to work? I have a "9.@ route and I tried to change incoming digits from any" to "10". I ran some debugs and, now that I'm writing this, I wish I had written down the results from debugging the t1 line. I'll update if I can remember, but if I remember correctly they were indicating an issue with information either being received or sent. I obviously needed to change something.

So... what was it?

Luckycharms

where to start, where to start...

Just so I understand exactly what you are trying to do, you are having 4 digits come into a IOS h.323 gateway via a PRI and want to expand a 10 digit internal phone DN. Is this a UC or Express setup??

chmorin

Luckycharms wrote: »

where to start, where to start...

Just so I understand exactly what you are trying to do, you are having 4 digits come into a IOS h.323 gateway via a PRI and want to expand a 10 digit internal phone DN. Is this a UC or Express setup??

Terribly sorry, I had asked questions here in the past so I assumed some things I shouldn't have.

We are using a 4.x version of Call Manager. It is an MGCP gateway.

Actually I just thought of something. If we changed the received digits to be 10, would our ability to have 4 digit extensions on phones go away and cause the ones with the 4 digit extensions to no longer work?

Luckycharms

Ultimately you can do almost any digit manipulation you want but the simple answer would be yes.. If you have 4 digit extensions and you set the incoming digits to 10 then with out some translation pattern then you would have a problem.

shodown

I hope I'm understanding you, but the carrier usually delivers 4 numbers to you. You buy a 10 digit, but they usually only give 4 unless you setup DID which is rare.

Also why do you have a 9.@ pattern?

You should close that up to local, LD, INT calls. It can get messy leaving it so open.

chmorin

shodown wrote: »

I hope I'm understanding you, but the carrier usually delivers 4 numbers to you. You buy a 10 digit, but they usually only give 4 unless you setup DID which is rare.

Also why do you have a 9.@ pattern?

You should close that up to local, LD, INT calls. It can get messy leaving it so open.

The 9.@ was done by a previous party. We are in the process of an 8.0 CUCM implementation and it will not have 9.@ in its route patterns. We just don't want to mess with what ain't broke, and what is going to be replaced this month.

Thanks for the help, I'm pretty sure I would need to configure some form of discarded digits as well as translation patterns to make internal and external calls work.

And we were setting the PRI to send in all 10 digits, instead of just the 4 in the DID range we have. This was because of some call routing problem we thought we had. We found out it was a non-issue, but I'm still curious.

So instead of just sending in YYYY, it would send in XXXXXXYYYY.

Luckycharms

Well the easiest way to fix you problem would have been to have the DN's in a PT-A and then have a Xlate with a 10X-to-4X translation pattern in another PT-B. And then have your CSS with PT-A then PT-B in that sequence. Then the gateway would have looked for the 10digit DN then fallen over to the Xlate after no exact match was made and then searched the CSS again. This configuration is done with a lot of assumptions.

CSS - GW-INBOUND
- PT-A - (10 and 4 digit DN's)
- PT-B - (10digit to 4 digit Xlate Pattern)

* well you don't actually need the extra PT but I think its easier to read.