We just ported 9 offices and about 800 numbers between all offices.

I've found only 2 problems. We have a "backdoor" number at each site that allows agents to get voicemail external. Each backdoor number is setup in call routing and points to off node application with the specific greeting for that office.

After porting 2 offices no longer work. It seems as if the number is bypassing the call routing table and just ringing the front desk.

Programming hasn't changed and everything looks to be correct. These numbers worked previously. Is there possibly a glitch after porting that may be occuring? I'm going to delete the entries and recreate and see what happens but I don't expect that to change anything.

Also, We have a 2nd call routing table for night mode. The number in question does ring the correct off node applicaiton in night mode using call routing table 2.

Even after removing and recreating the entry in call routing table 1 it does not work. It still rings the front desk

If it's ringing the front desk, then it's present on that particular span. I would verify the amount of digits that you should be receiving for that particular number.

Also, verify that the DNIS digits don't conflict with another number that has been ported maybe.

Sounds like you're not receiving the digits that are expected. Check with the carrier to see what they're sendidng.

What does the display read when the call arrives at the front desk? What does that match in the routing table?

I don't see a conflict in the call routing table. The call routing table Patter is using the last 4 digits. Is that the number of digits expected? Or would that be found somewhere else?

The Patter does match the last 4 of the number and no other number in this system has those 4 digits.

Did some monitoring:

1700 94408 RG 484-302-0000 215-362-1234 15:13 00:00:15
IN 1700 94408 484-302-0000 215-362-1234 15:14 00:00:18 $00.00
1700 94407 RG 484-302-0000 215-362-1234 15:15 00:00:03
IN 1700 94407 484-302-0000 215-362-1234 15:15 00:00:13 $00.00

Where 1700 is listed it should be 2528. I have tried adding the CRT3 deleted it from CRT1. Makes no sense. When system is in night mode CRT2 is used and it rings correctly.

Any idea why only these 2 numbers would fail in Call routing table 1? Both numbers in question work in Call routing table 2 when system is in night mode.

I don't think it would be an expected digit problem because it works in night mode.

Is there something higher on the routing able that would grab the call first? The “E” and “+” entries should always be the last ones on the bottom of the table.

Again, what does the display on the operator phone read when the call is presented? That should give a clue as to how the call is getting there.

E and + are at the end. The operator phone shows the caller id of the number calling in.

I have just tested numbers and actually none of the number in the call routing table are working. Something is very wrong.

Ok I see the problem. Has to be with router and digits it's sending. I changed the pattern on the CRT to 10 digits and now everything works. Where on the T1 card in db do I change this so I don't have to change all the CRT patterns.

You can't.

The number of digits in the table needs to match what the carrier is sending.

If they didn't follow your order, make them fix it. If you ordered it wrong, you fix it.

Well we did 9 sites and only 2 are sending 10 so I think it's safe to say carrier screwed up.

Sure sounds like they screwed up. However, it would actually be faster for you to fix the tables than fight with the carrier.

You could add the leading six digits in each table in just a few minutes. Here’s how:

Fix the first entry. Now right click and copy just the first six digits in the pattern.

Left click on the next entry and press [Home] to move the cursor to the beginning. Right click and paste the digits in.

Repeat as necessary – you could get the entire table fixed in no time at all.

We can safely say that this is resolved but a question for you guys with years of experience. In most of our locations we have multiple exchanges. I would think that going with 10 digits should be protocol here. Using only 4 digits could at some point cause conflict. Is it safe to assume that with multiple exchanges we should be using 10 digits as good practice?

Yea I actually did that before I saw your post but thank you for the information. I've changed it at both sites. Problem now is the owner just sent an email to Verizon telling them to change it to 4. Ugh! I am not a PBX expert but common sense would tell you, multiple exchanges, 10 digits is best practice to avoide conflict. At least I'd assume that to be the case, he just never listens.

I would agree that 10-digit patterns are a good idea, for the reasons you mention.

Back in the day, we used 3-digit DNIS and ran into very few conflicts. Of course, that was before sites were networked.