eFax :: Failing over from IP H.323 trunk (eFax server) to connected Analog Fax Machine 1

[mtaysiir]

Hello folks,

First post on tek-tips, so I will start with a very brief introduction.

The name is Taysiir and this year is the start of my adventure into Avaya, Telephony and Communication Manager.
I have had the opportunity to work in a definity lab about 6/7 years ago during college, and have since been working on Cisco and Data networks mostly.

Today, I have recently implemented a Fax over IP solution for a customer (GFI FaxMaker), but there's unfortunately no automated failover should the GFI FM server go down.
The process is done manually.

You will find attached:
> inc-call-handling-trmt (5034 -> #85034, where #8 is the TAC for the H.323 trunk to the FM Server)
> In case the FM server goes down, the admin would have to change this line to #85034 -> 5034

I have had a chat with an Avaya representative about how to introduce an automated failover should the IP trunk go down.
He advised me that I will need to use UDP/AAR in conjunction with 2 trunks mentioned in a created route pattern: the H.323 trunk to the server, and one analog trunk to the analog fax machine that's still connected to one port on the CM. The primary trunk would be going to the server, and should the server go down, the secondary trunk, the analog trunk, would reroute fax traffic from the pstn, to the fax machine.

Now, before the Faxmachine server was implemented, the analog fax machine was reachable from the outside via a DID assigned to it by telco, and that's carried over via the main PRI line connected to the CM G450.

So my dilemna, is it possible to create an analog trunk and associate the fax machine with it?

 

[kyle555]

OK, so if I follow, you'd like calls coming in to go first over a h323 trunk to your fax server, and secondly to an analog port with a real fax machine in case the fax server is down.

So, build a station with port X, call it 1234 for example.
Go "change coverage remote 1" and make an entry of 8-5034" where 8 would be your AAR code. Say that's entry number 5, and you'd have a match in AAR for 5034 to go to a route that points to your trunk to your fax server. Normally you shouldn't be dialing by TAC and it isn't something extendable to every feature in CM. You'd typically want to delegate that to ARS/AAR for public/private digit analysis.

Build a coverage path that goes first to r5, then to 5034. Assign that coverage path to your phantom/X ported phone 1234.
Send the calls to the fax to 1234 which will follow it's coverage path which first hits the fax server and if not available, it'll try the second point of coverage which is the analog 5034.

 

[mtaysiir]

Hello Kyle555,

Thank you for your response.

I will test it out, and let you know how well it fares.

Taysiir

 

[mtaysiir]

Hello Kyle555,

It worked!!! When the IP trunk is unavailable, the fax is received by the analog fax machine.

I have attached my configuration.

Now, there's one challenge.

When the IP trunk is brought down administratively through busyout trunk command, and then brought up with the release trunk command, the trunk becomes available instantly.
But when the actual fax server goes down, and the trunk status shifts to OOS/FE-Idle, what can be done for the trunk to come back up automatically when the network connectivity is restored.

I had to manually dial the trunk for it to change its status to in-service, as it remained in the OOS/FE-Idle for quite some time after the server connectivity was restored.

In any case, this working failover was enough for the users to be happy and confident about the efax solution implementation.

Thanks again.

Taysiir

 

[kyle555]

It's probably just timers for checking the status of the signaling channel that keep it in or out of service.

Is ACA (automatic circuit assurance) enabled on the trunk? That might be something that brings it up faster after a service outage.

Otherwise, you got the failover working. That's great!

For failback... i don't know if the h323 fax server needs to play nice before CM sees the IP trunks in a good state again.

Normally, CM will always try to check it's signaling groups and normally will bring everything up and into service automatically if possible.

Check out page 334:

https://downloads.avaya.com/elmodocs2/comm_mgr/r5.0/245205_6.pdf

Worst case, you have to kick the trunk on the Avaya when the fax server gets angry.