The res_http_websocket module will currently attempt to close
the WebSocket connection if fatal cases occur, such as when
attempting to write out data and being unable to. When the
fatal cases occur the code attempts to write a WebSocket close
frame out to have the remote side close the connection. If
writing this fails then the connection is not terminated.

This change forcefully terminates the connection if the
WebSocket is to be closed but is unable to send the close frame.

ASTERISK-25312 #close

Change-Id: I10973086671cc192a76424060d9ec8e688602845

We don't have a compatability function to fill in a missing htobe64; but
we already have one for the identical htonll.

Change-Id: Ic0a95db1c5b0041e14e6b127432fb533b97e4cac

A change recently went in which enabled perfect forward secrecy for
DTLS in res_rtp_asterisk. This was accomplished two different ways
depending on the availability of a feature in OpenSSL. The fallback
method created a temporary instance of a key but did not free it.
This change fixes that.

ASTERISK-25265

Change-Id: Iadc031b67a91410bbefb17ffb4218d615d051396

This will add ECDH support to Asterisk. It will
detect auto ECDH support in OpenSSL
(1.0.2b and above) during ./configure. If this is
available, it will use it,
otherwise it will fall back to prime256v1 (this
behavior is consistent with
other projects such as Apache and nginx).

This fixes WebRTC being broken in Firefox 38+ due
to Firefox now only supporting
ciphers with perfect forward secrecy.

ASTERISK-25265 #close

Change-Id: I8c13b33a2a79c0bde2e69e4ba6afa5ab9351465b

v11 only fix.

Change-Id: I340512f86cfd3a6f7703971fa8acfffc7d47132b

v11 only fix.

Change-Id: I97885946ebc7eda19f1c18d08698117cf6a7f14f

Change glue->update_peer() parameter from 0 to NULL to better indicate it
is a pointer.

Change-Id: Iefbf9d4a708f2b64b7ad2b4e6c33bfaa12ccfa9d

Change glue->update_peer() parameter from 0 to NULL to better indicate it
is a pointer.

Change-Id: I8ff2e5087f0e19f6998e3488a712a2470cc823bd

A test agent was continuously failing all ARI tests when run against
Asterisk 13. As it turns out, the reason for this is that on those test
runs, for some reason we decided to use the super extended 64 bit
payload length for websocket text frames instead of the extended 16 bit
payload length. For 64-bit payloads, the expected byte order over the
network is

7, 6, 5, 4, 3, 2, 1, 0

However, we were sending the payload as

3, 2, 1, 0, 7, 6, 5, 4

This meant that we were saying to expect an absolutely MASSIVE payload
to arrive. Since we did not follow through on this expected payload
size, the client would sit patiently waiting for the rest of the payload
to arrive until the test would time out.

With this change, we use the htobe64() function instead of htonl() so
that a 64-bit byte-swap is performed instead of a 32 bit byte-swap.

Change-Id: Ibcd8552392845fbcdd017a8c8c1043b7fe35964a

Commit 54b25c80 solved an issue where a
specific scenario involving local channels and a native local RTP bridge
could result in ringback still being heard on a calling channel even
after the call is bridged.

That commit caused many tests in the testsuite to fail with alarming
consequences, such as not sending DialBegin and DialEnd events, and
giving incorrect hangup causes during calls.

This commit reverts the previous commit and implements and alternate
solution. This new solution involves only passing AST_CONTROL_RINGING
frames across local channels if the local channel is in AST_STATE_RING.
Otherwise, the frame does not traverse the local channels. By doing
this, we can ensure that a playtones generator does not get started on
the calling channel but rather is started on the local channel on which
the ringing frame was initially indicated.

ASTERISK-25250 #close
Reported by Etienne Lessard

Change-Id: I3bc87a18a38eb2b68064f732d098edceb5c19f39

Control frames with a -1 payload are used as a special signal to stop
playtones generators on channels. This indication is sent both by
app_dial as well as by ast_answer() when a call is answered in case any
tones were being generated on a calling channel.

This control frame type was made to stop traversing local channel pairs
as an optimization, because it was thought that it was unnecessary to
send these indications, and allowing such unnecessary control frames to
traverse the local channels would cause the local channels to optimize
away less quickly.

As it turns out, through some special magic dialplan code, it is
possible to have a tones being played on a non-local channel, and it is
important for the local channel to convey that the tones should be
stopped. The result of having tones continue to be played on the
non-local channel is that the tones play even once the channel has been
bridged. By not blocking the -1 control frame type, we can ensure that
this situation does not happen.

ASTERISK-25250 #close
Reported by Etienne Lessard

Change-Id: I40227e4249d6d61dc6a9b08bbe9ee3aa18be7e30

Due to changes in audiohooks to support different sample rates the
underlying storage of samples is in the format of the audiohook
itself and not of the format being requested. This means that if a
channel is using G722 the samples stored will be at 16kHz. If
something subsequently reads from the audiohook at a format which
is not the same sample rate as the audiohook the number of samples
needs to be adjusted.

