Crash on disconnecting call with SRTP + ICE (thanks Bogdan Krakowski for the report)

[nanang]

Reported that this occurred on "slow CPU" (iPhone 3G) in "heavy CPU load" and barely reproducible.

The stack when crashing:

0   0x0018bdb4 auth_get_tag_length (auth.c:64)
1   0x001898dc srtp_unprotect (srtp.c:885)
2   0x00135310 srtp_rtp_cb (transport_srtp.c:864)
3   0x0011ce70 ice_on_rx_data (transport_ice.c:1641)
4   0x0014907c stun_on_rx_data (ice_strans.c:1395)
5   0x001404ac on_data_recvfrom (stun_sock.c:815)
6   0x000f08a0 ioqueue_on_read_complete (activesock.c:573)
7   0x000fb4bc ioqueue_dispatch_read_event (ioqueue_common_abs.c:560)
8   0x000fbb7c pj_ioqueue_poll

After investigation, a possible scenario is:

1. the call is disconnecting, so media deinitialization steps are on progress
2. an RTP packet is coming and ice_on_rx_data() is about to call SRTP callback rtp_cb in media worker thread
3. context switch happens, now pjsua_media_channel_deinit() is executed (at least until pjmedia_transport_media_stop()) in signaling worker thread
4. when the context back to media worker thread, SRTP callback is called after SRTP backend states (or even the SRTP instance itself) have been destroyed

[nanang]

(In [3348]) Re #1140, cleaned up the mutex usages in SRTP transport:

• using mutex in accessing application callback pointers
• releasing mutex before calling application callbacks to avoid deadlock
• refine the synchronization of backend/libsrtp states

[bennylp]

This would not protect all race condition situations, as there's still one possible scenario where SRTP is being destroyed while a callback is still executing. But nevertheless the fix above should help a bit. Closing the ticket..