mc_

You have the idea that a member can affect their own settings while a moderator can affect others. You can also set up conferences to start/end when the moderator joins/leaves.

I've passed the lack of us-central onto OPS to see if they can get something setup. Thanks for the update!

PRs are always welcome to fix this, of course. I would venture that its not a common configuration nor should it be encouraged but if its a real need, please issue the appropriate PRs to make it happen!

Kazoo is API driven so I suppose if the IMS environment has a way to write adapters to talk to Kazoo it should be possible. Do you have a system in mind?

You'll want to take a look at the logs for Kamailio and FreeSWITCH; I bet something will pop in the logs for what's going on.

If you are hearing a recording it is enabled but didn't find any matching channels.

@Mike Montgomery From reading the list, everything not Qubicle-related is in the open source project.

@FASTDEVICE this won't be possible since you won't be able to create the "internal" number properly. If you create it on the hosted platform, it gets tagged as a "local" number; as such, it would be forced outbound to the carrier, even though it exists on Account B's callflow. This prevents accounts from stealing numbers that don't belong to them and receiving calls for those numbers. Is there a reason why account B's callflow can't have a proper DID that account A can call? As mentioned previously, that DID will not go to the carrier if it has been properly purchased and configured.

So when a call goes to the "Resources" callflow action, stepswitch (the app) figures out what carrier(s) to send the call to, right? But first it checks that the dialed number is not already existent on the system; if the number is found and it isn't forced offnet, stepswitch will hairpin the call back into the system for processing. So any numbers known to the Kazoo system will stay local unless forced to go out. So you could define an "internal" prefix of "+abc" and when you create your callflows, you create an "internal-to-kazoo" DID for that callflow as well. Now your Pivot app returns {"module":"resources", "data":{"to_did":"+abc1001"}}. Since you setup Account B's callflow to include "numbers" :["1001", "+abc1001"], and "+abc1001" is in the number database, stepswitch will hairpin the call to Account B. This is a hack! But if you accept the headache of managing this, it could be a way to accomplish your goal. caveat emptor

Not really. Most operators still bill account A for calling account B, even if the call doesn't leave the system. You might assign "internal" DIDs to your accounts' callflows that you track (that aren't route-able); since you track them you could "dial" "abc123" to route to account A's "123" callflow? Hacky but....

Basic idea is here: https://docs.2600hz.com/dev/core/kazoo_auth/doc/oauth/#using-google-drive-for-voicemails Doc needs cleanup to render better though. Use https://github.com/2600hz/kazoo/blob/master/core/kazoo_auth/doc/oauth.md

A couple quick thoughts I had: Branch based on caller id - presumably internal calls will have internal CID (3-5 digits typically). Branch to user->voicemail. If CID is longer branch to voicemail. Assign two extensions - a "public" and a "private". So internal callers know to dial 5xxx and external callers get 4xxx (or whatever scheme makes sense).

Actually, I wonder if you could route based on the caller ID first. Then you can encode the Time-of-day route to match what the allowed calling times are for each device/user.

Can you give me a concrete example of what your dial_plan is, the number dialed, and your callflow configs?

The "Request" username is normalized to e164 if possible from the get-go. Depending on your e164_converters, they may correct the request to something not accounted for in your dial_plan. The classifiers are in the number_manager config. You use the classifier name as a key into the call_restriction object to allow/deny/inherit. The classifier key is used (so in the example "tollfree_us", "unknown", etc would be the values to use in the call_restriction object. Pretty print is only used for display purposes in the UI; unrelated to call processing You have to escape the backslash to make it literal to make the regex be valid. See here for example

I can't think of an easy way to encode this in the callflow JSON structure, personally. You can create an account-wide restriction using the "no_match" callflow and the time-of-day callflow action. You can always send the call to Pivot and create a script that controls outbound dialing rules there, of course.

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

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.

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

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

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.

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}"

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.

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.

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.