Darren Schreiber

I'd be down setting up some sort of system to fund these requests. Let me see what I can come up with.

BTW, I should be clear on this. When we don't change stuff quickly that we know you guys want, it's always based on math. Cost analysis basically. Dealing with this stream issue is likely $12-24k. Having the streams we already play simply start in a random location (moving the file pointer after fetching the file) is probably like a two hour change, and avoids any possibility of an "outage" of a remote server, ultimately achieving the experience people are looking for. So, back to the OP, yeah, we've already discussed and plan to add the ability to start playback from a random spot when on hold. It achieves the experience with the lowest cost and complexity.

There are multiple scenarios here: 1) Shoutcast stream doesn't stream at all. Right now when we start playback of an audio file we wait for it to start which is confirmed by various events. These events never fire, so code doesn't advance. 2) FreeSWITCH itself is actually where the main issue is - it's default behavior is to either advance or hangup, depending on the situation, when you ask it to do something invalid like play a non-working stream. In addition, it's behavior halfway through a stream when a connection closes is to advance, which triggers events that cause us to think the call should advance, further gumming up the works. 3) Neither FreeSWITCH nor Kazoo have a concept of an alternate stream to play (even silence is a stream) so we'd have to somehow update the code to support that 4) You would likely have to make the failback strategy configurable, thus a GUI component. Not everyone will accept just "silence" as a failover strategy and will complain just as loudly here when their callers suddenly hear silence that it's broken/not usable. All the above would of course have to be tested. I suspect it'd be about 40-120 hours of work (one to three weeks of hacking on this basically), with knowledge required being a mix of C code and Erlang. Then about 20 hours to test each scenario. You also need to get the C code changes committed upstream to FS since we keep in sync with their branch now, so there's about 10-20 hours of "management" in there. So the entire thing is probably 80-200 hours. Assume $150/hour minimum for this skillset, it's a $12,000 - $24,000 request. One way to fund this is we could get upfront commitments for people who want to use this. Let's say 10 resellers committed to pay for it for a year at $100/person/month, or up to two years to cover the higher end of the estimate. That would cover the cost.

Kazoo focuses on making sure the INTERNALs of Kazoo are heavily redundant. Cross-server, cross-zone, etc. That's already a lot of work. (Like an insanely high amount of work, way more than people seem to realize). Kazoo DOES NOT focus on external resources being redundant - we assume they already are, and you choose vendors and services that are (why should Kazoo engineers do double duty to cover the bu**s of other software providers? It's 2x the work for us! Pick good services to utilize!). The only real exception is carriers, which we expect to go down periodically in the course of business due to how complex carrier routing is. Your statement "it just seems to go against the principles of Kazoo" is not accurate, there is only such a principle for internal Kazoo component design. For external services, take for example: * If you link Webhooks to an external service and it's down, the Webhooks do not work and do not queue/retry for a long period of time. * If you link call recordings to an external service and it's down, the recordings do not requeue for later, they're just gone. * If you link fax storage to an external store and it's down, the files are gone. The complexity on retries, and dealing with faking events/moving forward with bogus files/sounds, bypassing errors, queueing retries in memory vs. disk, dealing with overloaded retry queues, etc. is very high. To keep costs low, we ask you to pick external services who hold themselves to the same standards we do for our INTERNAL software. If you don't want to do that, that's fine, but realize that there is a financial burden to then make us do the work to handle the failover on BEHALF OF another service. Thus, we would ask for you to fund for/pay for that work. But of course, the simpler/cheaper strategy is to just find a reliable provider, and roll out your own monitoring of that provider so you can respond (if necessary) when that provider is down. In this Shoutcast debacle, most of you seem to trust Amazon. So, setup load balancing on Amazon using their load balancer service. Have it ping, and utilize, your favorite streaming Shoutcast server. If that server is down, have it failover to a file or an alternate service. Problem solved. For like $20. Way cheaper than we could ever solve it.

We are working on a randomize feature so the playback will start at a random position. This avoids dependencies on third-party links that can break, but that is also an option as well. Either one should solve this.

There was a JS error that is preventing the list from loading. There is a patch rolling for that tonight.

