Change-Id: Ic476a56608b1820ca93dcf68d10cd76fc0b94141

The code for gathering contacts could result in the same contact
being retrieved and added to the list multiple times. The container
which stores the contacts to display will now only allow a contact
to be added to it once instead of multiple times.

ASTERISK-28228

Change-Id: I805185cfcec03340f57d2b9e6cc43c49401812df

incorrect handling of UDPTL squence number wrap arounds causes
loss of packets every time the wrap around occurs

ASTERISK-28483 #close

Change-Id: I33caeb2bf13c574a1ebb81714b58907091d64234

The functions that build manager message headers do so in a way that
results in a single messages being split across multiple packets. While
this doesn't matter to the remote end, it makes network captures noisier
and harder to follow, and also means additional system calls.

With this patch, we build up more of the message content into the TLS
buffer before flushing to the network. This change is completely
internal to the manager code and does not affect any of the existing
API's consumers.

Change-Id: I50128b0769060ca5272dbbb5e60242d131eaddf9

Change-Id: I8b8ed97001446fab0c14d7c89391ee572fb29dd6

Change-Id: Ib0a4b41e5ececbe633079e2d8c2b66c031d2d1f2

When a module fails to register itself (usually a coding error
in the module), dlerror() can return NULL.  We weren't checking
for that in load_dlopen() before trying to strdup the error message
so a SEGV was thrown.  dlerror() is now surrounded with an S_OR
so we don't SEGV.

Change-Id: Ie0fb9316f08a321434f3f85aecf3c7d2ede8b956

We don't support non-core modules for Certified releases but we
were enabling them for CI builds which was causing lots of test
failures.  Now we don't.

Change-Id: I0b3254c08a2479f3d39151690350cce5ce5ad766

ASTERISK-28477 #close
Reported by: Dennis

ASTERISK-28478 #close
Reported by: Dennis

Change-Id: I77347ad46a86dc5b35ed68270cee56acefb4f475

Change-Id: I94dc38920e6e77cc73062648f62fdd613d0d1452
Signed-off-by: Oron Peled <oron.peled@xorcom.com>

Change-Id: I452d6a853bcd8c6e194455b19e5e017713e9c0fe
Signed-off-by: Oron Peled <oron.peled@xorcom.com>

* This command show the MFC/R2 links

Change-Id: I213822e1b7ef9c05bd89a2ba62df8e0856ce9f84
Signed-off-by: Oron Peled <oron.peled@xorcom.com>

Change-Id: Ibcb2401515a58782a1488c0b9efbed201c3f3a17
Signed-off-by: Oron Peled <oron.peled@xorcom.com>

Otherwise, OpenR2 threads go crazy and consume almost all CPU resources

Change-Id: I10a41f617613fe7399c5bdced5c64a2751173f28
Signed-off-by: Oron Peled <oron.peled@xorcom.com>

Details:
  - The memcpy() call copied part of "dahdi_conf" and not "dahdi_conf.mfcr2"
  - As a result, the memcmp() in dahdi_r2_get_link() always fails
  - This cause dahdi_r2_get_link() to create new link for every channel
    (instead of a new link for every ~30 channels)
  - With the fix, far less links are generated -- so we use far less threads

Change-Id: I7259dd6272f5e46e8a6c7f5bf3e8c2ec01b8c132
Signed-off-by: Oron Peled <oron.peled@xorcom.com>

Change-Id: Ica182a891743017ff3cda16de3d95335fffd9a91

We're at the point where there are enough Jenkins jobs for
Asterisk branches than even cleaned checkouts of Asterisk
will add up to more disk space than is available on the
in-memory workspace mount.  Since we archive all relevent
artifacts anyway, there's no need to keep the workspace
around after the job finishes, whether it succeeds or fails.

Change-Id: I1cd3b73ebb045a987df0f62526d152a510210c39

The testsuite actually needs the headers installed to run
it's self_test.

Change-Id: Ice41d331131b876ad4a9c056085fe6aac34b32b2

When fixing ASTERISK~24212, a change was done so a scheduled callback could not
be removed while it was running. The caller of ast_sched_del would have to wait.

However, when the caller of ast_sched_del is the callback itself (however wrong
this might be), this new check would cause a deadlock: it would wait forever
for itself.

This changeset introduces an additional check: if ast_sched_del is called
by the callback itself, it is immediately rejected (along with an ERROR log and
a backtrace). Additionally, the AST_SCHED_DEL_UNREF macro is adjusted so the
after-ast_sched_del-refcall function is only run if ast_sched_del returned
success.

This should fix the following spurious race condition found in chan_sip:
- thread 1: schedule sip_poke_peer_now (using AST_SCHED_REPLACE)
- thread 2: run sip_poke_peer_now
- thread 2: blank out sched-ID (too soon!)
- thread 1: set sched-ID (too late!)
- thread 2: try to delete the currently running sched-ID

After this fix, an ERROR would be logged, but no deadlocks (in do_monitor) nor
excess calls to sip_unref_peer(peer) (causing double frees of rtp_instances and
other madness) should occur.

(Thanks Richard Mudgett for reviewing/improving this "scary" change.)

Note that this change does not fix the observed race condition: unlocked
access to peer->pokeexpire (and potentially other scheduled items in chan_sip),
causing AST_SCHED_DEL_UNREF to look at a changing id. But it will make the
deadlock go away. And in the observed case, it will not have adverse affects
(like memory leaks) because the scheduled item is removed through a different
path.

ASTERISK-28282

Change-Id: Ic26777fa0732725e6ca7010df17af77a012aa856

Asterisk headers are no longer installed and uninstalled
automatically when performing a "make install" or a
"make uninstall".  To install/uninstall the headers, use
"make install-headers" and "make uninstall-headers".
The headers also continue to be uninstalled when performing a
"make uninstall-all".

Also corrects an issue where /usr/include/asterisk.h was never
being removed at all.

Change-Id: Ia7399f3a0203a4825fc4a9f43b9034dae9a2b643