Darren Schreiber

Also could you please get a real quote from Fonality? Because your initial post is misleading. That is not an all-inclusive fee.

I don't have time ATM to look at Fonality as an example but if I had to split up basic and advanced, I'd say: Basic: - Queues - Hold Music - No Reports - Web Dashboard - Web & Phone Login/Logout Advanced: - Reports - Eavesdrop/whisper/barge - Phone BLF for agent status, login, logout - 0-out during queue - Announce place in queue - <other ideas> thoughts? Then maybe Basic is $99 or $199 to enable and a lower per-queue fee or something?

Is the main issue just the base fee? Seems like that is the benefit you would gain here.

Also if you switch to a per-device fee and pay for the minutes yourself, these numbers are probably much lower. That's another option.

@FastDevice: I'm going to give them a call and find out more, but I bet $$$ that there's extra fees. Presumably you're also comparing this to our pricing with call recording, faxing, support, yes? Did you look at their pricing in full? According to it, if you sign up for $24.99/seat x 5 seats with Fonality and include faxing, call recording and support for each user, it's $56.99/mo. So this is just not an apples to apples comparison in any way unless you're OK with me also removing call recording, faxing and support from your account? I doubt it. @Rick & @FastDevice On a higher level, we don't really want to be building and supporting large $1,000,000 applications and then have resellers sell 2 of them to 10 people. That's not going to work. If the numbers have too high of sticker shock I'm open to other things, like raising the per-device fee in general and lowering the base fee on the apps. Other ideas welcome. But giving it to ONE client and then trying to make a living off of it is a bit outrageous of an expectation. That's like me expecting Microsoft to fund my retirement for selling one copy of Microsoft Exchange. By my math, if you sell queues to anyone who has a support and sales team (two queues) with 10 seats where 6 people are signed up, and you have ten such customers, you have 100 seats with 60 of them being agents. At $12.99/user plus $3/agent plus the queue costs and base fee, that's: $1,299/mo user + $180/mo agents + $800/mo queues + $499/mo base = $2,778 / 100 seats = $27.78/seat. At first glance that's higher than Fonality based on this thread, BUT, they are charging for support, faxing, etc. You can't market this for $39.99/seat which includes queues, call recording, and faxing and stay competitive? It's basically the same thing they're offering (cheaper potentially based on my high math above). You still make $12.21/seat x 100 seats = $1,221/month. If you expand to 200 seats on the same math: $2,598/mo user + $360/mo agents + $1600/mo queues + $499/mo base = $5,057 / 200 seats = $25.29/seat. Perhaps we lower the per agent fee or queue fee. I could look at that. But I don't think the numbers are as far off as you guys are implying.

What is the full deal all-in? A lot of times these published prices do not include all the details. Do you have to buy phones from them? Contract length minimum? What do they pay their resellers? What features are included in basic and advanced? etc. etc. We get this comparison garbage all the time with RingCentral - people telling us RingCentral is $19.99/seat when it's just not true once you do all the math. So, what's the full math? Where is this advertisement?

How about hooking up WebHooks to a small script that emails the customer each time a call is missed? You can inspect the hangup cause to see if it was LOSE_RACE (means someone else answered) or ORIGINATOR_CANCEL meaning nobody answered.

There is an issue where, at the first of the month, the system erroneously sends those because the balance hasn't been carried over from the previous month to the new month. Please ignore those if they are on the 1st of the month. They should not have any impact.

So we have in the hopper an item where, when submitting a port request, the number is pre-added to the account. Maybe we can allow you to pre-add the number this way, too, even if the paperwork isn't completed. Would that work?

"One feature that Kazoo has that Monster doesn't is letting you free-form the caller ID at the account level." > I'll check into how we can do this. Historically, the problem has been that people are setting this incorrectly, or to numbers they don't own, or worse, to toll-free numbers (which is a big no-no for billing purposes on outbound calls). I'll see what we can do here. We've had the request from partners to do the opposite ironically, not allow this. "Will the Kazoo shutdown affect existing devices that have not been provisioned with the new provisioner yet?" > In theory, the phones will just keep trying to pull a new config and never get one, so they'll continue using the old one. We're tempted to deploy something that lets you, on a phone by phone basis, point the phone itself on it's next check-in to the new provisioner so that you don't have to gain access to the phones.

All Peerless items should now be redundant. HOWEVER, we're working on rolling out Geo-IP based routing with them and all our other carriers which further enhances this, so I was waiting until that was done for a full update.

Josh, where are you looking?

Weird... This is working on some accounts.

