Issue with welcome prompt on conference

[Ivan Tazelaar]

Dear Kazoo Team,

Good afternoon or evening! Any chance someone can lend me a hand?

I am having a strange issue with the conference action in callflows, for a very specific scenario.

I am trying to prevent the welcome_prompt from playing, so I created a callflow using monster, and then modified the callflow document flow attribute directly on the database as follows:

{
   "data": {
       "id": "5e526d64a90c856efb62048d58ffa29f",
       "moderator": false,
       "play_entry_tone": false,
       "play_exit_tone": false,
       "welcome_prompt": {
           "play": false
       }
   },
   "module": "conference",
   "children": {
   }
}

For some reason, this setting only works once (on my first attempt), but the "welcome to the conference" message gets played again on my second and subsequent call attempts.

I can make it stop playing (again, only once) by either waiting some seconds and trying again, or by flushing the callflows cache.

Could this be a cache issue? Maybe some odd logic not caching the welcome_prompt section or ignoring it if the object was recovered from cache?

Thanks much!

[mc_]

You could just use the callflows API directly to edit the callflow JSON instead of going to the document in the database. When you get a successful API response, all relevant caches will be flushed and things should just work. Why not try that route instead? You can see what the UI uses to POST the modified callflow to serve as a template.

[Ivan Tazelaar]

Hi mc_

Thanks for answering!

I know I should use the API, but it gives me headaches, I need to authenticate, etc, etc. Are there some tools I can use to simplify this? Calling it with curl from the terminal is very annoying and time-consuming.

BTW, all caches have been flushed, and remember the first callflow execution works just fine, and it doesn't play the welcome prompt at all, so it looks like it's reaching the right document, it's only on the second and consecutive call attempts that this issue shows, and only if I don't leave a few seconds between attempts.

Could it be something related with the copy that the conferences module does online to register the "opened" conference room? I know it does register the ID somewhere (and maybe some data?) because it uses that reference later to validate if the bridge is open (to allow callers to join if the room is active).

Thanks once more! Ivan

[mc_]

Regarding the API, it's all a matter of preference I guess. Joris posted about Postman that the UI team uses to whip up API calls quickly. I have scripts the authenticate and export relevant vars to my shell's env to speed up stuff. I know how painful it can be to track down what areas of Kazoo need intervention when DB changes occur.

Anyway, if you can get logs of the first and second attempts (where first succeeds and second doesn't), it may be instructive on what the differences are. Nothing comes to mind for why that observed behavior is happening.

[Ivan Tazelaar]

1 hour ago, mc_ said:

Regarding the API, it's all a matter of preference I guess. Joris posted about Postman that the UI team uses to whip up API calls quickly. I have scripts the authenticate and export relevant vars to my shell's env to speed up stuff. I know how painful it can be to track down what areas of Kazoo need intervention when DB changes occur.

Anyway, if you can get logs of the first and second attempts (where first succeeds and second doesn't), it may be instructive on what the differences are. Nothing comes to mind for why that observed behavior is happening.

Will the kazoo.log be enough? Shall I grep it somehow? Thanks!

[mc_]

Grep for the call-ids of the two calls (make sure kazoo is logging in debug).