I first came across the T.140 (Real-Time Text) specification many years ago. Back then I was working at Truphone - for those who don’t remember, the first mobile VoIP OTT app - where we were evaluating different ways of sending SMS over IP.
When I read the spec, my reaction was: who would ever consider using this? It seemed ugly and unnecessarily complicated compared to the other IP-based protocols we had on the table. So I filed it away and moved on.
It stayed filed away until the 2026 edition of Kamailio World, where I learned that T.140 had - many years ago, in fact - been selected as the protocol for emergency messaging.
What I learned at Kamailio World
Two talks reframed the protocol for me completely:
- Wolfgang Kampichler (Frequentis) laid out the foundations of emergency texting in mobile networks in The Point of No Return: NG112/911 Reality vs. the Standards in 2026, and was candid about the interoperability and implementation problems the ecosystem still struggles with.
- Henning Westerholt (Gilawa) walked through the pain of getting T.140 implemented and merged into Asterisk in Implementing Real-Time Text in a VoIP Infrastructure - a reminder that “standardised” and “easy to ship” are very different things.
A protocol that refused to die
T.140 has a longer and stranger history than I expected:
- 1998 - ITU-T recommends T.140 as a text conversation protocol for multimedia applications.
- 2000 - RFC 2793 specifies an RTP payload for it.
- 2005 - superseded by RFC 4103.
- It then rose from the ashes when ETSI TS 122 226 was specified.
- Things went quiet again for several years.
- 2019 - the European Commission produces the European Accessibility Act (EAA), and operators begin implementing emergency texting in earnest.
Crucially, the Act does not mandate any specific protocol or technology. Some countries have chosen OTT apps for emergency messaging; others are going with RTT (Real-Time Text) and T.140. There is also RFC 9071 for multi-party texting, which I won’t cover here - though VoiceBlender’s room model would handle it naturally.
The Dangerous Demo
During Kamailio World 2026 I took the chance to implement T.140 in VoiceBlender as part of the Dangerous Demo, led - as always - by James Body. The convention of a Dangerous Demo is that the project should not work, should fail live on stage, or should at least behave differently than intended.
This time everything worked fine. (Probably why I didn’t win the prize. 🙂)
To prove it genuinely works, I also put together a quick demo page that uses VoiceBlender’s WebSocket Streaming Interface (VSI) to exchange T.140 messages over WebRTC. The complete example - demo page and all - lives in the examples/rtt directory of the VoiceBlender repository.
To be fair, I wasn’t breaking new ground here. Back at Kamailio World 2023, Lorenzo Miniero (Meetecho, lead author of the Janus WebRTC gateway) had already explored exactly this problem - bridging SIP-based T.140 Real-Time Text to WebRTC endpoints over data channels - in his talk Real-Time Text and WebRTC. His work, RED redundancy and all, was a useful map of the territory before I set off.
Testing is harder than implementing
There are only a handful of applications you can actually test T.140 texting against:
- Tipcon1 v1.5.1 (commercial)
- eCtouch (commercial)
- pjsua from the pjsip project
Older versions of Linphone had RTT texting support, but it was dropped some time ago.
So, does VoiceBlender need RTT?
Honestly? Probably not. I don’t expect T.140 to be adopted for non-emergency conversations - we have far better alternatives for everyday messaging. That was never the point.
What I wanted to demonstrate is how easy it is to add a new feature like this into VoiceBlender. A protocol that took serious effort to land in established media servers became a focused, working addition here in the span of a conference.
One last remark: RED to the rescue
Since RTT uses RTP as its transport, it needs help to be reliable. To get there, I used RED (RFC 2198) - redundant payload encoding. I believe this was its original, real-world use case. These days RED is everywhere: widely used in WebRTC and in SFU implementations like LiveKit and Janus.
A protocol I once dismissed as ugly turned out to be a small, satisfying lesson in why standards endure - and a good excuse to show how quickly VoiceBlender can grow.