atcomsystems.ca/forum Forums TDM Business Telephone Systems Avaya - Lucent Telephones & Systems Lines on a ipoffice

I Have a customer with a ipoffice,basic mode. The lines are coming from a fiber provider thru their modem and they output analog lines. At least twice a week all the lines on the ip office go red and the lines appear to be dead, if you reset the system they come back. If you put a butt set on the lines they are fine. Is the system getting something from the providers modem that is causing the lines to get "tied up"?

No. Something with the system.

-Hal

Probably having a problem with the module the trunks are connected to, likely the combo card. Had a similar problem in a similar situation, replaced the module, all fixed.

The problem is likely the provider.
Many of them send a signal that looks like Caller ID to the KSU.
So, the KSU lights the CO Line LED and waits for the "CID Complete" message, which never arrives since it is not Caller ID data.
Now you have a Steady LED on any and all CO Lines.

Power cycling the KSU will clear it and may trick you into thinking the KSU is the problem, but it is not.

Here is your test.
Turn Caller ID off on all of the CO Lines and see if the trouble disappears.
Then, after a period of time, turn CID back on and see if the trouble re-appears.
If it does, then you can fight with the provider.

Best yet, switch to SIP Trunks and use up to 3 of the free SIP Trunk Channel license that are built into the KSU.

The IPO doesn't work that way. Turning CID "on" merely delays the extension ringing for 1 CO ring to allow the CID info to be displayed first. It couldn't care less about the CID otherwise.

Now, I suppose a continuous "ring" from the modem on all lines might do what you are experiencing but I wouldn't expect it to lock up the system requiring a reset.

-Hal

I tested it here with 8.1(81) Basic KSU.

Incoming Calls with "Trunk Type" set to "Loop Start" (No CID) show up as "External" in the LCD, not the actual CID of the caller.

Maybe Avaya changed it in later releases.

I believe that's correct. But how do you get from there to a CID signal locking up the system? Is that something you have verified before or been able to create on your test system?

-Hal

high mesa
this opinion is from an unqualified source with some small ipo experience. i once made about six site visits chasing a similar complaint. billx's suggestion was my first test.
my problems went away while i had cid turned off. if you think about it, cid information could be delayed 5-10 seconds during a normal pstn ring cycle. you may discover some ipo call routing instructions that start happening before cid is completely received resulting in your trouble symptoms. my final solution turned out to be a programming problem related to alternate call routing timing. do turn off cid trunk option as a test. that will not prove the trouble to be in either direction, but it may prove that it is connected to the solution.
good luck.

I do not recall 100% how I tested it.

I did a write up on it but I cannot find it in my computer.

To the best of my recollection, I think I what I did was to connect one PBX's Analog Extension (the source of the CID) to the IPO Basic KSU CO Line port.

I also had a buttset/testset connected to monitor the call across the Analog Extensions Tip and Ring.

This way I could hear the actual ring generator and CID going to the IPO KSU.

I made a test call and all went OK.

On the next call, I quickly disconnected the Tip and Ring to the IPO KSU during the CID data burst.

The CO Line LED came on, stayed lit and did not go out.

Somewhere on line I found the CID Specs for the data burst and there is a "Finished" or "Completed" data word sent at the end of the burst.

Since the Telco Provider is sending some type of signal (that the KSU interprets as CID and it turns the LED on) and there is no "Finished" or "Completed" data word,
the LED stays lit.

I had a customer with the same trouble and he turned off his CID in the KSU for a day and the trouble went away.
He turned CID back on, a day later, and the trouble came back in less than 1 minute.

The Telco Providers can send data like SMDR (CDR), Message Waiting or just about anything they want to.
The biggest problem is that they do not understand what we are talking about.

I mainly support Panasonic and IPO Systems and I have never had this report for Panasonic.

It seems to me that the IPO is just very sensitive to anything that looks like CID Data.

Good options to try. Now that CID was brought up, I do remember the same thing with an older ipoffice and the cable company, turned off CID and the problem went away and finally got them to fix it. I will go and change the programming today