rdg154 Posted August 16, 2019 Report Posted August 16, 2019 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?
Logicwrath Posted August 16, 2019 Report Posted August 16, 2019 I suspect you would have to use a Shoutcast server to do that and treat it like an Internet radio station.
FASTDEVICE Posted August 16, 2019 Report Posted August 16, 2019 I hear that's on their backlog but currently you can use a shoutcast server. It provides looping and longer media runs. I have shoutcast servers if you are interested.
FASTDEVICE Posted August 16, 2019 Report Posted August 16, 2019 (edited) Here is a free link for testing shoutcast Use this link from your browserhttp://live.emusiconhold.com Use this link for testing in Monstershout://live.emusiconhold.com Edited August 16, 2019 by FASTDEVICE (see edit history)
Administrators Darren Schreiber Posted August 16, 2019 Administrators Report Posted August 16, 2019 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.
Karl Stallknecht Posted August 16, 2019 Report Posted August 16, 2019 Ditto on the SHOUTcast integration. Our clients love it since we can setup all sorts of custom stuff for them, or just play a local radio station. Just keep in mind though that if the SHOUTcast server is down when you try to place the call on hold or park, the call will be dropped.
esoare Posted August 16, 2019 Report Posted August 16, 2019 4 hours ago, Karl Stallknecht said: Ditto on the SHOUTcast integration. Our clients love it since we can setup all sorts of custom stuff for them, or just play a local radio station. Just keep in mind though that if the SHOUTcast server is down when you try to place the call on hold or park, the call will be dropped. Boooo!!! Not your fault @Karl Stallknecht but wanted to state my dislike for that particular "non-feature". That's why I don't use the shoutcast.... esoare
Karl Stallknecht Posted August 16, 2019 Report Posted August 16, 2019 43 minutes ago, esoare said: Boooo!!! Not your fault @Karl Stallknecht but wanted to state my dislike for that particular "non-feature". That's why I don't use the shoutcast.... esoare Make sure you use a SHOUTcast server that doesn't go down 🙂
rdg154 Posted August 16, 2019 Author Report Posted August 16, 2019 Shoutcast is a not a serious option as calls are dropped if the stream fails, that deficiency must be resolved first.
Karl Stallknecht Posted August 16, 2019 Report Posted August 16, 2019 4 minutes ago, rdg154 said: Shoutcast is a not a serious option as calls are dropped if the stream fails, that deficiency must be resolved first. We have never had an issue with this before. Just use a reliable SHOUTcast server.
esoare Posted August 16, 2019 Report Posted August 16, 2019 Just now, Karl Stallknecht said: We have never had an issue with this before. Just use a reliable SHOUTcast server. 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.
Administrators Darren Schreiber Posted August 16, 2019 Administrators Report Posted August 16, 2019 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.
FASTDEVICE Posted August 16, 2019 Report Posted August 16, 2019 @Darren Schreiber I agree with you ** mostly ** the issue with a Shoutcast stream is, a load balancer doesn't solve the issue entirely. Any interruption, regardless of the transition time causes the fault. With failover, the next set of callers will hear the stream but the current ones may or may not be lost. Therefore, there is no 100% way to be bulletproof using a streaming service. @esoare there is failover for Pivot.
rdg154 Posted August 17, 2019 Author Report Posted August 17, 2019 Load balancers can fail - the best way would be when a stream stops - just play silence or failover to default music file.
Rick Guyton Posted August 17, 2019 Report Posted August 17, 2019 17 hours ago, FASTDEVICE said: @esoare there is failover for Pivot. Oh, really? How do you do that @FASTDEVICE? There's some things I'd like to do with pivot, but wont do it because I thought that wasn't the case and didn't want to risk it. I generally only use it now where it would be "acceptable" for the it to go down. I don't have a horse in this race, but I do sure wish Kazoo would allow fail over to an internal resources for this stuff. Much the same way that voicemails will deposit into VM boxes if vm-to-email fails. I sure wish pivot could fail over to a default call flow, and for my friends who use it, shoutcast could just play silence instead of hanging up. 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...
Administrators Darren Schreiber Posted August 17, 2019 Administrators Report Posted August 17, 2019 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.
Rick Guyton Posted August 17, 2019 Report Posted August 17, 2019 9 minutes ago, Darren Schreiber said: 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. Three thoughts. First, yea that is 10,000x more difficult than I think most would think and I appreciate the time to explain why it isn't so. Second, it's nice to hear a viable offer to the solution, I could care less personally about the shoutcast, so I'm not in. But, to put myself in those shoes, if it were the same cost for a resolution to the pivot issue, I would be. Third, on #4 I think that decision should be left to those funding it if it drastically decreases the cost...
Administrators Darren Schreiber Posted August 17, 2019 Administrators Report Posted August 17, 2019 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.
esoare Posted August 17, 2019 Report Posted August 17, 2019 19 hours ago, Darren Schreiber said: 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. 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. @Darren Schreiber Thank you for the clarification of what is Kazoo (Internals) and 3rd party connections. 51 minutes ago, Darren Schreiber said: 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 I wouldn't mind putting my money where my mouth is. That type of commitment would be fine with me. 1 out of 10 re sellers on board. I especially like that it stops after the development costs are paid for. esoare p.s. I understand it might be napkin math.
Administrators Darren Schreiber Posted August 17, 2019 Administrators Report Posted August 17, 2019 I'd be down setting up some sort of system to fund these requests. Let me see what I can come up with.
Karl Stallknecht Posted August 18, 2019 Report Posted August 18, 2019 21 hours ago, Darren Schreiber said: I'd be down setting up some sort of system to fund these requests. Let me see what I can come up with. This particular request isn't at the top of my list...I think the approach of a random start point would be money better spent. That being said...I would LOVE having this type of approach for other feature requests that are way higher up on my priority list. Some sort of feature request system, but when voting you agree to commit $x/month if it reaches its goal of y resellers. I realize there are legal challenges of enforcing this and what happens if people lose interest, but I think this could be addressed by making people over commit and then lowering the cost if everyone chips in like they agreed - half a feature request system and half a crowd funding system.
martin Posted December 8, 2019 Report Posted December 8, 2019 On 8/17/2019 at 7:15 PM, Darren Schreiber said: 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. i think we spoke about this a few years ago, maybe create a infrastructure for gathering finances for these kind of developments, and perhaps other requests? Its probably utopia to get many people to chip in, but then at least it clear. Gofundme style I would pay for what i want, but dont have a big budget, its not even a business yet. But chippping in for interesting development would be smth i would do On 8/17/2019 at 10:21 PM, Darren Schreiber said: I'd be down setting up some sort of system to fund these requests. Let me see what I can come up with. oh missed that)
Recommended Posts