Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Call Center Agents in LSP
- Thread starter wpetilli
- Start date
not really. What do you mean by "part of the roll"?
a CM goes into LSP mode because a gateway requested service. Presumably that'd be the condition that causes the phones at that site to do the same.
LSPs have a copy of the CM config, but unlike duplex, do not have current state of agent logins/active calls/etc. So, dropping to LSP means you got to login again
There are 101 ways to configure failover/failback depending on the use case. Say California loses access to the East Coast data center and goes into ESS on the West Coast DC. All sites can see the West Coast DC. You have an option to force phones and gateways to active ESS/LSP to force failover if you prefer keeping the network all together even if you all have to failover together. Or, let California flounder on it's own. Depends what's important to you!
a CM goes into LSP mode because a gateway requested service. Presumably that'd be the condition that causes the phones at that site to do the same.
LSPs have a copy of the CM config, but unlike duplex, do not have current state of agent logins/active calls/etc. So, dropping to LSP means you got to login again
There are 101 ways to configure failover/failback depending on the use case. Say California loses access to the East Coast data center and goes into ESS on the West Coast DC. All sites can see the West Coast DC. You have an option to force phones and gateways to active ESS/LSP to force failover if you prefer keeping the network all together even if you all have to failover together. Or, let California flounder on it's own. Depends what's important to you!
- Thread starter
- #3
When we lost the WAN link to certain locations we have backup VPN, but block the voice traffic (phones/MG) due to lack of QOS. In this case we force the site to go survivable. The s8300 activates and all the phones in the office register to the local 8300 successfully. Some of the users in that office are part of our call center, and are a skill that gets checked. In this state the core server shows them as unavailable and doesn't send calls to them. If that's expected behavior in that state then that's fine. If there was a way for them to still be checked and routed to I'd be interested in that.
Dang. No.
Don't think you can use IGAR either - so, every network region can get a DID for Inter Gateway Alternate Routing and Dial Plan Transparency.
DTP = in WAN fail, no signaling to CM. extn 1111 in NR 1 calls 2222 in NR 2, the LSP handling NR 1 knows NR2 is not reachable, so it grabs a PRI trunk, calls the DID for NR2's DPT/IGAR and passes the digits thru like an automagic auto attendant.
IGAR is the same but implies signaling is in place. But, your network-map/network-regions won't know or accommodate that core 10.x.x.x to site 1 at 172.16.x.x via hops 192.168.1.x core normal WAN is better than thru hops 192.168.2.x on backup VPN. unless those phones had different IPs entirely, CM wouldn't be smart enough to know you're on backup VPN
You do have the conditional in vectoring "if gateway 12 isn't registered then..." which could be leveraged "if no agents in skill 12 and no gateway registered in skill 12, well then...let's vector according to WAN failure!"
Now, if you had that condition, you could route to a DID at site 12 that hits the same vector/vdn/queuing. It'd make sense if site 12 has a PRI and the only agents that ever answer skill 12 are at site 12 and you have central trunks to reach them, that might be a clever reroute.
Depending on how you administer the failover timers, you might be able to get the gateway to failover to LSP but stall the timeout on the phones until the backup VPN is up, so they'd eventually come back to the main, but you'd have no way of getting calls to them if they're only tie to the core is on sketchy WAN and they can't take calls from the gateway on site cause they didn't failover with it.
Don't think you can use IGAR either - so, every network region can get a DID for Inter Gateway Alternate Routing and Dial Plan Transparency.
DTP = in WAN fail, no signaling to CM. extn 1111 in NR 1 calls 2222 in NR 2, the LSP handling NR 1 knows NR2 is not reachable, so it grabs a PRI trunk, calls the DID for NR2's DPT/IGAR and passes the digits thru like an automagic auto attendant.
IGAR is the same but implies signaling is in place. But, your network-map/network-regions won't know or accommodate that core 10.x.x.x to site 1 at 172.16.x.x via hops 192.168.1.x core normal WAN is better than thru hops 192.168.2.x on backup VPN. unless those phones had different IPs entirely, CM wouldn't be smart enough to know you're on backup VPN
You do have the conditional in vectoring "if gateway 12 isn't registered then..." which could be leveraged "if no agents in skill 12 and no gateway registered in skill 12, well then...let's vector according to WAN failure!"
Now, if you had that condition, you could route to a DID at site 12 that hits the same vector/vdn/queuing. It'd make sense if site 12 has a PRI and the only agents that ever answer skill 12 are at site 12 and you have central trunks to reach them, that might be a clever reroute.
Depending on how you administer the failover timers, you might be able to get the gateway to failover to LSP but stall the timeout on the phones until the backup VPN is up, so they'd eventually come back to the main, but you'd have no way of getting calls to them if they're only tie to the core is on sketchy WAN and they can't take calls from the gateway on site cause they didn't failover with it.
- Thread starter
- #5
- Status
Similar threads
