Archive

Posts Tagged ‘sip’

Telco PaaS is not Telco Assets and PaaS

April 11, 2011 2 comments

Telecom operators have always focused on two aspects: ARPU and time-to-market. In the latest technology craze – Cloud Computing – a lot of telecom operators are seeing a new golden grail. Those that can see further than SaaS marketplaces and moving their hosting to IaaS are only the happy few. Since Cloud Computing = SaaS + PaaS + IaaS, it is normal that operators start talking about Telco PaaS. However Telco PaaS is a lot more than combining telco assets with an IT PaaS.

IT PaaS are aimed at quickly launching applications. The IT grail is to launch thousands of applications to find the one that everybody likes and become an overnight millionair. Telecom operators might be easily fooled that opening their telecom assets to IT PaaS developers will bring that one application that will turn the telecom sector around: “The Killer App”.

Unfortunately a telecom application is more than an SDK+app server in the Cloud that can do VoIP. The reason why companies pay a plus to telecom operators is “trust”. “Trust” that you can pick up the phone and call somebody. “Trust” that if something is not working that you can call their call center. “Trust” that tomorrow they will offer you the service.

All this “Trust” has to do with the way operators have their backoffice systems and processes set-up. Having thousands of developers creating applications that mix telecom with SaaS might give some nice innovation. However telecom operators are not prepared to handle thousands of end-users that find bugs in a long list of applications and start calling call-centers massively. End-user expectations are different for telecom applications then for IT applications. This definitely has to do with the price they pay for them.

What should a Telco PaaS offer?

More than a fixed feature set, the most important changes for an operator that wants to offer a Telco PaaS might be internal. Operators will need a large shift in thinking to be able to accept some of the new realities:

  1. Telco PaaS services need to be launched in weeks not years.
  2. Telco PaaS services will be buggy, unstable and fail.
  3. Telco PaaS services can not be supported via a call center.
  4. There are no Telco PaaS standards and there are likely not to be any until it is too late.
  5. Telecom can not be greedy

Launching in weeks instead of years

If IT PaaS is bringing something then it is speed of development. Telco PaaS needs the same type of speed. In practice this means that REST and JSON should be the operator’s vocabulary, not SIP and CDRs. Telco Assets need to be exposed to non-telco programmers. Developer communities need to be created. Marketplaces that allow developers to sell their creations by the click of a button and not to worry about complex charging and billing.

Unstability, bugs and failure

Not every IT programmer is a genius. There are probably quite a few geniuses. Instead you need to expect that people will do things incorrectly, by error but also on purpose. Application virtualization and sandboxing are key to make sure “mistakes” don’t bring down the whole platform. On the other hand customers need to be segmented. There are customers that can see further than the bugs and see the potential. These are called visionaries or early adopters. It is critical that operators allow these early adopters to play around with buggy services. However it is equally important that the majority of users know that the sandbox might contain buggy apps and that the call center is not the place they can find help.

No support via the call center

All sandbox applications can not be supported via a call center. Agents will not know anything about these thousands of apps but neither should they. The only one that knows is the one that developed the service. He or she should get the right tools to quickly understand which bugs or feature requests are important, e.g. via a social CRM. The operator should monitor those promising apps that are ready to graduate the sandbox. They should be place in an incubation program. Incubation will see if the applications can go mainstream and will professionalize support, availability and reliability.

No Telco PaaS standards

In the dotcom world the first one that creates a solution, creates the standard. In Telco PaaS this will be the same. If we do not know how users will use a Telco PaaS, how can we expect that standardization bodies will define the correct standards. However in disruptive innovation, unlike technology evolution, first movers have an ever lasting advantage.

Telecom Greediness

If you have a monopoly, you can be greedy. No competitor will offer anybody a better deal. However in Cloud Computing, greediness will kill your best innovation. It is better to get a small percentage, signup or usage fee per application when you have thousands of applications then to get nothing at all. Many cents can make billions. Think Adwords…

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.

Creating Telecom Network Apps the Cloud Way: Telephone 2.0!

January 21, 2011 Leave a comment

Ask a Telecom architect how you create a telecom network application, often dubbed as value-added services. He or she will focus on SIP/SS7 standards, service delivery platforms, etc.

The future of cloud-based telecom network apps, let’s call them tapps, is going a totally different direction. For the former telecom architect they probably like open source solutions like Mobicents that allows you to create SIP-based applications on Java. The Asterisks and other types of VoIP application servers are other alternatives.

However for a new generation of Web-based programmers this is all too complex. These are the programmers that like Javascript, Ajax, JSON,  PHP, Ruby, etc.

The majority of them will be fine with whatever Twilio or Tropo offer via easy to use REST APIs or embedded in their favorite scripting language. Which cloud-based application needs more than calling, SMS, answering the phone, getting feedback from the user, telling the use what to do, putting multiple users in a conference, transcribing what the user does, forwarding a call, etc.? 95% of the functionality is covered with a handful of REST APIs.

For business developers that are more used to Java, they can also use Java APIs to access for instance Twilio. To be able to cheaply launch an application and scale it afterwards they could deploy it on Google App Engine. A new alternative has just come around from Amazon: Elastic Beanstalk. A developer can write their app and deploy it on Beanstalk. They no longer have to worry about monitoring, scaling, opening firewalls, etc.

