Issues with TALK_DETECT and ARI

Asterisk Asterisk APIs
1

Hello,
I am trying to build an interruptible voice capturing system. My test scenario is as follows:

(using the node-ari package)

  1. Place channel into Stasis application
  2. Play a sound file
  3. Register events for ChannelTalkingStarted and ChannelTalkingFinished
  4. Once ChannelTalkingStarted fires, stop the playback of the sound file

This flow functions perfectly fine while running the stasis application directly on my laptop, connected to a remote asterisk server via websocket. I’ve bundled this up (mainly for testing uploading/transcribing the recorded file which lives on the asterisk server) and I ran into an issue where the sound file I’m playing would be stopped immediately.

I placed console logs in and I was indeed receiving the ChannelTalkingStarted event prior to saying anything – even if my iPhone microphone was on mute prior to the call connecting. I tried adjusting the silence threshold to 15000ms to see if something interesting was happening there, but I still encountered the problem.

Here is a code snippet demonstrating what I’m doing

let playbackId;
const playback = await channel.play({
  media: 'sound:zombies',
});

channel.on('ChannelTalkingStarted', () => {
  if (playbackId) {
    client.playbacks.stop({
      playbackId
    });
  }
});

Just as an experiment, I wrapped the setting of playbackId in a setTimeout:

let playbackId;
const playback = await channel.play({
  media: 'sound:zombies',
});

setTimeout(() => {
  playbackId = playback.id;
}, 5000);

channel.on('ChannelTalkingStarted', () => {
  if (playbackId) {
    client.playbacks.stop({
      playbackId
    });
  }
});

This did indeed resolve the issue I was seeing and the prompt would continue to play continuously until I actually said something.

I guess what I want to get out of this is if anyone knows why those events are firing immediately event when my microphone is muted.

I tried adjusting the silence/talking thresholds to various levels but nothing seemed to make a difference.

Thanks!

2

What version of Asterisk are you using? I vaguely recall there being fixes for talk detection.

3

We are using asterisk version 14.0.2

4

That version is quite old and not supported. It is entirely possible that using a current supported version the problem does not exist any longer.

5

Alright, I’ll give that a shot. It might fix my issue, but I’m not sure since the expected behavior is happening when I’m running my ARI application locally vs on the server next to asterisk. Could there be a timing issue? With the messaging being too quick when it is on the same server? Which is why my setTimeout made the issue go away?

6

That’s possible, but my knowledge of node.js usage is minimal.

7

Alright, we built a server out with 16.4 on it and I’m experiencing the same behavior

8

I put my setTimeout back in and put it at 250ms and the expected behavior occurs. So it definitely seems like a timing issue to me

9

I think this may be a bug in Asterisk. Here’s the code that sets “talking” (from func_talkdetect.c):

ast_dsp_silence(td_params->dsp, frame, &total_silence);

if (total_silence < td_params->dsp_silence_threshold) {
    if (!td_params->talking) {
		update_talking = 1;
		td_params->talking_start = ast_tvnow();
	}
	td_params->talking = 1;
}

I’m guessing total_silence here starts out at zero or some really low number. Either way it is most likely less than the dsp_silence_threshold value. If so then it would trigger talking every time at start.

Anyhow, I was able to replicate the problem as well when watching for AMI events. Please create a bug report on our issue tracker. Describe the problem, and feel free to add a link to your post here.

Thanks!

10

Thank you for that – I might tinker around with it and see if I can determine anything.

That definitely aligns with what I’ve been seeing. I’m 99.9999% positive the setTimeout resolves something just based on network latency of connecting locally vs routing back to my laptop.