Hello, I'm using pjsip on iOS. I'm trying to find a way to keep my iOS app from going to sleep when put in the background, so that incoming UDP SIP calls can get received. So far, I found many clues that this is possible and in fact seems to be implemented by apps in the AppStore. The trick seems to be to use the 10 seconds granted by iOS upon incoming data received through the VOIP TCP socket: when the app is woken up by such a signal, let it wait for about 9 seconds, send a response to the server, and go to sleep, only to be awoken immediately by the server's response coming in through the socket; then again wait for 9 seconds etc. (the most elaborate description I found is here: http://stackoverflow.com/a/7393083) Now my question is: how can I provoke a TCP response from a UDP-only SIP server? What signal could I send to a SIP server, if the server only supports SIP over UDP? I know this is not strictly a pjsip question, but I think people on this list do have the largest knowledge in this field... Thanks! Martin

Hi Martin, | ... The trick seems to be to | use the 10 seconds granted by iOS upon incoming data received | through the VOIP TCP socket: when the app is woken up by such a | signal, let it wait for about 9 seconds, send a response to the | server, and go to sleep, only to be awoken immediately by the | server's response coming in through the socket; then again wait for | 9 seconds etc. (the most elaborate description I found is here: | http://stackoverflow.com/a/7393083) Do you know about "SBUnsuspendLimit"? iOS 5 or later will kill your app if it is woken up more then 15 times in 300 seconds. So I would stick to TCP on iOS. ;) Sebastian.

Hi Sebastian, thanks a lot for your answer. I didn't know about that "15 wakes per 300 seconds" limitation. Doing the math … not good when I only got 10 secs per wake! Do you know at which iOS version this was introduced? I'd still like to understand how an app can be kept constantly awake using the voip background mode. So if anyone can help me with this, I'd appreciate it. Sticking to TCP would naturally be preferable, but as it seems, most SIP servers don't support TCP. Is there a common solution to this, e.g. using an external SIP proxy to "translate" SIP from UDP to TCP? Regards, Martin On Jun 1, 2012, at 11:42 , s.marek@avm.de wrote: > Hi Martin, > > | ... The trick seems to be to > | use the 10 seconds granted by iOS upon incoming data received > | through the VOIP TCP socket: when the app is woken up by such a > | signal, let it wait for about 9 seconds, send a response to the > | server, and go to sleep, only to be awoken immediately by the > | server's response coming in through the socket; then again wait for > | 9 seconds etc. (the most elaborate description I found is here: > | http://stackoverflow.com/a/7393083) > > Do you know about "SBUnsuspendLimit"? > > iOS 5 or later will kill your app if it is woken up more then 15 times in > 300 seconds. > > So I would stick to TCP on iOS. ;) > > Sebastian. > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

