bridge.c: Crash during attended transfer when missing a local channel half
authorKevin Harwell <kharwell@digium.com>
Tue, 1 Mar 2016 22:18:21 +0000 (16:18 -0600)
committerKevin Harwell <kharwell@digium.com>
Thu, 3 Mar 2016 20:03:14 +0000 (14:03 -0600)
commit15c5743ac1371535441e2111499d848dd9c5ff52
tree2118adf804cd135ff9074f1d98df5a81f77adf34
parent7023055def57fe63bb169c481c801c72599d3fdb
bridge.c: Crash during attended transfer when missing a local channel half

It's possible for the transferer channel to get hung up early during the
attended transfer process. For instance, a phone may send a "bye" immediately
upon receiving a sip notify that contains a sip frag 100 (I'm looking at you
Jitsi). When this occurs a race begins between the transferer being hung up
and completion of the transfer code.

If the channel hangs up too early during a transfer involving stasis bridging
for instance, then when the created local channel goes to look up its swap
channel (and associated datastore) it can't find it (since it is no longer in
the bridge) thus it fails to enter the stasis application. Consequently, the
created local channel(s) hang up as well. If the timing is just right then the
bridging code attempts to add the message link with missing local channel(s).
Hence the crash.

Unfortunately, there is no great way to solve the problem of the unexpected
"bye". While we can't guarantee we won't receive an early hangup, and in this
case still fail to enter the stasis application, we can make it so asterisk
does not crash.

This patch does just that by locking the local channel structure, checking
that the local channel's peer has not been lost, and then continuing. This
keeps the local channel's peer from being ripped out from underneath it by
the local/unreal hangup code while attempting to set the stasis message link.

ASTERISK-25771

Change-Id: Ie6d6061e34c7c95f07116fffac9a09e5d225c880
include/asterisk/core_local.h
main/bridge.c
main/core_local.c