Darren Schreiber

LOL, isn't it though? The previous FCC chairman had a mandate that all carriers be able to start passing reliable Caller ID info between each other for this very reason, so spoofing stops. But the new FCC chairman is likely to nix that requirement now (Verizon and one other company, forget who, just re-petitioned to try to remove the requirement to upgrade their equipment to support this feature). So it will stay messy for a while.

There are limits in any system on packet sizes and memory buffers. Engineers sometimes code things assuming they'll only ever get so big. Sometimes they'll pick a number like 1024 for the number of bytes that can exist in a string. Well, if you call a phone in our system, potentially it creates this string: bridge {caller_id=X,caller_id_name=Y}sofia/profile/sipint...;some_setting=a&some_setting=b OK, that's for one person. Now you have two people, well, it doubles in length: bridge {caller_id=X,caller_id_name=Y}sofia/profile/sipint...;some_setting=a&some_setting=b, {caller_id=X,caller_id_name=Y}sofia/profile/sipint...;some_setting=a&some_setting=b Well, when you get to 100, maybe you now exceed 1024 characters and something breaks. It's impossible to unravel every single line of code an engineer has ever written to see if they have made an assumption like this basically, hence why they become "bugs" :-) It's something an engineer never thought someone would do, but then someone does it.

Got it. This is awesome feedback. Thanks. I'll pass it along!

There is a GUI component for this and I'm debating having a Monster app for this. The dream was to allow people to subscribe to a public list of telemarketers, too, and download updates to it regularly to block bogus Caller IDs. That idea, however, turns out to be flawed. A lot of telemarketers are now spoofing their Caller ID with numbers they don't own that belong to other people. Which means we'd accidentally block some poor soul out there. Kind of a big problem if you ask me but not a good solution to it.

I think we should add this to the GUI for configuration. But, question - do people not like the default? What are your clients telling you about this?

Our very first customer in NYC is still with us. They have 32 phones on a ring group when you call the main number. It was hell on earth to get that working in 2008 hehe - the bridge string in FreeSWITCH was HUGE because there were different settings on each phone. But we eventually figured it out. Since then, it's worked pretty flawlessly. And a lot of other people do it, too. Of course, I think 50 is probably the largest group I know of. If you put 100 or 200 in a group we'll probably hit some new problem we haven't seen before. Sooo I'd call 50 the max I know of :-) but larger might work OK too.

I was talking to Tuly offline here. Is it acceptable to just get a notice if someone hangs up if they've reached voicemail but don't leave a message?

Awesome! We look forward to integrating it into the open source product! Can't wait to see it.

Sorry, it was in a support ticket from a customer, which I thought was you? Am I wrong?

We answered some Pivot questions for you so you could test this, and you seemed satisfied with the answer. Did you ever get this working? It's a really neat use case. I'd love to know more.

Which parameters do you want added to the GUI?

Which parameters do you want added to the GUI?

The channel destroys will indeed be returned for each leg, as you've discovered. The CDRs are de-duped and we're working on different ways to pull CDRs because actually when people say CDR they mean 3 different things. More to come on that but the just released interaction IDs are the first start.

@Anthony the call queues item should be resolved now, it is available to you for testing at least. Please let us know your feedback.

Hi guys,       You will start receiving more invites to sign up. Wanted to make sure it was not lost that we're working through this list.

Thank you all for your feedback on this thread. I really do appreciate it and I will take all your requests under consideration.

I will look at what other FOSS solutions provide and get back to you on this. I can't provide a timeline or anything on what features. I get the message on what you want now (I think).

You'd still have the star-codes to login/logout.

OK, works for me. Let me talk to Mark about removing the dashboard altogether, BLF light status for agent login/logout (since this is costly to us to maintain anyway), custom hold music, the works. I'll see what it would take to make a stupidly dumbed down version of what we've built. So then you'll have two options. And we'll continue persuing yet a third option, which includes the reporting, CRM integration, screen pops and eavesdrop/whisper/barge and we'll mark those up as the "high end" product. The HUD product is a totally different discussion, has nothing to do with call queues. Good stuff. Thank you for sticking with me here and sorting out the details until I understood.

I will work with the team to remove the dashboard component's live updating and some of the features, then remove the queue price. By doing that, we risk less work to maintain the special queue functionality we have, so you can meet your price point for your client. I can't guarantee my team can accomplish this because now they have to, ironically, program MORE stuff (which costs more money) so that we're capable of delivering less stuff, but at the same time if it keeps users and customers happy, I guess that's what we have to do. And that way there's an upgrade path as well. Thank you so much for all the feedback. Despite my frustrations, which are no doubt quite clear in this thread and based solely on how much time and money we spend on our work and feeling a bit under-appreciated for it, I actually really NEED the feedback and appreciate it. We will find some happy medium.

There are a lot of things that confuse me about your reply. The conference call thing - it certainly seems to be treated like a secret! We were literally asked NOT to join. Weird. We beg for feedback, get none or barely any, then hear about all these "complaints" via some secret conference call. Why aren't you sending these people here to talk about it? So unbelievably strange. I don't even know what to say to that one. Anyway, as for the call queues thing, maybe I'm just not understanding you. We're trying to sell a call center product. It seems like you just want "queues". So if there is an element in the advanced callflow tool that lets you queue up callers and then ring whoever is available next, and that's IT, no other features (no custom hold music, no reports, one ring strategy, etc.) then maybe what we do is make a second version of this that's super, super, super basic and make that the cheap tier. If that's the hangup, OK, got it. Let me go back to the team again and see if we can make another version of call center. We called this one Call Center Lite because we know it already lacks features people expect in a call center you pay for. But if you're going to compare us to FOSS stuff then perhaps what we do is provide a "Call Center Super Basic" that has almost no features, no support services, and a really crummy UI textbox like FreePBX has. Then we'll at least be talking apples to apples. Let me stew on this. But also, you said "For me it's all about the long term vision. To me, I need to know I can get under$5/agent including average queue and flat costs eventually." We literally took that and made the pricing $7 at the high end, $3 at the low end, BEATING your price target, with a $99/month base fee. So we literally gave you your pricing. We set the $7 tier pretty low. What am I missing here. We effectively just offered you MORE features than you're asking for so you can go IMPRESS your client, and you're still complaining about the price? I literally have to be missing something here...

