With tls and udp enabled asterisk generates a warning about sending
message via udp instead of tls.
sip notify command via cli works as expected and without warning.

asterisk has to set the connection information accordingly to connection
and not on presumption

ASTERISK-28057 #close

Change-Id: Ib43315aba1f2c14ba077b52d8c5b00be0006656e

Fixes random asterisk crash on start or reload with TLS phones.

ASTERISK-28034 #close
Reported-by: David Hajek

Change-Id: I2a859f97dc80c348e2fa56e918214ee29521c4ac

Also remove function peer_ipcmp_cb since it's not used (according to
rmudgett).

Prior to b2c4e866 (ASTERISK_27457)
insecure=port was the defacto standard.  That commit also prevented
insecure=port from being applied for sip/tcp or sip/tls.

Into consideration there are three sets of behaviour:

1.  "previous" - before the above commit.
2.  "current" - post above commit, pre this one.
3.  "new" - post this commit.

The problem that the above commit tried to address was guests over TCP.
It succeeded in doing that but broke transport!=udp with host!=dynamic.

This commit attempts to restore sane behaviour with respect to
transport!=udp for host!=dynamic whilst still retaining the guest users
over tcp.

It should be noted that when looking for a peer, two passes are made, the
first pass doesn't have SIP_INSECURE_PORT set for the searched-for peer,
thus looking for full matches (IP + Port), the second pass sets
SIP_INSECURE_PORT, thus expecting matches on IP only where the matched
peer allows for that (in the author's opinion:  UDP with insecure=port,
or any TCP based, non-dynamic host).

In previous behaviour there was special handling for transport=tcp|tls
whereby a peer would match during the first pass if the utilized
transport was TCP|TLS (and the peer allowed that specific transport).

This behaviour was wrong, or dubious at best.  Consider two dynamic tcp
peers, both registering from the same IP (NAT), in this case either peer
could match for connections from an IP.  It's also this behaviour that
prevented SIP guests over tcp.

The above referenced commit removed this behaviour, but kept applying
the SIP_INSECURE_PORT only to WS|WSS|UDP.  Since WS and WSS is also TCP
based, the logic here should fall into the TCP category.

This patch updates things such that the previously non-explicit (TCP
behaviour) transport test gets performed explicitly (ie, matched peer
must allow for the used transport), as well as the indeterministic
source-port nature of the TCP protocol is taken into account.  The new
match algorithm now looks like:

1.  As per previous behaviour, IP address is matched first.

2.  Explicit filter with respect to transport protocol, previous
    behaviour was semi-implied in the test for TCP pure IP match - this now
    made explicit.

3.  During first pass (without SIP_INSECURE_PORT), always match on port.

4.  If doing UDP, match if matched against peer also has
    SIP_INSECURE_PORT, else don't match.

5.  Match if not a dynamic host (for non-UDP protocols)

6.  Don't match if this is WS|WSS, or we can't trust the Contact address
    (presumably due to NAT)

7.  Match (we have a valid Contact thus if the IP matches we have no
    choice, this will likely only apply to non-NAT).

To logic-test this we need a few different scenarios.  Towards this end,
I work with a set number of peers defined in sip.conf:

[peer1]
host=1.1.1.1
transport=tcp

[peer2]
host=1.1.1.1
transport=udp

[peer3]
host=1.1.1.1
port=5061
insecure=port
transport=udp

[peer4]
host=1.1.1.2
transport=udp,tcp

[peer5]
host=dynamic
transport=udp,tcp

Test cases for UDP:

1 - incoming UDP request from 1.1.1.1:
  - previous:
    - pass 1:
      * peer1 or peer2 if from port 5060 (indeterminate, depends on peer
        ordering)
      * peer3 if from port 5061
      * peer5 if registered from 1.1.1.1 and source port matches
    - pass 2:
      * peer3
  - current: as per previous.
  - new:
    - pass 1:
      * peer2 if from port 5060
      * peer3 if from port 5061
      * peer5 if registered from 1.1.1.1 and source port matches
    - pass 2:
      * peer3

