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
-
-
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.
-
9 minutes ago, Rick Guyton said:
At my own peril, how hard is it to catch any exception in the Shoutcast code block and simply play silence? I honestly don't know, one of these days I'll pick up erlang...
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.
-
19 hours ago, esoare said:
It just seems to go against the principles of Kazoo though....I guess by reliable Shoutcast server, there is potential for Two High availability servers? But if the connection goes down...
In an Ideal world, Kazoo could try for a Shoutcast Stream, and use 2nd Shoutcast/OR local MP3 as a backup Music source... @Darren Schreiber Just my two sents.
P.s. not trying to stir trouble, just stating what would make me feel Super Comfortable... It's kinda the same thing with Pivot Servers, having a backup request if the first server isn't reached would be ideal. I degress especially on the Pivot Server.
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.
-
2 hours ago, rdg154 said:
Many of our clients do not like that the on-hold music starts at the beginning each time - is there anyway to have this music start in the middle of the file at different points randomly?
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
AWESOME!
-
5 hours ago, esoare said:
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.
-
Video is exclusively via FreeSWITCH and it just proxies it. Since FS hasn't been upgraded for several months I suspect you should investigate changes on the client side instead.
-
Yep. We are in testing with transcoding services and full video support but it's not quite there yet. Time/resource constraints mostly.
-
Errr wait that sounds like a bug for sure, have you guys reported that? It should provision properly on the first go (as long as you rebooted it).
-
Thanks for your reply. This is helpful. So you are setting the DSS Keys in Advanced Provisioner. When you hit save, do you restart the phones?
We do not currently grab the logs from each phone so I can't do that, but you can locally login to the phone's GUI to try and see it's logs. But you do have to restart the phone after you make a change (you can do that from within advanced provisioner).
Also if you make any changes locally on the phone itself, the configs we send will be ignored for those features.
-
When you say "I am unable to make any changes" to you have more data on that? Screenshots? Error messages?
Is this on 2600Hz hosted?
-
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!)
-
30 minutes ago, esoare said:
Did you get billed on the 1st guys?
I didn't...
Wondering what's going on...
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.
-
I will have to triple check but I believed Auto-Login was whether or not you have to enter your mailbox #, and require pin was whether or not you needed to enter your password. But I could be wrong.
You can not assign a mailbox to multiple users, so in that case, I believe they all have to use a PIN.
-
Also, to be clear, the "Require PIN" option I believe means "if the owner of this mailbox tries to check the mailbox from a phone we know is theirs, i.e. the phone is assigned to them, don't require them to enter a PIN"
So if you want a user to be able to login, without a PIN, to two mailboxes, assign both mailboxes to that same user. Of course this also impacts MWI so now the MWI light means one of the two mailboxes might have messages.
-
So I looked at some call logs from your account where you're testing this. The system is playing that prompt because the PIN is blank:
Oct 19 03:02:08 apps001.ord.XXXX 2600hz[10626]: |XXXX|cf_voicemail:259 (<0.197.1521>) attempted to sign into a mailbox with no pin
So, yeah, make sure there's a PIN at least set on the mailbox. It's a security issue, actually, that another user on this forum discovered when he accidentally cleared all the pins out and it had unexpected behavior.
-
Also, do NOT leave the pin number blank!
-
Hmmmm I wasn't aware there was a way to restrict which person can login to which mailbox which is why I didn't think that could be it, but let me take another look.
-
"But it's telling me "I'm sorry your mailbox is not configured to allow access from this phone""
I believe this message means the mailbox has not been setup yet. I don't think it's related to the PIN settings.
Cubicle vs ACDC?
in PSTN, Software, and Services
Posted
ACDC is an old, unsupported call center module that doesn't work across federated zones and now actually has less features than Qubicle. Qubicle is one of the few paid products 2600Hz has to try and support/fund the overall project. Some folks are still attempting to maintain ACDC though so I believe it does work.
The two are not intended to be compatible with each other and formal inclusion of ACDC at all is going to be dropped in 5.x.
We would recommend integrating with Qubicle and it's event/feature set.