Thanks Andrea,
Effectively when I add the new condition in on_rx_rtp and on_rx_rtcp,
application doesn't stay lock (no deadlock),
and I get SIGPIPE.
I tried to set option SO_NOSIGPIPE in pjmedia_transport_udp_create3, but
it's not enough because UDP is used in several part.
Also I decided to set option SO_NOSIGPIPE on all UDP socket, for that I
added in pj_sock_socket
pj_int32_t val = 1;
if (type == pj_SOCK_DGRAM())
pj_sock_setsockopt(*sock, pj_SOL_SOCKET(), SO_NOSIGPIPE, &val,
sizeof(val));
With this (global) solution, I can answer incoming call but there is no
sound.
I think it's logic because UDP sockets have been closed, and they are
not re-opened.
Finally, it seems, it would be useful to close all UDP sockets when app
goes in bg, and to reopen the sockets the app is back in foreground.
I tried to close media transport in 'ApplicationDidEnterBackground' and
create media transport in 'applicationWillEnterForeground'.
Unfortunately, it doesn't work because pjsip needs enabled media
transport when there is an incoming call.
Benny,
Is it possible to reopen UDP socket when pj_ioqueue_recvfrom/recvfrom...
returns PJ_STATUS_FROM_OS(ENOTCONN) ?
If yes, where is the best place ?
Regards
Samuel
Le 09/08/10 14:42, Andrea Campi a ?crit :
> 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
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100810/eb34a4d1/attachment.html>
