mc_

I assume base url is http://server.com:8000/v2 (v1 is deprecated and should not be used anymore).

Basic SIPp scripting: https://github.com/2600hz/community-scripts/tree/master/sipp And make-busy: https://github.com/2600hz/make-busy Though make-busy is getting an overhaul to be more friendly to test writers!

To add more, will your devices be doing HD audio? Video? Lots of transcoding between WebRTC (using OPUS) and PSTN (using PCMU)? Conferencing? If so, how many participants? Support for SIP over TCP/TLS/VPN/etc (basically non-UDP)? SRTP? Fax? Expected CPS and concurrent calls? Lots of presence/BLF/other features? As mentioned, you can create more zones to isolate load based on geography (typically). You can throw bigger hardware at the problem. You can buy bigger and bigger pipes. You can host and get cross-connects in the same data-centers with your upstream providers. But there's no magic formula for inputting X devices and getting Y infrastructure costs. There are best practices that get you pretty far but eventually something will crack and you'll need good monitoring to detect those cracks. So, yes, Kazoo can be (and is) deployed to support 250K+ devices. As you grow, different parts of the infrastructure will fall down and need improvement, and where those spots are tend to be unique values for each installation (esp since usage patterns tend to vary greatly). We can be your partner in that journey to 250K and anticipate a lot of the growing pains

There is "max_branch_count", in the 'callflows' system_config, that defaults to 50 branches. Each time the callflow branches, it decrements its counter (starting at 50 or whatever the system_config says) until it hits 0 when it will stop the call.

Sounds like the schemas haven't been loaded into the database. Try 'sup kapps_maintenance refresh system_schemas` to force a reload of schemas, then try your create command again. You probably want to remove the account db (and modb), and the account doc from the 'accounts' db.

At the moment, no, its simple key/value pairs and the old value is overwritten. You can file feature requests like above so we don't lose track of them though.

There's a new callflow action, "set_variables", that you can use in Kazoo 4.2+ to set key/value pairs on the call. These will then exist on call events and the CDR under "custom_application_vars". This is probably the saner way to accomplish your goals.

@Josh Robbins sorry! PR is a pull request - when a developer wants to change something in Kazoo, they issue a PR to be reviewed by the team then merged into the project. I'll issue a PR to change the schema, get a team member to review, and then the next upgrade of the platform will change the schema's restriction. So it will be delayed a bit from being realized on the hosted platform but will make its way there eventually. Does that clarify things?

@Josh Robbins Ah, we can relax the schema to be 128 chars instead. I'll get a PR up today for that. If you're running your own system, you can edit the 'system_schemas / menus' document. Look under the "media" object for maxLength and change it to 128 (although, since technically you can put URLs there but of course RFC 2616 and 7230 say there's no defined limit - it is server-dependent - so...pick a value. It seems like 2048 is probably "big enough").

Try referencing the media as "/RESELLER_ACCOUNT_ID/RESELLER_MEDIA_ID".

https://docs.2600hz.com/dev/applications/crossbar/doc/accounts/#move-an-account Should get you what you want.

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?

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

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