Commit Graph

6 Commits

Author SHA1 Message Date
Mike Bradeen
6b03d60c7d res_monitor: Remove deprecated module.
ASTERISK-30303

Change-Id: I0462caefb4f9544e2e2baa23c498858310b52d50
2023-01-13 08:32:33 -06:00
Naveen Albert
68f1e5d508 ami: Add AMI event for Wink
Adds an AMI event for a wink frame.

ASTERISK-29830 #close

Change-Id: I83e426de5e37baed79a4dbcc91e9e8d030ef1b56
2022-01-05 11:31:42 -06:00
Naveen Albert
04454fc238 AMI: Add AMI event to expose hook flash events
Although Asterisk can receive and propogate flash events, it currently
provides no mechanism for doing anything with them itself.

This AMI event allows flash events to be processed by Asterisk.
Additionally, AST_CONTROL_FLASH is included in a switch statement
in channel.c to avoid throwing a warning when we shouldn't.

ASTERISK-29380

Change-Id: Ie17ffe65086e0282c88542e38eed6a461ec79e81
2021-05-19 08:40:05 -05:00
Sebastien Duthil
6e695c867f app_mixmonitor: Add AMI events MixMonitorStart, -Stop and -Mute.
ASTERISK-29244

Change-Id: I1862d58264c2c8b5d8983272cb29734b184d67c5
2021-02-23 11:40:56 -06:00
Matthew Jordan
1106e8fd0f main/stasis: Allow subscriptions to use a threadpool for message delivery
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-12-01 17:59:21 +00:00
Kinsey Moore
f1036f40dc Stasis: Allow message types to be blocked
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
2014-08-06 12:55:28 +00:00