Make sure buf[res] is not accessed at res=-1 (buffer underrun).
Address Sanitizer will complain about this quite loudly.
ASTERISK-24801 #close
Change-Id: Ifcd7f691310815a31756b76067c56fba299d3ae9
You have to call ast_taskprocessor_unref() outside of the taskprocessor
implementation code. Taskprocessor use since v12 has become more
transient than just the singleton uses in earlier versions.
Change-Id: If7675299924c0cc65f2a43a85254e6f06f2d61bb
This removes logchannels locking from init_logger_chain, puts the
responsibility on the caller. Adds locking around the one call that was
missing it.
ASTERISK-24833
Change-Id: I6cc42117338bf9575650a67bcb78ab1a33d7bad8
The xferfailsound was read from the channel at the beginning of the transfer,
and that value is "cached" for the duration of the transfer. Therefore, changing
the xferfailsound on the channel using the FEATURE() dialplan function does
nothing once the transfer is under way.
This makes it so the transfer code instead gets the xferfailsound configuration
options from the channel when it is actually going to be used.
This patch also fixes a potential memory leak of the props object as well as
making sure the condition variable gets initialized before being destroyed.
ASTERISK-25696 #close
Change-Id: Ic726b0f54ef588bd9c9c67f4b0e4d787934f85e4
* Add freed regions totals to allocations and summary.
* Add totals for all allocations and not just the selected allocations.
Change-Id: I61d5a5112617b0733097f2545a3006a344b4032a
If the attended transfer destination answers (picks call up or goes to
voicemail) and then hangs up on the transferer then transferer hears the
fail sound.
This patch makes it so the fail sound is not played when the transfer
destination/target hangs up after answering.
ASTERISK-25697 #close
Change-Id: I97f142fe4fc2805d1a24b7c16143069dc03d9ded
This issue was exposed when executing a connected line subroutine.
When connected or redirected subroutines or macros are executed it is
expected that the underlying applications and logic invoked are fast
and do not consume frames. In practice this constraint is not enforced
and if not adhered to will cause channels to continue when they shouldn't.
This is because each caller of the connected or redirected logic does not
check whether the channel has been hung up on return. As a result the
the hung up channel continues.
This change makes it so when the API to execute a subroutine or
macro is invoked the channel is checked to determine if it has hung up.
If it has then a hangup is queued again so the caller will see it
and stop.
ASTERISK-25690 #close
Change-Id: I1f9a8ceb1487df0389f0d346ce0f6dcbcaf476ea
* changes:
Sorcery: Create human friendly serializer names.
Stasis: Create human friendly taskprocessor/serializer names.
taskprocessor.c: New API for human friendly taskprocessor names.
taskprocessor.c: Sort CLI "core show taskprocessors" output.
Recent changes (ASTERISK-25394 commit 2bd27d1222)
introduced the possibility of a deadlock. Due to the mentioned modifications
ast_change_hints now needs to keep both merge/delete and state callbacks from
occurring while it executes. Unfortunately, sometimes ast_change_hints can be
called with the contexts container locked. When this happens it's possible for
another thread to grab the context_merge_lock before the thread calling into
ast_change_hints does and then try to obtain the contexts container lock. This
of course causes a deadlock between the two threads. The thread calling into
ast_change_hints waits for the other thread to release context_merge_lock and
the other thread is waiting on that one to release the contexts container lock.
Unfortunately, there is not a great way to fix this problem. When hints change,
the subsequent state callbacks cannot run at the same time as a merge/delete,
nor when the usual state callbacks do. This patch alleviates the problem by
having those particular callbacks (the ones run after a hint change) occur in a
serialized task. By moving the context_merge_lock to a task it can now safely be
attempted or held without a deadlock occurring.
ASTERISK-25640 #close
Reported by: Krzysztof Trempala
Change-Id: If2210ea241afd1585dc2594c16faff84579bf302
* Add new API call to get a sequence number for use in human friendly
taskprocessor names.
* Add new API call to create a taskprocessor name in a given buffer and
append a sequence number.
Change-Id: Iac458f05b45232315ed64aa31b1df05b875537a9
Update the CLI "core show taskprocessors" output format to not be
distorted because UUID names are longer than previously used taskprocessor
names.
Change-Id: I1a5c82ce3e8f765a0627796aba87f8f7be077601
The CLI "core ping taskprocessor" command does not work very
well with taskprocessor names that have spaces in them. You
have to put quotes around the name so using tab completion
becomes awkward.
Change-Id: I29e806dd0a8a0256f4e2e0a7ab88c9e19ab0eda0
This resolves a reference leak caused by ASTERISK-25535. The pointer
returned by ast_format_get_codec is saved so it can be released.
ASTERISK-25664 #close
Change-Id: If9941b1bf4320b2c59056546d6bce9422726d1ec
This is the sixth patch in a series meant to reduce the bulk of pbx.c.
This moves hangup handler management functions to their own source.
Change-Id: Ib25a75aa57fc7d5c4294479e5cc46775912fb104
This is the sixth patch in a series meant to reduce the bulk of pbx.c.
This moves dialplan application management functions to their own source.
Change-Id: I444c10fb90a3cdf9f3047605d6a8aad49c22c44c
This is the fifth patch in a series meant to reduce the bulk of pbx.c.
This moves ast_switch functions to their own source.
Change-Id: Ic2592a18a5c4d8a3c2dcf9786c9a6f650a8c628e
This is the fourth patch in a series meant to reduce the bulk of pbx.c.
This moves pbx timing functions to their own source.
Change-Id: I05c45186cb11edfc901e95f6be4e6a8abf129cd6
The menuselect conflict between app_voicemail and res_mwi_external
makes it hard to package 1 version of Asterisk. There no actual
build dependencies between the 2 so moving this check to runtime
seems like a better solution.
The ast_vm_register and ast_vm_greeter_register functions in app.c
were modified to return AST_MODULE_LOAD_DECLINE instead of -1 if there
is already a voicemail module registered. The modules' load_module
functions were then modified to return DECLINE instead of -1 to the
loader. Since -1 is interpreted by the loader as AST_MODULE_LOAD_FAILURE,
the modules were incorrectly causing Asterisk to stop so this needed
to be cleaned up anyway.
Now you can build both and use modules.conf to decide which voicemail
implementation to load.
The default menuselect options still build app_voicemail and not
res_mwi_external but if both ARE built, res_mwi_external will load
first and become the voicemail provider unless modules.conf rules
prevent it. This is noted in CHANGES.
Change-Id: I7d98d4e8a3b87b8df9e51c2608f0da6ddfb89247
This is the third patch in a series meant to reduce the bulk of pbx.c.
This moves channel and global variable routines to their own source.
Change-Id: Ibe8fb4647db11598591d443a99e3f99200a56bc6
Prior to this patch, we explicitly disallowed setting any properties on a
finalized CDR. This seemed like a good idea at the time; in practice, it was
more restrictive.
There are weird and strange scenarios where setting a property on a finalized
CDR is definitely wrong. For example, we may Fork a CDR, finalizing the
previous one, then change a property. In said case, the old CDR is supposed
to now be 'immutable' (so to speak), and should not be updated. From the
perspective of the code, a forked CDR that is finalized is just finalized.
Hence why we decided these should not be updated.
In practice, it is much more common to want to set a property on a CDR in
the h extension or in a hangup handler. Disallowing a common scenario to make
an esoteric behaviour work isn't good. This patch fixes this by allowing
callers to set a property IF we are the last CDR in the chain. This preserves
the finalized CDR if it was forked, while allowing the more common case to
function.
ASTERISK-25458 #close
Change-Id: Icf3553c607b9f561152a41e6d8381d594ccdf4b9
Prior to this patch, the CDR engine attempted to set the end time on a CDR
that was executing hangup logic and with endbeforehexten set to Yes by
calling a function that inspects the properties on the Party A snapshot to
determine if we are ready to set the end time. That always failed. This is
because a Party A snapshot is not updated for CDRs that are executing hangup
logic with endbeforehexten=Yes.
Instead of calling a function that looks at the Party A snapshot, we just
simply set the end time on the CDR. This is safe to call multiple times, and is
safe to call at this point as we know that (a) we are executing hangup logic,
and (b) we are supposed to set the end time at this point.
ASTERISK-25458
Change-Id: I0c27b493861f9c13c43addbbb21257f79047a3b3
This is the second patch in a series meant to reduce the bulk of pbx.c.
This moves custom function management routines to their own source.
Change-Id: I34a6190282f781cdbbd3ce9d3adeac3c3805e177
We joked about splitting pbx.c into multiple files but this first step was
fairly easy. All of the pbx_builtin dialplan applications have been moved
into pbx_builtins.c and a new pbx_private.h file was added. load_pbx_builtins()
is called by asterisk.c just after load_pbx().
A few functions were renamed and are cross-exposed between the 2 source files.
Change-Id: I87066be3dbf7f5822942ac1449d98cc43fc7561a
The test_timezone_watch unit test is written to expect a
condition to be signaled when the inotify daemon thread runs.
There exists a small window where the test_timezone_watch
thread can signal the inotify daemon thread while it is not
reading on the underlying file descriptor. If this occurs
the test_timezone_watch thread will wait indefinitely for a
signal that will never arrive.
This change adds a timeout to the condition so it will return
regardless after a period of time.
Change-Id: Ifed981879df6de3d93acd3ee0a70f92546517390
When an endpoint is created, its messages are forwarded to both the tech
endpoint topic and the all endpoints topic. This is done so that various
parties interested in endpoint messages can subscribe to just the tech
endpoint and receive all messages associated with that particular technology,
as opposed to subscribing to the all endpoints topic. Unfortunately, when the
tech endpoint is created, it also forwards all of its messages to the all
topic. This results in duplicate messages whenever an endpoint publishes its
messages.
This patch resolves the duplicate message issue by creating a new function
for Stasis caching topics, stasis_cp_sink_create. In most respects, this acts
as a normal caching topic, save that it no longer forwards messages it receives
to the all endpoints topic. This allows it to act as an aggregation "sink",
while preserving the necessary caching behaviour.
ASTERISK-25137 #close
Reported-by: Vitezslav Novy
ASTERISK-25116 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: Ie47784adfb973ab0063e59fc18f390d7dd26d17b
Use of GOTO_ON_BLINDXFR would not work at all. The target location would
never be executed by the transferring channel.
* Made feature_blind_transfer() call ast_bridge_set_after_go_on() with
valid context, exten, and priority parameters from the transferring
channel.
* Renamed some feature_blind_transfer() local variables for clarity.
ASTERISK-25641 #close
Reported by Dmitry Melekhov
Change-Id: I19bead9ffdc4aee8d58c654ca05a198da1e4b7ac
This change introduces the configuration option 'full_backend_cache'
which changes the cache to be a full mirror of the backend instead
of a per-object cache. This allows all sorcery retrieval operations
to be carried out against it and is useful for object types which
are used in a "retrieve all" or "retrieve some" pattern.
ASTERISK-25625 #close
Change-Id: Ie2993487e9c19de563413ad5561c7403b48caab5
When applying an empty DTLS configuration the filenames in the
configuration will be empty. This is actually valid to do and
each filename should simply be ignored.
Change-Id: Ib761dc235638a3fb701df337952f831fc3e69539
The JSON library Asterisk uses, jansson, is not thread
safe for us in a few ways. To help with this wrappers for JSON
object reference count increasing and decreasing were added
which use a global lock to ensure they don't clobber over
each other. This does not extend to reference count manipulation
within the jansson library itself. This means you can't safely
use the object borrowing specifier (O) in ast_json_pack and
you can't share JSON instances between objects.
This change removes uses of the O specifier and replaces them
with the o specifier and an explicit ast_json_ref. Some cases
of instance sharing have also been removed.
ASTERISK-25601 #close
Change-Id: I06550d8b0cc1bfeb56cab580a4e608ae4f1ec7d1
When the asterisk sending OriginateResponse message,
it doesn't set the "Uniqueid".
And it didn't support correct response message for
Application originate.
ASTERISK-25624 #close
Change-Id: I26f54f677ccfb0b7cfd4967a844a1657fd69b74d
An ERROR or WARNING message should generally indicate that something has gone
wrong in Asterisk. In the case of writing to a file descriptor, Asterisk is not
in control of when the far end closes its reading on a file descriptor. If the
far end does close the file descriptor in an unclean fashion, this isn't a bug
or error in Asterisk, particularly when the situation can be gracefully
handled in Asterisk.
Currently, when this happens, a user would see the following somewhat cryptic
ERROR message:
"utils.c: write() returned error: Broken pipe"
There's a few problems with this:
(1) It doesn't provide any context, other than 'something broke a pipe'
(2) As noted, it isn't actually an error in Asterisk
(3) It can get rather spammy if the thing breaking the pipe occurs often, such
as a FastAGI server
(4) Spammy ERROR messages make Asterisk appear to be having issues, or can even
mask legitimate issues
This patch changes ast_carefulwrite to only log an ERROR if we actually had one
that was reasonably under our control. For debugging purposes, we still emit
a debug message if we detect that the far side has stopped reading.
Change-Id: Ia503bb1efcec685fa6f3017bedf98061f8e1b566
pjproject < 2.5.0 will segfault on a tls transport if async_operations
is greater than 1. A runtime version check has been added to throw
an error if the version is < 2.5.0 and async_operations > 1.
To assist in the check, a new api "ast_compare_versions" was added
to utils which compares 2 major.minor.patch.extra version strings.
ASTERISK-25615 #close
Change-Id: I8e88bb49cbcfbca88d9de705496d6f6a8c938a98
Reported-by: George Joseph
Tested-by: George Joseph
Both transport and endpoint now check for the existence and readability
of tls certificate and key files before passing them on to pjproject.
This will cause the object to not load rather than waiting for pjproject
to discover that there's a problem when a session is attempted.
NOTE: chan_sip also uses ast_rtp_dtls_cfg_parse but it's located
in build_peer which is gigantic and I didn't want to disturb it.
Error messages will emit but it won't interrupt chan_sip loading.
ASTERISK-25618 #close
Change-Id: Ie43f2c1d653ac1fda6a6f6faecb7c2ebadaf47c9
Reported-by: George Joseph
Tested-by: George Joseph
This patch fixes a crash which would occur when an audiohook was
applied to a channel using an audio codec that could not be translated
to signed linear (such as when using pass-through codecs like OPUS or
when the codec translator module for the format in use is not loaded).
ASTERISK-25498 #close
Reported by: Ben Langfeld
Change-Id: Ib6ea7373fcc22e537cad373996136636201f4384
Currently if a channel is transferred out of a bridge, the BRIDGEPEER
variable (also BRIDGEPVTCALLID) remain set even once the channel is
out of the bridge. This patch removes these variables when leaving
the bridge.
ASTERISK-25600 #close
Reported by: Mark Michelson
Change-Id: I753ead2fffbfc65427ed4e9244c7066610e546da
According to the API doxygen a sched ID of 0 is valid. Unfortunately, 0
was never returned historically and several users incorrectly coded usage
of the returned sched ID assuming that 0 was invalid.
ASTERISK-25476
Change-Id: Ib19c7ebb44ec9fd393ef6646dea806d4f34e3a20
channels/chan_iax2.c:
* Initialize struct chan_iax2_pvt scheduler ids earlier because of
iax2_destroy_helper().
channels/chan_sip.c:
channels/sip/config_parser.c:
* Fix initialization of scheduler id struct members. Some off nominal
paths had 0 as a scheduler id to be destroyed when it was never started.
chan_skinny.c:
* Fix some scheduler id comparisons that excluded the valid 0 id.
channel.c:
* Fix channel initialization of the video stream scheduler id.
pbx_dundi.c:
* Fix channel initialization of the packet retransmission scheduler id.
ASTERISK-25476
Change-Id: I07a3449f728f671d326a22fcbd071f150ba2e8c8
dns.c and dns_system_resolver.c were spitting out errors for lookup
failures for things like not finding a SRV record even though
there was an A record. Those have been changed to debug messages.
Logging not finding ANY record is left to the higher level caller.
Also, dns_system_resolver was using Windows line endings so I
converted them to Unix style. The actual log changes are on lines
156 and 159.
Change-Id: I65be16ea15304b96f9dcb4d289dbd3e2286fc094
Several issues are addressed here:
- main() is large, and half of it is only used if we're not rasterisk;
fixed by spliting up the daemon part into a separate function.
- Call ast_term_init from rasterisk as well.
- Remove duplicate code reading/writing asterisk history file.
- Attempt to tackle background color issues and color changes that
occur. Tested by starting asterisk -c until the colors stopped
changing at odd locations.
- Remove unused term_prep() and term_prompt() functions.
ASTERISK-25585 #close
Change-Id: Ib641a0964c59ef9fe6f59efa8ccb481a9580c52f
Because the context, extension, and application are stored in stringfields,
checking for them being NULL doesn't work so well. This patch uses the
appropriate string library call, ast_strlen_zero, to see if there is a value
in the context/exten/app values.
Change-Id: Ie09623bfdf35f5a8d3b23dd596647fe3c97b9a23
Previously, a trancoding module did not have access to the joint but cached
format. Therefore, the module did not have access to the attributes negotiated
via SDP (line fmtp). Now, a translation module receives the joint format.
ASTERISK-25545 #close
Change-Id: Id6878a989b50573298dab115d3371ea369e1a718
When dns_parse_answer_ex was iterating over the answers it
wasn't incrementing the answer pointer correctly after the first
answer. The result was that no answers after the first
were being returned. For results where multiple records should
have been sorted by priority, weight, etc., there was nothing
to sort so the only the first record was returned even if it
wouldn't have been the correct record based on the sort.
ASTERISK-25565 #close
Reported-by: Daniel Tryba
Tested-by George Joseph
Change-Id: I8622604fefdcd3c11e2c5609a6382e53b1467b0b
The hashtab API is pretty NULL tolerant which has resulted
in remaining callers not doing much checks themselves.
Unfortunately the function to destroy an iterator does not
do a NULL check and will result in a crash if passed NULL.
This change fixes that.
ASTERISK-25552 #close
Change-Id: Ic1bf8eec3639e5a440f1c941d3ae3893ac6ed619
In practical tests, we have seen certain taskprocessors, specifically
Stasis subscription taskprocessors, cross the recently-added high-water
mark and emit a warning. This high-water mark warning is only intended
to be emitted when things have tanked on the system and things are
heading south quickly. In the practical tests, the Stasis taskprocessors
sometimes had a max depth of 180 tasks in them, and Asterisk wasn't in
any danger at all.
As such, this ups the high-water mark to 500 tasks instead. It also
redefines the SIP threadpool request denial number to be a multiple of
the taskprocessor high-water mark.
Change-Id: Ic8d3e9497452fecd768ac427bb6f58aa616eebce
In Asterisk 13, cached formats are created before their corresponding format-
attribute module is registered. Cached formats are involved when a local
extension is called. Therefore, ast_format_generate_sdp_fmtp did not work
on local extensions. This change affects the Opus Codec, H.263 (Plus), H.264,
and format-attribute modules provided externally.
ASTERISK-25160 #close
Change-Id: I1ea1f0483e5261e2a050112e4ebdfc22057d1354
We have observed situations where the SIP threadpool may become
deadlocked. However, because incoming traffic is still arriving, the SIP
threadpool's queue can continue to grow, eventually running the system
out of memory.
This change makes it so that incoming traffic gets rejected with a 503
response if the queue is backed up too much.
Change-Id: I4e736d48a2ba79fd1f8056c0dcd330e38e6a3816
When appending all formats of a type all the codecs are iterated
and added. This operation was incorrectly adding the ast_format_none
format which is special in that it is supposed to be used when no
format is present. It shouldn't be appended.
ASTERISK-25535
Change-Id: I7b00f3bdf4a5f3022e483d6ece602b1e8b12827c
This change adds handling of dead worker threads when moving them
to be active. When this happens the worker thread is removed from
both the active and idle threads container. If no threads are able
to be moved to active then the pool grows as configured.
A unit test has also been added which thrashes the idle timeout
and thread activation to exploit any race conditions between the
two.
ASTERISK-25546 #close
Change-Id: I6c455f9a40de60d9e86458d447b548fb52ba1143
Previously, format-attribute modules relied on an existing fmtp line in SDP
negotiation. However, fmtp is optional for several formats like the Opus Codec.
Now, the format-attribute module is called with an empty fmtp, which allows the
module to initialise itself to RFC defaults. Furthermore now, Asterisk is able
to differentiate between internally and externally created formats.
ASTERISK-25537 #close
Change-Id: I28f680cef7fdf51c0969ff8da71548edad72ec52
ABI compatibility stubs existed for ast_app_separate_args and ast_verbose,
this is not needed in master.
Change-Id: I07b4d2c16079da3c2c6efa55df4a74368e0bd453
Since Asterisk 13, formats are immutable and cached. However while loading a
module like chan_sip, some formats were created instead using cached ones.
ASTERISK-25535 #close
Change-Id: I479cdc220d5617c840a98f3389b3bd91e91fbd9b
dns_parse_answer_ex was not converting ans->ttl from network
by order to host byte order which was causing certain ttls
it to go negative. In turn this was causing answer edit checks
to fail.
ASTERISK-25528 #close
Reported-by: Daniel Tryba
Tested-by: George Joseph
Change-Id: I31505132d6321c46d2f39fd06c20ee808a864037
Previously, the wrapping did both lookahead and lookback, which,
together with color escape sequences, caused some lines to be wrapped
way earlier than other lines. This led to inconsistent output.
This simplifies the wrapping code and makes it more sane: if maxcolumns
is hit, we simply jump back to the last space and wrap there.
ASTERISK-25527 #close
Change-Id: I56d01c6f9a812642b1b05535c98d4db48d17c957
If a taskprocessor's queue grows large, this can indicate that there
may be a problem with tasks not leaving the processor or else that
the number of available task processors for a given type of task is
too low. This patch makes it so that if a taskprocessor's task queue
grows above 100 queued tasks that it will emit a warning message.
Warning messages are emitted only once per task processor.
ASTERISK-25518 #close
Reported by: Jonathan Rose
Change-Id: Ib1607c35d18c1d6a0575b3f0e3ff5d932fd6600c
When a dial attempt is made that involves a requesting channel, we previously
were not:
a) Protecting access to the native format capabilities structure on the
requesting channel. That is inherently unsafe.
b) Reference bumping the lifetime of the format capabilities structure.
In both cases, something else could sneak in, blow away the format
capabilities, and we'd be holding onto an invalid format_cap structure. When
the newly created channel attempts to construct its format capabilities, things
go poorly.
This patch:
a) Ensures that we get a reference to the native format capabilities while
the requesting channel is locked
b) Holds a reference to the native format capabilities during the creation
of the new channel.
ASTERISK-25522 #close
Change-Id: I0bfb7ba8b9711f4158cbeaae96edf9626e88a54f
A previous commit reduced the AST_BUILDOPTS compiler define to
only include options that affected ABI. This included some options
that were previously displayed by cli "core show settings". This
change corrects the CLI display while still restricting buildopts.h
to ABI effecting options only.
ASTERISK-25434 #close
Reported by: Rusty Newton
Change-Id: Id07af6bedd1d7d325878023e403fbd9d3607e325
The JSON packing for the ContactStatusChange event forgot to include the
roundtrip_usec field. As a result, the field never showed up in any event,
even when the data was available. This patch corrects that error by properly
packing the JSON blob with the data.
Change-Id: I8df80da659a44010afbd48f645967518ff5daa17
A crash was seen on a system that ran out of memory due to Asterisk not
checking for vector allocation failures in format_cap.c. With this
change, if either of the AST_VECTOR_INIT calls fail, we will return a
value indicating failure.
Change-Id: Ieb9c59f39dfde6d11797a92b45e0cf8ac5722bc8
Users of functions which call __ast_str_helper() such as the ones listed
below are likely to not check the return value for failure so ensuring
that the string is always nil terminated is a good safety measure.
ast_str_set_va()
ast_str_append_va()
ast_str_set()
ast_str_append()
Change-Id: I36ab2d14bb6015868b49329dda8639d70fbcae07
In September 2006, the maximum packetization time (ptime) were set to such a
low value, packetization was disabled for many codecs actually. This was fixed
for many codecs but not for iLBC 30. This enables packetization for iLBC which
can be enabled for example via allow=ilbc:60,gsm,alaw,ulaw in the file sip.conf.
ASTERISK-7803
Change-Id: I2ef90023d35efb7cb8fe96ed74f53f6846ffad12
This patch adds the functions
ast_cdr_modifier_register()
ast_cdr_modifier_unregister()
That work much like ast_cdr_register() and ast_cdr_unregister().
Modules registered will be given a chance to modify (or to do whatever
they want) CDR fields just before they are passed to registered engines.
Thus, for instance, if a module change the "userfield" field of a CDR,
the modified value will be passed to every registered CDR backend for
logging.
ASTERISK-25479 #close
Change-Id: If11d8fd19ef89b1a66ecacf1201e10fcf86ccd56
The memory corruption could happen if the [section](+) is the last section
in the file with trailing comments. In this case process_text_line() has
left *last_cat is set to newcat and newcat is destroyed.
Change-Id: I0d1d999f553986f591becd000e7cc6ddfb978d93
An #include right after a [section](+) would associate any variable
assignments before a new section in the #include with the wrong section.
* Fix section association by setting the current section to the appended
section.
* Fix '+' and '!' section flag interaction corner case depending upon
which flag came first. If the '!' came first then it would be ignored.
If the '!' came after then it would affect the appended section. The '!'
will now no longer be ignored.
ASTERISK-25461 #close
Reported by: Sean Pimental
Change-Id: Ic9d3191c8758048e2cbce6432f854b32531731c3
When GetConfigJSON was introduced back in 1.6, it returned each
section as an array of strings: ["key=value", "key2=value2"].
Afterwards, it was changed a few times and became
["key": "value", "key2": "value2"], which is not a correct JSON.
This patch fixes that by constructing a JSON object {} instead of
an array [].
Also, the keys "istemplate" and "tempates" that are used to
indicate templates and their inherited categories are now wrapped in
quotes.
ASTERISK-25391 #close
Reported by: Bojan Nemčić
Change-Id: Ibbe93c6a227dff14d4a54b0d152341857bcf6ad8
When Asterisk is part of a larger distributed system, log files are often
gathered using tools (such as logstash) that prefer to consume information
and have it rendered using other tools (such as Kibana) that prefer a
structured format, e.g., JSON. This patch adds support for JSON formatted
logs by adding support for an optional log format specifier in Asterisk's
logging subsystem. By adding a format specifier of '[json]':
full => [json]debug,verbose,notice,warning,error
Log messages will be output to the 'full' channel in the following
format:
{
"hostname": Hostname or name specified in asterisk.conf
"timestamp": Date/Time
"identifiers": {
"lwp": Thread ID,
"callid": Call Identifier
}
"logmsg": {
"location": {
"filename": Name of the file that generated the log statement
"function": Function that generated the log statement
"line": Line number that called the logging function
}
"level": Log level, e.g., DEBUG, VERBOSE, etc.
"message": Actual text of the log message
}
}
ASTERISK-25425 #close
Change-Id: I8649bfedf3fb7bf3138008cc11565553209cc238
There was a problem observed where the "logger add channel" CLI command
would allow for a channel with the same name to be added multiple times.
This would result in each message being written out to the same file
multiple times.
The problem was due to the difference in how logger channel filenames
are stored versus the format they are allowed to be presented when they
are added. For instance, if adding the logger channel "foo" through the
CLI, the result would be a logger channel with the file name
/var/log/asterisk/foo being stored. So when trying to add another "foo"
channel, "foo" would not match "/var/log/asterisk/foo" so we'd happily
add the duplicate channel.
The fix presented here is to introduce two new methods in the logger
code:
* make_filename(): given a logger channel name, this creates the
filename for that logger channel.
* find_logchannel(): given a logger channel name, this calls
make_filename() and then traverses the list of logchannels in order
to find a match.
This change has made use of make_filename() and find_logchannel()
throughout to more consistently behave.
ASTERISK-25305 #close
Reported by Mark Michelson
Change-Id: I892d52954d6007d8bc453c3cbdd9235dec9c4a36
When leaving a bridge, indications on a channel could be swallowed by
the internal indication logic because it appears that the channel is on
its way to be hung up anyway. One such situation where this is
detrimental is when channels on hold are redirected out of a bridge. The
AST_CONTROL_UNHOLD indication from the bridging code is swallowed,
leaving the channel in question to still appear to be on hold.
The fix here is to modify the logic inside ast_indicate_data() to not
drop the indication if the channel is simply leaving a bridge. This way,
channels on hold redirected out of a bridge revert to their expected "in
use" state after the redirection.
ASTERISK-25418 #close
Reported by Mark Michelson
Change-Id: If6115204dfa0551c050974ee138fabd15f978949
Page uses the async method of dialing with the dial API. When a call gets
forwarded there is no calling channel available. If the predial handler
was set then the calling channel could not be put into auto-service
for the forwarded call because it doesn't exist. A crash is the result.
* Moved the callee predial parameter string processing to before the
string is passed to the dial API rather than having the dial API do it.
There are a few benefits do doing this. The first is the predial
parameter string processing doesn't need to be done for each channel
called by the dial API. The second is in async mode and the forwarded
channel is to have the predial handler executed on it then the
non-existent calling channel does not need to be present to process the
predial parameter string.
* Don't start auto-service on a non-existent calling channel to execute
the predial handler when the dial API is in async mode and forwarding a
call.
ASTERISK-25384 #close
Reported by: Chet Stevens
Change-Id: If53892b286d29f6cf955e2545b03dcffa2610981
Currently, Asterisk will log to the last configured syslog
channel in logger.conf. This is due to the fact that the
final call to openlog() supersedes all of the previous calls.
This commit removes the call to openlog() and passes the
facility to ast_log_vsyslog(), along with utilizing the
LOG_MAKEPRI macro to ensure that the message is routed to
the correct facility and with the correct priority.
ASTERISK-25407 #close
Reported by: Elazar Broad
Tested by: Elazar Broad
Change-Id: Ie2a2416bc00cce1b04e99ef40917c2011953ddd2
This patch adds support for receiving events regarding Peer status changes
and Contact status changes. This is particularly useful in scenarios where
we are subscribed to all endpoints and channels, where we often want to know
more about the state of channel technology specific items than a single
endpoint's state.
ASTERISK-24870
Change-Id: I6137459cdc25ce27efc134ad58abf065653da4e9
Now with menuselect "DEBUG_FD_LEAKS" and CLI "core show fd", a timestamp is
shown with each file descriptor. This helps to debug leaked UDP/TCP ports on
long-lived servers, for example.
ASTERISK-25405 #close
Change-Id: I968339e5155a512eba1032a5263f1ec8b5e1f80b
When changing a hint extension without removing the hint first the
device state and presence state is not updated. This causes the state
of the hint to be that of the previous extension and not the current
one. This state is kept until a state change occurs as a result of
something (presence state change, device state change).
This change updates the hint with the current device and presence
state of the new extension when it is changed. Any state callbacks
which may have been added before the hint extension is changed are
also informed of the new device and presence state if either have
changed.
ASTERISK-25394 #close
Change-Id: If268f1110290e502c73dd289c9e7e7b27bc8432f
When Asterisk translates between codecs, each with a different frame size (for
example between iLBC 30 and Speex-WB), too large frames were created by
ast_trans_frameout. Now, ast_trans_frameout is called with the correct frame
length, creating several frames when necessary. Affects all transcoding modules
which used ast_trans_frameout: GSM, iLBC, LPC10, and Speex.
ASTERISK-25353 #close
Change-Id: I2e229569d73191d66a4e43fef35432db24000212
It has been observed that on long-running busy systems, a scheduler
context can eventually hit INT_MAX for its assigned IDs and end up
overflowing into a very low negative number. When this occurs, this can
result in odd behaviors, because a negative return is interpreted by
callers as being a failure. However, the item actually was successfully
scheduled. The result may be that a freed item remains in the scheduler,
resulting in a crash at some point in the future.
The scheduler can overflow because every time that an item is added to
the scheduler, a counter is bumped and that counter's current value is
assigned as the new item's ID.
This patch introduces a new method for assigning scheduler IDs. Instead
of assigning from a counter, a queue of available IDs is maintained.
When assigning a new ID, an ID is pulled from the queue. When a
scheduler item is released, its ID is pushed back onto the queue. This
way, IDs may be reused when they become available, and the growth of ID
numbers is directly related to concurrent activity within a scheduler
context rather than the uptime of the system.
Change-Id: I532708eef8f669d823457d7fefdad9a6078b99b2
Asterisk can load and register an object type while still having an invalid
sorcery mapping. This can cause an issue when a creation call is invoked.
For example, mis-configuring PJSIP's endpoint identifier by IP address mapping
in sorcery.conf will cause the sorcery mechanism to be invalidated; however, a
subsequent ARI invocation to create the object will cause a crash, as the
internal type may not be registered as sorcery expects.
Merely checking for a NULL pointer here solves the issue.
Change-Id: I54079fb94a1440992f4735a9a1bbf1abb1c601ac
In ast_endpoint_snapshot_create(), a failure to init the
string fields results in two attempts to ao2_cleanup the
same pointer. Removed RAII_VAR to eliminate problem.
ASTERISK-25375 #close
Reported by: Scott Griepentrog
Change-Id: If4d9dfb1bbe3836b623642ec690b6d49b25e8979
When issuing the "core show hints" CLI command a combination of both
the hint extension and context is created. This uses a fixed size
buffer expecting that the extension will not exceed maximum extension
length. When the extension is actually a pattern match this constraint
does not hold true, and the extension may exceed the maximum extension
length. In this case extra characters are written past the end of the
fixed size buffer.
This change makes it so the construction of the combined hint extension
and context can not exceed the size of the buffer.
ASTERISK-25367 #close
Change-Id: Idfa1b95d0d4dc38e675be7c1de8900b3f981f499
When unreferencing a taskprocessor its reference count is checked
to determine if it should be unlinked from the taskprocessors
container and its listener shut down. In between the time when the
reference count is checked and unlinking it is possible for
another thread to jump in, find it, and get a reference to it. If
the thread then uses the taskprocessor it may find that it is not
in the state it expects.
This change locks the taskprocessors container during almost the
entire unreference operation to ensure that any other thread which
may attempt to find the taskprocessor has to wait.
ASTERISK-25295
Change-Id: Icb842db82fe1cf238da55df92e95938a4419377c
When deleting a scheduled item if the item in question is currently
executing the ast_sched_del function waits until it has completed.
This is accomplished using ast_cond_wait. Unfortunately the
ast_cond_wait function can suffer from spurious wakeups so the
predicate needs to be checked after it returns to make sure it has
really woken up as a result of being signaled.
This change adds a loop around the ast_cond_wait to make sure that
it only exits when the executing task has really completed.
ASTERISK-25355 #close
Change-Id: I51198270eb0b637c956c61aa409f46283432be61
When executing an action in a bridge it is possible for the
channel to be hung up without the bridge becoming aware of it.
This is most easily reproducible by hanging up when the bridge
is streaming DTMF due to a feature timeout. This change makes
it so after action execution the channel is checked to determine
if it has been hung up and if it has it is kicked from the bridge.
ASTERISK-25341 #close
Change-Id: I6dd8b0c3f5888da1c57afed9e8a802ae0a053062
* Make ast_rtp_codecs_payload_code() get the current mapping or create a
rx payload type mapping.
ASTERISK-25166
Reported by: Kevin Harwell
ASTERISK-17410
Reported by: Boris Fox
Change-Id: Ia4b2d45877a8f004f6ce3840e3d8afe533384e56
There are numerous problems with the current implementation of the RTP
payload type mapping in Asterisk. It uses only one mapping structure to
associate payload types to codecs. The single mapping is overkill if all
of the payload type values are well known values. Dynamic payload type
mappings do not work as well with the single mapping because RFC3264
allows each side of the link to negotiate different dynamic mappings for
what they want to receive. Not only could you have the same codec mapped
for sending and receiving on different payload types you could wind up
with the same payload type mapped to different codecs for each direction.
1) An independent payload type mapping is needed for sending and
receiving.
2) The receive mapping needs to keep track of previous mappings because of
the slack to when negotiation happens and current packets in flight using
the old mapping arrive.
3) The transmit mapping only needs to keep track of the current negotiated
values since we are sending the packets and know when the switchover takes
place.
* Needed to create ast_rtp_codecs_payload_code_tx() and make some callers
use the new function because ast_rtp_codecs_payload_code() was used for
mappings in both directions.
* Needed to create ast_rtp_codecs_payloads_xover() for cases where we need
to pass preferred codec mappings to the peer channel for early media
bridging or when we need to prefer the offered mapping that RFC3264 says
we SHOULD use.
* ast_rtp_codecs_payloads_xover() and ast_rtp_codecs_payload_code_tx() are
the only new public functions created. All the others were only used for
the tx or rx mapping direction so the function doxygen now reflects which
direction the function operates.
* chan_mgcp.c: Removed call to ast_rtp_codecs_payloads_clear() as doing
that makes no sense when processing an incoming SDP. We would be wiping
out any mappings that we set for the possible outgoing SDP we sent
earlier.
ASTERISK-25166
Reported by: Kevin Harwell
ASTERISK-17410
Reported by: Boris Fox
Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac
When allocating a sorcery object, fail if the
id value was not allocated.
ASTERISK-25323
Reported by: Scott Griepentrog
Change-Id: I152133fb7545a4efcf7a0080ada77332d038669e
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
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
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
An http request can be sent to rotate a specified log channel.
If the channel does not exist, an error response will be
returned.
The command "curl -v -u user:pass -X PUT 'http://localhost:8088
/ari/asterisk/logging/logChannelName/rotate'" can be run in the
terminal to access this new functionality.
* Added the ability to rotate log files through ARI
ASTERISK-25252
Change-Id: Iaefa21cbbc1b29effb33004ee3d89c977e76ab01
A testsuite test recently failed due to a crash that occurred in the DNS
core. The problem was that the test could not resolve an address, did
not set a result on the DNS query, and then indicated the query was
completed. The DNS core does not handle the case of a query with no
result gracefully, and so there is a crash.
This changeset makes the DNS system resolver set a result with a
zero-length answer in the case that a DNS resolution failure occurs
early. The DNS core now also will accept such a response without
treating it as invalid input. A unit test was updated to no longer treat
setting a zero-length response as off-nominal.
Change-Id: Ie56641e22debdaa61459e1c9a042e23b78affbf6
ast_rtp_codecs_get_payload() gets called once or twice for every received
RTP frame so it would be nice to not allocate an ao2 object to then have
it destroyed shortly thereafter. The ao2 object gets allocated only if
the payload type is not set by the channel driver as a negotiated value.
The issue affects chan_skinny, chan_unistim, chan_rtp, and chan_ooh323.
* Made static_RTP_PT[] an array of ao2 objects that
ast_rtp_codecs_get_payload() can return instead of an array of structs
that must be copied into a created ao2 object.
ASTERISK-25296 #close
Reported by: Richard Mudgett
Change-Id: Icb6de5cd90bfae07d44403a1352963db9109dac0
* Fix off nominial ref leak of new_type in
ast_rtp_codecs_payloads_set_m_type().
* No need to lock static_RTP_PT_lock in
ast_rtp_codecs_payloads_set_m_type() and
ast_rtp_codecs_payloads_set_rtpmap_type_rate() before the payload type
parameter sanity check.
* No need to create ast_rtp_payload_type ao2 objects with a lock since the
lock is not used.
Change-Id: I64dd1bb4dfabdc7e981e3f61448beac9bb7504d4
This event is necessary for the bridge_wait_e_options test to be able to
confirm that ringing is being played on the local channel that runs the
BridgeWait() application with the e(r) option.
ASTERISK-25292 #close
Reported by Kevin Harwell
Change-Id: Ifd3d3d2bebc73344d4b5310d0d55c7675359d72e
Currently, if a blank musiconhold.conf is used, musiconhold will fail
to start for a channel going into a holding bridge with an anticipation
of getting music on hold. That being the case, no frames will be written
to the channel and that can pose a problem for blind transfers in PJSIP
which may rely on frames being written to get past the REFER framehook.
This patch makes holding bridges start a silence generator if starting
music on hold fails and makes it so that if no music on hold functions
are installed that the ast_moh_start function will report a failure so
that consumers of that function will be able to respond appropriately.
ASTERISK-25271 #close
Change-Id: I06f066728604943cba0bb0b39fa7cf658a21cd99
(cherry picked from commit 8458b8d441)
This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold'
endpoint options. These allow the channel to be hung up if RTP
is not received from the remote endpoint for a specified number of
seconds.
ASTERISK-25259 #close
Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9
Commit 54b25c80c8 solved an issue where a
specific scenario involving local channels and a native local RTP bridge
could result in ringback still being heard on a calling channel even
after the call is bridged.
That commit caused many tests in the testsuite to fail with alarming
consequences, such as not sending DialBegin and DialEnd events, and
giving incorrect hangup causes during calls.
This commit reverts the previous commit and implements and alternate
solution. This new solution involves only passing AST_CONTROL_RINGING
frames across local channels if the local channel is in AST_STATE_RING.
Otherwise, the frame does not traverse the local channels. By doing
this, we can ensure that a playtones generator does not get started on
the calling channel but rather is started on the local channel on which
the ringing frame was initially indicated.
ASTERISK-25250 #close
Reported by Etienne Lessard
Change-Id: I3bc87a18a38eb2b68064f732d098edceb5c19f39
Previous changes to sample rate support in audiohooks accidentally
removed code responsible for allowing the manipulate audiohooks
to work. Without this code the manipulated frame would be dropped
and not used. This change restores it.
ASTERISK-25253 #close
Change-Id: I3ff50664cd82faac8941f976fcdcb3918a50fe13
Control frames with a -1 payload are used as a special signal to stop
playtones generators on channels. This indication is sent both by
app_dial as well as by ast_answer() when a call is answered in case any
tones were being generated on a calling channel.
This control frame type was made to stop traversing local channel pairs
as an optimization, because it was thought that it was unnecessary to
send these indications, and allowing such unnecessary control frames to
traverse the local channels would cause the local channels to optimize
away less quickly.
As it turns out, through some special magic dialplan code, it is
possible to have a tones being played on a non-local channel, and it is
important for the local channel to convey that the tones should be
stopped. The result of having tones continue to be played on the
non-local channel is that the tones play even once the channel has been
bridged. By not blocking the -1 control frame type, we can ensure that
this situation does not happen.
ASTERISK-25250 #close
Reported by Etienne Lessard
Change-Id: I0bcaac3d70b619afdbd0ca8a8dd708f33fd2f815
Due to changes in audiohooks to support different sample rates the
underlying storage of samples is in the format of the audiohook
itself and not of the format being requested. This means that if a
channel is using G722 the samples stored will be at 16kHz. If
something subsequently reads from the audiohook at a format which
is not the same sample rate as the audiohook the number of samples
needs to be adjusted.
Given the following example:
1. Channel writing into audiohook at 16kHz (as it is using G722).
2. Chanspy reading from audiohook at 8kHz.
The original code would read 160 samples from the audiohook for
each 20ms of audio. This is incorrect. Since the audio in the
audiohook is at 16kHz the actual number needing to be read is 320.
Failure to read this much would cause the audiohook to reset
itself constantly as the buffer became full.
This change adjusts the requested number of samples by determining
the duration of audio requested and then calculating how many
samples that would be in the audiohook format.
ASTERISK-25247 #close
Change-Id: Ia91ce516121882387a315fd8ee116b118b90653d
This adds an "rtp_keepalive" option for PJSIP endpoints. Similar to the
chan_sip option, this specifies an interval, in seconds, at which we
will send RTP comfort noise frames. This can be useful for keeping RTP
sessions alive as well as keeping NAT associations alive during lulls.
ASTERISK-25242 #close
Reported by Mark Michelson
Change-Id: I3b9903d99e35fe5d0b53ecc46df82c750776bc8d
Fixes for issues with the ASTERISK-24934 patch.
* Fixed ast_escape_alloc() and ast_escape_c_alloc() if the s parameter is
an empty string. If it were an empty string the functions returned NULL
as if there were a memory allocation failure. This failure caused the AMI
VarSet event to not get posted if the new value was an empty string.
* Fixed dest buffer overwrite potential in ast_escape() and
ast_escape_c(). If the dest buffer size is smaller than the space needed
by the escaped s parameter string then the dest buffer would be written
beyond the end by the nul string terminator. The num parameter was really
the dest buffer size parameter so I renamed it to size.
* Made nul terminate the dest buffer if the source string parameter s was
an empty string in ast_escape() and ast_escape_c().
* Updated ast_escape() and ast_escape_c() doxygen function description
comments to reflect reality.
* Added some more unit test cases to /main/strings/escape to cover the
empty source string issues.
ASTERISK-25255 #close
Reported by: Richard Mudgett
Change-Id: Id77fc704600ebcce81615c1200296f74de254104
An http request can be sent to retrieve information on a single
module, including the resource name, description, use count, status,
and support level.
The command "curl -v -u user:pass -X GET 'http://localhost:8088/ari
/asterisk/modules/{moduleName}'" (or something similar, depending on
configuration) can be run in the terminal to access this new
functionality.
For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource
* Added new ARI functionality
* Information on a single module can now be retrieved
ASTERISK-25173
Change-Id: Ibce5a94e70ecdf4e90329cf0ba66c33a62d37463
During an attended transfer a thread is started that handles imparting the
bridge channel. From the start of the thread to when the bridge channel is
ready exists a gap that can potentially cause problems (for instance, the
channel being swapped is hung up before the replacement channel enters the
bridge thus stopping the transfer). This patch adds a condition that waits
for the impart thread to get to a point of acceptable readiness before
allowing the initiating thread to continue.
ASTERISK-24782
Reported by: John Bigelow
Change-Id: I08fe33a2560da924e676df55b181e46fca604577
This patch adds five CLI commands for the media cache:
* 'media cache show all' - display a summary of all items in the media
cache.
* 'media cache show <uri>' - display detailed information about a
single item in the media cache.
* 'media cache delete <uri>' - remove an item from the media cache, and
inform the bucket backend for the URI scheme to remove the item as
well.
* 'media cache refresh <uri>' - refresh a URI. If the item does not
exist in the media cache, the bucket backend will pull down the media
associated with the URI and create the item in the cache.
* 'media cache create <uri>' - create an item in the media cache from
some local media storage. Note that the bucket backend for the URI
scheme must still permit the item creation.
Change-Id: Id1c5707a3b8e2d96b56e4691a46a936cd171f4ae
This patch adds a new API to the Asterisk core that acts as a media
cache. The core API itself is mostly a thin wrapper around some bucket
API provided implementation that itself acts as the mechanism of
retrieval for media. The media cache API in the core provides the
following:
* A very thin in-memory cache of the active bucket_file items. Unlike a
more traditional cache, it provides no expiration mechanisms. Most
queries that hit the in-memory cache will also call into the bucket
implementations as well. The bucket implementations are responsible
for determining whether or not the active record is active and valid.
This makes sense for the most likely implementation of a media cache
backend, i.e., HTTP. The HTTP layer itself is the actual arbiter of
whether or not a record is truly active; as such, the in-memory cache
in the core has to defer to it.
* The ability to create new items in the media cache from local
resources. This allows for re-creation of items in the cache on
restart.
* Synchronization of items in the media cache to the AstDB. This
also includes various pieces of important metadata.
The API provides sufficient access that higher level APIs, such as the
file or app APIs, do not have to worry about the semantics of the bucket
APIs when needing to playback a resource.
In addition, this patch provides unit tests for the media cache API. The
unit tests use a fake bucket backend to verify correctness.
Change-Id: I11227abbf14d8929eeb140ddd101dd5c3820391e
This patch adds a new function to the bucket API for ast_bucket_file
objects, ast_bucket_file_metadata_callback. It will call ao2_callback on
the ast_bucket_file's ao2_container of metadata, calling the provided
ao2_callback_fn callback on each piece of metadata associated with the
file.
This is particularly useful when a bucket backend has added metadata,
and a higher level API wants to be aware of/access said metadata,
without knowing for sure what the key is.
Change-Id: I96f6757717f47b650df91a437f7df16406227466
Some individual fields may fail their conversion due to their default
values being invalid for their custom handlers. In particular,
configuration values that depend on others being enabled (and thus have
an empty default value) are notorious for tripping this routine up. An
example of this are any of the DTLS options for endpoints. Any of the
DTLS options will fail to be applied (as DTLS is not enabled), causing
the entire object set to be aborted.
This patch makes it so that we log a debug message when skipping a
field, and rumble on anyway.
ASTERISK-25238
Change-Id: I0bea13de79f66bf9f9ae6ece0e94a2dc1c026a76
We have a strange relationship between the parsing of format
capabilities from a string and their representation as a string. We
expect the format capabilities to be expressed as a string in the
following format:
allow = !all,ulaw,alaw
disallow = g722
While we would generate the string representation of those formats as:
allow = (ulaw|alaw)
disallow = (ulaw|alaw|g729...)
When the configuration framework needs to store values as a string, it
generates the format capabilities using the second representation; this
representation however cannot be parsed when the entry is rehydrated.
This patch fixes that by updating
ast_format_cap_update_by_allow_disallow to parse an entry as if it were
in the generated format if it has a leading '(' and a trailing ')'.
ASTERISK-25238
Change-Id: I904d43caf4cf45af06f6aee0c9e58556eb91d6ca
If a sorcery wizard does not support one of the 'optional' CRUD
operations (namely the CUD), log a WARNING message so we are aware of
why the operation failed. This also removes an assert in this case, as
the CUD operation may have been triggered by an external system, in
which case it is not a programming error but a configuration error.
Change-Id: Ifecd9df946d9deaa86235257b49c6e5e24423b53
Currently, the device state provider API will allow you to register a
device state provider with the same case insensitive name more than
once. This could cause strange issues, as the duplicate device state
providers will not be queried when a device's state has to be polled.
This patch updates the API such that a device state provider with the
same name as one that has already registered will be rejected.
Change-Id: I4a418a12280b7b6e4960bd44f302e27cd036ceb2
An http request can be sent to retrieve a list of all existing modules,
including the resource name, description, use count, status, and
support level.
The command "curl -v -u user:pass -X GET 'http://localhost:8088/ari/
asterisk/modules" (or something similar, depending on configuration)
can be run in the terminal to access this new functionality.
For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource
* Added new ARI functionality
* Information on modules can now be retrieved
Change-Id: I63cbbf0ec0c3544cc45ed2a588dceabe91c5e0b0
