Lost Idle Message on 412 TDL 1

[bassbill]

Here's anther good one for us to kick around. A customer is complaining about dropped calls on their MagixR3. The maintenance log shows error # 840F "Lost Idle Message Error" on ONLY the 412TDL line ports (there are also 800GS/LS/ID modules)This is not the first time I've seen this with Magix and it seems to me to possibly be an engineering problem with those modules - and as usual,the manual is vague on the problem "Loop start trunk lost an idle message during glare timing" HUH? Do I interpret this as a timing problem with the setup of the call?? And, to throw another variable into the equation, these loop start lines come off a T-1 channel bank from their provider. Has anyone else out there experienced this - I'd love to share as usual.
Thanks in advance to everyone.

 

[dagwoodsystems]

An idle message is exactly what I would expect to see with digital loop-start emulated lines, except that I would expect to see the message in the channelbank and not the PBX. Was a channelbank involved in the other cases where you witnessed this?

Glare on analog trunks goes hand-in-hand with unusually high call volumes or line disconnect issues. Knowing that, I wonder if "idle message" (again, terminology for a DIGITAL signal pattern) is Avaya's alternate verbage for disconnect/answer supervison. If so, you might consider looking at the channelbank's LS emulation. I don't think--for example--that loopstart with RLCF is supported on the 412TDL.

I'm also curious as to how the reliable disconnect parameter is set.

Does the message appear frequently enough that experimentation is in order? Or do we dig deep with our old Tier 3 friends in the forum?

 

[merlinman]

If I were on site, I would set up SMDR and see what I get.

If you get a * (Askerisk) in the print out, it means the other end dropped first.

 

[BigWill]

Another thing that I have done in the past is to physically test the disconnect supervision. Alot of times when my customers switch from Bellsouth to a CLEC who uses a Channel bank of some kind, I experience this problem. Call your cellphone from the lines in the system. Put yourself on hold on the Magix side. Hang up with the cellphone. Your call should drop. I also take a banjo, or use the 66 Block, this allows me to access the Tip and Ring with my tone or Volt Meter. A loopstart line is somewhere around 48VDC when not in use. When off hook, the line drops to 8-9VDC, when the caller hangs up the volts drop to 0, or reverses polarity. This can all be viewed with these tools. Good luck

 

[HiDesert]

I have one customer who has a r7.0142 legend and had no problem with the "idle message" error showing up on the
trk pool until they changed Dial tone vendors.
So far all I get are the errors..no complaints of calls dropping off...I just clear the errors and go my way.

 

[SYQUEST]

Dagwoodsystems,

What is RCLF? I have never come across this acronym.

....JIM....

 

[dagwoodsystems]

Reverse Loop Current Feed a.k.a. Loop Reverse Battery Signalling or simply reverse battery signalling.

It's an old way to send disconnect to the CPE.

I only threw it into to the mix to punctuate the point that older disconnect protocols were probably not supported on the 412TDL, but many times are on a channelbank. I'm hoping this is a CB config problem (i.e., a dialtone provider problem), and not another Avaya hardware issue.

 

[bassbill]

Here's an update everyone - I did the test Merlinman suggested - called the company had them put me on hold - called them back on another line and monitored how many seconds as I hung up. Approx 4 secs on the disconnect. To answer another question - the other switch problem was in conjunction with a channel bank (same provider too!)I started a trouble ticket with the provider and they had to have the SBC come out and rewire some stuff - the customer no longer is complaining about the "dead lines" when dialing outbound and disconnects when on hold, but still having errors on those trunks connected to the TDL modules - here's an exerpt from the log:


LOST IDLE MESSAGE ERROR 02/15 - - 01/09 09:58:18 840F
A LOST IDLE MESSAGE ERROR 01/16 - - 01/09 11:41:11 840F
A LOST IDLE MESSAGE ERROR 02/14 - - 01/09 11:46:15 840F
A LOST IDLE MESSAGE ERROR 02/16 - - 01/09 11:58:38 840F
A LOST IDLE MESSAGE ERROR 06/14 - - 01/09 14:23:17 840F
A LOST IDLE MESSAGE ERROR 02/15 - - 01/09 14:44:09 840F
A LOST IDLE MESSAGE ERROR 01/16 - - 01/09 15:05:00 840F
A LOST IDLE MESSAGE ERROR 01/16 - - 01/09 15:58:04 840F
A LOST IDLE MESSAGE ERROR 02/13 - - 01/09 16:56:27 840F
A LOST IDLE MESSAGE ERROR 02/16 - - 01/09 17:09:58 840F
A LOST IDLE MESSAGE ERROR 02/15 - - 01/10 07:57:54 840F
A LOST IDLE MESSAGE ERROR 01/16 - - 01/10 08:03:19 840F
A LOST IDLE MESSAGE ERROR 01/16 - - 01/10 09:03:54 840F
A LOST IDLE MESSAGE ERROR 01/16 - - 01/10 09:40:40 840F
A LOST IDLE MESSAGE ERROR 02/13 - - 01/10 09:57:29 840F

I'll also monitor any disconnects via SMDR.
Thanks everyone again for your support.

 

[SYQUEST]

Thanks Dagwoodsystems, I remember Reverse Battery Answer Supervision from the oooold STEP-BY-STEP days!

Bassbill,

It looks like you have some of the same lines showing up on modules 1 and 2. You might monitor the T/R of one of them to hear if anything odd is going on.

Do the 840F errors occur when the line is in use, idle or both? Also did you try any of the maintenance tests on the TDL modules?

....JIM....

 

[dagwoodsystems]

I did a little homework on this. "Lost Idle Message" is an alarm generated by the processor when a "trunk resource" becomes available at the hardware layer, but the complementary idle "token" is not reported by the background process.

Once a trunk is seized, it becomes "hooked" and is unavailable for other calls. The trunk is properly released into the pool of available resources after the signal processor receives disconnect (if it's programmed to look for it, Reliable Disconnect=YES). If the trunk suddenly reports that it is seized again (and the processor didn't expect it), the processor concludes that it never properly received an idle condition message.

The message often appears as a result of simultaneous seizures or other conditions where disconnect signalling is absent or ambiguous. Trunks programmed as reliable when a carrier does not provide reliable disconnect signal will also generate these messages. Per Avaya, T1 loop-start lines are considered unreliable.

Check your Reliable Disconnect setting.

Lastly, it's very important that these T1 loop-start emulated lines NOT be used for Remote Call Forwarding. The recommendation isn't due to toll fraud issues, but again, the business of proper disconnection. You could unduly tie up your trunks this way.

 

[HiDesert]

very informative, dogwood....thanks, now I know not to worry
too much about this error message.