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
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
This function allows code to run ao2_ref against the real
object associated with a weakproxy. It is useful when
all of the following conditions are true:
* You have a pointer to weakproxy.
* You do not have or need a pointer to the real object.
* You need to ensure the real object exists and is not
destroyed during a process.
In this case it's wasteful to store a pointer to the real
object just for the sake of releasing it later.
Change-Id: I38a319b83314de75be74207a8771aab269bcca46
The query set documentation states that upon completion queries can be
retrieved for the lifetime of the query set. This is a reasonable
expectation but does not currently occur. This was originally done
to resolve a circular reference between queries and query sets, but
in practice the query can be kept.
This change makes it so a query does not have a reference to the
query set until it begins resolving. It also makes it so that the
reference is given up upon the query being completed. This allows
the queries to remain for the lifetime of the query set. As the
query set on the query is only useful to the query set functionality
and only for the lifetime that the query is resolving this is safe
to do.
ASTERISK-24994 #close
Reported by: Joshua Colp
Change-Id: I54e09c0cb45475896654e7835394524e816d1aa0
This change adds the following:
1. A query set implementation. This is an API that allows queries to be executed in parallel and once all have completed a callback is invoked.
2. Unit tests for the query set implementation.
3. An external PJSIP resolver which uses the DNS core API to do NAPTR, SRV, AAAA, and A lookups.
For the resolver it will do NAPTR, SRV, and AAAA/A lookups in parallel. If NAPTR or SRV
are available it will then do more queries. And so on. Preference is NAPTR > SRV > AAAA/A,
with IPv6 preferred over IPv4. For transport it will prefer TLS > TCP > UDP if no explicit
transport has been provided. Configured transports on the system are taken into account to
eliminate resolved addresses which have no hope of completing.
ASTERISK-24947 #close
Reported by: Joshua Colp
Change-Id: I56cb03ce4f9d3d600776f36928e0b3e379b5d71e
This implements "weak" references. The weakproxy object is a real ao2 with
normal reference counting of its own. When a weakproxy is pointed to a normal
object they hold references to each other. The normal object is automatically
freed when a single reference remains (the weakproxy). The weakproxy also
supports subscriptions that will notify callbacks when it does not point
to any real object.
ASTERISK-24936 #close
Reported by: Corey Farrell
Change-Id: Ib9f73c02262488d314d9d9d62f58165b9ec43c67
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
The NAPTR and SRV branches were worked on independently and
resulted in some code being duplicated in each. Since both
have been merged into trunk now, this patch reduces the
duplication by factoring out common code into its own
source files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds support for parsing SRV records and consuming their values
in an easy fashion. It also adds automatic sorting of SRV records according
to RFC 2782.
Tests have also been included which cover parsing, sorting, and off-nominal
cases where the record is corrupted.
ASTERISK-24931 #close
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/4528/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an abstracted core DNS API which resembles the API described
here[1]. The API provides a pluggable mechanism for resolvers and also a
consistent view for records. Both synchronous and asynchronous queries are
supported.
This change also adds a res_resolver_unbound module which uses the libunbound
library to provide resolution.
Unit tests have also been written for all of the above to confirm the API and
functionality.
ASTERISK-24834 #close
Reported by: Matt Jordan
ASTERISK-24836 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4474/
Review: https://reviewboard.asterisk.org/r/4512/
[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+DNS+API
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
........
Merged revisions 433174 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433175 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/
........
Merged revisions 430315 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430316 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
........
Merged revisions 428892 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428893 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
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 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
........
Merged revisions 428544 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428545 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
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 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
........
Merged revisions 427276 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427277 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
........
Merged revisions 425384 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 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
........
Merged revisions 423783 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423784 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
........
Merged revisions 423478 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423480 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
........
Merged revisions 421538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421539 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
........
Merged revisions 421042 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421043 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
