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

Fix some warnings found with clang.

Change-Id: I5195b6189b148c2ee3ed4a19d015a6d4ef3e77bd

A recent commit set qualify_timeout to Decimal which isn't supported.
This path corrects it to Float.

Change-Id: I038f5274ba8cb60f8518a5845ce448d49306aadf

When I ask asterisk to send a SIP NOTIFY message to a sip peer using either a)
AMI action: SIPnotify or b) cli command: sip notify <cmd> <peer>, I expect
asterisk to include the same value for its own ip in both cases a) and b),
but it seems a) produces a contact header like Contact:
<sip:asterisk@192.168.1.227:8060> whereas b) produces a contact header like
<sip:asterisk@127.0.0.1:8060>. 0.0.0.0:8060 is my udpbindaddr in sip.conf

My guess is that manager_sipnotify should call
ast_sip_ouraddrfor(&p->sa, &p->ourip, p) the same way sip_cli_notify does,
because after applying this patch, both cases a) and b) produce
the contact header that I expect: <sip:asterisk@192.168.1.227:8060>

Reported by: Stefan Engström
Tested by: Stefan Engström

Change-Id: I86af5e209db64aab82c25417de6c768fb645f476

Change-Id: I915ea437936320393afde0e7552cf0a980a6b2e4

Since res_pjsip now depends on res_pjproject, this has been added to
basic-pbx modules.conf.

Change-Id: I42826597d5e10f08e518208860c44c96e52f1b2d

The Makefile only optionally includes makeopts so when goals like uninstall that
dont depend on anything else are run after a distclean, rules like
'rm -f "$(DESTDIR)$(ASTMODDIR)/"*' get run as 'rm -f ""/*' which attempts
to remove everything in the root directory.

Although there's a rule defined for makeopts which prints a message and does
an 'exit 1', since '-include makepopts' was specified (with the -), the exit
was ignored letting the rest of the rules run.

This patch makes makeopts required unless the goal has the string 'clean' in it.

ASTERISK-25730 #close
Reported-by: George Joseph

Change-Id: I1bce59a7ea4f48e7a468e22b2abbb13c63417ac7

The config options framework is strict in that configuration options must
be documented unless XML documentation support is not available. In
practice this is useful as it ensures documentation exists however in
off-nominal cases this can cause strange problems.

If it is expected that a config option has a non-zero or non-empty
default value but the config option documentation is unavailable
this reasonable expectation will not be met. This can cause obscure
crashes and weirdness depending on how the code handles it.

This change tweaks the behavior to ensure that the config option
is still allowed to register, apply default values, and be set when
devmode is not enabled. If devmode is enabled then the option can
NOT be set.

This also does not remove the initial documentation error message that
is output on load when registering the configuration option.

ASTERISK-25725 #close

Change-Id: Iec42fca6b35f31326c33fcdc25473f6fd7bc8af8

A recent change to queue channel variable setting to the Stasis control
queue caused a regression. When setting channel variables, it is
possible to give a NULL channel variable value in order to unset the
variable (i.e. remove it from the channel variable list). The change
introduced a call to ast_variable_new(), which is not tolerant of NULL
channel variable values.

This new change switches from using ast_variable to using a custom
channel variable struct that is lighter weight and NULL value-tolerant.

Change-Id: I784d7beaaa3c036ea936d103e7caf0bb1562162d

Core and extra sounds 1.5 was recently released! The tarballs contain
change descriptions however I figure more people will see this one so
I'll try to be a bit detailed. Approximately 60 sounds were moved from Extra
to Core for en, en_GB, fr and added for languages that didn't already
have Extra sound sets (it,ja,ru).

In addition all of the English and Russian sounds have been completely
re-recorded.

