Programmable Telecoms inside a Telco, by Jesus Cruz Manjavacas, VAS Development Expert at PLAY. Below are the video and slides, followed by my summary of the presentation. If you have any questions for Jesus ask in the comments or contact him directly.
Video and Slides
Slideshare is having difficulties today, here’s a direct link to Jesus’s slides.
Alan’s Summary
PLAY in Poland has been part of TADSummit since 2014, and a sponsor of TADHack Warsaw in 2016. It’s great to welcome Jesus for his first TADSummit presentation after attending in 2019 🙂
The PlayAPI is one of the longest running Telco API programs, since 2011. I greatly respect the tenacity of Play with its APIs, recognizing their strategic importance, and keeping with it when others dropped their programs because it was no longer considered fashionable.
In this presentation Jesus shares some excellent insights, and frank reviews on their experiences. For example, on the challenges they faced operationally with WebRTC. They’ve been involved in WebRTC since the beginning and did launch a WebRTC-based service in 2014. But because of the WebRTC standards battles and maintenance issues when WebRTC in browsers gets updated, its is currently deprecated.
The insight on the performance of Erlang compared to JAIN SLEE is common. As well as the risk on developer expertise, here partner jtendo is key. Definitely in Warsaw there is a center of excellence in Erlang 🙂
Jesus’s experience in moving from SIP servlets on Sailfin is a great example of how technology decisions can be changed out without heart-ache. In fact, this should be expected.
Moving to Kamailio and FreeSWITCH is a wise move. And having Kamailio in their architecture enables not only the migration from legacy stacks, but also other open source application servers like Asterisk and Drachtio to be brought in as well. Further minimizing technology risk. And even Kamailio can be changed out for OpenSIPS. So PLAY have created a flexible, low risk, modern architecture which many communication service providers should copy.
I’d also like to congratulate PLAY for talking about the open source projects they use. Too few telcos do this, more should follow PLAY’s lead.
OVOO were PLAY’s partner for the Virtual PBX service. Its mobile only and targeted to small and medium sized businesses. To all the US-biased analysts out there, mobile operators have a significant role in UCaaS in Europe and Asia!!! There’s so many more providers than the magic quadrant providers of Microsoft, Cisco, RingCentral, etc.
I love the recommendations, and have to repeat them here:
- APIs facilitates R&D and new services ideas o Having our own solution provides us with elasticity, adding more functionalities depending on business needs.
- If there are no standards, better to design your own API model
- Confirmation that Open Source is worth it, we have to support the community back
- Experienced suppliers, specially in telco, is a blessing
And on next steps – “Cloud Native 100% (only when 100% needed!)” YES!!
Well done Jesus, an excellent presentation. I hope to see you again in 2021.
Outline of the presentation
API Review:
- Messaging (SMS, MMS, USSD, RCS);
- Network Status (Location, Subscriber Status, etc.);
- Device Capabilities;
- Third Party Call Control;
- Identity (OAuth2, Mobile Connect GW);
- WebRTC (deprecated, will explain why);
- Subscription Management and Direct Billing.
Services example: VirtualPBX service built on top of our Call Control API.
Technology review: Java, Spring Boot, and Erlang.
Partner / supplier review: Jtendo and OVOO.
The importance of open source: Kamailio, FreeSwitch, Prometheus, Grafana, ELK, and Ansible.
Learning and next steps: developer portal, cloud native but not yet public cloud.
Hi Jesus, thank you for an excellent presentation and supporting the open source community. Some of my questions include:
AQ1) You are fortunately to have a local partners, even in the same city, with excellent open source experience and knowledge. For other telcos, will this be a problem for them?
AQ2) Developer portal is often an overlooked aspect, we have an invited keynote specifical on engaging developers, https://blog.tadsummit.com/2020/11/01/engaging-developers-steven-goodwin/. What lessons have you learned in building your developer portal, what recommendations would you provide to other telcos?
Thanks Alan for the opportunity of sharing our humble experience!
AQ1) I believe that if not a problem, at least they will have less options for sure. Not having such local partners with the needed knowledge, probably ends up in buying legacy solutions from bigger players, which means bigger cost and more level of vendor lock-in, together with more headaches integrating them to your network. Most of “ready”-solutions out there don’t work out of the box in your network and need to be elastic.
On the other hand, mayby some telcos will have such knowledge inside the company, in that cases there would be more in-house initiatives which I believe would be also a considerable way to go as well.
AQ2) We plan to simplify our APIs, build a layer on top even and provide SDKs, but after watching Steven’s talk (liked it!) must say that we will have to work harder on that than I thought. It’s true that developers nowadays want to have everything almost already “cooked”, clear and now. If not, they will go search for another API somewhere else. That for us could be translated for getting to cooperate with more partners ( which developers could be involved in the decision of which API to choose ).