IPO survivability scenarios 2

[vtt2019]

Hi Sirs:
For a Customer with IPO Server Edition r11.x (1 Server) where all the IP Telephony (IPT) users are registering in the Primary Server (no survivability),
I need to configure 2 survivability scenarios:
1) IPT Users registering in remote branches (IP500v2) first and if the local expansion unit fails, the same IPT Users will be re-registering in the Primary Server.
2) The opposite scenario, IPT Users registering in Primary Server first, if it fails then re-registering in their local expansion unit.

Sorry I am little confused about how Avaya explains its survivability options in IPO environment versus Aura environment.
Please could you give me how or where to setup these scenarios? is it at the device level or system level or both?
Thanks in advanced.

 

[nnaarrnn]

Everybody should be registered to the Primary Server.

Then you stand up a Secondary Server and set everything up for that to be for System Resilience.

"Branch" IPO Chassis' would only be used for digital+analog trunks and extensions (no survivability for digital+analog).

(unless something's changed in recent versions)

 

[telfire]

Like @nnaarrnn stated, you should always try and register IPT users to the Primary and then fail to either a Secondary or a non-IP500v2 expansion server with normal "Server Edition" licenses. If you have "Select" licensing, you could also fail from a Primary or Secondary to the IP500's (sort of like an LSP on CM) - I have been designing and implementing these for quite a few large customers migrating from the CM. If designed with a virtual Primary Select and a virtual Secondary Select in different locations with their own SBC's and SIP trunks), as well as IP500v2's at the remote sites (with a couple or more POTS lines), gives you the best of everything. In sunny day, all phones register to the Primary (and Secondary if using load balancing), then in rainy day if either fails or the WAN goes down to one of the remote sites, those local phones will fail to their respective IP500v2 gateway and use the POTS lines. Because you have 2 servers, you also have VM Pro resiliency. You must setup "Locations" for this to work properly and then assign the failover location to the SIP extension. This is not for every Server Edition customer, but for those wanting to depart CM because of maintenance costs, it is a rock star. I have also designed this for large Enterprises thinking of going to ACO with those perpetual costs, and they stayed with IP Office. If a customer has the VMware environment, they can create "their own cloud" and the only thing perpetual is the trunking and maintenance, which when comparing a TCO for say 5 years, it's a no-brainer to choose the IP Office solution. Again, this scenario is not for everyone either. Remember that resiliency is only as good as the weakest link. A couple of other issues to keep in mind when attempting to migrate from CM to IPO, are that bridged appearances of any type and internal twinning do not work with different extensions built on different nodes. (I wish Prod Dev would correct this in the near future). Also in CM you have VDN, cover paths and Vectors. These do not exist in IPO and you must create virtual users with UCallFwd's, Cover Groups used as NACallFwd destinations for the Users, and many times Vectors start out as Short Codes or Voicemail Pro modules. All of this needs to be accounted for in the total User and Group counts. I know you didnt ask for ALL of this, but more for others having some of these questions.

APSS-Midmarket
ACIS-Midmarket
ACSS-Midmarket
ACDS-Midmarket