bridge_native_rtp.c: Don't start native RTP bridging after attended transfer.
authorJoshua Colp <jcolp@digium.com>
Thu, 9 Jul 2015 14:18:11 +0000 (11:18 -0300)
committerJoshua Colp <jcolp@digium.com>
Thu, 9 Jul 2015 17:21:49 +0000 (12:21 -0500)
commit4a25d55416c736431620ce357f2bd9e241d62372
tree0b2ed220393b8f61887d9655444ad3d3852cca0e
parentaf3f4b342b1633c51e747d002335aed4ee78b26e
bridge_native_rtp.c: Don't start native RTP bridging after attended transfer.

The bridge_native_rtp module adds a frame hook to channels which are in
a native RTP bridge. This frame hook is used to intercept when a hold
or unhold frame traverses the bridge so native RTP can be stopped or
started as appropriate. This is expected but exposes a specific bug
when attended transfers are involved.

Upon completion of an attended transfer an unhold frame is queued up
to take one of the channels involved off hold. After this is done
the channel is moved between bridges.

When the frame hook is involved in this case for the unhold it
releases the channel lock and acquires the bridge lock. This
allows the bridge core to step in and move the channel
(potentially changing the bridging techology) from another thread.
Once completed the bridge lock is released by the bridge core.
The frame hook is then able to acquire the bridge lock and
wrongfully starts native RTP again, despite the channel no longer
being in the bridge or needing to start native RTP. In fact at
this point the frame hook is no longer attached to the channel.

This change makes it so the native RTP bridge data is available to
the frame hook when it is invoked. Whether the frame hook has
been detached or not is stored on the native RTP bridge data and
is checked by the frame hook before starting or stopping native
RTP bridging. If the frame hook has been detached it does nothing.

ASTERISK-25240 #close

Change-Id: I13a73186a05f4e5a764f81e5cd0ccec1ed1891d2
bridges/bridge_native_rtp.c