When an endpoint is deleted (such as through an API), the persistent endpoint
currently continues to lurk around. While this isn't harmful from a memory
consumption perspective - as all persistent endpoints are reclaimed on
shutdown - it does cause Stasis endpoint related operations to continue
to believe that the endpoint may or may not exist.

This patch causes the persistent endpoint related to a PJSIP endpoint to be
destroyed if the PJSIP endpoint is deleted.

Change-Id: I85ac707b4d5e6aad882ac275b0c2e2154affa5bb

The contact_status Sorcery objects are currently not destroyed when a contact
is deleted. This causes the contact's last known RTT/status to be 'sticky'
when the contact itself may no longer exist. This patch causes the
contact_status objects associated with both dynamic and static contacts to
be destroyed if the AoR holding those contacts is also destroyed (or via
other paths where a contact may be deleted.)

Change-Id: I7feec8b9278cac3c5263a4c0483f4a0f3b62426e

The JSON packing for the ContactStatusChange event forgot to include the
roundtrip_usec field. As a result, the field never showed up in any event,
even when the data was available. This patch corrects that error by properly
packing the JSON blob with the data.

Change-Id: I8df80da659a44010afbd48f645967518ff5daa17

This patch adds a new setting "websockets_enabled" to sip.conf.
Setting this to false allows chan_sip to be used without causing
conflicts with res_pjsip_transport_websocket.

ASTERISK-24106 #close
Reported by: Andrew Nagy

Change-Id: I04fe8c4f2d57b2d7375e0e25826c91a72e93bea7

During a stress test of subscriptions, a huge blast of
subscription-related traffic resulted in the threadpool expanding to a
ridiculous number of threads. The balooning of threads resulted in an
increase of memory, which led to a crash due to being out of memory.

An easy fix for the particular test was to limit the size of the
threadpool, thus reining in the amount of memory that would be used. It
was decided that there really is no downside to having a non-infinite
default value for the maximum size of the threadpool, so this change
introduces 50 threads as the maximum threadpool size for the SIP
threadpool.

ASTERISK-25513 #close
Reported by John Bigelow

Change-Id: If0b9514f1d9b172540ce1a6e2f2ffa1f2b6119be

Added code to allow the StatsD dialplan application to
send data to the server specified in statsd.conf.

ASTERISK-25419

Change-Id: I400db2f37c6ddf61515ff5a019646e36dcd0f922

When an AoR is created or destroyed dynamically, the scheduled OPTIONS
requests that qualify the contacts on the AoR are not necessarily started
or destroyed, particularly for persistent contacts created for that AoR.
This patch adds create/update/delete sorcery observers for an AoR, which
schedule/unschedule the qualifies as expected.

Change-Id: Ic287ed2e2952a7808ee068776fe966f9554bdf7d

This patch adds a rule for installing the Super Awesome Company based 'Basic
PBX' configuration files. As part of adding this rule, a bit of the content
that makes up installing the configuration files under the 'samples' target
was refactored into a make subroutine for usage by additional later config
make targets.

Change-Id: I6c2e27906f73e2919a2b691da0be20ae70302404

When compiled with assertions enabled one will occur when destroying
the subscription tree when UAS dialog creation fails. This is because
the code assumes that a dialog will always exist on a subscription
tree when in reality during this specific scenario it won't.

This change makes it so a dialog is not removed from the subscription
tree if it is not present.

ASTERISK-25505 #close

Change-Id: Id5c182b055aacc5e66c80546c64804ce19218dee

Added code to accept user input and validate it before
allowing it to be sent to the StatsD server.

ASTERISK-25419
Reported By: Ashley Sanders

Change-Id: I55c7ce44326a68ad6c5c1514b9575ac50f25bbc3

Since version 13, Asterisk sent all allowed codecs as callee, even when the
caller did not request/support them. In case of dynamic RTP payloads, this led
to the same ID for different codecs, which is not allowed by SIP/SDP. Now, the
intersection between the requested and the supported codecs is send again.

ASTERISK-24543 #close

Change-Id: Ie90cb8bf893b0895f8d505e77343de3ba152a287

When to install packages the indexed local is more old of the
version of software on the repository they have been upgraded by security
update then get the package will give 404 not found.

The patch prevent by update local index to repository for aptitude before
install.

ASTERISK-25495 #close

Reporte by: Rodrigo Ramírez Norambuena

Change-Id: I645959e553aac542805ced394cac2dca964051fa

Fixed 1 issue in each of the affected files.

ASTERISK-25494 #close
Reported-by: George Joseph
Tested-by: George Joseph

