This is a new one...I just set up a new MICS (7.1) w/PRI. Set public DN lengths appropriately (DN length = 10 for local calls, 11 = long-distance & 3 = 411/911). Absorb length "All". Dial "9" to get out. All outbound calls are working fine.

However, when I attempt to dial 411 I end up ringing 911...? The po-po is getting They're sending someone over to give me some "stick time".

Never had this issue before. Any guess as to what I'm missing or does this sound like a carrier issue?

Note: As a test, I tried dialing "Intercom 9 & 1 1 to see if this would ring 911, but it didn't...call didn't go anywhere. Somehow the system is seeing the "4" as a "9"?

Are you dialing 411 or 9411 ?

Is '9' the only destination code in the system?

Provider might have blocked 411 but they can't block 911 though that is why they might convert 411 to 911 which is suck.

Dialing "9" to get out, then "4-1-1". If I do the same with "9-9-1-1", it works (Dial "9", then "9-1-1"). If I dial "9", then "1-1", call goes nowhere (I thought, perhaps, the system was absorbing the "4"). Must dial 9-9-1-1 to get through to "911" operator.

If I remember correctly (I've been doing this remotely), Destination code is "9." (9/any). There may be other destination codes. I don't have the system in front of me. Have been programming this one remotely via an employee on-site.

I can't imagine they would program something to auto-dial 9-1-1. It's one of the biggest (albeit the worst) providers in the area. I wouldn't be the only one with this problem and 9-1-1 would be overwhelmed with calls for directory assistance.

Side note: I have set these up 1000x before and never had this issue. However, this is the first time I've tried programming a system "blind" (my employee is on the other end of the phone following my instructions). It's different when you can't see what's what...

Since it is a PRi, have the provider climb on the circuit and see what is going out.

The tech at the switch can see digits, translations, etc.

We had a Samsung 500 that would not accept DIDs with a leading digit zero and the people had those numbers for years. The switch "translated" the dialed 0050 and sent the digits 1050 to the Samsung which worked fine.

If they can translate outgoing digits they should be able to translate incoming digits and make you crazy thinking 411 is 911. Easily could be a glitch in the switch, not the Norstar.

Yes, that's where I'm leaning, but I need to be sure that it's not me. I already had to "prove" to the tech that the flashing green light on my T1 card was due to his (incomplete) connection. I always tell my employees "It's never the Nortel!"...

I also agree that the problem is most likely at the provider.

I'll try to help with some basic background from the translations side (at least with the 5ESS).

The way in which a call's digits across PRIs can be stripped and replaced by other digits depends on the direction of the call:

Calls outbound from a CO-
This is handled within the route index assigned to the PRI which handles the call "from" the CO.

Calls inbound to a CO-
This is handled by the IDP (individual dialing plan) assigned to the stand-alone PRI (or an entire PRI group) which provides the call to the CO.

With this problem occurring on a 3-digit call "inbound" to CO, it's very possible that the CO folks may have accidently assigned an incorrect IDP to the PRI's BRCS features list. IDPs are customized features that can be assigned to stand-alone PRIs (and PRI groups) that dictates and performs stripping (and replacing if needed) of certain digits inbound to the CO across that PRI. 5ESS IDPs are built by using multiple "ranges" to specially treat specific inbound digit patterns. If the CO uses a 5ESS, it sounds like the fault may be that either the IDP is assigned but not activated, has an incorrect range assigned for the inbound 411, or has an incorrect IDP assigned all together.

I remember an instance where an inbound PRI Group from a local PBX had an incorrectly assigned IDP. All calls placed to a specific local prefix were mistranslated, sending these calls flying halfway across the country.

Do you have access to, or is there any possible way that a PRI tester (Sunset, etc) can be setup to place a 411 test call directly across the PRI?

Thanks for the informative post. I do not have access to that equipment. When I am able to get on-site, I will call in a trouble-ticket and have the carrier send out a tech.

Why would they have to come out with a TBerd? They can see everything at the switch.

Anyone at that site could get the switch engineer on the line and have them see what is happening when you dial 411.

Why don't you copy and paste Mike's post above and email it to the switch engineer, they could look at it even without anyone making a call.

Bunnie,
My reason for suggesting using the PRI tester at the system side of the PRI was only because I'm unfamilliar with the Nortel MICS, and the test call directly across the PRI from the tester to the CO would confirm that the trouble is definately isolated to the CO side of the PRI. This may also be precisely why the tech wants to test the call across the PRI, from outside of the MICS.

If a trouble such at this occurred in our switches where I work, we would also run a "verify-office" (VFY:OFC,DN=xxxxxxx,DIALED DIGITS=411). The output message would show a snapshot of all translations associated with the entire traced pathway of that call thru a 5ESS.

Danny,
Just thinking out loud..With this being a new PRI: With the 411 calls presently terminating over at the 911 center, has anyone attempted to place a standard 911 test call thru the MICS, just to confirm that the regular 911 calls aren't also being redirected somewhere else?

Yes, 9-1-1 works fine.

5Etek-mike
I understand your reasoning about being on-site. I thought that with just a copy of your suggestion the switch engineer could look at their settings and see if they have a problem. If not, an on-site test with a TBerd would be the primary move.

The provider would still most likely prefer to first send someone onsite. It could be the normal practice of the LEC to first confirm that the digits being dialed (411) from beyond the local system match the digits being sent at the far end of the PRI. Once confirmed, they would then immediately address all translations & digit analysis associated with the 411 call.

Another sidenote about IDPs-

If it's a 5ESS supported LEC, and an IDP is in fact assigned to this PRI, the IDP's translations for the 411 call have already occurred within the PRI prior to the 411 call even being analyzed by the 5ESS. That's why IMHO it's so important to first confirm the sent digits from the far end of the PRI (especially if an IDP is assigned to that PRI).

IDPs are how we provide optional 5-digit dialing for four separate local prefixes between individual subscribers and lines assigned to various PBXs within a large military installation.

Update: I finally was able to get my hands on the system today. I called the carrier and had them monitor the outbound digits. Tech reveals he was seeing "9-1-1" when I dialed "4-1-1". I went in to programming and took out the "9-1" and "9-All", leaving just a "9" under Destination (?) Codes.

NOW, the system dials 9-1-1, 4-1-1 and 6-1-1 just fine, BUT...I don't have to dial "1" before a long-distance call...(we have 10-digit dialing in our area)...? So, it's working, but I am more confused than when I started.

It could be possible that the overlay plan for your 10-digit dialing area may not necessarily require 1+ dialing for long distance calls. I've heard that some of the older overlay plans offered optional 1+ dialing.

I would think that this is probably not the case, unless you're completely new to your area, and were not aware of being offered optional 1+ dialing.

This is the first time I set up a PRI that didn't require a "1".