If a tarball is corrupted during download, the makefile will attempt to
download it again. If the tarball somehow gets corrupted after it's
downloaded however, the makefile was just failing.  We now
retry the download.

ASTERISK-26653 #close

Change-Id: I1b24d454852d80186f60c5a65dc4624ea8a1c359

The conditional expressions of the 'if' operators
situated alongside each other are identical.

Change-Id: I652b6dcddb3be007e669a6aa8107edb31a1ddafb

Consider reviewing the expression of the 'A = B != C' kind.
The expression is calculated as following: 'A = (B != C)'

Change-Id: Ibaa637dfda47d51a20e26069d3103e05ce80003d

P is always true. We check it before

Change-Id: Iee61cda002a9f61aee26b9f66c5f9b59e3389efb

The conditional expressions of the 'if' operators situated
alongside each other are identical.

Change-Id: I2cf7c317b106ec14440c7f1b5dcfbf03639f748a

Expression 'rlen < 0' is always false.
Unsigned type value is never < 0.

Change-Id: Id9f393ff25b009a6c4a6e40b95f561a9369e4585

RFC says SIP headers look like:

    HCOLON  =  *( SP / HTAB ) ":" SWS
    SWS     =  [LWS]                    ; sep whitespace
    LWS     =  [*WSP CRLF] 1*WSP        ; linear whitespace
    WSP     =  SP / HTAB                ; from rfc2234

chan_sip implemented this:

    HCOLON  =  *( LOWCTL / SP ) ":" SWS
    LOWCTL  = %x00-1F                   ; CTL without DEL

This discrepancy meant that SIP proxies in front of Asterisk with
chan_sip could pass on unknown headers with \x00-\x1F in them, which
would be treated by Asterisk as a different (known) header.  For
example, the "To\x01:" header would gladly be forwarded by some proxies
as irrelevant, but chan_sip would treat it as the relevant "To:" header.

Those relying on a SIP proxy to scrub certain headers could mistakenly
get unexpected and unvalidated data fed to Asterisk.

This change fixes so chan_sip only considers SP/HTAB as valid tokens
before the colon, making it agree on the headers with other speakers of
SIP.

ASTERISK-26433 #close
AST-2016-009

Change-Id: I78086fbc524ac733b8f7f78cb423c91075fd489b

When an opus offer or answer was received that contained an
fmtp line with spaces between the attributes the module would
fail to properly parse it and crash due to recursion.

This change makes the module handle the space properly and
also removes the recursion requirement.

ASTERISK-26579

Change-Id: I01f53e5d9fa9f1925a7365f8d25071b5b3ac2dc3

The PJSIPShowRegistrationsInbound AMI command was just dumping out
all AORs which was pretty useless and resource heavy since it had
to get all endpoints, then all aors for each endpoint, then all
contacts for each aor.

PJSIPShowRegistrationInboundContactStatuses sends ContactStatusDetail
events which meets the intended purpose of the other command and has
significantly less overhead.  Also, some additional fields that were
added to Contact since the original creation of the ContactStatusDetail
event have been added to the end of the event.

For compatibility purposes, PJSIPShowRegistrationsInbound is left
intact.

ASTERISK-26644 #close

Change-Id: I326f12c9ecb52bf37ba03f0748749de4da01490a

Fix the tests for DNS to use older style nameser.h as
in ASTERISK-26608.

Tested on: OpenBSD 6.0, Debian 8

ASTERISK-26647 #close

Change-Id: I285913c44202537c04b3ed09c015efa6e5f9052d

Occasionally SIP message transactions are not found when they should be.
In the particular case an incoming INVITE transaction is CANCELed but the
INVITE transaction cannot be found so a 481 response is returned for the
CANCEL.  The problematic calls have a '_' character in the Via branch
parameter.

The problem is in the pjproject PJ_HASH_USE_OWN_TOLOWER feature's code.
The problem with the "own tolower" code is that it does not calculate the
same hash value as when the pj_tolower() function is used.  The "own
tolower" code will erroneously modify the ASCII characters '@', '[', '\\',
']', '^', and '_'.  Calls to pj_hash_calc_tolower() can use the
PJ_HASH_USE_OWN_TOLOWER substitute algorithm when enabled.  Calls to
pj_hash_get_lower(), pj_hash_set_lower(), and pj_hash_set_np_lower() call
find_entry() which never uses the PJ_HASH_USE_OWN_TOLOWER algorithm.  As a
result you may not be able to find a hash tabled entry because the
calculated hash values would differ.

* Simply disable PJ_HASH_USE_OWN_TOLOWER.

ASTERISK-26490 #close

Change-Id: If89bfdb5f301b8b685881a9a2a6e0c3c5af32253

This is a semi-regression caused by the iostreams change. Prior to
iostreams, HTTP headers were written to a FILE handle using fprintf.
Then the body was written using a call to fwrite(). Because of internal
buffering, the result was that the HTTP headers and body would be sent
out in a single write to the socket.

With the change to iostreams, the HTTP headers are written using
ast_iostream_printf(), which under the hood calls write(). The HTTP body
calls ast_iostream_write(), which also calls write() under the hood.
This results in two separate writes to the socket.

Most HTTP client libraries out there will handle this change just fine.
However, a few of our testsuite tests started failing because of the
change. As a result, in order to reduce frustration for users, this
change alters the HTTP code to write the headers and body in a single
write operation.