Also, @Matt, a few notes on your comment specifically. "The open source model allows us to contribute with code instead of with $." We are working on a way to trade time spent on docs or code for money that you can then use to get licenses for free (or cheaper). I am happy to look at what you've contributed and use that as leverage to knock the price down (or make it free for you). I absolutely agree, if you've helped us with code, it's a big deal, and we want to reward you. We have a new system for forums I'm trying to launch that actually lets you do just that. "I always thought giving us that option was honorable, righteous and it feels like whining, and asking for something for free so I can go out and make money." It IS whiny and self-righteous :-) But I understand that comes with the territory. I also have the right to set boundaries. If you all are going to go out and use our work to make money, it seems like once in a while that bounty should be shared. We are not restricting or preventing you from using the base product yourself, or building your own version of call center, nor are we against other people making competing products in ANY way. If theirs is better, great! We'll offer it, too, and stop offering ours, because hey, I can go work on something else. There's plenty to do in telecom. Always been my motto. "But, hey, thats the industry we are in, when Mark released Asterisk for free, he changed the game, and the VOIP market subsequently is what it is, its rooted in open source.  " That one is a huge reach: a) Mark did not release a full PBX product, he released a library + an engine. We are releasing the full product. It's NOT the same thing and most people who release a PRODUCT (even with Asterisk) charge for it, because the complexity, support and other maintenance requirements increase dramatically. b) FreeSWITCH also has queues, and we use FreeSWITCH. You're welcome to add a small adapter to just go start using FreeSWITCH queues. So your "loudness" is unwarranted, you have a perfectly reasonable alternative available to you. c) Mark also started a company called Digium as his business model, where selling cards would support Asterisk. Because he needed a way to support the work he was doing. He didn't JUST give it away for free, he found a way to continue supporting said free software with some paid income while leaving the free stuff available for people who don't want to pay. We've done exactly the same thing here. You are not required to turn on, or use, our call center. You can use, build or link to your own. Nothing has been crippled.

I would entertain one-time fees for some fixed license or something. Is that what you're looking for? Sounds awesome frankly, I'd love to get the larger cash funds up-front. I thought you guys all wanted monthly fees that were small. OK. That actually sounds even better. If you are willing to do that immediately, drop me a note. darren@2600hz.com Tell me the specifics of what you need. Indicate what your past contributions were. That will go a long way to lowering the price because it means you've got skin in the game, too, which is a big deal for us. We get VERY FEW contributions considering the amount of code we work on and maintain. I'm happy to figure something out. Happy to do one-offs. The goal is to pay for our work, plain and simple. I'm trying to work with you guys here, all you're doing is yelling and calling us names. Ugh. We give away $6 million of labor toward the software we build and now it's "but why isn't THE REST ALSO free". Well, simple, we have bills to pay, too. I have to be able to pay our staff, or you get NOTHING - literally, and that's not my fault, that's called life. If the staff don't collect a salary they can't feed their kids and they can't eat. We need a source to pay them. Contributions don't provide that and, frankly, we don't get many of those anyway. But if you've contributed a lot, then I'd be happy to trade, too. Labor cost is labor cost, regardless of who does it. So, pick your poison. But, really, you can't on the one hand say "we support you so much" then on the other hand when we actually need you to support the things we do because they cost a lot of money say "OMG WHAT IT COSTS MONEY?" Ridiculous. If there's a middle ground, let's find it. Rick you literally were the first one to write me saying how you wouldn't be able to feed your kids if BLF didn't work 100%. Well, back at ya, buddy. I was considerate and sympathetic to your plight. You seem completely unsympathetic to mine. And now on top of that, after I took your feedback and lowered the price (at the risk it will take longer, or possibly be never, to get paid back for our work), you're saying how we've somehow wronged you. Your behavior is pretty telling if you ask me. This is on TOP of the fact that you continue to maintain some secret group in the background where you try to get people to gang up on us and our product. *sigh*. Getting kind of tired of this frankly.

I agree this should work.

Your suggestions are always welcome. They are taken seriously. I will note that many suggestions focus around "small things." May seem glaring to you but overall they won't move us as a company, or you as a reseller frankly, forward in the market in the long-term. If we spent all our time on the suggestions you note, we would probably have an amazing set of existing features while falling completely behind on new features. So, like most things in life, there's a balance. It means nobody is ever perfectly happy, but we progress on the "small stuff" and the "big stuff" at the same time, based on resource availability. Thus, we won't always be able to fix the "things that make resellers lives easier" features without also scheduling things that people aren't even necessarily asking us about yet but are probably 1+ years worth of work so we need to be strategic and get them started. This particular conversation revolves around porting. Today, we spend $82,000 a year processing ports (just processing them). This number is too high based on our volume. I'd estimate we port-in about 10,000 numbers annually, so that's $8.20/port (we charge you $5/port). So, clearly a problem. Hence, the energy is now on porting. Thus, if we can pair the feedback with the financial goals and the overall objectives of porting in general (i.e. fixing both nuisance and functionally broken items), then everyone wins. So we take your feedback to heart, figure out it's cost + value, measure it amongst other cost/value scenarios, and go from there. That's why we don't provide ETAs, those values change often frankly. But they do eventually get done.