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
-
-
OK I've now re-read this thread a third time.
I THINK what you're saying is:
* You really need the ability to have a global template/settings that you can push to all phones for more features
* You are OK if those features are limited to what's in the GUI based on my comments about the cost if we just "open a text box" which isn't really acceptable/manageable
Did I get that right? -
Or maybe what you're saying is NOT to do the text box, you just want to be able to copy the existing settings already in the system, controlled by our provisioner?
I'm trying to understand what you've written more. -
I don't understand your response. I posed legitimate questions on how the feature you're requesting would introduce potentially astronomical costs to our firm without some way to manage those costs. I asked for suggestions on how we might handle 4 sample scenarios (which are ones we've actually had before, thus are real concerns).
You responded by acknowledging my concerns.
Then you asked for more features without answering my question? -
How would you solve these issues if we did that:
* Reseller enters some custom text, but it has typos or problems. Reseller calls us on support, claiming it's urgent because they think they did everything properly. Our support rep spends an hour or two combing through features that they know nothing about, trying to figure out what they did wrong (we of course have to also train every support rep now not just on how to use the advanced provisioner, but on how to debug the actual files it generates). If we did this, who pays for the training of our reps and the work it took to find the error you introduced via the file?
* Reseller introduces a setting that is not compatible with our failover/redundancy strategy. Doesn't notice. The system then has a failure and the phones go down. They blame us because the system is supposed to be redundant. We do an investigation and discover that, actually, the phone would have been fine except the particular features they introduced caused the failover not to work. This investigation takes 5 hours. Who pays for this?
* Reseller enters some text for a feature. Then they realize, in a panic, that we've rolled out a new feature that somehow overwrites or conflicts with what they deployed. They want us to revert the change. However, we planned, tested and publicly talked about the change in advance, alerting people it was coming. Now we have people where we had an agreed upon date for a feature to be rolled out who are already using the new feature. Rolling the feature back negatively impacts our ability to release the feature and everyone who was promised it, just for this one reseller. The reseller demands we roll it back anyway. What do we do?
* Reseller forces a firmware upgrade somehow but upgrading the phone via custom fields. The firmware upgrade causes BLF (and only BLF) to break. Reseller doesn't tell us they've done this, or realize it's related, but starts submitting BLF tickets. We trace BLF issues down for days not finding anything, only to finally check the firmware of the phone and realize it differs from the one we deploy and certify. Reseller then tells us they forced the firmware, and we downgrade. BLF starts working. The investigation took 20+ hours. Who pays for this?
There are more edge cases, but this gives some light as to why I don't like this idea. At least with us providing only checkboxes, fields, etc. we respect our hierarchical setups, automatic file generation, security management setups, firmwares, etc. we can avoid people breaking things that are 100% responsibility.
But the responsibility of management of the files (despite the freedom it affords you) gets extremely blurry if we end up picking up the tab for other people's tinkering on a scale of hundreds of clients. We'd basically have to raise our rates to cover this.
We are actually working on converting EVERYONE to per-hour support. That way, we actually WOULD bill if we discovered at the end of an investigation that the root cause was user error on the part of the reseller. That should hopefully solve this, but then people's reaction is "I don't want to get billed if I make a mistake, it's not fair." Sooooo yeahhhh I'd rather be more restrictive and keep people slightly happier. -
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.
-
Yup, I totally get it. Fun times.
They did the last time. We had provisioner working great and then they changed BLF keys to "line keys" or whatever but only in some firmwares. Had to redo the whole thing. -
Great, thanks Yealink for all the advance notice.
*grumble grumble*
Let me think about a way to not just fix this problem but avoid it from ever happening again. We really want a firmware selector tool so you can manage which firmware you push to phones. Perhaps we pair that finally with the ability to just edit flat files and upload them. Then you guys can do whatever you want, but of course it means increased support costs if you screw something up. But since we're moving to 100% per-hour support strategy anyway, I think the risk is minimized to us for exposing that level of functionality, so it would make sense to me to just do it at this point.
Last thing I want to do is make it hard to sell our service so it seems like that may be the best path forward. -
Can you tell me where you're getting your information that vendors are running out of the T46s? I just contacted four different vendors and they have a total collectively of over 200 in stock. What am I missing here, where is the urgency coming from?
The announcement originally pasted in this thread is from 5 days ago... I can't imagine all the old inventory just vanishes in 5 days time and we are expected to support the new firmware and configs with 5 days notice.
I can't tell if this is a "we really want this ASAP because we love OPUS" or a "we actually are screwed and can no longer continue selling phones" issue (there's a difference). -
I'm trying to get ahold of one of the new phones so we can figure out our action plan here. If they've changed the format of the files, it will take us a while to re-test and re-certify the new firmware + config file format. We have to test that ALL functions on the phone work as expect, such as BLF, parking, NAPTR/SRV failover, provisioning via SmartPBX, provisioning via advanced provisioner, network settings, VLAN, line keys, presence/speed dial/BLF programming, etc.
I would expect this will take some time.
There are still a bunch of vendors who are selling T46G's though so I don't think this problem is quite as acute as you're describing. I suspect we have a month or two here before this becomes a huge problem. -
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.
Account is running out of credit
in Product Discussion
Posted