During stress testing, we have frequently seen crashes occur because a
CLI or AMI command attempts to access information that is in the process
of being destroyed.

When addressing how to fix this issue, we initially considered fixing
individual crashes we observed. However, the changes required to fix
those problems would introduce considerable overhead to the nominal
case. This is not reasonable in order to prevent a crash from occurring
while Asterisk is already shutting down.

Instead, this change makes it so AMI and CLI commands cannot be executed
if Asterisk is being shut down. For AMI, this is absolute. For CLI,
though, certain commands can be registered so that they may be run
during Asterisk shutdown.

ASTERISK-25825 #close

Change-Id: I8887e215ac352fadf7f4c1e082da9089b1421990

Older versions of PJSIP do not have the proto field on the TLS transport
setting structure. This change adds a configure check so even if it is
not present we will still be able to build.

Change-Id: Ibf3f47befb91ed1b8194bf63888baa6fee05aba9

Channel masquerading had a conflict with autochannel locking.

When locking autochannel->channel, the channel is fetched from the
autochannel and then locked. During the fetch, the autochannel -- which
has no locks itself -- can be modified by someone who owns the channel
lock. That means that the value of autochan->channel cannot be trusted
until you hold the lock.

In practice, this caused problems with Local channels getting
masqueraded away while the ChanSpy attempted to get info from that
channel. The old channel which was about to get removed got locked, but
the new (replaced) channel got unlocked (no-op). Because the replaced
channel was now locked (and would never get unlocked), it couldn't get
removed from the channel list in a timely manner, and would now cause
deadlocks when iterating over the channel list.

This change checks the autochannel after locking the channel for changes
to the autochannel. If the channel had been changed, the lock is
reobtained on the new channel.

In theory it seems possible that after this fix, the lock attempt on the
old (wrong) channel can be on an already destroyed lock, maybe causing
a crash. But that hasn't been observed in the wild and is harder induce
than the current deadlock.

Thanks go to Filip Frank for suggesting a fix similar to this and
especially to IRC user hexanol for pointing out why this deadlock was
possible and testing this fix. And to Richard for catching my rookie
while loop mistake ;)

ASTERISK-25321 #close

Change-Id: I293ae0014e531cd0e675c3f02d1d118a98683def

Configurations like "aors = a, b, c" were either ignoring everything after "a"
or trying to look up " b".  Same for mailboxes,  ciphers, contacts and a few
others.

To fix, all the strsep(&copy, ",") calls have been wrapped in ast_strip.  To
facilitate this, ast_strip, ast_skip_blanks and ast_skip_nonblanks were
updated to handle null pointers.

In some cases, an ast_strlen_zero() test was added to skip consecutive commas.

There was also an attempt to ast_free an ast_strdupa'd string in
ast_sip_for_each_aor which was causing a SEGV.  I removed it.

Although this issue was reported for realtime, the issue was in the res_pjsip
modules so all config mechanisms were affected.

ASTERISK-25829 #close
Reported-by: Mateusz Kowalski

Change-Id: I0b22a2cf22a7c1c50d4ecacbfa540155bec0e7a2

Refactor and created function ast_cli_print_timestr_fromseconds to print
seconds formatted:  year(s) week(s) day(s) hour(s) second(s)

This function now is used in addons/cdr_mysql.c,cdr_pgsql.c, main/cli.c,
res_config_ldap.c, res_config_pgsql.c.

Change-Id: Ibeb8634102cd11d3f8623398b279cb731bcde36c

Per RFC3325, the 'From' header is now anonymized on outgoing calls when
caller id presentation is prohibited.

TID = trust_id_outbound
PRO = Set(CALLERID(pres)=prohib)
USR = endpoint/from_user
DOM = endpoint/from_domain
PAI = YES(privacy=off), NO(not sent), PRI(privacy=full) (assumes send_pai=yes)

Conditions          |Result
--------------------|----------------------------------------------------
TID PRO USR DOM     |PAI    FROM
--------------------|----------------------------------------------------
Y   Y   abc def.ghi |PRI    "Anonymous" <sip:abc@def.ghi>
Y   Y   abc         |PRI    "Anonymous" <sip:abc@anonymous.invalid>
Y   Y       def.ghi |PRI    "Anonymous" <sip:anonymous@def.ghi>
Y   Y               |PRI    "Anonymous" <sip:anonymous@anonymous.invalid>

Y   N   abc def.ghi |YES    <sip:abc@def.ghi>
Y   N   abc         |YES    <sip:abc@<ip_address>>
Y   N       def.ghi |YES    "Caller Name" <sip:<caller_exten>@def.ghi>
Y   N               |YES    "Caller Name" <sip:<caller_exten>@<ip_address>>