2 - incoming UDP request from 1.1.1.2:
  - previous:
    - pass 1:
      * peer5 if registered from 1.1.1.2 and port matches
      * peer4 if source port is 5060
    - pass 2:
      * no match (guest)
  - current: as previous.
  - new as previous (with the variation that if peer5 didn't have udp as
          allowed transport it would not match peer5 whereas previous
          and current code could).

3 - incoming UDP request from anywhere else:
  - previous:
    - pass 1:
      * peer5 if registered from that address and source port matches.
    - pass 2:
      * peer5 if insecure=port is additionally set.
      * no match (guest)
  - current - as per previous
  - new - as per previous

Test cases for TCP based transports:

4 - incoming TCP request from 1.1.1.1
  - previous:
    - pass 1 (indeterministic, depends on ordering of peers in memory):
      * peer1; or
      * peer5 if peer5 registered from 1.1.1.1 (irrespective of source port); or
      * peer2 if the source port happens to be 5060; or
      * peer3 if the source port happens to be 5061.
    - pass 2: cannot happen since pass 1 will always find a peer.
  - current:
    - pass 1:
      * peer1 or peer2 if from source port 5060
      * peer3 if from source port 5060
      * peer5 if registered as 1.1.1.1 and source port matches
    - pass 2:
      * no match (guest)
  - new:
    - pass 1:
      * peer 1 if from port 5060
      * peer 5 if registered and source port matches
    - pass 2:
      * peer 1

5 - incoming TCP request from 1.1.1.2
  - previous (indeterminate, depends on ordering):
    - pass 1:
      * peer4; or
      * peer5 if peer5 registered from 1.1.1.2
    - pass 2: cannot happen since pass 1 will always find a peer.
  - current:
    - pass 1:
      * peer4 if source port is 5060
      * peer5 if peer5 registered as 1.1.1.2 and source port matches
    - pass 2:
      * no match (guest).
  - new:
    - pass 1:
      * peer4 if source port is 5060
      * peer5 if peer5 registered as 1.1.1.2 and source port matches
    - pass 2:
      * peer4

6 - incoming TCP request from anywhere else:
  - previous:
    - pass 1:
      * peer5 if registered from that address
    - pass 2: cannot happen since pass 1 will always find a peer.
  - current:
    - pass 1:
      * peer5 if registered from that address and port matches.
    - pass 2:
      * no match (guest)
  - new: as per current.

It should be noted the test cases don't make explicit mention of TLS, WS
or WSS.  WS and WSS previously followed UDP semantics, they will now
enforce source port matching.  TLS follow TCP semantics.

The previous commit specifically tried to address test-case 6, but broke
test-cases 4 and 5 in the process.

ASTERISK-27881 #close

Change-Id: I61a9804e4feba9c7224c481f7a10bf7eb7c7f2a2

If asterisk offer an endpoint with SRTP and that endpoint respond
with non srtp, in that case channel(rtp,secure,audio) reply wrong
status.

Why delete flag AST_SRTP_CRYPTO_OFFER_OK while check identical remote_key:
Currently this flag has being set redundantly. In either case identical
or different remote_key this flag has being set. So if we
don't set it while we receive identical remote_key or non SRTP SDP
response then we can take decision of srtp use by using that flag.

ASTERISK-27999

Change-Id: I29dc2843cf4e5ae2604301cb4ff258f1822dc2d7

Changing any Menuselect option in the `Compiler Flags` section causes a
full rebuild of the Asterisk source tree.  Every enabled option causes
a #define to be added to buildopts.h, thus breaking ccache caching for
every source file that includes "asterisk.h".  In most cases each option
only applies to one or two files.  Now we only define those options for
the specific sources which use them, this causes much better cache
matching when working with multiple builds.  For example testing code
with an without MALLOC_DEBUG will now use just over half the ccache
size, only main/astmm.o will have two builds cached instead of every
file.

