mc_

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.

No, CDRs are read-only via API.

Because I linked it over there, here's a presentation from 2016 on pivot

@esoare I gave a presentation at KazooCon 2016. Any programming language that can receive an HTTP request and respond appropriately will work.

You can create directories that sort by first or last name. Assign the ID returned by Crossbar to the directory callflow action and it should sort accordingly

I think this is a great suggestion! I've been using Couch 2 (well, the master branch that I update every week or so) to good effect. We'll have to wait and see how operations feels about migrating existing installations from BigCouch to Couch 2. I think that's the main holdup at this point. Would love to hear experiences others have with migrations and with running Couch 2 vs BigCouch.

What about signing emails with PGP?

When the local cluster creates the MODb at the beginning of the month, no replication job will exist for it. You'll need to start one to replicate from the local cluster to your hosted cluster. Anyway, I'm sure there are dragons lurking in this setup so tread carefully, have lots of monitoring, etc.

I believe it allows you to retry the ring group if no one answers in the allotted timeout before progressing to the next callflow action. So if you set it to 2, it would ring the group, timeout, ring the group again, then continue the callflow.

I want to play with the idea of federated clusters more, to make this a more supported setup. In the meantime, I think the best you can do is setup HTTP replication in couch from their cluster to yours with the same account database. You'll have to go in each month to setup the MODB replication as well. There may be fancier ways to do it as well, but I haven't thought too hard about it.

I'm confused; bash auto-completion helps with exactly that. Consider: james@pdx:~/local/git/2600hz/kazoo/core/sup$ sup acdc_agent_maintenance doodle_maintenance kapps_config kazoo_modb_maintenance kazoo_voicemail_maintenance tasks_maintenance acdc_maintenance ecallmgr_config kapps_controller kazoo_modb_migrate_maintenance konami_maintenance teletype_maintenance blackhole_maintenance ecallmgr_maintenance kapps_maintenance kazoo_number_manager_maintenance media_mgr_maintenance trunkstore_maintenance callflow_maintenance fax_maintenance kazoo_amqp_maintenance kazoo_oauth_maintenance notify_maintenance webhooks_maintenance call_inspector_maintenance frontier_maintenance kazoo_auth_maintenance kazoo_perf_maintenance notify_resend_maintenance cb_apps_maintenance hangups_maintenance kazoo_data_maintenance kazoo_proper_maintenance omnipresence_maintenance conference_maintenance hotornot_maintenance kazoo_ips_maintenance kazoo_services_maintenance pusher_maintenance crossbar_bindings jonny5_maintenance kazoo_maintenance kazoo_speech_maintenance registrar_maintenance crossbar_maintenance kapps_account_config kazoo_media_maintenance kazoo_transactions_maintenance stepswitch_maintenance james@pdx:~/local/git/2600hz/kazoo/core/sup$ sup ecallmgr_ ecallmgr_config ecallmgr_maintenance james@pdx:~/local/git/2600hz/kazoo/core/sup$ sup ecallmgr_maintenance acl_summary channel_summary disable_authz flush_node_channels limit_channel_uptime registrar_sync show_channels add_fs_node check_sync disable_local_resource_authz flush_node_conferences list_fs_nodes reload_acls sync_channels allow_carrier conference_details enable_authz flush_registrar node_details remove_acl sync_conferences allow_sbc conference_summary enable_local_resource_authz flush_util node_summary remove_fs_node test_carrier_ip carrier_acls deny_carrier flush_acls get_fs_nodes registrar_details sbc_acls test_sbc_ip channel_details deny_sbc flush_authn hangup_long_running_channels registrar_summary show_calls james@pdx:~/local/git/2600hz/kazoo/core/sup$ sup ecallmgr_maintenance flush_ flush_acls flush_authn flush_node_channels flush_node_conferences flush_registrar flush_util I think the -h flag is preventing bash auto-completion for you.

Probably the best place to start is in the sysadmin docs while you get familiar with how Kazoo operates. Check out the CentOS 7 install guide and the quickstart API guide. If you find places in the docs that are unclear, click the edit link and submit a PR. The appendix is a pile of docs poorly migrated from the old wiki. There may still be some nuggets of wisdom that are worth cleaning up and moving to the main nav. Please use the forums to search for answers then pose questions if you don't find the help you need. The community is quite knowledge-able!