setKeepAliveTimeout iOS behavior, exceeded 15 wakes in 300 sec

Question

I am writing a VOIP application on iOS 5 and I am trying to understand how the actual communication can stay alive while in the background.

I understand there is a maximum amount of wakes the socket can get per amount of time. My problem is that my socket connection receive too many wakes messages, because of that the app is terminated with crash message:

exceeded 15 wakes in 300 sec

What I really don't understand is how is the socket supposed to be able to constantly send and receive data through it (for VOIP needs) if there is a limit for the amount of data it can receive per amount of time?

Let's say the socket is receiving voice data for a voice conversation that is happening while in the background. Is it not that voice data supposed to go through the socket connection? If so, how can it work if there is a limit for the activity the socket can have per amount of time?

Answer 1

VOIP app behavior at background (iOS 4.0+):

Having a single socket that remains open, flagged as Voip

This VOIP socket is maintained by the system, while app suspended at BG

You may schedule a keep-alive block, and the OS will wake your app every X time

X >= 10min (See [[UIApplication sharedApplication] setKeepAliveTimeout: handler:)

this socket is NOT the media socket, it uses only to receive invitations for incoming calls

App wake up on every incoming data on the socket (iOS 5.0+ limit is 15 times in 300 seconds)

Once you've received an incoming call, your app will wake up, and you may open an Audio Session for this call.

VOIP apps should be flagged at info.plist, under "Required background modes", as "voip" & "audio".

Once you've opened an Audio Session (For active call), your app may run fully at the background and it is no longer suspended, until this Audio Session is closed.

Anyway, the other alternative, is to use Push notifications as triggers for incoming calls.
Also, this will save you the trouble of maintaining a socket 24/7, save some battery,
and will work even if the user has closed the app (which is not the case with the first alternative).