Change-Id: I58bed58631a94295b267991c5b61a3a93c167f0c

The built frame format in audiohook_read_frame_both() is now set to a
signed linear format before the rx and tx frames are duplicated instead of
only for the mixed audio frame duplication.

ASTERISK-25322 #close
Reported by Sean Pimental

Change-Id: I86f85b5c48c49e4e2d3b770797b9d484250a1538

In chan_sip, after handling an incoming invite a security event is raised
describing authorization (success, failure, etc...). However, it was doing
a lookup of the peer by extension. This is fine for register messages, but
in the case of an invite it may search and find the wrong peer, or a non
existent one (for instance, in the case of call pickup). Also, if the peers
are configured through realtime this may cause an unnecessary database lookup
when caching is enabled.

This patch makes it so that sip_report_security_event searches by IP address
when looking for a peer instead of by extension after an invite is processed.

ASTERISK-25320 #close

Change-Id: I9b3f11549efb475b6561c64f0e6da1a481d98bc4

Due to the use of ast_websocket_close in session termination it is
possible for the underlying socket to already be closed when the
session is terminated. This occurs when the close frame is attempted
to be written out but fails.

Change-Id: I7572583529a42a7dc911ea77a974d8307d5c0c8b

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

This patch adds the .get callback to the format attribute module, such
that the Asterisk core or other third party modules can query for the
negotiated format attributes.

Change-Id: Ia24f55cf9b661d651ce89b4f4b023d921380f19c

Pressing DTMF digits on a phone to go out on a DAHDI channel can result in
the digit not being recognized or even heard by the peer.

Phone -> Asterisk -> DAHDI/channel

Turns out the DAHDI behavior with DTMF generation (and any other generated
tones) is exposed by the "buffers=" setting in chan_dahdi.conf.  When
Asterisk requests to start sending DTMF then DAHDI waits until its write
buffer is empty before generating any samples for the DTMF tones.  When
Asterisk subsequently requests DAHDI to stop sending DTMF then DAHDI
immediately stops generating the DTMF samples.  As a result, the more
samples there are in the DAHDI write buffer the shorter the time DTMF
actually gets sent on the wire.  If there are more samples in the write
buffer than the time DTMF is supposed to be sent then no DTMF gets sent on
the wire.  With the "buffers=12,half" setting and each buffer representing
20 ms of samples then the DAHDI write buffer is going to contain around
120 ms of samples.  For DTMF to be recognized by the peer the actual sent
DTMF duration needs to be a minimum of 40 ms.  Therefore, the intended
duration needs to be a minimum of 160 ms for the peer to receive the
minimum DTMF digit duration to recognize it.

A simple and effective solution to work around the DAHDI behavior is for
Asterisk to flush the DAHDI write buffer when sending DTMF so the full
duration of DTMF is actually sent on the wire.  When someone is going to
send DTMF they are not likely to be talking before sending the tones so
the flushed write samples are expected to just contain silence.

* Made dahdi_digit_begin() flush the DAHDI write buffer after requesting
to send a DTMF digit.

ASTERISK-25315 #close
Reported by John Hardin

Change-Id: Ib56262c708cb7858082156bfc70ebd0a220efa6a

There is a window of opportunity for DTMF to not go out if an audio frame
is in the process of being written to DAHDI while another thread starts
sending DTMF.  The thread sending the audio frame could be past the
currently dialing check before being preempted by another thread starting
a DTMF generation request.  When the thread sending the audio frame
resumes it will then cause DAHDI to stop the DTMF tone generation.  The
result is no DTMF goes out.

* Made dahdi_write() lock the private struct before writing to the DAHDI
file descriptor.

ASTERISK-25315
Reported by John Hardin

Change-Id: Ib4e0264cf63305ed5da701188447668e72ec9abb

If the saved SUBSCRIBE message is not parseable for whatever reason then
Asterisk could crash when libpjsip tries to parse the message and adds an
error message to the parse error list.