Hi, the only working solution I know (and have seen working) is to use a TCP proxy server. Audio packets still use UDP, which is no problem if you take the call after the user brought the app to foreground (e.g. using a local notification). I'd recommend to use the TCP proxy for all control packets, and not to try to switch between UDP and TCP based on foreground or background. I don't think it's worth the hassle... Florian On 6/1/2012 11:59, Martin Umgeher wrote: > Hi Sebastian, > > thanks a lot for your answer. I didn't know about that "15 wakes per 300 seconds" limitation. Doing the math … not good when I only got 10 secs per wake! Do you know at which iOS version this was introduced? I'd still like to understand how an app can be kept constantly awake using the voip background mode. So if anyone can help me with this, I'd appreciate it. > > Sticking to TCP would naturally be preferable, but as it seems, most SIP servers don't support TCP. Is there a common solution to this, e.g. using an external SIP proxy to "translate" SIP from UDP to TCP? > > Regards, > Martin > > > On Jun 1, 2012, at 11:42 , s.marek@avm.de wrote: > >> Hi Martin, >> >> | ... The trick seems to be to >> | use the 10 seconds granted by iOS upon incoming data received >> | through the VOIP TCP socket: when the app is woken up by such a >> | signal, let it wait for about 9 seconds, send a response to the >> | server, and go to sleep, only to be awoken immediately by the >> | server's response coming in through the socket; then again wait for >> | 9 seconds etc. (the most elaborate description I found is here: >> | http://stackoverflow.com/a/7393083) >> >> Do you know about "SBUnsuspendLimit"? >> >> iOS 5 or later will kill your app if it is woken up more then 15 times in >> 300 seconds. >> >> So I would stick to TCP on iOS. ;) >> >> Sebastian. >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

Hi Florian, yes, that's how I imagined this problem could be solved. Thanks for the clarification. Any hints which SIP service providers can/should be used for this? I don't want to turn this mailing list into an advertising platform ;) but I don't have any experience with such providers. And I don't need most of the common features (e.g. no new account). Just need to register my own existing account at the provider and redirect INVITEs. Thanks! Martin On Jun 1, 2012, at 14:03 , Florian wrote: > Hi, > > the only working solution I know (and have seen working) is to use a > TCP proxy server. Audio packets still use UDP, which is no problem if > you take the call after the user brought the app to foreground (e.g. > using a local notification). > > I'd recommend to use the TCP proxy for all control packets, and not to > try to switch between UDP and TCP based on foreground or background. I > don't think it's worth the hassle... > > Florian > > > On 6/1/2012 11:59, Martin Umgeher wrote: >> Hi Sebastian, >> >> thanks a lot for your answer. I didn't know about that "15 wakes per 300 seconds" limitation. Doing the math … not good when I only got 10 secs per wake! Do you know at which iOS version this was introduced? I'd still like to understand how an app can be kept constantly awake using the voip background mode. So if anyone can help me with this, I'd appreciate it. >> >> Sticking to TCP would naturally be preferable, but as it seems, most SIP servers don't support TCP. Is there a common solution to this, e.g. using an external SIP proxy to "translate" SIP from UDP to TCP? >> >> Regards, >> Martin >> >> >> On Jun 1, 2012, at 11:42 , s.marek@avm.de wrote: >> >>> Hi Martin, >>> >>> | ... The trick seems to be to >>> | use the 10 seconds granted by iOS upon incoming data received >>> | through the VOIP TCP socket: when the app is woken up by such a >>> | signal, let it wait for about 9 seconds, send a response to the >>> | server, and go to sleep, only to be awoken immediately by the >>> | server's response coming in through the socket; then again wait for >>> | 9 seconds etc. (the most elaborate description I found is here: >>> | http://stackoverflow.com/a/7393083) >>> >>> Do you know about "SBUnsuspendLimit"? >>> >>> iOS 5 or later will kill your app if it is woken up more then 15 times in >>> 300 seconds. >>> >>> So I would stick to TCP on iOS. ;) >>> >>> Sebastian. >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip@lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -- DI Dr. Martin Umgeher Research & Development m.umgeher@easymobiz.com +43 316 346800-15 easyMOBIZ mobile IT solutions GmbH Ruckerlberggasse 13, 8010 Graz, Austria Managing Director: Rudolf Schamberger Commercial Register: 321800 k http://easyMOBIZ.com http://ayControl.com ayControl auf der International Lighting Exhibition in Guangzhou China, 9.-12. Juni 2012 Wir freuen uns auf Ihren Besuch in der Halle 6.1 am Stand E18 - direkt bei der KNX Association! ayControl at the International Lighting Exhibition in Guangzhou China, 09-Jun-12 to 12-Jun-12 We are looking forward to meeting you on our booth E18, hall 6.1 - directly on the KNX Association booth!

Hi Martin, I've only seen a proprietary TCP proxy (on own servers), not a public service (although, would be an interesting offering). Any public service would just offer SIP via TCP directly, I guess. Florian On 6/4/2012 11:13, Martin Umgeher wrote: > Hi Florian, > > yes, that's how I imagined this problem could be solved. Thanks for the clarification. > > Any hints which SIP service providers can/should be used for this? I don't want to turn this mailing list into an advertising platform ;) but I don't have any experience with such providers. And I don't need most of the common features (e.g. no new account). Just need to register my own existing account at the provider and redirect INVITEs. > > Thanks! > Martin > > > On Jun 1, 2012, at 14:03 , Florian wrote: > >> Hi, >> >> the only working solution I know (and have seen working) is to use a >> TCP proxy server. Audio packets still use UDP, which is no problem if >> you take the call after the user brought the app to foreground (e.g. >> using a local notification). >> >> I'd recommend to use the TCP proxy for all control packets, and not to >> try to switch between UDP and TCP based on foreground or background. I >> don't think it's worth the hassle... >> >> Florian >> >> >> On 6/1/2012 11:59, Martin Umgeher wrote: >>> Hi Sebastian, >>> >>> thanks a lot for your answer. I didn't know about that "15 wakes per 300 seconds" limitation. Doing the math … not good when I only got 10 secs per wake! Do you know at which iOS version this was introduced? I'd still like to understand how an app can be kept constantly awake using the voip background mode. So if anyone can help me with this, I'd appreciate it. >>> >>> Sticking to TCP would naturally be preferable, but as it seems, most SIP servers don't support TCP. Is there a common solution to this, e.g. using an external SIP proxy to "translate" SIP from UDP to TCP? >>> >>> Regards, >>> Martin >>> >>> >>> On Jun 1, 2012, at 11:42 , s.marek@avm.de wrote: >>> >>>> Hi Martin, >>>> >>>> | ... The trick seems to be to >>>> | use the 10 seconds granted by iOS upon incoming data received >>>> | through the VOIP TCP socket: when the app is woken up by such a >>>> | signal, let it wait for about 9 seconds, send a response to the >>>> | server, and go to sleep, only to be awoken immediately by the >>>> | server's response coming in through the socket; then again wait for >>>> | 9 seconds etc. (the most elaborate description I found is here: >>>> | http://stackoverflow.com/a/7393083) >>>> >>>> Do you know about "SBUnsuspendLimit"? >>>> >>>> iOS 5 or later will kill your app if it is woken up more then 15 times in >>>> 300 seconds. >>>> >>>> So I would stick to TCP on iOS. ;) >>>> >>>> Sebastian. >>>> >>>> _______________________________________________ >>>> Visit our blog: http://blog.pjsip.org >>>> >>>> pjsip mailing list >>>> pjsip@lists.pjsip.org >>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip@lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >