I have a customer who has had the same system with a PRI for eleven years. Every year, like clockwork, their PRI goes down and won't come back up. Every time this happens, we have to get Verizon to come out and they realize that the NI2 protocol has somehow been changed to NI1. This happened again this past Monday.

We got them to change it back to NI2, but now they can't dial ten-digit local calls. They are only able to dial seven or eleven-digits. Verizon can't figure out what is going on and has just about thrown their hands up, blaming our equipment as usual.

Keep in mind that we haven't changed anything on the system other than the obvious swapping out the PRI card, etc. How I figured out that it was only ten-digit calls that were affected is a miracle, since they don't have seven-digit dialing in this area.

Can anyone think of something that I can throw at Verizon to get them pointed in the right direction? By the way, the PRI is coming from a DMS100.

Ed on inbound issues they can check table digman, outbound have them run a "traver" from your trunk group and check the calls. Also try marking the calls " unknown" instead of "national" and see if the helps at all

Ed,

I assume this is on a vodavi?! I remeber have to change something from CO to ITU on a cutover not very long ago. I can't remember what it was for the life of me and I don't have remote access for the site right now to look but I thought if I responded to this that the CO/ITU might ring a bell with you.

Thanks, Gary. I tried all three settings (CO, ITU and Unknown in flash 45) while I was on the phone with Verizon as they monitored our call attempts. None of the changes had any effect.

Oh, and yes, it is a DVX+4 that hasn't been touched for years. Verizon broke the circuit's settings and now it has become a vendor issue. The proverbial "MBSWWYPBX". The customer is over $500 into our wasted time on site at this point.

If I had a nickel every time this happened with Magix....

OK, seems to me that carriers like to do housekeeping or otherwise groom their circuits once in a while. This tends to happen over weekends and perhaps more than once a year. It also seems that certain customers always fall prey to this practice (remember that Magix only does Custom and that NI2 is the norm these days).

What I have found in multiple cases is that one way communications--whether from the switch to the CO or vise versa--has ALWAYS been a protocol screw-up at fault.

Tear it down and rebuild if they must...just like they did when they messed up the circuit to begin with. I strongly submit that there is a problem in the protocol config that isn't bi-directional.

Now I'm no C5 guy, but I'll bet Ant or someone could tell you how this happens. All I know is what I've experienced and that experience is solid. It IS a telco protocol def issue.

Ed any resolution? Can they provide a d-channel trap (protcol analysis) if so fwd me a copy

After ten days and numerous conference calls, etc. and thousands of dollars spent on-site for billable technician time, Verizon has basically said that ten-digit dialing cannot be accommodated for local calls with the NI2 protocol in a DMS100 office. Yeah, OK.

The very same protocol that this customer has had in place (and working) since 12/16/2000.

They insist that local calls must be seven digits and all others must be eleven, period, despite the fact that we are in a ten-digit area for local calls.

The customer is frustrated and is asking us to simply reconstruct their ARS/LCR so that the ten-digit dialing that they're accustomed to will be back to normal. They are basically asking us to fake it by inserting/deleting digits. God only knows how the unnecessary 1+ calls will be handled and billed.

Is this pathetic or what? The customer is willing to pay us to make up for the shortcomings of VZ. When does it end?

The story is beyond pathetic. It's downright scary.

Please don't let them get away with this...

They are giving the folks who work for the same company and still care about the customer such a horrid name...

Raise the holy h@ll to Seidenberg if needed, before he retires...

Good luck.

I agree with ajkula! The truth is most of the knowledge has retired or been riffed, leaving only people who try (well, most try)but don't have the background to make things happen.

Best of luck to you and your customer

I don’t know much about the DMS world but in 5ESS we did periodic generic upgrades. Normally customers’ line and trunk translations would be moved to the new generic issue with no problems. Occasionally there would be functions that were not supported as part of the retrofit program. These changes would need to be reapplied manually once the new program was installed. This is a stretch I’m guessing that this could be what you are experiencing. I’d try to find out if the DMS recently had a program upgrade. In the old days paper copies of any unusual translations were kept at the local C.O. or in the center handling the translations for that switch.

I agree with “whynot”. The experience has probably retired or is not able to offer any expertise since the translations work is being handled in a mega-center. Do you have any local Verizon contacts who could refer you to some local technicians who may have done translation work in the past?

Ed, it all depends on how vrz had the standard tables built. We do not do it this way cause of problems like this, but they can block dial patterns by protocol...whybthey do...your guess is as good as mine

Well, here's my update: After nearly two weeks and countless hours on-site or on conference calls with Verizon, they are pretty much throwing up their hands. Their stance is that NI2 is a national standard and that they have absolutely no way to address ten digit dialing. They claim that it could never have worked.

Let's keep in mind that this has been working just fine for 10-1/2 years until two weeks ago.

My choices are now to either make the customer change the manner in which they dial their calls (they are reluctant to do this), or I have to set up LCR tables to convert 10-digit calls dialed to either seven or eleven through digit manipulation. I'm really not looking forward to having to do that. Not so much because it is a lot of work, but because we shouldn't have to do this nor should the customer have to pay us for it.

