Recently, I wrote Implementing Battery-Saving Push Notifications in Bria covering important changes quickly emerging in mobile VoIP around backgrounding of applications and push server options currently available for customers.
With our Bria Mobile clients for iOS and Android launch this past Tuesday, we are very excited to offer our customers who purchase a subscription to these new clients with a significant new capability without disrupting the user experience they’ve come to enjoy. The art of pushing this new feature is that most customers will be unaware what this new feature is doing for them once they turn it on, other than improved battery life and call availability that is!
For me, this is the most exciting and amazing softphone CounterPath has ever designed for mass use. We know you will love it.
At this point both the title of this post and the graphics have let the cat out of the bag. CounterPath is doing something about push notifications. I want to draw attention to the fact that VoIP has been on mobile devices since before we can all remember. Then, why hasn’t CounterPath done something about it?
Well… we have. Twice. Read my previous post for more information. The solutions we’ve built and provided to our Voice Provider customers have not targeted our mobile retail customers. With the Bria Mobile release, that changes.
We’re doing something special and exciting for our customers. What push does for VoIP applications is limit their impact on battery life. It takes usage from something significant to essentially nothing and it protects against missed calls in cases where the operating system has stopped the application from running in the background; which is only getting more common. By solving this for our retail customer users, we solve for all users.
As Apple and Google became more aggressive with both limitations on running in the background and background communications, CounterPath set out to update our client to support a Push solution along with many other new features, OS updates and new devices that would work for any Bria Mobile client (iOS, Android, Retail or Branded) against any publicly reachable SIP service provider or server.
This is huge—let me say it again, CounterPath developed a solution that would work for any Bria Mobile client against any publicly reachable SIP service provider or server. Some so-called competition claim they have push – but they really don’t and if they do, it certainly does not work over any platform.
Bria Push is a Stretto server software module similar in some ways to the previous Push implementations but that also departs in a few important ways. Most notably:
- No modification is required within a customer’s SIP server or SIP service provider’s network. No Code. No Configuration.
- This service is hosted by CounterPath. The service is included in the subscription for Bria Mobile and requires minimal setup or knowledge for the end user.
At this time, we have not turned the service on by default. End users or their IT staff helping them set up their Bria Mobile clients need to turn the feature on using a simple slider in the account configuration menu as seen below.
We’ve left enabling the service to the user for two important reasons.
Reason one: At this time, we are calling this feature BETA. At CounterPath we don’t use that term Generally Available (GA) lightly. Think of the definition of BETA we are using as a very polished and well tested service; but it is a new service that we’re launching to hundreds of thousands of customers. Each customer will perhaps have their own unique requirements or SIP usage scenarios. We know SIP is SIP. But as we all know, RFC3261 is a set of guideposts that are generally followed, but allow room for many implementation differences. We also have a very wide-ranging customer base, some of whose servers we’ve discovered aren’t yet using 3261!
Reason two: We want to be absolutely clear with our customers about what we do and don’t do with the configuration data they enter into Bria Mobile. If a user never enables Bria Push, their account information never leaves the Bria Mobile client. If a customer does enable Bria Push, we transmit your SIP username, SIP Domain, SIP Proxy (if set), SIP Password, and a few more technical settings related to push (Single Device Emulation, NAT Emulation, Alternate SIP proxy) inside an SSL encrypted / secured API message to the Bria Push servers to create an account. When this account information arrives at the Bria Push servers we encrypt your SIP password for storage in our database.
We’ve launched Bria Mobile. Today however is neither nor the start or the end of our work on Bria Push. Bria Mobile and the Bria Push service has been in the hands of our internal QA team for a number of months. We’ve built up a set of over 20 ITSP partners whose accounts we’ve leveraged for our internal Bria Push testing. We’ve also tested Bria push against many of the most common SIP servers that our customers are using today. Through this testing we have chased down issues with our mobile and server development teams. It has been an intense few months of testing.
We’ve also had great feedback and help from our Bria Mobile BETA community. We appreciate their support and assistance with testing this feature in their environments. We want to take the time to thank each and every BETA community member for their commitment to helping CounterPath improve products and services that empower better user experience. Also we want this community to know that our launch includes a number of code and deployment improvements that are a direct result of this valuable interaction with the community. With the help of the community we have now tested with hundreds of SIP domains and hundreds of different SIP servers, (ignoring the different versions of these servers we can see in User-Agent strings!).
While thanking our customers, I also want to quickly to thank our team. The tentacles of a project like this are far reaching. Certainly, members of the development teams across iOS, Android, Stretto and the SDK contributed to this project. As well, the contributions fromQA, Support, Product and so many internal power users has been instrumental. A special thanks to the architects and development leaders of Bria Mobile and Bria Push. All of whom have worked tirelessly on the design, implementation, troubleshooting, bug fixing, bottle washing and shoe shining of anything related to Bria Push over the past months. It has been both amazing and thoroughly enjoyable to have a front row seat on the action.
So Jim, enough… how does Bria Push work? What’s special?
Here are the high level ideas:
- When Bria is in the foreground it operates like any other previous Bria client, communicating directly with the SIP server.
- When Bria Mobile goes into the background, the Bria Push service registers on behalf of Bria Mobile. The push server stands in for Bria.
- This means that Bria can shut down its SIP stack, stop using battery, or be killed by the operating system at any time.
- The Bria Push servers will stay SIP registered so that they can wake up the Bria Mobile application when the SIP server sends an inbound call.
Below is a simplified diagram of what happens when Bria Mobile goes into the background on a mobile device.
This flow looks simple and IS simple.
Bria Mobile subscribes to push which is a request that asks the push server to register to the SIP account on behalf of the client and alert the client if there is an inbound call. The interaction between Bria Mobile and the Bria Push server is done over SSL, encrypted and secured. The Bria Push server then registers to the SIP service provider or Enterprise PBX.
When a SIP account is created in the client and push is enabled for that account, the account information is also transmitted to the Bria Push service over SSL (TLS 1.2) and stored in a database with the sensitive information encrypted. If the customer chooses to turn off push for an account or delete an account within the Bria Mobile client, the account information is removed from the servers and no longer retained by CounterPath.
Below is a simplified diagram of what happens when a user’s SIP account receives an inbound call.
This diagram has a few more arrows, but the design and the flows are straightforward.
The Bria Push server anchors the signaling from the SIP server. When the push server receives a call for an account it wakes the Bria Mobile client associated with that account by sending a push notification. When the Bria Mobile client receives the Push notification it opens an encrypted SSL tunnel to the Bria Push service and receives the INVITE sent by the SIP provider through that tunnel. Bria Mobile then responds as it would to any other call issuing RINGING answering the call with a 200OK and negotiating codecs, media ports etc. through the tunnel connection. RTP (and SRTP) media flows directly between the Bria client and the SIP server / service providers’ infrastructure.
While this isn’t a complete run through of all the messaging and use cases, the important take away is that the user should not perceive that any of their traffic is handled by the Push Server. Users can receive calls, make additional calls, bridge multiple calls, upgrade calls to video, or do anything else they might do while signaling directly with their SIP server / ITSP.
We’ve done the testing of the service and worked through the interoperability issues to be able to say this:
- We designed Bria Mobile and Bria Push Services to solve a significant challenge in the VoIP community.
- Running SIP applications on mobile devices is possible, but battery life concerns and background application policies of the major mobile operating systems are on the verge of presenting a challenge to this idea.
- Bria Mobile and the Bria Push Service work with all the SIP service providers we’ve tested and with all of the SIP servers we’ve tested. The list is long.
- As we move past our BETA community testing and launch the BETA for all customers we want to continue to hear from customers who have a scenario that isn’t working as they expect.
- We expect there will be issues. Our team is ready to listen and work with customers to understand the issues and work to solve issues that are under our control.
- There are 2 basic requirements for the push service: 1) Bria Mobile needs to be able to access the Push server and the SIP Server. 2) The SIP Server / SIP Provider needs to allow SIP registrations from the collection of Push Service servers hosted by CounterPath.
Please give Bria Mobile a try. We hope that you’ll forget Bria Push is working on your behalf very quickly.
A final comment: Our Bria-X, Bria Stretto, Enterprise and Carrier customers shouldn’t worry that they are missing out because their deployments are not the focus of Bria Push at the time of launch. We’ve been offering these customers our B2BUA and API Push solutions for some time. We’re quickly productizing the Bria Push capability for enterprise and carrier customers. The plan is to very quickly offer this as a hosted capability and with the next Stretto release this fall offer this as a solution customers can deploy in their own data centers along with the other Stretto modules they are already using to enhance their customers experience using the best mobile softphone available on the market today.