Reorder main/Makefile so _ASTCFLAGS set on specific object files are all
together, sorted by filename.  Stop adding -DMALLOC_DEBUG to CFLAGS of
bundled pjproject, this define is no longer used by any header so only
serves to break cache.

The only code change is a slight adjustment to how main/astmm.c is
initialized.  Initialization functions always exist so main/asterisk.c
can call them unconditionally.  Additionally rename the astmm
initialization functions so they are not exported.

Change-Id: Ie2085237a964f6e1e6fff55ed046e2afff83c027

I have removed the STATIC_BUILD option immediately as it has not
been maintained in many years and is non-functional.

ASTERISK-27965

Change-Id: I64783d017b86dba9ee3c7bcfb97e59889a3f76d7

M_READ existed already and was conflicting in name.

Change-Id: I02108e07ae7d2dc314fe1e6c706c17731095a3e4

Change-Id: I34c3b1201b1de539945bcfdcb264fff30332d48c

The iax2 module is not handling timeout and EINTR case properly. Mainly when
there is an interupt to the kernel thread. In case of ast_io_wait recieves a
signal, or timeout it can be an error or return 0 which eventually escapes the
thread loop, so that it cant recieve any data. This then causes the modules
receive queue to build up on the kernel and stop any communications via iax in
asterisk.

The proposed patch is for the iax module, so that timeout and EINTR does not
exit the thread.

ASTERISK-27705
Reported-by: Kirsty Tyerman

Change-Id: Ib4c32562f69335869adc1783608e940c3535fbfb

ASTERISK-27908

Change-Id: Iac49d9f82faeb8a4611c6805906bd6d650b1b1d8

chan_pjsip wasn't registering for "BEFORE_MEDIA" responses which meant
it was not updating HANGUPCAUSE for 4XX responses.  If the remote end
sent a "180 Ringing", then a "486 Busy", the hangup cause was left at
"180 Normal Clearing".

* Removed chan_pjsip_incoming_response from the original session
  supplement (which was handling only "AFTER MEDIA") and added it to a
  new session supplement which accepts both "BEFORE_MEDIA" and
  "AFTER_MEDIA".

* Also cleaned up some cleanup code in load module.

ASTERISK-27902

Change-Id: If9b860541887aca8ac2c9f2ed51ceb0550fb007a

This function originally was used in chan_sip to enable some simplifying
assumptions and eventually was copy and pasted into res_pjsip_logger and
res_hep.  Since it's replicated in three places, it's probably best to
move it into the public netsock2 API for these modules to use.

Change-Id: Id52e23be885601c51d70259f62de1a5e59d38d04

This fixes build warnings found by GCC 8.  In some cases format
truncation is intentional so the warning is just suppressed.

ASTERISK-27824 #close

Change-Id: I724f146cbddba8b86619d4c4a9931ee877995c84

Analog phones dial overlap dialing and it is chan_dahdi's job to read the
numbers.  It has three timeout constants that this commit converts to
channel-level configuration options:

* firstdigit_timeout: Default time (ms) to detect first digit

* interdigit_timeout: Default time (ms) to detect following digits

* matchdigit_timeout: Default time (ms) to wait in case of ambiguous
match.  This happens when the dialed digits match a number in the current
context but are also the prefix of another number.

Change-Id: Ib728fa900a4f6ae56d1ed810aba61b6593fb7213

ASTERISK-27820

Change-Id: I310896143e94d65da1c2be3bb448204a8b86d557

Core bridging and, more specifically, bridge_softmix have been
enhanced to relay received frames of type TEXT or TEXT_DATA to all
participants in a softmix bridge.  res_pjsip_messaging and
chan_pjsip have been enhanced to take advantage of this so when
res_pjsip_messaging receives an in-dialog MESSAGE message from a
user in a conference call, it's relayed to all other participants
in the call.

