The cache_clear test was written to expect duplicate Stasis messages
sent from the technology endpoint to the all caching topic. This patch
fixes the test to no longer expect these duplicate messages.
ASTERISK-25137
Change-Id: I58075d70d6cdf42e792e0fb63ba624720bfce981
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
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
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
This patch adds more tests that exercise the device state API. This includes:
* Tests that cover adding a device state provider, as well as deleting a
device state provider. This also verifies that you cannot add an
already added device state provider, and cannot delete an already
deleted device state provider.
* A test that covers changing device state and receiving said updates
from a device state subscriber. This also covers hitting both the
device state cache as well as a custom device state provider.
* A test that covers converting device state to channel state and device
state values to a string representation and back.
* A test that covers obtaining device state from an active channel and a
channel driver that provides its own device state.
Change-Id: I2adca67ffb405cd8625a5d6df1e3f9b3d945c08d
Because unit tests now want descriptions to not end with a newline, the
sorcery memory cache thrash tests failed to register. This patch
corrects their descriptions.
Change-Id: Id004b1becfdeed8ee3c846f49beab76a5c0f68b6
Gerrit is complaining of conflicts when trying to create a patch series
of all of the cherry-picked master commits, so I have instead squashed
it all into one commit.
ASTERISK-25067 #close
Reported by: Matt Jordan
Change-Id: I6dda90343fae24a75dc5beec84980024e8d61eb9
Analyzing the code shows that the unit test summary and description
strings should not end with a new-line character. Where these strings are
used in the code a new-line is provided for output.
Change-Id: I129284f5e7ca93d82532334076da4c462d3d9fba
Although ast_context_find, ast_context_find_or_create and
ast_context_destroy perform locking of the contexts table,
any context pointer can become invalid at any time that the
contexts table is unlocked. This change adds locking around
all complete operations involving these functions.
Places where ast_context_find was followed by ast_context_destroy
have been replaced with calls ast_context_destroy_by_name.
ASTERISK-25094 #close
Reported by: Corey Farrell
Change-Id: I1866b6787730c9c4f3f836b6133ffe9c820734fa
So this issue is a bit complicated. Since it is possible to pass values to AMI
that contain a '\r\n' (or other similar sequences) these values need to be
escaped. One way to solve this is to escape the values and then pass the escaped
values to the AMI variable parameter string building function. However, this
puts the onus on the pre-build function to escape all string values. This
potentially requires a fair amount of changes along with a lot of string
allocations/freeing for all values.
Surely there is a way to push this complexity down a level into the string
building function itself? This of course is possible, but ends up requiring a
way to distinguish between strings that need to be escaped and those that don't.
The best way to handle this is by introducing a new format specifier in the
format string. For instance a %s (no escape) and %S (escape). However, that is
a bit weird and unexpected.
So faced with those possibilities this patch implements a limited version of the
first option. Instead of attempting to escape all string values this patch only
escapes those values that make sense. This approach limits the number of changes
and doesn't suffer from the odd format specifier problem.
ASTERISK-24934 #close
Reported by: warren smith
Change-Id: Ib55a5b84fe0481b0f2caaaab68c566f392c0aac0
The config wizard was always pulling the first occurrence of
a variable from an ast_variable list but this gets the template
value from the list instead of any overridden value. This patch
creates ast_variable_find_last_in_list() in config.c and updates
res_pjsip_config_wizard to use it instead of
ast_variable_find_in_list. Now the overridden values, where they
exist, are used instead of template variables.
Updated test_config to test the new API.
ASTERISK-25089 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: Ifa7ddefc956a463923ee6839dd1ebe021c299de4
These modules save a pointer to the context they create on load, and
use that pointer to destroy the context at unload. It is not safe
to save this pointer, it is replaced during load of pbx_config,
pbx_lua or pbx_ael.
This change causes the modules to pass NULL to ast_context_destroy,
a safer way to perform the unregistration since it does not use
a pointer that could become invalid.
ASTERISK-25085 #close
Reported by: Corey Farrell
Change-Id: I6a00ec8e38046058f97dc703e1adcde9bf517835
Currently you can 'apply' a wizard to an object type but the wizard
always goes at the end of the object type's wizard list. This patch
adds a new ast_sorcery_insert_wizard_mapping function that allows
you to insert a wizard anyplace in the list. I.E. You could
add a caching wizard to an object type and place it before all
wizards.
ast_sorcery_get_wizard_mapping_count and
ast_sorcery_get_wizard_mapping were added to allow examination
of the mapping list.
ast_sorcery_remove_mapping was added to remove a mapping by name.
As part of this patch, the object type's wizard list was converted
from an ao2_container to an AST_VECTOR_RW.
A new test was added to test_sorcery for this capability.
ASTERISK-25044 #close
Change-Id: I9d2469a9296b2698082c0989e25e6848dc403b57
Based on feedback from Corey Farrell and Y Ateya, a few new
macros have been added...
AST_VECTOR_REMOVE which takes a parameter to indicate if
order should be preserved.
AST_VECTOR_ADD_SORTED which adds an element to
a sorted vector.
AST_VECTOR_RESET which cleans all elements from the vector
leaving the storage intact.
Change-Id: I41d32dbdf7137e0557134efeff9f9f1064b58d14
After using the new vector stuff for real I found...
A bug in AST_VECTOR_INSERT_AT that could cause a seg fault.
The callbacks needed to be closer to ao2_callback in behavior
WRT to CMP_MATCH and CMP_STOP behavior and the ability to return
a vector of matched entries.
A pre-existing issue with APPEND and REPLACE was also fixed.
I also added a new macro to test.h that acts like ast_test_validate
but also accepts a return code variable and a cleanup label. As well
as printing the error, it sets the rc variable to AST_TEST_FAIL and
does a goto to the specified label on error. I had a local version
of this in test_vector so I just moved it.
ASTERISK-25045
Change-Id: I05e5e47fd02f61964be13b7e8942bab5d61b29cc
My 13 version of test_vector had an ASTERISK_REGISTER_FILE() macro
call at the top which is only supported in master. Once removed
builds are successful.
Change-Id: I7cac8b669bed6de543bbf4e2eec3cffc9741acdd
Renamed AST_VECTOR_INSERT to AST_VECTOR_REPLACE because it really
does replace not insert. The few users of AST_VECTOR_INSERT were
refactored. Because these are macros, there should be no ABI
compatibility issues.
Added AST_VECTOR_INSERT_AT that actually inserts an element into the
vector at a specific index pushing existing elements to the right.
Added AST_VECTOR_GET_CMP that can retrieve from the vector based
on a user-provided compare function.
Added AST_VECTOR_CALLBACK function that will execute a function
for each element in the vector. Similar to ao2_callback and
ao2_callback_data functions although the vector callback can take
a variable number of arguments. This should allow easy migration
to a vector where a container might be too heavy.
Added read/write locked vector and lock manipulation macros.
Added unit tests.
ASTERISK-25045 #close
Change-Id: I2e07ecc709d2f5f91bcab8904e5e9340609b00e0
When r432935 was merged, it did correctly fix a situation where a FILE read
operation on the middle of a file buffer would not read the requested length
in the parameters passed to the FILE function. Unfortunately, it would also
allow the FILE function to append more bytes than what was available in the
buffer if the length exceeded the end of the buffer length.
This patch takes the minimum of the remaining bytes in the buffer along with
the calculated length to append provided by the original patch, and uses
that as the length to append in the return result. This patch also updates
the unit tests with the scenarios that were originally pointed out in
ASTERISK-21765 that the original implementation treated incorrectly.
ASTERISK-21765
........
Merged revisions 433173 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I guess nobody uses templates with AST_CONFIG because today if you have a
context that inherits from a template and you call AST_CONFIG on the context,
you'll get the value from the template even if you've overridden it in the
context. This is because AST_CONFIG only gets the first occurrence which is
always from the template.
This patch adds an optional 'index' parameter to AST_CONFIG which lets you
specify the exact occurrence to retrieve, or '-1' to retrieve the last.
The default behavior is the current behavior.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4313/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430315 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the publication of attended transfer messages were pushed to another
thread, some subtle race conditions were introduced with the CEL unit tests.
This patch fixes one of them, and pushes the other to ASTERISK-22367, which
already exists to fix another bouncy CEL unit test.
In particular, this patch fixes the test_cel_attended_transfer_bridges_link
test, and defers the test_cel_attended_transfer_bridges_swap test to the
aforementioned JIRA issue.
ASTERISK-22367
........
Merged revisions 428891 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When merging the changes up stream in r428687, I missed the fact that the
signature for stasis_message_type_create was changed. This patch fixes
the compilation issues introduced by that merge.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428815 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428687 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a result of https://reviewboard.asterisk.org/r/3305, res_sorcery_realtime
was tossing database fields that didn't have an exact match to a sorcery
registered field. This broke the ability to use regexes as field names which
manifested itself as a failure of res_pjsip_phoneprov_provider which uses
this capability. It also broke handling of fields that start with '@' in
realtime but I don't think anyone noticed.
This patch does the following...
* Modifies ast_sorcery_fields_register to pre-compile the name regex.
* Modifies ast_sorcery_is_object_field_registered to test the regex if it
exists instead of doing an exact strcmp.
* Modifies res_pjsip_phoneprov_provider with a few tweaks to get it to work
with realtime.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4185/
........
Merged revisions 428543 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428544 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a config file is read, an unescaped semicolon signals comments which are
stripped from the value before it's stored. Escaped semicolons are then
unescaped and become part of the value. Both of these behaviors are normal
and expected. When the config is serialized either by 'dialplan save' or
AMI/UpdateConfig however, the now unescaped semicolons are written as-is.
If you actually reload the file just saved, the unescaped semicolons are
now treated as start of comments.
Since true comments are stripped on read, any semicolons in
ast_variable.value must have been escaped originally. This patch
re-escapes semicolons in ast_variable.values before they're written to
file either by 'dialplan save' or config/ast_config_text_file_save which
is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting
issues nearby in pbx_config.c
Tested-by: George Joseph
ASTERISK-20127 #close
Review: https://reviewboard.asterisk.org/r/4132/
........
Merged revisions 427275 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427276 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CEL pickup test previously looked for a disposition of ANSWER between the
original caller/peer when the call is picked up. This is actually incorrect:
the disposition should, at the very least, not be ANSWER as the call was
never ANSWERed. The disposition is now CANCEL; this patch updates the test
accordingly.
........
Merged revisions 425757 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With MALLOC_DEBUG the /main/config config_basic_ops test was causing a
SEGV while doing an ast_category_delete in an ast_category_browse loop.
Apparently this never worked but was also never tested. I removed the
test, added 2 notes to config.h indicating that it's not supported and
added a few lines of code to ast_category_delete to prevent the SEGV
should someone attempt it in the future.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4078/
........
Merged revisions 425525 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides the capability to manipulate templates and categories
with non-unique names via AMI.
Summary of changes:
GetConfig and GetConfigJSON: Added "Filter" parameter: A comma separated list
of name_regex=value_regex expressions which will cause only categories whose
variables match all expressions to be considered. The special variable name
TEMPLATES can be used to control whether templates are included. Passing
'include' as the value will include templates along with normal categories.
Passing 'restrict' as the value will restrict the operation to ONLY templates.
Not specifying a TEMPLATES expression results in the current default behavior
which is to not include templates.
UpdateConfig: NewCat now includes options for allowing duplicate category
names, indicating if the category should be created as a template, and
specifying templates the category should inherit from. The rest of the
actions now accept a filter string as defined above. If there are non-unique
category names, you can now update specific ones based on variable values.
To facilitate the new capabilities in manager, corresponding changes had to be
made to config, most notably the addition of filter criteria to many of the
APIs. In some cases it was easy to change the references to use the new
prototype but others would have required touching too many files for this
patch so a wrapper with the original prototype was created. Macros couldn't
be used in this case because it would break binary compatibility with modules
such as res_digium_phone that are linked to real symbols.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4033/
........
Merged revisions 425383 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this commit, CDR and CEL tests were expected to trigger
FRACKs (i.e. assertions) due to the fact that the channels they
create have no formats on them. Some code was independently added
recently that attempts to prevent FRACKs from occurring by failing
early when attempting to set up translation paths if one or both
channels support no formats. Unfortunately, this attempt to be helpful
made the CDR and CEL tests go from simply FRACKing to outright
failing and in some cases, failing so badly as to crash Asterisk.
This commit seeks to correct past mistakes by adding the ulaw format
to channels created by the CDR and CEL unit tests. This makes setting
up translation paths succeed, eliminates previously-seen FRACKs, and
ultimately causes the unit tests to succeed again.
Review: https://reviewboard.asterisk.org/r/4014
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function acts like strsep with three exceptions...
* The separator is a single character instead of a string.
* Separators inside quotes are treated literally instead of like separators.
* You can elect to have leading and trailing whitespace and quotes
stripped from the result and have '\' sequences unescaped.
Like strsep, ast_strsep maintains no internal state and you can call it
recursively using different separators on the same storage.
Also like strsep, for consistent results, consecutive separators are not
collapsed so you may get an empty string as a valid result.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3989/
........
Merged revisions 423476 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423478 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.
This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
........
Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL typically tracks a lot of information using the unique ID of the channel.
This is typically needed due to tying events together using the linked ID of
the various channels involved in a "call", which is derived from the channel ID
of the oldest channel involved in a bridge (or in the case of a Dial, the
parent channel).
Previously, we had updated the extra fields to include the involved channel
names, but forgot to put in the unique ID. This patch corrects that error.
........
Merged revisions 421037 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces stasis.conf and a mechanism to prevent certain message
types from being published. Internally, this works by preventing the
chosen message types from being created which ensures that those
message types can never be published. This patch also adjusts message
publishers such that message payloads are not created if the related
message type is not available.
ASTERISK-23943 #close
Review: https://reviewboard.asterisk.org/r/3823/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.
Inbound messages can now be received over ARI as well. An ARI application that
subscribes to endpoints will receive messages from those endpoints:
{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" <sip:alice@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has
two callbacks: one to determine if the handler has a destination for the
message, and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them.
Various other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when
the lifetime of things is well defined and the number of things is very
small.
res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.
Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
fix for that as well.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
(1) It updates the unit tests to expect additional stasis messages. More
messages are now sent to the endpoint topic, due to forwarding all
channel messages and the forwarding relationship set up between
endpoints themselves.
(2) Remove the technology forwarding subscription during
ast_endpoint_shutdown. This prevents an improper double shutdown of
an endpoint from occurring.
........
Merged revisions 419318 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects two issues with the extra field information in Asterisk
12+ in channel event logs.
It is possible to inject custom values into the dialstatus provided by
ast_channel_dial_type() Stasis messages that fall outside the
enumeration allowed for the DIALSTATUS channel variable. CEL now
filters for the allowed values and ignores other values.
The "hangupsource" extra field key is always blank if the far end
channel is a chan_pjsip channel. This is because the hangupsource is
never set for the pjsip channel driver. This change sets the
hangupsource whenever a hangup is queued for chan_pjsip channels.
This corrects an issue with the pjsip channel driver where the
hangupcause information was not being set properly.
Review: https://reviewboard.asterisk.org/r/3690/
........
Merged revisions 418071 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update the CEL unit tests that handle BRIDGE_ENTER and BRIDGE_EXIT
events to expect the "bridge_technology" extra field key.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch allows the current owner of a channel to define various
feature hooks to be made available once the channel has entered a
bridge. This includes any hooks that are setup on the
ast_bridge_features struct such as DTMF hooks, bridge event hooks
(join, leave, etc.), and interval hooks.
Review: https://reviewboard.asterisk.org/r/3649/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move some implementation specific code from astobj2_container.c into
astobj2_hash.c and astobj2_rbtree.c. This completely removes the need for
astobj2_container to switch on RTTI and it no longer has any knowledge of
the implementation details.
Also adds AO2_DEBUG as a new compile option in menuselect which controls
astobj2 debugging independently of AST_DEVMODE and REF_DEBUG.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3593/
........
Merged revisions 416806 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a problem when reading a string from the websocket. It assumed the
received data had a null terminator and tried to write the data to an ast_str.
This of course could/would read past the end of the given buffer while
writing the data to the internal buffer of ast_str. Modified the the code to
correctly place a null terminator on the result string.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416394 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We no longer publish a channel snapshot when it is associated with an endpoint;
after all, the channel itself hasn't changed - the endpoint state has changed.
This updates the channel_messages unit test accordingly.
........
Merged revisions 416298 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If using the custom URI parsing code (not external uriparser lib) and there
was no query parameters the resulting pointer would be NULL and then an
attempt was made to subtract from it. The pointer is now set to a valid
value if there is no query parameter(s).
Also, in the 'ast_uri_make_host_with_port' function when setting the terminator
on the resulting string it was writing it one past the end of allocated memory.
It now writes the string terminator appropriately.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a websocket server client in Asterisk. Asterisk has a websocket server,
but not a client. The ability to have Asterisk be able to connect to a websocket
server can potentially be useful for future work (for instance this could allow
ARI to connect back to some external system, although more work would be needed
in order to incorporate that).
Also a couple of things to note - proxy connection support has not been
implemented and there is limited http response code handling (basically, it is
connect or not).
Also added an initial new URI handling mechanism to core. Internet type URI's
are parsed into a data structure that contains pointers to the various parts of
the URI.
(closes issue ASTERISK-23742)
Reported by: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/3541/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit contains several changes to sorcery:
1) Application of sorcery configuration based on module name is automatically performed
when sorcery is opened for a module.
2) Sorcery will not attempt to apply the same wizard to an object type more than once.
3) Sorcery gives more exact results when attempting to apply a wizard, whether as the
default or based on configuration.
Sorcery unit tests still pass for me after making these changes.
Review: https://reviewboard.asterisk.org/r/3326
........
Merged revisions 411159 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Playing back a file to a channel in an ARI bridge would attempt to wait until
the playback concluded before returning. The method used involved signaling the
waiting thread in the ARI custom playback function.
The problem with this is that there were some corner cases that were not accounted for:
* If a bridge channel could not be found, then we never would attempt the playback but
would still attempt to wait for the playback to complete.
* If the bridge playfile action failed to queue, we would still attempt to wait for the
playback to complete.
* If the bridge playfile action were queued but some circumstance caused the playback
not to occur (the bridge dies, the channel is removed from the bridge), then we would
never be notified.
The solution to this is to move the waiting logic into the bridge code. A new bridge
API function is added to queue a synchronous action on a bridge. The waiting thread
is notified when the queued frame has been freed, either due to an error occurring
or due to successful playback. As a failsafe, the waiting thread has a 10 minute
timeout just in case there is a frame leak somewhere.
Review: https://reviewboard.asterisk.org/r/3338
........
Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A stasis cache entry now contains more than a single message/snapshot. It
contains messages/snapshots for the local entity as well as any remote
entities that post to the cached item. In addition callbacks can be
supplied when the cache is created to compute and post the aggregate
message/snapshot representing all entities stored in the cache entry.
* All stasis messages now have an eid to indicate what entity posted it.
* The stasis cache enhancements allow device state to cache and aggregate
the device states from local and remote entities in a single operation.
The cached aggregate device state is available immediately after it is
posted to the stasis bus. This improves performance by eliminating a
cache dump and associated ao2 container traversals to calculate the
aggregate state.
(closes issue ASTERISK-23204)
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3281/
........
Merged revisions 410184 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410185 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch creates the AST_SORCERY dialplan function which allows someone to
retrieve any value from a sorcery-based config file. It's similar to
AST_CONFIG.
The creation of the function itself was fairly straightforward but it required
changes to the underlying sorcery infrastructure that rippled into individual
sorcery objects. The changes stemmed from inconsistencies in how sorcery
created ast_variable objectsets from sorcery objects and the inconsistency
in how individual objects used that feature especially when it came to
parameters that can be specified multiple times like contact in aor and match
in identify. You can read more here...
http://lists.digium.com/pipermail/asterisk-dev/2014-February/065202.html
So, what this patch does, besides actually creating the AST_SORCERY function,
is the following...
* Creates ast_variable_list_append which is a helper to append one ast_variable
list to another.
* Modifies the ast_sorcery_object_field_register functions to accept the
already-defined sorcery_fields_handler callback.
* Modifies ast_sorcery_objectset_create to accept a parameter indicating return
type preference...a single ast_variable with all values concatenated or an
ast_variable list with multiple entries. Also fixed a few bugs.
* Modifies individual sorcery object implementations to use the new function
definition of the ast_sorcery_object_field_register functions.
* Modifies location.c and res_pjsip_endpoint_identifier_ip.c to implement
sorcery_fields_handler handlers so they return multiple occurrences as an
ast_variable_list.
* Added a whole bunch of tests to test_sorcery.
(closes issue ASTERISK-22537)
Review: http://reviewboard.asterisk.org/r/3254/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Make the consumer ao2 object use the ao2 lock instead of a redundant
lock in the struct for ast_cond_wait().
* Fixed some curly brace placements.
* Fixed use of malloc(0). malloc(0) has variant behavior. It is up to
the implementation to determine if it returns NULL or a valid pointer that
can be later passed to free().
........
Merged revisions 408983 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to retrieve an arbitrary sorcery instance from a dialplan function
(or any place else) there needs to be a registry of sorcery instances.
ast_sorcery_init now creates a hashtab as a registry.
ast_sorcery_open now checks the hashtab for an existing sorcery instance
matching the caller's module name. If it finds one, it bumps the
refcount and returns it. If not, it creates a new sorcery instance,
adds it to the hashtab, then returns it.
ast_sorcery_retrieve_by_module_name is a new function that does a hashtab
lookup by module name. It can be called by the future dialplan function.
res_pjsip/config_system needed a small change to share the main res_pjsip
sorcery instance.
tests/test_sorcery was updated to include a test for the registry.
(closes issue ASTERISK-22537)
Review: http://reviewboard.asterisk.org/r/3184/
........
Merged revisions 408518 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed the test_cel_attended_transfer_bridges_link unit test to also
account for the local channel link being destroyed now that the bridges
are actually destroyed.
* Made CDR unit test use its own version of do_sleep() from the CEL unit
tests.
........
Merged revisions 406707 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds an API call to Stasis that allows a publisher to publish a
stasis message that will not return until a specific subscriber handles the
message. Since a subscriber can have their own forwarding topic which orders
messages from many topics, this allows a publisher who knows of that subscriber
to synchronize to that subscriber regardless of the forwarding relationships
between topics.
This is of particular use for dialplan applications that need to synchronize
on a particular subscriber's handling of a message.
(issue ASTERISK-22884)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3099/
........
Merged revisions 405311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405313 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An md5 hash is 32 bytes long. The char buffer must be at least 33 bytes to
avoid clobbering of the stack. This patch also fixes a potential clobbering
in test_utils.c.
Thanks to Andrew Nagy for reporting and testing this out in #asterisk-dev
Reported by: Andrew Nagy
Tested by: Andrew Nagy
........
Merged revisions 404843 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
r404042 gave ast_bridge_base_new two new arguments for setting a bridge creator
and name. Unfortunately since a couple test modules aren't compiled by default,
I missed the fact that this change impacted those tests and caused compilation
failures against them.
........
Merged revisions 404048 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Make ast_sorcery_observer_remove() accept a const callbacks struct.
* Make ast_sorcery_observer_remove() tolerant of the sorcery parameter
being NULL. Now it can be called within a module unload routine if the
sorcery initialization fails.
* Fix ast_sorcery_observer_add() to fail if the container link fails.
........
Merged revisions 403324 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403327 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The patch allows ARI to parse request parameters from an incoming JSON
request body, instead of requiring the request to come in as query
parameters (which is just weird for POST and DELETE) or form
parameters (which is okay, but a bit asymmetric given that all of our
responses are JSON).
For any operation that does _not_ have a parameter defined of type
body (i.e. "paramType": "body" in the API declaration), if a request
provides a request body with a Content type of "application/json", the
provided JSON document is parsed and searched for parameters.
The expected fields in the provided JSON document should match the
query parameters defined for the operation. If the parameter has
'allowMultiple' set, then the field in the JSON document may
optionally be an array of values.
(closes issue ASTERISK-22685)
Review: https://reviewboard.asterisk.org/r/2994/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403177 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After a series of upgrades over recent weeks, I've discovered that
test_json.c won't compile in dev mode any more for me.
One of gcc-4.8.2, OS X Mavericks or Xcode 5 has decided to deprecate
tempnam. Which, in general, is a good thing. But for test code that just
needs a temporary file, it's just annoying.
This patch replaces usage of tempname with mkstemp, avoiding the
deprecation warning. It also removes the temporary files when the test
is complete, which apparently we weren't doing before (oops).
Review: https://reviewboard.asterisk.org/r/2957/
........
Merged revisions 401872 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r400318 | mmichelson | 2013-10-02 17:08:49 -0500 (Wed, 02 Oct 2013) | 12 lines
Remove unnecessary waits from stasis.
Since caches are updated on publisher threads, there is no need
to wait for the cache updates to occur after a stasis message
is published.
In the case of chan_pjsip device state changes, this set of
changes caused an improvement to performance.
Review: https://reviewboard.asterisk.org/r/2890
........
r400319 | mmichelson | 2013-10-02 17:10:54 -0500 (Wed, 02 Oct 2013) | 3 lines
Remove svn:mergeinfo property.
........
Merged revisions 400318-400319 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
This patch optimizes how forwards are dispatched in Stasis.
Originally, forwards were dispatched as subscriptions that are invoked
on the publishing thread. This did not account for the vast number of
forwards we would end up having in the system, and the amount of work it
would take to walk though the forward subscriptions.
This patch modifies Stasis so that rather than walking the tree of
forwards on every dispatch, when forwards and subscriptions are changed,
the subscriber list for every topic in the tree is changed.
This has a couple of benefits. First, this reduces the workload of
dispatching messages. It also reduces contention when dispatching to
different topics that happen to forward to the same aggregation topic
(as happens with all of the channel, bridge and endpoint topics).
Since forwards are no longer subscriptions, the bulk of this patch is
simply changing stasis_subscription objects to stasis_forward objects
(which, admittedly, I should have done in the first place.)
Since this required me to yet again put in a growing array, I finally
abstracted that out into a set of ast_vector macros in
asterisk/vector.h.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a large performance price currently in the CDR engine. We currently
perform two ao2_callback calls on a container that has an entry for every
channel in the system. This is done to create matching pairs between channels
in a bridge.
As such, the portion of the CDR logic that this patch deals with is how we
make pairings when a channel enters a mixing bridge. In general, when a
channel enters such a bridge, we need to do two things:
(1) Figure out if anyone in the bridge can be this channel's Party B.
(2) Make pairings with every other channel in the bridge that is not already
our Party B.
This is a two step process. In the first step, we look through everyone in the
bridge and see if they can be our Party B (single_state_process_bridge_enter).
If they can - yay! We mark our CDR as having gotten a Party B. If not, we keep
searching. If we don't find one, we wait until someone joins who can be our
Party B.
Step 2 is where we changed the logic
(handle_bridge_pairings and bridge_candidate_process). Previously, we would
first find candidates - those channels in the bridge with us - from the
active_cdrs_by_channel container. Because a channel could be a candidate if it
was Party B to an item in the container, the code implemented multiple
ao2_container callbacks to get all the candidates. We also had to store them
in another container with some other meta information. This was rather complex
and costly, particularly if you have 300 Local channels (600 channels!) going
at once.
Luckily, none of it is needed: when a channel enters a bridge (which is when
we're figuring all this stuff out), the bridge snapshot tells us the unique
IDs of everyone already in the bridge. All we need to do is:
For all channels in the bridge:
If the channel is us or our Party B that we got in step 1, skip it
Compare us and the candidate to figure out who is Party A (based on some
specific rules)
If we are Party A:
Make a new CDR for us, append it to our chain, and set the candidate as
Party B
If they are Party A:
If they don't have a Party B:
Make a new CDR for them, append us to their chain, and us as Party B
Otherwise:
Copy us over as Party B on their existing CDR.
This patch does that.
Because we now use channel unique IDs to find the candidates during bridging,
active_cdrs_by_channel now looks up things using uniqueid instead of channel
name. This makes the more complex code simpler; it does, however, have the
drawback that dialplan applications and functions will be slightly slower as
they have to iterate through the container looking for the CDR by name.
That's a small price to pay however as the bridging code will be called a lot
more often.
This patch also does two other minor changes:
(1) It reduces the container size of the channels in a bridge snapshot to 1.
In order to be predictable for multi-party bridges, the order of the
channels in the container must be stable; that is, it must always devolve
to a linked list.
(2) CDRs and the multi-party test was updated to show the relationship between
two dialed channels. You still want to know if they talked - previously,
dialed channels were always ignored, which is wrong when they have
managed to get a Party B.
(closes issue ASTERISK-22488)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2861/
........
Merged revisions 399666 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399667 65c4cc65-6c06-0410-ace0-fbb531ad65f3
You cannot use a function pointer variable with an external function from
another dynamically loaded module because data variables are always
resolved even with RTLD_LAZY.
* Added wrapper functions for ast_ari_validate_int() and
ast_ari_validate_string() to use instead for the function pointer
variable.
(closes issue ASTERISK-22457)
Reported by: David M. Lee
........
Merged revisions 399207 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.
* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.
* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.
* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.
* Made all callers of ast_bridge_impart() check the return value. It is
important. As a precaution, I also made the compiler complain now if it
is not checked.
* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.
An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.
(closes issue ASTERISK-22072)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2845/
........
Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel joins a multi-party bridge, the ordering of the CDRs that is
created is determined by the ordering of the channels who happen to be in that
bridge. When r398579 changed the number of buckets in the container to
something sensible, it changed the ordering that the CDRs was created in,
causing one of the multiparty tests to fail. This fixes the test with the
now expected ordering.
........
Merged revisions 398628 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the review for buckets was completed (r2715), the handling of names in
the bucket core was deferred to the wizards. As such, the bucket unit tests
cannot expect that passing a URI with a scheme specified but no actual resource
name will automatically fail. The tests have been updated to not make this
check.
........
Merged revisions 397630 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The config options test requires the entire configuration item to be transparent from
the documentation system. So we let it do that too.
As an aside, please do not use this power for evil. Documentation is your friend, and
you really should document your configurations. Hiding your module's configuration
information from the system attempting to enforce some sanity in the universe is something
only a Bond villain would contemplate.
........
Merged revisions 397628 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When strict XML documentation checking was re-enabled, the test objects used in
sorcery would fail to register as the types were not marked internal and the
nodoc option wasn't used for the options. This fixes that problem, such that,
as one would hope, they once again pass.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397571 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This modifies the behavior of the CEL engine to conform to documented
behavior for Asterisk 12 as defined on the wiki
https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CEL+Specification
The primary changes deal with removal of the peer field from function
calls since it is no longer directly relevant to the bridging system
and removal of the layer of CDR-like business logic that was providing
a partial emulation of Asterisk 11 CEL functionality. With this change,
there is no longer a distinction between "bridges" and "conferences"
and all participation changes are denoted with bridge enter and bridge
exit messages.
This updates the CEL unit tests to handle these changes and simplifies
some of the macros used in the process.
This also fixes a segfault when attempting to ref a configuration that
failed to load.
Review: https://reviewboard.asterisk.org/r/2788/
(issue ASTERISK-21567)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.
Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change r395954 reordered some stasis object destruction, which should
have been fine. Unfortunately, it caused some hard to reproduce issues
related to objects being accessed after they had been destroyed. The
patch in r396329 fixed the destruction order problem; this patch
addresses the underlying issue. A few other stasis-related fixes were
also added.
* Add ref-bumps around areas where objects may get transitively
destroyed. (For example, where we lock a topic, unref a subscription,
which unrefs the topic, which explodes the topic when we try to
unlock it.)
* Wrote an extensive doxygen page about Stasis implementation,
relationships between objects, lifecycles of objects, how the
refcounting works, etc. Many other comments were added, corrected, or
cleaned up.
* Added an assert to the topic dtor to catch extra ref decrements.
* Fixed type used after destruction errors for graceful shutdown in
stasis_channels.c.
* I added two unit tests in an attempt to catch destruction order
issues. Since the underlying cause is a race condition, though, the
tests rarely failed even when the code was wrong.
* Fixed a leak in stasis_cache_pattern.c.
(closes issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2746/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Depending on certain conditions it was possible for the hashtab counting thread
to starve other threads, preventing them from executing in the expected fashion.
This change adds a sleep to allow the others to do what they need to do. While
this doesn't thrash the hashtab as much as previously, it at least works.
(closes issue ASTERISK-22276)
Reported by: Matt Jordan
........
Merged revisions 396619 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 396620 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The debug logs added in r396528 neglected to account for suseconds_t
being an int.
See r392076 for more info.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Disabling DEBUG_THREADS caused this test to fail on the 32-bit build agent.
Adding some debugging to see why it thinks the test is timing out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Stasis changes in r395954 had an unanticipated side effect: messages
published directly to an _all topic does not get forwarded to the
corresponding caching topic.
This patch fixes that by changing how caching topics forward messages,
and how the caching pattern forwards are setup.
For the caching pattern, the all_topic is forwarded to the
all_topic_cached. This forwards messages published directly to the
all_topic to all_topic_cached.
In order to avoid duplicate messages on all_topic_cached, caching topics
were changed to no longer forward uncached messages. Subscribers to an
individual caching topic should only expect to receive cache updates,
and subscription change messages. Since individual caching topics are
new, this shouldn't be a problem.
There are a few minor changes to the pre-cache split behavior.
* For topics changed to use the caching pattern, the all_topic_cached
will forward snapshots in addition to cache updates. Since
subscribers by design ignore unexpected messages, this should be
fine.
* Caching topics that don't use the caching pattern no longer forward
non-cache updates. This makes no difference for the current caching
topics.
* mwi_topic_cached, channel_by_name_topic and
presence_state_topic_cached have no subscribers
* device_state_topic_cached's only subscriber only processes cache
udpates
(issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2738
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Improve reliability of attended transfer merge and link tests.
Stop using ast_log(LOG_ERROR, ...); in favor of ast_test_status_update
Remove fred and eve channel helpers since they are not necessary
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395653 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This renames all files and API calls from several variants of
Stasis-HTTP to ARI including:
* Stasis-HTTP -> ARI
* STASIS_HTTP -> ARI
* stasis_http -> ari (ast_ari for global symbols, file names as well)
* stasis http -> ARI
Review: https://reviewboard.asterisk.org/r/2706/
(closes issue ASTERISK-22136)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The stasis_cache_update messages are somewhat cumbersome to handle
with the stasis_message_router. Since all updates have the same
message type, they are normally handled with the same route.
Since caching itself is a first class component of stasis-core, it
makes sense for the router to handle the cache update messages itself.
This patch adds stasis_message_router_add_cache_update() and
stasis_message_router_remove_cache_update() to handle the routing of
stasis_cache_update messages.
This patch also corrects an issue with manager_{bridging,channels}.c,
where events might be reordered. The reordering occurs because the
components use different message routers, which they needed because
they both needed to route cache update messages. They now both use
manager's router, and add cache routes for just the cache updates they
are interested in.
(closes issue ASTERISK-22038)
Review: https://reviewboard.asterisk.org/r/2677/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a new CEL event type, AST_CEL_LOCAL_OPTIMIZE, to represent
local channel optimizations. Local channel optimizations were one of
several things conveyed by the now defunct BRIDGE_UPDATE event type.
This also adds a unit test to test generation of this new CEL event.
Review: https://reviewboard.asterisk.org/r/2676/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds CEL support for blind and attended transfers and call pickup.
During the course of adding this functionality I noticed that
CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly
useless without a bridge identifier, so I added that as well.
This adds tests for blind transfers, several types of attended
transfers, and call pickup.
The extra field in CEL records now consists of a JSON blob whose fields
are defined on a per-event basis.
Review: https://reviewboard.asterisk.org/r/2658/
(closes issue ASTERISK-21565)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since ast_hangup() is effectively a channel destructor, it should be a
void function.
* Make the few silly callers checking the return value no longer do so.
Only the CDR and CEL unit tests checked the return value.
* Make all callers take advantage of the NULL safe change and remove the
NULL check before the call.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The JSON test attempted an overly clever use of RAII_VAR to run code
at the beginning and end of each test, in order to validate that no
JSON objects were leaked during the test.
The problem is that the validation code would run during the initial
load, when the tests were initialized. This happens during startup,
when other parts of the system might actively be allocating and
freeing JSON objects.
This patch changes the RAII_VAR to use the new
ast_test_register_{init,cleanup} functions to run the validations
properly.
(closes issue ASTERISK-21978)
Review: https://reviewboard.asterisk.org/r/2669/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When I corrected the CEL test crash in r394037, I didn't quite pay attention
to how the globals and locals were being shuffled around in the cleanup
callback. I removed the nulling of the global variables, which caused them
to be double cleaned.
This patch puts the global nulling code back (since the vars are cleaned up
by RAII_VARs), and removes the explicit ao2_cleanup() (since they were no-ops,
because the variables had just been nulled).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The voicemail_api test had code like strncmp(a, b, sizeof(a)), but a was a
char pointer, instead of a literal or char array. This meant that sizeof was
the size of the pointer, not the length of the string.
Since the string is in a stringfield and should be null terminated, I just
changed it to a plain strcmp.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the first step in adding recording support to the
Asterisk REST Interface.
Recordings are stored in /var/spool/recording. Since recordings may be
destructive (overwriting existing files), the API rejects attempts to
escape the recording directory (avoiding issues if someone attempts to
record to ../../lib/sounds/greeting, for example).
(closes issue ASTERISK-21594)
(closes issue ASTERISK-21581)
Review: https://reviewboard.asterisk.org/r/2612/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393550 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matt Jordan
Joshua Colp
Alexander Traud
Richard Mudgett
Corey Farrell
Kevin Harwell
George Joseph
Kinsey Moore
Mark Michelson
Scott Griepentrog
Jonathan Rose
David M. Lee