* Made ast_sip_create_rdata() initialize the parse error rdata list.  The
list is checked after parsing to see that it remains empty for the
function to return successful.

ASTERISK-25306
Reported by Mark Michelson

Change-Id: Ie0677f69f707503b1a37df18723bd59418085256

iLBC 20 was advertised in a SIP/SDP negotiation. However, only iLBC 30 is
supported. Removes "a=fmtp:x mode=y" from SDP. Because of RFC 3952 section 5,
only iLBC 30 is negotiated now.

ASTERISK-25309 #close

Change-Id: I92d724600a183eec3114da0ac607b994b1a793da

Some codecs that may be a third party library to Asterisk need to have
knowledge of the format attributes that were negotiated. Unfortunately,
when the great format migration of Asterisk 13 occurred, that ability
was lost.

This patch adds an API call, ast_format_attribute_get, to the core
format API, along with updates to the unit test to check the new API
call. A new callback is also now available for format attribute modules,
such that they can provide the format attribute values they manage.

Note that the API returns a void *. This is done as the format attribute
modules themselves may store format attributes in any particular manner
they like. Care should be taken by consumers of the API to check the
return value before casting and dereferencing. Consumers will obviously
need to have a priori knowledge of the type of the format attribute as
well.

Change-Id: Ieec76883dfb46ecd7aff3dc81a52c81f4dc1b9e3

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

clock_gettime() is, unfortunately, not portable. But I did like that
over our usual `ts.tv_nsec = tv.tv_usec * 1000` copy/paste code we
usually do when we want a timespec and all we have is ast_tvnow().

This patch adds ast_tsnow(), which mimics ast_tvnow(), but returns a
timespec. If clock_gettime() is available, it will use that. Otherwise
ast_tsnow() falls back to using ast_tvnow().

Change-Id: Ibb1ee67ccf4826b9b76d5a5eb62e90b29b6c456e

An http request can be sent to get the existing Asterisk logs.

The command "curl -v -u user:pass -X GET 'http://localhost:8088
/ari/asterisk/logging'" can be run in the terminal to access the
newly implemented functionality.

* Retrieve all existing log channels

ASTERISK-25252

Change-Id: I7bb08b93e3b938c991f3f56cc5d188654768a808

An http request can be sent to create a log channel
in Asterisk.

The command "curl -v -u user:pass -X POST
'http://localhost:088/ari/asterisk/logging/mylog?
configuration=notice,warning'" can be run in the terminal
to access the newly implemented functionality for ARI.

* Ability to create log channels using ARI

ASTERISK-25252

Change-Id: I9a20e5c75716dfbb6b62fd3474faf55be20bd782

An http request can be sent to delete a log channel
in Asterisk.

The command "curl -v -u user:pass -X DELETE 'http://localhost:8088
/ari/asterisk/logging/mylog'" can be run in the terminal
to access the newly implemented functionally for ARI.

* Able to delete log channels using ARI

ASTERISK-25252

Change-Id: Id6eeb54ebcc511595f0418d586ff55914bc3aae6

The pjsip_rx_data structure has a pkt_info.packet field on it that is
the packet that was read from the transport. For datagram transports,
the packet read from the transport will correspond to the SIP message
that arrived. For streamed transports, however, it is possible to read
multiple SIP messages in one packet.

In a recent case, Asterisk crashed on a system where TCP was being used.
This is because at some point, a read from the TCP socket resulted in a
200 OK response as well as an incoming SUBSCRIBE request being stored in
rdata->pkt_info.packet. When the SUBSCRIBE was processed, the
combination 200 OK and SUBSCRIBE was saved in persistent storage. Later,
a restart of Asterisk resulted in the crash because the persistent
subscription recreation code ended up building the 200 OK response
instead of a SUBSCRIBE request, and we attempted to access
request-specific data.

The fix here is to use the pjsip_msg_print() function in order to
persist SUBSCRIBE requests. This way, rather than using the raw socket
data, we use the parsed SIP message that PJSIP has given us. If we
receive multiple SIP messages from a single read, we will be sure only
to save off the relevant SIP message. There also is a safeguard put in
place to make sure that if we do end up reconstructing a SIP response,
it will not cause a crash.

