mc_

I think you have to "subscribe" to each forum. I think @Darren Schreiber was going to turn on auto-subscribe by default? Or maybe it only applies to new signups? Anyway, there should be a "Follow" or similar link for each forum room/group/whatever they're called

Also, is the voicemail box owned by a user? And does the user have a timezone set on the user doc?

Have you looked at using the 'date' filter instead? Perhaps try adding 'e' to the date_called args?

To add, your hostname in the URL is kzdev; can FreeSWITCH resolve that to the proper IP address of the kazoo_apps server?

You can test it out by setting "sip.custom_sip_headers.in.X-Geolocation" on the device doc. This will set the header on outbound calls from the device (Kazoo typically uses in[bound] to mean coming to Kazoo from the endpoint). But it doesn't address the room/floor question.

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

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.

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.

AFAIK no other callflow actions make use of it besides Pivot so it is effectively coupled though this won't always be the case. You can see a usage example here: https://docs.2600hz.com/dev/applications/pivot/doc/kazoo/collect/

@Marcin Muzylo You'd need to file a ticket in JIRA and either hope it gets scheduled or talk to an account rep (or sales) about getting/paying to get it scheduled. A PR with the implementation would always be accepted too

I think the endpoint callflow actions, like device, user, etc, should be extended to support custom_sip_headers in the "data" portion. Then when building the endpoints, the CSHs can be applied after the endpoints are built to any endpoints found. I don't think setting CSHs on the kapps_call record affects anything (at least not with a cursory browsing).

Can you put the custom SIP header on the resource document itself? Or create a clone resource for these "group" calls that has it set (and use flags to indicate whether to use the vanilla resource or the SIP-header-ed resource)?

Your request has gotten complex enough that I think you need to engage consulting services. Please contact sales@2600hz.com to further this request; it's beyond the scope of normal PBX / call center functionality at this point.

Sure, use the hangup callflow action or send a custom SIP response if you like. You can also use the 'webhook' callflow action to send a custom webhook to your server, which you can use to insert call information into your database.

For routing based on the dialed number, use the "patterns" instead of "numbers" array to match dialed numbers. Otherwise you can use the callflow action to route based on Caller ID

For outbound calls via FreeTDM, resources support setting the TDM flags necessary. Set the gateway (gateways.[].endpoint_type) type to freetdm, then set "span", "channel_selection", etc to configure the channel in FreeSWITCH. For numbers, you can add the number just like any other number; you'll want your resource to have an appropriate regex to be chosen to route the calls.

Correct. Kazoo will still try to read the voicemail, for instance, for playback during a call to check a voicemail box. Kazoo will not delete attachments, however, if the metadata is deleted. Where the attachment resides is transparent to the higher level apps like Crossbar - the low-level driver will fetch the attachment and hand it up to Crossbar, cf_voicemail, wherever it is needed.

Hi! First, I would at least upgrade to 3.22, the last stable version of the 3.x series. This should be straightforward enough, if you've been tracking releases thus far. Ideally you would upgrade to 4.1 which would make error reports like this much more valuable. As for the missing CHANNEL_DESTROY events, it's hard to say where things are getting lost without logs. If you can get debug logs of a call where the caller hangs up during cf_play but the callflow continues to record/acdc queue, it might be easier to see where things get out of sync. Again, I would recommend upgrading your Kazoo version and re-test unless you're prepared to patch your system yourself.

@Graham Nelson-Zutter I'll put this in my queue for tomorrow. Will let you know what I find and we can compare notes. Would obviously like to support AMI users as well! Guess I finally have to learn AWS stuff

@Graham Nelson-Zutter just to add, when I wrote the storage blog article, I just signed up for S3, got my access and secret tokens, plugged them in as in the article, and got uploads working. It's possible/probable that's not the typical way folks setup their S3 accounts (I have pretty much no knowledge of S3 or Amazon properties). So I can only say that the instructions presented in the blog worked for me for a minimalist setup on S3. Obviously it would be great to have more detailed instructions for other S3 setups and adjust the code accordingly (if necessary).

Ah, I see the issue. The 'offnet' callflow action is specifically for global carrier usage (and considered deprecated). It predates BYOC and local resource usage; it is kept for backwards compatibility only (and explicitly sets use_local_resources to false). Change 'offnet' to 'resources' in the callflow action and the local resource(s) should be used. https://docs.2600hz.com/dev/applications/callflow/doc/resources/

If you updated via API, caches are flushed automatically. If via the DB, you'll want to issue 'sup stepswitch_maintenance reload_resources' I think (something along those lines).

Logs! Specifically callflow's and stepswitch's - debug level.

Webhooks, HTTP requests per-event, are too heavy for the relatively rapid nature of qubicle events. Websockets is the more appropriate way to receive them. You can read about them here

I haven't tested in a while, but you should be able to set the "Accept" header to "Accept: text/csv" and get the API response as a CSV directly.