Reorder Tones 1

[gbaughma]

Well, we've stumped NEC. Here's the scenario.
We have a DSS T1, 24 channels RBS going into an Adtran Atlas 550 (which does DNIS conversion). Out of the Adtran into the NEC PBX (2000IVS). We're getting occasional reorders (rapid busy). Here's what we've tried so far.

Frogged the cards (Switched the T1 cards for our long distance T, which is working, with the new T card we installed... same problem.)

Rebuilt the trunk.

I even went into Matworx and dumped the configuration for the working T, and compared setting-for-setting with the new one.

The reorders aren't happening all the time; only about 20% of the time. I can sit and watch the adtran and watch calls come in, the DNIS digits be converted and passed over; as far as the Adtran is concerned, the call went through; but when it happens, it's not ringing the extension or anything. It rings a couple of times (going through the adtran) then gives a reorder.

Any thoughts?
--Greg

 

[3DNet]

How about outgoing calls? Are you having trouble there too?

 

[gbaughma]

Negative. Outbound calls are working fine.

--Greg

 

[3DNet]

I don't suppose the trouble is happening with specific extensions? That would be easier to track

This sounds like a numbering plan issue (might sound stupid but I did this awhile back-and felt like an idiot). How/why are you converting DNIS? Are you just converting 1 of the digits (as in 9000 to 7000)? Check to make sure that your numbering is programmed correctly in CM20. If your conversion is done before the call reached the PBX, you should only need the converted digits programmed. If you're converting from the PBX make sure both sets of digits are programmed.

Was this an existing T1 where new numbers were ported or the vendor was changed?

 

[gbaughma]

DNIS conversion is happening before it even gets to the PBX (If you haven't checked out the Adtran Atlas 550, it's SO slick....) Meanwhile, here's what our vendor just tried.

According to a tip from NEC, he went into the trunk route stuff (35) and set
3521 to 02
3524 to 2
3546 to 1

.... Now, I asked what the pulse dialing had to do with our T, but he said the NEC faq said to try it. I guess we'll see if that fixes it or not.

--Greg

 

[neax]

None of the above command changes will not fix the problem. Why is the Adtran doing the digit conversion? The 2000 can handle any digit Telco sends regardless of its digit length.

I need to know what the following command settings are:

3500, 3501, 3504, 3509, 3512, 3517, 3518, 3520.
What are the DID digits sent to the PBX. What type T1 is this (ANI being sent in or just Wink Start DID)

This sounds like a timing / Wink issue that varies slightly letting most calls complete correctly.

Also, a Register circuit (8RTS or 4RST) is needed to handle the incoming DNIS (DID) from the outside (from Telco). Check command B00>072 and let me know what the value is.

 

[gmannatl]

neax is correct, check the commands he listed and post them. And not to sound redundant, but WHY are you using the ADTRAN for DNIS conversion? You have got to be passing DNIS back out of the Adtran to the PBX. What format are you using? I know that the Atlas support feature group d for ani on t1. Is this why, or is it a conflict with the numbering plan as Doug Willis suggested (ex 9000 to 7000). If so, all you have to do is assign the trunks to a different numbering plan and make all leading digits station numbers.

 

[gbaughma]

We're using the Adtran for a couple of reasons:

1) We have a Quad BRI/ST module in it (for video conferencing equipment)
2) I'm using it for digit conversion in the dialplan because, frankly, it's easier. (Then I can route calls to the BRI's as well.

My vendor just called, and said it sounded like we were running out of registers... 60-some-odd times that calls reordered due to no registers available. Ugh.

BUT, just to answer the questions above...
3500 = 04
3501 = 7
3504 = 2
3509 = 03
3512 = 2
3517 = 20
3518 = 1
3520 = 00
B00 072 = 61 <--- I think this is the problem?
The T coming into the PBX from the Adtran is Wink-Start, then send DID.

--Greg

 

[neax]

As B00-072 is anything other than a &quot;0&quot;, you will need to add more registers (8RST card). What this means is, Telco went off hook but when the PBX tries to respond (wink back) to that condition, a Register was not avaiable at that moment - 61 time to be exact. Telco tries to send the call but as the PBX is &quot;not ready&quot;, the result is the call can't come int.

After you add another register card, &quot;CCC&quot; the 61 and monitor afterwards.

 

[gbaughma]

Ordered a 8RST card today. $656. &lt;Sigh&gt; Oh, well.

I have a Merlin system at home. It's so much easier.

--Greg

 

[gbaughma]

OK, time to bump this.
Situation: Still getting occasional reorders. Even got a slow-busy once that should have gone to voicemail.

I put in the 8RST card, and 072 and 070 have both been 0 ever since. For that matter, B00-070 through 076 have been 0.

Using 45, I busied out all 12 receivers, then un-busied them one at a time (trying to ferret out a bad receiver channel). All receiver channels are working fine. I used a SL phone, got dialtone and was able to dial on each and every receiver.

I checked F70 for every LEN in my first PIM, and verified that time slots were available. I'm not out of time slots.

We set 5106 and 5107 so that *IF* a number were mis-dialed, and didn't terminate to a station, it would go to the operator.

**** THIS PHONE SYSTEM IS MAKING ME LOSE MY HAIR! ****

I'll try anything short of C-4 at the moment, if someone has things I should try, check, wiggle, tweak, break, snap, hit with a bat to get this problem resolved.

--Greg

 

[gbaughma]

Well, just a FYI (in case you care)

Put in the 8RST card, and that solved the "no senders" issue.

Took the Adtran out of the loop, and the reorders went away.

--Greg