sipXcom
Child pages
  • Bria Solo with Sipxcom
Skip to end of metadata
Go to start of metadata

Overview

This document is broken up into two sections:

  • Introduction to Bria Solo by Counterpath - installing and configuring the softclient. This section is suitable for administrators and end-users
  • Use of Bria Solo when connecting remotely from an Iphone or Android device to Sipxcom from the public Internet using a Session Border Controller (SBC) as a secure gateway. This section is geared primarily towards administrators. 

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:

  • Bria Solo must be provisioned from the cloud using the Counterpath Stretto platform - the configuration files are then downloaded from Stretto to the Bria softclient upon login. The introduction section to the Installing and configuring Bria Solo section provides a high-level overview of Bria Solo and Bria Solo Free,
  • Bria Solo and Bria Solo Free leverages the Apple and Android Push Notification Services, resulting in significant savings to mobile phone power usage. The downside to this approach is that incoming calls to Bria when using the service remotely works inconsistently - further details can be found in the second section of this document.  The focus in this document  is on configuring Bria to operate remotely with Sipxcom using a data over cellular connection, where a public IP address is assigned to the Bria client. Bria Solo also has capabilities for network address translation and sitting behind a private network when operating remotely - these capabilities will be explored in future iterations of this document.

Introduction - Installing and Configuring Bria Solo

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:

  • Bria Solo Free - the user downloads a fully-featured 30-day  trial of the application on a Windows, MACOS, Android, or IOS platform. After 30 days, the trial ends and Bria Solo features (e.g. call forwarding, transfer) get downgraded to Bria Solo free with a similar experience to X-lite. When being downgraded to Bria Solo Free, the Counterpath web site keeps track of the last device that logged into Bria - after converting to Bria Solo Free, the user must use that device for 28 days (see following image) before it can be de-registered and Bria can be registered from another device. Bria Solo Free limits the user to 1 device at a time.
  • Bria Solo - 3 device installations (desktop & mobile apps), supporting 5 accounts and features such as call transfer, auto-answer, and call recording. Subscription cost is $2.95 per month, or ~$35 for an annual subscription. Fixes are automatically applied as they become available from Counterpath.

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.

Step 1 - Open a User Account with Counterpath

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.

Step 2 - Set up a Voice Account for Bria Solo in the Web Portal - User is on the Enterprise Network

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:

  • Domain Name
  • Port
  • SIP User Name
  • SIP/Voice Password
  • Call Display

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.

Step 3 - Set up a Voice Account for Bria Solo in the Web Portal - User is on the Public Internet

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:

  • Use the domain name provided by Louisa Voice - e.g. remote.test.com
  • Port setting is Auto
  • Sip username is the extension number e.g. 8500
  • SIP/Voice password is the extension password as defined in the Sipxcom voice server

Go to the Service Settings tab and provision the following:

  • SIP Proxy setting is public IP address of the firewall front-ending the SBC and port number provisioned in the SBC connected to the dialplan. For this document, the SIP proxy setting is 108.xx.12.232:25067, where 25067 is the port the SBC listens to for incoming remote calls.
  • Check the Register with domain and receive calls option.
  • Set transport to UDP - Bria Solo Free does not allow TCP transport.
  • Firewall method is STUN
  • Firewall server URL is stun.counterpath.com and firewall method is ICE.

With Bria Solo Free, the Voicemail number cannot be provisioned so the user must dial 101 to access voicemail.

Step 4 - Configure Bria Mobile Client on an Iphone or Android

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:

  1. Go to the Bria->Settings→Account menu. Disable the SIP account
  2. The Display as Field is provisioned from the cloud (step 3)
  3. The Username is provisioned from the cloud (step 3)
  4. The domain name is provisioned from the cloud (step 3)
  5. Ascertain the Use Push Notifications option is enabled
  6. Set the Registration mode to the Single Device Takeover or Single Device Emulation -  alternate registration modes were tested but did not work with any consistency.
  7. Turn off NAT emulation

When the above seven steps have been completed, enable the SIP account again (point 1 above).

Use of Bria Solo when connecting remotely from a Mobile Device to Sipxcom using a Session Border Controller (SBC) as a secure gateway

High-Level Architecture

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.

Case 1 - Incoming Call to x8500 - Remote User Extension is not Registered to Sipxcom

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.

Case 2 - Incoming Call to x8500 - Remote User Extension is Registered to Sipxcom by the Counterpath Push Notification Service

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.

Using Registration Mode of Single Device Emulation

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:8500@10.20.4.59...) from the Sipxcom registrar.


Case 3 - Incoming Call to x8500 - No Remote Registrar Entries for Sipxcom

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.

Case 4 - Remote User Toggles Mobile Phone Between SLEEP Mode and Bria, Generating Multiple Sipxcom Registrar Entries

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.

Behavior using Bria Single Device Emulation Registration Mode

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:8500@10.20.2.25...) in the Sipxcom registrar when mobile phone goes into SLEEP mode.


Summary

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.








  • No labels