2013-01-25 14:01:04 +00:00
|
|
|
; Sample configuration file for Sorcery Data Access Layer
|
|
|
|
|
|
sorcery: Prevent duplicate objects and ensure missing objects are created on update
This patch resolves two issues in Sorcery objectset handling with multiple
backends:
1. Prevent duplicate objects:
When an object exists in more than one backend (e.g., a contact in both
'astdb' and 'realtime'), the objectset previously returned multiple instances
of the same logical object. This caused logic failures in components like the
PJSIP registrar, where duplicate contact entries led to overcounting and
incorrect deletions, when max_contacts=1 and remove_existing=yes.
This patch ensures only one instance of an object with a given key is added
to the objectset, avoiding these duplicate-related side effects.
2. Ensure missing objects are created:
When using multiple writable backends, a temporary backend failure can lead
to objects missing permanently from that backend.
Currently, .update() silently fails if the object is not present,
and no .create() is attempted.
This results in inconsistent state across backends (e.g. astdb vs. realtime).
This patch introduces a new global option in sorcery.conf:
[general]
update_or_create_on_update_miss = yes|no
Default: no (preserves existing behavior).
When enabled: if .update() fails with no data found, .create() is attempted
in that backend. This ensures that objects missing due to temporary backend
outages are re-synchronized once the backend is available again.
Added a new CLI command:
sorcery show settings
Displays global Sorcery settings, including the current value of
update_or_create_on_update_miss.
Updated tests to validate both flag enabled/disabled behavior.
Fixes: #1289
UserNote: Users relying on Sorcery multiple writable backends configurations
(e.g., astdb + realtime) may now enable update_or_create_on_update_miss = yes
in sorcery.conf to ensure missing objects are recreated after temporary backend
failures. Default behavior remains unchanged unless explicitly enabled.
2025-07-07 16:52:13 -04:00
|
|
|
[general]
|
|
|
|
|
|
|
|
|
|
; When true, writable Sorcery backends may attempt to insert the object
|
|
|
|
|
; if the object is missing.
|
|
|
|
|
; This helps re-populate missing backends when using multiple writable mappings
|
|
|
|
|
; (e.g., AstDB + Realtime) if a backend was temporarily unavailable.
|
|
|
|
|
; NOTE: This is best-effort and does not guarantee atomicity across backends.
|
|
|
|
|
; Default: no (preserves legacy behavior).
|
|
|
|
|
;
|
|
|
|
|
;update_or_create_on_update_miss = no
|
|
|
|
|
|
2013-01-25 14:01:04 +00:00
|
|
|
;
|
|
|
|
|
; Wizards
|
|
|
|
|
;
|
|
|
|
|
; Wizards are the persistence mechanism for objects. They are loaded as Asterisk modules and register
|
|
|
|
|
; themselves with the sorcery core. All implementation specific details of how objects are persisted is isolated
|
|
|
|
|
; within wizards.
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
;
|
|
|
|
|
; Caching
|
|
|
|
|
;
|
|
|
|
|
; A wizard can optionally be marked as an object cache by adding "/cache" to the object type within the mapping.
|
|
|
|
|
; If an object is returned from a non-object cache it is immediately given to the cache to be created. Multiple
|
|
|
|
|
; object caches can be configured for a single object type.
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
;
|
|
|
|
|
; Object Type Mappings
|
|
|
|
|
;
|
|
|
|
|
; To allow configuration of where and how an object is persisted object mappings can be defined within this file
|
|
|
|
|
; on a per-module basis. The mapping consists of the object type, options, wizard name, and wizard configuration
|
|
|
|
|
; data. This has the following format:
|
|
|
|
|
;
|
|
|
|
|
; object type [/options] = wizard name, wizard configuration data
|
|
|
|
|
;
|
|
|
|
|
; For example to configure an in-memory wizard for the 'bob' object type:
|
|
|
|
|
;
|
|
|
|
|
; bob = memory
|
|
|
|
|
;
|
|
|
|
|
; Or to configure the object type 'joe' from a configuration file:
|
|
|
|
|
;
|
|
|
|
|
; joe = config,joe.conf
|
|
|
|
|
;
|
|
|
|
|
; Note that an object type can have multiple mappings defined. Each mapping will be consulted in the order in which
|
|
|
|
|
; it appears within the configuration file. This means that if you are configuring a wizard as a cache it should
|
|
|
|
|
; appear as the first mapping so the cache is consulted before all other mappings.
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
;
|
|
|
|
|
; The following object mappings are used by the unit test to test certain functionality of sorcery.
|
|
|
|
|
;
|
2014-04-02 18:57:29 +00:00
|
|
|
[test_sorcery_section]
|
2013-01-25 14:01:04 +00:00
|
|
|
test=memory
|
|
|
|
|
|
|
|
|
|
[test_sorcery_cache]
|
|
|
|
|
test/cache=test
|
|
|
|
|
test=memory
|
|
|
|
|
|
2014-01-06 17:45:25 +00:00
|
|
|
;
|
|
|
|
|
; The following object mapping is the default mapping of external MWI mailbox
|
|
|
|
|
; objects to give persistence to the message counts.
|
|
|
|
|
;
|
|
|
|
|
;[res_mwi_external]
|
|
|
|
|
;mailboxes=astdb,mwi_external
|
|
|
|
|
|
2013-10-04 18:13:37 +00:00
|
|
|
;
|
|
|
|
|
; The following object mappings set PJSIP objects to use realtime database mappings from extconfig
|
|
|
|
|
; with the table names used when automatically generating configuration from the alembic script.
|
|
|
|
|
;
|
|
|
|
|
;[res_pjsip]
|
|
|
|
|
;endpoint=realtime,ps_endpoints
|
|
|
|
|
;auth=realtime,ps_auths
|
|
|
|
|
;aor=realtime,ps_aors
|
|
|
|
|
;domain_alias=realtime,ps_domain_aliases
|
2017-02-10 08:35:51 -07:00
|
|
|
|
|
|
|
|
;[res_pjsip_endpoint_identifier_ip]
|
2013-10-04 18:13:37 +00:00
|
|
|
;identify=realtime,ps_endpoint_id_ips
|
2017-04-07 13:35:33 +00:00
|
|
|
|
|
|
|
|
;[res_pjsip_outbound_publish]
|
|
|
|
|
;outbound-publish=realtime,ps_outbound_publishes
|
|
|
|
|
|
|
|
|
|
;[res_pjsip_pubsub]
|
|
|
|
|
;inbound-publication=realtime,ps_inbound_publications
|
|
|
|
|
|
|
|
|
|
;[res_pjsip_publish_asterisk]
|
|
|
|
|
;asterisk-publication=realtime,ps_asterisk_publications
|
Stir/Shaken Refactor
Why do we need a refactor?
The original stir/shaken implementation was started over 3 years ago
when little was understood about practical implementation. The
result was an implementation that wouldn't actually interoperate
with any other stir-shaken implementations.
There were also a number of stir-shaken features and RFC
requirements that were never implemented such as TNAuthList
certificate validation, sending Reason headers in SIP responses
when verification failed but we wished to continue the call, and
the ability to send Media Key(mky) grants in the Identity header
when the call involved DTLS.
Finally, there were some performance concerns around outgoing
calls and selection of the correct certificate and private key.
The configuration was keyed by an arbitrary name which meant that
for every outgoing call, we had to scan the entire list of
configured TNs to find the correct cert to use. With only a few
TNs configured, this wasn't an issue but if you have a thousand,
it could be.
What's changed?
* Configuration objects have been refactored to be clearer about
their uses and to fix issues.
* The "general" object was renamed to "verification" since it
contains parameters specific to the incoming verification
process. It also never handled ca_path and crl_path
correctly.
* A new "attestation" object was added that controls the
outgoing attestation process. It sets default certificates,
keys, etc.
* The "certificate" object was renamed to "tn" and had it's key
change to telephone number since outgoing call attestation
needs to look up certificates by telephone number.
* The "profile" object had more parameters added to it that can
override default parameters specified in the "attestation"
and "verification" objects.
* The "store" object was removed altogther as it was never
implemented.
* We now use libjwt to create outgoing Identity headers and to
parse and validate signatures on incoming Identiy headers. Our
previous custom implementation was much of the source of the
interoperability issues.
* General code cleanup and refactor.
* Moved things to better places.
* Separated some of the complex functions to smaller ones.
* Using context objects rather than passing tons of parameters
in function calls.
* Removed some complexity and unneeded encapsuation from the
config objects.
Resolves: #351
Resolves: #46
UserNote: Asterisk's stir-shaken feature has been refactored to
correct interoperability, RFC compliance, and performance issues.
See https://docs.asterisk.org/Deployment/STIR-SHAKEN for more
information.
UpgradeNote: The stir-shaken refactor is a breaking change but since
it's not working now we don't think it matters. The
stir_shaken.conf file has changed significantly which means that
existing ones WILL need to be changed. The stir_shaken.conf.sample
file in configs/samples/ has quite a bit more information. This is
also an ABI breaking change since some of the existing objects
needed to be changed or removed, and new ones added. Additionally,
if res_stir_shaken is enabled in menuselect, you'll need to either
have the development package for libjwt v1.15.3 installed or use
the --with-libjwt-bundled option with ./configure.
2023-10-26 10:27:35 -06:00
|
|
|
|
|
|
|
|
;[res_stir_shaken]
|
|
|
|
|
;tn=realtime,stir_tn
|