[Add custom field/attribute to Users and CDRs Schemas]

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

[Email To Fax Gateway]

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.

[How to add existing caller to a dynamic conference]

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?

[Unable to Play Media using 'Https' link]

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.

[How to add existing caller to a dynamic conference]

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.

[How to add existing caller to a dynamic conference]

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!

[Websocket address:port for 2600hz hosted Sandbox?]

wss://sandbox.2600hz.com:5065

[How to add existing caller to a dynamic conference]

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

[Kazoo UI / Winkstart not wanting to connect to server]

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.

[Kazoo UI / Winkstart not wanting to connect to server]

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?

[Can't create callflow from main number?]

I suspect you need to find out what is using the number, no? The number should have a "used_by" attribute that can hint at it. Or search your callflows. Did SmartPBX get opened on the account and auto-create them and you don't realize it?

[Kazoo UI / Winkstart not wanting to connect to server]

I suspect the config.js (or whatever it is for kazoo-ui has a URL for Crossbar that is not reachable. Try using `curl -v` on the URL to see more details on what's happening perhaps?

[Call forward not showing initial caller]

If you can capture the SIP packets and debug kazoo logs, you should see what caller-id manipulation is happening. Specifically you would need to look at the second pass through KAZOO when Avaya forwards the call to the X03 number, how the SIP packet comes in from Avaya.

[Terminating Call too early]

@bsimpson72515 afaik kazoo-ui will still work through 4.3. When 5.0 is release, /v1 of the API will be deprecated and kazoo-ui will cease to work as it uses /v1.

[10 Years of KAZOO!]

@fmateo05 thanks, its a team effort with 2600Hz, our partners, and the community at large. Thank you for participating here on the forums, I know lots of people are benefiting from your questions, comments and answers!

Oh yeah, if SF in March sounds feasible, anyone can get a discounted ticket by using my code "JamesAimonetti15". I get no kickbacks here, you just get 15% off!

[Detecting Call Path (Ring Group vs. Direct to ext)]

@Ken Rowland it is my expectation that using the 'set_variables' callflow action with '"data":{"custom_application_vars":{"my":"secret"}}' will cause all subsequent call events for this call leg to include '{"my":"secret"}'. If you add '"export":"true"` then the bridged call leg should also carry them.

If that's not the case, please open a support ticket so we can investigate. But we do have customers that rely on these CAVs being present and, AFAIK, we have not received additional reports of missing CAVs.

[Terminating Call too early]

I mean, its your cluster right? So you can run whatever you want. But, IMHO, how is running a 4+ year old version of KAZOO easier than fixing on HTTP response's content-type header?

[10 Years of KAZOO!]

July 28th 2010, the first commit to an ambitious project, Whistle, was made.

We're coming up on 10 years of KAZOO and all its history! Holy moly!

Part of the fun will be a talk I'm giving in March in San Francisco at the CodeBEAM conference. I'll be going through some of the history of KAZOO, how we got where we are today, some war stories, horror stories, hopefully some levity and minimal amounts of 20/20 vision jokes. But come on, there's probably going to be at least one! As a dad, I can't not make 'em!

I would love for folks to come, especially anyone interested in (or already doing) Erlang as this is a premier conference to attend. The hallway track is worth the price of admission and the talks are typically top-notch (excepting yours truly but apparently I know where the bodies are hid?).

Whether you can join the conference or not, I'd also love to hear your stories around this project and maybe include some in the talk if you permit. Are there things you want to know more about, like technical decisions, that I can make sure to speak to in my talk? Anything that sticks out as "I'm really glad I'm part of this community"?

Look forward to hearing from you all!

[Terminating Call too early]

The first implementation of Pivot was a basic TwiML clone, so we probably didn't check the content-type response header then. When we added KAZOO's callflow JSON as an option, Pivot started checking the content-type to know which backend, kzt_twiml or kzt_kazoo, to use interpreting the response.

Now, why your server changes from text/xml to text/html I can't answer. Its obvious the preceding responses had their content-type header set to text/xml so you would need to check the code path taken on your side for this failing response to see why it didn't set the content-type header.

[Terminating Call too early]

Pivot posted to ' Jan  7 16:05:57 pintransfer 2600hz[1137]: |call-711CE674-8013-3810-000C-2F@72.82.244.65|pivot_call:431(<0.2507.0>) sending req to http://209.142.178.205:57113/Keefe_2//Keefe/amountEntered(post): Digits=1&CallerNumber=9940140000&CallerName=9940140000&Direction=inbound&ApiVersion=2010-04-01&ToRealm=165.227.107.0&To=9940140000&FromRealm=165.227.107.0&From=9940140000&AccountSid=72bd25b60a91cfebe5bf1f50894126ee&CallSid=call-711CE674-8013-3810-000C-2F%4072.82.244.65 '

That returned text/html which is wrong, it should be text/xml, as the previous responses returned.

[Terminating Call too early]

@bsimpson72515  the previous Pivot requests to your URLs all returned with 'Content-Type: text/xml'. 'text/xml' is associated with the twiml backend of Pivot and so life is good. The errant response itself is fine, XML-wise, but the server is returning 'Content-Type: text/html' which is not associated with any Pivot backend. Why does the web server response with the proper Content-Type header in all but the last response?

[Internal Error when creating account]

@simonp22 No not yet, sorry. It is not forgotten, just keeps getting trumped by other work. I'll throw this into the engineering pool and see if anyone else has spare cycles to look too. Otherwise I will try to get to it this week.

[msg_id in websocket messages]

This guy's blog is great in general for SIP stuff but specifically https://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/

 

[msg_id in websocket messages]

I believe msg_id for call events is the timestamp from FreeSWITCH, at least in 4.3. So presumably msg_id + event_name should be "unique"?

[Unable to make successful call.]

Interesting that the mod_kazoo processes in your logs restart the event streams. I suspect your packet framing sizes are mismatched between ecallmgr and mod_kazoo. Check those settings (there's a recent thread about it) and hopefully that addresses the issue.