ASTERISK-25306 #close
Reported by Mark Michelson

Change-Id: I4bf16f7b76a2541d10b55de82bcd14c6e542afb2

The ast_sip_sanitize_xml function is used to sanitize
a string for placement into XML. This is done by examining
an input string and then appending values to an output
buffer. The function used by its implementation, strncat,
has specific behavior that was not taken into account.
If the size of the input string exceeded the available
output buffer size it was possible for the sanitization
function to write past the output buffer itself causing
a crash. The crash would either occur because it was
writing into memory it shouldn't be or because the resulting
string was not NULL terminated.

This change keeps count of how much remaining space is
available in the output buffer for text and only allows
strncat to use that amount.

Since this was exposed by the res_pjsip_pidf_digium_body_supplement
module attempting to send a large message the maximum allowed
message size has also been increased in it.

A unit test has also been added which confirms that the
ast_sip_sanitize_xml function is providing NULL terminated
output even when the input length exceeds the output
buffer size.

ASTERISK-25304 #close

Change-Id: I743dd9809d3e13d722df1b0509dfe34621398302

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

Commit 39cc28f6 attempted to fix a
test failure observed on 32 bit test agents by ensuring that a cast from
a 32 bit unsigned integer to a 64 bit unsigned integer was happening in
a predictable place. As it turns out, this did not cause test runs to
succeed.

This commit adds several redundant debug messages that print the payload
lengths of websocket frames. The idea here is that this commit will not
cause tests to succeed for the faulty test agent, but we might deduce
where the fault lies more easily this way by observing at what point the
expected value (537) changes to some ungangly huge number.

If you are wondering why something like this is being committed to the
branch, keep in mind that in commit
39cc28f6 I noted that the observed test
failures only happen when automated tests are run. Attempts to run the
tests by hand manually on the test agent result in the tests passing.

Change-Id: I14a65c19d8af40dadcdbd52348de3b0016e1ae8d

We have seen a rash of test failures on a 32-bit build agent. Commit
48698a5e solved an obvious problem where
we were not encoding a 64-bit value correctly over the wire. This
commit, however, did not solve the test failures.

In the failing tests, ARI is attempting to send a 537 byte text frame
over a websocket. When sending a frame this small, 16 bits are all that
is required in order to encode the payload length on the websocket
frame. However, ast_websocket_write() thinks that the payload length is
greater than 65535 and therefore writes out a 64 bit payload length.
Inspecting this payload length, the lower 32 bits are exactly what we
would expect it to be, 537 in hex. The upper 32 bits, are junk values
that are not expected to be there.

In the failure, we are passing the result of strlen() to a function that
expects a uint64_t parameter to be passed in. strlen() returns a size_t,
which on this 32-bit machine is 32 bits wide. Normally, passing a 32-bit
unsigned value to somewhere where a 64-bit unsigned value is expected
would cause no problems. In fact, in manual runs of failing tests, this
works just fine. However, ast_websocket_write() uses the Asterisk
optional API, which means that rather than a simple function call, there
are a series of macros that are used for its declaration and
implementation. These macros may be causing some sort of error to occur
when converting from a 32 bit quantity to a 64 bit quantity.

This commit changes the logic by making existing ast_websocket_write()
calls use ast_websocket_write_string() instead. Within
ast_websocket_write_string(), the 64-bit converted strlen is saved in a
local variable, and that variable is passed to ast_websocket_write()
instead.

Note that this commit message is full of speculation rather than
certainty. This is because the observed test failures, while always
present in automated test runs, never occur when tests are manually
attempted on the same test agent. The idea behind this commit is to fix
a theoretical issue by performing changes that should, at the least,
cause no harm. If it turns out that this change does not fix the failing
tests, then this commit should be reverted.

Change-Id: I4458dd87d785ca322b89c152b223a540a3d23e67