res_pjsip_messaging already queues TEXT frames to the channel when
it receives an in-dialog MESSAGE from an endpoint and chan_pjsip
will send an MESSAGE when it gets a TEXT frame.  On a normal
point-to-point call, the frames are forwarded between the two
correctly.  bridge_softmix was not though so messages weren't
getting forwarded to conference bridge participants.  Even if they
were, the bridging code had no way to tell the participants who
sent the message so it would look like it came from the bridge
itself.

* The TEXT frame type doesn't allow storage of any meta data, such
as sender, on the frame so a new TEXT_DATA frame type was added that
uses the new ast_msg_data structure as its payload.  A channel
driver can queue a frame of that type when it receives a message
from outside.  A channel driver can use it for sending messages
by implementing the new send_text_data channel tech callback and
setting the new AST_CHAN_TP_SEND_TEXT_DATA flag in its tech
properties.  If set, the bridging/channel core will use it instead
of the original send_text callback and it will get the ast_msg_data
structure. Channel drivers aren't required to implement this.  Even
if a TEXT_DATA enabled driver uses it for incoming messages, an
outgoing channel driver that doesn't will still have it's send_text
callback called with only the message text just as before.

* res_pjsip_messaging now creates a TEXT_DATA frame for incoming
in-dialog messages and sets the "from" to the display name in the
"From" header, or if that's empty, the caller id name from the
channel.  This allows the chat client user to set a friendly name
for the chat.

* bridge_softmix now forwards TEXT and TEXT_DATA frames to all
participants (except the sender).

* A new function "ast_sendtext_data" was added to channel which
takes an ast_msg_data structure and calls a channel's
send_text_data callback, or if that's not defined, the original
send_text callback.

* bridge_channel now calls ast_sendtext_data for TEXT_DATA frame
types and ast_sendtext for TEXT frame types.

* chan_pjsip now uses the "from" name in the ast_msg_data structure
(if it exists) to set the "From" header display name on outgoing text
messages.

Change-Id: Idacf5900bfd5f22ab8cd235aa56dfad090d18489

clang 6.0 warned about this. Beside that, this change removes the used variable
'desc'.

ASTERISK-27808

Change-Id: Ia26bdcc0a562c058151814511cfcf70ecafa595b

ast_sip_push_task_synchronous() did not necessarily execute the passed in
task under the specified serializer.  If the current thread is any
registered pjsip thread then it would execute the task immediately instead
of under the specified serializer.  Reentrancy issues could result if the
task does not execute with the right serializer.

The original reason ast_sip_push_task_synchronous() checked to see if the
current thread was a registered pjsip thread was because of a deadlock
with masquerades and the channel technology's fixup callback
(ASTERISK_22936).  A subsequent masquerade deadlock fix (ASTERISK_24356)
involving call pickups avoided the original deadlock situation entirely.
The PJSIP channel technology's fixup callback no longer needed to call
ast_sip_push_task_synchronous().

However, there are a few places where this unexpected behavior is still
required to avoid deadlocks.  The pjsip monitor thread executes callbacks
that do calls to ast_sip_push_task_synchronous() that would deadlock if
the task were actually pushed to the specified serializer.  I ran into one
dealing with the pubsub subscriptions where an ao2 destructor called
ast_sip_push_task_synchronous().

* Split ast_sip_push_task_synchronous() into
ast_sip_push_task_wait_servant() and ast_sip_push_task_wait_serializer().
ast_sip_push_task_wait_servant() has the old behavior of
ast_sip_push_task_synchronous().  ast_sip_push_task_wait_serializer() has
the new behavior where the task is always executed by the specified
serializer or a picked serializer if one is not passed in.  Both functions
behave the same if the current thread is not a SIP servant.

* Redirected ast_sip_push_task_synchronous() to
ast_sip_push_task_wait_servant() to preserve API for released branches.

ASTERISK_26806

Change-Id: Id040fa42c0e5972f4c8deef380921461d213b9f3

There is a problem when an INVITE-with-Replaces transfer targets a channel
in a ConfBridge.  The transfer will unconditionally swap out the
ConfBridge channel.  Unfortunately, the ConfBridge state will not be aware
of this change.  Unexpected behavior will happen as a result since
ConfBridge channels currently can only be replaced by a masquerade and not
normal bridge channel moves.

