Subscribe
LinkedIn Profile
Twitter Timeline
Old BlogI’ve been looking at the work I did a decade ago. Yep, the Linux Telephony API that Ed Okerson and I designed while at Quicknet. Recently Ed and I have met some folks who are interested in porting that work to a new gateway device (a nifty one too). Seperately I’ve been looking at Android phones too, as well as looking at the femtocell vs 802.11 issues. In short, what’s the future of voice communications?
What struck me the most as I looked at the Android Telephony API is how utterly useless it is for any advanced telephony. There’s nothing much exposed, really, to control the actual phone part of the device! If the July Linux Journal article by Alexander Sirotkin is correct then the telephony portion of the phone is not open at all. I got an email today asking if I knew how to access the low level phone features – and they asked me because they figured that if the phone is linux based, then it must use the Linux Telephony API, right?
I don’t know. I doubt it. I think it should though. The LTAPI provides a fantastic framework to let developers build real telephony capabilities. The LTAPI treats a phone line as if it was just a character device – /dev/phoneN. You open it, read and write audio in native sound frames. You select the audio codec and control the device with IOCTL calls. It’s already in the Linux kernel. Of course we’d have to extend it to support a mobile device – there’s a lot more constants we’d have to define I’m sure, but that’s easy. Ed and I could knock that out quickly. In fact, it would be fun.
But the whole problem of why it’s not already done keeps nagging at me. It seems that the only way to interact with the phone system in the Android API is via the already provided dialer application. Why? If the rest of the stack is open, why is that part NOT open? What motives or reasons could there be?
I’m interested in what you think. Please post a comment. I’d love to know what you think.
[...] the fact (carrier meddling?) that they won’t even expose real telephony interfaces (read my blog about that) and it’s not the iPhone killer some seem tho think it [...]
I’m not a googler, so here are my informed opinions…
Android’s SDK is not particularly well locked down. Users are given one chance to allow an application permission to do what its Manifest says it has access to. This is a single pass/fail all/nothing check. I’d wager most users, just as they don’t read EULAs, don’t check what they’re giving applications access to. Further, because Android allows off-deck (out of app store) software, the potential for damage is fairly large.
Priority is another issue. The pool of people interested in re-implementing tapi or making a custom dialer is small.
For those people (such as yourself) I’d suggest staying out of the SDK (it’s going to be a lot slower than a native C/C++ app) and checking out the source code for Android. Make your modifications there and load a custom build on your device.
The real problem is that to get LTAPI level support – meaning low level access to the telephony events, raw access to the audio stream, etc – then the hardware vendors have to provide enough data about the hardware interfaces to allow device drivers to be built.
I don’t quite buy the notion that the they didn’t expose the interfaces because there’s not enough interest or demand… they exposed a jillion other things that are likely to have little demand. I suspect that in reality it has more to do with non-disclosure agreements and the proprietary nature of some of the low level chips sets. That certainly slowed us down at Quicknet, and remains an issue with some hardware – especially advanced wireless chipsets.
Hello gherlein,
Thank you for the work you Ed Okerson did on the Linux Telephony API.
I’m not a programmer, so I am probably off…
Yet,… can’t we just “re-hack” the Android?
Make a fork?
I am guessing the lack of openess if because of pressure from the mobile carriers.
Thanks for the post!
The critical path to implementing the LTAPI in Android would be access to the detailed hardware information to write the /dev/phone drivers for the phone. Without that we are stuck.
Closed (limited) compared to LTAPI or compared to other phone OSes? There is plenty of telephony stuff you can do without going through the dialer app.
Compared to Blackberry certainly, if you believe the various posts I read (I’m a newbie BB developer). But the point isn’t “there’s plenty that you can do” it’s “why isn’t it more open?”