Being Pushy with VoIP—What we learned about push notifications, iterative development, and working with customer partners.
Push Notification is a generic term that describes a mechanism used to send messages to a mobile device. These messages could be texts or application information sent in order to make an app on the phone “do something”. For real-time media applications such as Bria, it’s used to conserve battery—and in a big way.
So, leveraging Push Notifications is a really big deal. The solution that CounterPath offers both limits their impact on battery life of Bria based clients (takes battery usage from something; to essentially nothing) and it protects against missed calls in cases where the operating system has stopped the application from running in the background.
Unfortunately, we have seen that the last few releases of both iOS and Android have been progressively more aggressive with closing background applications and disconnecting data connections. SIP is a connection based protocol like many others. What the mobile operating systems have done is to effectively deprecate support for multimedia applications outside certain use cases like a music or audio player or GPS application. There are some exceptions, but what we see is:
- Mobile applications in the background are subject to being stopped at any time by the operating system.
- Data connections for a mobile application can also be disconnected without allowing the application a chance to re-establish that connection until the application is in the foreground.
We are starting to understand that running a SIP stack within a mobile application in the background on a mobile device will become impractical if not impossible without Push Notifications. We want to encourage our customers to work quickly to understand their options and move forward with an implementation that meets their needs.
In this post, I’ll share some things we learned as we developed what we believe to be an unmatched Push implementation. We definitely took our time to get it right and certainly learned from others on what not to do. There are some technologies where it makes sense to be a fast follower in order to take a leadership position and establish the best user experience. We did this with CallKit and now with Push. Here's what we did to Make Push Great Again:
- Leveraged our relationships with PBX partners
- Worked with service providers and ITSPs
- Created a way for all the core use cases to work--every time
As we thought about the uses cases and the challenges of making Push work with “any call platform”, we carefully thought through the different approaches and came up with two viable options, Push (1) via B2BUA and (2) leveraging APIs.
B2BUA = Back-to-Back User Agent (Wiki). This can be described as a SIP server that maintains two separate call legs between other SIP entities, perhaps 2 clients, or a client and a server. This solution was released in 2014 as CounterPath’s first Push solution targeted largely towards operators and large enterprises with a single or a few large and/or high volume back end SIP servers. The Stretto B2BUA Push Module as the name describes is a SIP B2BUA. All Bria client calls pass through the Push server. More than that it is a SIP registrar that is deployed inside and/or northbound of a carrier’s SBC. Bria SIP clients register to the Stretto B2BUA push server through an SBC (Session Border Controller) (Wiki). Stretto is also registering on behalf of each user and sip account to the carriers SIP application server in a persistent manner. Bria clients, when in the foreground, SIP register to the Stretto Push server and when in the background Push subscribe (over https API) to the push server. The Push server can support multiple clients per account, in either foreground or background, and alert them all for each incoming call plus handle outgoing calls from all clients.
The B2BUA solution is particularly interesting to customers who are unable to modify their SIP server and need a SIP solution to plug into their network. The Stretto B2BUA Push module is offered as only as a premise deployment.
This solution was developed to remove the Stretto Push Server from the SIP signaling path and allow customers who were operating or building their own PBXs / SIP servers to interact with Stretto using an API. It allows Stretto to manage both client push subscriptions and interaction with Google and Apple for formatting / sending of push messages. Stretto API Push exposes a REST API that allows a customer’s SIP server(s) to alert their Bria clients. This push wakes up the Bria client and has is register to the SIP server. At that point, the SIP server can extend the inbound call to the Bria client and the user can receive the call.
The API solution removes the SIP interworking tasks / deployment requirements and manageability friction points that were part of the B2BUA Solution. The API solution requires that customers can adapt their SIP server to launch API messages and wait for mobile Bria clients to re-register before forwarding INVITEs to these clients. CounterPath has documentation on how Asterisk-based systems can achieve this through dial plan modification [no code] and similar configuration changes are possible in other open source systems including FreeSWITCH.
The API Push solution is offered as either a premise deployment of Stretto software or hosted by CounterPath.
Stay tuned to our blog for news on our upcoming Bria Mobile release! For more information about CounterPath, visit our website.