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.