Posts Tagged ‘twilio’

Bye bye WAC, hurray Twilio

In the same week Twilio announced global SMS delivery, WAC was declared a failure.
Was it a surprise? Not really. Developers want simple APIs that are cheap and global. Twilio offers this, WAC does not. Are operators learning anything? The answer is they are not.
Telecom dogma 1: Users will not use a service that is not a global standard.
Internet response: proprietary APIs.
Telecom dogma 2: 99.999% availability with expensive hardware and Oracle RAC is the only way to launch a telecom service.
Internet response: Amazon and Rackspace virtual servers and MySQL.
Telecom dogma: I am the king. I put prices and users have to pay them.
Internet response: $1/virtual number, $0.01 SMS/call per minute.
How can a company with less than 100 employees offer better pricing than the actual network owners?
Operators are thinking ROI in 6 months and then ask what users might like. Internet players launch something simple and cheap, get continuous feedback and improve the service. In 12-36 months they dominate the world.
Know any bad service on the Internet that had a good ROI in 6 months? If you do not provide what users want, ROI will be a lie in your Excel. Forget 99.999%, forget RFPs, forget 40-70% revenue shares, etc. Either you innovate and launch in 3 months with daily improvements afterwards or you will not be an Internet player. The alternative is being a bit pipe. But even there Freedom Pop,, Google FttH, etc. might spoil ROI…


Alternatives to paying millions in software licenses

January 9, 2012 2 comments

Telecom operators pay millions in software licenses each year. By doing so they are sustaining an industry of “feature loading”. “Feature loading” refers to complex software solutions that in order to win RFPs add more and more features. Most telecom operators are using RFPs to compare different software solutions. Whoever has more features for the lowest price wins the deal. The end result is that telecom software is unnecessary complex and expensive. Software providers do not want to respond with “not compliant” and prefer to add some extra feature even if the one who wrote the RFP will never ever use them.

The likes of Apple have shown us that software is most beautiful when it does very few things very well. The era of mini applications allows users to use special purpose “apps” for each activity. No training required. No heavy investment. No heavy integrations.

Telecom operators should move away from the long RFPs with hundreds of features being compared. Instead they should try to simplify. Why pay millions for a complex system that does too many things too complex? Many large dotcoms have moved away from this type of solutions and have used Open Source, have built single purpose systems/services or generic platforms with plugins to reduce complexity.


  • Amazon has pioneered Cloud Computing and has created individual single purpose systems or services that are easily accessible via REST or Web Interfaces. Different individual services (e.g. product recommendation, virtual server, virtual storage) get aggregated into complex solutions at the last moment.
  • Google built its Google File System, BigTable, etc. as generic platforms on which hundreds of other services could be easily added.
  • Thousands of dotcoms are using Hadoop, Cassandra, etc. to store data.

Each telecom service needs to be provisioned, rated, charged, billed, monitored, operated, supported, migrated, etc. By building solutions in which network, IT, communication and services are mixed into mega-complex architectures it has become impossible to launch new services in less than 12 months.

Building a Free Telco PaaS

How to do it differently? Is it possible to build a zero-license Telco PaaS that acts like a giant service delivery platform in the Cloud? YES

Operators will need to use Open Source, IaaS and SaaS solutions. IaaS can be delivered cheaply by using Open Source components: KVM for virtualization, Open Nebula for virtual machine and storage management, Hadoop/Cassandra for storage, Open vSwitch for network virtualization, etc. On top PaaS platforms can be built with solutions like WSO2 Stratos. Telecom services like Twilio‘s or the private cloud version, RestComm, can be used to allow developers to quickly create VAS. Open Source billing systems have been announced, like Meveo. Online shops can be build with Opencart. Datawarehousing and data analytics with Pentaho or Jasper Reports. There are hundreds of open source monitoring solutions: Icinga, Nagios, Zenoss, etc. Helpdesk can either be SaaS like Zendesk, or Open Source like Request Tracker. CRM like SugarCRM. SIP backoffice systems like FreeSwitch.

Operators should start thinking about the Cloud as a way to simplify internal integrations. All back-office systems should be shielded from the outside via easy to use REST, Thrift/Protocol Buffers, etc. interfaces. Service-based loadbalancing should allow service upgrades and rolling migrations without outages. The architecture should be built with in mind. Non-programmers, and even better end-users, can build their own VAS by using drag-and-drop interfaces and combining different service blocks together into custom solutions. Plug-ins allow for custom behaviour without cluttering a solution for the rest of the users.

Operators should embrace new disruptive technologies to simplify their business, lower their cost structures and be able to launch new services every hour of the day. Large dotcoms are launching new features every day and use A/B testing to validate if users like them and they add to the bottom line. Marketing and product management get a totally different dimension…

Disrupting the SDP market with Open Source Telco PaaS – An interview with the Restcomm team

