Products of --enable-coverage

Change-Id: Ie20882d64b60692e2c941ea8872ab82a86ce77a3

The query set documentation states that upon completion queries can be
retrieved for the lifetime of the query set. This is a reasonable
expectation but does not currently occur. This was originally done
to resolve a circular reference between queries and query sets, but
in practice the query can be kept.

This change makes it so a query does not have a reference to the
query set until it begins resolving. It also makes it so that the
reference is given up upon the query being completed. This allows
the queries to remain for the lifetime of the query set. As the
query set on the query is only useful to the query set functionality
and only for the lifetime that the query is resolving this is safe
to do.

ASTERISK-24994 #close
Reported by: Joshua Colp

Change-Id: I54e09c0cb45475896654e7835394524e816d1aa0

- When you need to refer to 'variable XXX' outside a block, it needs
to be declared as '__block XXX', otherwise it will not be available with-
in the block, making updating that variable hard to do, and ast_free
lead to issues.

- Removed the #error message
because it creates complications when compiling external projects
against asterisk For example when using a different compiler than the
one used to compile asterisk. The warning/error should be generated
during the configure process not the compilation process

ASTERISK-24917
Change-Id: I12091228090e90831bf2b498293858f46ea7a8c2

Currently the res_pjsip_mwi module only sends an unsolicited MWI NOTIFY upon
a mailbox state change (such as a new message being left, or one being deleted).
In practice this is not sufficient to keep clients aware of the current MWI status.

This change makes the module send unsolicited MWI NOTIFY on startup so that
clients are guaranteed to have the most up to date MWI information. It also makes
clients receive an unsolicited MWI NOTIFY upon registration so if they are unaware
of the current MWI status they receive it.

ASTERISK-24982 #close
Reported by: Joshua Colp

Change-Id: I043f20230227e91218f18a82c7d5bb2aa62b1d58

Fix a crash that could occur in __ast_channel_internal_alloc if
ao2_alloc fails.

ASTERISK-24991 #close

Change-Id: I4ca89189eb22f907408cb87d0a1645cfe1314a90

When SUBSCRIBE dialogs were established, we never associated
the endpoint that created the subscription with the dialog
we end up creating. In most cases, this ended up not causing
any problems.

The actual bug that was observed was that when a device that
was behind NAT established a subscription with Asterisk, Asterisk
would end up sending in-dialog NOTIFY requests to the device's
private IP addres instead of the public address of the NAT router.

When Asterisk receives the initial SUBSCRIBE from the device,
res_pjsip_nat rewrites the contact to the public address on which the
SUBSCRIBE was received. This allows for the dialog to have its target
address set to the proper public address. Asterisk then would send a 200
OK response to the SUBSCRIBE, then a NOTIFY with the initial
subscription state. The device would then send a 200 OK response to
Asterisk's NOTIFY.

Here's where things went wrong. When the 200 OK arrived, res_pjsip_nat
did not rewrite the address in the Contact header. Then, when the PJSIP
dialog layer processed the 200 OK, PJSIP would perform a comparison
between the IP address in the Contact header and its saved target
address for the dialog. Since they differed, PJSIP would update the
target dialog address to be the address in the Contact header. From this
point, if Asterisk needed to send a NOTIFY to the device, the result was
that the NOTIFY would be sent to the private address that the device
placed in the Contact header.

The reason why res_pjsip_nat did not rewrite the address when it
received the 200 OK response was that it could not associate the
incoming response with a configured endpoint. This is because on a
response, the only way to associate the response to an endpoint is by
finding the dialog that the response is associated with and then finding
the endpoint that is associated with that dialog. We do not perform
endpoint lookups on responses. res_pjsip_pubsub skipped the step of
associating the endpoint with the dialog we created, so res_pjsip_nat
could not find the associated endpoint and therefore couldn't rewrite
the contact.

This commit message is like 50x longer than the actual fix.

ASTERISK 24981 #close
Reported by Mark Michelson

Change-Id: I2b963c58c063bae293e038406f7d044a8a5377cd

The chan_dahdi channel driver is a very old driver.  The ability for it to
support ISDN was added well after the initial analog support.  Setting the
softhangup flags is a carry over from the original analog code.  The
driver was not updated to call ast_queue_hangup() which will post the AMI
HangupRequest event.

* Changed sig_pri.c to call ast_queue_hangup() instead of setting the
softhangup flag when the remote party initiates a hangup.

ASTERISK-24895 #close
Reported by: Andrew Zherdin

Change-Id: I5fe2e48556507785fd8ab8e1c960683fd5d20325

The concatenate for columns name to INSERT INTO is always the same. It is
possible to do it on one line.

