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 at 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 at lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -- DI Dr. Martin Umgeher Research & Development m.umgeher at 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!
