The ao2_global_obj_release() function holds an exclusive lock on the
global object while it is being dereferenced. Any destructors that
run during this time that call ao2_global_obj_ref() will deadlock
because a read lock is required.

Instead, we make the global object inaccessible inside of the write
lock and only dereference it once we have released the lock. This
allows the affected destructors to fail gracefully.

While this doesn't completely solve the referenced issue (the error
message about not being able to create an IQ continues to be shown)
it does solve the backtrace spew that accompanied it.

ASTERISK-21009 #close
Reported by: Marcello Ceschia

Change-Id: Idf40ae136b5070dba22cb576ea8414fbc9939385

ast_cel_alloc and ast_cel_destroy do not exist in code, remove them from
the headers.

Change-Id: I99ce848e2e109e7d61771559f559b9e57973e45c

PQEscapeStringConn() expects the buffer passed in to be an
adequitely sized buffer to write out the escaped SQL value string
into.  It is possible, for large values (such as large values to
Dial with a lot of devices) to have more than our 512+1 byte
allocation and thus cause libpq to create a buffer overrun.

glibc will nicely ABRT asterisk for you, citing a stack smash.

Let's only allocate it to be as large as needed:
If we have a value, then (strlen(value) * 2) + 1 (as recommended
by libpq), and if we have none, just one byte to hold our null
will do.

ASTERISK-26896 #close

Change-Id: If611c734292618ed68dde17816d09dd16667dea2

ASTERISK-25490 #close

Change-Id: I1c5fc0942c33c96d62b24203aad0f1e1a1a0131f

Two new parameters have been added to the pjsip config wizard.

 * Setting 'sends_line_with_registrations' to true will cause the wizard
   to skip the creation of an identify object to match incoming request
   to the endpoint and instead add the line and endpoint parameters to
   the outbound registration object.

 * Setting 'outbound_proxy' is a shortcut for adding individual
   endpoint/outbound_proxy, aor/outbound_proxy and
   registration/outbound_proxy parameters.

Change-Id: I678e5f80765734c056620528a6d40d82736ceeb0
(cherry picked from commit a827892f)
(cherry picked from commit 27344675)

Change-Id: I744c986da4a38aeff8c00837eb89de7841fbc86c

Change-Id: Ib32612cf6c7ce9213a11b9cba82f630f8cd3564b

This change removes the old epoll support which has not been used or
maintained in quite some time.

The fixed number of file descriptors on a channel has also been removed.
File descriptors are now contained in a growable vector. This can be
used like before by specifying a specific position to store a file
descriptor at or using a new API call, ast_channel_fd_add, which adds
a file descriptor to the channel and returns its position.

Tests have been added which cover the growing behavior of the vector
and the new API call.

ASTERISK-26885

Change-Id: I1a754b506c009b83dfdeeb08c2d2815db30ef928

ASTERISK-26086 #close
Reported by: Jens Bürger

Change-Id: I6aab666c0bf01fd0c64d7a5bcb22fa7f5d41335e

This has not worked for some time and is no longer actively maintained.

Change-Id: I5110b0db69c152761b58fa025cb0a53b0e544d99

There doesn't appear to be any reason that we are chdir'ing in
moh_scan_files, and in the event of an Asterisk crash, the core files
may not get written because we have changed into a read-only directory.

ASTERISK-23996 #close
Reported by: Walter Doekes

Change-Id: Iac806dce01b3335963fbd62d4b4da9a65c614354

If a read error occurs, we immediately attempt a reconnect without any
delay. Instead, let's sleep and backoff up to 60 seconds before we try
again.

ASTERISK-24712 #close
Reported by: Matthias Urlichs

Change-Id: I6fe10ef4734837727437beab715e336777f13f48

chan_sip sets the hangup cause code to AST_CAUSE_REQUESTED_CHAN_UNAVAIL
(44) when a channel is hung up due to an RTP timeout. So do the same
when it happens with PJSIP for parity.

Change-Id: I3546ebbde6460c22a27c9da1bf321711b5961ab8

Updated the AMI version for the following reason (see CHANGES for more details):

The 'PJSIPShowEndpoint' command's response event of 'IdentifyDetail' now
contains a new optional parameter, 'MatchHeader'.

Change-Id: Ie206913ef1dcfa6a2ebe3282da2387e52d6f05b9

After configuring Asterisk with '--with-pjproject-bundled' the configure/build
process attempts to download pjproject from its download site. Currently, a
timeout of 10 seconds is used that will stop the download process if pjproject
has not been fully downloaded in that time. For some systems this was not enough
time and the process was timing out too early.

This patch raises the download timeout value to '60'. Also, this patch fixes
another bug where the DOWNLOAD_TIMEOUT variable was not being properly exported
due to a naming error. DOWNLOAD_MAX_TIMEOUT is now properly renamed to
DOWNLOAD_TIMEOUT.

ASTERISK-26814 #close

Change-Id: Ia56e4e8a3d39db76bc8a1852b2cf07ec10b39842

The documentation for JABBER_STATUS (and the deprecated JabberStatus
app) indicate that a return value of 7 indicates that the specified
buddy was not in the roster. It also indicates that you can specify a
"bare" JID (one without a resource). Unfortunately the actual behavior
does not match the documented behavior.

Assuming that our roster includes the buddy online and available
"valid@example.org/Valid" and does *not* include the buddy
"invalid@example.org", the JABBER_STATUS() function returns the
following before this patch:

+------------------------------+------------+--------------------------+
| Buddy                        | Status     | Result                   |
+------------------------------+------------+--------------------------+
| valid@example.org            |  Online    |  7 (Not in roster)       |
| valid@example.org/Valid      |  Online    |  1 (Online)              |
| valid@example.org/Invalid    |  N/A       |  7 (Not in roster)       |
| invalid@example.org          |  N/A       |  Error logged, no return |
| invalid@example.org/Valid    |  N/A       |  Error logged, no return |
+------------------------------+------------+--------------------------+

And after this patch:

+------------------------------+------------+--------------------------+
| Buddy                        | Status     | Result                   |
+------------------------------+------------+--------------------------+
| valid@example.org            |  Online    |  1 (Online)              |
| valid@example.org/Valid      |  Online    |  1 (Online)              |
| valid@example.org/Invalid    |  N/A       |  6 (Offline)             |
| invalid@example.org          |  N/A       |  7 (Not in roster)       |
| invalid@example.org/Valid    |  N/A       |  7 (Not in roster)       |
+------------------------------+------------+--------------------------+

This brings the behavior in line with the documentation.

ASTERISK-23510 #close
Reported by: Anthony Critelli

Change-Id: I9c3241035363ef4a6bdc21fabfd8ffcd9ec657bf

If any errors occur during the TLS connection setup, we currently dump a
fairly generic error message. So instead we try to pull in something
useful from OpenSSL to report instead.

ASTERISK-24712
Reported by: Matthias Urlichs

Change-Id: I288500991a9681f447d92913b11fedaf426087f4

The only remaining reference to the endpoint is in the endpoints
container, and because it is unlinked in ast_endpoint_shutdown, we don't
have to explicitly cleanup the endpoint ourselves.

Change-Id: I912a2692e52d3e2ed445b32d8ae3f9004bc2f2e8

SSL_connect returns non-zero for both success and some error conditions
so simply negating is inadequate.

Change-Id: Ifbf882896e598703b6c615407fa456d3199f95b1