This patch adds a bucket backend for the core media cache that interfaces to a
remote HTTP server. When a media item is requested in the cache, the cache will
query its bucket backends to see if they can provide the media item. If that
media item has a scheme of HTTP or HTTPS, this backend will be invoked.

The backend provides callbacks for the following:
 * create - this will always retrieve the URI specified by the provided
            bucket_file, and store it in the file specified by the object.
 * retrieve - this will pull the URI specified and store it in a temporary
              file. It is then up to the media cache to move/rename this file
              if desired.
 * delete - destroys the file associated with the bucket_file.
 * stale - if the bucket_file has expired, based on received HTTP headers from
           the remote server, or if the ETag on the server no longer matches
           the ETag stored on the bucket_file, the resource is determined to be
           stale.

Note that the backend respects the ETag, Expires, and Cache-Control headers
provided by the HTTP server it is querying.

ASTERISK-25654

Change-Id: Ie201c2b34cafc0c90a7ee18d7c8359afaccc5250

The "Refer-to" header of an incoming REFER request is parsed by
pjsip_parse_uri().  That function requires the URI parameter to be NULL
terminated.  Unfortunately, the previous code added the NULL terminator by
overwriting memory that may not be safe.  The overwritten memory results
could be benign, memory corruption, or a segmentation fault.  Now the URI
is NULL terminated safely by copying the URI to a new chunk of memory with
the correct size to be NULL terminated.

ASTERISK-25814 #close

Change-Id: I32565496684a5a49c3278fce06474b8c94b37342

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

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

Change-Id: I265e4ac47c629c9a63dd86b59df82a7ab3c64384

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

During the transfer process, some phones (okay it was the Jitsi softphone,
but maybe others are out there) send a "bye" immediately after receiving a
SIP Notify. When a "bye" is received early for some types of transfers the
transferer channel may no longer be available during late stage transfer
processing.

For instance, during an attended transfer involving stasis bridging at one
point the created local channel looks for an associated swap channel in
order to retrieve the stasis application name. If the transferer has hung
up then the local channel will fail to find it. The local channel then has
no way to know which stasis app to enter, so it fails and hangs up as well.
Thus the transfer does not complete as expected.

This patch delays the sending of the initial notify in order to give the
transfer process enough time to gather the necessary data for a successful
transfer.

ASTERISK-25771

Change-Id: I09cfc9a5d6ed4c007bc70625e0972b470393bf16

PJSIP does not ensure that when printing the message body the
buffer will be NULL terminated. This is problematic when searching
for the signal and duration values of the DTMF.

This change ensures the buffer is always NULL terminated.

Change-Id: I52653a1a60c93092d06af31a27408d569cc98968

ast_sip_get_transport_states was returning a container of internal_state
objects instead of ast_sip_transport_state objects.  This was causing
transport lookups to fail, most noticably in res_pjsip_nat, which
couldn't find the correct external addresses.  This was causing contacts
to go out with internal ip addresses.

ASTERISK-25830 #close
Reported-by: Sean Bright

Change-Id: I1aee6a2fd46c42e8dd0af72498d17de459ac750e

In message.c, if msg_alloc fails to init the string field,
vars may be null, so use a null tolerant cleanup.

In res_pjsip_messaging.c, if msg_data_create fails, mdata
will be null, so use a null tolerant cleanup.

ASTERISK-25323

Change-Id: Ic2d55c2c3750d5616e2a05ea92a19c717507ff56

This patch avoids crashing on a null pointer
if the strdup() allocation fails.

ASTERISK-25323

Change-Id: I3f67434820ba53b53663efd6cbb42749f4f6c0f5

Previous chan_sip behavior:

Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason).  For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize.  Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).

Previous chan_pjsip behavior:

Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason).  For an outgoing reason value, chan_pjsip
would send the reason value as passed down.

With this patch:

Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not.  RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason).  e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value.  The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.

The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).

Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent.  User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token.  Note that there are still
limitations on what characters can be put in a custom user value.  e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.

* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.

* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().

* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header().  The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.

Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87

Change-Id: Id6350b3c7d4ec8df7ec89863566645e2b0f441fd

* Fix double unref of other_party channel in off nominal path.

* This is unlikely to be a real problem.  However, for safety,
in handle_incoming_request() keep the datastore ref with the
other_party channel ref until we are finished with the other_party
channel.

Change-Id: I78f22547bf0bb99fb20814ceab75952bd857f821

