Forward on Station Disconnect 1

[bakell]

Hi,

Is there any way to have incoming calls to a station forward to a destination in the event that the phone is disconnected? For instance, a remote site has IP phones registered to the core, and if the WAN link goes down, calls to these phones are redirected to cell phones. I'm not aware of any sort of Forward Unavailable feature. Is this possible with H.323 stations?

Thanks,
Brad

 

[dialtonebone]

EC500 would help though it isn't exactly what you want.

 

[coolwhisper]

Does the remote site have a gateway and trunking? You could use IGAR to make sure the calls still go through.

 

[bakell]

I've thought about EC500, but yes, it's not really what we want. It could be used as an alternative to ensure that calls are being routed to somewhere they can be answered.

The remote site doesn't have gateway and trunking - the customer is trying to get away from needing CPE/local lines and centralize everything in the core. I'm wondering if Avaya intentionally doesn't have the capability I'm looking for so that customers are forced to buy more equipment for failover...

 

[coolwhisper]

How many stations does the site have? If you purchased a used G430 you could have a coverage path that routes to a vdn and vector. The vector would check to see if gateway was registered and route to the cell phone if not or voicemail if they are are. This would eliminate the need for local trunking and the gateway is a few hundred dollars. The limitation is that you need a separate van/vector for each station so not practical unless it is for a small number of users.

 

[Vidmine]

May not be exactly what you are looking for but if your station is out of service the call will route straight to voicemail.
You could turn on reach me and route the call to a cell or an extension.

 

[bakell]

Coolwhisper,

Unfortunately, the customer has dozens of remote sites with 10-20 users each, so it could become a programming nightmare if we need to go the vectoring route. However, I appreciate the idea and it may be our best bet!

 

[1a22ip]

We use a Telco feature called Custom Redirect Service. Through a website we activate pre-defined scenarios. NYC down Route inbound calls (all digits) to Boston office. Incoming call treatment sees (212)XXX-XXXX strip 212 XX. We have 5 digit dial plan that routes on first digit 1XXXX = City 1 2XXXX = City 2 ETC. We then route the calls over the internal Network.

Works Well

1a2 to ip I seen it all

 

[kyle555]

If you want one-to-one mapping per station to a cell, you've got to do it somewhere. Remote coverage tables, ARS digit conversion, off-pbx station-mapping - whatever. If you're that far deep, maybe manage the remote coverage table and give everyone their own coverage path.

How bout this?
sites 1-20 each get a VDN that share a vector - call it 8001-8020
All those VDNs get a vector - say 101 to 120, and a hunt group - say 101-120 with extn 7001-7020

So, have a hunt group 101 for site 1 and have someone log in to it.
The unique coverage paths at site 1 go to vdn 8001 to vector 101 with "go to step 10 if staffed-agents in skill 101 >0" and "step 10=messaging split 99 for extension active"
Step 2 is busy, which should fail coverage step 1 and hit coverage step 2 which is the unique remote coverage point for the user in question.

By having 1 set per location log in to a hunt group that doesn't get calls, you can use that as a condition to check. Sure, that set dying would make it appear like the site failed, but it's close enough.

 

[bakell]

kyle555,

I tested your suggestion. The first issue I came across was that I couldn't have a coverage point after the VDN - the VDN must be the last coverage point in the path. So, I changed step two in the vector to route to the cell phone number and it had the same behavior as the remote coverage point.

The issue I'm running into now, however, is the hunt group agent check. When the station is logged into the hunt group, the condition for checking staffed agents always returns true, regardless if the phone is connected or not. I tried checking available agents instead, and it also doesn't seem to matter if the phone is connected.

 

[coolwhisper]

You could use a control vector that lets you set a global variable. The vector in your coverage path routes based on the global variable. If you use vdn variables you would only need one control vector. Give site staff/managers the instructions to dial the control variable to activate/deactivate alternate coverage whenever the phones go dead. It is super easy for the users with the right prompts or have a number that activates and another that deactivates. Also easy to add a pin to prevent unauthorized use. Or a call with a certain ANI wouldn't need a pin. Each site can be independently controlled. It isn't as good as automatic but it will work.

 

[kyle555]

Well, you'd need the link loss delay timer for the station to go off before it logged out of the hunt group. Perhaps making the station's "service link mode" permanent on page 2 of the station form might help that failure be detected more quickly. Otherwise tightening that up from the default 6 minutes in system-parameters ip-options should make that quicker.

And I didn't catch that a VDN could only be the last point in a coverage path. So, OK, fine, be that way!
Give everyone a coverage path and a VDN and have their cell number be a VDN variable. So, if user 8001 covers to VDN 9001 with variable 555-555-2222 on vector 101 that checks if anyone's in hunt 101, if so, messaging split 99 for extension active else route to VDN Variable 1.

Or, like coolwhisper says, set global variables manually. Either way, you're trying to automatically get around some fundamental Avaya principle of keeping the PBX in control of the call.

Reach me from voicemail might work - but i don't think it kicks in when you covered because you're busy and on the phone and only when you're in SAC or no answer. Depending on what a voicemail cover message looks like for a disconnected set - like "avaya-reason-for-covering=set not online" or something and AAM being flexible enough to only trigger reach me on that, I'd say that wouldn't work out very well

 

[bakell]

Changing the link loss delay timer and/or the station's service link mode doesn't appear to have an effect on the time that the system determines the phone is disconnected. The station doesn't go out of service until 9 minutes 30 seconds after it's disconnected, regardless of any settings I change. The solution works well enough otherwise.

Does anyone have an idea on anything else that may affect the 9 minute 30 second timer?

Thanks,
Brad

 

[kyle555]

might need to reboot the set for those changes to take.

 

[bakell]

I did a phone reboot and nothing changed - still 9 min 30 sec delay.

 

[kyle555]

my bad. just found out service link mode has nothing to do with tcp sockets...go figure

And LLDT is how long CM preserves the call state once it detects a signaling failure. Look at the bottom left of the network region form. What do those timers look like? That's the time CM is expecting a regular keepalive, and after missing the 1st, it gets default 5 more 5 seconds each, and the phone starts looking for a survivable server after that. If CM misses the 1st default 20 seconds and starts counting the 5x5 timer, if exceeded, CM should detect a signaling failure and start the h323 link loss delay timer relative to call state - but if the call state is idle at the time, it should just deregister it.

Perhaps lower those timers in the network region and the LLDT