In sorcery based config files where there are multiple categories with the same
name, you can't use the (+) operator to reliably append to a category because
config.c stops looking when it finds the first one with the same name.
Example:
[1000]
type = endpoint
[1000]
type = aor
[1000](+)
authenticate_qualify = yes
This config will fail because config.c appends authenticate_qualify to the
first category it finds, the endpoint, and that's not valid for endpoint.
Solution:
The capability to find a category that contains a certain variable already
exists so the only real change was to parse anything after the '+' that's not a
comma, as a filter string.
[1000]
type = endpoint
[1000]
type = aor
[1000](+type=aor)
authenticate_qualify = yes
This now works as expected.
Although the following example doesn't make any sense for pjsip, you can even
specify multiple filters:
[1000](+type=aor&qualify_frequency=10)
ASTERISK-25868 #close
Reported-by: Nick Repin
Change-Id: I10773da4c79db36fbf1993961992af63d3441580
String fields are great, except that you can't add new ones without breaking
ABI compatibility because it shifts down everything else in the structure.
The only alternative is to add your own char * field to the end of the
structure and manage the memory yourself which isn't ideal, especially since
you then can't use the OPT_STRINGFIELD_T type.
Background:
The reason string fields had to be declared inside the
AST_DECLARE_STRING_FIELDS block was to facilitate iteration over all declared
fields for initialization, compare and copy. Since AST_DECLARE_STRING_FIELDS
declared the pool, then the fields, then the manager, you could use the offsets
of the pool and manager and iterate over the sequential addresses in between to
access the fields. The actual pool, field allocation and field set operations
don't actually care where the field is. It's just iteration over the fields
that was the problem.
Solution: Extended String Fields
An extended string field is one that is declared outside the
AST_DECLARE_STRING_FIELDS block but still (anywhere) inside the parent
structure. Other than using AST_STRING_FIELD_EXTENDED instead of
AST_STRING_FIELD, it looks the same as other string fields. It's storage comes
from the pool and it participates in string field compare and copy operations
peformed on the parent structure. It's also a valid target for the
OPT_STRINGFIELD_T aco option type.
Implementation:
To keep track of the extended fields and make sure that ABI isn't broken, the
existing embedded_pool pointer in the manager structure was repurposed to be a
pointer to a separate header structure that contains the embedded_pool pointer
plus a vector of fields. The length of the manager structure didn't change and
the embedded_pool pointer isn't used in the macros, only the stringfields C
code. A side benefit of this is that changing the header structure in the
future won't break ABI.
ast_string_fields_init initializes the normal string fields and appends them to
the vector, and subsequent calls to ast_string_field_init_extended initialize
and append the extended fields. Cleanup, ast_string_fields_cmp, and
ast_string_fields_copy can now work on the vector instead of sequentially
traversing the addresses between the pool and manager.
The total size of a structure using string fields didn't change, whether using
extended fields or not, nor have the offsets of any structure members, either
inside the original block or outside. Adding an extended field to the end of a
structure is the same as adding a char *.
Details:
The stringfield C code was pulled out from utils.c and into stringfields.c.
It just made sense.
Additional work was done in ast_string_field_init and
ast_calloc_with_stringfields to handle the allocation of the new header
structure and the vector, and the associated cleanup. In the process some
additional NULL pointer checking was added.
A lot of work was done in stringfields.h since the logic for compare and copy
is there. Documentation was added as well as somne additional NULL checking.
The ability to call ast_calloc_with_stringfields with a number of structures
greater than 1 never really worked. Well, the calloc worked but there was no
way to access the additional structures or clean them up. It was agreed that
there was no use case for requesting more than 1 structure so an ast_assert
was added to prevent it and the iteration code removed.
Testing:
The stringfield unit tests were updated to test both normal and extended
fields. Tests for ast_string_field_ptr_set_by_fields and
ast_calloc_with_stringfields were also added.
As an ABI test, 13 was compiled from git and the res_pjsip_* modules, except
res_pjsip itself, saved off. The patch was then added and a full compile and
install was performed. Then the older res_pjsip_* moduled were copied over the
installed versions so res_pjsip was new and the rest were old. No issues.
contact->aor, which is a char * at the end of contact, was then changed to an
extended string field and a recompile and reinstall was performed, again
leaving stock versions of the the res_pjsip_* modules. Again, no issues with
the res_pjsip_* modules using the old stringfield implementation and with
contact->aor as a char *, and res_pjsip itself using the new stringfield
implementation and contact->aor being an extended string field.
Finally, several existing string fields were converted to extended string
fields to test OPT_STRINGFIELD_T. Again, no issues.
Change-Id: I235db338c5b178f5a13b7946afbaa5d4a0f91d61
LDCONFIG apparently isn't set to something sane on all systems so the creation
of the shared library links fails. Instead of just testing for non-blank,
main/Makefile now checks that LDCONFIG is actually executable and reverts to
LN if it isn't.
This applies to both libasteriskpj and libasteriskssl.
Thanks to 'abelbeck' for pointing out that the issue was LDCONFIG.
ASTERISK-25873 #close
Reported-by: Hans van Eijsden
Change-Id: I25b76379bc637726ec044b2c0e709b56b3701729
Asterisk uses separate UDP ports for RTP and RTCP traffic and RFC 5764
explicitly states:
There MUST be a separate DTLS-SRTP session for each distinct pair of
source and destination ports used by a media session
This means RTP keying material cannot be used for DTLS RTCP, which was
the reason why RTCP encryption would fail.
ASTERISK-25642
Change-Id: I7e8779d8b63e371088081bb113131361b2847e3a
There were a number of places in the res_pjsip stack that were getting
all endpoints or all aors, and then filtering them locally.
A good example is pjsip_options which, on startup, retrieves all
endpoints, then the aors for those endpoints, then tests the aors to see
if the qualify_frequency is > 0. One issue was that it never did
anything with the endpoints other than retrieve the aors so we probably
could have skipped a step and just retrieved all aors. But nevermind.
This worked reasonably well with local config files but with a realtime
backend and thousands of objects, this was a nightmare. The issue
really boiled down to the fact that while realtime supports predicates
that are passed to the database engine, the non-realtime sorcery
backends didn't.
They do now.
The realtime engines have a scheme for doing simple comparisons. They
take in an ast_variable (or list) for matching, and the name of each
variable can contain an operator. For instance, a name of
"qualify_frequency >" and a value of "0" would create a SQL predicate
that looks like "where qualify_frequency > '0'". If there's no operator
after the name, the engines add an '=' so a simple name of
"qualify_frequency" and a value of "10" would return exact matches.
The non-realtime backends decide whether to include an object in a
result set by calling ast_sorcery_changeset_create on every object in
the internal container. However, ast_sorcery_changeset_create only does
exact string matches though so a name of "qualify_frequency >" and a
value of "0" returns nothing because the literal "qualify_frequency >"
doesn't match any name in the objset set.
So, the real task was to create a generic string matcher that can take a
left value, operator and a right value and perform the match. To that
end, strings.c has a new ast_strings_match(left, operator, right)
function. Left and right are the strings to operate on and the operator
can be a string containing any of the following: = (or NULL or ""), !=,
>, >=, <, <=, like or regex. If the operator is like or regex, the
right string should be a %-pattern or a regex expression. If both left
and right can be converted to float, then a numeric comparison is
performed, otherwise a string comparison is performed.
To use this new function on ast_variables, 2 new functions were added to
config.c. One that compares 2 ast_variables, and one that compares 2
ast_variable lists. The former is useful when you want to compare 2
ast_variables that happen to be in a list but don't want to traverse the
list. The latter will traverse the right list and return true if all
the variables in it match the left list.
Now, the backends' fields_cmp functions call ast_variable_lists_match
instead of ast_sorcery_changeset_create and they can now process the
same syntax as the realtime engines. The realtime backend just passes
the variable list unaltered to the engine. The only gotcha is that
there's no common realtime engine support for regex so that's been noted
in the api docs for ast_sorcery_retrieve_by_fields.
Only one more change to sorcery was done... A new config flag
"allow_unqualified_fetch" was added to reg_sorcery_realtime.
"no": ignore fetches if no predicate fields were supplied.
"error": same as no but emit an error. (good for testing)
"yes": allow (the default);
"warn": allow but emit a warning. (good for testing)
Now on to res_pjsip...
pjsip_options was modified to retrieve aors with qualify_frequency > 0
rather than all endpoints then all aors. Not only was this a big
improvement in realtime retrieval but even for config files there's an
improvement because we're not going through endpoints anymore.
res_pjsip_mwi was modified to retieve only endpoints with something in
the mailboxes field instead of all endpoints then testing mailboxes.
res_pjsip_registrar_expire was completely refactored. It was retrieving
all contacts then setting up scheduler entries to check for expiration.
Now, it's a single thread (like keepalive) that periodically retrieves
only contacts whose expiration time is < now and deletes them. A new
contact_expiration_check_interval was added to global with a default of
30 seconds.
Ross Beer reports that with this patch, his Asterisk startup time dropped
from around an hour to under 30 seconds.
There are still objects that can't be filtered at the database like
identifies, transports, and registrations. These are not going to be
anywhere near as numerous as endpoints, aors, auths, contacts however.
Back to allow_unqualified_fetch. If this is set to yes and you have a
very large number of objects in the database, the pjsip CLI commands
will attempt to retrive ALL of them if not qualified with a LIKE.
Worse, if you type "pjsip show endpoint <tab>" guess what's going to
happen? :) Having a cache helps but all the objects will have to be
retrieved at least once to fill the cache. Setting
allow_unqualified_fetch=no prevents the mass retrieve and should be used
on endpoints, auths, aors, and contacts. It should NOT be used for
identifies, registrations and transports since these MUST be
retrieved in bulk.
Example sorcery.conf:
[res_pjsip]
endpoint=config,pjsip.conf,criteria=type=endpoint
endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error
ASTERISK-25826 #close
Reported-by: Ross Beer
Tested-by: Ross Beer
Change-Id: Id2691e447db90892890036e663aaf907b2dc1c67
Blind transfers to a recognized parking extension need to use the parker's
channel variable values to create the dynamic parking lot. This is
because there is always only one parker while the parkee may actually be a
multi-party bridge. A multi-party bridge can never supply the needed
channel variables to create the dynamic parking lot. In the multi-party
bridge blind transfer scenario, the parker's CHANNEL(parkinglot) value and
channel variables are inherited by the local channel used to park the
bridge.
* In park_common_setup(), make use the parker instead of the parkee to
supply the dynamic parking lot channel variable values. In all but one
case, the parkee is the same as the parker. However, in the recognized
parking extension blind transfer scenario for a two party bridge they are
different channels. For consistency, we need to use the parker channel.
* In park_local_transfer(), pass the CHANNEL(parkinglot) value to the
local channel when blind transferring a multi-party bridge to a recognized
parking extension.
* When a local channel starts a call, the Local;2 side needs to inherit
the CHANNEL(parkinglot) value from Local;1.
The DTMF one-touch parking case wasn't even trying to create dynamic
parking lots before it aborted the attempt.
* In parking_park_call(), add missing code to create a dynamic parking
lot.
A DTMF bridge hook is documented as returning -1 to remove the hook.
Though the hook caller is really coded to accept non-zero. See the
ast_bridge_hook_callback typedef.
* In feature_park_call(), don't remove the DTMF one-touch parking hook
because of an error.
ASTERISK-24605 #close
Reported by: Philip Correia
Patches:
call_park.patch (license #6672) patch uploaded by Philip Correia
Change-Id: I221d3a8fcc181877a1158d17004474d35d8016c9
The file playback system will now query the media cache and then
the old file functionality. Under normal conditions this will result
in the cache failing to retrieve a file causing a warning message
to get output each time a file is played back.
This change demotes this warning to a debug message.
Change-Id: Ib72246ba300b5cce32774bfb3c26634bfb708624
During stress testing, we have frequently seen crashes occur because a
CLI or AMI command attempts to access information that is in the process
of being destroyed.
When addressing how to fix this issue, we initially considered fixing
individual crashes we observed. However, the changes required to fix
those problems would introduce considerable overhead to the nominal
case. This is not reasonable in order to prevent a crash from occurring
while Asterisk is already shutting down.
Instead, this change makes it so AMI and CLI commands cannot be executed
if Asterisk is being shut down. For AMI, this is absolute. For CLI,
though, certain commands can be registered so that they may be run
during Asterisk shutdown.
ASTERISK-25825 #close
Change-Id: I8887e215ac352fadf7f4c1e082da9089b1421990
The configuration unsigned integer option handler sets flags for the
parser as if the option should be a signed integer (PARSE_INT32),
leading to errors on "out of range" values. Fix flags (PARSE_UINT32).
A fix to res_pjsip is also present which stops invalid flags from
being passed when registering sorcery object fields for qualify
status.
ASTERISK-25612 #close
Change-Id: I96b539336275e0e72a8e8033487d2c3344debd3e
The fix to ASTERISK-25407 introduced the usage of LOG_MAKEPRI. However
this macro is broken in older glibc (< 2.17); it would left-shift the
facility a second time, causing the resultant priority to become
invalid.
The syslog manpage mentions nothing about LOG_MAKEPRI and suggests this:
The priority argument is formed by ORing the facility and the level
values [...].
ASTERISK-25510 #close
Reported by: Michael Newton
Change-Id: Ia89debe7fac5ad090c7ef595c0707f31bb1e3d03
There is a little known feature in app_controlplayback that will cause the
specified offset to be used relative to the end of a file if a ':end' is
detected within the filename.
This feature is pretty bad, but okay.
However, a bug exists in this code where a ':' detected in the filename
will cause the end pointer to be non-NULL, even if the full ':end' isn't
specified. This causes us to treat an unspecified offset (0) as being
"start playing from the end of the file", resulting in no file playback
occurring.
This patch fixes this bug by resetting the end pointer if ':end' is not
found in the filename.
Change-Id: Ib4c7b1b45283e4effd622a970055c51146892f35
This patch allows applications/APIs that access media through the core file
APIs to play media in the media cache. Prior to determining if a 'filename'
exists, the filename is passed to the media cache's retrieve API call. If
that call succeeds, the local file specified passed back by the API is
opened for streaming. When used in this fashion, the 'filename' is actually
a URI that the media cache process and understand.
ASTERISK-25654 #close
Change-Id: I73b6e2e90c3e91b8500581c45cdf9c0dc785f5f0
This patch does the following:
First, it addresses file extension handling in the media cache. The media core
in Asterisk is a bit interesting in that it wants:
* A file to have an extension on it. That extension is used to associate the
file with a defined format module.
* The filename passed to the core to not have an extension on it. This allows
the core to match the available file formats with the format a channel
is capable of handling.
Unfortunately, this makes the current implementation a bit lacking in the media
cache. By default, we do not store the extension of a retrieved URI on the
local file that is created. As a result, the media core does not know what
format the file is, and the file is ignored. Modifying the file outside of the
media core is bad, as we would not be able to update the internal
ast_bucket_file's path.
At the same time, we do not want to pass the extension out in the file_path
parameter in ast_media_cache_retrieve. This parameter is intended to be fed
into the media core; if we passed the extension, all callers would have to
strip it off.
Thus, this patch does the following:
* If there is an extension specified in the URL, we append it to the local
file name (if a preferred file name isn't specified), and we store that
in the local file path.
* The extension, however, is stripped off of the file_path parameter passed
back out of ast_media_cache_retrieve.
Second, this patch causes stale items to be completely removed from the system.
Prior to this patch, sound files could be orphaned due to the bucket
referencing the file being deleted, but the file itself not being removed. This
is now addressed by explicitly calling ast_bucket_file_delete on the
bucket_file when it is deemed to be stale. Note that this only happen when we
know we will attempt to retrieve the resource again.
Finally, this patch changes the AO2 container holding media items to just use
a regular mutex. The usage for this container already assumed it was a plain
mutex, and - given that retrieval of an item can cause it to be replaced in
the container - a mutex makes more sense than a read/write lock.
Change-Id: I51667fff86ae8d2e4a663555dfa85b11e935fe0f
This patch is part of a series to resolve deadlocks in chan_sip.c.
* Updated sched unit test to check new behavior.
ASTERISK-25023
Change-Id: Ib69437327b3cda5e14c4238d9ff91b2531b34ef3
Channel masquerading had a conflict with autochannel locking.
When locking autochannel->channel, the channel is fetched from the
autochannel and then locked. During the fetch, the autochannel -- which
has no locks itself -- can be modified by someone who owns the channel
lock. That means that the value of autochan->channel cannot be trusted
until you hold the lock.
In practice, this caused problems with Local channels getting
masqueraded away while the ChanSpy attempted to get info from that
channel. The old channel which was about to get removed got locked, but
the new (replaced) channel got unlocked (no-op). Because the replaced
channel was now locked (and would never get unlocked), it couldn't get
removed from the channel list in a timely manner, and would now cause
deadlocks when iterating over the channel list.
This change checks the autochannel after locking the channel for changes
to the autochannel. If the channel had been changed, the lock is
reobtained on the new channel.
In theory it seems possible that after this fix, the lock attempt on the
old (wrong) channel can be on an already destroyed lock, maybe causing
a crash. But that hasn't been observed in the wild and is harder induce
than the current deadlock.
Thanks go to Filip Frank for suggesting a fix similar to this and
especially to IRC user hexanol for pointing out why this deadlock was
possible and testing this fix. And to Richard for catching my rookie
while loop mistake ;)
ASTERISK-25321 #close
Change-Id: I293ae0014e531cd0e675c3f02d1d118a98683def
Refactor and created function ast_cli_print_timestr_fromseconds to print
seconds formatted: year(s) week(s) day(s) hour(s) second(s)
This function now is used in addons/cdr_mysql.c,cdr_pgsql.c, main/cli.c,
res_config_ldap.c, res_config_pgsql.c.
Change-Id: Ibeb8634102cd11d3f8623398b279cb731bcde36c
Although we use the RTLD_LAZY flag when calling dlopen
the first time on a module, this only defers resolution
for function calls. Pointer references to functions are
determined at link time so dlopen expects them to be there.
Since we don't cross-module link, pointers to functions
in other modules won't be available and dlopen will fail.
Doing a "hardened" build also causes problems because it
typically sets "-z now" on the ld command line which
overrides RTLD_LAZY at run time.
If the failing module isn't a GLOBAL_SYMBOLS module, then
dlopen will be called again after all the GLOBAL_SYMBOLS
modules have been loaded and they'll eventually resolve.
If the calling module IS a GLOBAL_SYMBOLS module itself
and a third module depends on it, then there's an issue
because the second time through the dlopen loop,
GLOBAL_SYMBOLS modules aren't given any special treatment
and since the order in which dlopen is called isn't
deterministic, the dependent may again be tried before the
module it needs is loaded.
Simple solution: Save modules that fail load_resource
because of a dlopen error in a list and retry them
immediately after the first pass. Keep retrying until
the failed list is empty or we reach a #defined max
retries. Error messages are suppressed until the final
pass which also gets rid of those confusing error messages
about module failures that are later corrected.
Change-Id: Iddae1d97cd2f00b94e61662447432765755f64bb
It's possible for the transferer channel to get hung up early during the
attended transfer process. For instance, a phone may send a "bye" immediately
upon receiving a sip notify that contains a sip frag 100 (I'm looking at you
Jitsi). When this occurs a race begins between the transferer being hung up
and completion of the transfer code.
If the channel hangs up too early during a transfer involving stasis bridging
for instance, then when the created local channel goes to look up its swap
channel (and associated datastore) it can't find it (since it is no longer in
the bridge) thus it fails to enter the stasis application. Consequently, the
created local channel(s) hang up as well. If the timing is just right then the
bridging code attempts to add the message link with missing local channel(s).
Hence the crash.
Unfortunately, there is no great way to solve the problem of the unexpected
"bye". While we can't guarantee we won't receive an early hangup, and in this
case still fail to enter the stasis application, we can make it so asterisk
does not crash.
This patch does just that by locking the local channel structure, checking
that the local channel's peer has not been lost, and then continuing. This
keeps the local channel's peer from being ripped out from underneath it by
the local/unreal hangup code while attempting to set the stasis message link.
ASTERISK-25771
Change-Id: Ie6d6061e34c7c95f07116fffac9a09e5d225c880
In message.c, if msg_alloc fails to init the string field,
vars may be null, so use a null tolerant cleanup.
In res_pjsip_messaging.c, if msg_data_create fails, mdata
will be null, so use a null tolerant cleanup.
ASTERISK-25323
Change-Id: Ic2d55c2c3750d5616e2a05ea92a19c717507ff56
Previous chan_sip behavior:
Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason). For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize. Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).
Previous chan_pjsip behavior:
Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason). For an outgoing reason value, chan_pjsip
would send the reason value as passed down.
With this patch:
Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not. RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason). e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value. The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.
The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).
Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent. User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token. Note that there are still
limitations on what characters can be put in a custom user value. e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.
* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.
* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().
* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header(). The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.
Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
The channel is now going to get T.38 terminated when it leaves the
bridging system and the bridged peers are going to get T.38 terminated as
well.
ASTERISK-25582
Change-Id: I77a9205979910210e3068e1ddff400dbf35c4ca7
Local channel optimization could cause DTMF digits to be duplicated.
Pending DTMF end events would be posted to a bridge when the local channel
optimizes out and is replaced by the channel further down the chain. When
the real digit ends, the channel would get another DTMF end posted to the
bridge.
A -- LocalA;1/n -- LocalA;2/n -- LocalB;1 -- LocalB;2 -- B
1) LocalA has the /n flag to prevent optimization.
2) B is sending DTMF to A through the local channel chain.
3) When LocalB optimizes out it can move B to the position of LocalB;1
4) Without this patch, when B swaps with LocalB;1 then LocalB;1 would
settle an owed DTMF end to the bridge toward LocalA;2.
5) When B finally ends its DTMF it sends the DTMF end down the chain.
6) Without this patch, A would hear the DTMF digit end when LocalB
optimizes out and when B ends the original digit.
ASTERISK-25582
Change-Id: I1bbd28b8b399c0fb54985a5747f330a4cd2aa251
Frame hooks can conceivably return a control frame in exchange for an
audio frame inside ast_write(). Those returned control frames were not
handled quite the same as if they were sent to ast_indicate(). Now it
doesn't matter if you use ast_write() to send an AST_FRAME_CONTROL to a
channel or ast_indicate().
ASTERISK-25582
Change-Id: I5775f41421aca2b510128198e9b827bf9169629b
The ast_sorcery_create, update and delete function have been refactored
to better deal with caches and errors.
The action is now called on all non-caching wizards first. If ANY succeed,
the action is called on all caching wizards and the observers are notified.
This way we don't put something in the cache (or update or delete) before
knowing the action was performed in at least 1 backend and we only call the
observers once even if there were multiple writable backends.
ast_sorcery_create was never adding to caches in the first place which
was preventing contacts from getting added to a memory_cache when they
were created. In turn this was causing memory_cache to emit errors if
the contact was deleted before being retrieved (which would have
populated the cache).
ASTERISK-25811 #close
Reported-by: Ross Beer
Change-Id: Id5596ce691685a79886e57b0865888458d6e7b46
The return type of ast_cel_track_event() is not large enough to return all
64 potential bits of the event enable mask. Fortunately, the defined CEL
events do not really need all 64 bits and the return value is only used to
determine if the requested CEL event is enabled.
* Made the ast_cel_track_event() return 0 or 1 only so the return value
can fit inside an int type instead of zero or a truncated 64 bit non-zero
value.
Change-Id: I783d932320db11a95c7bf7636a72b6fe2566904c
The SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 defines did not exist prior
to OpenSSL version 1.0.1. A recent commit attempts to, by default, set
these options, which can cause problems on systems with older OpenSSL
installations.
This commit adds a configure script check for those defines and will not
attempt to make use of those if they do not exist. We will print a
warning urging the user to upgrade their OpenSSL installation if those
defines are not present.
Change-Id: I6a2eb9a43fd0738b404d8f6f2cf4b5c22d9d752d
This change exposes the configuration of various aspects of the TLS
support and sets the default to the modern standards.
The TLS cipher is now set to the best values according to the
Mozilla OpSec team, different TLS versions can now be disabled, and
the cipher order can be forced to be that of the server instead of
the client.
ASTERISK-24972 #close
Change-Id: I0a10f2883f7559af5e48dee0901251dbf30d45b8
Sending UDPTL packets to Asterisk with the right amount of missing
sequence numbers and enough redundant 0-length IFP packets, can make
Asterisk crash.
ASTERISK-25603 #close
Reported by: Walter Doekes
ASTERISK-25742 #close
Reported by: Torrey Searle
Change-Id: I97df8375041be986f3f266ac1946a538023a5255
The config options framework is strict in that configuration options must
be documented unless XML documentation support is not available. In
practice this is useful as it ensures documentation exists however in
off-nominal cases this can cause strange problems.
If it is expected that a config option has a non-zero or non-empty
default value but the config option documentation is unavailable
this reasonable expectation will not be met. This can cause obscure
crashes and weirdness depending on how the code handles it.
This change tweaks the behavior to ensure that the config option
is still allowed to register, apply default values, and be set when
devmode is not enabled. If devmode is enabled then the option can
NOT be set.
This also does not remove the initial documentation error message that
is output on load when registering the configuration option.
ASTERISK-25725 #close
Change-Id: Iec42fca6b35f31326c33fcdc25473f6fd7bc8af8
The null terminator of the tail struct member was not being allocated
when no logger.conf config file is installed.
ASTERISK-25714 #close
Reported by: Badalian Vyacheslav
Change-Id: I45770fdd08af39506a3bc33ba279c4f16e047a30
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
