Route list issue

[T8keiteasy]

Hi,

I've a route list leading to two routes.
When the first route is out of order, it goes to the second one (Great !!).
When the first route becomes available again, it takes a VERY LONG time before this route may be used...
IS there a timer to let the ICP checking more often the route availability ?

Regards

System used :
3300 Cxi ICP Relase 8.0 UR1

Now, it's about French users too !!!

 

[shawnb345]

I'm not 100 percent but you may want to check in your Class of Service assignment in the 3300. There are alot of timers in there

 

[T8keiteasy]

I did....
But didn't find out...
Perhaps one specific timer for user's is alos used for this...

Now, it's about French users too !!!

 

[paterson]

How long is a "very long time"? Have you timed it? If you definately know the length of time it takes, then you will significantly narrow your options.

**************************************
Insert Witty Signature Here.

 

[MitelInMyBlood]

When you say the first route becomes available again, is it really available? In other words, just because the T1 (or whatever) appears to be back in service, what do the trunks say (use the state command)? With certain telcos the T1 may come up a lot sooner than the D channel, and without the D channel the span is technically still out of service. I've seen it take easily several minutes for the D channel to come back.

 

[kwbMitel]

MitelInMyBlood has it right.

If the trunk is available and is the first choice, it will be used. There is no timer that tracks whether a route has been out of service.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[T8keiteasy]

I've lab tested it.
I'll have to connect analog lines to antenna's installed on ships. Many different antenna's will be connected so when one is shadowed, another on can be available...

When I say un-available, it is that I disconnect the line.
A long time is 8 minutes to use the first route.

It must be a timer so when a route is not available, it is not automaticly this first line which is tried every new calls...

Cheers

Now, it's about French users too !!!

 

[Lundah]

What kind of trunks are these routes? Seems to me the type of trunk is going to play a lot more into how long it takes the system to show it as restored than anything else.

 

[Mitelpassion]

i'm guessing that your trunks in your first route are not actually back cause if they were the system would definately use them. I use route lists all the time and there are no timers.

if you using analog trunks, when do you know they are back? do you check using st command?

 

[T8keiteasy]

As I've lab tested my analog trunks, I have one analog line connected to the first LS port. When I say it's becoming unavailable I mean that I disconnect the analog line from the first port to the second one.
Then, I connect the analog line to the first LS port and dial a number...the route taken still the second one...up to 8 minutes...which is long to me...

The ICP is just great because it detects that analog line is not connected and route to the second route (wich is not like this on every PBX)...

AS Mitelpassion says, there's no timer to check that an analog line becomes available again.

Regards

Now, it's about French users too !!!

 

[Lundah]

8 minutes does seem like a long time, even for an analog trunk. Have you tried tweaking your Circuit Descriptor settings? You may be able to improve the restore time by changing some settings there.

 

[Mitelpassion]

uhm i think i know what you are saying. Can you confirm that once you've connnected the analog line back to the first LS, that it's idle and ready?

analogs are funny. we still seem to have a lot of them here in south africa which is such a pain. the ls ports sometimes remain in releasing if the circuit descriptor isn't correct. use the defaults, don't tweak too much for a start....

just at least confirm that when the trunk is in port LS1 that it's idle and ready for use

 

[MitelInMyBlood]

Try executing a directed test to the trunk, i.e., test (PLID) then try accessing it. Could be background stats is only thing I can think of that might be taking that long to make the rounds.