Given the following example:
1. Channel writing into audiohook at 16kHz (as it is using G722).
2. Chanspy reading from audiohook at 8kHz.

The original code would read 160 samples from the audiohook for
each 20ms of audio. This is incorrect. Since the audio in the
audiohook is at 16kHz the actual number needing to be read is 320.
Failure to read this much would cause the audiohook to reset
itself constantly as the buffer became full.

This change adjusts the requested number of samples by determining
the duration of audio requested and then calculating how many
samples that would be in the audiohook format.

ASTERISK-25247 #close

Change-Id: Ia91ce516121882387a315fd8ee116b118b90653d

 * In sip.conf.sample fix sentence where we said that WS or WSS are supported
   transports for use in an outbound register definition. They are not
   supported in that case.

ASTERISK-24853 #close
Reported by: PSDK

Change-Id: I3d698bc6302b9d00a0a995b5c4ad9a42d69b48ca

Change-Id: Ifdfbd0b97cf31478d29923ec30aabce28d01740b

In channels/sig_pri.h, struct sig_pri_span, the field
force_restart_unavailable_chans is only defined if

#if defined(HAVE_PRI_MCID) is true.

All other occurences of force_restart_unavailable_chans are outside of the

#if defined(HAVE_PRI_MCID)
endif

scope.

ASTERISK-25257 #close
Reported by: Patric Marschall

Change-Id: I071de89cc2cd0d85927a013036e235851f672549

Last time I checked, it's "Sangoma", not "Samgoma". Thanks to Brian
(GameGamer43) for pointing that out.

Change-Id: I43d7b196f6d7a2b2517b84915e3a8dfbc2894106

This patch adds more tests that exercise the device state API. This includes:

* Tests that cover adding a device state provider, as well as deleting a
  device state provider. This also verifies that you cannot add an
  already added device state provider, and cannot delete an already
  deleted device state provider.
* A test that covers changing device state and receiving said updates
  from a device state subscriber. This also covers hitting both the
  device state cache as well as a custom device state provider.
* A test that covers converting device state to channel state and device
  state values to a string representation and back.
* A test that covers obtaining device state from an active channel and a
  channel driver that provides its own device state.

Change-Id: I2adca67ffb405cd8625a5d6df1e3f9b3d945c08d

Currently, the device state provider API will allow you to register a
device state provider with the same case insensitive name more than
once. This could cause strange issues, as the duplicate device state
providers will not be queried when a device's state has to be polled.
This patch updates the API such that a device state provider with the
same name as one that has already registered will be rejected.

Change-Id: I4a418a12280b7b6e4960bd44f302e27cd036ceb2

This change fixes a bug where the DTLS timeout timer would be
initialized to 0 if DTLS was not used for an RTP session.

ASTERISK-25103

Change-Id: If8d26bb054f1d300838850da5b8db9044c2fe2ac

This change moves logic for setting up the DTLS SSL contexts to
when the SDP is done being processed instead of when ICE negotiation
completes. It also stops handshakes from being initiated when we
are acting as a server.

Manipulating the SSL context when ICE negotiation has completed
is problematic as the SSL context is not protected and if acting
as a client the remote side may have started DTLS negotiation
already.

The retransmission timeout timer code has also been split up
and simplified some. Both RTP and RTCP now have their own timers
and the points at which the timer is stopped and started is now
more specific. When a packet is sent the timer is started. When
a response is received but before it is processed the timer is
stopped. This provides a guarantee that the timeout is not
occurring while the response is processed.

ASTERISK-22805 #close
ASTERISK-24550 #close
ASTERISK-24651 #close
ASTERISK-24832 #close
ASTERISK-25103 #close
ASTERISK-25127 #close

Change-Id: Ib75ea2546f29d6efc3d2d37c58df6986c7bd9b91

If non-magic pickup (no "pickup-" in callid) is used, chan_sip locks the
channel it wants to pick up, and a bit further down, it locks the
channel list when allocating a new channel.

That causes a deadlock when another part of the code traverses over the
channel list, locking all the channels one by one.

This changeset fixes it by releasing the locks before calling sip_new
and reacquiring them afterwards.  Unfortunately this involves doing the
checks we already did again (because the channel may have changed).

While trying to avoid duplicate code, I did some refactoring for
readability:
- if refer_locked == 1, we guarantee there is a locked channel
- magic_callid holds a cached version of !ast_strlen_zero(pickup.exten)

This is for branch 11 only. It appears that the changed code in 13 does
not lock the components like it does in 11 and below. Reproducing the
deadlock on 13 has thusfar failed.

ASTERISK-25213 #close

Change-Id: Ie1d15bec7d634035f48892e1ed6227411d7de2c1

ASTERISK-25220 #close

Change-Id: Ic48f3a82f51ada87f2fb0e016c9efe0ad56f1ee3

