Samuel,
Samuel Vinson wrote:
> Hi Darald,
>
> I tried your solution and mine, they work in all cases except one.
> My app runs in background and the iphone is locked. When pjsip receive
> an incoming call, one LocalNotification is sent from on_incoming_call
> callback.
> If the user anwsers, the application:didReceiveLocalNotification: is
> called by iOS. In this function, I call pjsua_call_answer(cid, 200,
> null,null), but the function stays locked in pj_mutex_lock
>
> Calls stack :
> pjsua_call_answer -> pjsip_inv_answer -> process_answer ->
> inv_negotiate_sdp -> pjsua_call_on_media_update ->
> pjsua_media_channel_update -> pjmedia_session_create ->
> pjmedia_stream_create -> pjmedia_transport_attach -> transport_attach
> -> pj_ioqueue_lock_key(rtp_key) ->pj_mutex_lock (-> pthread_mutex_lock
> ->semaphoe_wait_signal -> semaphore_wait_signal_trap)
>
> I use the last version og svn trunk.
>
> Had you got the same issue ?
> How did you resolve it ?
this is almost exactly the same as an issue I've been working on.
Thread 1:
#3 0x00173c62 in pj_mutex_lock at os_core_unix.c:1193
#4 0x0017168e in pj_ioqueue_lock_key at ioqueue_common_abs.c:1289
#5 0x001a4c46 in transport_attach at transport_udp.c:657
#6 0x001a252e in pjmedia_transport_attach at transport.h:593
#7 0x001a24ae in transport_attach at transport_srtp.c:681
#8 0x0019e4ca in pjmedia_transport_attach at transport.h:593
#9 0x0019e3c2 in pjmedia_stream_create at stream.c:2011
#10 0x0019a10a in pjmedia_session_create at session.c:663
#11 0x00202886 in pjsua_media_channel_update at pjsua_media.c:2258
#12 0x001f9fec in pjsua_call_on_media_update at pjsua_call.c:3320
#13 0x001c75b6 in inv_negotiate_sdp at sip_inv.c:1502
#14 0x001c7b7c in process_answer at sip_inv.c:1767
#15 0x001c7ed4 in pjsip_inv_answer at sip_inv.c:1907
#16 0x001f93fa in pjsua_call_answer at pjsua_call.c:1393
Thread 5 owns the mutex:
#1 0x00175e98 in pj_sock_recvfrom at sock_bsd.c:679
#2 0x00170e18 in pj_ioqueue_recvfrom at ioqueue_common_abs.c:767
#3 0x001a489c in on_rx_rtp at transport_udp.c:541
#4 0x00170a6a in ioqueue_dispatch_read_event at ioqueue_common_abs.c:558
#5 0x00172376 in pj_ioqueue_poll at ioqueue_select.c:768
#6 0x0018d630 in worker_proc at endpoint.c:264
#7 0x00173090 in thread_main at os_core_unix.c:473
on_rx_rtp (and on_rx_rtcp, I've seen in happen there too) are called by
ioqueue_dispatch_read_event with the pj_ioqueue_key_t mutex held.
They both run a do { } while loop that doesn't check for errors:
do {
...
} while (status != PJ_EPENDING && status != PJ_ECANCELLED);
Apparently, the iPhone returns ENOTCONN when reading from a UDP socket;
as you mention, that seems to only happen when the application is in
background *and* the screen is locked (and no, this is not documented
anywhere that I know of).
Once that happens the thread keeps looping there.
Simply changing that to:
} while (status != PJ_EPENDING && status != PJ_ECANCELLED && status
!= PJ_STATUS_FROM_OS(ENOTCONN));
keeps the application from freezing. That would of course need to be
cleaned up and possibly made more portable; I can imagine other OSes can
fail in other ways.
The next step would be to cleanly close and reopen the RTP socket.
Actually, I'm thinking we should shut down the UDP socket when moving to
the background and only reopen it when needed for a new call. Not sure
how easy that would be.
For the record, I'm seeing a related issue: once you survive that
livelock, you'll probably get a SIGPIPE when writing on the RTP socket :)
I solved that by adding in pjmedia_transport_udp_create3 a couple of:
val = 1;
status = pj_sock_setsockopt(si.rtp_sock, pj_SOL_SOCKET(),
SO_NOSIGPIPE,
&val, sizeof(val));
if (status != PJ_SUCCESS)
goto on_error;
That's again unportable and would need to be cleaned up, but I can
confirm with these two fixes I can reliably answer a call from
background + lock.
I can gladly provide a diff with both, but I would appreciate guidance
on how to get it in shape for submission.
Bye,
Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100809/44e55e73/attachment.html>
