Darren Schreiber

This is what I end up with: And it appears to work perfectly? I will note that when I block the IP, it takes about 30 seconds for the phone to "give up" trying to reach the primary IP and then switch to the secondary. Also, ignore the invalid port numbers above, they're not even used (I was trying to test that, and the test passed)

Why would it not be searchable? Not sure I understand.

Yeah, we're all about getting the help into the system. Past experience, however, has been filled with a LOT of sloppy edits, so we've been hunting for a system that has approval controls and/or community moderators and such. That's why it's a non-trivial problem. I think GitHub solves this for us via the pull request mechanism.

The provisioner should no longer be setting a second proxy. This is by design. You should be using NAPTR/SRV on p3.zswitch.net . This is NOT a bug and you should NOT put in a second proxy. You break things if you do that.

There is a way to upload private media files (though they are then private) I believe. Then, you can download the voicemail box I believe and add a message to each one and have the media ID attached. You have to upload the file for each mailbox, but that could work.

I am almost positive that the new branding app has variables, and one of them is now the mailbox number, so you can customize the voicemail to email notices. But I could be wrong. We discussed it at one point.

Oh also, I agree on the HTTPS though we were trying to roll our own, but I've been side-tracked.

While the old wiki is getting outdated because we're trying to move the data, the fax settings are still good there for the Grandstream. You can check it.

OK let me ask around internally to see what's up.

Yeah, you're right, it's the whole amplifier and all I believe. So you are right, the SNOM solution would be better if they want to keep the old PA.

Oh you are so right, and I am so sorry! Yes, that is exactly our plan. In fact, the only reason we bought THIS CURRENT system that you're on was for the forums + credit/karma point system they had. That was our original goal, was to use this system to track participation points. Unfortunately it doesn't let you "spend" them and I can't manually modify them or whatever. But yeah our thoughts were: - High point values for Erlang code contributions. - Medium point values for Bug Fixes, Scripts (like Bash helpers, etc.), Tutorial Contributions, Documentation Contributions - Low point values for correcting typos, helping us organize meet-ups/events/etc, correctly answering people's questions in forums, etc. We kind of want to model this off ExpertsExchange or StackOverflow as a concept.

I like the user portal idea. These are great ideas. Are you guys filing these in tickets.2600hz.com? Each time we get to a planning phase for a particular portion of the product (i.e. "the next 3 weeks we're doing faxing!") we do a search in JIRA for all things with the word "fax" for example. So while the tickets may seem ignored, they quickly get done in bulk when we touch a feature, so this is worth your time to do.

I didn't fully answer this question but since I just saw a code commit for the fix to it, I'll come back here. The "Typo" is actually because: 1) We originally hard-coded https://p3.zswitch.net 2) Someone complained that wasn't white-labeled 3) We changed it to try and dynamically generate and also show http:// or https:// depending on something (I forget) (which was kind of dumb) 4) The branding is missing still so now the domain is just gone *sigh* We'll try again and get the UI updated to have the brand in there, but you'll need to explicitly set the brand in the branding app I think (or it uses your base domain, I don't remember exactly). I'll try to remember to update this once we roll the fix.

Even if we built this out, it would only work if every DID had an IVR first before forwarding. Is that acceptable for your design?

When did you last try this? This was patched, at customers request (might have even been you?) last month I believe. If you can point me to a callflow (feel free to send it in as a support ticket) we'll take a peak.

Are you willing to do this via APIs?

The danger with the multicast suggestion is all phones must be on the same network and usually same manufacturer. Otherwise, yes, this is a VoIP-wide issue. If the system is not on-prem then you basically have to dump users into a conference bridge and it's slow. We might be able to speed it up some, but otherwise the Multi-cast idea is good. I'll talk to Peter Lau about exposing this in Advanced Provisioner. Good idea, although people may not "Get it" so we have to watch what we offer.

We are working on doing this w/ WebSockets but if there are existing versions, that will definitely be the faster route to go. Would anyone be willing to sell alternative solutions via our app store for this tool? We get asked it a lot. I want to be sure the implementation is not doing naughty things to our system, though.

Since Peter Lau (provisioner guy) is finally getting through the bugs in provisioner (I think we're down to one known one), and he needs to add ATAs, I think we will do the copy phone thing but AFTER those two items. Sound good? I'll triple check with everyone to see if that is a good plan. We're also considering a "bulk upload" tool where you can upload a list of names, extensions, MAC addresses, make/model and it adds the users and auto-sets up the account basically. I will consider allowing the name of the template to be applied to the spreadsheet you upload, and then you could upload a CSV and the phones would even be programmed based on the templates maybe? Or this is too hard and Peter will kill me? Just tossing out ideas here.

I believe we have fixed this in the new provisioner release (it's not rolled yet). Perhaps you'd test this with us?

What do you mean by "Label Set"?

So you're aware, we are working on being able to store files (all files - voicemails, call recordings, etc. - you choose which ones) on a per-account basis to outside services. Yesterday I got my first PROTOTYPE DEMO (to be clear, NOT RELEASED!) of it working with Google Drive. We are considering Dropbox and Amazon as well. We are discussing ways to link the links for Dropbox/Google Drive/etc. into the call logs in the SmartPBX Call Logs section so customers can easily login and get the data. Do people also want these in the user portal? We don't have a way to do it per-user so I'm thinking no... So the admin of the office/account would be the one to retrieve recordings when they're needed?

So Advanced Provisioner is a paid service (for a slew of reasons, if you're interested I'll write them up but I'm swamped ATM so just trust me if you will). You have to sign up for it. Please let your account rep know if you want this.

Hmmmm there was a permissions issue but I thought we fixed this. Any chance you can video this or provide every step exactly on doing this? I thought we fixed this already.

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.