When running valgrind on Asterisk, it complained about:

    ==32423== Source and destination overlap in memcpy(0x85a920, 0x85a920, 304)
    ==32423==    at 0x4C2F71C: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/...)
    ==32423==    by 0x55BA91: ast_rtp_engine_unload_format (rtp_engine.c:2292)
    ==32423==    by 0x4EEFB7: ast_format_attr_unreg_interface (format.c:1437)

The code in question is a struct assignment, which may be performed by
memcpy as a compiler optimization. It is changed to only copy the struct
contents if source and destination are different.

ASTERISK-25219 #close

Change-Id: I6d3546c326b03378ca8e9b8cefd41c16e0088b9a

If DEBUG_FD_LEAKS was used and more file descriptors than the default of
1024 were available, some DEBUG_FD_LEAKS-patched functions would
overwrite memory past the fixed-size (1024) fdleaks buffer.

This change:
- adds bounds checks to __ast_fdleak_fopen and __ast_fdleak_pipe
- consistently uses ARRAY_LEN() instead of sizeof() or 1023 or 1024
- stores pointers to constants instead of copying the contents
- reorders the fdleaks struct for possibly tighter packing
- adds a tiny bit of documentation

ASTERISK-25212 #close

Change-Id: Iacb69e7701c0f0a113786bd946cea5b6335a85e5

This fixes so a failure to get a timer file descriptor does not cascade
to closing FD 0.

On error, both res_timing_kqueue and res_timing_timerfd would call the
destructor before setting the file handle. The file handle had been
initialized to 0, causing FD 0 to be closed. This in turn, resulted in
floods of "CLI>" messages and an unusable terminal.

ASTERISK-19277 #close
Reported by: Barry Chern

Change-Id: I147d7e33726c6e5a2751928d56561494f5800350

Change-Id: I0ec7fd10d56d90d5a60b12b5a7d6807f265ac5e0

When a frame is queued on a channel, any failure in
ast_channel_alert_write is logged along with errno.

This change improves the diagnostic message through
aligning the errno value with actual failure cases.

ASTERISK-25224
Reported by: Andrey Biglari

Change-Id: I1bf7b3337ad392789a9f02c650589cd065d20b5b

This patch updates a variety of Makefiles in Asterisk's build system to
remove .gcda and .gcno files when 'make clean' is executed. These files
are generated when '--enable-coverage' is passed to the Asterisk
configure script.

Change-Id: Ib70b41eea2ee2908885bff02e80faf9f40c84602

When 8297136f was merged for ASTERISK-25040, a regression was introduced
surrounding the case sensitivity of device names within hints.
Previously, device names - such as 'sip/foo' - were compared in a case
insensitive fashion. Thus, 'sip/foo' was equivalent to 'SIP/foo'. After
that patch, only the case sensitive name would match, i.e., 'SIP/foo'.
As a result, some dialplan hints stopped working.

This patch re-introduces case insensitive matching for device names in
hints.

ASTERISK-25040

ASTERISK-25202 #close

Change-Id: If5046a7d14097e1e3c12b63092b9584bb1e9cb4c

If a client sends and INVITE which is 401 rejected, then subsequently
sends a new INVITE with the auth info and uses a different fromtag
from the first INVITE, Asterisk will accept the new INVITE as part of
the original dialog - match_req_to_dialog() specifically ignores the
fromtag. However it does not update the stored dialog with the new
fromtag.

This results in Asterisk being unable to match future packets that are
part of this dialog (such as the ACK to the OK or the OK to the BYE),
and the call is dropped.

This problem was originally found when using an NEC-i SV8100-GE (NEC SIP
Card).

* After a successful match of a packet to the dialog, if the packet is
  not a SIP_RESPONSE, authentication is present and the fromtags are
  different, the stored fromtag is updated with the one from the recent
  INVITE.

ASTERISK-25154 #close
Reported by: Damian Ivereigh
Tested by: Damian Ivereigh

Change-Id: I5c16cf3b409e5ef9f2b2fe974b6bd2a45a6aa17e

When a BYE with an Also header is successfully processed, and the sender
of the BYE is bridged with another channel, chan_sip will unlock the
owner of the dialog on which the BYE was received, call ast_async_goto()
on the bridged channel, and then re-lock the owner. The reason for this
locking behavior is that ast_async_goto() can result in a masquerade,
which requires that the involved channels are unlocked.

The problem here is that this causes a locking inversion since the
dialog's lock is held when re-locking the owner channel after the async
goto. The lock order is supposed to be channel and then sip_pvt.

The fix proposed is simple. In addition to unlocking the owner channel
before the ast_async_goto() call, also unlock the sip_pvt. Then relock
both after ast_async_goto() returns, being sure to lock the channel and
then the sip_pvt.

ASTERISK-25139 #close
Reported by Gregory Massel

Change-Id: I72c4fc295ec8573bee599e8e9213c5350a3cd224