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

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

Change validation on reload module because now used the cli function for
reload. The sip_reload() function never fail and ever return NULL for this
reason on reload() now use the call the sip_reload() and return
AST_MODULE_LOAD_SUCCESS.

This problem is dectected on reload by PUT method on ARI, getting always
404 http code when the module is reloaded.

ASTERISK-25325 #close
Reporte by: Rodrigo Ramírez Norambuena

Change-Id: I41215877fb2cfc589e0d4d464000cf6825f4d7fb

Change-Id: I2b8db18eac36c01a5c7eb9467699124e203fd093

Change-Id: Ie62ff1f4b7adc1a12fa0303f53926af249b25e20

We should not try to send a SIP response message because we may be
restoring a persistent subscription where we are not responding to a SIP
request.

Change-Id: Id89167ef90320c5563f37e632db0dda6cb9e7dec

Fix off-nominal visited vector leak in build_resource_tree().

Change-Id: If0399c7941c9c0b1038bcfb7b9a371760977831c

ast_sip_pubsub_register_body_generator() did not account for the null
terminator set by sprintf() in the allocated output buffer.

Change-Id: I388688a132e479bca6ad1c19275eae0070969ae2

Change-Id: Ia396096b4fedc2874649ca11137612c3f55e83e3

Change-Id: I15debd0f717f16ee2f78e7f56151c3b3b97b72fc

Change-Id: I364906d6d2bad3472929986704a0286b9a2cbe3f

The default_from_user retrieval function was pulling the
default_from_user from the global configuration struct in an unsafe way.
If using a database as a backend configuration store, the global
configuration struct is short-lived, so grabbing a pointer from it
results in referencing freed memory.

The fix here is to copy the default_from_user value out of the global
configuration struct.

Thanks go to John Hardin for discovering this problem and proposing the
patch on which this fix is based.

ASTERISK-25390 #close
Reported by Mark Michelson

Change-Id: I6b96067a495c1259da768f4012d44e03e7c6148c

We will only rewrite the Contact header if there is no Record-Route header in
the received request. If a malfunctioning proxy places a Record-Route header
into a REGISTER request, we will decide that we shouldn't update the IP/port
in the Contact header, and we will end up storing a contact with an AoR that
contains the NAT'd IP address.

While it is nice to have the proxy *not* send a Record-Route in a REGISTER
request, it's also a good idea to not process the header in a non-dialog
message. This patch updates the code to explicitly ignore the Record-Route
header in REGISTER requests.

ASTERISK-25387 #close

Change-Id: I4bd3bcccc4003d460cc354d986b0dea2e433ef3f

Add ProgressIndicator IE with inband info present to Progress and
Alerting Q.931 message

ASTERISK-25227 #close
Reported by: Alexandr Dranchuk

Change-Id: I326ad13cb1db9a72b3fd902bafed3c28a3684203

Make certain that the pjsip session has not failed to
allocate the format capabilities structure, which can
otherwise cause a crash when referenced.

ASTERISK-25323

Change-Id: I602790ba12714741165e441cc64a3ecde4cb5750

In working through a recent ICE negotiation bug, I found the debug
logging in res_rtp_asterisk to be lacking. This patch adds a number of
debug and warning statements that were helpful.

Change-Id: I950c6d8f13a41f14b3d6334b4cafe7d4e997be80