Updated the AudioSocket protocol to allow sending DTMF frames.
AST_FRAME_DTMF frames are now forwarded to the server, in addition to
AST_FRAME_AUDIO frames. A new payload type AST_AUDIOSOCKET_KIND_DTMF
with value 0x03 was added to the protocol. The payload is a 1-byte
ascii representing the DTMF digit (0-9,*,#...).
UserNote: The AudioSocket protocol now forwards DTMF frames with
payload type 0x03. The payload is a 1-byte ascii representing the DTMF
digit (0-9,*,#...).
(cherry picked from commit ea657ec7c7)
- Correct wait timeout logic in the dialplan application.
- Include server address in log messages for better traceability.
- Allow dialplan app to exit gracefully on hangup messages and socket closure.
- Optimize I/O by reducing redundant read()/write() operations.
Co-authored-by: Florent CHAUVEAU <florentch@pm.me>
(cherry picked from commit e8209bf56b)
CLI 'pjsip show contact' does not show enough information.
One must telnet to AMI or write a script to ask Asterisk for example what the User-Agent is on a Contact
This feature adds the same details as PJSIPShowContacts to the CLI
Resolves: #643
(cherry picked from commit abc8c5c93a)
1. When one channel is placed on hold, the device state is set to ONHOLD
without checking other channels states.
In case of AST_CONTROL_HOLD set the device state as AST_DEVICE_UNKNOWN
to calculate aggregate device state of all active channels.
2. The current implementation incorrectly classifies channels in use.
The only channels that has the states: UP, RING and BUSY are considered as "in use".
A channel should be considered "in use" if its state is anything other than
DOWN or RESERVED.
3. Currently, if the number of channels "in use" is greater than device_state_busy_at,
the system does not set the state to BUSY. Instead, it incorrectly assigns an aggregate
device state.
The endpoint device state should be BUSY if the number of channels "in use" is greater
than or equal to device_state_busy_at.
Fixes: #1181
(cherry picked from commit 03cf8c62ad)
Resolves an issue where the tcp_keepalive_enable option was not properly enabled in the sample configuration due to an incorrect default flag setting.
Fixes: #1149
(cherry picked from commit c4123901e5)
This reverts commit f30ad96b3f.
The original change was not RFC compliant and caused issues because it
set the RTP marker bit in cases when it shouldn't be set. See the
linked issue #1135 for a detailed explanation.
Fixes: #1135.
(cherry picked from commit a47fe8f84f)
Issues:
* The bridging core allowed multiple bridges to be created with the same
unique bridgeId at the same time. Only the last bridge created with the
duplicate name was actually saved to the core bridges container.
* The bridging core was creating a stasis topic for the bridge and saving it
in the bridge->topic field but not increasing its reference count. In the
case where two bridges were created with the same uniqueid (which is also
the topic name), the second bridge would get the _existing_ topic the first
bridge created. When the first bridge was destroyed, it would take the
topic with it so when the second bridge attempted to publish a message to
it it either FRACKed or SEGVd.
* The bridge destructor, which also destroys the bridge topic, is run from the
bridge manager thread not the caller's thread. This makes it possible for
an ARI developer to create a new one with the same uniqueid believing the
old one was destroyed when, in fact, the old one's destructor hadn't
completed. This could cause the new bridge to get the old one's topic just
before the topic was destroyed. When the new bridge attempted to publish
a message on that topic, asterisk could either FRACK or SEGV.
* The ARI bridges resource also allowed multiple bridges to be created with
the same uniqueid but it kept the duplicate bridges in its app_bridges
container. This created a situation where if you added two bridges with
the same "bridge1" uniqueid, all operations on "bridge1" were performed on
the first bridge created and the second was basically orphaned. If you
attempted to delete what you thought was the second bridge, you actually
deleted the first one created.
Changes:
* A new API `ast_bridge_topic_exists(uniqueid)` was created to determine if
a topic already exists for a bridge.
* `bridge_base_init()` in bridge.c and `ast_ari_bridges_create()` in
resource_bridges.c now call `ast_bridge_topic_exists(uniqueid)` to check
if a bridge with the requested uniqueid already exists and will fail if it
does.
* `bridge_register()` in bridges.c now checks the core bridges container to
make sure a bridge doesn't already exist with the requested uniqueid.
Although most callers of `bridge_register()` will have already called
`bridge_base_init()`, which will now fail on duplicate bridges, there
is no guarantee of this so we must check again.
* The core bridges container allocation was changed to reject duplicate
uniqueids instead of silently replacing an existing one. This is a "belt
and suspenders" check.
* A global mutex was added to bridge.c to prevent concurrent calls to
`bridge_base_init()` and `bridge_register()`.
* Even though you can no longer create multiple bridges with the same uniqueid
at the same time, it's still possible that the bridge topic might be
destroyed while a second bridge with the same uniqueid was trying to use
it. To address this, the bridging core now increments the reference count
on bridge->topic when a bridge is created and decrements it when the
bridge is destroyed.
* `bridge_create_common()` in res_stasis.c now checks the stasis app_bridges
container to make sure a bridge with the requested uniqueid doesn't already
exist. This may seem like overkill but there are so many entrypoints to
bridge creation that we need to be safe and catch issues as soon in the
process as possible.
* The stasis app_bridges container allocation was changed to reject duplicate
uniqueids instead of adding them. This is a "belt and suspenders" check.
* The `bridge show all` CLI command now shows the bridge name as well as the
bridge id.
* Response code 409 "Conflict" was added as a possible response from the ARI
bridge create resources to signal that a bridge with the requested uniqueid
already exists.
* Additional debugging was added to multiple bridging and stasis files.
Resolves: #211
(cherry picked from commit 46c9f7db8e)
The verification check for missing or anonymous callerid was happening before
the endpoint's profile was retrieved which meant that the failure_action
parameter wasn't available. Therefore, if verification was enabled and there
was no callerid or it was "anonymous", the call was immediately terminated
instead of giving the dialplan the ability to decide what to do with the call.
* The callerid check now happens after the verification context is created and
the endpoint's stir_shaken_profile is available.
* The check now processes the callerid failure just as it does for other
verification failures and respects the failure_action parameter. If set
to "continue" or "continue_return_reason", `STIR_SHAKEN(0,verify_result)`
in the dialplan will return "invalid_or_no_callerid".
* If the endpoint's failure_action is "reject_request", the call will be
rejected with `433 "Anonymity Disallowed"`.
* If the endpoint's failure_action is "continue_return_reason", the call will
continue but a `Reason: STIR; cause=433; text="Anonymity Disallowed"`
header will be added to the next provisional or final response.
Resolves: #1112
(cherry picked from commit 71551013c4)
Between ast_ari_channels_external_media(), external_media_rtp_udp(),
and external_media_audiosocket_tcp(), the `variables` structure being passed
around wasn't being cleaned up properly when there was a failure.
* In ast_ari_channels_external_media(), the `variables` structure is now
defined with RAII_VAR to ensure it always gets cleaned up.
* The ast_variables_destroy() call was removed from external_media_rtp_udp().
* The ast_variables_destroy() call was removed from
external_media_audiosocket_tcp(), its `endpoint` allocation was changed to
to use ast_asprintf() as external_media_rtp_udp() does, and it now
returns an error on failure.
* ast_ari_channels_external_media() now checks the new return code from
external_media_audiosocket_tcp() and sets the appropriate error response.
Resolves: #1109
(cherry picked from commit 5267c17645)
Introduce a ChannelTransfer event and the ability to notify progress to
ARI. Implement emitting this event from the PJSIP channel instead of
handling the transfer in Asterisk when configured.
Introduce a dialplan function to the PJSIP channel to switch between the
"core" and "ari-only" behavior.
UserNote: Call transfers on the PJSIP channel can now be controlled by
ARI. This can be enabled by using the PJSIP_TRANSFER_HANDLING(ari-only)
dialplan function.
(cherry picked from commit 71eb8a262f)
This process was a bit different than the others because everything
is in the same file, there's an array that contains the command
names and their handler functions, and the last command was created
over 15 years ago.
* Dump a `git blame` of res/res_agi.c from BEFORE the handle_* prototypes
were changed.
* Create a command <> handler function xref by parsing the the agi_command
array.
* For each entry, grep the function definition line "static int handle_*"
from the git blame output and capture the commit. This will be the
commit the command was created in.
* Do a `git tag --contains <commit> | sort -V | head -1` to get the
tag the function was created in.
* Add a single since/version element to the command XML. Multiple versions
aren't supported here because the branching and tagging scheme changed
several times in the 2000's.
(cherry picked from commit f1df1cacf6)
Also updates the 'since' of applications/functions that existed before
XML documentation was introduced (1.6.2.0).
(cherry picked from commit b4156fecf0)
When an incoming request can't be matched to an endpoint, the "artificial"
auth object is used to create a challenge to return in a 401 response and we
emit a "No matching endpoint found" log message. If the client then responds
with an Authorization header but the request still can't be matched to an
endpoint, the verification will fail and, as before, we'll create a challenge
to return in a 401 response and we emit a "No matching endpoint found" log
message. HOWEVER, because there WAS an Authorization header and it failed
verification, we should have also been emitting a "Failed to authenticate"
log message but weren't because there was a check that short-circuited that
it if the artificial auth was used. Since many admins use the "Failed to
authenticate" message with log parsers like fail2ban, those attempts were not
being recognized as suspicious.
Changes:
* digest_check_auth() now always emits the "Failed to authenticate" log
message if verification of an Authorization header failed even if the
artificial auth was used.
* The verification logic was refactored to be clearer about the handling
of the return codes from verify().
* Comments were added clarify what return codes digest_check_auth() should
return to the distributor and the implications of changing them.
Resolves: #1095
An issue in config_auth.c:ast_sip_auth_digest_algorithms_vector_init() was
causing double allocations for the two supported_algorithms vectors to the
tune of 915 bytes. The leak only happens on startup and when a reload is done
and doesn't get bigger with the number of auth objects defined.
* Pre-initialized the two vectors in config_auth:auth_alloc().
* Removed the allocations in ast_sip_auth_digest_algorithms_vector_init().
* Added a note to the doc for ast_sip_auth_digest_algorithms_vector_init()
noting that the vector passed in should be initialized and empty.
* Simplified the create_artificial_auth() function in pjsip_distributor.
* Set the vector initialization count to 0 in config_global:global_apply().
* Do a git blame on the embedded XML application or function element.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The applications and functions defined in the following files were done by
hand because the XML was extracted from the C source file relatively recently.
* channels/pjsip/dialplan_functions_doc.xml
* main/logger_doc.xml
* main/manager_doc.xml
* res/res_geolocation/geoloc_doc.xml
* res/res_stir_shaken/stir_shaken_doc.xml
(cherry picked from commit 85a4ab8390)
* Do a git blame on the embedded XML managerEvent elements.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The events defined in res/res_pjsip/pjsip_manager.xml were done by hand
because the XML was extracted from the C source file relatively recently.
Two bugs were fixed along the way...
* The get_documentation awk script was exiting after it processed the first
DOCUMENTATION block it found in a file. We have at least 1 source file
with multiple DOCUMENTATION blocks so only the first one in them was being
processed. The awk script was changed to continue searching rather
than exiting after the first block.
* Fixing the awk script revealed an issue in logger.c where the third
DOCUMENTATION block contained a XML fragment that consisted only of
a managerEventInstance element that wasn't wrapped in a managerEvent
element. Since logger_doc.xml already existed, the remaining fragments
in logger.c were moved to it and properly organized.
(cherry picked from commit a47b8e2d40)
This should resolve the Prometheus error:
> Error scraping target: non-compliant scrape target
sending blank Content-Type and no
fallback_scrape_protocol specified for target.
Resolves: #1075
(cherry picked from commit fa286641fb)
Most of the configObjects and configOptions that are implemented with
ACO or Sorcery now have `<since>/<version>` elements added. There are
probably some that the script I used didn't catch. The version tags were
determined by the following...
* Do a git blame on the API call that created the object or option.
* From the commit hash, grab the summary line.
* Do a `git log --grep <summary>` to find the cherry-pick commits in all
branches that match.
* Do a `git patch-id` to ensure the commits are all related and didn't get
a false match on the summary.
* Do a `git tag --contains <commit>` to find the tags that contain each
commit.
* Weed out all tags not <major>.<minor>.0.
* Sort and discard any <major>.0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the API was last touched.
configObjects and configOptions elements implemented with the base
ast_config APIs were just not possible to find due to the non-deterministic
way they are accessed.
Also note that if the API call was on modified after it was added, the
version will be the one it was last modified in.
Final note: The configObject and configOption elements were introduced in
12.0.0 so options created before then may not have any XML documentation.
(cherry picked from commit a22dc33057)
The return code fom digest_check_auth wasn't explicitly being initialized.
The return code also wasn't explicitly set to CHALLENGE when challenges
were sent. When optimization was turned off (DONT_OPTIMIZE), the compiler
was setting it to "0"(CHALLENGE) which worked fine. However, with
optimization turned on, it was setting it to "1" (SUCCESS) so if there was
no incoming Authorization header, the function was returning SUCCESS to the
distributor allowing the request to incorrectly succeed.
The return code is now initialized correctly and is now explicitly set
to CHALLENGE when we send challenges.
(cherry picked from commit 317b830c1e)
* channels/pjsip/dialplan_functions_doc.xml: Added xmlns:xi to docs element.
* main/bucket.c: Removed XML completely since the "bucket" and "file" objects
are internal only with no config file.
* main/named_acl.c: Fixed the configFile element name. It was "named_acl.conf"
and should have been "acl.conf"
* res/res_geolocation/geoloc_doc.xml: Added xmlns:xi to docs element.
* res/res_http_media_cache.c: Fixed the configFile element name. It was
"http_media_cache.conf" and should have been "res_http_media_cache.conf".
(cherry picked from commit 3b53152624)
* Added the "since" element to the XML configObject and configOption elements
in appdocsxml.dtd.
* Added the "Since" section to the following CLI output:
```
config show help <module> <object>
config show help <module> <object> <option>
core show application <app>
core show function <func>
manager show command <command>
manager show event <event>
agi show commands topic <topic>
```
* Refactored the commands above to output their sections in the same order:
Synopsis, Since, Description, Syntax, Arguments, SeeAlso
* Refactored the commands above so they all use the same pattern for writing
the output to the CLI.
* Fixed several memory leaks caused by failure to free temporary output
buffers.
* Added a "since" array to the mustache template for the top-level resources
(Channel, Endpoint, etc.) and to the paths/methods underneath them. These
will be added to the generated markdown if present.
Example:
```
"resourcePath": "/api-docs/channels.{format}",
"requiresModules": [
"res_stasis_answer",
"res_stasis_playback",
"res_stasis_recording",
"res_stasis_snoop"
],
"since": [
"18.0.0",
"21.0.0"
],
"apis": [
{
"path": "/channels",
"description": "Active channels",
"operations": [
{
"httpMethod": "GET",
"since": [
"18.6.0",
"21.8.0"
],
"summary": "List all active channels in Asterisk.",
"nickname": "list",
"responseClass": "List[Channel]"
},
```
NOTE: No versioning information is actually added in this commit.
Those will be added separately and instructions for adding and maintaining
them will be published on the documentation site at a later date.
(cherry picked from commit 3e28ddce78)
* Refactored pjproject code to support the new algorithms and
added a patch file to third-party/pjproject/patches
* Added new parameters to the pjsip auth object:
* password_digest = <algorithm>:<digest>
* supported_algorithms_uac = List of algorithms to support
when acting as a UAC.
* supported_algorithms_uas = List of algorithms to support
when acting as a UAS.
See the auth object in pjsip.conf.sample for detailed info.
* Updated both res_pjsip_authenticator_digest.c (for UAS) and
res_pjsip_outbound_authentocator_digest.c (UAC) to suport the
new algorithms.
The new algorithms are only available with the bundled version
of pjproject, or an external version > 2.14.1. OpenSSL version
1.1.1 or greater is required to support SHA-512-256.
Resolves: #948
UserNote: The SHA-256 and SHA-512-256 algorithms are now available
for authentication as both a UAS and a UAC.
(cherry picked from commit 1933548d41)
Added a new option "qualify_2xx_only" to the res_pjsip AOR qualify
feature to mark a contact as available only if an OPTIONS request
returns a 2XX response. If the option is not specified or is false,
any response to the OPTIONS request marks the contact as available.
UserNote: The pjsip.conf AOR section now has a "qualify_2xx_only"
option that can be set so that only 2XX responses to OPTIONS requests
used to qualify a contact will mark the contact as available.
(cherry picked from commit 85f5a047c1)
Whenever a slot is freed up due to a failed connection, wake up a waiter
before failing.
In the case of a dead connection there could be waiters, for example,
let's say two threads tries to acquire objects at the same time, with
one in the cached connections, one will acquire the dead connection, and
the other will enter into the wait state. The thread with the dead
connection will clear up the dead connection, and then attempt a
re-acquire (at this point there cannot be cached connections else the
other thread would have received that and tried to clean up), as such,
at this point we're guaranteed that either there are no waiting threads,
or that the maxconnections - connection_cnt threads will attempt to
re-acquire connections, and then either succeed, using those
connections, or failing, and then signalling to release more waiters.
Also fix the pointer log for ODBC handle %p dead which would always
reflect NULL.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
(cherry picked from commit 89ffbb5de7)
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 90cf13acd8)
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 badf203203)
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 be8f3a3fa4)
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 2ee258b0fc)
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 50bd50d798)
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 b8d818bd3c)
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 6763dda90f)
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 f3138af519)
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 243f20a78d)
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 b8b21b3f00)
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 7db8ae296c)
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 2d676c7560)
attest_level, send_mky and check_tn_cert_public_url weren't
propagating correctly from the attestation object to the profile
and tn.
* In the case of attest_level, the enum needed to be changed
so the "0" value (the default) was "NOT_SET" instead of "A". This
now allows the merging of the attestation object, profile and tn
to detect when a value isn't set and use the higher level value.
* For send_mky and check_tn_cert_public_url, the tn default was
forced to "NO" which always overrode the profile and attestation
objects. Their defaults are now "NOT_SET" so the propagation
happens correctly.
* Just to remove some redundant code in tn_config.c, a bunch of calls to
generate_sorcery_enum_from_str() and generate_sorcery_enum_to_str() were
replaced with a single call to generate_acfg_common_sorcery_handlers().
Resolves: #904
