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

Users of functions which call __ast_str_helper() such as the ones listed
below are likely to not check the return value for failure so ensuring
that the string is always nil terminated is a good safety measure.

ast_str_set_va()
ast_str_append_va()
ast_str_set()
ast_str_append()

Change-Id: I36ab2d14bb6015868b49329dda8639d70fbcae07

Change-Id: I0c2cdcd53727bdc6634095c61294807255bd278f

In a realtime based system with a limited number of threadpool threads
it is possible for a deadlock to occur. This happens when permanent
endpoint state is updated, which will cause database queries to be done.
These queries may result in URI validation being done which is done
synchronously using a PJSIP thread. If all PJSIP threads are in use
processing traffic they themselves may be blocked waiting to get the
permanent endpoint container lock when identifying an endpoint.

This change moves URI validation to occur at use time instead of
configuration time. While this comes at a cost of not seeing a problem
until you use it it does solve the underlying deadlock problem.

ASTERISK-25486 #close

Change-Id: I2d7d167af987d23b3e8199e4a68f3359eba4c76a

With Asterisk 13, the structures ast_format and ast_codec changed. Because of
that, the paketization timing (framing) of the RTP channel moved away from the
formats/codecs. In the course of that change, the ptime of the callee was not
honored anymore, when the optional autoframing was enabled.

ASTERISK-25484 #close

Change-Id: Ic600ccaa125e705922f89c72212c698215d239b4

Error response code descriptions may contain wiki markup that need to be
escaped. Without this patch, Confluence will reject the document being sent
and the responsible script will raise an exception.

Change-Id: I21fcb66fee7f6332381f2b99b1b0195dff215ee5

When ab803ec3 was committed, it accidentally forgot to actually *add* the
HOLD_INTERCEPT function. This highlights two interesting points:
* Gerrit forces you to put the patch as it is going to into the repo up for
  review, which Review Board did not. Yay Gerrit.
* No one apparently bothered to use this feature, or else they don't know about
  it. I'm going to go with the latter explanation.

ASTERISK-24922

Change-Id: Ida38278f259dd07c334a36f9b7d5475b5db72396

This patch adds the functions

	ast_cdr_modifier_register()
	ast_cdr_modifier_unregister()

That work much like ast_cdr_register() and ast_cdr_unregister().

Modules registered will be given a chance to modify (or to do whatever
they want) CDR fields just before they are passed to registered engines.

Thus, for instance, if a module change the "userfield" field of a CDR,
the modified value will be passed to every registered CDR backend for
logging.

ASTERISK-25479 #close

Change-Id: If11d8fd19ef89b1a66ecacf1201e10fcf86ccd56

This patch adds some minor tweaks for autosupport to update it for Asterisk 13.
This includes:
* Finally removing most references to Zaptel
* Adding support for some additional 'core' commands, and fixing nomenclature
  that generally hasn't been used for some time
* Adding some PJSIP/SIP commands to gather endpoints/peers and active channels

Change-Id: Ic997b418cbd9313588b6608e50f47b0ce6f4f1f1
(cherry picked from commit 9fc9777f)

ASTERISK-25308 fixed a memory leak in res_ari_events.c, but
this file is regenerated by a template and the template was
not fixed.

Change-Id: Ied4c6deae89d21f87f9cf99676b1d055aa83b38b

* changes:
  config.c: Fix off-nominal memory leak.
  config.c: Fix potential memory corruption after [section](+).
  config.c: Fix #include after [section](+).

On v13, loading several thousand PJSIP endpoints on Asterisk start causes
a deadlock most of the time.

Thanks to mdu113 for discovering that there was a call to pgsql_exec() not
protected by the pgsql_lock reentrancy lock.

{quote}
I believe a code path exists that attempts to use pgsql connection without
locking pgsql_lock.  I believe what happens during that deadlock that I
see is two concurrent threads are both attempting to send query to pgsql,
one of the thread is using a code path without locking pgsql_lock.  If
they managed to send queries at the same time, it seems postgres ignores
one of the queries and replies only to the one of them.  If it happens so
that the thread holding the lock didn't receive the reply it will wait for
it (and hold the lock) forever (or at least for very long time), thus
completely blocking all access to db.
{quote}

* Added missing reentrancy locking around pgsql_exec() in find_table().

* Moved unlock of pgsql_lock in unload_module() to avoid locking inversion
between the psql_tables list lock and the pgsql_lock.

