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.