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

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

This patch adds the ability to subscribe to all events. There are two possible
ways to accomplish this:
(1) On initial WebSocket connection. This patch adds a new query parameter,
    'subscribeAll'. If present and True, Asterisk will subscribe the
    applications to all ARI events.
(2) Via the applications resource. When subscribing in this manner, an ARI
    client should merely specify a blank resource name, i.e., 'channels:'
    instead of 'channels:12354'. This will subscribe the application to all
    resources of the 'channels' type.

ASTERISK-24870 #close

Change-Id: I4a943b4db24442cf28bc64b24bfd541249790ad6

The RECORDED_FILE variable is empty unless a '%d' is specified in the filename.
This patch makes it so the variable is always set to the filename.

ASTERISK-25410 #close

Change-Id: I4ec826d8eb582ae2ad184e717be8668b74d37653

Currently, Asterisk will log to the last configured syslog
channel in logger.conf. This is due to the fact that the
final call to openlog() supersedes all of the previous calls.
This commit removes the call to openlog() and passes the
facility to ast_log_vsyslog(), along with utilizing the
LOG_MAKEPRI macro to ensure that the message is routed to
the correct facility and with the correct priority.

ASTERISK-25407 #close
Reported by: Elazar Broad
Tested by: Elazar Broad

Change-Id: Ie2a2416bc00cce1b04e99ef40917c2011953ddd2

This patch adds support for subscribing to all device state changes. This is
done either by subscribing to an empty device, e.g., 'eventSource=deviceState:',
or by the WebSocket connection specifying that it wants all state in the
system.

ASTERISK-24870

Change-Id: I9cfeca1c9e2231bd7ea73e45919111d44d2eda32

This patch adds support for receiving events regarding Peer status changes
and Contact status changes. This is particularly useful in scenarios where
we are subscribed to all endpoints and channels, where we often want to know
more about the state of channel technology specific items than a single
endpoint's state.

ASTERISK-24870

Change-Id: I6137459cdc25ce27efc134ad58abf065653da4e9

Now with menuselect "DEBUG_FD_LEAKS" and CLI "core show fd", a timestamp is
shown with each file descriptor. This helps to debug leaked UDP/TCP ports on
long-lived servers, for example.

ASTERISK-25405 #close

Change-Id: I968339e5155a512eba1032a5263f1ec8b5e1f80b

When changing a hint extension without removing the hint first the
device state and presence state is not updated. This causes the state
of the hint to be that of the previous extension and not the current
one. This state is kept until a state change occurs as a result of
something (presence state change, device state change).

This change updates the hint with the current device and presence
state of the new extension when it is changed. Any state callbacks
which may have been added before the hint extension is changed are
also informed of the new device and presence state if either have
changed.

ASTERISK-25394 #close

Change-Id: If268f1110290e502c73dd289c9e7e7b27bc8432f

Validate string buffer allocation before using them.

ASTERISK-25323

Change-Id: Ib9c338bdc1e53fb8b81366f0b39482b83ef56ce0

Remove repeated code on macro of assigned buffer to SQL vars

Change-Id: Icb19ad013124498e172ea1d0b29ccd0ed17deef0

The CALLERID(num) and CALLERID(name) and other info are placed into the
`char from[256]` in initreqprep. If the name was too long, the addr-spec
and params wouldn't fit.

Code is moved around so the addr-spec with params is placed there first,
and then fitting in as much of the display-name as possible.

ASTERISK-25396 #close

Change-Id: I33632baf024f01b6a00f8c7f35c91e5f68c40260

Validate ast_malloc buffer returned before using it in
set_redirecting_value().

ASTERISK-25323

Change-Id: I15d2ed7cb0546818264c0bf251aa40adeae83253

When a queued caller transfers an agent to another extension sometimes the
raised AgentComplete event has a reason of "caller" and sometimes "transfer".
Since a transfer has taken place this should always be transfer. This occurs
because sometimes the stasis hangup event arrives before the transfer event
thus writing a different reason out.

With this patch, when a hangup event is received during a transfer it will
check to see if the channel that is hanging up is part of a transfer. If so
it will return and let the subsequently received transfer event handler take
care of the cleanup.

ASTERISK-25399 #close

Change-Id: Ic63c49bd9a5ed463ea7a032fd2ea3d63bc81a50d

Although unlikely, if the tech private is returned as
a NULL, chan_pjsip_get_rtp_peer() would crash.

ASTERISK-25323

Change-Id: Ie231369bfa7da926fb2b9fdaac228261a3152e6a

During some transfer scenarios involving queues Asterisk would sometimes
crash when trying to obtain a channel snapshot (could happen on caller or
member channels). This occurred because the underlying channel had already
disappeared when trying to obtain the latest snapshot.

This patch adds a reference to both the member and caller channels that
extends to the lifetime of the queue'd call, thus making sure the channels
will always exist when retrieving the latest snapshots.

ASTERISK-25185 #close
Reported by: Etienne Lessard

Change-Id: Ic397fa68fb4ff35fbc378e745da9246a7b552128

There is a slim chance of a race condition occurring where two threads
can both attempt to manipulate the same area.

Thread A can be handling an incoming initial SUBSCRIBE request. Thread A
lets the specific subscription handler know that the subscription has
been established.

At this point, Thread B may detect a state change on the subscribed
resource and queue up a notification task on Thread C, the subscription
serializer thread.

Now Thread A attempts to generate the initial NOTIFY request to send to
the subscriber at the same time that Thread C attempts to generate a
state change NOTIFY request to send to the subscriber.

The result is that Threads A and C can step on the same memory area,
resulting in a crash. The crash has been observed as happening when
attempting to allocate more space to hold the body for the NOTIFY.

The solution presented here is to queue the subscription establishment
and initial NOTIFY generation onto the subscription serializer thread
(Thread C in the above scenario). This way, there is no way that a state
change notification can occur before the initial NOTIFY is sent, and if
there is a quick succession of NOTIFYs, we can guarantee that the two
NOTIFY requests will be sent in succession.

Change-Id: I5a89a77b5f2717928c54d6efb9955e5f6f5cf815

It has been observed that on long-running busy systems, a scheduler
context can eventually hit INT_MAX for its assigned IDs and end up
overflowing into a very low negative number. When this occurs, this can
result in odd behaviors, because a negative return is interpreted by
callers as being a failure. However, the item actually was successfully
scheduled. The result may be that a freed item remains in the scheduler,
resulting in a crash at some point in the future.

The scheduler can overflow because every time that an item is added to
the scheduler, a counter is bumped and that counter's current value is
assigned as the new item's ID.

This patch introduces a new method for assigning scheduler IDs. Instead
of assigning from a counter, a queue of available IDs is maintained.
When assigning a new ID, an ID is pulled from the queue. When a
scheduler item is released, its ID is pushed back onto the queue. This
way, IDs may be reused when they become available, and the growth of ID
numbers is directly related to concurrent activity within a scheduler
context rather than the uptime of the system.

Change-Id: I532708eef8f669d823457d7fefdad9a6078b99b2

Asterisk can load and register an object type while still having an invalid
sorcery mapping. This can cause an issue when a creation call is invoked.
For example, mis-configuring PJSIP's endpoint identifier by IP address mapping
in sorcery.conf will cause the sorcery mechanism to be invalidated; however, a
subsequent ARI invocation to create the object will cause a crash, as the
internal type may not be registered as sorcery expects.

Merely checking for a NULL pointer here solves the issue.

Change-Id: I54079fb94a1440992f4735a9a1bbf1abb1c601ac