The T.38 fax gateway state machine can cause the fax gateway
to be started more than once on a channel depending on the
responses of the remote endpoint. This would previously leak
the channel name, channel unique id, and underlying fax engine
state. This change instead makes it so that if the fax gateway
session is already present and not reserved the fax gateway
is not started again.

ASTERISK-27981

Change-Id: I552d95086860cb18f2522ee40ef47b13b6da2e0e

The realtime text timer pops regularly and sends text frames even if
the buffer is empty. This causes a lot of unecessary debug logging.

* Made red_write() test if we need to send a frame before calling
ast_rtp_write()

ASTERISK-28002
Reported by: Emmanuel BUU
Tested by: Emmanuel BUU

Change-Id: Icf81310c3b8080b615a42060afc02ab41f9523dd

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

All HTTP/AMI message headers are being sent to the verbose channel.
There are multiple places this is happening.  Consolidate the loop into
a function.  Drop the debug/verbose message.

Convert to using ast_asprintf to perform the length calculation, memory
allocation and snprintf all in one step.

Change-Id: Ic45e673fde05bd544be95ad5cdbc69518207c1a1

When mobile SIP clients register with Asterisk that use some sort of
push notifications, the URI can get quite lengthy due to the
additional push-service annotations (things like tokens, pn-type, etc.)
contained in it.

ASTERISK-28022 #close

Change-Id: I4c7ceadc3bb405f3daf722641c8cd5ca4188cc37

Change disables loading of res_hep.so in default installation.  Loading
res_hep has a performance impact whether it's used or not.  This disables
loading of it in sample config files.

Change-Id: I5ec150cf941634fabc72973e5bf1a965cb0ef9d0

I'm only seeing an error in 14+, so I assume it is due to different
compiler options:

app_queue.c: In function ‘handle_queue_add_member’:
app_queue.c:10234:19: error: ‘%d’ directive writing between 1 and 11
    bytes into a region of size 3 [-Werror=format-overflow=]
     sprintf(num, "%d", state);
                   ^~
app_queue.c:10234:18: note: directive argument in the range
    [-2147483648, 99]
     sprintf(num, "%d", state);
                  ^~~~

Compiler: gcc version 8.0.1 20180414 (experimental)
    [trunk revision 259383] (Ubuntu 8-20180414-1ubuntu2) 

Change-Id: I18577590da46829c1ea7d8b82e41d69f105baa10

Change-Id: I5736965c64c44338f7330e85a24bb46818607f19

When a Contact is updated the only material change that qualify
support cares about is the underlying configuration for the AOR.
In this case we will update things with the new AOR information but
otherwise the callback to indicate the Contact has changed can be
ignored.

This is because it is only when a Contact is added or deleted that
material changes occur within the qualify support. An update can't
change the URI since it would result in a new Contact so it can be
ignored.

Change-Id: I2f97ebfa79969a36a97bb7b9afd5b6268cf1a07d

We were still getting crashes after the first fix.  Somehow we receive a
non-2xx final response before we get a 200 final response.  With the
failure response we had already cleaned up and destroyed some data
structures.  When the unexpected 200 response comes in we crash.

* Add protection code to prevent processing another final T.38 reINVITE
response.

ASTERISK-27944

Change-Id: I8b5baba8d07fe4d63f0d7d05d3eb9a3d27d40a74

The allow_unqualified_fetch option for the sorcery realtime backend
blocked actually fetching all rows when the option is set to warn.

* Made issue a warning and actually do the request when
allow_unqualified_fetch=warn is set.

Change-Id: I74456c80a03a62dce66fc3dc3cb0cf2351ac4312

Change includes move to netsock2 library.

ASTERISK-27164
Reported-by: Adam Secombe

Change-Id: Ia9e8dc3d153de7a291dbda4bd87fc827dd2bb846

* In destroy_peer(), fixed memory leaks of lookup history strings and
qualify transactions when destroying peers.

* In destroy_peer(), fixed leaving the registerexpire scheduled callback
active when a peer is destroyed on a reload.  The reload marks and sweeps
peers so any peers not explicitly configured get destroyed.  Peers created
dynamically from the '*' peer will not exist until they re-register after
the reload.  These destroyed peers caused memory corruption when the
registerexpire timer expired.

* Made build_peer() not schedule any callbacks on the '*' peer
(empty_eid).  It is a special peer that is cloned to dynamically created
peers so it doesn't actually get involved in any message transactions.

* Made do_register_expire() remove the dundi/dpeers AstDB entry when a
peer registration expires.

* Fix deep_copy_peer() to not copy some things that cannot be copied to
the cloned peer structure.  Timers, message transactions, and lookup
history are specific to a peer instance.

* Made set_config() lock around processing the mappings configuration.

* Reordered unload_module() to handle load_module() declining the load due
to error.

Change-Id: Ib846b2b60d027f3a2c2b3b563d9a83a357dce1d6

Change-Id: Id52f99bd6a948fe6dd82acc0a28b2447a224fe87

* Fixed a typo in the name of the REGREQ frame decode string array.
* Fixed off by one range check indexing into the frame decode string
array.
* Removed some unneeded casts associated with the decode string array.

Change-Id: I77435e81cd284bab6209d545919bf236ad7933c2

Change-Id: I33d0ad0611c2124ca3440f0f811fa0f45e4e2849

Compiling without SRTP support installed resulted in some unused variable
warnings.  These warnings also showed that the srtp variable was obtained
and passed around some functions but not really used even when a system
has SRTP installed.

Change-Id: I6daad34be3e89b19adef6e2fbe738018975155fc

Change-Id: I5e1d4a09e58b92b541bc8ed6f9e10e54c4e5101f

Change-Id: I7729ecceedceb12f52bf18dae259846aa1d993b3

If the review to be tested is in a project with restricted access,
we need to use the jenkins user's gerrit https credentials when we
do the checkout or the checkout will fail.

Change-Id: I9dc9994763c5ebfeb9f1cff60fb53f6902b7fd5f

If in the initial sdp the caller doesn't include the line
a=rtcp-mux

Then asterisk shoud not include rtcp-mux in the response regardless
of rtcp-mux being enabled on the endpoint

ASTERISK-28007 #close

Change-Id: I58e9b9f40a139afc0da5de41906cc608fb62adc7

Change-Id: I3f396316bb40d1ae6e91f5f688042420f1a540ed

Cleanup idle check scheduled events at shutdown.

Change-Id: I61bfbb56bac69fe840c3242927d31ff3593be461

This makes it possible for REF_DEBUG to report no leaks when loading
res_odbc.

Change-Id: I1a3dea786bd6e7f4820a6dd5cbaa197fa783ce93