Norstar 0x32 1

[itsnndn]

I have a norstar 0x32 e/w startalk flash. CCR is active - answers all calls on 6 incoming lines. Callers can put in extension number to be routed to people in the office.

Problem that started a few days ago. If a caller gets in on line 1 (of 6 in a hunt group), the call goes to CCR and the call is handled properly. IF - line one is busy, the 2nd, 3rd, etc caller that comes in hears on ring, then a fast busy.

If I call from the six line (last in group, 1st in pool to for outcalling) to say the 3rd incoming line (testing) AND the first line is available - the call will come in on line 3, ring once, bridge to line 1, and go to fast busy???

If I pull all bridging clips, call each of the six lines, everything is OK. I can call the 1st line in hunt, short it, and step through all lines ok. Once the bridging clips are in to connect to the switch the trouble starts.

Again - IF line 1 is free, and you call into line 2, 3, 4,5, or six - you can listen to it ring once, you can hear the switch pick it up, then it will bridge to line one (from the switch side) and go to fast busy

????? I'm at a loss - has anyone heard of such a thing?
I've shutdown, rolled CO cards, and there's theres no diff.

Thanks in advance

 

[bkrike]

I don’t quite understand “If I pull all bridging clips, call each of the six lines, everything is OK. I can call the 1st line in hunt, short it, and step through all lines ok. Once the bridging clips are in to connect to the switch the trouble starts “

After you have removed the bridge clips…
You need to make line one busy with a phone/ buttset (have it on an active call, but don’t use the norstar) then dial into the other lines to see if it repeats. Have you done this? Shorting it can cause a different effect than having it active with a call.

I have not seen that problem inside a Norstar before. I have seen it many times coming into the building, where it was a crossed line, or short, or bad card on the CO side.

 

[itsnndn]

Thanks for the reply!

Agree, it's a real head scratcher. In 34 years, I've never seen this in any vendor equipment.
I isolated the co lines, with butt set called/shorted each line, then called MLN and began shorting lines to verify hunting from CO was working.

Then - reconnect all lines to the 0x32. It is programmed as a squared system - all 6 lines appear (no ringing) on all 12 phones. If you select line 6 - dial the number for line 2 (for example) - you can hear/watch the line ring in on the Norstar. When the system answers line 2 (first ring - even though it's set for 2 rings before going to CCR Tree 1)
you can see line 2 (on the phone display - triangle) connect - then a fraction of a second later line 1 connects and you get a fast busy. This happens no matter what line you call - line 2 through 6. It will bridge (within the system) to line one and then give a fast busy.

I've rolled the CO cards, shut system & VM down and restarted. It just happens - Magic....

If you call into line one, it will answer (ccr tree). If you short out (busy out) line 1, call in, it will hunt - go to the CCR tree, call again (hunts to line 3 this time) (line 1 is busy, line 2 is busy) - then I get a fast busy.

Don't know if this helps to explain or not - as I said, I've never seen this before!

Time for Bailey's and hot coffee!!

Thanks again for your reply

 

[senk1s]

from what i understand - when a call comes in on line 1 - it works propoerly ...but calls coming in on other lines - seize other trunk ports/ get disconnected...
and the CO lines are ok

if that is the case, i'll suspect the LS/DS card, slot, backplane(KSU)

line1 works -> try eliminating one at a time i guess - maybe you've already tried this

 

[itsnndn]

Thnaks for the quick response senk1s

I'm affraid that's what I'm looking for - either defective system board or DS cards. That's the only thing that makes sense to me.

Only in America do things like this happen

 

[map78620]

I've had this very thing happen once before with a CICS. What I found just after I ordered a new cabinet is that 1 extension was using their call forward feature to forward to an external number instead of using the line redirect feature for this. The system was allowing this to occur because the Telephone lines were being delivered thru a T-1 and then a ChannelBank so I guess they were digital, in a sense. Anyway, after discovering this and retraining the employees on the correct method for forwarding to an external number it cleared this problem.

 

[itsnndn]

map78620,

You win! Feature 84 did the trick. Although I only have copper trunks - it cleared the problem.

I didn't even think about it. I had no idea that any of the end users even knew about the feature, let alone trying to use it. Adding to the problem, the set at the cause of the problem had been unplugged/stored for construction/remodeling.

Thanks for leading me in the right direction. I owe you coffee!

 

[bkrike]

omg- nice call map.
a star for u