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

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

The sending codec is switched to the receiving codec and then
is switched back to the best native codec on EVERY receiving RTP packets.
This is because after call of ast_channel_set_rawwriteformat there is call
of ast_set_write_format which calls set_format which sets rawwriteformat
to the best native format.

This patch adds a new function ast_set_write_format_path which set
specific write path on channel and uses this function to switch
the sending codec.

ASTERISK-26603 #close

Change-Id: I5b7d098f8b254ce8f45546e6c36e5d324737f71d

Issue/patch ASTERISK-26587 was inspired by issue ASTERISK-22992
that requested ability to add callerid into app_originate.
Comments in that issue suggested that it was better solved by
adding an option to gosub prior to originating the call.  The
attached patch implements this much like app_dial with two
options one to gosub on the originating channel and one to gosub
on the newly created channel and behaves just like app_dial.
I have tested this patch by adding callerid info to the new
channel and also SIPAddHeader (to e.g. add header to force auto
answer) and confirmed it works.  Have also tested both 'exten'
and 'app' versions of app_originate.

Opened by: dkerr
Patch by: dkerr

Change-Id: I36abc39b58567ffcab4a636ea196ef48be234c57

The response from gmail calendar includes the string name
"caldav:calendar-data". res_calendar_caldav implements
the example included in RFC 4791: string "C:calendar-data".
When reading the calendar, res_calendar_caldav compare the
string and if does not match just discards the event.
This commit compares the response to both strings,
successfully loading gmail calendar events.
Writing to gmail calendar is working prior to this fix.

ASTERISK-26624
Reported by: Eduardo S. Libardi

Change-Id: Ia1eef10552ae616efb645d390f5ffe81260d7d4a

Tabs > Spaces.

Change-Id: If1e43a71822615a898e958e0f8b2e882606f0bd0

Per RFC 7118 5.2, the SIP URI 'transport' parameter should advertise
'ws' when WebSockets are to be used as the transport. This applies to
both secure and insecure WebSockets.

There were two bugs in Asterisk with respect to this:

(1) The most egregious occurs in res_pjsip. There, we advertise 'ws' for
    insecure websockets and 'wss' for secure websockets. While this
    would seem to make sense - since 'WS' and 'WSS' are used for the Via
    Transport parameter - this is not the case for the SIP URI. This
    patch corrects that by registering the secure websockets with
    pjproject using the shorthand 'WS', and by returning 'ws' when asked
    for the transport parameter. Note that in pjproject, it is perfectly
    valid to have multiple transports use the same shorthand.

(2) In chan_sip, we return an upper-case version of the transport 'WS'
    instead of 'ws'. Since we should be strict in what we send and
    liberal in what we accept (within reason), this patch lower-cases
    the transport before appending it to the parameter.

ASTERISK-24330 #close
Reported by: cervajs, Inaki Baz Castillo

Change-Id: Iff77b645f8cc3b7cd35168a6676c26b147f22f42

download_externals wasn't handling the "certified/13.x" version
correctly.

Change-Id: I124d195bb117ca36fd7bf1150c630f3b474a9d9a

The asterisk.h header file needs to be included first or else
some things go awry, such as:

implicit declaration of function 'vasprintf'

Change-Id: I981dc2a77a1ba791888e4f1726644d4656c0407c

If a TCP/TLS connection was pending (not accepted and not timed out) during
unload of chan_sip, Asterisk would segfault when trying to send a signal to
a thread whose thread ID hadn't been recorded yet. This commit fixes that by
recording the thread ID before calling the blocking connect() syscall.
This was a regression introduced by 776a1438.

The above wasn't enough to fix the segfault, which was now delayed to the
point where connect() timed out. Therefore, it was necessary to also remove
the SA_RESTART flag from the SIGURG sigaction so that pthread_kill() could be
used to interruput the connect() syscall.
This was a regression introduced by 5d313f51.

ASTERISK-26586 #close

Change-Id: I76fd9d47d56e4264e2629bce8ec15fecba673e7b

Switched from AST_MODULE_LOAD_DECLINE to AST_MODULE_LOAD_FAILURE.
Therefore, if pbx_lua fails to load and pbx_lua is marked as required,
Asterisk exits as expected.
If extensions.lua cannot be opened, AST_MODULE_LOAD_DECLINE is reported.

Change-Id: I8e5a0037e69b41743db60c568541ebb2f52a7a8f

When retrieving RTCP stats for PJSIP channels, RTT values are unreliable.
RTT calculation is correct, but the data representation isn't.  RTT is
represented by a 32-bit fixed-point number with the integer part in the
first 16 bits and the fractional part in the last 16 bits.  In order to
get the RTT value, the fractional part is miscalculated, there is an
unnecessary 16 bit shift that causes overflow.  Besides this there is
another mistake, when transforming the integer value to the fixed point
fractional part via bitwise operation, that loses precision.

* RTT fractional part is no longer shifted, avoiding overflow.

* RTT fractional part is transformed to its fixed-point value more
precisely.

* Fixed timeval2ntp() and ntp2timeval() second fraction conversions.

* Fixed NTP timestamp report logging.  The usec was inexplicably
multiplied by 4096.

ASTERISK-26566 #close
Reported by Hector Royo Concepcion

Change-Id: Ie09bdabfee75afb3f1b8ddfd963e5219ada3b96f

Previously, a TLS server socket would only be restarted upon sip reload if the
bind address had changed. This commit adds checking for changes to TLS
parameters like certificate, ciphers, etc. so they get picked up without
requiring a reload of the entire chan_sip module. This does not affect open
connections in any way, but new connections will use the new TLS parameters.
The changes also apply to HTTP and Manager.

ASTERISK-26604 #close

Change-Id: I169e86cefc6dcd627c915134015a6a1ab1aadbe6

libasteriskpj was hard coded to use -lrt but librt is linux specific
so we now use the LIB_RT variable which gets set by configure.

Change-Id: I41148884517e3031f7675a413d524c86e8614694