endpoint.destroy() never returns if aws transcription is active

[lylepratt]

If you try to destroy an endpoint while an aws transcription is active, the destroy never succeeds and the call isn't torn down in FS.

Below is an example based on your aws transcription example.

async function doTts(dlg, ep) {
  try {
    await ep.play('silence_stream://1000');
    await ep.speak({
      ttsEngine: 'google_tts',
      voice: 'en-GB-Wavenet-A',
      text
    });
    var result = await ep.api('uuid_aws_transcribe', `${ep.uuid} start en-US interim`);  
    
    await delay(2000)    
    /*
    * without calling stop first, the below ep.destroy will never return
    * Comment it out to reproduce
    */
    console.log("stopping transcribe first")
    var result = await ep.api('uuid_aws_transcribe', `${ep.uuid} stop`);
    
    console.log("destroying main")
    await ep.destroy()
    
    // it won't ever get here if you don't stop the transcribe first
    console.log("destroyed main")
  }

  catch (err) {
    console.log(err, 'Error starting transcription');
  }
}

Here are the FS logs if you try to destroy an endpoint while transcription is still active:
failedDestroyLogs.txt

Here are the FS logs if you try to destroy an endpoint but stop transcription first (it works):
successDestroyLogs.txt

[byoungdale]

I think this will be an issue here in mod_aws_transcribe. I can get this recreated locally tonight, and see what I can find.

[lylepratt]

curious if you think this could be an issue with Google transcribe as well? Reason I ask is because we switched to aws transcribe after we started experiencing long delays before Google would return any transcription result. Seemed to happen more frequently after the server had been running a while, and I suspect its because there were tons of hung calls with transcribe still active on the FS box.

[davehorton]

I rather doubt it, because I use google all the time and would have seen this

[lylepratt]

Just verified. Same issue does not exist with google transcribe.

[byoungdale]

I was able to recreate this issue. I created an issue on the drachtio-freeswitch-module repo where I will work on a fix.

[lylepratt]

cool! let me know if there’s any way I can help you 🍻

[byoungdale]

My fix for this got added in v0.8.4 of drachtio-freeswitch-modules. Can you verify it works for you?

[lylepratt]

howdy! apologies for the slow response here. I'll give it a shot today.

[lylepratt]

hmm...not sure how I can test this in our setup. we use docker-drachtio-freeswitch-mrf in our dev and prod so until it gets in there I'm stuck.

[byoungdale]

Sorry for the late reply. If you build using drachtio/drachtio-freeswitch-base:latest in the docker-drachtio-freeswitch-mrf Dockerfile, it will have this fix. But, there isn't a new docker-drachtio-freeswitch-mrf version yet to use.

[davehorton]

I will look at building that today

[byoungdale]

@lylepratt, you should be able to use the latest docker-drachtio-freeswitch-mrf now.