Application overwhelmed with ChannelVarSet events when extensions enter a bridge

I have an ARI application that gets overwhelmed with ChannelVarSet events as channels are added into a confbridge. Its so bad, that Asterisk is constantly throwing the warning: taskprocessor.c: the ‘stasis-core-control’ task processor queue reached 500 scheduled tasks.

Setup: Using StarTrinity to generate inbound calls for the testing.
50 extensions (250 ms apart) call into an stasis-application extension which answers, then the application adds the channel into a predefined conference bridge. By extension 30 or so that have called in, my application is receiving over 462 ChannelVarSet events in 1.1 secs.

I would have expected 1 or 2 ChannelVarSet events as each extension gets put into the confBridge, but I am receiving about 15 on the 1st extension being added to the confBridge, 30 for the second extension, 45 for the 3rd, and so on. It seems that there are ~15 ChannelVarSet events per extension sent for every extension added. Hence the large number. I am using tcpdump and filtering on the websocket port to determine these counts.

In the deployed system, we usually get 100+ extensions calling in within a couple of seconds time frame which just saturates the C# app, and Asterisk in generating these events.

My application doesn’t care about “type”: “ChannelVarset” events for any of the client events I have subscribed to.

Is there any way to disable/turn off the generation of “type”: “ChannelVarset” for any subscribed event? Either through asterisk or through the ARI interface?

Using Asterisk: 13.19.1

Thanks in advance,

Recent versions of Asterisk provide a filtering mechanism[1] that the application can use to filter out event types server side that it is not interested in.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.