ASTERISK-24980

Change-Id: Ib8bb53c42535378581d4ef729cc5ebbb22b067ac

Contact status rtt is an int64_t and needs the PRId64 macro to
properly create the format specifier on 32-bit systems.

Change-Id: I4b8ab958fc1e9a179556a9b4ffa49673ba9fdec7

The "Add qualify_timeout processing and eventing" patch introduced
an issue where contacts that had qualify_frequency set to 0 were
showing Unavailable instead Unknown.  This patch checks for
qualify_frequency=0 and create an "Unknown"  contact_status
with an RTT = 0.

Previously, the lack of contact_status implied Unknown but since
we're now changing endpoint state based on contact_status, I've
had to add new UNKNOWN status so that changes could trigger the
appropriate contact_status observers.

ASTERISK-24977: #close

Change-Id: Ifcbc01533ce57f0e4e584b89a395326e098b8fe7

When a PBX registrar is unloaded, it will fail to remove its extension from
the context root_table if a dialplan application used by that extension is
still loaded. This can be the case for AGI, which can be unloaded after several
of the standard PBX providers. Often, this is harmless; however, if the
extension's priorities are removed during the failed unloading *and* the
dialplan application later unregisters, it leaves a ticking timebomb for the
next PBX provider that attempts to iterate over the extensions. When that
occurs, the peer_table pointer on the extension will already be set to NULL.
The current code does not check to see if the pointer is NULL before passing
it to a hashtab function this is not NULL tolerant.

Since it is possible for the peer_table to be NULL when we normally would not
expect that to be the case, the solution in this patch is to simply skip over
processing an extension's priorities if peer_table is NULL.

Prior to this patch, the tests/pbx/callerid_match test would crash during
module unload. With this patch, the test no longer crashes after running.

ASTERISK-24774 #close
Reported by: Corey Farrell

Change-Id: I2bbeecb7e0f77bac303a1b9135e4cdb4db6d4c40

Three fax related tests started failing as a result of changes made for
ASTERISK-24841:
tests/fax/pjsip/gateway_t38_g711
tests/fax/sip/gateway_mix1
tests/fax/sip/gateway_mix3

Historically, ast_channel_make_compatible() did nothing if the channels
were already "compatible" even if they had a sub-optimal translation path
already setup.  With the changes from ASTERISK-24841 this is no longer
true in order to allow the best translation paths to always be picked.  In
res_fax.c:fax_gateway_framehook() code manually setup the channels to go
through slin and then called ast_channel_make_compatible().  With the
previous version of ast_channel_make_compatible() this was always a
no-operation.

* Remove call to ast_channel_make_compatible() in fax_gateway_framehook()
that now undoes what was just setup when the framehook is attached.

* Fixed locking around saving the channel formats in
fax_gateway_framehook() to ensure that the formats that are saved are
consistent.

* Fix copy pasta errors in fax_gateway_framehook() that confuses read and
write when dealing with saved channel formats.

ASTERISK-24841
Reported by: Matt Jordan

Change-Id: I6fda0877104a370af586a5e8cf9e161a484da78d

When DEBUG_THREADLOCALS is enabled it causes the threadlocal cleanup to be
called as a function.  This causes a compile error with raw threadstorage as
it uses NULL for cleanup.  This fix uses a macro that provides NULL when
DEBUG_THREADLOCALS is disabled, and replaces the call to "c_cleanup(data);"
with "{};" when DEBUG_THREADLOCALS is enabled.

ASTERISK-24975 #close
Reported by: Ashley Sanders

Change-Id: I3ef7428ee402816d9fcefa1b3b95830c00d5c402

A potential problem that can arise is the following:

* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.

If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.

Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.

The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:

* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.

This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:

* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.

The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.

Address review feedback on gerrit.

* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
  max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c

ASTERISK-24958 #close

Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23

* changes:
  res_pjsip: Add global option to limit the maximum time for initial qualifies
  pjsip_options: Add qualify_timeout processing and eventing
  res_pjsip: Refactor endpt_send_request to include transaction timeout

Due to a race condition there was a chance that during an attended transfer the
channel's application would return NULL. This, of course, would cause a crash
when attempting to access the memory. This patch retrieves the channel's app
at an earlier time in processing in hopes that the app name is available.
However, if it is not then "unknown" is used instead. Since some string value
is now always present the crash can no longer occur.

ASTERISK-24869 #close
Reported by: viniciusfontes
Review: https://gerrit.asterisk.org/#/c/133/

Change-Id: I5134b84c4524906d8148817719d76ffb306488ac