This backs out item 4 of the 4875e5ac
commit.  Item 4 added the t38_bye_supplement.  Unfortunately, the frame
that it puts into the bridge may or may not be processed by the time the
bridged peer is kicked out of the bridge.  If it is processed then all is
well.  However, if it is not processed then that channel is stuck in fax
mode until it hangs up or maybe if it joins another bridge for T.38
faxing.

ASTERISK-25582

Change-Id: Ib20a03ecadf1bf8a0dcadfadf6c2f2e60919a9f7

There are a few cases where we're emitting notices or warnings
for things that really need neither, like a client retrying to subscribe
to mwi when they're not conifgured for it.  They get a 404 so there's no
need for non-debug messages.

Change-Id: I05e38a7ff6c2f2521146f4be6a79731b9864e61f

A few of the CLI commands weren't checking for enough arguments
and were SEGVing.

Change-Id: Ie6494132ad2fe54b4f014bcdc112a37c36a9b413

Introduced realloaction of ast_str buf in sqlite3_escape functions in case
the returned buffer from threadstorage was actually too small.

Change-Id: I3c5eb43aaade93ee457943daddc651781954c445

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

Warnings and errors in the pjproject libraries are generally handled by
Asterisk.  In many cases, Asterisk wouldn't even consider them to be warnings
or errors so the messages emitted by pjproject directly are either superfluous
or misleading.  A good exampe of this are the level-0 errors pjproject emits
when it can't open a TCP/TLS socket to a client to send an OPTIONS.  We don't
consider a failure to qualify a UDP client an "ERROR", why should a TCP/TLS
client be treated any differently?

A config file for res_pjproject has bene added (pjproject.conf) and a new
log_mappings object allows mapping pjproject levels to Asterisk levels
(or nothing).  The defaults if no pjproject.conf file is found are the same
as those that were hard-coded into res_pjproject initially: 0,1 = LOG_ERROR,
2 = LOG_WARNING, 3,4,5 = LOG_DEBUG<level>

Change-Id: Iba7bb349c70397586889b8f45b8c3d6c6c8c3898

When Asterisk receives a 412 (Conditional Request Failed) response
it has to recreate publish session.
There is bug in res_pjsip_outbound_publish.c
The function sip_outbound_publish_client_alloc is called with wrong object
while processing 412 (Conditional Request Failed) response.
This patch fixes it.

ASTERISK-25229 #close

Change-Id: I3b62f2debf6bb1e5817cde7b13ea39ef2bf14359

res_odbc.exports.in was missing a few symbols.
Changed to wildcards.

Change-Id: Ieadd76df24e43ea92577f651d478a0f7b742c30c

res_statsd.export.in was missing the _va variations of the log
functions causing Asterisk to crash in res_pjsip if OPTIONAL_API
wasn't enabled.

ASTERISK-25727 #close
Reported-by: Gergely Dömsödi

Change-Id: I395729f9f51bdd33c5ca757f5f96ebedad74077b

A new command (pjsip export config_wizard primitives) has been added that
will export all the pjsip objects it created to the console or a file
suitable for reuse in a pjsip.conf file.

ASTERISK-24919 #close
Reported-by: Ray Crumrine

Change-Id: Ica2a5f494244b4f8345b0437b16d06aa0484452b

If the PJSIP_HEADER dialplan function adds a PAI or RPID header and send_rpid
or send_pai is set, res_pjsip_caller_id attemps to retrieve, parse and modify
the header added by the dialplan function.  Since the header added by the
dialplan function is generic string, there are no virtual functions to parse
the uri and we get a segfault when we try.  Since the modify, was really only
an overwrite, we now just delete the old header if it was type PJSIP_H_OTHER
and recreate it.

This raises a question for another time though:  What should happen with
duplicate headers?  Right now res_pjsip_header_funcs doesn't check for dups
so if it's session supplement is loaded after res_pjsip_caller_id's (or any
other module that adds headers), there'll be dups in the message.

ASTERISK-25337 #close

Change-Id: I5e296b52d30f106b822c0eb27c4c2b0e0f71c7fa

It is possible when processing a SIP REGISTER request to have two
threads end up creating contact_status structures in sorcery.
contact_status is created using a "find or create" function. If two
threads call into this at the same time, each thread will fail to find
an existing contact_status, and so both will end up creating a new
contact status.

During testing, we would see sporadic failures because the
PJSIP_CONTACT() dialplan function would operate on a different
contact_status than what had been updated by res_pjsip/pjsip_options.

