Custom Query (2195 matches)

UDP sockets are reset by iOS when the app goes into background mode. PJLIB handles this by detecting the error when receive event is set and recreating the sockets accordingly. This feature was added by ticket #1107.

Unfortunately sometimes it's the sending operation that comes first after the app is woken up, and since the UDP socket is in a bad state, this will cause the sending operation to fail. This will cause errors similar to these:

17:35:40.120 stuntsx0x9de55  STUN error sending message: Broken pipe
17:35:40.120 stuntp0x33b920  Error sending STUN request: Broken pipe
17:35:40.121 stuntp0x33b920  Session failed because STUN Binding request failed: Broken pipe
17:35:40.121        icetp00  STUN binding request failed: Broken pipe
17:35:40.121 stuntsx0xa17b5  STUN error sending message: Broken pipe
17:35:40.122 stuntp0x33af00  Error sending STUN request: Broken pipe
17:35:40.122 stuntp0x33af00  Session failed because STUN Binding request failed: Broken pipe

This ticket will fix the sending error by recreating the UDP sockets if the sending operation fails after waking up from background mode.

As has been reported in ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2011-November/013692.html, iOS 5 will kill an application if it wakes up more than 15 times in 300 seconds. Below is a typical stack trace for the "crash" event:

Exception Type:  00000020
Exception Codes: 0xbad22222
Highlighted Thread:  1

Application Specific Information:
SBUnsuspendLimit myapp[346] exceeded 15 wakes in 300 sec

There are several other discussions on the Apple's developer forum:

• ​https://devforums.apple.com/message/574557
• ​https://devforums.apple.com/message/566555
• ​https://devforums.apple.com/message/565667

This ticket provides several tips that may help avoiding the situation.

1. Use a background task to ensure that the app doesn't suspend immediately after being waken up. App most likely will need to send something when it is waken up, for example some requests or TCP keep-alive data. Chances are these data will be responded by the server. If the app immediately gets suspended after sending them, it will be waken up again when the response arrives, hence adding to the wake up count. The app should delay as much as iOS allows before it goes to suspended state again, to take care the fact that some requests do take a while to complete, for example due to authentication.

2. Fixing spurious wakeups problem. It has been reported that iOS may wake up the application every 10 seconds even when there is no activity in the network. This has been correlated to TCP transport disconnection, i.e. once the TCP transport is disconnected the app starts to get waken up every 10 seconds even when Wireshark shows no activity at all. This issue seemed to have been fixed by #1465 and #1481, which now immediately close (or to close sooner) the TCP socket when it gets disconnected. If the app also holds a reference to the TCP transport, it should also release this reference once it gets the TCP disconnection notification (on the on_transport_state() callback), because the transport will only be destroyed once it's reference goes to zero.

Call to AudioConverterNew() for the iLBC codec may take long time to complete, causing timeout in acquiring pjsua lock (when doing get call info on incoming call).

This happens on iPhone 3GS with iOS 4.0.2 and SDK 4.0.