mc_

Those look borked. See if you can revert the doc back a revision or two? { "special_services_087_uk" : { "friendly_name" : "special_services_087_uk" }, "special_services_084_uk" : { "special_services_087_uk" : { "friendly_name" : "special_services_087_uk" }, "friendly_name" : "special_services_084_uk" }, "premium_uk" : { "special_services_087_uk" : { "friendly_name" : "special_services_087_uk" }, "special_services_084_uk" : { "special_services_087_uk" : { "friendly_name" : "special_services_087_uk" }, "friendly_name" : "special_services_084_uk" }, "friendly_name" : "premium_uk" }, "personal_number_uk" : { "special_services_087_uk" : { "friendly_name" : "special_services_087_uk" }, "special_services_084_uk" : { "special_services_087_uk" : { "friendly_name" : "special_services_087_uk" }, "friendly_name" : "special_services_084_uk" }, ... How did you set these up initially? Lots of weird duplication going on...

What's `sup knm_converters available_classifiers` return?

Port 8000 is the API port, not the HTTP port for serving the MonsterUI Javascript, CSS, etc. If you just access http://${IP_ADDR}/ with no port or /v2 you should see the UI load.

What version of KAZOO are you running? Did you recently upgrade and not run `sup kapps_maintenance refresh` or `sup kapps_maintenance migrate`?

Depends on your definition of easy For the most control from your perspective, a Pivot callflow would allow you to maintain dynamic access codes and return the necessary callflow JSON to either complete the call in an authorized scenario, or respond/play media in an unauthorized scenario. If the access codes are more static, you could look at the menu callflow action and have the valid access codes be child branches of the menu action. Just back of napkin here but I could see: 1. Set the callflow's "patterns":[..] to match international number formats, this way you won't conflict with extension of local dialing rules 2. First action of the "flow" is the menu with a prompt to enter access code to authorize the call 3. Children for each access code and a catch-all for invalid entries 4a. Valid child branches will then have the "resources" action to route the call accordingly. 4b. Invalid will play a media file or respond with SIP error codes. Maybe this can give you a little direction? You could also look at the DISA callflow to see if that would work better (similar step 1 though to match international calls).

AFAIR these are still using the FreeSWITCH say command so you'll need to look for a language pack for FreeSWITCH. Check the FreeSWITCH log of the call to see if it is using a URL (kazoo prompt file) or the 'say' command to be sure though.

Could be a ulimit issue? Check those settings, make sure you have enough file descriptors...

It appears that app (not a 2600Hz monster app) is not compatible (at least not directly) with KAZOO 4.3: root@four monster-ui]# sup crossbar_maintenance init_app /var/www/html/monster-ui/apps/whitelabel http://192.168.122.119:8000/v2 trying to init app from /var/www/html/monster-ui/apps/whitelabel failed to incorporate app because there was no app.json in /var/www/html/monster-ui/apps/whitelabel/metadata Unless there are missing steps to getting that metadata directory populated, anyway. Compare to SmartPBX's: https://github.com/2600hz/monster-ui-voip/tree/master/metadata For the Spanish stuff, I can only point to Monster's docs: https://docs.2600hz.com/ui/docs/internationalization/ In any case, I think it is important to distinguish between MonsterUI (the web frontend) and the KAZOO backend - they are two distinct entities. But I also think the internationalization capabilities of Monster have improved (we have more native Spanish speakers on staff so hopefully that's the case ). Thanks for sharing what bogged you down. Hopefully you'll give it another shot at some point!

@Guillermo Prado sorry to hear your frustration with the platform. What in particular was out of date or poorly documented for you? What was hard that you thought should be easier? Would be great to know where to direct some attention. For reference, https://docs.2600hz.com/dev is refreshed every time a commit is merged into the master branch of KAZOO so it should always reflect the latest and greatest. Admittedly there is still some work to be done to backfill more information but we need to know what people are using so we can focus there.

Possibly permissions on the database files themselves (I think they're under /srv/dbs ?). Try accessing a single bigcouch node and see what its logging. Also, n=4 (or any even number) is problematic in a network split. It is generally good to have n be odd to make it more likely to have a majority on one side of the split.

I would guess the "bridged" part is necessary for the export to happen, but I'm hazy on the details at the moment.

Sorry to hear, this is one of those cases where I think we've been in the weeds so long it wouldn't even occur to us to use the platform's hostname as a SIP realm for an account. Would love to see a pull request against https://github.com/2600hz/docs-sysadmin/blob/master/doc/install/install_via_centos7.md Put the text you wish had been there?

@Ken Rowland that particular PR was merged into the master branch (what is going to be 5.0). I'm not sure if there was a backport to the 4.3 branch so it will not be available until 5.0.

@Ken Rowland are you looking for some kind of macro-expansion to add the group ID? I don't believe those exist for custom application vars. Are you seeing any attempt in your KAZOO logs to set the CAV on the channel (should be in ecallmgr and FreeSWITCH logs at a minimum if KAZOO is trying).

I mean the RPMs aren't hosted by 2600Hz anymore, as far as I know anyway. Perhaps there's an archive somewhere. But more importantly, why can't you upgrade production? There are a myriad of reasons why you should be upgrading, chief among them security improvements. What limitations are you up against to upgrade off a 3+ year old version of KAZOO?

@Dhoine 3.20 is not supported. 3.x is not supported. 4.3 is supported. 5.0 will be released in the near future. What's preventing you from upgrading to 4.3?

Correct; once set they will appear on all subsequent call events for the leg (via webhook / websocket if you ingest those) as well as the CDR.

You will need to consult your logs to see that callflows sends the metaflow request to start the Konami listener and that Konami is receiving the DTMFs and attempting to match them to a metaflow.

Did you configure metaflows on the account? https://docs.2600hz.com/dev/applications/crossbar/doc/metaflows/#set-metaflows-on-the-account Unfortunately, you need at least one metaflow (even a basic no-op one would work) to trigger this functionality with Konami.

You are on the right track. You need to use the channels API: https://docs.2600hz.com/dev/applications/crossbar/doc/channels/#execute-an-application-against-a-channel Enable metaflows on the account, execute your pivot request as before, then use the Channels API to interact with the call in progress. You'll need Konami running to handle the call manipulation.

Don't assign the account a DID and it won't receive a call for that DID. If you must keep the DID assigned to the account, create or edit the callflow for the DID(s) to use the "response" callflow action to respond to the caller with the SIP response code of choice.

I found updating the FreeSWITCH candidate ACL list to allow local IPs works because FreeSWITCH will auto-adjust the RTP stream based on what is being sent from the browser.

AFAIK there are not; accounts (or their resellers) should maintain those by cleaning up as necessary. As a feature request, this would be pretty straightforward to implement as a task for the tasks app, though.

What version of KAZOO? What type of cert? Is the https address publically accessible for us to try? And what are the logs for the attempt (probably log lines prefixed with `kz_http`).

Just checked the 4.2 code and indeed, the menu callflow action does not construct the URL in the same way that 4.3/master do. Sorry, I should have asked your version at the start. So this will definitely work when you upgrade to 4.3