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, Invox / PBXPlus, 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.
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.
- 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.