Change-Id: I818f149cd66a93b062df421e1c73c7942f5a4a77

Add the ability to filter output from pjsip list and show commands
using the "like" predicate like chan_sip.

For endpoints, aors, auths, registrations, identifyies and transports,
the modification was a simple change of an ast_sorcery_retrieve_by_fields
call to ast_sorcery_retrieve_by_regex.  For channels and contacts a
little more work had to be done because neither of those objects are
true sorcery objects.  That was just removing the non-matching object
from the final container.  Of course, a little extra plumbing in the
common pjsip_cli code was needed to parse the "like" and pass the regex
to the get_container callbacks.

Some of the get_container code in res_pjsip_endpoint_identifier was also
refactored for simplicity.

ASTERISK-25477 #close
Reported by: Bryant Zimmerman
Tested by: George Joseph

Change-Id: I646d9326b778aac26bb3e2bcd7fa1346d24434f1

During outbound registration it is possible to receive a fatal (any permanent/
non-temporary 4xx, 5xx, 6xx) response from the registrar that is simply due
to a problem with the registrar itself. Upon receiving the failure response
Asterisk terminates outbound registration for the given endpoint.

This patch adds an option, 'fatal_retry_interval', that when set continues
outbound registration at the given interval up to 'max_retries' upon receiving
a fatal response.

ASTERISK-25485 #close

Change-Id: Ibc2c7b47164ac89cc803433c0bbe7063bfa143a2

* changes:
  strings.c: Fix __ast_str_helper() to always return a terminated string.
  Add missing failure checks to ast_str_set_va() callers.

A crash was seen on a system that ran out of memory due to Asterisk not
checking for vector allocation failures in format_cap.c. With this
change, if either of the AST_VECTOR_INIT calls fail, we will return a
value indicating failure.

Change-Id: Ieb9c59f39dfde6d11797a92b45e0cf8ac5722bc8

A certain situation can result in our attempting to send a NOTIFY on a
destroyed dialog. Say we attempt to send a NOTIFY to a subscriber, but
that subscriber has dropped off the network. We end up retransmitting
that NOTIFY until the appropriate SIP timer says to destroy the NOTIFY
transaction. When the pjsip evsub code is told that the transaction has
been terminated, it responds in kind by alerting us that the
subscription has been terminated, destroying the subscription, and then
removing its reference to the dialog, thus destroying the dialog.

The problem is that when we get told that the subscription is being
terminated, we detect that we have not sent a terminating NOTIFY
request, so we queue up such a NOTIFY to be sent out. By the time that
queued NOTIFY gets sent, the dialog has been destroyed, so attempting to
send that NOTIFY can result in a crash.

The fix being introduced here is actually a reintroduction of something
the pubsub code used to employ. We hold a reference to the dialog and
wait to decrement our reference to the dialog until our subscription
tree object is destroyed. This way, we can send messages on the dialog
even if the PJSIP evsub code wants to terminate earlier than we would
like.

In doing this, some NULL checks for subscription tree dialogs have been
removed since NULL dialogs are no longer actually possible.

Change-Id: I013f43cddd9408bb2a31b77f5db87a7972bfe1e5

When sending a NOTIFY, we lock the dialog and then unlock the dialog
when finished. A recent change made it so that the subscription tree's
dialog pointer will be set NULL when sending the final NOTIFY request
out. This means that when we attempt to unlock the dialog, we pass a
NULL pointer to pjsip_dlg_dec_lock(). The result is that the dialog
remains locked after we think we have unlocked it. When a response to
the NOTIFY arrives, the monitor thread attempts to lock the dialog, but
it cannot because we never released the dialog lock. This results in
Asterisk being unable to process incoming SIP traffic any longer.

The fix in this patch is to use a local pointer to save off the pointer
value of the subscription tree's dialog when locking and unlocking the
dialog. This way, if the subscription tree's dialog pointer is NULLed
out, the local pointer will still have point to the proper place and the
dialog lock will be unlocked as we expect.

Change-Id: I7ddb3eaed7276cceb9a65daca701c3d5e728e63a

The SIP dialog is removed from the subscription tree when the final
NOTIFY is sent. However, after the final NOTIFY is sent, the persistence
update function still attempts to access the cseq from the dialog,
resulting in a crash.

This fix removes the subscription persistence at the same time that the
dialog is removed from the subscription tree. This way, there is no
attempt to update persistence when the subscription is being destroyed.

Change-Id: Ibb46977a6cef9c51dc95f40f43446e3d11eed5bb