Commit Graph

4 Commits

Author SHA1 Message Date
Kevin Harwell
1f9913f272 core_local: local channel data not being properly unref'ed and unlocked
In an earlier version of Asterisk a local channel [un]lock all functions were
added in order to keep a crash from occurring when a channel hung up too early
during an attended transfer. Unfortunately, when a transfer failure occurs and
depending on the timing, the local channels sometime do not get properly
unlocked and deref'ed after being locked and ref'ed. This happens because the
underlying local channel structure gets NULLed out before unlocking.

This patch reworks those [un]lock functions and makes sure the values that get
locked and ref'ed later get unlocked and deref'ed.

ASTERISK-27074 #close

Change-Id: Ice96653e29bd9d6674ed5f95feb6b448ab148b09
2017-06-21 16:17:02 -05:00
Kevin Harwell
40d9e9e238 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
2016-03-03 13:55:24 -06:00
Matthew Jordan
30d379851e Create Local channel messages on the Stasis message bus and produce AMI events
This patch does the following:

* It adds a virtual table of callbacks to core_unreal. These callbacks can be
  supplied by concrete implementations of "unreal" channel drivers, which lets
  the unreal channel driver call specific functionality when it performs some
  action. Currently, this is done to notify implementations when an
  optimization operation has begun, and when an optimization operation has
  succeeded.

* It adds Stasis-Core messages for Local channel bridging and Local channel
  optimization. Local channel optimization is now two events: a Begin and an
  End. Some consumers of Stasis-Core may want to know when an operation is
  beginning so that they can 'prepare' their information; others will be more
  concerned about when the operation has completed, so that they can 'fix up'
  information. Stasis-Core allows for both, as does AMI.

Review: https://reviewboard.asterisk.org/r/2552



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-08 14:26:40 +00:00
Richard Mudgett
3d63833bd6 Merge in the bridge_construction branch to make the system use the Bridging API.
Breaks many things until they can be reworked.  A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-21 18:00:22 +00:00