Hi everyone,       Just thought I'd post this for anyone struggling with it.       Obviously there were lots of changes with the upgrade to 4.0, and a bunch of stuff didn't work the same or broke. I think we've worked through most broken items and tickets at this point.        HOWEVER, a lot of things were ironically FIXED PROPERLY but had a side effect of exposing other defects.        ONE ITEM IN PARTICULAR we uncovered today that I thought I would share here, because we can't actually "fix" it for you (you have to do it), is for those of you with Grandstream phones. MODELS: GXP2100/2110/2120/2124/1450/1400/1405/1160/1165/1100/1105        We now properly update Caller ID in many scenarios where we previously did not. This requires our switch to send an UPDATE packet to your phone. Grandstreams erroneously expect an ACK after the OK for the UPDATE here, which they shouldn't. If they don't get one, they hang up after 20-30 seconds.       So basically, the noticeable symptom to your user is that when they make phone calls, they last 20-30 seconds and then get disconnected.       Grandstream fixed this bug in 1.0.6.7 as noted here http://firmware.grandstream.com/Release_Note_GXP116x_GXP14xx_1.0.8.9.pdf  . But some of you are running 1.0.5.58 or earlier. To be fair, those firmwares are REALLY old (May 2014) so you should hopefully NOT be on these firmwares and running something much more recent. But nonetheless, you will now have serious issues if you are not on 1.0.6.7 or higher.       Please update the firmware on your Grandstream phones. Despite not formally supporting them, they should work, and this issue is resolved with the firmware update.

The public IP will start being shown as of Friday night. Posting a maintenance notice now.

I'm checking on this.

If I had to toss out my personal favorite (but you MUST configure NOT to do load balancing, only failover), I'm a huge fan of Cisco RV042 for small office (10 people or less) Cisco RV082 for larger office (up to 100 people usually) You MUST use the latest firmware and change the UDP timeout to be at least 60 seconds higher than the longest register time on the phones. You MUST also set the router to NOT load balance. But what we do is setup the phones on a specific VLAN, which you can then add manual routes to "pin" to a specific WAN interface. Then your internet traffic is "bonded" with failover but your VoIP traffic has a primary/secondary route, no bonding, and fails over, too. Then put two internet connections at the client's site (using different media - like Cable + DSL), then boom, done, failover + faster internet. Yaaay. YMMV

Maintenance was to restore that, but we decided in the last minute that we did not want to risk people complaining about BLFs. So we did half the maintenance (the fields in the GUI now show up) and we will do the other half on Friday, which is the Kamailio restart portion. RECOVERY_ON_TIMER_EXPIRE means we're unable to make it past the firewall/router on the remote side. That would have nothing to do with this maintenance. Try restarting the firewall/router on-site. Sometimes if there is an internet snafu the router will dismiss our host as down and perceive phone's constant attempts at outbound UDP requests as a sort-of DoS attack and drop them before they even leave the network. If a restart DOES work consider, long-term, picking a new firewall/router or turning off some of the firewall features.

Hi there,      So this is being handled with fairly high priority at this point on our team via your support ticket FYI. The problem is that ironically you may have been exploiting a bug, and we didn't understand that. So we're trying to sort that out. PREPEND is supposed to PRE-PEND or add to the beginning a number, and leave the rest of the number intact. This allows you to, say, add the digit 1 or 2 to a phone number to identify if the call is a work or personal call, or add "Sales" to the Caller ID Name if it's a VOIP call. But keep the rest intact. This is allowed by most carriers even though the number is more than 11 digits. From what I gather, it sounds like this was actually somehow being used in a way where you were stripping stuff off a capture group and maybe using a bug which didn't properly add the remainder of the number back. We're trying to sort out how to not continue having a bug while also supporting your use case. We would hate to revert a legitimate bugfix just to support the one use case which is actually a bug. I think Karl and Hessam are engaged heavily on this right now. We will get this working again, somehow, hopefully with minor need or no need to modify your callflows.

That's not my intent. The intent is the DEFAULT filter dates when you first bring up the screen should be one day. You are welcome to expand them.

Funny, I ran into this with another client this week. The issue is indeed that the views take too long to load on larger accounts. I will file a ticket to reduce the default to show today only. This is ironically what ThinQ and Flowroute do (and limit searches to a 24 hour period for example).

To be clear, the recreating was a workaround if you just needed to do this now, before a permanent fix is figured out.

Let me take a look. Email a support ticket in with the account and group you're editing and how I can recreate it.

Well the issue ironically is that the old callflows have invalid data in them. We fixed the validation for that, but now the hidden values in the old callflows won't save (which is technically correct). If you rebuild the callflow, it will work. We are looking into some JS that will "cover up" the invalid data if you try to re-save it and just "clean" it "as you go" basically. But for now, rebuilding the callflow SHOULD work. Let me know if that matches your findings. To be clear, the callflows still work fine, so no need to re-save them if you're not actually working on them.

There has, for a long time apparently, been an erroneous time flag saved in the STOP call recording objects, which the schemas have now actually been fixed for. BUT when we fixed the schema (properly ironically) it made it so the old elements are failing. At least this is what we believe the issue to be. In the call flow you are editing, is there a start AND a stop element? If so, can you try deleting the stop element and then re-adding it?