As they're not actively used, they only grow stale. The moduleinfo field itself
is kept in Asterisk 13/15 for ABI compatibility.

ASTERISK-28046 #close

Change-Id: I8df66a7007f807840414bb348511a8c14c05a9fc

The documentation already specified EVENT_FLAG_DIALPLAN for this
event, but the implementation was using EVENT_FLAG_CALL.

Using EVENT_FLAG_DIALPLAN allows AMI clients to opt out of receiving
this highly verbose event.

ASTERISK-28033

Change-Id: I45b3119f30e4dbc17b49831f2b1a4f2c1beadafe

Generators provide such functionality as tone generation or
silence generation. RTCP frames provide RTCP information and
should not stop generators from operating.

ASTERISK-28005

Change-Id: Ieadada07b068a7aa426e8763f1b73a18e1ac34a9

This ensures the most up-to-date information is used for the next
call attempt.

ASTERISK-28032

Change-Id: I02fc17c6ffb50bb60ea97c2d2e6023e8061815ce

Currently, to convert from a pj_sockaddr to an ast_sockaddr, the address
needs to be rendered to a string and then parsed into the correct
structure. This also involves a call to getaddrinfo(3). The same is true
for the inverse operation.

Instead, because we know the internal structure of both ast_sockaddr and
pj_sockaddr, we can translate directly between the two without the
need for an intermediate string.

Change-Id: If0fc4bba9643f755604c6ffbb0d7cc46020bc761

The stasis cache provides a way to reconstruct the current state
of topic subscribers.  Unfortunately, since every subscribe and
unsubscribe is cached, the cache continues to grow unabated while
asterisk is running.  This patch removes subscribe messages from
the cache when the corresponding unsubscribe is received.

This patch also registers the cache containers with ao2 so that if
AO2_DEBUG is turned on, you can list the container and get its
stats from the CLI.

ASTERISK-27121

Change-Id: I3d18905e477f3721815da91f30da8d3fbb2d4f56

Change-Id: I08f88adb09f7e5813f37e70fecd787468cdb32c8

Added decline if extensions.conf file not available
when loading pbx_config, and also made sure everything
gets properly unregistered and/or destroyed on unload.

Change-Id: Ib00665106043b1be5148ffa7a477396038915854

Added a check when we receive a HTTP request line or header line that is
too long.  We now return an error response to the sender because we are
not able to process the request.

Change-Id: I6df2705435fd7dde4d5d3bdf7acec859cfb7c12d

Providing a buffer larger than the internal buffer of ast_iostream_gets()
fails to get lines longer than the internal buffer.

* Made ast_iostream_gets() fill the supplied buffer with read data until
either a '\n' is found or the supplied buffer is filled just like fgets().

Change-Id: If18b3f6ee500e22f0633a68779ed09f7e0f305ed

ASTERISK-27988

Change-Id: Iccafdd0552ea8aaed647620fb14499f1bf341843

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

SIP responses over WebSockets when the client is using IPv6 have invalid
Via headers according to RFC 3261. The 'received' header parameter
should not be wrapped in brackets if it is an IPv6 address.

When src_name is populated by the built-in PJSIP transports, the code
uses pj_sockaddr_print() with 'flags' set to 0, meaning that the
brackets are not rendered around IPv6 addresses.

This may be related to ASTERISK~27101.

See also: https://github.com/onsip/SIP.js/pull/594

ASTERISK-28020 #close

Change-Id: I8ea9d289901b837512bee2ca2535e3dc14f04d77

This new option can be passed for ./configure or
./tests/CI/buildAsterisk.sh to prevent download/install of binary
modules.

Normally enabling the categories MENUSELECT_CODECS or MENUSELECT_RES
will result in binary modules being enabled even if the build target is
incompatible with those modules.  This includes CI scripts which enable
categories before disabling specific modules.

If more binary modules are offered in the future this will help avoid
accidentally downloading them if unwanted or incompatible.  Adding a
binary module will only require creating a new menuselect entry similar
to the existing ones, it will not be necessary to modify the CI scripts.

Change-Id: I6b1bd1c75a2e48f05b8b8a45b7a7a2d00a079166

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