When the CounterPath Bria Enterprise application is used on a mobile device the native operating system (Android or iOS) can close the application when it is running in the background to preserve battery life.
As this can happen, it is important to make sure the application is still receiving phone calls regardless of whether the application is open and running in the foreground, or if the application is:
- Running in the background
- Closed (Manually, or by the Operating System to save battery)
The Bria Enterprise Application ensures this by utilising the Bria Push Servers to take over the SIP registrations of the accounts. In most cases this is when the application is closed, or running in the background.
Now, because some SIP servers support multiple SIP Registrations per SIP extension and some only allow one SIP registration per extension it’s important to configure the CCS provisioning portal with the correct value to reflect your SIP servers registration method (otherwise your clients may end up missing calls).
The table below shows the setting that changes the application and Push servers behaviour. Hopefully from the information below you can choose the appropriate value. Remember after each change in the CCS portal each user needs to logout of their application and back in again to apply the changes.
| Setting: accountN.briaPush.RegistrationMode (where N is a number from 1 to 5) | Parameters: 0,1,2,3 |
| accountN.briaPush.RegistrationMode controls how the combination of the Bria Enterprise client and the Bria Push server interact with the SIP server. Continuous (2) and Standard (0) are used if your VoIP service provider supports multiple registrations. Single Device Takeover (3) and Single Device Emulation (1) are used if your VoIP service provider does not support multiple registrations. 0:Standard (Dual Instances Alternate): Allows both the Bria Push servers and the Bria Enterprise clients to register to a customer’s SIP account in an alternating manner. In this mode, there may be short overlaps of registration where both the Bria Push server and the Bria Enterprise client are registered to the SIP server. Some PBXs, SIP servers or SIP services may have issues with this registration overlap. If you encounter an issue with registering to the SIP server or receiving push notifications, select a different mode. This option is equivalent to the deprecated pushSingleRegistration setting set to False. 1: Single Device Emulation (Single Instance Alternate): Ensures that both the Bria Enterprise client and the Bria Push server unregister before the other one registers. In other words, the Bria Enterprise client and the Bria Push server never register to a PBX, SIP server, or SIP service at the same time. The Bria Enterprise client controls the registrations by requesting the Bria Push server to register only after the Bria Enterprise client has de-registered and alternately, by receiving confirmation that the Bria Push server has de-registered before the Bria Enterprise client registers directly to the SIP server. The Bria Enterprise clients will also not register while they are in a call delivered through the Bria Push server so that they do not cause potential issues with the call in progress being terminated by the SIP Server. This option is equivalent to the deprecated pushSingleRegistration setting set to True. Note that when in the Single Device Emulation mode, there are periods of time (typically fractions of a second) when neither the Bria Enterprise client or the Bria Push server will be registered to the PBX, SIP server or SIP service. This gap could lead to a missed call if the call is presented to the SIP server at the same time that neither element is actively registered. This is a downside of the requirement of the SIP server that only one element can be registered at any one time. 2: Continuous (App Foreground, Server Persistent): Ensures that the Bria Push server is always registered on behalf of the Bria Enterprise client. The Bria Enterprise client still registers directly to the SIP server when in the foreground, but the Bria Push server does not de-register from the SIP server. In this mode, all inbound calls and all outbound calls from the Bria Enterprise client are handled by the Bria Push server. The Continuous mode, in particular, is used when a SIP server supports multiple registrations at the same time. This mode avoids any gap in SIP registration because the Bria Push server is always registered on behalf of the Bria Enterprise client. In the event of a call to the SIP account while the Bria Enterprise client is in the foreground, the Bria Enterprise client will receive an INVITE directly from the SIP server and via the Bria Push server. The Bria Enterprise client will filter out these duplicate events and only allow one of the call attempts to progress. 3: Single Device Takeover (Single Instance Takeover): This is an enhanced option of the Single Device Emulation mode. The Bria Enterprise client and the Bria Push server take over registrations from each other without unregistering first. Neither the Push server or the Bria Enterprise client sends SIP de-registration messages when transitioning from one element to the other. It aims to eliminate gaps that are present in the other registration mode. This mode is in some cases beneficial for SIP servers that only support single registration. |