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
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
With `sounds_search_custom_dir = yes` we first look to see if a sound file
is present in the "custom" sound directory before looking in the standard
sound directories. We should not be issuing a WARNING log message if a
sound cannot be found in the "custom" directory.
Resolves: https://github.com/asterisk/asterisk/issues/1170
Gosub and Goto were not displaying their syntax correctly on the docs
site. This change adds a new way to specify an optional context, an
optional extension, and a required priority that the xml stylesheet can
parse without having to know which optional parameters come in which
order. In Asterisk, it looks like this:
parameter name="context" documentationtype="dialplan_context"
parameter name="extension" documentationtype="dialplan_extension"
parameter name="priority" documentationtype="dialplan_priority" required="true"
The stylesheet will ignore the context and extension parameters, but for
priority, it will automatically inject the following:
[[context,]extension,]priority
This is the correct oder for applications such as Gosub and Goto.
Commit e86f937e added AMI documentation to the module but the cherry-pick
from master to the 20 branch pulled in an xpointer reference to the
`user_agent` config option which doesn't actually exist in 20. This causes
asterisk to fail to start because it can't load the core-en_US.xml
documentation file. The CI cherry-pick tests should have caught this but
there was bug in the cherry-picker that was causing the commits to be
cherry-picked to the wrong branch. Just removing the xpointer reference
resolves the issue.
* Outdated information has been removed.
* New links added.
* Placeholder added for link to change logs.
Going forward, the release process will create HTML versions of the README
and change log and will update the link in the README to the current
change log for the branch...
* In the development branches, the link will always point to the current
release on GitHub.
* In the "releases/*" branches and the tarballs, the link will point to the
ChangeLogs/ChangeLog-<version>.html file in the source directory.
* On the downloads website, the link will point to the
ChangeLog-<version>.html file in the same directory.
Resolves: #1131
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
The `CreateConfig` manager action now ensures that a config file can
only be created in the AST_CONFIG_DIR unless `live_dangerously` is set.
Resolves: #1122
Recent python versions complain when backslashes in strings create invalid
escape sequences. This causes issues for strings used as regex patterns like
`'^List\[(.*)\]$'` where you want the regex parser to treat `[` and `]`
as literals. Double-backslashing is one way to fix it but simply converting
the string to a raw string `re.match(r'^List\[(.*)\]$', text)` is easier
and less error prone.
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.
Found via `codespell -q 3 -S "./CREDITS,*.po" -L abd,asent,atleast,cachable,childrens,contentn,crypted,dne,durationm,enew,exten,inout,leapyear,mye,nd,oclock,offsetp,ot,parm,parms,preceeding,pris,ptd,requestor,re-use,re-used,re-uses,ser,siz,slanguage,slin,thirdparty,varn,varns,ues`
Found via `codespell -q 3 -S "./CREDITS" -L abd,asent,atleast,childrens,contentn,crypted,dne,durationm,exten,inout,leapyear,nd,oclock,offsetp,ot,parm,parms,requestor,ser,slanguage,slin,thirdparty,varn,varns,ues`
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
GitHub strikes again. Apparently the github.ref context variable only
contains the PR number if the workflow is triggered by "pull_request" so
since we just changed the trigger to "pull_request_target" the variable
no longer contains the PR number and is therefore not unique and can't be
used as a concurrency group id. We now use
`github.triggering_actor-github.head_ref`.
Due to a potential race condition via ARI when hanging up a channel hangup with cause
while also deleting a bridge containing that channel, the bridge delete can over-write
the hangup cause code resulting in Normal Call Clearing instead of the set value.
With this change, bridge deletion will only set the hangup code if it hasn't been
previously set.
Resolves: #1124
After careful review, we believe we can now use the "pull_request_target"
workflow trigger instead of "pull_request" which required a separate
privliged workflow to add labels and comments to PRs when they are submitted
or updated. This allows us to greatly streamline our workflows and remove
unneeded ones.
* The OnPRChanged workflow was...
* Renamed to OnPRCheck
* Changed to trigger on pull_request_target and the "recheckpr" label.
* Changed to simply call reusable workflows in asterisk-ci-actions.
* Changed to use better concurrency groups.
* The OnPRCPCheck and OnPRMergeApproved workflows were also...
* Changed to simply call reusable workflows in asterisk-ci-actions.
* Changed to use better concurrency groups.
* The NightlyTest and CreateDocs were also tweaked
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
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
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.
Nothing ever sets the `AST_GENERATOR_FD`, so this block of code will
never execute. It also is the only place where the `generate` callback
is called with the channel lock held which made it difficult to reason
about the thread safety of `ast_generator`s.
In passing, also note that `AST_AGENT_FD` isn't used either.
When in single-argument mode (very rarely used), a malformation of a column
name (also very rare) could cause a NULL to be returned when retrieving the
channel variable for that column. Passing that to strncat causes a SEGV. We
now check for the NULL and print a warning message.
Resolves: #1101
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.
Newer versions of gcc now warn about old style definitions, such
as those in libdb, which causes compilation failure with DEVMODE
enabled. Ignore these warnings for libdb.
Resolves: #1085
* Dump a git blame of each file in rest-api/api-docs.
* Get the commit for each "resourcePath" and "httpMethod" entry.
* Find the tags for each commit (same as other processes).
* Insert a "since" array after each "resourcePath" and "httpMethod" entry.
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
This commit doesn't actually change anything. It just adds the following
upgrade notes that were omitted from the original commits.
Resolves: #1097
UpgradeNote: Two commits in this release...
'Add SHA-256 and SHA-512-256 as authentication digest algorithms'
'res_pjsip: Add new AOR option "qualify_2xx_only"'
...have modified alembic scripts for the following database tables: ps_aors,
ps_contacts, ps_auths, ps_globals. If you don't use the scripts to update
your database, reads from those tables will succeeed but inserts into the
ps_contacts table by res_pjsip_registrar will fail.
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
* 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.
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
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.