ASTERISK-25455 #close
Reported by:  mdu113
Patches:
      res_config_pgsql.c-connlock2.diff (license #5543) patch uploaded by mdu113

Change-Id: Id9e7cdf8a3b65ff19964b0cf942ace567938c4e2

To quote Olle:

"When issuing a hangup due to RTP timeouts the cause code is not set. I have
selected 44 based on Cisco's implementation..."

ASTERISK-25135 #close
Reported by: Olle Johansson
patches:
  rtp-timeout-cause-1.8.diff uploaded by Olle Johansson (License 5267)

Change-Id: Ia62100c55077d77901caee0bcae299f8dc7375fc

Change-Id: I06e346e9a5c63cc5071e7eda537310c4b43bffe0

The memory corruption could happen if the [section](+) is the last section
in the file with trailing comments.  In this case process_text_line() has
left *last_cat is set to newcat and newcat is destroyed.

Change-Id: I0d1d999f553986f591becd000e7cc6ddfb978d93

An #include right after a [section](+) would associate any variable
assignments before a new section in the #include with the wrong section.

* Fix section association by setting the current section to the appended
section.

* Fix '+' and '!' section flag interaction corner case depending upon
which flag came first.  If the '!' came first then it would be ignored.
If the '!' came after then it would affect the appended section.  The '!'
will now no longer be ignored.

ASTERISK-25461 #close
Reported by: Sean Pimental

Change-Id: Ic9d3191c8758048e2cbce6432f854b32531731c3

This patch adds menuselect options for building Asterisk with
various sanitizers provided by gcc and clang.

When one of *SANITIZER flags is set in menuselect, the appropriate
option is added to CFLAGS ad LDFLAGS for the build.

Information on sanitizers in the project wiki:
https://github.com/google/sanitizers/wiki

GCC Manual:
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

Clang Compiler User's Manual:
http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation

ASTERISK-24718 #close
Reported by: Badalian Vyacheslav

Change-Id: Iafa51b792b7bcb20e848b99d16cf362d08590fa0

Versions of libunbound before v1.4.21 do not compile with Asterisk.
However, since v1.4.21 has a configure script bug that fails to detect the
ldns library (which is fixed in v1.4.22) and v1.4.22 is not an easily
detectable version we will require v1.5.0 as a minimum version of the
library to work with Asterisk.

ASTERISK-25108 #close
Reported by: Richard Mudgett

Change-Id: Ieb228bfb01467573fc121c7356a9dde27128894d

Wrote the skeleton framework for the Asterisk StatsD dialplan
application. This includes a load function, unload function, a
callback for execution, and XML documentation.

ASTERISK-25419
Reported By: Ashley Sanders

Change-Id: I9597730e134c6e82c8a55ef4d5334b62dd473363

The struct send_request_wrapper has a pjsip lock associated with it that
is created non-recursive.  There is a code path for the struct
send_request_wrapper lock that will attempt to lock it recursively.  The
reporter's deadlock showed that the thread calling endpt_send_request()
deadlocked itself right after the wrapper object got created.

Out-of-dialog requests such as MESSAGE, qualify OPTIONS, and unsolicited
MWI NOTIFY messages can hit this deadlock.

* Replaced the struct send_request_wrapper pjsip lock with the mutex lock
that can come with an ao2 object since all of Asterisk's mutexes are
recursive.  Benefits include removal of code maintaining the pjsip
non-recursive lock since ao2 objects already know how to maintain their
own lock and the lock will show up in the CLI "core show locks" output.

ASTERISK-25435 #close
Reported by: Dmitriy Serov

Change-Id: I458e131dd1b9816f9e963f796c54136e9e84322d

In ast_rtp_read, the value of the variable 'mark' which we try to assign to a
frame->subclass.frame_ending may be 0, 1 or (1<<23), but we should translate
it to 0 or 1.

ASTERISK-25451 #close
Change-Id: I53bdf5c026041730184a6a809009c028549ce626

Return AST_PRESENCE_NOT_SET when CustomPresence AstDB key does not
exist, i.e. when a new CustomPresence is added in the dialplan.

ASTERISK-25400 #close
Reported by: Andrew Nagy

Change-Id: I6fb17b16591b5a55fbffe96f3994ec26b1b1723a

When we decide we will no longer schedule an RTCP write, we remove the
reference to the RTP instance, then assign -1 to the stored scheduler ID
in case something else comes along and wants to see if anything is scheduled.

That scheduler ID is on the RTP instance. After 60a9172d was merged to
fix the regression introduced by 3cf0f293, this improper assignment on a
potentially destroyed object started getting tripped on the build agents.

Frankly, this should have been crashing a lot more often earlier. I can only
assume that the timing was changed just enough by both changes to start
actually hitting this problem.

As it is, simply moving the assignment prior to the ao2 deference is sufficient
to keep the RTP instance from being referenced when it is very, truly,
aboslutely dead.

(Note that it is still good practice to assign -1 to the scheduler ID when we
know we won't be scheduling it again, as the ao2 deref *may* not always destroy
the ao2 object.)

ASTERISK-25449

Change-Id: Ie6d3cb4adc7b1a6c078b1c38c19fc84cf787cda7

If a Via header containes an IPv6 address and a port number is ommitted,
as it is the standard port, we now leave the port empty and to not set it
to the value after the first colon of the IPv6 address.

ASTERISK-25443 #close

Change-Id: Ie3c2f05471cd006bf04ed15598589c09577b1e70

Apparently some endpoints attempt to send a reINVITE before completing the
initial INVITE transaction.  In this case PJSIP responds appropriately to
the reINVITE with a 491 INVITE request pending.  Unfortunately chan_pjsip
is using the initial INVITE transaction state to determine if an INVITE is
the initial INVITE or a reINVITE.  Since the initial INVITE transaction
has not been confirmed yet chan_pjsip thinks the reINVITE is an initial
INVITE and starts another PBX thread on the channel.  The extra PBX thread
ensures that hilarity ensues.

* Fix checks for a reINVITE on incoming requests to look for the presence
of a to-tag instead of the initial INVITE transaction state.

* Made caller_id_incoming_request() determine what to do if there is a
channel on the session or not.  After a channel is created it is too late
to just store the new party id on the session because the session's party
id has already been copied to the channel's caller id.

ASTERISK-25404 #close
Reported by: Chet Stevens

Change-Id: Ie78201c304a2b13226f3a4ce59908beecc2c68be