Currently when Asterisk starts initial qualifies of contacts are spread out
randomly between 0 and qualify_timeout to prevent network and system overload.
If a contact's qualify_frequency is 5 minutes however, that contact may be
unavailable to accept calls for the entire 5 minutes after startup.  So while
staggering the initial qualifies is a good idea, basing the time on
qualify_timeout could leave contacts unavailable for too long.

This patch adds a new global parameter "max_initial_qualify_time" that sets the
maximum time for the initial qualifies.  This way you could make sure that all
your contacts are initialy, randomly qualified within say 30 seconds but still
have the contact's ongoing qualifies at a 5 minute interval.

If max_initial_qualify_time is > 0, the formula is initial_interval =
min(max_initial_interval, qualify_timeout * random().  If not set,
qualify_timeout is used.

The default is "0" (disabled).

ASTERISK-24863 #close

Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
Tested-by: George Joseph <george.joseph@fairview5.com>

This change makes the send_notify of the sub_tree
not happen when the sub_tree has been deleted due
to the notify call failing, which avoids a crash.

ASTERISK-24970 #close

Change-Id: I1f20ffc08b192f59c457293b218025a693992cbf

This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html



The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint.  Only dynamic contact add/delete actions
update the endpoint.  Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.

This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...

1.  A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message.  The default is 3000ms.  When the timer expires, the contact is
marked unavailable.

2.  Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'.  When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'.  The
existing endpoint events are generated appropriately.

ASTERISK-24863 #close

Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>

This is the first follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html



Since we currently have no control over pjproject transaction timeout, this
patch pulls the pjsip_endpt_send_request function out of pjproject and into
res_pjsip/endpt_send_transaction in order to implement that capability.

Now when the transaction is initiated, we also schedule our own pj_timer with
our own desired timeout.

If the transaction completes before either timeout, pjproject cancels its timer,
and calls our tsx callback where we cancel our timer and run the app callback.

If the pjproject timer times out first, pjproject calls our tsx callback where
we cancel our timer and run the app callback.

If our timer times out first, we terminate the transaction which causes
pjproject to cancel its timer and call our tsx callback where we run the app
callback.

Regardless of the scenario, pjproject is calling the tsx callback inside the
group_lock and there are checks in the callback to make sure it doesn't run
twice.

As part of this patch ast_sip_send_out_of_dialog_request was created to replace
its similarly named private function.  It takes a new timeout argument in
milliseconds (<= 0 to disable the timeout).

ASTERISK-24863 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>

Change-Id: I0778dc730d9689c5147a444a04aee3c1026bf747

Added .pyc and .sha1 to the top-level .gitignore.

Change-Id: I7dfc4f554d54d22947b38140d3305007503cc16a
Tested-by: George Joseph <george.joseph@fairview5.com>

The Makefile claims that you can set default menuselect options by creating
~/.asterisk.makeopts or /etc/asterisk.makeopts, but they are never read.
The rule for menuselect.makeopts is only allowed to run if the active target
is 'menuselect', but the menuselect target doesn't depend on
menuselect.makeopts.  A dot (wildcard character) was added so the rule will
be active for the targets that cause it to run: nmenuselect, cmenuselect,
and gmenuselect.

ASTERISK-13271 #close
Reported by: John Nemeth

Change-Id: Ibde804ff196283def49ccb9432fbf224a22586e2

This change adds the following:

1. A query set implementation. This is an API that allows queries to be executed in parallel and once all have completed a callback is invoked.
2. Unit tests for the query set implementation.
3. An external PJSIP resolver which uses the DNS core API to do NAPTR, SRV, AAAA, and A lookups.

For the resolver it will do NAPTR, SRV, and AAAA/A lookups in parallel. If NAPTR or SRV
are available it will then do more queries. And so on. Preference is NAPTR > SRV > AAAA/A,
with IPv6 preferred over IPv4. For transport it will prefer TLS > TCP > UDP if no explicit
transport has been provided. Configured transports on the system are taken into account to
eliminate resolved addresses which have no hope of completing.

ASTERISK-24947 #close
Reported by: Joshua Colp

Change-Id: I56cb03ce4f9d3d600776f36928e0b3e379b5d71e

The LOG_ERROR has reference to CDR instead of CEL  for LENGTHEN_BUF1 and
LENGTHEN_BUF2.

ASTERISK-24965 #close
Reported by: Rodrigo Ramirez Norambuena

Change-Id: Icc818697d7d66d34bfe3048cdd15ca2b06c89744

Update test_astobj2_weaken to use the new AST_REGISTER_FILE macro.

Change-Id: Ieedadf16610f2e042f393e0501a36447cd07f83d