summaryrefslogtreecommitdiff
path: root/doc/asterisk-ng-doxygen.in
diff options
context:
space:
mode:
authorKevin Harwell <kharwell@digium.com>2016-03-16 12:37:01 -0500
committerKevin Harwell <kharwell@digium.com>2016-03-18 11:16:32 -0500
commit9444ddadf8525d1ce66a1faf1db97f9f6c265ca4 (patch)
tree729f71a888e760fedc0e377fa30bc29686ddb450 /doc/asterisk-ng-doxygen.in
parent65ad76113033f7b18ae36a98e731c67fdade0d63 (diff)
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
Diffstat (limited to 'doc/asterisk-ng-doxygen.in')
0 files changed, 0 insertions, 0 deletions