idoubs crashes on startup when it running at background

[GoogleCodeExporter]

a) Before posting your issue you MUST answer to the questions otherwise it
will be rejected (invalid status) by us
b) Please check the issue tacker to avoid duplication
c) Please provide network capture (wireshark) or Android log (DDMS output)
if you want quick response

What steps will reproduce the problem?
1. waking up the device
2. launch idoubs
3. press home to send idoubs into the backgound
4. loading a new app
5. switch the device into sleep mode
6. after a while, waking up the device again
7. launch idoubs, then you'll see idoubs crashes

What is the expected output? What do you see instead?

Exited abnormally: Broken pipe
Tue Dec 20 17:32:45 unknown SpringBoard[33] <Warning>: Application 'idoubs' 
exited abnormally with signal 13: Broken pipe

***ERROR: function: "tnet_transport_sendto()"
doubango/branches/2.0/doubango/tinyNET/src/tnet_transport_poll.c
MSG: (SYSTEM)NETWORK ERROR ==>Broken pipe

What version of the product or source code revision are you using? On what
operating system?

Verizon iOS 4.2.7

Original issue reported on code.google.com by Vise...@gmail.com on 20 Dec 2011 at 4:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Keep both 3G and WIFI on, and make sure you have an available wireless network.

Original comment by Vise...@gmail.com on 21 Dec 2011 at 1:17

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 19 Jan 2012 at 3:54

• Changed state: Accepted
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Confirmed this behavior today on iPod 4Gs running 5.0.1 / 4.3.5. Expressed in 
the device logs as "Broken pipe"

I have been working with these devices for my job, and suspect this is related 
to what Apple appears to confirm is "... a known problem with the current VoIP 
design." that impacts devices on WiFi that do not have access to 3G. In certain 
power saving modes, the radio turns off, causing dropped VoIP application 
sockets in the background.

Specifically, this behavior is never expressed when the device is attached to a 
power source. Additionally, low battery levels exacerbate wifi disconnection, 
dropping VoIP connections.

Original comment by acpeloq...@gmail.com on 7 Feb 2012 at 5:46

[GoogleCodeExporter]

Wanted to share what I've done as a workaround for this issue:

http://stackoverflow.com/questions/108183/how-to-prevent-sigpipes-or-handle-them
-properly
Based on this thread, I have elected to flag the SIP socket with NOSIGPIPE to 
avoid a crash.
This was a single-file change in ios-ngn-stack -- 
Doubango/tinyNET/src/tnet_socket.c
Line 266 is the way Mamadou handles socket flags, so I copied lines 266 to 276 
and pasted a new block in:

        /* To prevent SIGPIPEs? */
        {
#if defined(SOLARIS)
            char yes = '1';
#else
            int yes = 1;
#endif
            if(setsockopt(sock->fd, SOL_SOCKET, SO_NOSIGPIPE, (char*)&yes, sizeof(int))){
                TNET_PRINT_LAST_ERROR("setsockopt(SO_NOSIGPIPE) have failed.");
            }
        }

This still throws a network error but doesn't crash the App, however I'm not 
familiar enough with C to figure out a way to expose whether or not the pipe is 
broken up to the Objective-C code. 

The registrationState still shows connected once the pipe is broken, so I'm 
having to restart the whole thing to get my connection fixed.
For my application, VoIP is a secondary feature, so I stop and restart the 
service upon device wake as well as the keepalive handler. This means the 
connection can get lost in the background (the known iOS issue I mentioned in 
comment 4), and we make the best effort to keep it alive.

Original comment by acpeloq...@gmail.com on 8 Feb 2012 at 5:47

[GoogleCodeExporter]

https://trac.pjsip.org/repos/ticket/1225

Looks like PJSIP overcame this iOS problem already. 
My workaround doesn't yet fix the actual broken pipe (trying to do so now).

Original comment by acpeloq...@gmail.com on 8 Feb 2012 at 8:21

[GoogleCodeExporter]

@acpelog...@gmail.com:
It seems that PJSIP fixed the problem! Only my problem is that I've so few 
experience with C that I can't translate it and build it into the ios-ngn-stack 
project.

See this link for the solution that worked for PJSIP:
https://trac.pjsip.org/repos/changeset/3491

Original comment by nightfox...@gmail.com on 28 May 2012 at 7:06

[GoogleCodeExporter]

Two solutions:
1) Use TCP
or
2) Use UDP with KeppAwake option enabled

Original comment by boss...@yahoo.fr on 3 Sep 2012 at 5:43

[GoogleCodeExporter]

I have tried both these options:

1) I am using TCP. This is not the root of the problem though... the background 
listener socket Apple offers can get disconnected, sometimes by the OS itself.
2) iOS does not offer UDP socket keepalive! 
(http://stackoverflow.com/questions/6502561/problems-receiving-udp-data-while-in
-background?rq=1)

To clarify my issue: when in the background, Apple's background socket is 
sometimes broken (roaming between access points, wifi throttling, off network, 
etc), I can suppress the SIG_PIPE with the appropriate flag, however I do not 
have the knowledge of your library implementation to expose the error state of 
the socket to my Objective-C code.

If that were doable (read: If I could detect if your socket was in error), I 
would tear down and reconnect the VoIP socket, which could theoretically reduce 
my window of lost connection to within the bounds of Apple's keep-alive handler 
(up to 10 minutes) without crashing.
As it stands today, I can suppress the crash but [[NgnEngine 
sharedInstance].sipService getRegistrationState] still returns 
CONN_STATE_CONNECTED.

My workaround would not be perfect, and this change in iOS 5 did break VoIP 
functionality for lots of background apps, not just idoubs/doubango 
specifically.

Thanks for your help!

Original comment by acpeloq...@gmail.com on 5 Sep 2012 at 1:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Have you even found a way to deal with this? 

I have a SIP application using the same framework and I am forced to use 
keepalive (with the music play) in order to keep the whole application running 
and handle network connection changes.. 
It seams that I cannot find a proper way to get notified by the tear down and 
re-register. 
I would use TCP instead because I find it a more ergonomic way of handling 
background running.

Original comment by andrei.n...@hypersense-software.com on 8 Feb 2013 at 1:52

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 16 May 2014 at 1:58

• Changed state: Fixed