chan_pjsip: transfers with direct media reinvite has wrong address/port
authorKevin Harwell <kharwell@digium.com>
Wed, 16 Mar 2016 17:37:01 +0000 (12:37 -0500)
committerKevin Harwell <kharwell@digium.com>
Fri, 18 Mar 2016 16:15:56 +0000 (11:15 -0500)
commitc534bd58075e2e1a1e4f3b23c435186c71b155fd
tree4a2a9f03659c96b865760b88487ac8fb2ea25ac9
parent7ea1e181dc7c3540c9af0c3bd6d0915260c570d8
chan_pjsip: transfers with direct media reinvite has wrong address/port

During a transfer involving direct media a race occurs between when the
transferer channel is swapped out, initiating rtp changes/updates, and the
subsequent reinvites.

When Alice, after speaking with Charlie (Bob is on hold), connects Bob and
Charlie invites are sent to each in order to establish the call between them.
Bob is taken off hold and Charlie is told to have his media flow through
Asterisk. However, if before those invites go out the bridge updates Bob's
and/or Charlie's rtp information with direct media data (i.e. address, port)
then the invite(s) will contain the remote data in the SDP instead of the
Asterisk data.

The race occurs in the native bridge glue code when updating the peer. The
direct_media_address can get set twice before sending out the first invite
during call connection. This can happen because the checking/setting of the
direct_media_address happened in one thread while the sending of the invite(s)
happened in another thread.

This fix removes the race condition by moving the checking/setting of the
direct_media_address to be in the same thread as the sending of the invites(s).
This serializes the checking/setting and sending so they can no longer happen
out of order.

ASTERISK-25849 #close

Change-Id: Idfea590175e74f401929a601dba0c91ca1a7f873
channels/chan_pjsip.c