Reference16r1:Concept myApps Redundancy

From innovaphone wiki
Jump to navigation Jump to search
There are also other versions of this article available: Reference13r3 | Reference16r1 (this version)


The myApps client handles the failure of a single PBX by failover to a secondary PBX.

Applies to

  • innovaphone devices with a PBX from version 16r1
  • innovaphone myApps (all platforms)

General concept

The innovaphone PBX has implemented a mechanism, that by adding a single PBX to an installation, from the failure of any single PBX can be recovered.

  • For a single PBX a standby PBX can be configured
  • For a slave PBX a standby-slave PBX or otherwise the master can act as standby
  • For a master PBX any slave PBX can act as standby

The myApps client can connect to any PBX in the system. If it does not match the PBX on which the user is configured on, the client follows a number of redirects until it ends up at the user's PBX.

  • Standby PBXes (including standby-slaves) redirect to their active PBX.
  • Slave PBXes redirect to their master PBX.
  • The master PBX redirects to the slave PBX of the user.

Handling of standby cases

If the current PBX has no registration to the PBX it would redirect to, it acts as a standby and keeps the myApps connection.

If a slave should act as a standby for the master, the myApps client must be logged on to the slave. This forwards the login to the master. In the event of a failover, the slave takes over.

For cases in which the initial PBX is unavailable the myApps client tries to connect to two PBXes in an alternating manner:

Primary PBX
This is the PBX where the client tries to connect first.
Secondary PBX
This is the PBX, where the client tries to connect, when the connection to the primary PBX failed.

Handling of connection loss

If the connection to the current PBX is lost:

  • myApps tries to re-connect to the current PBX first.
  • If the current PBX is unavailable it restarts connecting to the primary and secondary PBX in an alternating manner.

Determination of primary and secondary PBX

On each successful connection in a non-standby case, myApps determines the primary and secondary PBX automatically and stores the information for handling standby cases.

Primary PBX

The PBX configured in the myApps client is used as the primary PBX.

Secondary PBX

There are different cases to be considered to determine the secondary PBX:

  • In case the client was redirected to the PBX the user is configured on
    • the explicit standby of this PBX is used as secondary PBX (if existing)
    • this PBX is used as secondary PBX (otherwise)
  • In case the client was not redirected but stayed on the primary PBX
    • the explicit standby of the primary PBX is used as secondary PBX (if existing)
    • the implicit standby of the primary PBX (the master for slave PBXes) is used as secondary PBX (if exisiting)
    • no secondary PBX is used (otherwise)

Published information for the softphone app

The myApps client publishes the determined configuration along with other connection details in the API model of com.innovaphone.client inside the connInfo object.

This information is used by the softphone app. See Reference16r1:Concept_Softphone_Redundancy for details.

Example:

"connInfo": {
   "up": true,
   "standby": false,
   "cur": "slave.example.com/PBX0",
   "pri": "master.example.com/PBX0",
   "sec": "slave.example.com/PBX0",
   "phys": "master"
}

Values:

up
true, if the connection is up. false if myApps is offline.
standby
true, if the myApps client is connected to a standby PBX. false, if the myApps client is connected to the user's PBX.
cur
the current PBX in the format host/pbx-module
pri
the primary PBX in the format host/pbx-module
sec
the secondary PBX in the format host/pbx-module
phys
the physical location, if configured explicitly

Configuration

For configuration in the myApps launcher, see Reference16r1:Concept_myApps_platform_services#Server_configuration.

In the browser the PBX specified by the URL is used as the primary PBX. An explicit physical location can be set using a URL parameter, see Reference16r1:Concept_myApps#Supported_URL_Parameters.

Tracing

Trace flags

Browser Console
to see the connection flow including redirects and determined configuration

For trace flags for the softphone app see Reference16r1:Concept_Softphone_Redundancy#Tracing