Confbridge dynamic profiles did not have a default profile unless you
explicitly used Set(CONFBRIDGE(bridge,template)=default_bridge). If a
template was not set prior to the bridge being created then some
options were left with no default values set. This patch makes it so
the default templates are set to the default bridge and user profiles.

ASTERISK-24749 #close
Reported by: philippebolduc

Change-Id: I1bd6e94b38701ac2112d842db68de63d46f60e0a

Change-Id: I8f3d0a6c3f1075a1f7d8308593394611a96749de

The way PJSIP generates an authenticated request is to use a previous
request as a template. This means that the authenticated request will
have the same Call-ID, From header (including tag), and CSeq as the
original request. PJSIP generates a new branch on the Via header to
indicate that this is a new transaction, though.

There are some SIP implementations, though, that do not notice the
change in the branch and therefore will match the authed request to the
original request's transaction. Since the CSeq is the same, the server
will repeat the response it sent to the original request.

This patch aids interoperability by increasing the CSeq of the authed
request by one.

ASTERISK-24845 #close
Reported by: Carl Fortin
Tested by: Carl Fortin

Change-Id: I39c4ca52e688a9f83bcc1878371334becdc5be01

When Asterisk originates a channel to an application, the channel is
hung up once the application finishes executing. When the application
in question is SendFax, the Asterisk PJSIP code will attempt to reinvite
the T.38 session to audio after the FAX completes. The hangup of the
channel happens in the midst of this reinvite transaction. In most
circumstances, this works out okay because the BYE is delayed until the
reinvite transaction can complete.

However, if the reinvite that Asterisk sends receives a 401/407
response, then Asterisk's attempt to re-send the reinvite with
authentication will fail. This is because the session supplement in
res_pjsip_t38 makes the assumption that the channel on the session will
always be non-NULL. Since the channel has been hung up, though, the
channel is now NULL. Attempting to operate on the channel causes a
crash.

This patch fixes the issue by ensuring that the channel on the session
is not NULL before attempting to mess with the T.38 framehook.

This patch also contains some corrections for comments that were
incorrect and really confused me when I first started looking at the
code.

ASTERISK-25004 #close
Reported by Mark Michelson

Change-Id: Ic5a1230668369dda4bb13524098aed9306ab45a0

Currently we use pjsip_parse_hdr to validate contact uris but it
appears that it allows uris without a scheme if there's a port
supplied.  I.E myexample.com will fail but myexample.com:5060 will
pass even though it has no scheme.  This causes SEGVs later on
whenever the uri is used.

To prevent this, permanent_contact_validate has been updated to check
that the scheme is either 'sip' or 'sips'.

2 uses of possibly-null endpoint have also been fixed in
create_out_of_dialog_request.

ASTERISK-24999

Change-Id: Ifc17d16a4923e1045d37fe51e43bbe29fa556ca2
Reported-by: Brad Latus

clang can warn about a so called tautological-compare, when it finds
comparisons which are logically always true, and are therefor deemed
unnecessary.

Exanple:
unsigned int x = 4;
if (x > 0)    // x is always going to be bigger than 0

Enum Case:
Each enumeration is its own type. Enums are an integer type but they
do not have to be *signed*. C leaves it up to the compiler as an
implementation option what to consider the integer type of a particu-
lar enumeration is. Gcc treats an enum without negative values as
an int while clang treats this enum as an unsigned int.

rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
The cast does have an effect. For gcc, which seems to treat all enums
as int, the cast to unsigned int will eliminate the possibility of
negative values being allowed. For clang, which seems to treat enums
without any negative members as unsigned int, the cast will have no
effect. If for some reason in the future a negative value is ever
added to the enum the assert will still catch the negative value.

ASTERISK-24917

Change-Id: I0557ae0154a0b7de68883848a609309cdf0aee6a

On some systems, res_corosync isn't compatible with the installed version of
corosync so corosync_cfg_initialize fails, load_module returns LOAD_FAILURE,
and Asterisk terminates.  The work around has been to remember to add
res_corosync as a noload in modules.conf.  A better solution though is to have
res_corosync check for its config file before attempting to call corosync apis
and return LOAD_DECLINE if there's no config file.  This lets Asterisk loading
continue.

If you have a res_corosync.conf file and res_corosync fails, you get the same
behavior as today and the fatal error tells you something is wrong with the
install.

ASTERISK-24998

Change-Id: Iaf94a9431a4922ec4ec994003f02135acfdd3889

__adjust_lock doesn't check for invalid objects, and doesn't have an
appropriate return value for invalid objects.  Most callers of
__adjust_lock pass objects that have already been confirmed valid,
this change adds checks before the remaining calls.

ASTERISK-24997 #close
Reported by: Corey Farrell

Change-Id: I669100f87937cc3f867cec56a27ae9c01292908f

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

Change-Id: I6b43e43474bf6fb77b8227eadb036036f8e90521

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

This change modifies how the the output from a CLI command is sent
to a client over AMI.

Output from the CLI command is now sent as a series of zero-or-more
Output: headers.

Additionally, commands that fail to execute (eg: no such command,
invalid syntax etc.) now cause an Error response instead of Success.

If the command executed successfully, but the manager unable to
provide the output the reason will be included in the Message:
header. Otherwise it will contain 'Command output follows'.

Depends on a new version of starpy (> 1.0.2) that supports the new
output format.

See pull-request https://github.com/asterisk/starpy/pull/34

ASTERISK-24730

Change-Id: I6718d95490f0a6b3f171c1a5cdad9207f9a44888

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