res_rtp_asterisk.c: Fix TURN deadlock by using ICE session group lock.
authorRichard Mudgett <rmudgett@digium.com>
Wed, 5 Jul 2017 18:39:45 +0000 (13:39 -0500)
committerRichard Mudgett <rmudgett@digium.com>
Thu, 6 Jul 2017 21:14:48 +0000 (16:14 -0500)
commit9cd8a1df792c26cc4e82263a950f877d4c255100
treeb80725b383974d72011314070f296fb82ce605f6
parent7a4f577eb76d0f17894979f4c83924183e5d056c
res_rtp_asterisk.c: Fix TURN deadlock by using ICE session group lock.

When a message is received on the TURN socket, the code processing the
message needs to call into the ICE/STUN session for further processing.
This code path locks the TURN group lock then the ICE/STUN group lock.  In
another thread an ICE/STUN timer can fire off to send a keep alive message
over the TURN socket.  In this code path, the ICE/STUN group lock is
obtained then the TURN group lock is obtained to send the packet.  A
classic deadlock case if the group locks are not the same.

* Made TURN get created using the ICE/STUN session's group lock.

NOTE: I was originally concerned that the ICE/STUN session can get
recreated by ice_reset_session() for an event like RTCP multiplexing
causing a change during SDP negotiation.  In this case the TURN group lock
would become different.  However, TURN is also recreated as part of the
ICE/STUN recreation in ice_create() when all known ICE candidates are
added to the new ICE session.  While the ICE/STUN and TURN sessions are
being recreated there is a period where the group locks could be
different.

ASTERISK-27023 #close
Patches:
    res_rtp_asterisk-turn-deadlock-fix.patch (license #6502)
        patch uploaded by Michael Walton (modified)

Change-Id: Ic870edb99ce4988a8c8eb6e678ca7f19da1432b9
res/res_rtp_asterisk.c