MICS 6.1 XC Previous Vendor Nightmare!

[daveinfla]

I'll preface this post by stating I have very little experience with PRI's on an MICS and even less with building routes.The vendor that installed the PRI apparently knew even less.

My customer has an MICS 6.1 XC with a PRI installed. There is also a DS card which isn't currently being used.

The problem, for some reason the previous vendor has configured the PRI in such a way that the customer is required to dial 99 for an outside line.

I glanced at the programming, btw I have it backed up to an Excel Workbook if someone wants to look at it, and spotted two items I just don't understand.

Route 001 = PRI-B (Why B and not A?)

Dest. Code 001 = 9A Uses Route 001 (What the heck is 9A?)

I think the issue my have something to do with their DID's. The telco is passing the last for digits and two of the numbers end in 9xxx, one of which is 4xx-9684 the other is 9xx-9700. Now the 9684 is programmed and seems to work, however the customer recently wanted to point the 9700 number to a station but programming rejects it saying it's an invalid Rec'd #. What gives?

What is it going to take to correct the PRI dial 9 issue and the DID issue?

Thanks,

Dave

 

[jeffkoeh]

can you change the dest code to 8 and remove the 9?

that will fix your target line problem also

 

[daveinfla]

I guess I could, however is there anyway to avoid this. I'd like to stick to industry standard, dial 9.

The 9 appears as 9A, what is that about?

Why would the PRI be setup as PRI-B vs. PRI-A with only one PRI?

Thanks,

 

[hawks]

It appears as 9A on the spreadsheet correct? If that's the case then 9A means 9any. What is the absorb length for that Desti Code? You can out that Desti Code and rebuild it with just the 9 as long as 9 by itself is available.

 

[daveinfla]

Yes it appears as 9A in the spreadsheet.

The absorb length is set to ALL.

Refer to my original post about the DID's, I believe the DID's with leading 9's is causing an issue, however I don't have enough experience with Dest. Codes to know how to program around this.

I'd like to get them back to dialing just 9, NOT 99, to get an outside line.

Thanks,

Dave

 

[DigitelD]

The PRI provider can send you 4 digits without the 9. The caller would still dial the number with the 9. For example, DID number 555-9191, this is what the caller dials, the provider can send you 8191. We have this setup with a customer. You need to stay away from received digits that start with 9. When you get this resolved you can resolve the other issue.

 

[hawks]

why is the absorb length set to all? That means that you are absorbing the 9 plus the next digit that you dial.
EX: 9555-1212 the only thing that goes out is 55-1212.

 

[DigitelD]

You still need to resolve the leading digit of 9 issue, but I agree with hawks on the absorb length.

 

[daveinfla]

As I mentioned above I didn't set this mess up and have limited experience with routing.

Your example about the absorb all explains why the customer is required to dial 99 to get out, I guess?

However, what does a DID with a lead digit of 9 have to do with outbound routing?

Is there a way to fix this without having the CO make changes, I have read other posts that talked about the CO sending 8 vs. 9, however can't some sort of translation at the customer site take care of this?

Also, can someone answer my question about the PRI appearing as PRI-B vs. PRI-A. If it's the only PRI in the switch shouldn't it be PRI-A?

Thanks,

Dave

 

[phoneguy427]

I guess the guy that set up the PRI liked the letter "B". It can be either, "A" is the norm. Norstar doesn't play nice with a leading did digit of 8,9 or 0. According to Nortel it is because 8 and 9 are access codes and 0 is operator code. CO will do digit manipulation to change leading digit of recieved number.

 

[daveinfla]

Sounds like the way to go.

Weird thing is one of the DID's does start with a 9 and it's working some how...

Do the destination codes apply to incomming DID digits as well, is this why they don't like 9 as a leading digit?

 

[phoneguy427]

Yeh, something strange about the way Nortel designed the software, I had the same problem and they couldn't explain why, they said thats just the way it was designed. Very odd you have one working, it shouldn't.

 

[senk1s]

PRI - can be a,b,c,d ...its the installers choice

so to say, there is no separate dialplan for o/g and i/c trunk digits

thats why if there is a 9876 on a target line, there cannot be a dest code 9876

BUT you can have 9877, 9875 etc

Hope this makes sense

 

[daveinfla]

Actually what started all this is the fact that the 9876 Rec'd # is working but when the customer tried to add 9700 as a Rec'd # the switch wouldn't allow it. You would think that if 9700 was a dialplan conflict wouldn't 9876 also be a conflict?

I figured if I was going to look into fixing this I'd take care of the double dial 9 to get out while I was at it.

The customer informed me today that they had plenty of extra DID's that didn't conflict so they are going to have the telco foward the above referenced (both of them) to conforming DID's, then I'll replace the 9A dest. code with plain old 9.

Dave

 

[biv343]

It's possible if you dig deeper into the 9A destination code and look under the wildcards that 8 will show as "unassigned". That would explain why 9876 works. That's one way to fool things, provided you don't have any local prefixes that start with 8 (such as needing to dial 981234567).

Sure would be nice if Norstar/BCM had an IDC feature like the "big PBX's" do.