mc_
-
Posts
1,796 -
Joined
-
Days Won
4
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by mc_
-
-
Not sure what OSes will be targeted. I think CentOS7 will continue and hopefully a Debian variant. Not sure on timeline for CentOS8 though...
-
@btracht00 hmm, didn't know there were 3.22 still active lol
We weren't planning on keeping the 3.x->4.x migration stuff in there with 5.x so I would say you'll need to upgrade to 4.x first, then 5.x once its available in the packages.
-
Hi Folks,
Its finally happening! We are separating the KAZOO git repository into multiple repos, one for each kazoo application (and one for kazoo core libs).
This Friday, May 1st, at the end of business hours Pacific time, all remaining pull requests will be closed from the main kazoo repo (the Erlang team here will be working hard to merge as many before that time). Closed PRs will be asked to be re-opened against the appropriate repo(s) starting on Monday. The breakening will occur over the weekend.
The workflow for KAZOO development will be a little different in the bootstrapping phase - you will define the applications you want to include (crossbar, callflows, whatever) and they will be fetched just as we fetch 3rd party dependencies now. The apps will still live under applications/ so most existing tooling will continue to work as expected. We realize there will be some pain points in the transition. We want to hear what you're butting up against so we can build tooling or refine process to make development a more pleasant experience.
Community apps like ACDc and Konami will be moved to a new Github organization: https://github.com/kazoo-community
If you would like to be added as a contributor or maintainer of a repo under that organization, let me know. Eventually we'll get a proper organizational structure but for now, the leading community contributors are going to be auto-accepted if they ask to be included on those repos. What that means is 2600Hz will no longer be in the mix for reviewing/merging pull requests. The community around each app will be able to move forward as they see fit.
This is a big step and we know there will be a period of adjustment for everyone, 2600Hz engineers included.
If you have further questions, please ask here and I'll clarify as necessary.
Thanks!
-
Yup, nothing too helpful in that log. You may not have captured the logs of the timeout. In any case, keep an eye on it and hopefully you can capture it closer to live next time.
-
@wolfman1956 you'll have better luck using plaintext; I don't open random MS docs posted to weird forums about telecom stuff...
-
Adding the file SmartPBX_app.png to doc e9cc159ebcb93062e51c5f38604ec77f resulted in a timeout. I would check the local HAProxy logs to see what it has to say about DB requests to Couch for that ID, then check the actual Couch servers for that ID as well. May be something lurking in those logs.
And welcome!!!
-
Those apps just create callflows using the 'menu' action. Use the children object to match DTMF inputs. See https://docs.2600hz.com/dev/applications/callflow/doc/menu/
-
I think you want to set the forwarded device's call_forward:{keep_caller_id:true} (assuming you're doing the forwarding server-side. Then look in your system_config's kazoo_endpoint doc for "should_add_diversion_header" and set it to true. `sup kapps_config set_default kazoo_endpoint should_add_diversion_header true` should work.
See if the carrier likes that.
-
As @mat1010 points out, you can use the "rules" regular expressions to filter what types of numbers can be routed using a particular resource (carrier). See https://docs.2600hz.com/dev/applications/crossbar/doc/resources/
There's also a 'resource selectors' option: https://docs.2600hz.com/dev/applications/crossbar/doc/resource_selectors/ contributed to the community. May help you too (though I haven't personally used it).
That should cover the "destination" portion of your question.
For caller ID, you would need to setup the callflow(s) with branching based on the caller ID: https://docs.2600hz.com/dev/applications/callflow/doc/check_cid/
Using the match/nomatch branches, you could then use the "resources" callflow action and set an outbound_flag "use_c" or whatever, which the resource doc would need to have in its "flags" as well. See https://docs.2600hz.com/dev/applications/callflow/doc/resources/
-
If the fields are not defined in the JSON schemas, KAZOO will store them but they are unused. How would they show up in the CDR at that point?
Instead, in the callflow, use https://docs.2600hz.com/dev/applications/callflow/doc/set_variables/
However, since you want to dynamically set team_id (or whatever) you will need to use Pivot in your callflow to set the variable on your server.
So your callflow would for "no_match" would be Pivot -> Your HTTP Server. Your server would then return callflow JSON like "{"module":"set_variables", "data":{"custom_application_vars":{"team_id":"YOUR_DYNAMIC_TEAM_ID"}}, "children":{"_":{"module":"resources", "data":{...}}}}"
I have not counted my curly braces so adjust accordingly :)
-
What version of kazoo-configs-kamailio is installed?
-
Did you enable the websocket and tls roles in Kamailio?
-
If you stop the 'cdr' app it will not store the CDR data into the account's MODB. `sup kapps_controller stop_app cdr`
-
You have some options but nothing immediately straightforward that I can see.
There are "custom_application_vars" that you can set in a callflow: https://docs.2600hz.com/dev/applications/callflow/doc/set_variables/
So if you have a callflow that goes to a ring_group for "team X" you could put 'set_variables' before the ring_group action and set the team_id in the CAVs. These CAVs will appear on the CDR.
-
If you create a user with any fields not defined in the schema, KAZOO will store them untouched. So you can easily add "team_id" to the user doc when you create it and you will get it back when you fetch the user doc.
For the CDR portion, you should get the Owner-ID included if the device involved in the call leg is owned by a user. Assuming you track the KAZOO User's ID + "team_id", you should be able to receive the CDR, read the Owner-ID and associate the CDR with the user / team in your application.
And welcome! :)
-
You should have logs related to KAZOO receiving the email and processing it. Make sure you're in debug log level and see what's being logged.
-
You can use the conferences API to dial out to the participant - this will create the conference if not already running and put the callee into it in one step.
But you can't create dynamic conferences with a statically defined callflow - you need Pivot to help you return the conference callflow JSON with the conference name you want to use.
Perhaps if you tell us more about your logic for how you name the conferences, maybe there's a way to do it?
-
First thing to check is if you can get the file from the FreeSWITCH box using cURL: `curl -v $URL`. cURL's output will tell you what cert bundles are being used. Then check FreeSWITCH configs to see if its using a similar bundle; update if not.
-
Nope, there's no "target" (which is basically a callflow extension/number) named conference1 so it won't work. You could transfer to "target":"pick-conference" then create a callflow with "numbers":["pick-conference"] and a "flow":{"module":"pivot",...} that will call out to your server. You do your logic, realize the caller needs to be connected to "conference1" so you return {"module":"conference", "data":{"config":{"name":"conference1"}}}
Something along those lines should get you where you want to go.
-
Dynamic conferences basically use a hash of the "name" so as long as you use dynamic conferences with the same "name" KAZOO should still locate things fine. Give it a shot!
-
wss://sandbox.2600hz.com:5065
-
@Srikant I would say use the /channels API + metaflows to initiate a transfer of the callee's leg to the conference.
But I would also ask why don't you put the callee into the conference first with your hold music, then add the second participant?
-
Obviously the web server, on port 3333, is responding. However, your initial report was the UI telling you it couldn't connect to the server, which is the KAZOO API server. That server address should be stored in the config.js file somewhere (forget the format but should be obvious).
The KAZOO URL is the one not reachable. Test that...then check kazoo logs, make sure KAZOO and Crossbar are running on the expected server(s), etc.
-
43 minutes ago, bsimpson72515 said:
<!--script type="text/javascript" src="config/config.js"></script-->
I suspect that's your problem. Why is your config (which I wager has the Kazoo API URL) commented out?
The Great Breakening for 5.0!
in Product Discussion
Posted
It is done!
Community-supported apps can be found here: https://github.com/kazoo-community
2600Hz-supported apps can still be found here: https://github.com/2600hz
Look for kazoo-{APP} repos like kazoo-crossbar.
The kazoo repo itself still serves as the focal point for pulling in core and apps, tooling, CI, etc. Changes to the Erlang code will be committed to the individual repos.
There's still a lot of work to do (like linking changes in two or more repos) and general workflow improvements, but this is an exciting step! Plus I may never get a commit stat like '+490 −717,630' again!