December 20, 2011 1 comment

The service delivery platform market is going to see disruptive players in 2012. One of these offerings is Restcomm that offers an open source Telco PaaS solution that will get to version 1.0 in March 2012. I interviewed the director of Cloud Engineering of Telestax, Thomas Quintana, who is responsible for driving Restcomm within the Mobicents community.

What is RestComm?

RestComm is what I like to call a “Web Driven Communications Platform”. In order to understand what I mean it’s useful to have a basic understanding of how RestComm works. When RestComm receives a phone call for example, it calls out to some resource on the web to instruct it on how to handle a call. In turn the resource itself can turn over control of the call to other resources on the web. Hence my description of RestComm.

Who is the target user? 

In developed markets that is an interesting question because the target user has always been web developers but we have noticed that the RestComm instruction set maps nicely as a DSL (Domain Specific Language) on top of development platforms such as Java, Ruby, Python, etc. This in turn has made mobile applications developers and desktop applications developers target user communities as well.

In emerging markets the target users are operators who want to deploy a PaaS (Platform as a Service) and provide services to its customers and SME’s

What is the RestComm Vision?

The RestComm vision is to offer a 100% open source and service provider agnostic web driven communication platform to the open source community. Woah, that’s a mouth full 🙂

What is on the direct roadmap for RestComm?

There are a quite a few goals on the RestComm road map but I will list the ones I think are currently most important:

  • 100% Twilio API compatibility (Available as of ALPHA 2 which will debut in a few of weeks)
  • 100% Tropo API compatibility
  • Monitoring support
  • Web based management interface for easy management
  • Support for other communications networks such as Skype and Google Talk

Will RestComm also support non-REST APIs, e.g. Javascript?

Yes, as a matter of fact most if not all of the Twilio wrappers will work with RestComm with very little effort (possible as of ALPHA 2). Usually all it takes is just pointing the API at your RestComm server.

When will release 1.0 be available?

The RestComm FINAL release is scheduled to be available in March. 

What will be in release 1.0 that is currently not there yet?

We are doing a lot of work on RestComm based on community feedback from early adopters so it’s hard to tell everything that will make it in to the FINAL release but the following are things that will definitely be present.

  • A super set of the Twilio API to support functionality currently not covered by the Twilio API but requested by our development community (e.g. faxing, call leg and conference room recording, etc.).
  • JDBC and MongoDB support (plus it’s very easy to add additional back-ends)
  • Support for any SIP origination/termination provider
  • Support for more international SMS aggregators
  • High Availability support
  • and many more things stay tuned 😉

Below are two features that we would like to have available by the FINAL release but are still investigating.

  • RestComm application Fail-Over support
  • Very large self organizing conference rooms (1000+ participants)

How will RestComm scale? 

This question is a bit difficult to answer because RestComm’s ability to scale is limited only by the infrastructure that it runs on. In order to answer this question I would like us to assume that most of the RestComm deployments will be on private/public clouds with sufficient resources. Now that we have some context RestComm scales horizontally on two layers the RestComm interpreter itself and the media gateways. Each RestComm interpreter can drive tens to hundreds of media gateways providing scaling for media and by placing SIP load-balancers in front of the RestComm applications servers the interpreter itself can be scaled horizontally. We are currently investigation media gateway fail-over where if a RestComm interpreter becomes unavailable the other interpreters in the cluster will take over its media servers and continue executing the RestComm applications.

In order to provide a demonstration on how to accomplish large scale scaling the Mobicents team will publish a paper on how to deploy RestComm on the Amazon EC2 cloud with hundreds of instances once we reach our BETA release in February.

Will there be a GUI management interface?

Yes, we are planning on releasing a web based management interface but we are currently focusing on providing a stable release. 

Will there be a monitoring interface?

JMX and SNMP support are currently available for the Mobicents Sip Servlet Container which RestComm sits on and that is how we monitor RestComm for now. In the future RestComm will provide its own monitoring interfaces.

Will Telestax offer support/SLAs for RestComm?

TeleStax enables Telecommunication Service Providers and Enterprises to create scalable communication applications based on Open Source and Open Standards. Therefore, TeleStax will provide supported versions of the “RestComm Platform for Production” aka RCPP (like JBCP) to its end customers. The support subscription will be for developement as well as production support with flexible SLA’s to suit the requirement’s and demand’s of end customers. For further details contact TeleStax – 

Mobicents ‘ Restcomm is to Twilio what Eucalyptus is to Amazon

December 10, 2011 3 comments

In recent weeks I had the pleasure to talk to the team behind Mobicents. I have been pleasantly surprised by Restcomm. Restcomm is Twilio for the Private Cloud. Telco 2.0 SaaS for private cloud. Tropo APIs are also on the roadmap. Mobicents is starting a revolution by moving away from telecom standards and moving to the new Cloud telecom standards. Telecom engineers are no longer needed to make enticing value-added services. Any web developer can make telecom apps in minutes and integrate them with Web 2.0 and social networks.

