Darren Schreiber

So actually we built the schemas so that they can have descriptions, and thus be "fed" into a friendlier tool. Let me talk to the UI team about what we can do here.

Someone rebuilt the old Kazoo UI developer app, perhaps we could merge that in and maintain it, if you really liked it?

OK sounds good!

OK, for those on-lookers. I've just gone through about 15 of Tuly's accounts and now believe that the information he is posting here is not accurate. For the sake of avoiding any misleading assumptions by other customers, we CAN NOT produce any failing packet traces except from ONE of Tuly's locations thus far. So, until I have something more conclusive that shows this is more widespread, please note that I do not think there is any issue on our equipment or with our network provider in EWR at this time. Happy to investigate more reports, and waiting for Tuly to provide a more comprehensive list of where he's seeing failures, but at this point, I can't reproduce this, including to his own customers, so I want to prevent any FUD on this thread until I have more data. I'll circle back when I've collected more data.

Also, I've re-confirmed that this appears to be only traffic to NY so far that I've been able to simulate this with. Very strange. I think a peer somewhere is saturated. I wonder if Level3 is having peering disputes again with Verizon and/or Comcast or their backhaul providers.

I don't think this is throttling. BlueTel has been working with me on this with some traces. What is super weird is Level3 (or Verizon?) is sending traffic to our gateway IP (.1) via one peering point, but traffic to our other nodes is going through an alternate peering point. I think something is still wrong, and am working on it. We did confirm that if you're impacted by this, you can reroute to us-central.p.zswitch.net for now and the problem is resolved. I may even do that for the remainder of the day for all traffic until I understand this issue more.

Now we're splitting hairs and finding things to complain about. OK, I'll bite. This thread is about Account IDs and Auth Tokens in the GUI. If you want to change the topic to the old Developer's app, I again state that the move from Kazoo UI to Monster UI had no change or removal in functionality. That's because the developer's app was replaced over 2 years ago in the Kazoo UI. Considering that this is the first time anyone has brought it up, I'm assuming this functionality was not missed. It wasn't a working product, it was supposed to be a demo, and it was not kept up to date with the latest functionality because it took too much time to do so. Postman was the replacement, as it provides a better experience and is easier to manage. If you have an issue with the Developer App missing, then please start a different thread - don't hijack this one, as it's totally unrelated.

You're talking about something different, FastDevice.

We are working on a new doc site, I'll see if we can post some info about the keyboard shortcuts and how they work.

Got it. So my point in my reply was that nothing was taken away from Kazoo UI, nor intentionally hidden. All the things available in Kazoo UI are still available in Monster UI, and have infact been enhanced to make it easier (hence the 'd' key to get the data with one push). So hopefully you see this as an improvement. Your original post seemed to imply we took something away that was there before - we did not.

We are working on supporting OAuth and a few other strategies as a baseline. Past that we can open it up for suggestions. Sponsorship is always welcome, as it helps us fund the development of such projects. Feel free to drop a note to sales@2600hz.com for that portion, but you are welcome to continue to post ideas here regardless.

That's correct. To support single sign-on features in the future, we moved to JWT-based authentication in 4.0. It also allows us to avoid storing additional information in our database about your authentication mechanism. Please read https://jwt.io/introduction/ if you would like to understand more about this technology, it is a common web standard now (RFC 7519). While it may seem more complicated it actually paves the way for single sign-on when you link it to your own Monster apps in the future, while also allowing our systems to work better in a distributed manner (less data to sync across nodes), among other things.

Thanks, I'll ask @JR^ and @Chris Kerber where they think this should go in the planning & UI.

What do you mean "now that I can't get it from Kazoo"? The Account ID is available in both the account manager and the currently logged in user's control center, and the auth token was never available in the old Kazoo UI. It's the same as it has always been? The only thing the debug option allows for is retrieving the auth-token, which has never been exposed previously.

LOL this feature was discussed on one of our webinars about a year ago :-) Press the question mark key on any screen for more tips. You must use keyboard shortcuts only when a text box is not already selected (otherwise it thinks you're typing in the text box). You just need to push d, not cd, in this case.

Yes but most people expect it to also not open the bridge until a moderator arrives, drop callers at the end when a moderator leaves, and give DTMF control, too basically. None of that works (yet).

That is the entire point of these new forums :-)

If someone could file a JIRA requesting this enhancement, I can see about getting it on the schedule.

The moderator pin doesn't really do anything yet. Also, you either use a moderator pin or an attendee pin. We're still working on moderator functionality.

ALG should be off, Consistent NAT should be on.

Not yet, we are working on an installer that allows for this. But we're not quite there, the delivery mechanism is being built for them.

This is not a great idea. While it's been discussed, we generally only support extension dialing within the same account. As you pointed out, there are many threads discussing this, and while most people SAY they only want to call extensions between accounts, the conversation always devolves into additional requirements (all of which vary) like BLF across accounts, conference bridges across accounts, parking slots across accounts, and so on. It gets super messy. We are instead working on a solution so that, in a single account, you can have multiple delegations (for location or franchise and so on). This should solve this, but is not ready yet.

We'll see for sure on Monday but we have just completed some routing changes that should put this issue to rest. Sorry for any headaches this has caused.

Thanks for writing. I'll try to answer your questions as best I can! You wrote: "1) I would like to know how many registrations/calls Kazoo can manage for each Kazoo/kamailio node (for registrations) and for each FreeSwitch node (for calls). How can I estimate these values? Do I have to evalutate for each node or for the entire cluster?" Currently we have a number of people hitting between 10,000 and 30,000 on a single proxy. There are some optimizations we're working on which should raise that limit, but that's the norm, on mediocre hardware. You wrote: "2) I would like to start with 2 nodes. How can I setup them? 1 FS + 1 DB/Kazoo? 1FS+1DB + 1Kazoo? All-in-one? Next they will be scaled as the registered devices increase." Yes, we support this now. All-in-one nodes are fine. You can split the components out later. But use at least 2 servers so you have some redundancy. You wrote: "3) I know Kazoo 4.0 pretty good (applications and source code). Is it a good idea to start with 4.1 instead?" Up to you, 4.1 is stable now. There was a memory leak in Kamailio 5.0.3a but I believe that is patched also, so should be good to go. We are running 4.1 publicly on many clusters now.

We now have three FiOS folks complaining about this. I have opened a ticket with Level3 to see if we can get some traces and figure out what is going on here.