The fix here is two-fold:
1) The "find or create" function for contact_status now has a lock
around the entire operation. This way, if two threads attempt the
operation simultaneously, the first to get there will create the object,
and the second will find the object created by the first thread.

2) res_sorcery_memory has had its create callback updated so that it
will not allow for objects with duplicate IDs to be created.

Change-Id: I55b1460ff1eb0af0a3697b82d7c2bac9f6af5b97

A problem arose when testing the AMI subscription listing actions where it
was possible for a subscription that had not been fully initialized to be
listed. This was problematic as the underlying listing code would crash.

This change makes it so the subscription tree is fully set up before it is
added to the list of subscriptions. This ensures that when the listing actions
get the subscription it is valid.

ASTERISK-25738 #close

Change-Id: Iace2b13641c31bbcc0d43a39f99aba1f340c0f48

load_module was just too hairy with every step having to clean up all
previous steps on failure.

Some of the pjproject init calls have now been moved to a separate
load_pjsip function and the unload_pjsip function was enhanced to clean
up everything if an error happened at any stage of the load process.

In the process, a bunch of missing pj_shutdowns, serializer_pool_shutdowns
and ast_threadpool_shutdowns were also corrected.

Change-Id: I5eec711b437c35b56605ed99537ebbb30463b302

* heap-use-after-free happens when we free "cfg"
but then use "value" which refers to it

* A memory leak occurs because in some cases
it is not released "defaults"

ASTERISK-25721 #close
Reported by: Badalyan Vyacheslav
Tested by: Badalyan Vyacheslav

Change-Id: I3807d3f4726df6864430ec144cf6265d3f538469

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

Change-Id: I9290115a1aaadb589eb1d02eaeb502eec01b31fa

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

In case failed of command "realtime show pgsql status" show a message the data
of connection to more clear information in error.

Change-Id: Ia8e9e2400466606e7118f52a46e05df0719b6a29

Device state subscription lifetimes were governed by when the
subscription was established and unsubscribed from. However, it is
possible that at the time of unsubscription, there could be device state
events still in flight. When those device state events occur, the device
state callback could attempt to dereference a freed pointer. Crash.

This change ensures that the lifetime of the device state subscription
does not end until the underlying stasis subscription has confirmed that
its final message has been sent.

Change-Id: I25a0f1472894c1a562252fb7129671478e25e9b2

During ICE negotiation the IPs of the local interfaces are sent to the remote
peer as host candidates. In many cases Asterisk is behind a static one-to-one
NAT, so these host addresses will be internal IP addresses.

To help in hiding the topology of the internal network, this patch adds the
ability to override the host candidates by matching them against a
user-defined list of replacements.

Change-Id: I1c9541af97b83a4c690c8150d19bf7202c8bff1f

test_dlinklists doesn't need to NOTICE everyone that every macro worked.

res_phoneprov doesn't need to VERBOSE everyone that a phoneprov extension or
provider was registered.

res_odbc was missing a newline at the end of one message.

Change-Id: I6c06361518ef3711821795e535acd439782a995e

A regression was introduced where searching for realtime PJSIP objects
by regex by starting the regex with a leading "^" would cause no items
to be returned.

This was due to a change which attempted to drop the requirement for a
leading "^" to be present due to how some CLI commands formulate their
regexes. However, the change, rather than simply eliminating the
requirement, caused any regexes that did begin with "^" to end up not
returning the expected results.

This change fixes the problem by inspecting the regex and formulating
the realtime query differently depending on if it begins with "^".

ASTERISK-25702 #close
Reported by Nic Colledge

Patches:
    realtime_retrieve_regex.patch submitted by Alexei Gradinari License #5691

Change-Id: I055df608a6e6a10732044fa737a9fe8dca602693

The module res_xmpp does not accept usernames in the form used in component
mode (XEP-0114). In component mode there is no @something in the name.
In component mode the connection is now not dropped anymore.

If the xmpp server sends out a "stream" tag before handshake is finished,
the connection gets dropped in res_xmpp. Now this tag will be ignored and
the connection will be established.

After connecting there will be an exchange of presence states. This does
not work as expected in component mode. The responsible function
"xmpp_pak_presence" is left before the states get sent out. Sending
presence states in component mode is now moved to the top of the function.

ASTERISK-25735 #close

Change-Id: I70e036f931c3124ebb2ad1e56f93ed35cfdd9d5c

Fix some warnings found with clang.

Change-Id: I5195b6189b148c2ee3ed4a19d015a6d4ef3e77bd