Darren Schreiber
-
Posts
1,202 -
Joined
-
Days Won
27
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by Darren Schreiber
-
-
So we already integrated the provisioner with the Obihai's, but there were so many problems with the existing templates that we decided not to roll out anymore new templates until all bugs with provisioner were fixed. Yealink screwed us a bit because they changed the format of major settings between their firmware version upgrades (they now have two concepts, "ComboKeys" and "Line Keys" even though the T22 and T23, for example, are nearly identical). They also changed their port mapping strategy, which screwed up a bunch of firewall stuff.
So, yeah, that took a while. But I believe that's all done now.
We have one outstanding issue, actually from Karl on this board which he has been waiting for for a while, where he sent in a video showing that BLFs don't work right on Polycoms via the new provisioner. This is totally weird and we can't figure it out so I've asked our team to test again, otherwise setup a live debug next week w/ Karl to fix that.
We're rolling out a new security system for provisioner this weekend and also a neat new feature that I'm not going to mention here because it might not work :-) It's really hard to test. But if it does, you guys are going to be psyched </teasing>
ONCE WE'RE DONE WITH ALL THAT, then we will start adding more models. My list includes:
* Grandstream Phones (we are already working on these, and Grandstream is releasing a fix for NAPTR/SRV records, which we now require, in their next release so that their phones failover properly on our system)
* Grandstream ATAs
* Obihai ATAs
I am really on the fence about Cisco 79XXs, we stopped getting requests for them, so I could use some input there. They are such a nightmare and have so little functionality.
We get a lot of calls about the Panasonic Wireless sets, but they fail to re-register automatically if they ever get a response back to a REGISTER that is anything other than 200 OK and we've never gotten them to fix that, so that one scares me. It's a terrible user experience having to reboot the phone to get it back online, for any reason. Sooooo yeah on that one, too.
Finally, I should note, in regards to faxing, there ARE special settings for fax ATA devices. We're working on a new tool and guide for that. We still can't guarantee 100% but it's much better and we've learned a LOT. So we'll probably explicitly have ATAs in the provisioner, and then "ATAs connected to Fax Machines" as a section. -
2600hz is trademarked. All the other items are not. I doubt we'll change that ever, certainly not anytime soon, though. It doesn't do anyone any favors, I don't see the point, so, yeah...
-
Hi there,
We are literally writing two documents right now, so good question!
1) A partner program, for people who want to CONTRIBUTE code back to the project. The idea is to give you credit for what you contribute which you can use for consulting, hosted services, etc. That way people are encouraged to contribute more. Right now there's a huge lack of contributions and I blame us for not making it easier and rewarding so we're working pretty hard on that.
2) The App Store program. As you can see, in Kazoo UI we had a thing called App Store that was anything but, but we've always had that idea. In Monster we actually flushed it out. Now we're working on the transaction services behind it and rules for using it. If you have an app you already want to put in, contact me offline and maybe you can trial the idea with us. The apps would be available to everyone - open-source and closed - who use the platform.
As for the original question re: wiki/documentation, we discussed this internally. We discussed Confluence (which we used before) but it's sooooo hard to modify the HTML/CSS/etc. unless you run your own copy, which we don't want to have to manage (it's a beast of a Java program with constant security patches and such). So we think we're going to use Github's Wiki service. It lets you edit online in the browser, or offline. Only thing it doesn't have is easy image attachments, so I'm still looking around. -
So to follow up on the Wiki, we discussed this yesterday.
Github has a Wiki. It also lets you fork it so you can always have a copy and never fear where it goes. Plus you can download it offline.
So we're going to use our Kazoo Wiki and I'm working on laying out sections I think you guys want filled there. I'll keep you posted. This solution is cool because you can edit inline on the webpage, or download it and edit offline in your favorite editor. And we can track revisions.
Will this work? -
Is this also popular? We get this request but mostly from overseas places where DIDs aren't cheap.
The problem with these is fax machines that don't make a tone. Some still exist, or try to do answer detection and don't like hitting an IVR. This then, of course, generates support tickets.
We could potentially implement this but I wonder if the demand is really that high? Also, it would probably only work for IVRs because Faxboxes have nothing to do technically with voicemail boxes so on individual users I don't know how, once you're in a voicemail box and we hear a tone, we'd be able to figure out which faxbox it maps to. Maybe in SmartPBX we could just assume it's the same user and in advanced callflows we could let you manually set a mailbox. -
So, this one is kind of funny. I can't believe you guys like this.
DISA was supposed to be for REMOTE people to call in and then call out, deferring international charges to their provider/company/etc. Our implementation of it was originally designed simply so a customer with a cell phone could call-thru on a pre-paid style system, preserve their phone's Caller ID (we did NOT originally change it) and then have the international call charge to someone else. It was actually from back in the day when cell phone companies were still pitching Family & Friends plans, where you could have up to 5 numbers that were free to call. By making the DISA number one of the free numbers and making all your calls via it, you still kept your cell phone Caller ID but you could call the DISA number first, then the actual number you wanted to reach. Then all your calls were free.
Fast-forward a year or so and we started getting people who wanted to use this feature for what it historically is actually for, which is charging your company for your outbound calls while also appearing to be at the company / at your desk (i.e. having the Caller ID match the person calling out). Because DISA PIN codes are per-account/call-flow and have nothing to do with a user, we have no way to identify the "right" Caller ID to use for a particular user from the PIN. Therefore, we simply chose the easiest option (for times sake) and changed DISA to start masking the Caller ID if an account-wide Caller ID was set.
When we rolled that out, we got a call from a company (possibly you Michael? I'm not sure) who, unbeknownst to us, had been using the callflow editor to map Dynamic Caller ID + DISA (with no PIN) to a speed dial button on people's phones. When the user pushed the button, they heard a familiar dialtone, entered their Caller ID number (which was the Dynamic Caller ID module), then routed to DISA to dial out (with no PIN). Problem is, we didn't know people were using it in this way, and the upgrade we did just broke their setup because it forced the Caller ID to match the account and was no longer just "not touching" the Caller ID, meaning now the Dynamic Caller ID was being overwritten.
We really wanted DISA to have a consistent behavior, especially since it already seems to confuse people. So what we did is we added a hidden flag in the API that lets you make DISA NOT set Caller ID, and for everyone else, we made the default for DISA to use the Caller ID of the account by default.
Based on this thread, I am surprised at how popular this idea is. We have had a lot of comments about Caller ID recently for some reason. I'm wondering, before we decide how to "fix" this better, maybe you all could tell us WHY these people are changing their Caller ID? What is the actual use case? I feel like we keep going in circles with this feature and guessing as to what the actual use case is.
Then we could design something better that fits everyone's needs. My thoughts on the current DISA design is, by definition, it's now finally doing what it's supposed to do by default (based on how other systems work) and what you guys are doing with it is kind of a hack. I'd almost rather copy the module and make a new feature with a new name that's, like, "Custom Outbound Caller ID Dialer" or something (shorter).
But I don't know how to make that decision without understanding the use case. The ones I've heard so far are:
* Customer has multiple clients they represent and they want the Caller ID to reflect their client on outbound dialing
* Customer has multiple offices and they want the local number to appear for the office they're calling from
Those are the only two use cases I'm aware of. -
Also, once the roll-out is complete, we'd love you to look at it again and provide feedback. If it's worse/better and if there are more improvements possible.
-
I appreciate your comments, and I agree! That is infact one of the reasons we're leaving Confluence - we can't modify the nav bar!
Very shortly (hopefully by end of week) we will be rolling out a new website. The new design has nav links that go to all resources, and the nav bar will be available on almost everything we do. It will hopefully make things much easier to find. That's the goal, anyway. -
What if we create a set of Github folders for this? Someone started such a project that they were calling the Great Book of Kazoo which we're considering including for this very reason. It would use the same strategy - you'd chat on here, but you'd update the permanent docs via Github on, well, Github. That way we get the benefits of versioning, ease-of-use, being able to download it, and we can run it through a script which formats it and makes it look pretty.
Is that not sufficient or is it just too foreign a concept over a Wiki? The reality of the Wiki is we had one before, and people submitted mostly junk, often anonymously, and it required constant work to keep it up to date, had no versioning, and was work for us to maintain the site itself. -
Great question! There is! It's a bit in transition at the moment but you can participate.
We used to use Confluence. The problem we had with confluence was:
* No way to use our own CSS / HTML. While the tool itself lets you do that, they overwrite/force you to import the default themes they have and randomly update them which breaks customization. And no custom JS is allowed, no modifications to the nav bar (so that you can quickly link to other sources), etc. So, yeah, it's a problem.
* No great way to have public/private/paid customer material without super complex users/groups that don't integrate to single sign-on
* Wiki markup was not ideal, a lot of times we want to imbed JS or apps or test tools and we can't easily unless it's a supported plug-in.
* No versioning
* The default TOC format is OK but it's hard to make a reference manual or printable / brandable manual out of it.
* etc.
So, we met about this about 6 months ago and started an endeavor to move documentation into the product itself. Right now, if you go to https://github.com/2600hz/kazoo and while the screen is open, push the letter 't'. Then type "doc". You will get a list of doc folders and locations. If you strictly want API documentation, which I'm guessing is what you want, check out https://github.com/2600hz/kazoo/tree/master/applications/crossbar/doc which contains documentation on each API crossbar supports. Note that not all APIs are available on the shared hosted environment.
Why are these in Github? Why is it better? A bunch of reasons.
1) It supports Markdown format, which is common
2) You can edit things directly on the site and submit them back for inclusion in the docs
3) It's version controlled. The docs on branch 3.22 will be what was programmed/available on 3.22
4) We've built a crawler that takes these files and turns it into a nicer, more polished website (well, work in progress, but pending)
5) You can skin it with custom CSS / HTML later and call it your own!
We will likely eventually expand this out to more then just API documentation, such as including tutorials and other items.
Give it a try. It may be scary looking but it's actually really easy to do.
You can reference James's post on the Google mailing list about the more intricate details of how this works: https://groups.google.com/forum/#!topic/2600hz-dev/qKKrHh0Aznc . -
I'd prefer not to get you psyched about something that's not out of the gate yet. But the idea is that any media that needs to be stored can be stored in an alternate engine.
-
We have that in the works, yes. It's not quite done yet. Trying to find some solutions so that, out-of-the-box, the storage, archival and security solutions are resolved while ALSO integrating with additional service platforms that have interfaces, synchronization, ease-of-use benefits, mobility, etc.
More to come... -
No, I'm saying that if you're using a Fax over HTTPS solution, it probably wasn't invented by Vitelity. You guys keep mentioning them. In reality, you could probably just contact AudioCodes you could buy the same device/service, or use other providers who offer the same box. It's not a Vitelity service, and it's not a Fax ATA. It's a Store-and-Forward solution, too, which is kind of cheating. It's basically an HTTPS version of the T.37 standard (store-and-forward).
Frankly if it's still this critical and in demand, perhaps 2600hz should sign up for the AudioCodes solution and implement it. I'll think about that... -
Hmmmm you're sort-of paraphrasing things I've said here. So for the record, I mentioned that it's dependent on the quality of the circuit, the distance the fax ATA is from our datacenters, the places you try to fax TO and the types of machines involved.
What works for one person doesn't always work for another.
Thus, the path of least resistance to ensure quality is NOT to use the ATAs if you are not willing to gamble. The issue I have with this approach is, at some point, the cost of everyone's labor to try and get a fax ATA + fax machine working is way higher then just going the non-ATA route (whether that be an API, email or an HTTPS Fax device).
I never meant to imply it can't work or that there's a hard rule here. I was trying to state that when it doesn't work, it's near impossible to diagnose and fix in a reasonable amount of time/effort. Thus, you can use it if it works for you, or go the safe route and use something else. -
The problem is that results vary, but everyone wants 100% perfect. The best option is a device that does "fax over HTTP" which is what you all are describing with this Vitelity solution. They don't actually make that device - it's available for resale to resellers. It's likely the one provided by http://www.faxata.com/ if I had to guess. Then they brand it & resell it and/or tie it into their portal.
-
Hi there,
You're both right :-)
https:// works fine. However, some phones (we're narrowing down which ones, but appears to be just Polycoms and only certain firmwares) don't appear to like that we use a wildcard cert (or something about our cert, but we're pretty sure it's because it's a wildcard).
We're in the process of revising our cert so that it's a specific domain name to see if that resolves the issue. Either way, we'll continue to support both methods, so use whichever suits you. -
The software itself had it as a feature at one point, and that code is still there. We could remove it altogether I guess, but I keep hoping a new vendor will come along who is awesome, so I don't want to remove it yet.
-
We have no plans to add this because all the transcription services have been so awful frankly.
-
That one is already in the works. Yes, a diff thread for this one if you wanna go there! And I think that one is thousands of devices, not hundreds, so financially speaking a much better bet!
-
OK, so what is this worth then? It may fit your use case and a few others here, but I doubt everyone will use this. Thus, we'd be spending probably 200-500 hours building this at let's say $75/hour. So it's a $15k-$38k project probably. If I divide that over, let's say, 500 endpoints x 12 months = that's a fee of $6.25 per endpoint to have this feature? Would that be worth it to you?
I'd say if we could get a commit collectively from everyone for 500 endpoints @ 12 months then we could build this. -
If it's just to call extensions between accounts, perhaps that's simpler, but it's going to open a pandora's box including all the items I mentioned above (and again, that's just what I can think of now). We could start down the path but I still feel supporting multiple offices in the same account will be more useful and lucrative for everyone from the start. The other use cases are edge cases.
-
OK, and are you paying attention to how you can't just do that? :-) See all my comments above about all the things that must be considered, both front-end and back-end, to achieve what you just over-simplified...
-
This only covers the GUI and is too simplistic to be secure. That said, pretend we did do that. Your design indicates that for each device/callflow in account A you would create a corresponding callflow in Account B which points to the callflow in account A?
This would imply that:
* A security key or otherwise would need to be introduced that indicates Account A is allowed to view the things in Account B
* Callflows now must pull their dropdowns, every time requested, from two sources
* When the calls are actually processed we still need to make sure the Account ID is allowed to call other said Account ID, so we must pull the security list and then pull the info in the second account
* The built-in / nested "Edit" buttons - how will those work? Will those just break / not be allowed if you try to edit a device/user on a different account?
There's probably more I'm not even thinking of, that's with 5 minutes of thought.
I assure you, if it was as easy as you're stating, someone would have already done this... -
How would such a widget work? I'm less concerned with the GUI and more concerned with how it would work on the back-end.
Decisions such as:
* Security
* Caller ID
* Which accounts can see which other accounts
* Performance on having to scan multiple accounts per BLF query
* Performance on having to scan multiple accounts per call
* Teaching/training the user on how to perform the above security and possibly introduce a key to identify which accounts can access which others, that's configurable
* Handling of errors/issues where both callflows on accounts have the same number configured
* CDRs (What if both accounts have the same Caller IDs or user names? This could get really confusing)
* Billing/rating
* Limits/restrictions across accounts (we have features that limit simultaneously calls, including internal extensions, within an account - how will these work between accounts?)
* Webhooks and other items that don't currently include an Account-ID field, these would now presumably all need to be found and enhanced to have an Account-ID, otherwise you'll get an Owner-ID and/or device ID but no account ID and won't know where it came from?
There's probably more.
Paging to an Amplifier with Hosted VoIP
in Product Discussion
Posted