[restricting a device]

1. You could use Pivot and maintain the list of device->allowed_numbers in a db. Then you can create a UI where you/the facility can manage what numbers a device can dial.

2. You could create a "dial_plan" object on the device that whitelists the allowed numbers and rewrites all others to a "can't dial this number" recording (like adding a prefix "BARRED" and having a callflow pattern for "BARRED{\\d+}")

Those are two quick thoughts with no testing so buyer beware

[Unable to get the kazoo atlassian wiki page]

Probably though I find the docs site comes up using duckduckgo. I don't think we've tuned it much and should probably add redirects from the wiki somehow. The big push is getting content moved over; making it discoverable to the search engines hasn't been prioritized yet.

[Advanced Provisioner Vs SmartPBX]

Also, there was open-source carrier management in KazooUI but there hasn't been one in Monster open-sourced yet. I don't know the timeline but I'm pretty sure the intent is to open-source it once its "finished".

[Advanced Provisioner Vs SmartPBX]

Your assurance is that you can fork the open source work and maintain a copy yourself. AFAIK there are no open-source components in Monster or Kazoo that have been changed to closed source.

[IP Phone Dial Plans]

I will throw in doing similar things on the server side (never hurts to have redundancy!):

1. Classifiers can be used to restrict/allow dialing numbers. In your example, a classifier for "\\+?1900\\d+" could be added to deny access to these numbers

2. Dial plans can convert "local" dials to appropriate representations. You can prepend area codes, country codes, add access codes, whatever is needed.

These will operate independent of the phone manufacturer which is nice in case a phone is misconfigured, tampered with, credentials stolen, etc. Good security is built in layers (just like ogres and cakes)!

 

[Building Kazoo]

Perhaps you could share where its failing and we could go from there? How did you install Erlang? What version? Etc...

[failed to query registrar for authentication credentials]

@Andreas Mueller you might want to use CentOS 7 and the install instructions here: https://docs.2600hz.com/sysadmin/doc/install/install_via_centos7/

In any case, walking through those steps might help you figure out what is wrong in your existing system as well.

[Cheat sheet]

The install guide has a lot of those commands as part of setting up a server. Want to contribute a v4 cheat sheet to the sysadmin repo?

[Conference Bridge Not Using Account's Hold Music]

I don't think this is currently possible. I know there's work done to make conference profile generation more flexible but don't immediately recall if that includes account-specific overrides.

[Conference Bridge Not Using Account's Hold Music]

I believe this is controlled in the conference profile config in the conference system_config doc. "moh-sound" for the default profile is "$${hold_music}"

[how does kazoo APIs compare to RestComm]

Perhaps it would be better if you specify your requirements and we can tell you if Kazoo meets the need? Of if there's something in RestComm that you can't find in Kazoo, maybe we can point you in the right direction?

[Unable to get the kazoo atlassian wiki page]

The wiki is in the process of being deprecated. Some of the pages were "auto-imported" into the docs site but require refreshing and updating to render properly. For instance, the SUP page can be found here. It needs love though; want to make the updates and issue a pull request? There's an edit link on the page if you're signed into Github.

[SaaS Support]

Hi @Luigi and welcome! You will want to check out our Global Infrastructure program. You can also reach out to the sales team to talk through your requirements, hopes, and dreams. They'll walk you through your options, give you a demo of what the platform looks like, etc.

[Testing on Local Machine]

And to be clear, this is changing so that the billing component is more general and less tied to braintree. Not sure on roadmap / timeline but it is an active priority.

[Who wants a Developer app, or, a bunch of API calls/Commands and a Step by Step Postman Tutorial?]

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

[Scalability of Kazoo - Number of Users Supported]

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!

[Scalability of Kazoo - Number of Users Supported]

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

[Callflow limiations]

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.

[schema user_auth not found]

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.

[net neutrality: What it means for us?]

[Idea - Invisable unicode characters to track menu usage?]

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.

[Idea - Invisable unicode characters to track menu usage?]

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.

[Sharing Media Files with Child Accounts?]

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

[Sharing Media Files with Child Accounts?]

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

[Sharing Media Files with Child Accounts?]

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