×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

IPO survivability scenarios
2

IPO survivability scenarios

IPO survivability scenarios

(OP)
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.

RE: IPO survivability scenarios

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)

RE: IPO survivability scenarios

2
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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close