Firmerware to make SIP phones usable for 0cpm

By: Rick van Rein, OpenFortress


Project goals

When done well, digital telephony could mean a quantum leap in communication. It could do so much more than the plain-old telephony system (POTS) does:

In reality, progress is very limited due to a number of factors. This project aims to give a headstart to a solution to these problems. The problems on the current market are:

Of course not everything is free -- bandwidth is not free, and if you process many simultaneous calls you should certainly invest in good network connectivity before considering a switch to VoIP. But if you are a home user with a decent uplink, you have the basic ingredients for free telephony... free as in in free beer and as in free speech!

Design choices

All development will take place under the following guidelines:

Much of the software for this project is readily available, but has not been packed together because of the lack of critical mass for this solution style. What will have to be added, aside from reverse engineering phones, is a generic firmware application that can be configured at compile-time to match any hardware phone.

This project wants to setup an alternative, more mature approach to SIP, and gain critical mass for that. The approach to do that is developing open source software for telephony based on

The first actual release should at least support all these in a hardware phone. Such a phone could be plugged into an IPv6 environment and be able to call other IPv6 phones instantly. Also, if the IPv6 address that it autoconfigures (the LAN's IPv6 prefix and its MAC address) is publised in the proper places, it can be rang directly. For example, if your POTS-to-SIP provider can relay incoming calls to IPv6, then just enter the phone's address and it would ring for incoming calls on your POTS number!

Additional features may be added as modules, so the simple core has a way of becoming as powerful as the phone's address space can support. A few attractive examples would be:

Practical approach

Note: This firmware analysis is becoming a part of a larger whole. Its pages will move soon. For example, another subproject that has emerged is SIPproxy64.

We hope to achieve a same positive result for hardware manufacturers as OpenWRT has for Linksys, but initially it may be better to just get started through reverse engineering. In the end it would be ideal to integrate the work with the manufacturer's, and perhaps even mark models that are suitable for the alternative firmware.

Although a vast range of devices lends itself for SIP connectivity, we will initially concentrate on a simple, ethernet-connected phone. The first version of this firmware will be built on the popular, commonly available and low-cost hardware of Grandstream. The hardware is quite good, but the firmware has its problems. Think of directory buttons that won't work when passing on calls.

We will initially work on Budgetone 101/102 phones. These are fairly simple, and will make the work easier to do. Later, we can expand to include more models of the same manufacturer as well as other series from other manufacturers.

The eventual goal is to add more kinds of hardware to this mix. For instance, the Linksys SPA phones are also very popular, but their firmware is so incredibly flexible that they seem a bit daunting to approach at this time. Note that the hardware in Linksys SPA phones is quite similar; it uses another type of processor and the buttons will be wired differently, but that's about it.

Other phones that tickle our interest are the Siemens DECT phones, and/or their Targa clones. These come in a large variety of shapes and forms, but generally they are Linux-based, so they easily have the space to run an application that is prepared to run on the smaller devices of Grandstream.

Concrete tasks

Like working on hardware? Looking for an interesting challenge? Following is a work list for this project, where each task is small enough for a rainy weekend. You are quite welcome to pick up on any of them and help this project advance!

Please document your work in RST. Send me your text and I will be happy to add it. I'd rather do this manually than having to fight spam. (Yes, I know, the Internet is broken in more than one way.) The sources of all HTML documents is available if you replace .html in the URL with .rst and save it to disk.

  1. Charting hardware: What is the bill of materials of a Grandstream phone? Photo's are cool!

    Done 2010-08-22: See the BT102 PCB for this information.

    Done 2010-09-19: See the GXP2020 PCB for this information.

    Done 2010-09-22: See the BT200 PCB for this information.

    Done 2010-09-28: See the HT486 PCB for this information.

  2. JTAG hookup: How can a JTAG-cable be attached, how can its JTAG connector be made to work under UrJTAG or OpenOCD?

    The JTAG pinout is on JP1 along with bootloader support.

  3. Flash dumping: If we can dump the contents of Flash memory over JTAG, we can solve the biggest problem with these phones, being that upgrades are not always reliable and reverting upgrades is not possible.

  4. Flash rewrite: How to write flash images back to the device over JTAG?

  5. Bootlog dump: How to find a place on the device that dumps boot code?

    It is probably worthwhile trying buffered serial port 1 for output.

    Done 2010-09-29: This step is probably a waste of time; the impression I get from the phone is that it won't log during boot like a starting Linux or RedBoot system does; it probably limits itself to interaction with the display and LEDs.

  6. Alternate booting: How to make the phone dump "Hello world" on the bootlog?

    Read about the bootloader and buffered serial port 1.

    Done 2010-09-29: As with the previous point, this attention to the serial port is most likely a waste of time.

  7. Button scan: How can we scan for buttons and switches attached to the base board?

  8. LED driving: How do we switch the LEDs on the device to their different colours? Flashing can be added at some later point.

  9. Sleeping: How can we sleep optimally? Wakeups are rather explicit on a phone, as a result of network traffic, users poking keys and timers expiring. This is the place where lots of power can be saved, namely for the phone in sleep mode.

  10. Phone hardware: Make a simple application that sleeps while it waits for user interaction and other hardware-related events. Have it display such events on any output device, and wait on all other times. Aim to evade polling and instead sleep as deeply as possible. If all is working, also include a timer-driven action as well.

  11. LCD driving: How do we drive the display in the various forms of the device? There is a plastic-covered LCD driver chip under the LCD itself. To gain access, straighten the metal fasteners on the backside of the PCB that holds the LCD and use a screwdriver to force the metal around the LCD up.

  12. Networking: How to port uIP or another network stack with IPv6 support to these phones? Is it better to use RTEMS' BSD-based stack? How do we make it autoconfigure address, router, DNS?

  13. pjSIP or oSIP: Can we get pjSIP running under this core and on the limited hardware available? Or would oSIP be a better choice? Both have detailed documentation, making them suitable for a rock-solid implementation. Do we need a realtime kernel underneath?

  14. Encryption: Choose and implement one or more frameworks for end-to-end encryption.

    Done 2010-09-29: The choice has been firmly established on ZRTP because that is the only mechanism that has no requirement for infrastructure maintained by other parties. The device can usually show call security status, for instance by switching the voicemail LED to on/off/flashing for insecure/secure/verifyneeded.

  15. Online update: Is there a way to upgrade a phone under the original firmware to something of our own making?

    For this, an analysis of the original flash contents may be very useful. Especially a disassembly of the relatively small Grandstream bootloader may prove to be useful to understand in detail how a software-only update would be possible.

    This is partly done. The original firmware analysis shows that the structure of the BIN image files is really straightforward. The only problem is the signature, which seems to rely on a key that is probably present inside the phone, where it is used to verify the signatures.