NLUUG: Filling the gaps in open telephony
On May 12, NLUUG held its Spring Conference with the theme "Open is efficient". With such a general theme, it won't be a surprise that the program was a mix of talks about policy matters, case studies, and technical talks in various domains. However, two talks were particularly interesting because they pinpointed some gaps in our current solutions for open (source) telephony.
Open SIP firmware
The Dutch cryptographer Rick van Rein presented [PDF] his project to build open source firmware for SIP (Session Initiation Protocol) telephony. His vision is that SIP holds great promises for the future of telephony, but that nobody is unleashing its potential:
All this holds for SIP devices, but there's another type of SIP phone
that currently has much more advanced functionality: the softphones (software implementing SIP functionality on a computer or smartphone). According to van Rein, the softphone market is where the real innovation is happening, with advanced features such as presence settings, IPv6 connectivity, and end-to-end encryption of phone calls with ZRTP (a cryptographic key-agreement protocol to negotiate the keys for encryption in VoIP calls). In short, open source is great at handling SIP functionality, but this doesn't help the people that have bought a SIP phone (the hardware), because the firmware of these devices remains "as open as an oyster
".
Van Rein's goal is to build open source firmware that can be installed on such a SIP device instead of its original closed firmware, and ultimately it should be able to bring the advanced SIP features of softphones to these phones too. The project is called 0cpm, and is partially funded by NLnet Foundation. As a proof of concept, van Rein is now implementing his firmware for the Grandstream BT200, a fairly typical and affordable SIP phone for home and office use, but the framework is designed with portability in mind. The 0cpm firmware, called Firmerware, is GPLv3 licensed.
As some of these SIP phones have only 256K of RAM, Linux would be too big an operating system to run on them; even its microcontroller cousin uClinux would be too large. So van Rein wrote his own tickless realtime operating system, with a footprint of around 13K. Together with the network stack and the application, this fits well into the 512K NOR flash that is typical for smaller devices. According to van Rein, it's important that 0cpm is able to run on cheap and energy efficient phones (because they're always on) with limited resources, so he doesn't have the luxury to use Linux. At the bottom of the 0cpm firmware stack, you need drivers for all chips and peripherals of the phone, and on top of it there will be some applications running, such as a SIP phone application.
One of the main goals of the 0cpm project is to enable SIP on IPv6. For most end users, current SIP phones are too complex to configure due to a dependency on IPv4 and NAT routers. To tackle these issues, most SIP vendors end up passing all traffic through their own servers, but of course this isn't free. Van Rein believes that only an IPv6 SIP project will be able to offer an open but easy-to-configure SIP experience to end users. With IPv6, direct calls are always possible, and with technologies like ITAD (defined in RFC 3219) and ENUM (E.164 NUmber Mapping), SIP telephone numbers can be found using a DNS-based lookup. By combining all these existing pieces in the 0cpm project, users can finally call freely. Not only free as in beer (that's where the project's name comes from, "zero cents per minute"), but also free as in speech, van Rein emphasizes. For devices that have no IPv6 connectivity whatsoever, the 0cpm firmware will fall back to a suitable device-local tunnel for IPv6 access.
Reverse engineering
But before we get there, there's a lot of reverse engineering to do. In
his talk at the NLUUG conference, van Rein gave some tips and tricks he
used to reverse engineer the inner workings of his Grandstream BT200
device. One of the tips he gave was to use the Logical Link Control
(LLC) network protocols, which are extremely easy to implement and come in
handy for reverse engineering. The LLC1 protocol offers a trivial datagram
service directly over Ethernet and it has minimal requirements: just
memory, network and booting code. A stand-alone LLC1 image is about 10K,
including console access. You can install a bootloader using TFTP over LLC1
instead of TFTP over UDP. In a similar way you can connect to the console
over LLC2 (a trivial stream service) instead of over TCP. It has the same
minimal requirements as LLC1 and adds about 200 lines of C code. Van Rein
calls LLC "a generally useful tool for reverse engineering
",
emphasizing that with LLC2 it's even possible to show the boot logs before
the device gets an IP address.
But when reverse engineering phone hardware, you should first be able to figure out what each component is doing. In general, most phones contain a System-on-Chip, RAM, flash storage, Ethernet connectivity, and GPIO (General Purpose Input/Output) pins. Reverse engineering is more of an art than a science, and it includes identifying the components, gathering datasheets, and finding an open source compiler toolchain. Finally, you have to figure out a way to launch your own code on the device. Then you can start writing some "applications" to test your drivers, for instance an application that flashes the LEDs to test the drivers for timers and interrupts, and an application that shows typed numbers to test the drivers for the keys and the display. By building various of these simple applications, you can test the drivers individually. The 0cpm software contains these applications to make porting easier. Van Rein is currently still working on the drivers, and he has a simple application that gets an IPv6 address. He hopes to be able to show a working phone application in the second half of this year.
In short, van Rein truly believes that progress in SIP phones will come from open source firmware, and with the 0cpm project he wants to build this firmware. While the current proof of concept phone is the Grandstream BT200, he invites anyone to port to their own hardware. For interested developers, there's a Git repository with the source code (git://git.0cpm.org/firmerware/, which is only accessible over IPv6). Reverse engineering current SIP phone hardware is a big task, and van Rein emphasizes that 0cpm is not even alpha-quality code. If the project can generate a critical mass, its vision of generic SIP firmware could come true, in much the same way as we now have free firmware projects such as OpenWrt and DD-WRT for wireless routers.
A nice by-product will be that 0cpm allows a truly secure way of calling each other, thanks to the direct IPv6 connectivity without any central server that can wiretap all media streams, as well as the encryption and mutual authentication offered by the ZRTP protocol. On a related note, GNU SIP Witch 1.0 was released last week, which offers a secure peer-to-peer SIP server that lets ZRTP phones talk without the need for an intermediate service provider.
An "open" GSM network operator
Another telephony-related project that was presented at the NLUUG conference is Limesco [in Dutch], an "open" and transparent pan-European not-for-profit GSM network. Mark van Cuijck, one of the three founders, presented the rationale behind this project:
On the other hand, the telephones and some of the telecom infrastructure are becoming more and more open. Van Cuijck mentioned the popular Android platform, which is largely open source and has a big open applications ecosystem. There's also OsmocomBB, an open source GSM baseband software implementation, and OpenBTS, an open source software-based implementation of a GSM base station. And in the SIP domain, we have open source SIP softphones such as Ekiga and server software like Asterisk and FreeSWITCH. But what good are all these open source programs if the mobile network operators are very restrictive about what happens on their network? That's where Limesco would come in.
Limesco is still in research phase, so even the founders aren't sure yet that it will become reality. They are researching now whether it would be financially and technically viable to become a mobile virtual network operator (using another operator's infrastructure) aiming at a target audience of users that value freedom, openness, and transparency. They have published a survey that has been filled out by 1200 people, and they are talking with companies in the telecom market to get an idea about the costs. By June 1, they want to decide whether to go further with the project or whether to abandon it.
A targeted approach
Whatever will happen with the project, the idea is interesting, and it seems like it should appeal to enough people to make it a viable business model. There are already a lot of mobile virtual network operators that have a specific target audience. For instance, van Cuijck mentioned the Dutch mobile operator Telesur, which targets Surinamese inhabitants of the Netherlands. Many of these people still have relatives in this former colony of the Netherlands, and Telesur is responding by offering them very cheap call rates between the Netherlands and Suriname. It's this kind of targeted approach that the Limesco founders are thinking about, but this time targeted at the "hacker" community.
Van Cuijck presented some ideas. One of the goals of Limesco is to be more transparent about the call rates:
The preliminary results from the survey also show that the respondents are interested in knowing what data Limesco would store about the subscribers. Each mobile network operator has to store certain data and cooperate with the police, and Limesco would have to obey these laws as any other network operator, but it wants to make the difference by being completely transparent about it.
Another goal is to give the subscribers the freedom to manage their own services. For instance, instead of offering services on the level of the operator network, subscribers could get the capability to manage their own voice mail application, their own conference call implementation, and so on. Subscribers could also get the ability to block certain numbers, and it should even be possible to link two mobile phone numbers to one SIM card or to have two SIM cards linked to the same mobile phone number. All these examples van Cuijck mentioned are clearly features that are not interesting for most of the public but that could be interesting for a niche audience of do-it-yourself people.
This all sounds interesting, but it's not yet reality, and it might be that the project is a bit naïve. One of the people in the audience made an excellent observation after van Cuijck's talk: a mobile operator makes its profit because of the difference in how much you think you call and how much you call in reality. All these various call plans only have one goal: confuse the subscribers and let them choose a suboptimal plan for their situation. So if Limesco wants to be completely transparent about its call rates, it loses the information asymmetry to its customers, so it will make less profit than the other mobile operators. While this observation may be true, though, your author thinks that Limesco can have a competitive advantage over other mobile operators with its do-it-yourself approach: if its subscribers are not interested in the many services other operators offer, like voice mail, conference calls, call forwarding, and so on, Limesco doesn't have to build or outsource these services, and maybe that's how it can lower the costs for the infrastructure it rents.
Filling the gaps in open telephony
Both 0cpm and Limesco are interesting projects in that they are filling the few remaining gaps in our open telephony infrastructure. We have good open source SIP softphones like Ekiga, we have good SIP server software like Asterisk, we even have open source GSM base station software such as OpenBTS and open source GSM baseband software like OsmocomBB, but we still lack two important components to have a fully open and transparent telephony experience: open firmware for SIP phones, and a mobile network operator that doesn't hamper what we can do with our mobile phone connection. Perhaps we will see that change in the relatively near future.
Index entries for this article | |
---|---|
GuestArticles | Vervloesem, Koen |
Conference | Netherlands Unix Users Group Conference/2011 |
Posted May 19, 2011 6:37 UTC (Thu)
by Cato (guest, #7643)
[Link]
Posted May 19, 2011 14:34 UTC (Thu)
by wingo (guest, #26929)
[Link] (1 responses)
Cool!
Posted May 23, 2011 6:15 UTC (Mon)
by jzbiciak (guest, #5246)
[Link]
This is totally off topic, but I find it immensely amusing that "wingo", which is one inverted character away from "mingo" (aka. Ingo Molnar), commented on Rick van Rein's RTOS, where "Rick van Rein" is a very short edit distance from Rik van Riel...
For a brief second I wondered if I was in a parallel universe. ;-)
(Not to take away from anyone's identities or accomplishments by confusing them with each other. I just found it an amusing set of parallels.)
Posted May 19, 2011 18:00 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (2 responses)
Posted May 20, 2011 11:06 UTC (Fri)
by sorpigal (guest, #36106)
[Link] (1 responses)
Posted May 20, 2011 15:58 UTC (Fri)
by iabervon (subscriber, #722)
[Link]
Posted May 21, 2011 23:17 UTC (Sat)
by gerdesj (subscriber, #5446)
[Link]
I can't say they lack for features given that they are extensible via a web server and a well documented API. They even come with a set of demo scripts which do 95% of what most people would ever want out of a handset packaged up for several major trix based distros: PIAF, Elastix, Trixbox etc.
As for the built in functionality - they are each virtually a PBX on their own, before you add a "real one".
I'm starting to sound like an advert here ...
No IPv6 on them but then it is near impossible to get an ADSL router with it in the UK without custom firmware.
Posted May 27, 2011 7:08 UTC (Fri)
by henning (guest, #13406)
[Link]
NLUUG: Filling the gaps in open telephony
there is statement, and there is understatement
there is statement, and there is understatement
NLUUG: Filling the gaps in open telephony
NLUUG: Filling the gaps in open telephony
NLUUG: Filling the gaps in open telephony
NLUUG: Filling the gaps in open telephony
To point out some common misconception: "..we have good SIP server software like Asterisk.." - Asterisk is not usable to run a SIP service on a bigger scale, like a ISP needs, as its more a PBX. The same also is true for Freeswitch. For building scalable, performance and available SIP infrastructures people normally use a SIP proxy or router, something like Kamailio. (Disclaimer: I'm involved in Kamailio development.)
NLUUG: Filling the gaps in open telephony