Reference16r1:Concept Reconnect Calls

Restoring calls can be necessary for various reasons:

• Restart of the PBX. Calls are lost during the PBX restart.
• Loss of network connectivity, for example due to a coverage gap or when leaving a Wi-Fi network and transitioning to 5G or PC switching between ETH and WiFi.
• Audio/video problems in a conference, as an attempt to repair the session.

Applies To

innovaphone PBX and Clients from version 16r1

Requirements

Version 16r1 (not compatible with older versions of PBX or clients)

Configuration

No configuration needed

How it works

PBX Registration

A registration with the PBX is needed in order to establish a call.

In older version (15r1 and below) calls were automatically dropped when the clients lost the registration with the PBX.

Calls now remain in the endpoints and once the registration is restablished with the PBX the reconnect call will be started replacing the old call.

There is an important different between a PBX Reboot or a switching in the network interface:

During a PBX reboot the registration is lost but the RTP Path for audio and video may remain and the user will not notice the reboot while during a switching the user temporarily loses all internet connections experiencing no audio until registration with the PBX and reconnect call are restablished.

Mechanism

The idea of this new feature is that all endpoints involved in a connection store the information required to restablish the connection.

To indicate that this mechanism is supported, the Facility FTY_RECONNECT_INIT is sent during call setup.

An endpoint that supports this mechanism responds with FTY_RECONNECT_INFO Facility which contains an id for the call (the user could have two calls simultaneosly or start a second one later on) and also a hardware id (since the user could have several Softphone instances running)

Restoring the connection is performed by establishing a new call that replaces the old one.

This new call is always initiated by the endpoint that received FTY_RECONNECT_INFO which is typically the side that originally established the call.

The reconnect call setup contains the Facility FTY_RECONNECT_SETUP which contains the id and hardware provided in the FTY_RECONNECT_INFO.

Once this call is transparently connected (user is not aware of the reconnect process) the old call is cleared up.

Known Issues

• Reconnect calls is still not working for external calls initiated by the external participant
• iOS clients take long to detect switching between network interfaces (5G <-> WiFi). That means that there could be a long period without Audio until the registration with the PBX is restablished and the reconnect call can be started.
• myApps may crash if the call is on Hold.
• Calls in a conference are not reconnected at the moment.
• Non successfully Reconnect Calls will be shown in the call list.