[VoiceOps] Which Softswitch?

[Alex Balashov]

Oh, yes, big-brand switches do have integration capabilities, but within a tightly controlled set of parameters. Moreover, these integration paths typically take the form of morbidly obese, bureaucratic SDKs, betraying a common fondness for heavyweight SOAP and Java. 

It's not the same as just going into the database and doing whatever you please, bolting on views and triggers from the ‎side, etc, nor is it like a lightweight REST API.

--
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/

Sent from my BlackBerry.
  Original Message  
From: Peter E
Sent: Saturday, June 20, 2015 14:47
To: Alex Balashov
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] Which Softswitch?

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