Other alternatives are to extend Cloud-ready telecom applications via plug-ins. An example here could be Twilio’s OpenVBX in which you can easily add new plug-ins.

The conclusion is that 2011 will be the year in which Web 2.0 and the Cloud meet the Telephone 2.0. However the Telephone 2.0 will unlikely pass through Bluevia and other operator initiatives given the fact that they are running about two years late and are very scattered, slow-moving initiatives.

Operators should embrace the new reality and try to help these new applications find new users. The Appstore brought a new eco-system to life. Millions of small and medium-sized Telephone 2.0 applications are waiting to be discovered by Billions of users. Remember that not everybody can pay an expensive mobile with an expensive data plan. However there are billions that can pay for cheap call and SMS-based applications. We need to help the billions find those tapps that are useful to them…

The power of binary SIP

December 10, 2010 Leave a comment

With the world looking more at XML, SOAP and REST these days, it is perhaps  anti-natural to think binary again. However with Protocol Buffers [Protobuf], Thrift, Avro and BSON being used by the large dotcoms, thinking binary feels modern again…

How can we apply binary to telecom? Binary SIP?

SIP is a protocol for handling sessions for voice, video and instant messaging. It is a dialect of XML. For a SIP session to be set-up a lot of communication is required between different parties. What if that communication is substituted by a binary protocol based for instance on protocol buffers? Google’s protocol buffers can dramatically reduce network loads and parsing, even between 10 to a 100 times compared to regular XML.

What would be the advantages:

  • Latency – faster parsing and smaller network traffic reduces latency which is key in real-time communication.
  • Performance – faster parsing and lower load means that more can be done for less. One server can handle more clients.
  • Scalability – distributing the handling of SIP sessions over more machines becomes easier if each transaction can be handled faster.

Disadvantages:

  • No easy debugging – SIP can be human ready hence debugging is “easier”. However in practice tools could be written that allow binary debugging.
  • Syncing client & server – clients and server libraries need to be in sync otherwise parsing can not be handled. Protocol buffers ignores extensions that are unknown so there is some freedom for an old client to connect to a newer server or vice-versa.
  • Firewalls/Existing equipment – a new binary protocol can not be interchanged with existing equipment. A SIP to binary SIP proxy is necessary.

It would be interesting to see if a binary SIP prototype joined with the latest NOSQL data stores can compete with commercial SIP/IMS equipment in scalability, latency and performance.

Are you exposing assets the wrong way?

September 13, 2010 Leave a comment

The standards API myth

In the perfect API we talked about how to expose assets. Simplicity is key. The general telecom thinking is to go for standards. However in the dotcom era standards are set by the one that innovates quicker and better then the rest.

The iPhone does not support Java or Flash [yet]. Skype did not build a SIP-compatible service. Facebook does not expose a standard Opensocial API.

Many operators are focusing on the GSMA OpenAPI and other API standardization efforts. However all these standards often are designed by “experts” that have not programmed in the last years. Startups focus on making it simple. Launching something quickly and making incremental changes and extensions on a weekly basis. The only way to create a successful API is to constantly listen to the community of programmers that are using it.

Dotcoms are bitpipe creators

Many operators still consider their most fearsome competitor the other operator that shares the same country borders. Unfortunately it is not this competitor that will potentially render them into a bitpipe.

If you are exposing assets, it should be because of two reasons:

  1. You want to make some extra money.
  2. You are afraid that if you don´t expose your assets, then some dotcom will find a way around them, e.g. Google Latitude and location assets.

What are you exposing?

Ok, we finally got the agreement from management to expose APIs so let´s start with SMS and MMS… Wrong! There is absolutely no shortage on the Internet for ways to send an SMS. Additionally MMS is becoming less important with all the email enabled phones.

What should be exposed are those assets dotcoms are not offering yet! Why? Selling something that others already offer cheap is not a guarantee for business success. Selling access to assets that only are available through you, makes for a great differentiator.

Offering assets as-is will not be very successful either. One example: If I can only generate standard numbers which follow the official numbering plan, why would I need an API. Any VoIP DID provider can get me a phone number. It would be different if I could generate “un-official” numbers that don´t cost me €5/month but instead can even generate revenue. Send an email to maarten at telruptive dot com if you want to know more!

One-stop shop

Developers of telecom services want one thing. Fortunately this one thing is not new. A developer wants to make an application that they can easily sell to as many people as possible. Several startups exist that allow developers to create very advanced call-control, conferencing, etc. applications. However this is only one side of the story. Even if I can build the best voice conferencing bridge, that does not make me a millionaire. Developers need the channels to market their applications and make money with them. They need a “Net App” store.

Open versus Closed

If we are not competing against another operator but against dotcoms, why can´t we work together? American Airlines build their reservation system and afterwards allowed other airlines to use it. It quickly became the standard.

An open platform in which developers can write ones and sell everywhere, will prevail over closed platforms. Facebook allows companies to extend its platform. By being the market leader, it attracts a disproportionate number of partners to its platform.  The iPod has probably more extensions and add-ons then the next five competing products together. If you are not willing to open your platform then you are probably not going to be the market leader.

%d bloggers like this: