[Merging Accounts in Platform]

https://docs.2600hz.com/dev/applications/crossbar/doc/accounts/#move-an-account

Should get you what you want.

[Merging Accounts in Platform]

Do you mean put all devices/users/callflows/etc from one account into another? Or move the child account to have a new parent account?

[Ring Group with Remote number]

Is there a  reason not to use the "user" callflow and assign/unassign devices from there as appropriate? Then you can have children of the user callflow action that branch based on the SIP response.

{"module":"user"
 ,"data":{"id":"{USER_ID}"
 ,"children":{
    "sip:404":{
       "module":"resources"
       ,"data":{"to_did":"{FORWARD_NUMBER}"}
       ,"children":{"_":{"module":"voicemail",...}}
    }
    ,"sip:486":{...}
    ,"_":{
      "module":"voicemail"
      ,"data":{"id":"{VMBOX_ID}"
    }
 }
}

I think this would be more robust that managing a ring group (unless you have many users involved?).

[Receive updated on all psotes]

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

[Any good CDR analytics packages?]

@FASTDEVICE nothing at the moment. Those were just ideas I had that would fit nicely in the tasks framework. You would need to get in the ear of @Chris Kerber or @Darren Schreiber I think and see about getting something like this on the roadmap.

[Email Template Macro for Timezone]

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

[Email Template Macro for Timezone]

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

[Call recording per channel]

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

[ACDC Strategy options]

AFAIR there is no ring-all strategy.

[Advanced e911 - granular based on room or building]

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.

[Issue with welcome prompt on conference]

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

[Issue with welcome prompt on conference]

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.

[Issue with welcome prompt on conference]

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.

[Presenting kazoo-ansible (Ansible Roles for Kazoo)]

This looks really nice!

I would consider adding, either on the main README or in an INSTALL or similar file, copy/paste-able shell commands for each of the installation steps. What is intuitive and obvious to you may not be to others and having an example shell session will provide more feedback as people try setting this up for themselves. For instance, if I wanted to play with this, I would need to dig up how to add the user for SSH and sudo, running the Kazoo commands, etc.

If there are more hooks into Kazoo that would make life easier for setting this up, do let us know! Anything we can do to facilitate easier setup and maintenance, we'd like to know about.

Thanks again for this work and sharing it with the community.

 

[Collect DTMF Widget in Advanced Callflows]

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/

[call group with special sip headers]

@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

[call group with special sip headers]

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).

[call group with special sip headers]

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)?

[to fetch agent numbers from custom database and forwarding the call]

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.

[PSTN connectivity by kazoo freeswitch using freetdm]

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.

[PSTN connectivity by kazoo freeswitch using freetdm]

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

[PSTN connectivity by kazoo freeswitch using freetdm]

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.

[Request for experienced developer to set up Kazoo]

@Morpho9 You might check out 2600Hz's Global Infrastructure product. Then you get the team, the support, and the experience behind your platform! And you get to support the open source efforts as well.

[Call recording per channel]

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.

[Sometimes ecallmgr failed to get channel_destroy from FS, sometimes whistle_app failed to get channel_destroy from ecallmgr]

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.