SIP Instance Server

The SIP Instance Server (SIPIS) is Acrobits’ workaround for the “no multitasking” limitation of Apple’s iPhone OS (prior version 4). Due to that limitation, it is not possible to receive incoming SIP calls, unless a softphone application is already running on the device, which, on the other hand, prevents iPhone users from doing anything else.

Apple’s answer to the above and similar issues was the introduction of the Apple Push Notification Service (APNS). Basically, one can send a chunk of data to Apple and Apple will forward it, at its own discretion, to a particular device, based on the device’s unique identifier. The device may then display a simple message box, allowing the user to start an application which can further process the push notification.

Unfortunately, APNS alone doesn’t really solve the incoming call problem as a SIP softphone must periodically refresh its registration on the registrar server to be able to receive and answer incoming calls. Therefore, to receive an incoming SIP call on the iPhone at any time, there must be an entity which maintains the SIP registration on behalf of the iPhone user while she is using the device at her pleasure. This entity is the SIP Instance Server -– it registers on behalf of the iPhone user and when incoming call arrives it notifies the user’s device via APNS.

Now we are almost done. The only remaining problem is how to patch the incoming call through to the device. This turned out to be the most difficult problem. In the end we ended up with the following method which puts SIPIS to the role of an active relay. When a device receives a push notification about a pending incoming call, it launches the softphone application. The softphone creates a special SIP user agent which communicates directly with SIPIS. Next, the softphone notifies SIPIS about its “readiness” and SIPIS then proceeds by initiating its own SIP call with the device. This new call is constructed using most of the information from the real incoming call, so from the iPhone’s point of view it just seems as if the call came directly from the calling party (while it is, in fact, just iPhone – SIPIS “tunnel”). Once this new call is established, SIPIS relays all relevant signaling information between these two separate calls. Note that while SIP signaling goes always through the SIPIS, RTP media streams don’t.

SIPIS Ecosystem

The following diagram illustrates the SIPIS ecosystem with the SIPIS Installation placed inside the VoIP provider’s perimeter.

../_images/overview_ecosystem.png

SIPIS Ecosystem

For its full functionality, SIPIS relies on the following external services.

PostgreSQL Server

SIPIS uses this database to obtain the information necessary for a successful registration on behalf of the softphone users. The database also serves as a persistent data backend.

Push Notification Mediator

Internally, SIPIS uses proprietary unified push notification protocol. It is the task of the Push Notification Mediator, to transform incoming push notifications to the appropriate format for a given platform and relay them to the platform specific push notification service.

TLS, TCP to UDP Bridge + Load Balancer

SIPIS itself handles all communication with the softphone via the UDP protocol. To allow the softphone to communicate with SIPIS using the TCP and TLS protocols, we decided to build this small utility program that translates TCP and TLS traffic to corresponding UDP traffic and vice versa.

Optionally, this program can be configured to distribute server load to multiple SIPIS servers – each one dedicated to a portion of the entire user space.