atcomsystems.ca/forum Forums TDM Business Telephone Systems Vodavi Telephones & Systems XTSip with PRI using Combo Card problems.

I don't even know where to start with this one. The system was connected to the PRI ten days before the cutover. It is a new PRI with 20 did numbers and 2 additional numbers pointed from the customer pots to the PRI. We cut the swtich over at night, no errors on the DMS 500 span, could make calls in and out no problem but it seemed a bit slow to connect when going out. The next day we had the telco point the main number to the PRI and that is when the problems started. Customer could not always dial out. They would dial 9 get dialtone, dial the number and it would just sit there. Inbound callers were getting busies, long ring times, and recordings saying the number was no longer in service,number disconnected, try again etc. I got on the phone with the techs and they had the PRI configured for sequential as opposed to most idle and only the first 4 channels would take calls, the 5th caller would get the error. He reconfigured it for most idle, reset the PRI on his end, but got a number of errors which forced me to reset my card. It finally came up and we made a lot of calls in and out. The telco also made an interdigit timing change. No problems....for about a week then it started all over again. Now the finger pointing is getting really bad. Out of desperation I pointed the main number back to the pots to stop the inbound recordings but outbounds remained on the PRI. We then made some additional option changes on our swtich as suggested by Vodavi: PRI restart, set the PRI to the Nortel option, Pri Centrex plan unknown. We left it like that while checking other DID numbers to make sure we could call in. Worked without a hitch, although I think my changes had nothing to do with it. The customer when dialing out started using the # sign to speed up the connection. Two days ago (thirteen days later) we repointed the main number back to the PRI made a tremendous number of calls..all looked fine. I turned on LCR to speed up the outbound call connections. Yesterday outbound problems started up again.Customer dials the number with LCR, the XTS siezes a line and the call sits there. Etrace reports no ACK from CO. Inbound seems to work fine. Now the telco is going to move the circuit to a different port on their CO. It is the first substantial thing that they have done other than tell me it is my problem. Vodavi insists that it is a telco D channel issue and I have done all I can do on my end. I have again asked the telco to verify all parameters of the PRI, NI2, call by call enabled,FAS, ESF, B8ZS, channels set for wink. I intend to replace the combo card with a standard PRI card if the problem continues. I don't think that will fix the problem but I think I need to try it anyway.

The channels should be set for TIE-DNIS. Also, make sure that the 24th channel is set to trunk group 0 and is in the out of service state. If there's one thing that Vodavi told me that I'll never forget, it's that these problems are ALWAYS the carrier. In the ten years or so that I've been installing PRI's on their systems, I must say that they are right.

One other thing to ask the carrier to check in their DMS: There is a table called "LTDEF". In this table, there is a definition called a "variant". Ask them to make sure that the definition of this variant is set to NI PRI.

You might also want to run an "L" trace to see if there's any rhyme or reason for this. It's usually due to call collisions occurring. If an incoming and outgoing call collide, this will take the channel out of service. When using "most idle" hunting, the risk of collisions is greater. The trunks really should be set to hunt sequentially from first to last since outgoing calls hunt from last to first.

Thanks ED, I'll check it out.

The switch techs informed me that the DMS LTDEF variant is set for NI PRI. They are reconfiguring the channels for sequential ascending order. I am changing my signalling to Tie-dnis although that is not what is causing this, not by itself anyway. I have other sites set for tie-ani. Ani is what the telco info sheet has on it. I have changed it, not at this site, from ani to dnis to did before and calls come in the same without the CID changing its format at all. The telco techs say they don't have any kind of signalling settings they just send the call. What can I say to that?

I had another site that I installed back in November. XTSip FP1. I installled a combo card fired up the PRI, made calls in and out and they worked fine. I then did a software upgrade to the system (I wanted to do it before I istalled the PRI but couldn't) and took it to 2.23. The PRI was offline for about an hour. Once the upgrade was done, I reset the system the PRI came back up and I made some test calls. Inbound worked fine, outbound 7 digit local call.. nothing. Call just sat there. I dialed 411 and it worked, 611, 911 and 1 plus area all worked. Local calls..worked when I dialed the area code first. Something caused me to have to dial 10 digits. I made no PRI programming changes to my system. Before the upgrade 7 digits worked after the upgrade I needed to use 10....still have no answer for it. I turned on LCR and used an add/delete table for the 757 area code. The telco says it isn't their problem..of course. One tech told me its because my switch requires national tagging. Yea, National I 2!

I know what you are saying. The telco is always right. I can't say that I blame you for wanting to try using a standard PRI card. Not that I've had any trouble with the new combo cards, but I've never had any trouble with the old ones.

We always have to tinker with the Tie/Tie-ANI/Tie-DNIS settings, depending upon the service provider. That's never consistent. I agree that wouldn't be the cause for your problems though. We also have to tinker with the leading 1 and 011 settings on nearly every install.

It seems as if you've exhausted all options except to try the other card. I'd really like to know how you make out with this.

An update from our problems at a site with the same problem.... after doing our traces with both cards it was determined that something with the signal sent from the telco just wouldn't work with the combo card. I would take as many trace's that you can with the the combo card and with the old style card, which you will have to probably get as a refurb. If you are like me you won't see a rhyme or reason for the issues but trace it and make it fail over and over and over some more. Vodavi finally got enough info from the traces to say "yep the combo just won't work with the signaling from the telco". But throw as much info at them that you can.

I will say that I have seen issues where the "name" information sent by the carriers exceeds the field size expected by the system. When that would happen, it would also knock the PRI card silly for no obvious reason. You may want to ask the carrier to temporarily disable name/number delivery and see how it behaves for a few days after that.

I have seen when the carrier sent Caller ID name/number info in a wierd format for no reason cause an XTS with MPBe on it continually reboot. It would happen once in a great moon but when it did, BOOM there when the system. It would come back up then as soon as another call would come int BOOM. Call the carrier tell them to take the name/number option off and all was well. They would turn it back on and it would work fine. Just once in a blue moon it would send some wierd info to the XTS causing it to crash. Vodavi did not have an answer for this at the time.

On another note Derrik: you do have all the dip switch settings correct on the combo card, correct? and the clocking switch?

oobie, I am taking clocking from the net. The switches are set to spec. I think if the swithces are misplaced you will get span errors. The green led on the mpb is on so I have proper sync. To update, there were very few instances of not being able to dial out today. Only two or three and they might have been legitimate busies. The telco reconfigured the trunk group tonight and reset the pri. I made test calls and so far so good. Before we made the changes, a tech and I compared notes during some test calls. We saw something odd. He showed an idle channnel 16 but my slot dump showed a call on that channel and when I 088ed it, I got a busy. It took almost five minutes for it to release. We made an inbound test call to the channel but could not duplicate the problem again. It reminded me that when this first started the opposite took place, the telco could see calls on channels but the channels were idle in my switch. The whole thing is weird and has taught me to never again bring up a PRI two days before a major holiday weekend.

I'm still leaning toward the possibility of extraneous characters in the CID name field as being the culprit due to the sporadic nature of the problem.

When you did the slot dump for the channel 16 issue, did it show an associated station or was the channel just locked out? That almost sounds like a call collision did occur on it when the "most idle" hunting was in place since the channels closer to the middle would traditionally be the most idle.

It's pretty easy to try creating a call collision to see if this is what is causing this issue. Just direct-select the trunk at exactly the same time that you have an incoming call arriving. Obviously, split-second timing is imperative, but it can be done. I hate to keep beating a dead horse but these are the only two issues that I've ever encountered that have caused the inexplicable.

Do slot dumps actually show the station in use? I agree with you that it may have been a call collision. I have called into the system the auto attendant answers plays a greeting, I hang up, call back and the greeting picks up where I left off. My call obviously came back into the same channel which had yet to release from the switch.

Actually, no. Sorry about that. A slot dump doesn't, but D_B will.

There's no doubt that there's a severe lack of D channel supervision going on based upon that test call you made.

The pri failed again yesterday big time, no calls in or out, busies coming in. I went on site, reseated the pri card, the circuit came back up quickly, the calls didn't start working for about five minutes. My partner showed up right after, called the rep from the Telco (Cox) and let her have it with both barrells. They finally agreed to send out a couple of techs with a firebird. Long story short, we could not make the pri fail again except for one time, and that was by calling out on it and back in on the same pri. The tech said that didn't help them cause they can't track a call from the same number to the same number. It the call would have to come from outside. So four of us banged away on our cell phones and never had another failure. I made two programming changes while this was going on. I increased the transmit levels on the pri trunks to +3 and made sure the 24th trunk was programmed as oos. It was not but it was programmed out of trunk group 1 and it has always shown up as oos on a slot dump. The last thing I did, just out of desperation more than anything else, was change out the pri combo to an older version card. This is a D channel problem and when the pri fails calls are still coming in but with no dnis info just the caller ID info. I get an invalid pri call error on etrace. Going out there is a no co ack message. The really weird thing is that when I uplug the csu/pri card from the smart jack and the circuit goes down, Cox CANNOT see that it is down. What does that mean? Does it have to do with the fact this pri comes through Verizon before it gets to us? And we never had any slips show up no matter what with the combo card. The older card gets 3 or 4 slips when it first comes up after being connected to the net. I am at a loss to figure out what is going on. I did hear the techs confering between themselves about some kind of high voltage reading wondering if that was normal or not. At the moment they have their tech eq still in the loop monitoring the net. And the plan is to come off the Verizon net and onto Cox's fibernet asap.

Is there a CSU/DSU in place? If so, you should try bypassing it and go straight into the card. If there isn't one there, you should try putting one in at least for troubleshooting purposes.

There is the adtran csu/ace that came with the pri card. Inline or out, it didn't make any difference with this problem. At the present time it is in use.

Problem no longer happens. We are on a COX pri from our eq to theirs and using the single function PRI card not the combo. The problem comes back when using the combo card. Don't know if the card is defective or just doesn't tolerate the circuit. I am thinking about trying it at another site and see if the card fails there.

Are you kidding me? That just makes my blood boil to think of the countless hours that you have spent over this. I am going to go out on a limb here and assume that Vodavi never offered to replace the card, correct?

I do have to ask a somewhat insulting question though: Was the DIP switch on the combo card set in the correct position for use with a PRI? :shrug:

Honestly, I've never seen one of their PRI cards go bad without reason (aside from lightning, etc.) and I surely haven't seen a combo card fail. You should take this up with Vodavi for sure.

They never offered to replace the card. The dip swiches have always been in the correct position all five of them. Belive me, I spent hours on the phone with Vodavi, on this including programming parameters in the switch and in the DMS 500 (Vodavi keeps asking if it is a soft switch and one tech said Cox must be lying about that) My customer has been most patient about this but Vodavi sure didn't come through on this one. I had to get the card from a reseller. It was one techs suggestion that I try it at another site where a combo card is working.

The answer is right here and no place else. It's not Vodavi's nor the combo card's fault.

The problem is dead square in Cox's hands. If they cannot see the PRI card unplugged then they have an issue with the circuit or provisioning to the customer's site. It is IMPOSSIBLE to not see the card unplugged if the circuit is correct. The D channel is in constant communication with the C.O.

I have a CLEC here that drives me nuts with the same type of issues. I'm at a loss as to why the Vodavi techs didn't pick up on this when you told them.

--Bill.

Bill, tell Larry I said hello! I agree with you, but maybe the techs just are not looking in the right place, but they never show any slips even after the circuit is unplugged and for that matter I don't either. One tech said that not seeing the circuit down might have been caused by some auto diagnostics that Verizon runs when a circuit is in trouble. Don't know. But why would the combo end up having this d channel choke problem and the older PRI card work? Is the combo less tolerate to D channel fluctuations than the older card? The older cards will work with a soft switch (so I have been told) but the combo will not. Also I found out that if I set the pri/bri centrex plan to ITU I could not call out at all.(with the combo, don't know if it is the same with the older card) This is not an issue at any other Cox site that I have. Even though it appears to be working at the moment, I still want to get to the bottom of it so I don't go through this again the next time I install a PRI.

I guess that at this point, any further suggestions would be moot since it's working. I will say that I talked to one of my techs today and he reminded me of a similar issue that we had several years ago. It didn't involve a combo card obviously, but the scenario was similar to yours.

We ended up finding out that Verizon had split the pairs on their punch down to house cable pairs when extending the circuit upstairs to their RJ48X. Basically, the transmit pair ended up being white/blue and orange/white and the receive pair ended up on the blue/white and white/orange. It still managed to work (with service calls every other day) for quite a while. It wasn't entirely the installer's fault, it was the Bell Atlantic cable splicer in 1978 when the riser cables were installed who split the pairs in a splice case. The installer just assumed that pairs 1501 and 1502 were good and didn't bother to check them with anything more than a toner and a probe.

Surprisingly, a T1 or PRI does manage to function (marginally) under these circumstances. I've even seen them continue to function with half of a pair missing, but chock full of errors.

We could get call collisions to happen if two people called in within seconds of each other both trying to get on that first line, one would get thru the other would not and it wouldn't roll to the next in the series. The lines would eventually clear but was never less than ten minutes. Never happened with the old card, we couldn't make the old card fail once, but the combo card would every time. Again Vodavi said it was a problem with the signaling from the telco, but as far as I'm concerned I just wanted it to work so leaving the old card in is where I left it. Sucks that the only option from vodavi is the combo card anymore. I don't see the telco's changing their way of doing things any time soon here.

I talked with a very good Vodavi Tech-engineer this morning about this problem..He told me that changing out the combo card with a different combo card would not have made any difference. Cox is sending something squirely down the B channel, the combo passes the bad info on to the MPB and the MPB buffer fills up and locks out the PRI and just denies calls. Reset the PRI at either end clears the buffer and the whole mess starts over again. The really bad thing is..depending on the MPB software (2.0) when the buffer fills it may deny all co calls including calls through th LCOB or Voip which requires a system reset. They are working on redesigning the combo to make it more tolerate. Trying to figure out what the CLEC is doing or not doing with the PRI to fix this or keep it from happening again is next to impossible. Apparently, many dealers are trying to get the older card which has eariler firmware to try to resolve issues they are having. Ed, this goes along with what you said about CID info on the PRI.

We didn't change to a different combo card we had originally installed a combo card which is when we got the failure, we had to go to the older pri card which took care of the problem of course you can't get that from vodavi.

I had this same issue with the first Vodavi the company I used to work for put in this same set up on a DMS. We fought and fought with Vodavi and the carrier. THe high voltage reading may have been from the fact the PRI was running across a HDSL T-1 circuit. It is true however, that the carrier would see the D-channel and the B channel trunk groups go down in the switch. I worked in a CO for 2 years, and if a circuit dropped, we would know it. The MCC would light up like a Christmas tree. It is possible if the rep from Cox you were working with was monitoring the wrong span. It doesn't matter if the circuit is passing through 5 different LECs, the switch is always monitoring the span, no matter how many DACS or slicks it passes through.