ASTERISK-26629 #close
Reported by Joshua Colp

Change-Id: Idc2d2fb3d9b3db14b8631a1e302244fa18b0e518

ast_iostream_printf() attempts first to use a fixed-size buffer to
perform its printf-like operation. If the fixed-size buffer is too
small, then a heap allocation is used instead. The heap allocation in
this case was exactly the length of the string to print. The issue here
is that the ensuing call to vsnprintf() will print a NULL byte in the
final space of the string. This meant that the final character was being
chopped off the string and replaced with a NULL byte. For HTTP in
particular, this caused problems because HTTP publishes the expected
Contact-Length. This meant HTTP was publishing a length one character
larger than what was actually present in the message.

This patch corrects the issue by adding one to the allocation length.

ASTERISK-26629
Reported by Joshua Colp

Change-Id: Ib3c5f41e96833d0415cf000656ac368168add639

Added back in a -g3, and an -O3 when DONT_OPTIMIZE is not set, to
the CFLAGS.  Not sure how they went missing.

Also fixed an uninstall problem where we weren't removing the
symlink from libasteriskpj.so.2 to libasteriskpj.so.  While I was
there, I fixed it for libasteriskssl as well.

Change-Id: I9e00873b1e9082d05b5549d974534b48a2142556

Increasing the testsuite shutdown timeout before forcibly killing
Asterisk allowed more events to be sent out.  Some tests failed as
a result.  The tests/channels/pjsip/statsd/registrations failed
because we now get the statsd events that a comment in the test
configuration stated couldn't be intercepted.  Unfortunately, we
get a variable number of events because of internal status state
transition races generating redundant statsd events.

We were reporting redundant statsd PJSIP.registrations.state changes
for internal state changes that equated to the same thing publicly.

* Made update_client_state_status() filter out redundant statsd
updates.

ASTERISK-26527

Change-Id: If851c7d514bb530d9226e4941ba97dcf52000646

OpenSSL 1.1.0 includes some major changes in the interface. See
https://wiki.openssl.org/index.php/1.1_API_Changes .

Status: Right now there are still a few deprecation notes with OpenSSL
1.1.0. But it's a start.

Changes:
* CRYPTO_LOCK is no longer available. Replace it with its value for now.
  I don't completely understand what it is used for there.
* Remove several functions from libasteriskssl that seem to no longer be
  needed.
* Structures have become opaque and are accesses with accessors.
* ERR_remove_thread_state() no longer needed.
* SSLv2 code now could no longer be used in 1.1.

ASTERISK-26109 #close

Change-Id: I5e29d477d486ca29b6aae0dc2f5dff960c1cb82b

The latest Release candidate fails to create RTP streams when IPv6
is not available. Due to the changes made in September the ast_sockaddr
structure passed around to create these streams is always of AF_INET6
type, causing failure when used for IPv4. This patch adds a utility
function to check for availability of IPv6 and applies such check
at startup to determine how to create the ast_sockaddr structures.

ASTERISK-26617 #close

Change-Id: I627a4e91795e821111e1cda523f083a40d0e0c3e

Use of the new logging is as simple as issuing the new CLI command or
setting the new pjproject.conf option.

Other options that can affect the logging are how you have the pjproject
log levels mapped to Asterisk log types in pjproject.conf and if you have
configured Asterisk to log the DEBUG type messages.  Altering the
pjproject.conf level mapping shouldn't be necessary for most installations
as the default mapping is sensible.  Configuring Asterisk to log the DEBUG
message type is standard practice for collecting debug information.

* Added CLI "pjproject set log level" command to dynamically adjust the
maximum pjproject log message level.

* Added CLI "pjproject show log level" command to see the currently set
maximum pjproject log message level.

* Added pjproject.conf startup section "log_level" option to set the
initial maximum pjproject log message level so all messages could be
captured from initialization.

* Set PJ_LOG_MAX_LEVEL to 6 to compile in all defined logging levels into
bundled pjproject.  Pjproject will use the currently set run time log
level to determine if a log message is generated just like Asterisk
verbose and debug logging levels.

* In log_forwarder(), made always log enabled and mapped pjproject log
messages.  DEBUG mapped log messages are no longer gated by the current
Asterisk debug logging level.

* Removed RAII_VAR() from res_pjproject.c:get_log_level().

ASTERISK-26630 #close

Change-Id: I6dca12979f482ffb0450aaf58db0fe0f6d2e5389

The recent change that made frame deferral into an API had a behavior
change to it. When frame deferral was completed, we would take all of
the deferred frames and queue them all onto the channel in one call to
ast_queue_frame_head(). Before frame deferral was API-ized, places that
performed manual frame deferral would actually take each deferred frame
and queue them onto the channel.

This change in behavior caused the confbridge_recording test to start
failing consistently. Without going too crazily deep into the details,
a channel was getting "stuck" in an ast_safe_sleep(). An AMI redirect
was attempting to break it out of the sleep, but because there were more
frames in the channel read queue than expected, the channel ended up
being unable to break from its sleep loop.

By restoring the behavior of individual frame queuing after deferral,
the test starts passing again.

Note, this points to a potential underlying issue pointing to an
"unbalance" that can occur when queuing multiple frames at once,
and so a follow-up issue is being created to investigate that
possibility.

Change-Id: Ied5dacacda06d343dea751ed5814a03364fe5a7d