• withold the call
• contact Apple push infrastructure using a proprietary protocol to wake up the client app remotely
• wait for the application to reconnect to the infrastructure and release the call when it is ready

This "I know better than you" approach is ment to further optimize battery life on iOS devices by avoiding the use of resources by apps running in background. It has also the positive effect to force developpers to switch to push model and remove all periodic pollings that ultimately use mobile data and clog the Internet.

However, the decision to use an Apple infrastructure has many consequences for VoIP providers:

• in order to serve iOS app, those infrastructure will need to be tied with Apple service so the reliability of serving incoming calls is directly bound to Apple service.
• Apple may revoke the PushKit certificate. It has then life and death decision power over third party communication infrastructures.
• organisation wanting to setup IPBX and use iOS client have no option but to open access for the push services of Apple in their firewall.
• It is not possible to have iOS VoIP or communication client in network disconnected from the Internet.
• Pure standard SIP client are now broken on iOS

• the 'cloud' or flexible computing where server-side applications are hosted on virtual machines Multiple 'instances' of the same application can be created on demand to cope with load surge. Context information is shared through add-ons such as memcached or databases. Advanced realtime web applications such as facebook use message and notifications and look like good candidate of actor based implementations.
• the Internet of Thing where multiple devices with low processing power coordinates over a local area network and through the Internet. Again, this matches nicely with actor model purposes.
• finally, server side applications such as HTTP servers are put under pressure by growing users bases. The 10K user problem well documented for web servers, occurs in any big server-side application. Adding more processors to cope with load does improve performance linearly as processes or threads spend more and more time to wait for locks when accessing critical ressources. The actor model provides a 'lock free' alternative that can overcome this issue.

Several programming frameworks and languages provides very good ways to implement actor based software. Three of them come in mind:

• Erlang, a language developped by Ericsson and open sourced or Elixir that provides a friendlier language syntax but produce bytcode that is compatible with Erlang VM.
• Scala a language that produces java compatible bytcode. It is used in the famous Minecraft game
• The C++ Actor Framework brings the actor model into native code.

Erlang and Scala merge functional programming with actor model and that has a solid consequence: developpers can only assign variables once and cannot change the value. The only way to change a variable is to send a new messsage (or to call a function) with new arguments. This is a radical way to prevent any use of memory sharing but this breaks most of the classical programming techniques: loops needs to be implemented by recursive function calls or can be replaced with more functional equivalents.

Let's focus now on server side application development, especially in telecommunication field where protocol exchange is the main purpose. Intuitively the actor model fits perfectly . However the majority of telecommunication apps are still developped in classical C/C++ with scripting languages or in Java (SIP servlet). But Actors make four important promises:

1. I shall not fail: Telco applications should always be on. With the OTP framework, Erlang provides a radical way to recover. If an actor detects an error condition, it can crash and be restarted. Dependant actors will be nicely notified about the restart. Application can partially crash and restart limiting the impact to a single user. Erlang also supports code replacement without application stop. I did not test it first hand but if proved, this is a tremendous advantage in telco business.
2. I will not block: by design, actor model is lock free. This remove one of the worst nightmare of any server side application developpement.
3. I can scale: actor model breaks downs a piece of software into a set of coordinated actors that do not share any memory. They exchange messages transparently and therefore can be very easily spread on several hardware system. Traditionnal approach implies communication context sharing that was never fully scalable.
4. I am a finite state machine: That concept is not enough understood while it is central to build robust and resilient telecommunication applications. actor model is about exchanging message. The actor framework provides a natural way to map messages into function calls and implement FSM easily.

So ... why the telecom world is not rushing to embrace actor based programming ?

Its because it requires major cultural changes and telco world is a bit conservative.

• Software needs to be entirely redesigned into actors that are simple and pipelined.
• Developpers need to give up any use of shared memory to store a "communication context".
• no more control on lock and threading
• Langages such as Erlang and even C++ Actor framework uses a syntax that is so different from procedural approach that the learning curve is very steep. Almost hostile.