Analog trunk on IP Office goes OOS when ringing in

[Jeremy Parr]

This is a goofy one. I have an IP Office, running 11.1.1.1.0, four combo cards, with analog trunks spread across all four cards. Calling in on any trunk the caller hears a beep, followed by noise. This beep and noise is consistent, across multiple calls to multiple analog line numbers.

If I remove a trunk from the IPO, and connect it to a butt set, incoming calls are fine.

Dialing out from the butt set, or from the IPO, everything is fine.

I ran the system monitor on the IPO, rang in, and I see the trunk go from Idle to Out of Service at the first ring, then hangs up after the beep and noise sequence is complete.

My best guess is some sort of issue at the CO, with voltage dipping or something when trying to generate ring voltage, which is why the IPO puts the port OOS. I'm going to schedule a porting exercise to SIP trunks Monday morning, but in the meantime, is there anything I can do on this end for the calls to get answered?

One last thought, the trace shows the state going from Idle to DiscInd is that phantom disconnect supervision?

 

[sizbut]

Firstly Avaya are going to say that only 2 combo cards are supported so you're lucky anything works.

What's the incoming call route for the line group used by the analog lines set to?


Stuck in a never ending cycle of file copying.

 

[dagwoodsystems]

When you say "beep and noise sequence" are you talking about something that you hear while monitoring with your buttset? That is the Caller ID coming in between the first and second ring. Just to be clear, you're saying that the call drops immediately after this is sent?

Tim Alberstein

 

[Jeremy Parr]

Firstly Avaya are going to say that only 2 combo cards are supported so you're lucky anything works.

Nice, this was installed by our CLEC, the same ones seemingly sending us goofy voltage.

What's the incoming call route for the line group used by the analog lines set to?

Nothing complex, just rings a few phones, the thing to note is that while we are experiencing this behavior, the IPO never "detects" an incoming call. It only moves the trunk from idle to OOS, and then seizes the trunk to do a test, resulting in the call being answered.

When you say "beep and noise sequence" are you talking about something that you hear while monitoring with your buttset? That is the Caller ID coming in between the first and second ring. Just to be clear, you're saying that the call drops immediately after this is sent?

The caller dialing in to the IPO from outside hears the beep and the static. Based on the timing of when I hear this, and the output of the log, I believe the IPO is generating these tones. Take a look at the log attached to my original post.

At 2463359ms the IPO does a `TRUNK SEIZE`, then at 2465359ms (exactly two seconds later) it executes a `TONE DIAL (1 digits)`, and then does a `TRUNK RELEASE` four seconds later at 2469306ms.

I believe what is happening is that the analog card at the CO is trying generate ring voltage, and failing, resulting in a voltage drop that the IPO perceives as an OOS trunk. It puts the port OOS, and then when the voltage returns (when the first ring completes) it returns the trunk to service, and goes off-hook to do an echo test, which results in the call being answered (accidentally, as the call doesn't route anywhere in the IPO, I don't think the IPO even knows it answered an active call). This is supported by the fact that my tech onsite told me that the butt set did not ring, it only made a soft clicking noise each time it was supposed to ring.

 

[budbyrd]

I am with sizbut on the number of combo cards. Usually if you have more than 2 the card will go red if it boots at all. I would take a closer look at the card labeling. If they are all combos try pulling out two of them and test it.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'

 

[Jeremy Parr]

I am with sizbut on the number of combo cards. Usually if you have more than 2 the card will go red if it boots at all. I would take a closer look at the card labeling. If they are all combos try pulling out two of them and test it.

Thanks. I should mention that the customer has had this deployed for years, and only recently has this problem started happening. Power cycling the unit does nothing to affect change. I will check the card details and see what models they are.

In any event, my plan for Monday morning is to port the numbers from analog to SIP. The ILEC in this area already has existing fiber in the building and a CPE, so we just need to patch a port on the CPE to the WAN port of the IPO and configure the SIP trunks. All this analog nonsense goes away at that point.