-
Posts
1,760 -
Joined
-
Days Won
4
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by mc_
-
-
Thanks for the examples! I'll see if I can find time to try them out locally and reproduce the error you're seeing
-
By "funny money" I mean when you want to issue a service credit to your customer, say give them $20 for whatever reason, there's no credit card to charge or otherwise. It's just you updating their ledger with some "money". "real money" is when a CC is processed and those funds are added to the account to pay for services.
-
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`?
-
I can only point you to the docs and source code, unfortunately, since konami is a community-maintained application in KAZOO. I haven't worked with konami directly for some time.
-
Hi Vijay,
As seen here: https://docs.2600hz.com/dev/applications/crossbar/doc/channels/#put-a-feature-metaflow-on-a-channel
The PUT is not applicable for the open source konami application; it requires the currently closed-source konami-pro. So it is not unexpected that konami cannot handle the request properly.
-
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).
-
See konami_event_listener, you should also see konami_code_statem started when the call begins if the initial metaflow is configured properly.
-
I think there's some confusion on terminology here; let's clarify a bit
Pivot is an app that, on a per-call basis, sends an HTTP request to your server and receives callflow instructions (versus configuring the callflow statically). It has nothing to do with metaflows directly.
So when you say "testing the metaflow through PIVOT" I'm not sure what that means.
How are you initiating calls? What are the steps to recreate the issue you see? Basically, what are the steps in your two scenarios, from start to finish, for how the initial phone call is placed up until the call ends?
Another thought, device ID is typically sent as 'Authorizing-ID' when the call is started by a known device, perhaps that is present for you to use?
Finally, if you're in a bad spot, you might consider contracting with us for support, officially, and get dedicated engineering time to help you move forward. Obviously that's a business decision on your end but figured I'd mention it.
-
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...
-
Yeah no metaflow is being sent to Konami during call setup. Take a look in cf_route_win maybe_start_metaflow to see what it is looking for and what you've configured.
-
Your pivot response is to play silence for 60s but you don't specify DTMF terminators so when you press '*' the playback of silence is cancelled. Then because you have no more callflow actions, the call is hung up.
-
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!
-
The control queue is "ecallmgr@sandbox.testcomp.com-ecallmgr_call_control-<0.363.4>-35669c98". This tells you that the control queue is on the "ecallmgr@sandbox.testcomp.com" Erlang VM, an "ecallmgr_call_control" process at PID "0.363.4". Your logs, afaict, don't include the logs for that PID. You may need to increase ecallmgr's log level. sup, by default, talks to kazoo_apps@{hostname}. You can include "-necallmgr" to run commands against the ecallmgr VM: "sup -necallmgr kazoo_maintenance syslog_level debug" for instance.
-
@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.
-
@Srikant sorry, I'm not seeing KAZOO debug logs in your attachments. Can you increase logging to debug and make another attempt. Grab the call-id and use that when grepping the logs.
@Vijay https://docs.2600hz.com/dev/applications/crossbar/doc/metaflows/
Do note that Konami is the community-supported version at the moment.
-
You will need to get the ecallmgr logs to see if the hangup was received or check the FreeSWITCH logs to see if uuid_kill was issued.
-
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.
Direct SIP Calls with Kazoo
in General OS Kazoo Questions
Posted
@chinext its a good question and the short answer is no, KAZOO as-is doesn't support this use case. I'm assuming here that you mean a SIP device unknown to KAZOO sends an INVITE to to KAZOO for customercare@sip.realm.net and expects it to be routed.
You ask about `customercare@publicip:5060` but there's no way to associate `customercare@publicip` with an account in KAZOO. Because KAZOO is a multi-tenant environment you need some kind identifier (a DID or an account's SIP realm) to identify the call as being for a particular account. KAZOO allows you to define carriers and add those carrier(s)' IPs to your ACLs to allow inbound calls from them. You then need to setup the DIDs in the database to be assigned to an account. Since `customercare` is not a DID it isn't searched for to associate with an account. Additionally, it is not "unique" so how would you handle two accounts defining a "customercare" callflow?
Bigger picture, why can't your callers come through an authenticated portal of some kind? Why are they initiating calls to `customercare` and how are they doing so?