* We just need to pretend that the channel isn't in a bridge (like other
transfer methods already do) so the transfer channel will masquerade into
the ConfBridge channel.

Change-Id: I209beb0e748fa4f4b92a576f36afa8f495ba4c82

This change allows chan_pjsip to be given an AST_FRAME_RTCP
containing REMB feedback and pass it to res_rtp_asterisk.
Once res_rtp_asterisk receives the frame a REMB RTCP feedback
packet is constructed with the appropriate contents and sent
to the remote endpoint.

ASTERISK-27776

Change-Id: Ic53f821c1560d8924907ad82c4d9c0bc322b38cd

Given the below call scenario:
A -> Ast1 -> B
C <- Ast2 <- B

1) A calls B through Ast1
2) B calls C through Ast2
3) B transfers A to C

When party B transfers A to C, B sends a REFER to Ast1 causing Ast1 to
send an INVITE with replaces to Ast2.  Ast2 then leaks a channel ref of
the channel between Ast1 and Ast2.

Channel ref leaks are easily seen in the CLI "core show channels" output.
The leaked channels appear in the output but you can do nothing with them
and they never go away unless you restart Asterisk.

* Properly account for the channel refs when imparting a channel into a
bridge when handling an INVITE with replaces in handle_invite_replaces().
The ast_bridge_impart() function steals a channel ref but the code didn't
account for how many refs were held by the code at the time and which ref
was stolen.

* Eliminated RAII_VAR in handle_invite_replaces().

ASTERISK-27740

Change-Id: I7edbed774314b55acf0067b2762bfe984ecaa9a4

This change extends the existing AST_FRAME_RTCP frame type to be
able to contain additional RTCP message types, such as feedback
messages. The payload type is contained in the subclass which allows
knowing what is in the frame itself.

The RTCP feedback message type is now handled and REMB[1] messages
are raised with their containing information.

This also fixes a bug where all feedback messages were triggering
video updates instead of just FIR and FUR.

Finally RTCP frames are now passed up through the Asterisk core to
what is handling the channel, mapped appropriately in the case of
bridging, and written to an outgoing stream. Since RTCP frames are
on a per-stream basis this is only done on multistream capable
channels.

