The purpose of this CXTech Week 16 2023 newsletter is to highlight, with commentary, some of the news stories in CXTech this week. What is CXTech? The C stands for Connectivity, Communications, Collaboration, Conversation, Customer; X for Experience because that’s what matters; and Tech because the focus is enablers.
You can sign up here to receive the CXTech News and Analysis by email. Please forward this on if you think someone should join the list. And please let me know any CXTech news I should include.
Covered this week:
- IETF: mimi and vCon
- TADHack Global and TADSummit are live
- TADSummit and TADHack Global
- Sony Backs Maker of Tiny Raspberry Pi Computers With Fresh Funding, Access To AI Chips
- Zoom set to acquire Workvivo
- Chenosis relaunches
- Detecting Bots
- WHEP update from Meetcheo
- Are We Countering Cloud Skepticism the Wrong Way?
- GitHub Copilot: Fly With Python at the Speed of Thought
- People, Gossip, and Frivolous Stuff
IETF: mimi and vCon
IETF is working on vCon, PDF for conversations, yeah! And has a separate workgroup on More Instant Messaging Interoperability (MIMI). For those following TADSummit and TADHack over the years will of course immediately think Matrix.org for messaging interoperability. But of course standards bodies are highly political, so nothing is straightforward 😉
TADHack Global and TADSummit websites are live
We’ll be adding content over the coming months. Hacking, innovation, thought-leadership, and no-BS in programmable communications.
The TADSummit special we ran last month gives a hint on some of the topics we’ll be adding this year, e.g. cyber resilience, identity verification and fraud detection, open source, as well as the rise of automation in wholesale, interconnect, and aggregation of telecom services.
The company behind the Raspberry Pi line of computers has raised fresh investment from Sony’s semiconductor unit, in a deal aimed at advancing its efforts in artificial intelligence.
Sony Semiconductor Solutions, a subsidiary of Sony Corporation, invested an undisclosed amount in Raspberry Pi Ltd, the trading company of Raspberry Pi, the company said in a statement on Wednesday. The extent of the funding was not revealed, but Eben Upton, Raspberry Pi’s co-founder and CEO, said that the firm raised the cash at the same $500 million valuation it was worth in a 2021 funding round, when it brought in $45 million.
Hackers and hobbyists will be able to have some fun playing with novel ways of applying AI to solve problems that matter to them at in the device, and possibly hybrid.
Zoom is to buy Irish employee communications company Workvivo for an undisclosed sum.
Workvivo developed an internal communications platform to increase remote / hybrid employee engagement; including an activity feed, people directory, surveys and company comms. Like the company-wide channel on Slack where you do not feel the pressure to keep up with the flow of conversation.
The deal is expected to bolster Zoom’s employee experience competence, helping customers to keep staff connected and engaged. Zoom doesn’t often do M&A, but saw the team was delivering its remote / hybrid employee engagement.
Workvivo customers include Amazon, RyanAir and Bupa. The company had raised a total of $40 million, including a $22 million Series B in 2022 led by existing investor Tiger Global. Zoom founder and CEO Eric Yuan invested in 2019.
MTN is having another stab at Chenosis, its API Marketplace / platform, first announced in 2020. It’s now supported across five markets: South Africa, Nigeria, Uganda, Rwanda and Ghana. Beyond that it appears to be on the hunt for a proposition related to telecom APIs.
Chenosis is built with Apigee, there’s a long history going back to before Google bought them. Here’s an article explaining how Apigee is only API management. It does not contain a telecom app server to support communication services.
If you only want API management for exposing cloud compute services, API management is fine. But for comms stuff like, messaging, voice, 2FA (2 Factor Authentication), identity verification, risk rating, etc. you need all those telecom protocols, tolerance of carrier differences, and regional regulatory requirements. Hence the need for a telecom app server. This gap could be filled by using for example Jambonz or Radisys, both are TADHack and TADSummit sponsors.
I’ve had conversations with many telcos that have discovered what I wrote about in 2012 on the limitations of Apigee. I wrote recently on how Programmable Communications and CPaaS are Different, to drive the point home:
- CPaaS: A software product aggregators use to expose communications APIs like Syniverse.
- Programmable Communications / Telecoms: Making your communications / telecom solutions programmable for your customers and ecosystem partners like Twilio.
The advice I freely provided in 2020 was to focus on a couple of viable businesses, and build the MVP (Minimum Viable Product) for each business in one country. For example, undercut the aggregators (e.g. Infobip / Twilio) for messaging. We’ve seen telcos in the Middle East start to do this in 2021. Telcos control their wholesale pricing and costs for A2P SMS, they have an in-country competitive advantage compared to the aggregators.
Another opportunity in Africa is with respect to trust, specifically identity verification (e.g. silent network verification to confirm its Alan’s phone) or credit risk rating using insight such as Alan has been a MTN postpaid customer at the same address with XYZ geodemographic profile for 15 years.
Ayoba and Momo are two well-established MTN brands, and have worked with TADHack over the years. Ayoba is an all-in-one App focused on the needs of the African market. They have sponsored TADHack and some amazing apps have been created over the years, for example Maftuha, by Adela Bootha and Talhah Patelia. The power of Ayoba is it provides distribution for applications, like Google Play and the Apple App Store. MoMo is a mobile money wallet API/app, and again a TADHack sponsor, check out Xplorer by Naomi Skie (@NaomiBisimwa), Carol Khoza (@karol_khoza), and Christine Bismwa (@Hyitschristine).
The claims of Chenosis becoming a marketplace and accelerator are tough because MTN is not a technology company like AWS, Twilio, Azure, or Google; which makes them all developer-centric. BTW Twilio never used Apigee for API management, they built it themselves like many programmable communication companies.
MTN is an operations company, it is not developer centric. It works best in B2B relationships with scale where through its network and operations has defensible value. My advice remains the same as 2020 focus on a couple of simple propositions. Build only what is necessary, MVP. Open source is critical to be competitive. No BHAG (Big Hairy Audacious Goals). That’s for when you’ve made it and are trying to make it look like you knew your success was inevitable. It never is.
According to a 2021 report by Imperva, bots accounted for 25.6% of all internet traffic. Of this figure, bad bots were responsible for 45.9%, with their primary objectives being credential stuffing, web scraping, and distributed denial-of-service (DDoS) attacks.
Juniper Research estimates that businesses could lose over $48 billion globally to online payment fraud by 2023!
Behavioral biometrics is state of the art in monitoring how users interact with devices and applications. By examining these patterns, it becomes possible to distinguish between human and bots.
Examples include typing speed and patterns, mouse movements, device orientation, and touch gestures. And all the weird stuff humans do while using those devices, such as speed, acceleration, and trajectory in mouse movements.
With bots its possible to see quantization of behaviors, humans are more analog. It’s a game of cat and mouse, the human simulators (bots) will lessen the quantization, and replicate common human ‘traits’ as they are discovered more often.
WHEP update from Lorenzo Miniero (Meetcheo)
Lorenzo explains how WHIP and WHEP both play a quite important role in the future of WebRTC-based broadcasting. I always find his writing concise to read and as importantly fun.
- WHIP (WebRTC-HTTP ingestion protocol) is a protocol that was conceived to facilitate the process of media ingestion via WebRTC, something that in “traditional” broadcasting is usually done by means of protocols like RTMP. Which is what I use for my live broadcasts on YT.
- WHEP (WebRTC-HTTP Egress Protocol), on the other end, takes care of the distribution process, that is how to ensure viewers and subscribers can consume a stream via WebRTC instead.
Although it’s not mandatory for both of them to be used at the same time (WHIP could feed stream only consumed via HLS, or WHEP could be used to consume streams fed using other means), combining WHIP and WHEP is indeed the easiest way of getting ultra-low latency broadcasting of your streams, since WebRTC would be used on both ends. That can be huge in contexts where the lowest latency possible is important, like the broadcasting of live sport events, betting, gaming, etc.
That said, while work on WHIP is basically done, and an RFC may be ready soon, work on WHEP has just started: it’s not even a working group document yet. In its short life, there have already been some major changes in its design (some of which, spoiler alert, I’m totally unhappy about), and it’s likely that in the next few iterations it will change even more. As such, I thought I’d spend a few words on where we started and where we’re at, with a few considerations on the prototype work I’m doing on the protocol.
In a nutshell, WHEP assumed that a client could do either of two things:
- just as in WHIP, originate an SDP offer (stating their intention of receiving specific media), and wait for an answer from the WHEP server, or
- ask the WHEP server to provide an SDP offer instead (with a description of the media session), and then provide the SDP answer in a further exchange.
While this made sense, it also caused a few troubles, since it meant WHEP servers (and clients) could operate in two completely separate modes, basically non interoperable with each other. Without specific guidelines or requirements, this could easily get to a point where some WHEP servers would only implement one, and some WHEP clients would only implement the other, thus causing them not to be able to interoperate, despite them implementing the same specification.
To address this, the latest WHEP specification got rid of one to only remain with a single viable mode. The problem being, IMHO they got rid of the wrong one, which got me quite pissed…
(Alan) I recommend you read Lorenzo’s article, hopefully this shows your investment of time will generate a good return in understanding.
This article reminded me of the TechCrunch article I covered in CXTech Week 12 2023 on the Cloud backlash. Back in 2018 Dropbox moved away from AWS as it scaled up its business and saved $75M. Many large SaaS companies have done the same over the passed 5 years. And the Tom Nolle post highlights general enterprise IT are also in the midst of a cloud reassessment and highlights that cloud should be applied to the ‘core business’ not ‘core office’ applications for most enterprises. Though I do not consider it skepticism, rather learning on where cloud makes business sense.
With telco we still see much marketing hype on public cloud being the answer. While at TADSummit 2020 we did a panel discussion and opening opinions on cloud computing and serverless for RTC, which backs up the selective application of cloud compute Tom mentions.
It’s a hybrid approach, as what is best: serverless, public cloud, private cloud, on-prem, and hybrid depends on the workloads’ needs. Understanding each workloads’ needs is critical. AND we can not underestimate the impact Amazon, Google, Microsoft have on the developer fashion (all those developer relations and marketing dollars). Serverless and public cloud are trendy atm.
The panel included:
- Tim Panton, Co-founder and CTO at Pipe
- João Camarate Silva, Founder & CTO GoContact
- Simon Woodhead, CEO Simwood
- Jason Berryman, Freelance Google Cloud Architect and Google Developers Expert at 418.dev
- Sebastian Schumann, Network Production Development, Technology & Innovation at Deutsche Telekom
- Marten Schoenherr, CEO/Founder at Automat Berlin GmbH
The panel focused on 5 questions:
- Does everyone agree with Tim’s view that: the lifecycle of serverless functions is short, max 9 mins. Which is not compatible with the longer sessions of communications?
- One issue brought up is the limited set of functions available on serverless today, is that significant for RTC?
- Less serverless more cloud: What’s your experience with VoIP/SIP servers and containers?
- Timing of serverless for RTC? Now, part of a hybrid solution, or never as the world will have moved on?
- Will some technology companies skip serverless and move to a decentralized event drive stack using HTTP/3 RIPP?
I apologize for grossly simplifying the answers / discussion below. My aim is to give you the main gist, in the hope you invest your time and watch the video in the linked articles above. The answers were:
- Generally yes. Jason highlighted there are some tools that can extend the lifetime to 15 mins. General consensus was Serverless for production RTC services is not necessarily appropriate. Now you’d think that would be the end of the panel discussion.
- There are tools like Knative and Cloud Run, which extend serverless to containers. So serverless functionality is not an necessarily an issue.
- Simon mentioned Simwood has been running its services in containers for 5+ years. As part of a hybrid approach across bare metal, containers, and bursting into the public cloud. While Sebastian highlighted telcos are taking an incremental approach, in part limited by their planning cycles. And open source telecom projects are moving into containers as well. Containerization should be considered BAU by now.
- Some workloads are ideal for serverless, particularly in development and testing, strong recommendations there and excellent examples. Also for workloads like data analysis, machine learning, transcription, make sense. So severless is being adopted just not for the RTC core.
- The last question was where things got interesting, and the reason we overran. Briefly: because Amazon, Google, Microsoft dominate developer fashion, technology companies have no choice by to adopt serverless, its inevitable. The discussion above shows the focus is for specific workloads, not necessarily the RTC core. The continued progression of abstraction from AGM, where rather than CPaaS APIs or WebRTC SDKs, calling simply becomes a function received much discussion and recognition of its inevitability given development trends. The role of edge compute was a little more contentious, but I think decentralization and edge compute are a reaction to the inevitable abstraction and silo lock-in AGM want to achieve.
GitHub Copilot is a virtual assistant for your code editor. Python is well-supported by Copilot. After reading this tutorial, you’ll know whether GitHub Copilot is a risk, a gimmick, or a useful tool in software engineering.
In this tutorial, you’ll learn how to:
- Install the GitHub Copilot extension in your code editor
- Transform your natural language description of a task into working code
- Choose between multiple alternative intelligent code completion suggestions
- Explore unfamiliar frameworks and programming languages
- Teach GitHub Copilot how to use your custom API
- Exercise test-driven development with a virtual pair programmer in real time
The tutorial is insightful and great fun. I was left feeling a little more confident on my coding abilities, my rusty C/C++/Pascal/BASIC/Assembler just left me feeling sad whenever I was working on a project. I now need to apply this new found confidence to some of my hobby projects, e.g. didn’t get to the UV detector last summer.
People, Gossip, and Frivolous Stuff
Juan Rosero is now CIO Televox & SVP West Corporation. I’ve known Juan since he joined West.
Alain Mowad is now Senior Director, Product, Technical & Services Marketing, Analyst Relations at Talkdesk. I’ve known Alain since his time at Ribbit that BT bought for $105M in 2008, then closed down in 2011.