N   Y   abc def.ghi |NO     "Anonymous" <sip:abc@def.ghi>
N   Y   abc         |NO     "Anonymous" <sip:abc@anonymous.invalid>
N   Y       def.ghi |NO     "Anonymous" <sip:anonymous@def.ghi>
N   Y               |NO     "Anonymous" <sip:anonymous@anonymous.invalid>

N   N   abc def.ghi |YES    <sip:abc@def.ghi>
N   N   abc         |YES    <sip:abc@<ip_address>>
N   N       def.ghi |YES    "Caller Name" <sip:<caller_exten>@def.ghi>
N   N               |YES    "Caller Name" <sip:<caller_exten>@<ip_address>>

ASTERISK-25791 #close
Reported-by: Anthony Messina

Change-Id: I2c82a5ca1413c2c00fb62ea95b0ae8e97af54dc9

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

Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html

From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.

   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.

   The default behavior remains building with the shared pjproject
   installation, if any.

Building:

   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.

Behind the scenes:

   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.

   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.

   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.

   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.

   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.

   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.

   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.

   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.

Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.

Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103

The channel is now going to get T.38 terminated when it leaves the
bridging system and the bridged peers are going to get T.38 terminated as
well.

ASTERISK-25582

Change-Id: I77a9205979910210e3068e1ddff400dbf35c4ca7

ASTERISK-25582

Change-Id: I69451920b122de7ee18d15bb231c80ea7067a22b

Local channel optimization could cause DTMF digits to be duplicated.
Pending DTMF end events would be posted to a bridge when the local channel
optimizes out and is replaced by the channel further down the chain.  When
the real digit ends, the channel would get another DTMF end posted to the
bridge.

A -- LocalA;1/n -- LocalA;2/n -- LocalB;1 -- LocalB;2 -- B

1) LocalA has the /n flag to prevent optimization.
2) B is sending DTMF to A through the local channel chain.
3) When LocalB optimizes out it can move B to the position of LocalB;1
4) Without this patch, when B swaps with LocalB;1 then LocalB;1 would
settle an owed DTMF end to the bridge toward LocalA;2.
5) When B finally ends its DTMF it sends the DTMF end down the chain.
6) Without this patch, A would hear the DTMF digit end when LocalB
optimizes out and when B ends the original digit.

ASTERISK-25582

Change-Id: I1bbd28b8b399c0fb54985a5747f330a4cd2aa251

Change-Id: Ib462633d396fa941379dfef648dcd2245e350084

The 'reload' mechanism actually involves closing the underlying
socket and calling the appropriate udp, tcp or tls start functions
again.  Only outbound_registration, pubsub and session needed work
to reset the transport before sending requests to insure that the
pjsip transport didn't get pulled out from under them.

In my testing, no calls were dropped when a transport was changed
for any of the 3 transport types even if ip addresses or ports were
changed. To be on the safe side however, a new transport option was
added (allow_reload) which defaults to 'no'.  Unless it's explicitly
set to 'yes' for a transport, changes to that transport will be ignored
on a reload of res_pjsip.  This should preserve the current behavior.

Change-Id: I5e759850e25958117d4c02f62ceb7244d7ec9edf

Pjproject has deprecated pjsip_dlg_create_uas in 2.5 and replaced it with
pjsip_dlg_create_uas_and_inc_lock which, as the name implies, automatically
increments the lock on the returned dialog.  To account for this, configure.ac
now detects the presence of pjsip_dlg_create_uas_and_inc_lock and res_pjsip.c
has an #ifdef HAVE_PJSIP_DLG_CREATE_UAS_AND_INC_LOCK to decide whether to use
the original call or the new one.  If the new one was used, the ref count is
decremented before returning.

ASTERISK-25751 #close
Reported-by Josh Colp

Change-Id: I1be776b94761df03bd0693bc7795a75682615ca8

FD_SET contains a conditional statement to protect against buffer
overruns.  The statement was overly complicated and prevented use
of the last array element of ast_fdset.  We now just verify the fd
is less than ast_FDMAX.

Change-Id: I41895c0b497b052aef5bf49d75c817c48b326f40

Attempting to load a transport from realtime was forcing asterisk into an
infinite recursion loop.  The first thing transport_apply did was to do a
sorcery retrieve by id for an existing transport of the same name. For files,
this just returns the previous object from res_sorcery_config's internal
container, if any.  For realtime, the res_sourcery_realtime driver looks in the
database and finds the existing row but now it has to rehydrate it into a
sorcery object which means calling... transport_apply.  And so it goes.

