A deadlock can happen when a sorcery object is being expired from the
memory cache when at the same time another object is being placed into the
memory cache.  There are a couple other variations on this theme that
could cause the deadlock.  Basically if an object is being expired from
the sorcery memory cache at the same time as another thread tries to
update the next object expiration timer the deadlock can happen.

* Add a deadlock avoidance loop in expire_objects_from_cache() to check if
someone is trying to remove the scheduler callback from the scheduler.

ASTERISK-25441 #close

Change-Id: Iec7b0bdb81a72b39477727b1535b2539ad0cf4dc

Make sorcery_memory_cache_close() call remove_all_from_cache() instead of
partially inlining it.

ASTERISK-25441

Change-Id: I1aa6cb425b1a4307096f3f914d17af8ec179a74c

Basically you should shutdown in the opposite order of how you setup since
later setup pieces likely depend on earlier setup pieces.  e.g.,
Registering your external API with the rest of the system should be the
last thing setup and the first thing unregistered during shutdown.

Change-Id: I5715765b723100c8d3c2642e9e72cc7ad5ad115e

Change-Id: I8cd32dffbb4f33bb0c39518d6e4c991e73573160

Change-Id: Ibca6574dc3c213b29cc93486e01ccd51f5caa46c

In practice the set_role API callback can be invoked even
when no ICE is present on an RTP instance. This can occur
if ICE has not been enabled on it.

ASTERISK-25438 #close

Change-Id: I0e17e4316f0f0d7f095c78c3d4fd73a913b6ba69

Change-Id: Ib91435fb45b7f5f7c0fc83d0eec20b88098707bc

Made use the ao2 sort compare template function and OBJ_SEARCH_xxx
identifiers.

Change-Id: Ic53005dc5aafa7a36c72300dd89b75fb63c92f4c

* Now conf_alloc() has more off nominal error checking.

* Eliminated RAII_VAR() use in conf_alloc().

* Eliminated a dubius shortcut when destroying cfg->general in
conf_destructor() that would cause a crash if cfg->general failed to get
allocated.

* Add some ACO registration section comments.

Change-Id: Ia40c2b1b2d0777d641605118ae019c5a73865e1a

Need to finish initializing the string fields in the ao2 object before
putting any default strings into them.

ASTERISK-25383 #close
Reported by:  yaron nahum

Change-Id: I9f7f3a03f0c4991a01593abf8697b9a587c0ea84

When Asterisk is part of a larger distributed system, log files are often
gathered using tools (such as logstash) that prefer to consume information
and have it rendered using other tools (such as Kibana) that prefer a
structured format, e.g., JSON. This patch adds support for JSON formatted
logs by adding support for an optional log format specifier in Asterisk's
logging subsystem. By adding a format specifier of '[json]':

full => [json]debug,verbose,notice,warning,error

Log messages will be output to the 'full' channel in the following
format:

{
  "hostname": Hostname or name specified in asterisk.conf
  "timestamp": Date/Time
  "identifiers": {
    "lwp": Thread ID,
    "callid": Call Identifier
  }
  "logmsg": {
    "location": {
      "filename": Name of the file that generated the log statement
      "function": Function that generated the log statement
      "line": Line number that called the logging function
    }
    "level": Log level, e.g., DEBUG, VERBOSE, etc.
    "message": Actual text of the log message
  }
}

ASTERISK-25425 #close

Change-Id: I8649bfedf3fb7bf3138008cc11565553209cc238

When b99a7052 was merged, subscribing to a
NULL bridge will now cause app_subscribe_bridge to implicitly subscribe to
all bridges. Unfortunately, the res_stasis control loop did not check that
a bridge changing on a channel's control object was actually also non-NULL.
As a result, app_subscribe_bridge will be called with a NULL bridge when a
channel leaves a bridge. This causes a new subscription to be made to the
bridge. If an application has also subscribed to the bridge, the application
will now have two subscriptions:
(1) The explicit one created by the app
(2) The implicit one accidentally created by the control structure

As a result, the 'BridgeDestroyed' event can be sent multiple times. This
patch corrects the control loop such that it only subscribes an application
to a new bridge if the bridge pointer is non-NULL.

ASTERISK-24870

Change-Id: I3510e55f6bc36517c10597ead857b964463c9f4f

To help in diagnosing mismatched modules and libraries, this
script scans for version, repository, and source information
and reports what is found.

ASTERISK-25376 #close
Reported by: Ashley Sanders

Change-Id: Ib0642d0fb96712476f59760d6d137a24633fe2d6

* When a call is answered and the outgoing channel name has changed then
force a connected line update because the channel is no longer the same.
The channel was masqueraded into by another channel.  This is usually
because of a call pickup.

Note: Forwarded calls are handled in a controlled manner so the original
channel name is replaced with the forwarded channel.

ASTERISK-25423 #close
Reported by: John Hardin

Change-Id: Ie275ea9e99c092ad369db23e0feb08c44498c172

Replace inlined code with update_connected_line_from_peer().

ASTERISK-25423
Reported by: John Hardin

Change-Id: I33bbd033596fcb0208d41d8970369b4e87b806f3

While the 'A' option is playing the announcement file allow the caller and
peer to exchange COLP update frames.

ASTERISK-25423
Reported by: John Hardin

Change-Id: Iac6cf89b56d26452c6bb88e9363622bbf23895f9

* When a call is answered and the outgoing channel name has changed then
force a connected line update because the channel is no longer the same.
The channel was masqueraded into by another channel.  This is usually
because of a call pickup.

Note: Forwarded calls are handled in a controlled manner so the original
channel name is replaced with the forwarded channel.

ASTERISK-25423
Reported by: John Hardin

Change-Id: I2e01f7a698fbbc8c26344a59c2be40c6cd98b00c

Replace inlined code with update_connected_line_from_peer().

ASTERISK-25423
Reported by: John Hardin

Change-Id: Ia14f18def417645cd7fb453e1bdac682630a5091

Change-Id: Ice1884a94315d3cb7e3bbd47a9fba76a27276c54

There was a problem observed where the "logger add channel" CLI command
would allow for a channel with the same name to be added multiple times.
This would result in each message being written out to the same file
multiple times.

The problem was due to the difference in how logger channel filenames
are stored versus the format they are allowed to be presented when they
are added. For instance, if adding the logger channel "foo" through the
CLI, the result would be a logger channel with the file name
/var/log/asterisk/foo being stored. So when trying to add another "foo"
channel, "foo" would not match "/var/log/asterisk/foo" so we'd happily
add the duplicate channel.

The fix presented here is to introduce two new methods in the logger
code:
 * make_filename(): given a logger channel name, this creates the
   filename for that logger channel.
 * find_logchannel(): given a logger channel name, this calls
   make_filename() and then traverses the list of logchannels in order
   to find a match.

This change has made use of make_filename() and find_logchannel()
throughout to more consistently behave.

ASTERISK-25305 #close
Reported by Mark Michelson

Change-Id: I892d52954d6007d8bc453c3cbdd9235dec9c4a36

When leaving a bridge, indications on a channel could be swallowed by
the internal indication logic because it appears that the channel is on
its way to be hung up anyway. One such situation where this is
detrimental is when channels on hold are redirected out of a bridge. The
AST_CONTROL_UNHOLD indication from the bridging code is swallowed,
leaving the channel in question to still appear to be on hold.

The fix here is to modify the logic inside ast_indicate_data() to not
drop the indication if the channel is simply leaving a bridge. This way,
channels on hold redirected out of a bridge revert to their expected "in
use" state after the redirection.

ASTERISK-25418 #close
Reported by Mark Michelson

Change-Id: If6115204dfa0551c050974ee138fabd15f978949

Page uses the async method of dialing with the dial API.  When a call gets
forwarded there is no calling channel available.  If the predial handler
was set then the calling channel could not be put into auto-service
for the forwarded call because it doesn't exist.  A crash is the result.

* Moved the callee predial parameter string processing to before the
string is passed to the dial API rather than having the dial API do it.
There are a few benefits do doing this.  The first is the predial
parameter string processing doesn't need to be done for each channel
called by the dial API.  The second is in async mode and the forwarded
channel is to have the predial handler executed on it then the
non-existent calling channel does not need to be present to process the
predial parameter string.

* Don't start auto-service on a non-existent calling channel to execute
the predial handler when the dial API is in async mode and forwarding a
call.

ASTERISK-25384 #close
Reported by: Chet Stevens

Change-Id: If53892b286d29f6cf955e2545b03dcffa2610981