This is not correct. Provisioner is working. As noted in your ticket to support, this seems to be isolated to some issue possibly related to Polycoms and you downgrading the firmware. Provisioner is not down. Your comments have caused some FUD in the community, please be careful with any unproven assumptions.

Checking into this!

This was already reverted in the latest build - please check it.

Yup, no worries. Your complaints about being really sure account issues don't break your account were heard. We're a bit behind on releasing the additional features to make it so you can charge a card first before utilizing your balance and charge a few days early, as you know. I'm hoping we get that wrapped up next week in time for April (and then I don't have to run this manually anymore - my incentive!)

Sorry about that, I'm running billing now manually. I have still been doing it manually since it rolled out just to check it every month. I have also been giving people complimentary credit when they are below their balance until the features I promised are rolled out (hence why I do it manually). Your clients are NOT impacted.

If you just add a callflow in advanced callflow of extension 0, it will also allow you to route it to whatever you want.

Actually, it should not have charged your CC today. I'll check on that. We are a bit behind schedule. However, if it did already charge you, if your bill date is first of month, I can leave that as-is if you like. Tonight you'll get an email on your pro-rated additions from last month being applied to this month. As for not seeing the other options, this was discussed this on the previous webinar. I like and agree with the suggestion to "pre-bill" but the suggestion came in too late after we had completed most of the code, so for this month, we're simply not turning off accounts for not paying on the 1st - we'll just manually notify you. We'll then work to implement that feature and it should be on next month.

The Yealink phones by default allow us to grab the call. For the Polycoms you are correct, more needs to be done (such as above) to make it work. We could probably add the above to the default provisioning if people like it.

Don't think so because hold is handled by the handset itself.

Yup, I think you have a valid point. I think we should do both things.

Also, we were debating allowing you to add a backup credit card.

It's not possible to allow the account to go negative with a period to cure. I like your #2 suggestion. What we could maybe do is pre-charge your credit card a few days before the actual billing date under the assumption that you won't increase services very much between the pre-bill date and the actual bill date. Or perhaps allow you to set the date that the system will try to add funds to your account in anticipation of covering the next month's charges. This would achieve the same effect as allowing you a few days to correct any billing issues prior to the amount becoming due. Would that work?

@Rick Guyton I think your response is more on a chronic issue, where as Travis's issue is that suddenly today all of clients started complaining at the same time. From our side, we saw 100% packet loss to his customers from ORD. I don't think your issue is the same in AZ frankly. The symptoms and timeframes don't match.

An update on this. This morning we received this complaint (posted by the OP who started this post). We can replicate 100% packet loss to some of their clients over Cogent but everything works OK over Level3. Around 11am PT we tried a workaround to route to (roughly) their block of IPs via Level3 only, but it seems to have caused issues with OTHER clients, so we've undone that change as of 1pm PT today. At this point: * If you had call quality complaints between 11am and 1pm PT (roughly), they are probably related to the workaround we attempted for the poster of the original topic here, and likely are resolved. * The original issue resolved by the poster of this topic is still ongoing but appears isolated to their customers for some reason. We are still trying to determine why. The packets make it to the provider (Suddenlink) but apparently have heavy packet loss past entry into Suddenlink. So, to be clear: Tuly, your issue is probably already fixed. Travis, your issue is probably still a peering issue at Suddenlink. We're looking for workarounds to avoid this but the fastest/easiest way to resolve this is likely to change the DIDs and proxies to use SJC instead. We believe this issue is regional to you.

Yup. The service is referred to as Next Generation 911 and we've been working with bandwidth to get this implemented. It's in progress but actually getting it turned on is non-trivial with them atm. We'll be sure to announce once this is available!

Customer calls their own numbers. When voicemail picks up, push * to login. You can also make a custom callflow with a secret extension number or phone number that routes to the voicemail system. But that's not required.

Is this your own install? If the pdf2tiff program is not installed, it won't convert to PDF.

Can you be more specific?

Enabled is indeed an admin function for controlling login/logout but I think it makes sense to have it also impact whether the devices ring. Feel free to file that as an enhancement request at https://tickets.2600hz.com/