The main issue with loading from realtime (apart from the loop) was that
transport stores structures and pointers directly in the ast_sip_transport
structure instead of the separate ast_transport_state structure.  This patch
separates those items into the ast_sip_transport_state structure.  The pattern
is roughly the same as res_pjsip_outbound_registration.

Although all current usages of ast_sip_transport and ast_sip_transport_state
were modified to use the new ast_sip_get_transport_state API, the original
items are left in ast_sip_transport and kept updated to maintain ABI
compatability for third-party modules.  They are marked as deprecated and
noted that they're now in ast_sip_transport_state.

ASTERISK-25606 #close
Reported-by: Martin Moučka

Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19

The SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 defines did not exist prior
to OpenSSL version 1.0.1. A recent commit attempts to, by default, set
these options, which can cause problems on systems with older OpenSSL
installations.

This commit adds a configure script check for those defines and will not
attempt to make use of those if they do not exist. We will print a
warning urging the user to upgrade their OpenSSL installation if those
defines are not present.

Change-Id: I6a2eb9a43fd0738b404d8f6f2cf4b5c22d9d752d

This change exposes the configuration of various aspects of the TLS
support and sets the default to the modern standards.

The TLS cipher is now set to the best values according to the
Mozilla OpSec team, different TLS versions can now be disabled, and
the cipher order can be forced to be that of the server instead of
the client.

ASTERISK-24972 #close

Change-Id: I0a10f2883f7559af5e48dee0901251dbf30d45b8

Asterisk by default will create a single database connection and share
it among all threads that attempt to access the database. In previous
versions of Asterisk, this was tolerable, because the most used channel
driver, chan_sip, mostly accessed the database from a single thread.
With PJSIP, however, many threads may be attempting to perform database
operations, and there is the potential for many more database accesses,
meaning the concurrency is a horrible bottleneck if only one connection
is shared.

Asterisk has a connection pooling facility built into it, but the
implementation has flaws. For one, there is a strict limit on the number
of simultaneous connections that could be made to the database. Anything
beyond the maximum would result in a failed operation. Attempting to
predict what the maximum should be is nearly impossible even for someone
intimately familiar with Asterisk's threading model. In addition, use of
transactions in the dialplan can cause some severe bugs if connection
pooling is enabled.

This commit seeks to fix the concurrency problem by removing all
connection management code from Asterisk and leaving that to the
underlying unixODBC code instead. Now, Asterisk does not share a single
connection, nor does it try to maintain a connection pool. Instead, all
Asterisk ever does is request a connection from unixODBC and allow
unixODBC to either allocate those connections or retrieve them from a
pool.

Doing this has a bit of a ripple effect. For one, since connections are
not long-lived objects, several of the safeguards that previously
existed have been removed. We don't have to worry about trying to use a
connection that has gone stale. In every case, when we request a
connection, it has just been made and we don't need to perform any
sanity checks to be sure it's still active.

Another major player affected by this change is transactions.
Transactions and their respective connections were so tightly coupled
that it was almost pornographic. This code change moves
transaction-related code to its own file separate from the core ODBC
functionality. This way, the core of ODBC does not even have to know
that transactions exist.

In making this large change, I had to look at a lot of code and
understand it. When making this change, I discovered several places
where the behavior is definitely not ideal, but it seemed outside the
scope of this change to be fixing it. Instead, any place where I saw
some sort of room for improvement has had a XXX comment added explaining
what could be altered to improve it.

Change-Id: I37a84def5ea4ddf93868ce8105f39de078297fbf

Dump the res_pjsip endpt internals.

In non-developer mode we will not document or make easily accessible the
"details" option even though it is still available.  The user has to know
it exists to use it.  Presumably they would also be aware of the potential
crash warning below.

Warning: PJPROJECT documents that the function used by this CLI command
may cause a crash when asking for details because it tries to access all
active memory pools.

Change-Id: If2d98a3641c9873364d1daaad971376311aef3cb

res_pjsip_log_forwarder has been renamed to res_pjproject
and enhanced as follows:

As a follow-on to the recent 'Add CLI "pjsip show buildopts"' patch,
a new ast_pjproject_get_buildopt function has been added.  It
allows the caller to get the value of one of the buildopts.

The initial use case is retrieving the runtime value of
PJ_MAX_HOSTNAME to insure we don't send a hostname greater
than pjproject can handle.  Since it can differ between
the version of pjproject that Asterisk was compiled against
and the version of pjproject that Asterisk is running against,
we can't use the PJ_MAX_HOSTNAME macro directly in Asterisk
source code.

Change-Id: Iab6e82fec3d7cf00c1cf6185c42be3e7569dee1e

The xferfailsound was read from the channel at the beginning of the transfer,
and that value is "cached" for the duration of the transfer. Therefore, changing
the xferfailsound on the channel using the FEATURE() dialplan function does
nothing once the transfer is under way.

This makes it so the transfer code instead gets the xferfailsound configuration
options from the channel when it is actually going to be used.

This patch also fixes a potential memory leak of the props object as well as
making sure the condition variable gets initialized before being destroyed.

ASTERISK-25696 #close

Change-Id: Ic726b0f54ef588bd9c9c67f4b0e4d787934f85e4

Added new global option (regcontext) to pjsip. When set, Asterisk will
dynamically create and destroy a NoOp priority 1 extension
for a given endpoint who registers or unregisters with us.

ASTERISK-25670 #close
Reported-by: Daniel Journo

Change-Id: Ib1530c5b45340625805c057f8ff1fb240a43ea62

On a system with multiple ip addresses in the same subnet, if a
transport is bound to a specific ip address and endpoint/media_address
 is set, the SIP/SDP will have the correct address in all fields but
the rtp stream MAY still originate from one of the other ip addresses,
most probably the "primary" ip address.  This happens because
 res_pjsip_sdp_rtp/create_rtp always calls ast_instance_new with
the "all" ip address (0.0.0.0 or ::).

The new option causes res_pjsip_sdp_rtp/create_rtp to call
ast_rtp_instance_new with the endpoint's media_address (if specified)
instead of the "all" address.  This causes the packets to originate from
the specified address.

ASTERISK-25632
ASTERISK-25637
Reported-by: Olivier Krief
Reported-by: Dan Journo

Change-Id: I3dfaa079e54ba7fb7c4fd1f5f7bd9509bbf8bd88

PJSIP name formats:
pjsip/aor/<aor>-<seq> -- registrar thread pool serializer
pjsip/default-<seq> -- default thread pool serializer
pjsip/messaging -- messaging thread pool serializer
pjsip/outreg/<registration>-<seq> -- outbound registration thread pool
serializer
pjsip/pubsub/<endpoint>-<seq> -- pubsub thread pool serializer
pjsip/refer/<endpoint>-<seq> -- REFER thread pool serializer
pjsip/session/<endpoint>-<seq> -- session thread pool serializer
pjsip/websocket-<seq> -- websocket thread pool serializer

Change-Id: Iff9df8da3ddae1132cb2ef65f64df0c465c5e084

* Add new API call to get a sequence number for use in human friendly
taskprocessor names.

* Add new API call to create a taskprocessor name in a given buffer and
append a sequence number.

Change-Id: Iac458f05b45232315ed64aa31b1df05b875537a9

Renamed global declaration:tv to dummy_tv_var_for_types,
which would oltherwise cause 'shadow' warnings when 'tv'
was declared as a local variable elsewhere.

Added comment to note that dummy_tv_var_for_types is never
really exported and only used as a place holder.

ASTERISK-25627 #close

Change-Id: I9a6e17995006584f3627efe8988e3f8aa0f5dc28

This is the sixth patch in a series meant to reduce the bulk of pbx.c.
This moves hangup handler management functions to their own source.

Change-Id: Ib25a75aa57fc7d5c4294479e5cc46775912fb104

This is the sixth patch in a series meant to reduce the bulk of pbx.c.
This moves dialplan application management functions to their own source.

Change-Id: I444c10fb90a3cdf9f3047605d6a8aad49c22c44c

This is the fifth patch in a series meant to reduce the bulk of pbx.c.
This moves ast_switch functions to their own source.

Change-Id: Ic2592a18a5c4d8a3c2dcf9786c9a6f650a8c628e

The menuselect conflict between app_voicemail and res_mwi_external
makes it hard to package 1 version of Asterisk.  There no actual
build dependencies between the 2 so moving this check to runtime
seems like a better solution.

The ast_vm_register and ast_vm_greeter_register functions in app.c
were modified to return AST_MODULE_LOAD_DECLINE instead of -1 if there
is already a voicemail module registered. The modules' load_module
functions were then modified to return DECLINE instead of -1 to the
loader.  Since -1 is interpreted by the loader as AST_MODULE_LOAD_FAILURE,
the modules were incorrectly causing Asterisk to stop so this needed
to be cleaned up anyway.

Now you can build both and use modules.conf to decide which voicemail
implementation to load.

