Voice and Video


SIP/Wi-Fi clients for the iPhone: incoming call notifications...

A matter that exercises us frequently and considerably is the gap between what we would like to do with the iPhone, and what’s possible.

An opportunity for a little exploratory coding? Dare I say ‘rapid prototyping’? But mostly on the network side, rather than the client.

As we know, the iPhone doesn’t support apps running in the background. As far as this concerns us in the voice world, we can do outgoing calls easily enough… the user can bring up the SIP app when he/she wants to make a call. But it’s not so good for incoming calls. If the app isn’t running, you won’t be notified about incoming calls. (This isn’t necessarily a show-stopper: if the voicemail system supports email delivery, the incoming call will forward to VM, and the user will get the email, allowing a call-back… and of course this also works when the iPhone is out of Wi-Fi coverage. But it’s certainly incomplete.)

Apple has fixed this notification issue with its Apple Push Notification Service (APNS), which came out around June last year. But it’s still not completely satisfactory.

First, a brief description of APNS. It’s is a two-stage architecture.


Here’s the picture (our little pun: forgive us, but AOL doesn’t let us insert pictures, so please use the link above). The client app on the phone reaches out over the Internet and registers with the APNS server (hosted by Apple), establishing a persistent but intermittent IP connection. APNS sends the app a token, which it forwards back to the ‘provider’, which is the party, like an IP-PBX, that might like to notify the phone of something like an incoming call.

Meanwhile, the provider establishes its own secure connection with the APNS server, using certificates and all kinds of security stuff. Now, when the provider wants to alert the client, it composes a notification package including the user app’s token (remember the app sent it the token to begin with), sends it to the APNS server, and the APNS server pushes it through the persistent IP connection to the client. At the client end it can take the form of a sound, an alert message to display to the user or ‘a number to badge the application icon with’.

By all accounts it works: a number of SIP clients, like iSIP (sold by Vnet) have incorporated this APNS into their client, but the notification has to be originated from their ‘provider’ server. In other words, you get tied to a carrier, and we in enterprise VoIP would rather not do that – we already have a SIP server, thank you. (Also, it’s such a long chain that I would have some concern about latency, but we successfully run plenty of other time-sensitive transactions over the Internet).

There’s a second challenge to overcome: how to maintain the SIP registration when the client isn’t running on the iPhone. We can solve both this and the notification problem by using a proxy (or B2BUA+) that maintains the SIP keep-alives as long as the iPhone is associated on the WLAN, and takes the incoming call from the IP-PBX, using it to trigger the APNS notification. In fact, this seems to be the way Vnet and other cloud-based carriers do it, caching the SIP credentials in their servers and registering as a proxy… some security concerns there, it would seem? But not very useful when the enterprise SIP server won't send a call across the Internet.

Life would be much simpler if Apple would just allow multiple active apps on the iPhone, rendering the above moot and putting the device on the same level as Android and other smartphone OS’s. We have no particular knowledge in that direction, but one can hope. Some of the UC vendors (Avaya etc) have ‘extension to cellular’ mobile clients that may use the APNS mechanism, but there’s little in the way of WLAN connectivity underneath them, and you generally need an expensive server to mediate with the phone – that server would be a useful platform for originating this kind of notification.

Meanwhile, down on the farm at Aruba, in the shadow of the Sunnyvale landfill, we actually have many of the pieces necessary to do this already on the mobility controller… anyone interested in a little programming?

Joe Bob says check it out.

Search Airheads
Showing results for 
Search instead for 
Did you mean: