This document is broken up into two sections:
The standalone versions of Bria and X-lite are deprecated starting in release 6 by Counterpath and replaced by Bria Solo - there are two significant changes introduced:
Counterpath, which is the software publisher for the Bria and X-Lite soft clients, has eliminated the X-lite standalone Free Clint and rebranded it as Bria Solo in their release 6 offerings. Bria Solo comes with the following options:
The new Bria softclients are provisioned from the cloud using the Counterpath Stretto platform and configurations downloaded to the softclient. Changes to the voice account must be applied through their web portal - unlike X-lite, the account information on the softclient is locked and cannot be changed. Bria Solo also keeps track of devices accessed by Bria - when using the Free version, users cannot change devices (e.g. Windows 10 to Iphone) for 28 days. In the free version of Bria Solo, other capabilities such as automated voicemail access and TCP transport are disabled - the user must upgrade to a Bria Solo subscription in order to access these features.
Go to www.counterpath.com and click on the Start a 30-day trial radio button.
Click through menus until you arrive at the Select your plan menu. Select the Bria Solo radio button and click on the Continue with Bria Solo button at the bottom.
The web portal will request your email address - enter it in the menu.
Enter an appropriate password.
The 30 day trial subscription to the full Bria Solo functionality is now activated and the portal will now walk you through the details of setting up an account. Click on Set Up a Voice Account radio button and then Configure SIP settings button in the menu. Accept the terms for creating an account which will then bring you to the Configure a Voice Account menu. Use this setup when the user in on the Enterprise network with network access to the voice server.
The Configure a Voice Account Menu will request the following information - this information will be provided by your voice administrator:
Enter the pertinent information from your administrator and then proceed to the next step by clicking on the Configure Service Settings menu.
The Counterpath web portal will then prompt for service settings - your administrator will provide guidance on these settings depending on whether you are connecting to the voice server via a VPN connection or remotely from the public Internet using a session border controller (SBC) gateway.
The Counterpath web portal will then prompt you to download the appropriate Bria client. After the 30 day trial period has expired, Counterpath will allow one client to access the web portal and downgrade the Bria Solo application to Bria Solo free.
After the Bria application is started, the portal will request your email address and password. Once signed in, the Bria application will download the account configuration file from the Counterpath cloud and load into the client. Properly configured, the
The Counterpath web portal offers a dashboard where voice configurations for Bria Solo can be administered and subscriptions managed. As well, Bria clients for the four supported platforms can be downloaded.
Use this setup when using Bria to connect to the voice server from the public Internet using a Session Border Controller (SBC) gateway with gateway dialplan copnfigured for your organization. Open up a Counterpath account as described in the previous step. Instead of the service settings defined for an enterprise, edit the General profile as follows:
Go to the Service Settings tab and provision the following:
With Bria Solo Free, the Voicemail number cannot be provisioned so the user must dial 101 to access voicemail.
According to Counterpath technical support, Bria works best with the Push Notification Server when a public IP address is assigned to the mobile client - current testing has been with this configuration. In this mode, WIFI capability on the mobile phone must be disabled and Bria must connect using the data over cellular mode of transport. As well, the following options must be configured on the Bria client:
When the above seven steps have been completed, enable the SIP account again (point 1 above).
The following diagram shows the high-level architecture of Bria on a mobile phone accessing Sipxcom from the public Internet using the Sangoma SBC as a secure gateway to proxy SIP signaling and bearer path between remote Bria and Sipxcom. This document assumes the administrator is familiar with the Sangoma SBC upper registration feature along with the configuration of SIP profiles and dialplans for remote phones.
The Bria 6 client on the mobile phone must be deployed using data over cellular capabilities and receive a public IP address - the WIFI network on the phone must be turned off in order to use the Counterpath notification service. The Bria client setup in the previous step documents how to configure Bria 6 for remote use using the data over cellular capability.
The Counterpath Push Notification Service builds on Apple and Android capabilities to wake up the phone for incoming calls in a power-efficient manner. Prior to Release 6, the Bria application would be running in an 'always on' mode to receive incoming calls which would quickly drain the mobile phone battery. In all cases during testing, outbound calls were able to be successfully placed. The next few sections describe the behavior of the mobile phone running Bria 6 when receiving incoming calls.
It is recommended that a hard phone be provisioned with the extension (e.g. x8500) for every remote phone defined by Bria 6. There are corner cases where the Counterpath Push Notification Server does not respond to an INVITE from Sipxcom - without the remote extension defined somewhere, the calling user will hear 20 seconds of silence before voicemail kicks in. With the remote extension (e.g. x8500) defined on a hardphone, the calling user will hear ringing before voicemail kicks in if the Counterpath Push Notification server is unable to wake up the Bria client.
From the architecture diagram, x8500 is mapped to a Polycom phone at x8500 - the Sipxcom registrations page looks as follows:
There are no registrations from the mobile phone stored in the registrar - this is probably due to the Bria 6 application on the Iphone or Android mobile phone being dormant for an extended period of time while the phone is in SLEEP mode. To conserve mobile battery power, some mobile phones stop Bria from running in the background after a specified interval. In this scenario, Sipxcom by default will ring x8500 on the Polycom phone at 10.20.4.59 and then place the calling user into voicemail. By waking up the mobile phone from SLEEP mode and starting the Bria 6 application, the soft client on the phone will register to Sipxcom, and incoming calls to x8500 can be answered from Bria on the mobile phone.
From the architecture diagram, both the x8500 extension from the Polycom phone and the x8500 extension from the remote Bria phone are defined in the Sipxcom registrar. For the Bria soft client, the registration comes from the Counterpath Push Notification Server, where a 32-character globally unique identifier is appended to the extension. The Sipxcom registrations page looks as follows:
When an incoming call arrives at the voice server for x8500, Sipxcom sends an Invite to the Counterpath Push Notification server, the server then wakes up Bria on the mobile phone and rings to signal an incoming call - the attached packet capture screen-scrape shows the SIP signaling,
An issue being worked with Counterpath Support is that when the Bria remote phone registration expires, the Counterpath Push Notification Server does not consistently renew the registration. When the Bria remote phone registration is not renewed, then the Sipxcom registrar reverts back to scenario illustrated in Case 1. Waking up the phone and starting the Bria application renews the mobile phone registration on Sipxcom and re-initiates the processing of incoming calls.
One pattern that is being observed as this document is written is that upon expiry of the registrar entry in Sipxcom generated by the Counterpath Push Notification Server, there would be no Bria remote phone registrations for 15 minutes - then the push notification server would issue a new registration request to Sipxcom with the extension+32 character GUID. Another pattern being observed was that the Push Notification Server would issue a registration renewal upon expiry in Sipxcom, and then miss registrations to Sipxcom based on multiple increments of 15 minutes.
When configuring Bria to use the Single Device Emulation registration mode, when the Counterpath Push Notification Server issues a new registration request to Sipxcom with the extension+32 character GUID identifier, the registration request clears out any extension entries (e.g. sip:email@example.com...) from the Sipxcom registrar.
When there are no remote registration entries for x8500 in the Sipxcom registrar, then the behavior outlined in Case 1 applies here. The user goes into their mobile phones, and starts the Bria application - entry (1) is generated from the SBC. When the mobile phone goes into SLEEP mode (default on an Apple iPhone is 1 minute), the Counterpath Push Notification Server generates entry (3) in the Sipxcom registrar. In both cases incoming calls into x8500 arrive at Bria on the Mobile and ring.
The packet capture screen-scrape shows the two invites for the x8500 remote phone arriving from Sipxcom, and the SBC merges the Invite request into one request and sends the INVITE to the Counterpath Push Notification Server, which then rings the remote phone.
In this scenario, a remote user with the Bria application toggles the mobile phone between SLEEP mode and accessing Bria 4-5 times - when the user access Bria after coming out of SLEEP mode, multiple x8500 entries for the remote user are created in the Sipxcom registrar.
Having multiple entries for the x8500 remote user has no impact on incoming or outgoing calls. Duplicate registration entries for the remote x8500 extension will expire.
This case does not occur using the Bria Single Device Emulation Registration mode as the Register request from the Counterpath Push Notification Server with the extension+32 character GUID identifier clears out all extension entries (e.g. sip:firstname.lastname@example.org...) in the Sipxcom registrar when mobile phone goes into SLEEP mode.
The remaining issue being worked with Counterpath Support is Case 2 - the Counterpath Push Notification Server does not consistently issue a REGISTER request to Sipxcom to renew the registrar entry for a mobile Phone that has gone into SLEEP mode - when in this state, incoming calls do not ring the Bria remote client on the mobile phone. This issue has no impact on outgoing calls from the remote phone. The workaround here to receive incoming calls is to take phone out of SLEEP mode and access the Bria application - this will generate new entries in the Sipxcom registrar that will take 60 minutes to expire.