The default menuselect options still build app_voicemail and not
res_mwi_external but if both ARE built, res_mwi_external will load
first and become the voicemail provider unless modules.conf rules
prevent it.  This is noted in CHANGES.

Change-Id: I7d98d4e8a3b87b8df9e51c2608f0da6ddfb89247

This is the third patch in a series meant to reduce the bulk of pbx.c.
This moves channel and global variable routines to their own source.

Change-Id: Ibe8fb4647db11598591d443a99e3f99200a56bc6

This is the second patch in a series meant to reduce the bulk of pbx.c.
This moves custom function management routines to their own source.

Change-Id: I34a6190282f781cdbbd3ce9d3adeac3c3805e177

We joked about splitting pbx.c into multiple files but this first step was
fairly easy.  All of the pbx_builtin dialplan applications have been moved
into pbx_builtins.c and a new pbx_private.h file was added. load_pbx_builtins()
is called by asterisk.c just after load_pbx().

A few functions were renamed and are cross-exposed between the 2 source files.

Change-Id: I87066be3dbf7f5822942ac1449d98cc43fc7561a

Updated ast_websocket_write to encode the entire frame in to one
write operation, to ensure that we don't end up with a situation
where the websocket header has been sent, while the body can not
be written.

Previous to August's patch in commit b9bd3c14, certain network
conditions could cause the header to be written, and then the
sub-sequent body to fail - which would cause the next successful
write to contain a new header, and a new body (resulting in
the peer receiving two headers - the second of which would be
read as part of the body for the first header).

This was patched to have both write operations individually fail
by closing the websocket.

In a case available to the submitter of this patch, the same
body which would consistently fail to write, would succeed
if written at the same time as the header.

This update merges the two operations in to one, adds debug messages
indicating the reason for a websocket connection being closed during
a write operation, and clarifies some variable names for code legibility.

Change-Id: I4db7a586af1c7a57184c31d3d55bf146f1a40598

When an endpoint is created, its messages are forwarded to both the tech
endpoint topic and the all endpoints topic. This is done so that various
parties interested in endpoint messages can subscribe to just the tech
endpoint and receive all messages associated with that particular technology,
as opposed to subscribing to the all endpoints topic. Unfortunately, when the
tech endpoint is created, it also forwards all of its messages to the all
topic. This results in duplicate messages whenever an endpoint publishes its
messages.

This patch resolves the duplicate message issue by creating a new function
for Stasis caching topics, stasis_cp_sink_create. In most respects, this acts
as a normal caching topic, save that it no longer forwards messages it receives
to the all endpoints topic. This allows it to act as an aggregation "sink",
while preserving the necessary caching behaviour.

ASTERISK-25137 #close
Reported-by: Vitezslav Novy

ASTERISK-25116 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>

Change-Id: Ie47784adfb973ab0063e59fc18f390d7dd26d17b

ASTERISK-25615
Reported by: George Joseph

Change-Id: Ieff35307254ca193f3d473cff2e396ca57c7ce0b

pjproject < 2.5.0 will segfault on a tls transport if async_operations
is greater than 1.  A runtime version check has been added to throw
an error if the version is < 2.5.0 and async_operations > 1.

To assist in the check, a new api "ast_compare_versions" was added
to utils which compares 2 major.minor.patch.extra version strings.

ASTERISK-25615 #close

Change-Id: I8e88bb49cbcfbca88d9de705496d6f6a8c938a98
Reported-by: George Joseph
Tested-by: George Joseph

Both transport and endpoint now check for the existence and readability
of tls certificate and key files before passing them on to pjproject.
This will cause the object to not load rather than waiting for pjproject
to discover that there's a problem when a session is attempted.

NOTE: chan_sip also uses ast_rtp_dtls_cfg_parse but it's located
in build_peer which is gigantic and I didn't want to disturb it.
Error messages will emit but it won't interrupt chan_sip loading.

ASTERISK-25618 #close

Change-Id: Ie43f2c1d653ac1fda6a6f6faecb7c2ebadaf47c9
Reported-by: George Joseph
Tested-by: George Joseph

An earlier commit changed the id of dynamic contacts to contain
a hash instead of the uri.  This patch updates status change
logging to show the aor/uri instead of the id.  This required
adding the aor id to contact and contact_status and adding
uri to contact_status.  The aor id gets added to contact and
contact_status in their allocators and the uri gets added to
contact_status in pjsip_options when the contact_status is
created or updated.

ASTERISK-25598 #close

Reported-by: George Joseph
Tested-by: George Joseph

Change-Id: I56cbec1d2ddbe8461367dd8b6da8a6f47f6fe511