summaryrefslogtreecommitdiff
path: root/res/res_xmpp.c
AgeCommit message (Collapse)Author
2017-12-15aco: Minimize use of regex.Corey Farrell
Remove nearly all use of regex from ACO users. Still remaining: * app_confbridge has a legitamate use of option name regex. * ast_sorcery_object_fields_register is implemented with regex, all callers use simple prefix based regex. I haven't decided the best way to fix this in both 13/15 and master. Change-Id: Ib5ed478218d8a661ace4d2eaaea98b59a897974b
2017-11-06Fix ast_(v)asprintf() malloc failure usage conditions.Richard Mudgett
When (v)asprintf() fails, the state of the allocated buffer is undefined. The library had better not leave an allocated buffer as a result or no one will know to free it. The most likely way it can return failure is for an allocation failure. If the printf conversion fails then you actually have a threading problem which is much worse because another thread modified the parameter values. * Made __ast_asprintf()/__ast_vasprintf() set the returned buffer to NULL on failure. That is much more useful than either an uninitialized pointer or a pointer that has already been freed. Many uses won't have to check for failure to ensure that the buffer won't be double freed or prevent an attempt to free an uninitialized pointer. * stasis.c: Fixed memory leak in multi_object_blob_to_ami() allocated by ast_asprintf(). * ari/resource_bridges.c:ari_bridges_play_helper(): Remove assignment to the wrong thing which is now not needed even if assigning to the right thing. Change-Id: Ib5252fb8850ecf0f78ed0ee2ca0796bda7e91c23
2017-10-22res_xmpp: Ensure the connection filter is available.Joshua Colp
Users of the API that res_xmpp provides expect that a filter be available on the client at all times. When OAuth authentication support was added this requirement was not maintained. This change merely moves the OAuth authentication to after the filter is created, ensuring users of res_xmpp can add things to the filter as needed. ASTERISK-27346 Change-Id: I4ac474afe220e833288ff574e32e2b9a23394886
2017-08-22res_xmpp: fix inverted return code check in OAuthMichael Kuron
fetch_access_token calls func_curl via ast_func_read. The latter returns 0 upon success and -1 if the function is not available. This commit inverts the return code check so that an error is printed if the module is not loaded and not if it is loaded. ASTERISK-27207 #close Change-Id: I9ef903f80702d1218e8701f65a4e5e918e6548fb
2017-08-15res_xmpp: Google OAuth 2.0 protocol support for XMPP / MotifAndrey Egorov
Add ability to use tokens instead of passwords according to Google OAuth 2.0 protocol. ASTERISK-27169 Reported by: Andrey Egorov Tested by: Andrey Egorov Change-Id: I07f7052a502457ab55010a4d3686653b60f4c8db
2017-03-29Merge "res_xmpp: Fix ref counting issue"Joshua Colp
2017-03-24res_xmpp: Use incremental backoff when a read error occursSean Bright
If a read error occurs, we immediately attempt a reconnect without any delay. Instead, let's sleep and backoff up to 60 seconds before we try again. ASTERISK-24712 #close Reported by: Matthias Urlichs Change-Id: I6fe10ef4734837727437beab715e336777f13f48
2017-03-24Merge "res_xmpp: Correct implementation of JABBER_STATUS & JabberStatus"zuul
2017-03-24Merge "res_xmpp: Include client name in connection related error messages"zuul
2017-03-24Merge "res_xmpp: Don't crash when trying to send a message without a connection"Joshua Colp
2017-03-24Merge "res_xmpp: Correctly check return value of SSL_connect"zuul
2017-03-23res_xmpp: Correct implementation of JABBER_STATUS & JabberStatusSean Bright
The documentation for JABBER_STATUS (and the deprecated JabberStatus app) indicate that a return value of 7 indicates that the specified buddy was not in the roster. It also indicates that you can specify a "bare" JID (one without a resource). Unfortunately the actual behavior does not match the documented behavior. Assuming that our roster includes the buddy online and available "valid@example.org/Valid" and does *not* include the buddy "invalid@example.org", the JABBER_STATUS() function returns the following before this patch: +------------------------------+------------+--------------------------+ | Buddy | Status | Result | +------------------------------+------------+--------------------------+ | valid@example.org | Online | 7 (Not in roster) | | valid@example.org/Valid | Online | 1 (Online) | | valid@example.org/Invalid | N/A | 7 (Not in roster) | | invalid@example.org | N/A | Error logged, no return | | invalid@example.org/Valid | N/A | Error logged, no return | +------------------------------+------------+--------------------------+ And after this patch: +------------------------------+------------+--------------------------+ | Buddy | Status | Result | +------------------------------+------------+--------------------------+ | valid@example.org | Online | 1 (Online) | | valid@example.org/Valid | Online | 1 (Online) | | valid@example.org/Invalid | N/A | 6 (Offline) | | invalid@example.org | N/A | 7 (Not in roster) | | invalid@example.org/Valid | N/A | 7 (Not in roster) | +------------------------------+------------+--------------------------+ This brings the behavior in line with the documentation. ASTERISK-23510 #close Reported by: Anthony Critelli Change-Id: I9c3241035363ef4a6bdc21fabfd8ffcd9ec657bf
2017-03-23res_xmpp: Try to provide useful errors messages from OpenSSLSean Bright
If any errors occur during the TLS connection setup, we currently dump a fairly generic error message. So instead we try to pull in something useful from OpenSSL to report instead. ASTERISK-24712 Reported by: Matthias Urlichs Change-Id: I288500991a9681f447d92913b11fedaf426087f4
2017-03-23res_xmpp: Fix ref counting issueSean Bright
The only remaining reference to the endpoint is in the endpoints container, and because it is unlinked in ast_endpoint_shutdown, we don't have to explicitly cleanup the endpoint ourselves. Change-Id: I912a2692e52d3e2ed445b32d8ae3f9004bc2f2e8
2017-03-23res_xmpp: Correctly check return value of SSL_connectSean Bright
SSL_connect returns non-zero for both success and some error conditions so simply negating is inadequate. Change-Id: Ifbf882896e598703b6c615407fa456d3199f95b1
2017-03-23res_xmpp: Don't crash when trying to send a message without a connectionSean Bright
If we never establish a connection to our Jabber server, iksemel never sets up its internal transport pointer, so attempting to send a message dereferences a NULL pointer and causes a crash. ASTERISK-21855 #close Reported by: Jeremy Kister Change-Id: I204a568894e4a53ab929783ecc594a000f04d79c
2017-03-23res_xmpp: Include client name in connection related error messagesSean Bright
ASTERISK-25622 #close Reported by: Sean Darcy Change-Id: I8472cb7bfb58d411a3cfbd482da98cae2d94d1e9
2016-10-27Remove ASTERISK_REGISTER_FILE.Corey Farrell
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes all traces of it. Previously exported symbols removed: * __ast_register_file * __ast_unregister_file * ast_complete_source_filename This also removes the mtx_prof static variable that was declared when MTX_PROFILE was enabled. This variable was only used in lock.c so it is now initialized in that file only. ASTERISK-26480 #close Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
2016-08-16Refactor usage pattern of xmldoc info tag.Corey Farrell
This updates func_channel.c and main/message.c to use a generic xpointer include instead of including info from each channel driver. Now the name attribute of info is CHANNEL or CHANNEL_EXAMPLES to be included in documentation for func_channel. Setting the name attribute of info to MessageToInfo or MessageFromInfo causes it to be included in the MessageSend application and AMI action. Change-Id: I89fd8276a3250824241a618009714267d3a8d1ea
2016-08-15core: Entity ID is not set or invalidAlexei Gradinari
The Exchanging Device and Mailbox States could not working if the Entity ID (EID) is not set manually and can't be obtained from ethernet interface. This patch replaces debug message to warning and addes missing description about option 'entityid' to asterisk.conf.sample. With this patch the asterisk also: (1) decline loading the modules which won't work without EID: res_corosync and res_pjsip_publish_asterisk. (2) warn if EID is empty on loading next modules: pbx_dundi, res_xmpp Starting with v197 systemd/udev will automatically assign "predictable" names for all local Ethernet interfaces. This patch also addes some new ethernet prefixes "eno" and "ens". ASTERISK-26164 #close Change-Id: I72d712f1ad5b6f64571bb179c5cb12461e7c58c6
2016-02-02res_xmpp: Does not connect in component modeKarsten Wemheuer
The module res_xmpp does not accept usernames in the form used in component mode (XEP-0114). In component mode there is no @something in the name. In component mode the connection is now not dropped anymore. If the xmpp server sends out a "stream" tag before handshake is finished, the connection gets dropped in res_xmpp. Now this tag will be ignored and the connection will be established. After connecting there will be an exchange of presence states. This does not work as expected in component mode. The responsible function "xmpp_pak_presence" is left before the states get sent out. Sending presence states in component mode is now moved to the top of the function. ASTERISK-25735 #close Change-Id: I70e036f931c3124ebb2ad1e56f93ed35cfdd9d5c
2015-05-22Stasis: Fix unsafe use of stasis_unsubscribe in modules.Corey Farrell
Many uses of stasis_unsubscribe in modules can be reached through unload. These have been switched to stasis_unsubscribe_and_join. Some subscription callbacks do nothing, for these I've created a noop callback function in stasis.c. This is used by some modules that monitor MWI topics in order to enable cache, since the callback does not become invalid after dlclose it is safe to use stasis_unsubscribe on these, even during module unload. ASTERISK-25121 #close Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c
2015-05-13AST_MODULE_INFO: Format corrections to the usages of AST_MODULE_INFO macro.Rodrigo Ramírez Norambuena
Change-Id: Icf88f9f861c6b2a16e5f626ff25795218a6f2723
2015-04-13git migration: Refactor the ASTERISK_FILE_VERSION macroMatt Jordan
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
2015-03-25res_xmpp: Buddies are always auto-registered when processing the rosterMatthew Jordan
Due to a quirk in the configuration handling of res_xmpp, the 'autoregister' setting was never actually processed. This was due to not properly copying over the global settings to the client settings when applying the configuration to the run-time object. Review: https://reviewboard.asterisk.org/r/4496/ ASTERISK-14233 ASTERISK-24780 #close Reported by: Simon Arlott patches: asterisk-13.1.0-24780 uploaded by Simon Arlott (License 5756) ........ Merged revisions 433395 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 433396 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-01main/stasis: Allow subscriptions to use a threadpool for message deliveryMatthew Jordan
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
2014-10-20AST-2014-011: Fix POODLE security issuesMatthew Jordan
There are two aspects to the vulnerability: (1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the TCP/TLS core, which should be done as an improvement at a latter date. (2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified, will default to the OpenSSL SSLv23_method. This method allows for all ecnryption methods, including SSLv2/SSLv3. A MITM can exploit this by forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE. This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration, and explicitly disables SSLv2/SSLv3 if using SSLv23_method. For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or SSLv3. Much thanks to abelbeck for reporting the vulnerability and providing a patch for the res_jabber/res_xmpp modules. Review: https://reviewboard.asterisk.org/r/4096/ ASTERISK-24425 #close Reported by: abelbeck Tested by: abelbeck, opsmonitor, gtjoseph patches: asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903) asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903) AST-2014-011-1.8.diff uploaded by mjordan (License 6283) AST-2014-011-11.diff uploaded by mjordan (License 6283) ........ Merged revisions 425987 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 425991 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05Multiple revisions 420089-420090,420097Matthew Jordan
........ 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
2014-07-25Add module support level to ast_module_info structure. Print it in CLI ↵Mark Michelson
"module show" . ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22ARI: Fix endpoint/channel subscription issues; allow for subscriptions to techMatthew Jordan
This patch serves two purposes: (1) It fixes some bugs with endpoint subscriptions not reporting all of the channel events (2) It serves as the preliminary work needed for ASTERISK-23692, which allows for sending/receiving arbitrary out of call text messages through ARI in a technology agnostic fashion. The messaging functionality described on ASTERISK-23692 requires two things: (1) The ability to send/receive messages associated with an endpoint. This is relatively straight forwards with the endpoint core in Asterisk now. (2) The ability to send/receive messages associated with a technology and an arbitrary technology defined URI. This is less straight forward, as endpoints are formed from a tech + resource pair. We don't have a mechanism to note that a technology that *may* have endpoints exists. This patch provides such a mechanism, and fixes a few bugs along the way. The first major bug this patch fixes is the forwarding of channel messages to their respective endpoints. Prior to this patch, there were two problems: (1) Channel caching messages weren't forwarded. Thus, the endpoints missed most of the interesting bits (such as channel creation, destruction, state changes, etc.) (2) Channels weren't associated with their endpoint until after creation. This resulted in endpoints missing the channel creation message, which limited the usefulness of the subscription in the first place (a major use case being 'tell me when this endpoint has a channel'). Unfortunately, this meant another parameter to ast_channel_alloc. Since not all channel technologies support an ast_endpoint, this patch makes such a call optional and opts for a new function, ast_channel_alloc_with_endpoint. When endpoints are created, they will implicitly create a technology endpoint for their technology (if one does not already exist). A technology endpoint is special in that it has no state, cannot have channels created for it, cannot be created explicitly, and cannot be destroyed except on shutdown. It does, however, have all messages from other endpoints in its technology forwarded to it. Combined with the bug fixes, we now have Stasis messages being properly forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar), where bar has a single channel associated with it and foo has two channels associated with it. The messages would be forwarded as follows: channel PJSIP/foo-1 -- \ --> endpoint PJSIP/foo -- / \ channel PJSIP/foo-2 -- \ ---- > endpoint PJSIP / channel PJSIP/bar-1 -----> endpoint PJSIP/bar -- ARI, through the applications resource, can: - subscribe to endpoint:PJSIP/foo and get notifications for channels PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo - subscribe to endpoint:PJSIP/bar and get notifications for channels PJSIP/bar-1 and endpoint PJSIP/bar - subscribe to endpoint:PJSIP and get notifications for channels PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar Note that since endpoint PJSIP never changes, it never has events itself. It merely provides an aggregation point for all other endpoints in its technology (which in turn aggregate all channel messages associated with that endpoint). This patch also adds endpoints to res_xmpp and chan_motif, because the actual messaging work will need it (messaging without XMPP is just sad). Review: https://reviewboard.asterisk.org/r/3760/ ASTERISK-23692 ........ Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-05-09Allow Asterisk to compile under GCC 4.10Kinsey Moore
This resolves a large number of compiler warnings from GCC 4.10 which cause the build to fail under dev mode. The vast majority are signed/unsigned mismatches in printf-style format strings. ........ Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 413587 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-27Fix dialplan function NULL channel safety issuesCorey Farrell
(closes issue ASTERISK-23391) Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/3386/ ........ Merged revisions 411313 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 411314 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 411315 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411328 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-19Voicemail: Remove mailbox identifier format (box@context) assumptions in the ↵Richard Mudgett
system. This change is in preparation for external MWI support. Removed code from the system for normal mailbox handling that appends @default to the mailbox identifier if it does not have a context. The only exception is the legacy hasvoicemail users.conf option. The legacy option will only work for app_voicemail mailboxes. The system cannot make any assumptions about the format of the mailbox identifer used by app_voicemail. chan_sip and chan_dahdi/sig_pri had the most changes because they both tried to interpret the mailbox identifier. chan_sip just stored and compared the two components. chan_dahdi actually used the box information. The ISDN MWI support configuration options had to be reworked because chan_dahdi was parsing the box@context format to get the box number. As a result the mwi_vm_boxes chan_dahdi.conf option was added and is documented in the chan_dahdi.conf.sample file. Review: https://reviewboard.asterisk.org/r/3072/ ........ Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-17Reduce log level of a non-pubsub error messageKinsey Moore
Drop an error log message to debug level 1 since distributed device state functions correctly when receiving this message and it spams the logs. (closes issue ASTERISK-22410) Reported by: abelbeck Patches: asterisk-1.8-res_jabber-log-nonpubsub-error-to-debug.patch uploaded by abelbeck (License 5903) asterisk-11-res_xmpp-log-nonpubsub-error-to-debug.patch uploaded by abelbeck (License 5903) ........ Merged revisions 401119 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 401120 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 401121 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30Multiple revisions 399887,400138,400178,400180-400181David M. Lee
........ 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
2013-09-07Prevent XMPP timeout on blank responsesKinsey Moore
Sometimes the Google Voice servers have a bad habit of sending out 1 byte replies to the xmpp resource. When a blank 1 byte reply is received from the socket the buffer attempts to wait (endlessly) for the rest of the reply from google which effectively blocks the socket and google voice calls will no longer come into the server. This patch allows the xmpp module to correctly detect empty packets and send out ping replies to google. It also sets a socket timeout on the default socket which prevents the xmpp socket from closing and preventing future google voice calls from coming into the server. Furthermore instead of sending an empty reply back to google we send a proper xmpp ping reply back. This also adds several more socket messages. (closes issue ASTERISK-22347) Reported by: Andrew Nagy Review: https://reviewboard.asterisk.org/r/2771 Patches: xmpp_fix_1.diff uploaded by Andrew Nagy (License #6524) ........ Merged revisions 398618 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 398619 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-06Multiple revisions 398558,398577Kinsey Moore
........ r398558 | kmoore | 2013-09-06 14:28:16 -0500 (Fri, 06 Sep 2013) | 17 lines Fix Jabber/XMPP distributed MWI The mailbox and context are swapped on the receiving end for all users of Jabber and XMPP distributed MWI in Asterisk 1.8 and all more recent versions. This swaps those values to be correct when publishing to the internal event system from Jabber/XMPP distributed MWI state. (closes issue ASTERISK-22435) Reported by: abelbeck Tested by: Michael Keuter Patches: asterisk-1.8-res_jabber-aji_handle_pubsub_event.patch uploaded by abelbeck asterisk-11-res_xmpp-xmpp_pubsub_handle_event.patch uploaded by abelbeck ........ Merged revisions 398523 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ r398577 | kmoore | 2013-09-06 16:00:56 -0500 (Fri, 06 Sep 2013) | 10 lines Commit the remainder of r398523 This is a missing part of the commit in revision 398523 that corrects the name of a variable. (issue ASTERISK-22435) ........ Merged revisions 398576 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 398558,398577 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 398580 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-17Strip down the old event systemKinsey Moore
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
2013-08-01Split caching out from the stasis_caching_topic.David M. Lee
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
2013-05-24Migrate a large number of AMI events over to Stasis-CoreMatthew Jordan
This patch moves a number of AMI events over to the Stasis-Core message bus. This includes: * ChanSpyStart/Stop * MonitorStart/Stop * MusicOnHoldStart/Stop * FullyBooted/Reload * All Voicemail/MWI related events In addition, it adds some Stasis-Core and AMI support for generic AMI messages, refactors the message router in AMI to use a single router with topic forwarding for the topics that AMI cares about, and refactors MWI message types and topics to be more name compliant. Review: https://reviewboard.asterisk.org/r/2532 (closes issue ASTERISK-21462) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389733 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-16res_xmpp and res_jabber need to search 'cachable' in the attrib section of ↵Alec L Davis
the received IE, not data. (issue ASTERISK-20175) (closes issue ASTERISK-21429) (closes issue ASTERISK-21069) (closes issue ASTERISK-21164) Reported by: alecdavis Tested by: alecdavis alecdavis (license 585) Review https://reviewboard.asterisk.org/r/2452/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-16Move device state distribution to Stasis-coreKinsey Moore
In the move from Asterisk's event system to Stasis, this makes distributed device state aggregation always-on, removes unnecessary task processors where possible, and collapses aggregate and non-aggregate states into a single cache for ease of retrieval. This also removes an intermediary step in device state aggregation. Review: https://reviewboard.asterisk.org/r/2389/ (closes issue ASTERISK-21101) Patch-by: Kinsey Moore <kmoore@digium.com> git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-03-27Convert MWI state message type to the new stasis naming conventionKinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-03-16Transition MWI to Stasis-coreKinsey Moore
Remove MWI's dependency on the event system by moving it to Stasis-core. This also introduces forwarding topic pools in Stasis-core which aggregate many dynamically allocated topics into a single primary topic. Review: https://reviewboard.asterisk.org/r/2368/ (closes issue ASTERISK-21097) Patch-by: Kinsey Moore git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-03-16Add support for using XMPP buddy state via device state.Joshua Colp
This change allows you to use XMPP buddy state in places where device state can be used be used, such as dialplan hints. If at least one resource is available the buddy is considered available. Now your phone can reflect their IM status too! git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383283 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-03-16Fix a bug where resources were not found due to hashing on the priority itself.Joshua Colp
........ Merged revisions 383266 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-03-12Fix a crash when res_xmpp is configured using a username without a domain.Joshua Colp
(closes issue ASTERISK-21156) Reported by: amsoft2001 ........ Merged revisions 382923 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-02-15Add CLI configuration documentationMatthew Jordan
This patch allows a module to define its configuration in XML in source, such that it can be parsed by the XML documentation engine. Documentation is generated in a two-pass approach: 1. The documentation is first generated from the XML pulled from the source 2. The documentation is then enhanced by the registration of configuration options that use the configuration framework This patch include configuration documentation for the following modules: * chan_motif * res_xmpp * app_confbridge * app_skel * udptl Two new CLI commands have been added: * config show help - show configuration help by module, category, and item * xmldoc dump - dump the in-memory representation of the XML documentation to a new XML file. Review: https://reviewboard.asterisk.org/r/2278 Review: https://reviewboard.asterisk.org/r/2058 patches: on review 2058 uploaded by twilson git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-02-11Fix crash in res_xmpp when deleting pubsub node from CLIMatthew Jordan
An error existed in res_xmpp where it would attempt to delete attributes from a node that itself was also deleted. Per the iksemel documentation, attributes added using iks_insert are copied to the parent node's stack, and will be reclaimed when that node is itself destroyed. (closes issue ASTERISK-20982) Reported by: marcelloceschia patches: delete-node-fix.diff uploaded by marcelloceschia (License 6036) ........ Merged revisions 381159 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-01-16Let documentation reference links specify which module they're linking toMatthew Jordan
Again, since res_jabber/res_xmpp have duplicate APIs, their documentation ref links have to specify which reference they're referring to. The various documentation parsers can interpret the module attribute however they want in order to construct the appropriate links. ........ Merged revisions 379228 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379229 65c4cc65-6c06-0410-ace0-fbb531ad65f3