I swear that in the dozens upon dozens of PRIs that I've installed, I've never ever had one where 10-digit dialing was not permitted. :bang:

Without knowing how your telco switch is setup and capable I would like to point couple things to check on both sides.

With NI-2 DMS100 should accept two methods of dialing TON (type of number).

1. Your CPE marks “Called Party Number” as UNK (unknown). Digits must be sent exactly like is dialed by POTS lines in that area. 7 or 10dgt local, 1+10dgt for LD, 011+ for INTL
2. Your CPE should mark “Called Party Number” as L(subscriber) if sending less than 10dgt, NA(national) for 10dgt, IN(international) more than 10 In that case most telcos accept 10dgt NA for all calls and route calls as local or long distance based on NPA-NXX combination.

Another frequent problem exists if the CO serves for than one rate area exchange. Rate plan assigned to your customer PRI should match their npa-nxx, that’s DMS LTCALLS table. In that situation you could have dialing plan for some rural area different than your city.

At this point I would not waste any more time and ask for Tier3 ISDN support to run protocol analysis and confirm that you both in fact have the same protocol version setup.

Thanks, Markbos for your input. Your comments raised an interesting point. The local CO wasn't equipped to provide PRI service, so they are sending down from a DMS100 about 20 miles north. The host CO has multiple rate centers, but our local one doesn't. I will say that the different rate center is served via an RSC (Lorton, VA: LRTNVAXARSO), from the host (Occoquan, VA: OCQNVAXADSO). I'm wondering if they are following the Washington, DC rate zones instead of the local one.

I just realized that the customer's CO (Stafford, VA: STFRVAXARSO) is also a remote from the same host. For the longest time, I assumed that it was a DSO, considering the sheer size of the area that it serves. That's what I get for assuming.

Still, the rate center (WASDCZ17) where the circuit originates is 100% ten/eleven digit dialing. We may be onto something here.

Well, Verizon continues to dig in their heels on this issue. Here's a nice response sent to the customer by one of the senior people in charge of this dilemma. The customer isn't buying it though:

"Sorry that I am responding so late. Where we left this was your vendor was to get back with the equipment manufacturer to explore a solution.

Here are the details about the issue;

We all agree that this PRI is setup for NI2.
The NI2 standard defines how calls are passed from the PBX to the Verizon Switch;

If the PBX sets up a Call Type as Local, the PBX must send 7 digits.

If the PBX sets up a Call Type as National, the PBX must send 10 or 11 digits.

If the PBX sets up a Call Type as Unknown, the PBX could send 7, 10 or 11 digits.

Basically, the NI2 standard defines the language and specifications that allow the two switches to communicate.

What we found with the Protocol Monitor that we did on 5/5;

When 10 digits are dialed, the PBX sets up the Call Type as Local and sends 10 digits. This is in violation of the NI2 Standard.

When 7 digits are dialed, the PBX sets up the Call Type as Local and sends 7 digits. This is acceptable based on the NI2 Standard.

When 11 digits are dialed, the PBX sets up the Call Type as National and sends 11 digits. This is acceptable based on the NI2 Standard.

Calls are failing because the PBX is not setting up the call properly based on the NI2 Standard.
We looked at another customer's service that your vendor suggested was setup exactly like your system and we found that it was setup for NI1.
We attempted to set your service up as NI1 and your vendor could not get the PBX to bring up the PRI.

Based on our findings from the call on 5/5 with you and your vendor, the issue with your PRI service has been determined to be the PBX. There is nothing further that Verizon can do to correct this situation.

I am on vacation starting today. Please feel free to reach out to me on my cell phone if you have any questions, number below. There are additional center management personnel included on the PotomacMCO group list, included on this email. Brian should be able to get in-touch with someone from the center as well."

So, as you can see, I'm back to square one. Keep in mind that nothing was changed on our end. This situation just occurred over a weekend. I'm getting desperate here.

Solution to that problem is modifying 10 digit calls (Called Party Number field) and Calling Station (for proper caller ID) as NATIONAL
Hopefully that can be done by changing one entry or single string on your end.
I know that was working before but he’s right that 10 digits marked as Local is non compliant with NI-2 protocol.
All work for LECs is done like someone mentioned before in Mega Centers. With so many acquisitions and switches to maintain they try to standardize everything across the board. It’s possible that your ISDN serving office was “broken” and accepted everything before without sticking to proper format.

Strange, I have had the opposite problem happen to two of my customers. Our area does not have mandatory ten digit local calling. It will work as will eleven digit local calling. That being said twice I had pris go down, once due to a cable cut and once due to a software upgrade performed on my equipment. On both occasions when service was restored my customers could no longer make seven digit local calls. The area code had to be used. The problem for one customer went away "on its own" after a few days. The other customer's switch had a crash during a power outage because the ram battery was shot. Once restored, seven digit dialing was now working....two years later.

Ed I thought you tried marking all of the calls National as well as unknown And it still failed??

We prefer to have all our calls marked National on this side of the house any way

I tried all three settings that our switch offers and none of them had any effect.