[VoiceOps] Which Softswitch?

[Carlos Alvarez]

I'm currently working on my third successful open source based company. We use Asterisk and haven't needed support in years. 

Sent from my iPhone

> On Jun 20, 2015, at 12:57 PM, Zak Rupas <zak at simplesignal.com> wrote:
> 
> I agree with Peter. The company's I worked for in the past that deployed open source never made it as they encountered serious issues and bugs and did not have a solid in house talent that could resolve the issues. There is only a hand full of large carriers left with open source cores and they spend more money retaining talent to manage and solve issues vs going with a known canned system that will do the support etc
> 
> Just my 2 cents for what it's worth
> 
> 
> Thanks
> Zak Rupas
> Tier 3 Voice
> Vonage
> 
>> On Jun 20, 2015, at 12:47 PM, Peter E <peeip989 at gmail.com> wrote:
>> 
>> Well said Alex. Service providers require support for the *whole* product and that is where open source solutions may falter.
>> 
>> I don't necessarily agree with the notion that the big-brands don't integrate. We do a ton of integration with Broadsoft, both with software that we've written and 3rd party software. While they're not perfect (who among us is), and they're not cheap, they are highly scalable, reliable, and yes, extensible.
>> 
>> I am also a big fan of open source where it makes sense, but for our core soft switch, no.
>> 
>> 
>> On Jun 20, 2015, at 11:34, Alex Balashov <abalashov at evaristesys.com> wrote:
>> 
>> Indeed, it doesn't seem to me that open-source systems are the thing to be avoided, nor that it's necessarily possible to do so. Moreover, the value proposition and trade-offs of open-source systems are quite clear. It seems to me the largest long-term value is in integration paths and connectors; most proprietary, "big iron" boxes just do what they do, and that's all they do, more or less. They may have a lot of features, but that's the feature set, and tying it together into novel, innovative and commercially differentiated third-party services is hard.
>> 
>> That said, I think we all know the sort of open source-based system to which the OP was referring. Asterisk and FreeSWITCH are low-hanging fruit, and have invited a lot of bad implementations and poor architectures. There's nothing wrong with using these systems foundationally within a carrier-grade product, as long as the system is architected correctly, in a horizontally scalable, distributed and fault-tolerant way, and that's a fairly complex undertaking of software engineering.
>> 
>> Vendors of these kinds of solutions also often do not provide a level of support that comports with telco sensibilities; their reasoning is either that the customer should largely support it themselves, since it's all built on open-source components, or their scope of support is narrow. Consistency and commitment can be an issue.
>> 
>> I can only speak firsthand, but in our case it has been very clear to me since the early life of our open source-based, commercial ITSP product that customers expect a high level of service value, and that the vendor relationship, along with the institutional domain knowledge and expertise provided, is as much a part of the value proposition as software itself. It's also been very clear that they expect support for the _entire_ technology stack of which the product consists, much as they would receive from Acme Packet or Sonus. Our customers don't care that our product ties together Kamailio, SEMS, PostgreSQL, Node.js, Redis and, ultimately, Linux, nor do they care about the degree to which we can or cannot exert direct control over bugs in these third-party GPL components. They expect us to configure the installations, maintain them, and troubleshoot, debug and fix as necessary.
>> 
>> I don't think this insight is necessarily common among vendors of open source-founded products. I've heard a lot of things like, "Oh, well, that's a bug in Asterisk, that's not a problem with our application." If the vendor sells and supports an Asterisk-based platform, to a large extent, it should be the vendor's problem. They may not be able to resolve it themselves, but they should own it, communicate it efficiently to the appropriate parties through expedient channels, and marshal the appropriate resources in support of fixing it. Not everything is always possible, of course, but many things should be possible most of the time.
>> 
>> -- Alex
>> 
>> -- 
>> Alex Balashov | Principal | Evariste Systems LLC
>> 303 Perimeter Center North, Suite 300
>> Atlanta, GA 30346
>> United States
>> 
>> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20150620/78b0e684/attachment.html>