[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03

ASTERISK-27758
ASTERISK-26366

Change-Id: I680da0ad8d5059d5e9655d896fb9d92e9da8491e

In the script ./configure, AST_EXT_LIB_CHECK checks for external libraries. Some
libraries do not specify all their dependencies and require additional shared
libraries. In AST_EXT_LIB_CHECK, this is the fifth parameter. However, if a
library is specified there, it must exist on the platform, because ./configure
tries to compile/link/execute a small app using those statements. For example,
the library libdl.so is Linux specific and does not exist on BSD-like platforms.

Furthermore, no supported platform/version was found, which still (ever?)
requires those additional libraries. Therefore, they were simply removed.

Finally, this change adds the error code ESTRPIPE to the channel driver
chan_alsa for those platforms which lack it, again for example NetBSD.

ASTERISK-27720

Change-Id: I3b21f2135f6cbfac7590ccdc2df753257f426e0b

* acl (named_acl.c)
* cdr
* cel
* ccss
* dnsmgr
* dsp
* enum
* extconfig (config.c)
* features
* http
* indications
* logger
* manager
* plc
* sounds
* udptl

These modules are now loaded at appropriate time by the module loader.
Unlike loadable modules these use AST_MODULE_LOAD_FAILURE on error so
the module loader will abort startup on failure of these modules.

Some of these modules are still initialized or shutdown from outside the
module loader.  logger.c is initialized very early and shutdown very
late, manager.c is initialized by the module loader but is shutdown by
the Asterisk core (too much uses it without holding references).

Change-Id: I371a9a45064f20026c492623ea8062d02a1ab97f

Checking option_debug directly is incorrect as it ignores file/module
specific debug settings.  This system-wide change replaces nearly all
direct checks for option_debug with the DEBUG_ATLEAST macro.

Change-Id: Ic342d4799a945dbc40ac085ac142681094a4ebf0

The "ptime" SDP parameter received in a SIP response was not honoured.
Moreover, in the abscence of this "ptime" parameter, locally configured
framing was lost during response processing.

This patch systematically stores the framing information in the
ast_rtp_codecs structure, taking it from the response or from the
configuration as appropriate.

ASTERISK-27674

Change-Id: I828a6a98d27a45a8afd07236a2bd0aa3cbd3fb2c

ASTERISK-27714
Reported by: John Nemeth

Change-Id: I1b84a89315a5f61222123d21bf35c59224da8990

When constructing a dialog-info+xml NOTIFY message a ringing channel
is found if the state is ringing and further information is placed into
the message. Due to the migration to the Stasis message bus this did
not always work as expected.

This change raises a second ringing event in such a way to guarantee
that the event is received by chan_sip and another lookup is done to
find the ringing channel.

ASTERISK-24488

Change-Id: I547a458fc59721c918cb48be060cbfc3c88bcf9c

Check if initreq data string exists before using it when processing a
CANCEL request.

ASTERISK-27666

Change-Id: Id1d0f0fa4ec94e81b332b2973d93e5a14bb4cc97

It seems that the ALSA backend of PortAudio doesn't know how to both
read and write at the same time by adding a per-device mutex.

FIXME: currently only a draft version. Need to either auto-detect
we work with the ALSA backend or add an extra configuration option
to use this mutex.

ASTERISK-27426 #close

Change-Id: I635eacee45f5413faa18f5a3b606af03b926dacb

This removes references that are no longer needed due to automatic
references created by module dependencies.

In addition this removes most calls to ast_module_check as they were
checking modules which are listed as dependencies.

Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e

This patch fix chan_unistim hold functions to correctly support
hold function in different states possible in case of multiple lines
established on the phone

ASTERISK-26596 #close

Change-Id: Ib1e04e482e7c8939607a42d7fddacc07e26e14d4

* Declare 'requires' and 'enhances' text fields on module info structure.
* Rename 'nonoptreq' to 'optional_modules'.
* Update doxygen comments.

Still need to investigate dependencies among modules I cannot compile.

Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf

Before getting the file descriptor for an iostream check
that it is present.

ASTERISK-27534

Change-Id: Ie0aa1394007a37c30e337ea1176a6fb3a63bc99c

Per RFC 5245, the foundation specified with an ICE candidate can be up
to 32 characters but we are only allowing for 31.

ASTERISK-27498 #close
Reported by: Michele Prà

Change-Id: I05ce7a5952721a76a2b4c90366168022558dc7cf

This is the old ASTOBJ macro's which are no longer used except by the
deprecated netsock.c.  Move it to the chan_iax2 include folder so it
does not get used elsewhere.

Change-Id: I7e4ae96678b36b9f41d3cae14b167f110eb5d349

Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0

Fix instances of:
* Retreive
* Recieve
* other then
* different then
* Repeated words ("the the", "an an", "and and", etc).
* othterwise, teh

ASTERISK-24198 #close

Change-Id: I3809a9c113b92fd9d0d9f9bac98e9c66dc8b2d31

In change_redirecting_information variables we use ast_strlen_zero to
see if a value should be saved.  In the case where the value is not NULL
but is a zero length string we leaked.

handle_response_subscribe leaked a reference to the ccss monitor
instance.

Change-Id: Ib11444de69c3d5b2360a88ba2feb54d2c2e9f05f

Some variables are set and never changed, making them constant.  This
means that code in the 'false' block of the conditional is unreachable.

In chan_skinny and res_config_ldap I used preprocessor directive `#if 0`
as I'm unsure if the unreachable code could be enabled in the future.

Change-Id: I62e2aac353d739fb3c983cf768933120f5fba059