Is Restcomm a threat for Twilio? Quite the contrary. Many larger companies did not want to move to Amazon because of fears of vendor lock-in. Eucalyptus brought a way for public cloud apps to move to a private cloud. Restcomm will allow companies to move their telco apps to the private cloud when they become a large hit. Developers could even start from a private cloud deployment and move apps to Twilio when spikes in demand happen, a.k.a. cloud bursting. In general Twilio is very likely going to get more customers instead of less by having a valid open source alternative.

Mobicents is also undergoing large changes. There has been a shift in direction at Red Hat and the Mobicents team started their own company called Telestax. The company is independent from Red Hat, however it will partner with Red Hat for telecom opportunities involving RHEL and JBoss products.

When will operators offer visual VAS designing tools?

A long list of startups are making it easier every day to create and customize value-added services. These tools mainly focus on two segments:

  • soho and small enterprises with visual PBX, call center as a service, etc.
  • consumer oriented with voicemail, mobile apps, etc.

The main players in this new market are small startups. Companies like Twilio with OpenVBX, InvoxPBXPlus, etc. Also some established players offer solutions: e.g. App Inventor and Voice from Google, Yuave from Nokia Siemens Networks, etc.

I am still waiting for the first telecom operator to offer a similar service. Neither of these services is nuclear science. Most are SIP or other VoIP solution based. Via a SaaS marketplace operators could be reselling them if they don’t want to license or build. Additionally the operators have some valuable assets that dotcoms would love to make use off: micro-payments a.k.a. billing/charging; free call forwarding; numbering plan creation; high-available network assets; quality of service; etc.

The Long Tail Telco – An Alternative Cloud Strategy

February 11, 2011 2 comments

Most operators have a mobile portal in which end-users can buy games, applications, ringtones, etc. Several operators have a legacy of server hosting, email hosting, and other business services.  Some operators have a marketplace where small medium enterprises can buy SaaS. Others are thinking or building a private cloud and want to become an infrastructure as a service provider. Often to avoid legacy hosting to disappear.

There can be reasons why a small, medium or large enterprise wants to use the infrastructure from an operator compared to a public cloud: SLAs, quality of network service, security, etc. Price is very likely not going to be one of them. Neither will be innovation or flexibility because here the likes of Amazon, Google and Microsoft are almost impossible to beat.

So why is it that operators think that IaaS is their preferred strategy to enter the cloud? I have no idea but my opinion is that it is easier to start with SaaS and work down to PaaS then to start at IaaS and work upwards. IaaS will have hyper-competition and very small margins as a consequence…

An alternative telco cloud strategy

Operators often have a direct sales channel towards medium-sized enterprises. By offering a SaaS marketplace they could extend the amount of services they are providing towards these medium enterprises. After reaching a tipping point, smaller enterprises will likely follow via direct web-based purchases. However reselling SaaS can never be a long-term strategy.

SaaS should be an initial start of a new customer relationship. Operators should focus on selling complete solutions focused on a specific industry or problem domain. Examples:

* Healthcare – web, mobile, tablet, TV and SMS patient reminder & reservation system, health-care call-center as a service, farmacy locator,web-based medicine reservation system, etc. 
* Restaurant – web, mobile, tablet, TV and SMS table reservation system, online menu web hosting, group-based or community food purchasing service, special deals á la, etc.
* Car dealers – web, mobile, tablet, TV and SMS maintenance reminder & reservation system, parts-locator call-center as a service, etc.

The operator should not focus on inventing these services but instead on creating the tools, the eco-system and the community for smaller IT shops and other to come up with scalable niche services.

To fully utilize a SaaS an SME needs help: training, configuration, customization, integration, etc. For this you need a services marketpace closely linked to your SaaS marketplace. As well as a long tail support solution.

The Long Tail Telco PaaS

To be really able to offer long tail services, operators need to have a long tail Telco Paas. A Telco PaaS is like a Google App Engine, combined with Google App Marketplace, combined with Twilio/OpenVBX, combined with charging on your invoice, combined with open standards like OpenID, oAuth,SIP, etc.

Not clear??? A small company knows best what another small company need. However they do not have the infrastructure to reach and help thousands of other small companies in the world that have the same problem. This is where the operator should help both with global communication and IT solutions. A small company should not be focusing on installing a CRM, call center, ERP, etc. if they want to help others configuring and customizing a health care reminder service. They should have specialists in the health care reminder service and should be able to purchase the rest from the Long Tail Telco’s marketplace. They should also be able to auction a request for legal assistance, escrow-service, translation, etc., basically an all-in deal. The operator should focus on business communication in the broad sense, not the telephone service sense…

%d bloggers like this: