Although C++ files (as extension .cc) have been handled in the module
directories for many years, the main directory was missing one line in its
Makefile that prevented C++ files from being recognised there.
(cherry picked from commit 882f21c5bc)
Sometimes it's impossible to get a file extension from URL
(eg. http://example.com/gsm/your) so we have to rely on content-type header.
Currenly, asterisk does not support content-type for gsm format(unlike wav).
Added audio/gsm according to https://www.rfc-editor.org/rfc/rfc4856.html
(cherry picked from commit 877449ddf5)
This function is useful for uniquely identifying calls, recordings, and other entities in distributed environments, as well as for generating an argument for the AudioSocket application.
(cherry picked from commit e9220e80f9)
Fixes: #1007
UserNote: use the p option of AddQueueMember() for paused member state.
Optionally, use the r(reason) option to specify a custom reason for the pause.
(cherry picked from commit 1689aaa576)
Add a log message for a path that currently silently drops IAX2
frames without indicating that anything is wrong.
(cherry picked from commit 949cca09a8)
Currently, when a chan_pjsip channel receives a VIDUPDATE indication,
an RTP VIDUPDATE frame is only queued on a H.264 stream if WebRTC is
enabled on that endpoint. This restriction does not really make sense.
Now, a VIDUPDATE RTP frame is written even if WebRTC is not enabled (as
is the case with VP8, VP9, and H.265 streams).
Resolves: #1013
(cherry picked from commit 63ae96c6e7)
When there is 0% packet loss on one side of the call and 15% packet loss on the other side, reading frame is often failed when reading direction_both audiohook. when read_factory available = 0, write_factory available = 320; i think write factory is usable read; because after reading one frame, there is still another frame that can be read together with the next read factory frame.
Resolves: #851
(cherry picked from commit a37bac6b86)
This update properly documents all the current configuration options supported
by the curl implementation, including the new ssl_* options.
(cherry picked from commit 01cbaffbdf)
This update adds the processed call count to the CoreStatus AMI Action responsie. This output is
similar to the values returned by "core show channels" or "core show calls" in the CLI.
UserNote: The current processed call count is now returned as CoreProcessedCalls from the
CoreStatus AMI Action.
(cherry picked from commit dd0b3e713a)
This patch adds additional CURL TLS options / options to support mTLS authenticated requests:
* ssl_verifyhost - perform a host verification on the peer certificate (CURLOPT_SSL_VERIFYHOST)
* ssl_cainfo - define a CA certificate file (CURLOPT_CAINFO)
* ssl_capath - define a CA certificate directory (CURLOPT_CAPATH)
* ssl_cert - define a client certificate for the request (CURLOPT_SSLCERT)
* ssl_certtype - specify the client certificate type (CURLOPT_SSLCERTTYPE)
* ssl_key - define a client private key for the request (CURLOPT_SSLKEY)
* ssl_keytype - specify the client private key type (CURLOPT_SSLKEYTYPE)
* ssl_keypasswd - set a password for the private key, if required (CURLOPT_KEYPASSWD)
UserNote: The following new configuration options are now available
in the res_curl.conf file, and the CURL() function: 'ssl_verifyhost'
(CURLOPT_SSL_VERIFYHOST), 'ssl_cainfo' (CURLOPT_CAINFO), 'ssl_capath'
(CURLOPT_CAPATH), 'ssl_cert' (CURLOPT_SSLCERT), 'ssl_certtype'
(CURLOPT_SSLCERTTYPE), 'ssl_key' (CURLOPT_SSLKEY), 'ssl_keytype',
(CURLOPT_SSLKEYTYPE) and 'ssl_keypasswd' (CURLOPT_KEYPASSWD). See the
libcurl documentation for more details.
(cherry picked from commit fdd916e590)
Commit 466eb4a52b introduced a regression
which completely broke Feature Group D and E911 signaling, by removing
the call to analog_my_getsigstr, which affected multiple switch cases.
Restore the original behavior for all protocols except Feature Group C
CAMA (MF), which is all that patch was attempting to target.
Resolves: #993
(cherry picked from commit d69f2722b6)
Added a new option "unknown_tn_attest_level" to allow Identity
headers to be sent when a callerid TN isn't explicitly configured
in stir_shaken.conf. Since there's no TN object, a private_key_file
and public_cert_url must be configured in the attestation or profile
objects.
Since "unknown_tn_attest_level" uses the same enum as attest_level,
some of the sorcery macros had to be refactored to allow sharing
the enum and to/from string conversion functions.
Also fixed a memory leak in crypto_utils:pem_file_cb().
Resolves: #921
UserNote: You can now set the "unknown_tn_attest_level" option
in the attestation and/or profile objects in stir_shaken.conf to
enable sending Identity headers for callerid TNs not explicitly
configured.
(cherry picked from commit 9e5cac457f)
When using the ListCategories AMI action, it was possible to traverse
upwards through the directories to files outside of the configured
configuration directory. This action is now restricted to the configured
directory and an error will now be returned if the specified file is
outside of this limitation.
Resolves: #GHSA-33x6-fj46-6rfh
UserNote: The ListCategories AMI action now restricts files to the
configured configuration directory.
The suppress_moh_on_sendonly endpoint option should have been
defined as OPT_BOOL_T in pjsip_configuration.c and AST_BOOL_VALUES
in the alembic script instead of OPT_YESNO_T and YESNO_VALUES.
Also updated contrib/ast-db-manage/README.md to indicate that
AST_BOOL_VALUES should always be used and provided an example.
Resolves: #995
Normally, when one party in a call sends Asterisk an SDP with
a "sendonly" or "inactive" attribute it means "hold" and causes
Asterisk to start playing MOH back to the other party. This can be
problematic if it happens at certain times, such as in a 183
Progress message, because the MOH will replace any early media you
may be playing to the calling party. If you set this option
to "yes" on an endpoint and the endpoint receives an SDP
with "sendonly" or "inactive", Asterisk will NOT play MOH back to
the other party.
Resolves: #979
UserNote: The new "suppress_moh_on_sendonly" endpoint option
can be used to prevent playing MOH back to a caller if the remote
end sends "sendonly" or "inactive" (hold) to Asterisk in an SDP.
(cherry picked from commit 98510d4c75)
The tenantid field was originally added to the ast_sip_endpoint
structure at the end of the AST_DECLARE_STRING_FIELDS block. This
caused everything after it in the structure to move down in memory
and break ABI compatibility. It's now at the end of the structure
as an AST_STRING_FIELD_EXTENDED. Given the number of string fields
in the structure now, the initial string field allocation was
also increased from 64 to 128 bytes.
Resolves: #982
(cherry picked from commit 3dfac27ef2)
The key used for transport monitors was the remote host name for the
transport and not the remote address resolved for this domain.
This was problematic for domains returning multiple addresses as several
transport monitors were created with the same key.
Whenever a subsystem wanted to register a callback it would always end
up attached to the first transport monitor with a matching key.
The key used for transport monitors is now the remote address and port
the transport actually connected to.
Fixes: #932
(cherry picked from commit d1ed1018c4)
This adds an EVAL_SUB function, which is similar to the existing
EVAL_EXTEN function but significantly more powerful, as it allows
executing arbitrary dialplan and capturing its return value as
the function's output. While EVAL_EXTEN should be preferred if it
is possible to use it, EVAL_SUB can be used in a wider variety
of cases and allows arbitrary computation to be performed in
a dialplan function call, leveraging the dialplan.
Resolves: #951
(cherry picked from commit 5a4026d080)
There's really no point in spamming logs with a verbose message
for every unsupported crypto suite an older client may send
in an SDP. If none are supported, there will be an error or
warning.
(cherry picked from commit 39ed13940b)
Adds res_pjsip_config_sangoma as an external module that can be
downloaded via menuselect. It lives under the Resource Modules section.
(cherry picked from commit 4f1987f21e)
Adds the 'D' option to app_mixmonitor that interleaves the input and
output frames of the channel being recorded in the monitor output frame.
This allows for two streams in the recording: the transmitted audio and
the received audio. The 't' and 'r' options are compatible with this.
Fixes: #945
UserNote: The MixMonitor application now has a new 'D' option which
interleaves the recorded audio in the output frames. This allows for
stereo recording output with one channel being the transmitted audio and
the other being the received audio. The 't' and 't' options are
compatible with this.
(cherry picked from commit 6c2cbac384)
When a transport is disconnected, several events can arrive following
each other. The first event will be PJSIP_TP_STATE_DISCONNECT and it
will trigger the destruction of the transport monitor object. The lookup
for the transport monitor to destroy is done using the transport key,
that contains the transport destination host:port.
A reconnect attempt by pjsip will be triggered as soon something needs to
send a packet using that transport. This can happen directly after a
disconnect since ca
Subsequent events can arrive later like PJSIP_TP_STATE_DESTROY and will
also try to trigger the destruction of the transport monitor if not
already done. Since the lookup for the transport monitor to destroy is
done using the transport key, it can match newly created transports
towards the same destination and destroy their monitor object.
Because of this, it was sometimes not possible to monitor a transport
after one or more disconnections.
This fix adds an additional check on the transport pointer to ensure
only a monitor for that specific transport is removed.
Fixes: #923
(cherry picked from commit 03e08d5c33)
If to_answer is -1, simply comparing to see if the progress timeout
is smaller than the answer timeout to prefer it will fail. Add
an additional check that chooses the progress timeout if there is
no answer timeout (or as before, if the progress timeout is smaller).
Resolves: #821
(cherry picked from commit 6a6f962acb)
* pjproject is now configured with --disable-libsrtp so it will
build correctly when doing "out-of-tree" development. Asterisk
doesn't use pjproject for handling media so pjproject doesn't
need libsrtp itself.
* The pjsua app (which we used to use for the testsuite) no longer
builds in pjproject's master branch so we just skip it. The
testsuite no longer needs it anyway.
See third-party/pjproject/README-hacking.md for more info on building
pjproject "out-of-tree".
(cherry picked from commit 97ad7256d7)
This reverts commit cb5e3445be.
The original change from 16 to 15 bit sequence numbers was predicated
on the following from the now-defunct libSRTP FAQ on sourceforge.net:
> *Q6. The use of implicit synchronization via ROC seems
> dangerous. Can senders and receivers lose ROC synchronization?*
>
> **A.** It is possible to lose ROC synchronization between sender and
> receiver(s), though it is not likely in practice, and practical
> steps can be taken to avoid it. A burst loss of 2^16 packets or more
> will always break synchronization. For example, a conversational
> voice codec that sends 50 packets per second will have its ROC
> increment about every 22 minutes. A network with a burst of packet
> loss that long has problems other than ROC synchronization.
>
> There is a higher sensitivity to loss at the very outset of an SRTP
> stream. If the sender's initial sequence number is close to the
> maximum value of 2^16-1, and all packets are lost from the initial
> packet until the sequence number cycles back to zero, the sender
> will increment its ROC, but the receiver will not. The receiver
> cannot determine that the initial packets were lost and that
> sequence-number rollover has occurred. In this case, the receiver's
> ROC would be zero whereas the sender's ROC would be one, while their
> sequence numbers would be so close that the ROC-guessing algorithm
> could not detect this fact.
>
> There is a simple solution to this problem: the SRTP sender should
> randomly select an initial sequence number that is always less than
> 2^15. This ensures correct SRTP operation so long as fewer than 2^15
> initial packets are lost in succession, which is within the maximum
> tolerance of SRTP packet-index determination (see Appendix A and
> page 14, first paragraph of RFC 3711). An SRTP receiver should
> carefully implement the index-guessing algorithm. A naive
> implementation can unintentionally guess the value of
> 0xffffffffffffLL whenever the SEQ in the packet is greater than 2^15
> and the locally stored SEQ and ROC are zero. (This can happen when
> the implementation fails to treat those zero values as a special
> case.)
>
> When ROC synchronization is lost, the receiver will not be able to
> properly process the packets. If anti-replay protection is turned
> on, then the desynchronization will appear as a burst of replay
> check failures. Otherwise, if authentication is being checked, then
> it will appear as a burst of authentication failures. Otherwise, if
> encryption is being used, the desynchronization may not be detected
> by the SRTP layer, and the packets may be improperly decrypted.
However, modern libSRTP (as of 1.0.1[1]) now mentions the following in
their README.md[2]:
> The sequence number in the rtp packet is used as the low 16 bits of
> the sender's local packet index. Note that RTP will start its
> sequence number in a random place, and the SRTP layer just jumps
> forward to that number at its first invocation. An earlier version
> of this library used initial sequence numbers that are less than
> 32,768; this trick is no longer required as the
> rdbx_estimate_index(...) function has been made smarter.
So truncating our initial sequence number to 15 bit is no longer
necessary.
1. 0eb007f0dc/CHANGES (L271-L289)
2. 2de20dd9e9/README.md (implementation-notes)
(cherry picked from commit e6ad08bb74)
When the channel tech is multistream capable, the reference to
chan_topology was passed to the new channel. When the channel tech
isn't multistream capable, the reference to chan_topology was never
released. "Local" channels are multistream capable so it didn't
affect them but the confbridge "CBAnn" and the bridge_media
"Recorder" channels are not so they caused a leak every time one
of them was created.
Also added tracing to ast_stream_topology_alloc() and
stream_topology_destroy() to assist with debugging.
Resolves: #938
(cherry picked from commit ac7cd9d407)
The dnsmgr_refresh() function checks to see if the IP address associated
with a name/service has changed. The gotcha is that the ast_get_ip_or_srv()
function only returns the first IP address returned by the DNS query. If
there are multiple IPs associated with the name and the returned order is
not consistent (e.g. with DNS round-robin) then the other IP addresses are
not included in the comparison and the entry is flagged as changed even
though the IP is still valid.
Updated the code to check all IP addresses and flag a change only if the
original IP is no longer valid.
Resolves: #924
(cherry picked from commit 7223bddffb)
Under some circumstances, the progress timeout feature added in commit
320c98eec8 does not work as expected,
such as if there is no media flowing. Adjust the waitfor call to
explicitly use the progress timeout if it would be reached sooner than
the answer timeout to ensure we handle the timers properly.
Resolves: #821
(cherry picked from commit b4dadd8ea5)
In some circumstances, it is possible for the do_monitor thread to
erroneously think that a line is on-hook and send an MWI FSK spill
to it when the line is really off-hook and no MWI should be sent.
Commit 0a8b3d3467 previously fixed this
issue in a more readily encountered scenario, but it has still been
possible for MWI to be sent when it shouldn't be. To robustly fix
this issue, query DAHDI for the hook status to ensure we don't send
MWI on a line that is actually still off hook.
Resolves: #928
(cherry picked from commit 0a6a962ad7)
This unit test checks that dialplan apps and app data specified
as parameters for the Originate action are allowed with the
permissions the user has.
(cherry picked from commit 89c6557fc1)
Calls to `ast_replace_sigchld()` and `ast_unreplace_sigchld()` must be
balanced to ensure that we can capture the exit status of child
processes when we need to. This extends to functions that call
`ast_replace_sigchld()` and `ast_unreplace_sigchld()` such as
`ast_safe_fork()` and `ast_safe_fork_cleanup()`.
The primary change here is ensuring that we do not call
`ast_safe_fork_cleanup()` in `res_agi.c` if we have not previously
called `ast_safe_fork()`.
Additionally we reinforce some of the documentation and add an
assertion to, ideally, catch this sooner were this to happen again.
Fixes#922
(cherry picked from commit 750333ae03)
asterisk.c, manager.c: Increase buffer sizes to avoid truncation warnings.
config.c: Include header file for WIFEXITED/WEXITSTATUS macros.
res_timing_kqueue: Use more portable format specifier.
test_crypto: Use non-linux limits.h header file.
Resolves: #916
(cherry picked from commit c807f39267)
In dtls_srtp_handle_timeout(), when DTLSv1_get_timeout() returned
success but with a timeout of 0, we were stopping the timer and
decrementing the refcount on instance but not resetting the
timeout_timer to -1. When dtls_srtp_stop_timeout_timer()
was later called, it was atempting to stop a stale timer and could
decrement the refcount on instance again which would then cause
the instance destructor to run early. This would result in either
a FRACK or a SEGV when ast_rtp_stop(0 was called.
According to the OpenSSL docs, we shouldn't have been stopping the
timer when DTLSv1_get_timeout() returned success and the new timeout
was 0 anyway. We should have been calling DTLSv1_handle_timeout()
again immediately so we now reschedule the timer callback for
1ms (almost immediately).
Additionally, instead of scheduling the timer callback at a fixed
interval returned by the initial call to DTLSv1_get_timeout()
(usually 999 ms), we now reschedule the next callback based on
the last call to DTLSv1_get_timeout().
Resolves: #487
(cherry picked from commit 8f82b8cfc1)
When using the ModuleLoad AMI action, it was possible to traverse
upwards through the directories to files outside of the configured
modules directory. We decided it would be best to restrict access to
modules exclusively in the configured directory. You will now get an
error when the specified module is outside of this limitation.
Fixes: #897
UserNote: The ModuleLoad AMI action now restricts modules to the
configured modules directory.
(cherry picked from commit 98380812c0)
When using the speech recognition module, crashes can occur
sporadically due to a "double free or corruption (out)" error. Now, in
the section where the audio stream is being captured in a loop, each
time after releasing fr, it is set to NULL to prevent repeated
deallocation.
Fixes#772
(cherry picked from commit 5bd7403fed)