Sounds moved and added:
activated,added,all-circuits-busy-now,astcc-followed-by-pound
at-tone-time-exactly,call-forwarding,call-fwd-no-ans,call-fwd-on-busy
,call-fwd-unconditional,calling,call-waiting,cancelled,
cannot-complete-as-dialed,check-number-dial-again,conf-full,de-activated
,disabled,do-not-disturb,enabled,enter-num-blacklist,entr-num-rmv-blklist
,extension,feature-not-avail-line,for,from-unknown-caller,goodbye,hello
,if-correct-press,im-sorry,info-about-last-call,is,is-in-use,is-set-to
,location,number,number-not-answering,num-was-successfully,one-moment-please
,please-try-again,pls-hold-while-try,pls-try-call-later,pm-invalid-option
,privacy-to-blacklist-last-caller,removed,simul-call-limit-reached
,something-terribly-wrong,sorry,sorry-youre-having-problems,speed-dial
,speed-dial-empty,telephone-number,time,to-call-this-number,to-extension
,to-listen-to-it,to-rerecord-it,unidentified-no-callback,with,you-entered
,your

There were also a few random fixes here and there to file names for a few
of the languages.

ASTERISK-25068 #close

Change-Id: I2b594344ec585d7dfd922b40c1af43b1508828b3

A test recently uncovered that running an ill-timed AMI command to show
inbound subscriptions could cause a crash since Asterisk will try to
operate on a freed subscription.

The fix for this is to remove the subscription tree from the list of
subscriptions at the time that we are sending our final NOTIFY request
out. This way, as the subscription is in the process of dying, it is
inaccessible from AMI.

Change-Id: Ic0239003d8d73e04c47c12dd2a7e23867e5b5b23

sip_sipredirect uses sscanf to copy up to 256 characters to a stacked buffer
of 256 characters.  This patch reduces the copy to 255 characters to leave
room for the string null terminator.

ASTERISK-25722 #close

Change-Id: Id6c3a629a609e94153287512c59aa1923e8a03ab

Change-Id: I2734392b131f1fb0949515d538f83f30fbc15d8c

Remove repeated code on macro of assigned buffer to SQL vars.

Add table and connection name to log error message when is not possible
allocate memory.

Change-Id: I1fbf37d286a032d38fdda72a9f736356956c9ffe

When queuing tasks onto the Stasis control queue, you can pass an
arbitrary data pointer and a function to free that data. All ARI
commands that use the Stasis control queue made the assumption that the
destructor function would be called in all paths, whether the task was
queued successfully or not. However, this was not correct. If a task was
queued onto a control structure that was already completed, the
allocated data would not be freed properly.

This patch corrects this by making sure that all return paths call the
data destructor.

Change-Id: Ibf06522094f8e5c4cce652537dc5d7222b1c4fcb

A crash occurred when attempting to set a channel variable on a channel
that had already been hung up. This is because there is a small window
between when a control is grabbed and when the channel variable is set
that the channel can be hung up.

The fix here is to queue the setting of the channel variable onto the
control queue. This way, the manipulation of the channel happens in a
thread where it is safe to be done.

In this change, I also noticed that the setting of bridge roles on
channels was being done outside of the control queue, so I also changed
those operations to be done in the control queue.

ASTERISK-25709 #close
Reported by Mark Michelson

Change-Id: I2a0a4d51bce6fba6f1d9954e40935e42f366ea78

The null terminator of the tail struct member was not being allocated
when no logger.conf config file is installed.

ASTERISK-25714 #close
Reported by: Badalian Vyacheslav

Change-Id: I45770fdd08af39506a3bc33ba279c4f16e047a30

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

Change-Id: Idc2ae8a6bd869a66544916906744a5678622262d

* Add 'check-alembic' target to root Makefile.
* Create build_tools/make_check_alembic to do the actual checks.

ASTERISK-25685

Change-Id: Ibb3cae7d1202ac23dc70b0f3b5801571ad46b004

ASTERISK-25712 #close
Reported by: Richard Mudgett

Change-Id: I70634df24f8c6c3a2c66c45af61d021e4999253f

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