TRK130

[Jaimegu]

Hi, everybody,

I have a 150 member route (MFCR2) to a company, and sometimes they see many of their channels in "seal" state (Ericsson AXE) because it doesn't get Seizure acknowledges. Meanwhile we didn't see any different from IDLE or BUSY.
Tracing down the problem we could reproduce the fenomenon throu a set of very short calls and we could see some channels in Lock Out temporary (of course, they saw the "seal" state in their switch).
The channels left the LCKO state issuing a TRK130 which is related to a "short hold" failure.
The question is: which parameter is to be changed in order to solve this matter?
Could it be HOLD in route config.?
Keep in mind this is a call center application.

Best regards,

Jaime Gutiérrez

 

[freddog]

I'm familiar with sealing current on trunks but haven't heard of a "seal" state related to channel seizure. Some places to look... If the route is made of digital, but not PRI, circuits, print the RDB in LD 21 and see if NEDC & FEDC (near/far end disconnect control)are set for ETH (either). The RDB can be modified in LD 16 if necessary. If they are PRI circuits, disconnect control is part of the D-channel signalling and you won't have NEDC or FEDC listed in the RDB. Also, print some of the trunk members in LD 11 or 20. You'll want to check that the start arrangement and answer supervision (STRI, STRO & SUPN) are appropriate for your type of trunks. When in doubt, set SUPN to YES. You can check with the circuit provider if in doubt on start arrangement. For digital, not PRI, it'll either be wink start or immediate start.

 

[janaya]

The book states that you can actually change the short hold measurements from 0 to 128, but it does not say where. I would assume somewhere in the RDB, but I looked and don't see anything there. I am using electronic documentation, so it's hard to flip back and forth between loads.

John

 

[freddog]

It's set at the HOLD field in the RDB, LD 16

 

[Jaimegu]

The seal state is like a Lockout or faulty state and the AXE doesn't try to make calls over a channel in that state. The way it gets in "seal" is: It sends a SEIZURE (TS16 CAS bits) but Meridian 81C sometimes doesn't answer it with a SEIZURE ACKNOWLEDGE.
After a couple of minutes AXE sends another SEIZURE and when it gets a correct answer, it "unseals" the channel.

BTW, The problem started after a Release update from Rls22 to 25.30 FNF. And the type of trunks are E1 digital using MFCR2 (no PRIs)
Thank you guys for your answers. I'll tell you how it's going.

 

[freddog]

Has your maintanence vendor had any ideas? I wonder if your problem is caused by a bug in rls 25.30 that can be fixed with a patch.