Developing mobile VoIP: or why I hate all the mobile industry
PS: It might be also interesting for you to read my first essay on how we started our GTalk2VoIP project.
Introduction
Since the very start of GTalk2VoIP project early in 2006 we at GTalk2VoIP TEAM had been nursing the idea of creating something very Google Talk like for mobile phones which could be used to make voice calls over GPRS (and WIFI) as simple as it is made in Google Talk: you see a contact of your friend, if he/she is present, you press Call button and you talk. So easy and so powerful, isn’t it ? On the opposite, the mainstream consumer VoIP software (so called soft-phones) was and still is very unfriendly: simply downloading a SIP phone onto your PC won’t make you able to make calls over the internet instantly, you will need to obtain a SIP account, configure it into your soft-phone, define a dozen of other settings like STUN server, dialing schemes depending on your SIP provider, etc, and only after that, if you were lucky enough, you will be able to add your friend’s SIP URI into list of contacts, then call. Of course being able to manage as many settings is very positive feature for a power user, but for an average this kind of mainstream VoIP is very frightening and totally unacceptable. Sure, there are some projects like Gizmo Project (now Gizmo5) which are desperately trying to make things better, but still…
So at that time early in spring of 2006 we came to a thought -- we want all that Google Talk style VoIP on our brand new mobile phones, with all the power of presence and Jabber based IM chat, we want it to be able to run through dominating GPRS/EDGE service of GSM networks as well as through WIFI hotspots, we want it to be easily and automatically switching between available hotspots like any GSM phone switches between towers, we wish it had a Google Talk like user interface. Why ? Because it’s clean, neat and intuitive, there’s nothing obsolete in its design like innumerous features of Yahoo! Messenger, nothing irritating and slowing down like in Live Messenger, and it is not using stone-age protocol like AIM. But most of all we want it to be completely based on open standards.
The more we discussed the idea of this powerful mobile “VoIP+Presence+Chat” in betweens of our circles and friends the more intriguing it became to start developing it on our own. Meanwhile, we quite successfully ran our GTalk2VoIP gatewaying service, which gave us invaluable experience developing VoIP software, understanding open standards and digging up closed ones. So in June 2006 instead of spending up our vacations sipping up cold coconuts somewhere on a shore of Thailand [1], we started coding. After analyzing mobile phone markets a little we came to a, as it later appeared, to false decision to start developing for “Java to Micro Extension” (J2ME) platform. Of course we wanted our mobile software to be able to run on as many mobile handsets as possible, thus we studied MIDP 2.0 profiles and found them quite sufficient to achieve our goals. Poor guys we were.
Losing faith in Java
In the mid August 2006 when a first “almost” working prototype of the application was ready with all the IM and Presence functionality we started to investigate VoIP stuff in Java. We discovered a number of Java based VoIP projects, including SIP protocol implementation as well as Java port of the famous open-source and patent-free Speex codec which both sound very promising, because we needed Speex to be able to fit into a very narrow and laggy GPRS link. But, after a deep experimental research we found it very disappointing that Java VM is so much slowing down computational tasks that it became totally impossible to run Java Speex on any existing mobile phone due to lack of CPU cycles. Another J2ME related problem lurked and revealed was total absence of possibility to set up full-duplex audio streaming. We played with a number of hacks [2] and almost succeeded in making it working, but all these hacks were very much depending on implementation of Java VM on a phone and it did not work on most handsets. Together with the codec issue it appeared to us as an unsolvable programmatical problem. I cannot express how much frustrated we were, how deeply disappointing and faith-losing the whole mobile industry appeared to us, how the whole world once in a sudden turned against our bright blue ideas, oh doh!
And the proper solution was found, the solution was -- to take a rest and get all the delight of sunny days of ending summer. During this unplanned vacation we spend time riding inline skates, discussing our problems with other friends-programmers, in betweens hacking new protocols, namely MSN, for GTalk2VoIP project to get some satisfaction and to restore coders’ mental wellbeings :-). Meanwhile some conclusions were made: 1. the whole idea of programming in Java became irritating, 2. there’s no some “microsoft” in mobile industry hence you cannot write a piece of software that could be ran on dominating number of phone models, and 3. the whole mobile industry is so corrupted that it just sucks! Mobile carriers suck, but most of all suck all the handset vendors who do not obey standards and worship mobile carriers and afraid of taking any step that can disappoint any of the carriers. This is completely bullshit industry and one must do something to it, and there will come a day of revolution and revelation I believe! :-) [3]
Talkonaut and callback based VoIP
As long as we had an almost working mobile IM chat application (of course it had plenty of bugs and lacked some valuable features) we decided to give it a chance to meet some users. But, we still coped with the idea of mobile VoIP, so as we had another very interesting VoIP project running, we decided to play with idea of “VoIP via Callback” implementing server side functionality based on GTalk2VoIP [4]. Basically it’s quite simple: when a user wants to make a VoIP call, it sends some command to a server/service by the means of the application menus. A server then initiates two standard VoIP calls (legs), one to user’s mobile phone number, another – to called party. When both calls get answered, server merges these two legs into a single call thus connecting two persons. Since both calls are treated as incoming calls they could be 100% free in most of the world except for North America. The only problem here was the charges for VoIP calls made through standard VoIP infrastructure and we thought we could rely that on user’s shoulders: those who want or need to make VoIP calls to their friends overseas with a single click on the contact list, they easily can do that. But the whole feature turned into paid service, hence required users to add credits to their GTalk2VoIP accounts.
The integration with GTalk2VoIP was easy and completed in a month. We made our best to make it as transparent for users as it was possible: a single click on Call menu in front of any contact in the roster instantly initiated callback service, which produced incoming GSM call onto user’s handset as long as the user has positive balance. We added features to check call costs, to choose VoIP carriers from the list of available in GTalk2VoIP system, to add credits, etc. Although all this had over-complicated the initial idea of cool and easy VoIP, it still provided a lot of new and revolutionary capabilities to our mobile application users: 1. it allowed users to choose between different VoIP carriers, 2. allowed users to add their own SIP accounts and use them to make calls thus to avoid adding credits to GTalk2VoIP accounts, 3. it provided all the VoIM gatewaying features of our GTalk2VoIP project.
In mid November 2006 after a load of time spent on debugging and testing the application on many different mobile handsets, a first version of our mobile IM chat + callback VoIP application was released with the code name Talkonaut [5]. A week before the release we set up a project related web site at , stuffed it up with FAQs, HowTos and screen-shots, we added an Over-The-Air download feature (sending SMS downloadable link), etc. So, everything was ready for pretty much successful start :-). I wrote a short overview of our new project and product and set it over to a bunch of mobile related blogs, waiting for bloggers to cover us and downloads to get rise high. In a week nothing was heard about our application neither on the web nor in blogs until someone posted a link on Digg.
I fail to understand how Digg society works or behaves, every time we were trying to post some link to our project’s new cool feature on that site, it either got buried instantly or just went unnoticed. But for this time it was something very different, the link to Talkonaut site got to the front page of Digg pretty soon and been kept there for several hours providing a flow of newcomers, so downloads skyrocketed. In half a day we got 5000 downloads which I think was pretty good for an unknown piece of software made by a bunch of guys from Siberia :-).
Unfortunately, our little happiness did not last long and soon it was spoiled by the fact that most of the downloaders failed to run our software on their mobiles. It appeared that our application refused to work on any particular mobile phone which we did not test it on. That was another kick from the mobile phone industry. By not supporting or loosely supporting J2ME standards handset vendors made it virtually impossible to write portable mobile applications: for every vendor, for every particular handset model, one needs to write dozens of workarounds to make application work and use most of MIDP APIs. Cannot say we were not ready for such a treat, so we started to gather feedbacks, and with a great help from our early adopters in a couple of months we managed to overcome and fix most of the bugs in Java VMs on most phones (the only bug that still exists is a memory leak in bogus Java VM with which Nokia still equips their phones and is not going to fix it any time soon!).
Second and third releases of our Talkonaut mobile software were made public in March and July 2007 accordingly. All that time we had been pumping up our application with cool features, like file transfer, multi-user chat conferencing, other IM protocols like MSN, Yahoo, AIM and ICQ, extra voice features, improved graphics, support for qwerty keyboards, etc. With the third release Talkonaut became very powerful IM chat client and appeared to be quite popular (so popular that people on jabber.org main conference, to whom I apologies, started to hate Talkonaut because it brought them so many newbies who didn’t care much about Jabber only seeking for cyber-sex or something [6]). Yet callback based VoIP functionality was not used much, as we think due to a number of reasons: 1) it was not easy to get used to callbacks, 2) it often fails to work due to fails on VoIP carriers’ networks, 3) it still was a paid service. And the last reason was very significant one. With a growing number of free calling services popping up daily on the Net (mostly Silicon Valley based and backed by a huge VC money cow) it became not only hard to promote any paid calling service, but the whole idea started to sound very offensive. Society demands and expects to see 100% free international calling services, as we predicted to see the market developing this way even in early 2006.
Ideas never die!
Right after the second release of our Java based Talkonaut, as long as we got some spare time, we turned back to our initial idea of mobile VoIP over GPRS, but from a slightly different angle. We started to investigate different mobile platforms for possibilities to implement VoIP stuff. What we were looking for was pretty simple: 1) a native C/C++ API which permits raw access to audio, 2) BSD style networking, 3) downloadable SDK, docs and developer support. Availability of such mobile systems on the market did not surprise us by a large scale of options -- there were only two of them: Windows Mobile and Symbian. Both platforms offered a free downloadable SDK, some docs and technical forums for software developers, so we started to play with both systems at once in hope to find out which is best. Keeping in mind our previous experience coding for UNIX-like systems, although we did not like Windows, but Windows Mobile became an OS of our choice, because: first, it is POSIX compatible, has BSD sockets, and second – all my efforts to compile a simple HelloWorld for Symbian did not succeed with in a week. Instead the further I tried to understand how to create a simple application (without all the hassle around CActiveObject), the deeper it buried me into Symbian internals, so finally I decided I won’t withstand long coding for such a different OS. On the opposite, Windows Mobile API appeared to be very developer-friendly and quite familiar to us.
Thus in spring 2007 we decided to start with some VoIP library, which we thought should rest on Jingle Audio protocol, same as in Google Talk, and use open-source Speex codec that is also present in Google Talk. Coding for Windows Mobile was pretty easy and in June 2007 we had our own implementation of Jingle Audio including some test command line XMPP tool which could set up VoIP calls both to Google Talk and to our GTalk2VoIP gateway. The whole library was less than 2000 lines of C++ code [7], and its existence so much inspired us, so we believed in feasibility of our bright idea of mobile VoIP again. Now, the problem was pretty simple: to port some 30k lines of Java code into C++ :-).
How we got stuck into Symbian S60 swamp
As some one said “we don’t need no easy ways”, before beginning porting Talkonaut from J2ME to Windows Mobile, we decided to dig up some Symbian stuff in hope to find out if VoIP possible on Symbian at all. Of course there are some Nokia phones that are equipped with SIP stack already and appropriate SIP API, but this API appeared to be not publicly available (means you will have to pay to Nokia to get some libs and docs) and it was intentionally locked to use WIFI connection only (no VoIP over GPRS – no need to treat the Dragon). Want we thought we could do was to port our 2000 lines of C++ code from Windows Mobile to Symbian, as long as Symbian API provides all the access to raw audio data and networking.
After a deep study of developer documentations, forums and code snippets I finally managed to compile some examples to Symbian S60 3rd edition. It must be said here, that somehow Nokia with the friends during the last 10 years succeeded to produce such a load of different and totally incompatible Symbians, so they have three different Symbians S40 for cheap handsets, they have Symbian S80 for expensive smart-phones, again they have three different Symbians S60 for very expensive smart-phones, they have lots of other Symbians for every day in your life, and they even plan to release more! [8] It was a great question to what Symbian should we start porting our VoIP stuff first? Reading some marketing research paper we discovered that the lion’s share of Nokia’s smart-phones that had been sold with in last two years were based on S60 branch, among which there were two most popular versions: 2nd edition and 3rd edition. It was also stated in the article that Nokia plans to develop this branch and new smart-phones will be released on this OS. Beside the research paper, we already had a couple of brand new nokias (E60 and E61) which were S60 3rd edition based, so developing for S60 3rd was considered as perspective :-).
Thus, as soon as I figured out how to build simple console based applications for S60, so it allowed me to use my beloved printf() for debugging purpose, I begun to dash my way to audio device access, while my colleague sunk deep into the dust and bones of GUI programming for this same OS. Another thing, or quite a feature of Symbian SDK, that must be mentioned here, is a strict resistance of any source code example (which is officially provided by Symbian Ltd or Nokia to help developers) I could find, to compile and work from the first try. Usually, when a developer wants to see how some particular feature works, she gets some official source code example, compiles it, runs it in an emulator or on a real device and sees how feature is done. Not that easy with Symbian: to make it working one always has to tweak the Build and MMP files, sometimes fix UIDs in source code and even then compiling for device and emulator are two very different things [9]. Nonetheless, with Google’s help I found an official example which promised to do a direct access to DevSound to produce full-duplex audio streaming and even to access hardware codecs [10] over some APS Server component. I managed to compile it easily, but hack no! I was not able even to install it on my phone because, as I instantly knew, it used some “capabilities” that are not open for public use, hence developers need to a) obtain a developer certification key from Symbian Ltd, b) sign their application with that key and only after that the application will be permitted to run on a limited number of phones with predefined list of IMEIs. In other words this means: no way to give your application to anyone who is not a part of your developer circle until you finish development of your application and ready to sign it by some Symbian Ltd approved Test House for some significant amount of euros [11]. More simply, it means: if you are not ready to invest money and time to pass over the bureaucracy, you cannot develop anything interesting for Symbian. Even if you are ready for that, the development process can be spread far long in time and you don’t have a chance to fix any bugs discovered after you passed the test! This was the second kick from mobile industry. I was not prepared for such a treat from Nokia. None of us was.
We searched through the forums and found that not only this useful DevSound API was protected, but a lot number of the very interesting and potentially useful APIs were also in the same state. Moreover, some APIs are subject for sell by Nokia as SDK plug-ins for a separate price and require developers to sign NDAs and other crap-papers. What the sssssschnitzel!
For this time it did not stop us. I had a feeling that there must be a way to overcome this artificial limitation, there were some unsigned applications for S60 3rd freely available on the Net that did audio recording and playback the way we needed for our development, so there was a hope. And this way was found. Firstly, I posted my questions on a number of Symbian related forums. I have to say, that I don’t like asking for technical help from forums or in any other way, I like hacking up things on my own, trying, searching and discovering. But that was a special case, so I asked. You might guess that the only type of answers I got from all the “Nokia Forum Champions” was this: “use DevSound and APS Server, you oxymoron” and it was very inspiring of course ;-). Then, I searched through header files in SDK and found very interesting pair of classes CMdaAudioInputStream and CMdaAudioOutputStream, I even found some sample codes illustrating how to use them each in separate to record and play raw audio data, but nobody had spoiled any light on how to use these classes simultaneously to achieve full-duplex. After a week of trials and errors I managed to solve this problem, it was real easy and even had some elegance. Thus, within a couple of days after, I ported the rest of my C++ code from Windows Mobile to Symbian, so we now got a working VoIP library and a console based test application which could make calls to Google Talk from our nokias.
Soon, after we made a third release of J2ME version of Talkonaut, satisfied with our achievements we went to have some rest on a sea shore.
Another Symbian, another problem
Some time later we decided that having VoIP library for Windows Mobile 5/6 and Symbian S60 3rd is very cool, but it would be lots cooler to have it also running on S60 2nd edition, since there were (and still are) a lot many owners of such handsets, mostly Nokia N70 devices. Besides we kept receiving more and more requests from our devoted users to “fix” Talkonaut crashes on S60 2nd caused by memory leaks in the Java VM, and the only way to fix it was to rewrite Talkonaut in C/C++ so it would be a native application to run, thus no dependence on buggy Java. So we started porting our VoIP library and GUI framework to this new flavor of Symbian.
As you might guess, we instantly stumbled upon another bunch of very hard solving programmatical problems of Symbian architecture. The root of the issues was this: Symbian S60 2nd Edition OS developers somehow falsely presumed that all Symbian GUI applications would be run not as a stand-alone apps, but like some DLLs loadable by a single “application launcher”. I don’t actually know what sort of problem they were trying to fix by this bogus OS architecture tweak [12], but it had the following consequences: 1) none of the GUI apps may have writable global data (we had many because we use Speex C library which had tons of globally defined array tables), 2) DDLs may not use or request to allocate on heap more than 1M of RAM, which was also violating our needs. Of course there was a way to have normal EXE-style applications on that OS, without these “1M RAM” and “global data” issues, but it was available for console or none-GUI applications only. Initiating a system GUI framework from EXE-style application was not only undocumented, it was even proclaimed as impossible! Sure I felt this was not true since the whole system application launcher is an EXE program and it does all the tricks to set up GUI framework right before running each DLL application user starts.
It was the second time I applied to Nokia’s developer support forum in hope to solve DLL-EXE problem or trying to figure out how to start GUI from EXE. Ideas expressed to me were quite the following: 1) you must obey the rules set by OS developers no matter how ridiculous they sound, 2) remove all your global writable data, 3) split up your application into GUI and none-GUI parts and run each separately as a client/server architecture. Well... Yes, of course, I could spend loads of time hacking Speex library and could get rid of all the global data from it, but the essential idea to split a single and quite simple application in to a bunch of programs communicating each others over some client-server style RPC was totally against my and my colleagues’ programming habits, it was against the common sense and it was just weird! So, enarmed with Interactive Disassembler and some Debugger, I started to back-trace EIKSTART.DLL, the system very library which does all the GUI framework initialization for DLL applications. In two weeks I managed to reveal a set of 10 lines of pretty standard API calls which did the trick, so now we could easily run GUI right from our EXE-style applications and we were not bound to the 1M RAM limit, and hell no-one and nothing cared about global writable data in Speex or any of the libraries we used! Bravo Symbian OS developers who made a really developer “friendly” system. Doh!
Porting Java Talkonaut to C/C++
Thus, in September 2007 we had a Windows Mobile VoIP library, the same library and our own GUI framework ported to Symbian S60 3rd and 2nd Editions. Altogether quite enough to start porting rest of Talkonaut functionality from Java to C++. Since we had all the GUI stuff already working for Symbian, we decided to put up with Symbian first.
Thank to Java syntax and semantics, which by some accident were pretty well derived from C++ (God bless Java inventors), it was a semi-mechanic work to translate Java classes into C++ classes, the rest worked by itself. The only thing we had to do was to separate definitions of classes off from their implementations, i.e. to spread stuff between .h and .cpp files. It took another couple of weeks of midnight work from my colleague to accomplish this task and move all the 30k lines of Java into C++ code. So, in late October of 2007, a first version of Talkonaut for Symbian S60 3rd Edition came to life. Although it was hell-buggy and perpetually crashing, it was a real happiness to all our small team, because it worked, it could IM chat and make VoIP calls to Google Talk and to other Talkonauts over GPRS or WIFI in a one-click-way. We were happy because we managed to solve all the artificial problems rolled out along they way we traveled. And that was cool!
Next two months we dedicated to fixing bugs in our libraries, applying workarounds to overcome bugs in Symbian [13] and adding new VoIP related features to the application itself. It must be said that the whole Symbian OS is such a weird and buggy thing that the word “workaround” became our mantra. There are hundreds of workarounds currently present in our Talkonaut for S60 and the whole source code is bleeding of #ifdef’s and other run-time ifs. Another problem we faced developing for Symbian was an extreme difficulty to debug code that is heavily loaded with RThreads running separate CActiveScheduler in each. For some period of time we used standard ECMT logger shipped with the SDK, but after some weird bug-fixing cases we discovered that this damn ECMT thing produces so many untraceable crashes, so we finally abandoned it. Instead, I coded a simple class that provided API for logging using standard UNIX “syslog” facility. It was small, fast and reliable and eased our lives a lot.
Issues
Although we have succeeded in implementing mobile VoIP software, I would like to express some issues that do exist in this field.
First, as I already mentioned it, we don’t have options in mobile market. Both platforms, Symbian and Windows Mobile are closed proprietary stuff, they lack good documentation, and the companies they belong to are hardly interested in making developers’ life easier. Instead, they are adding more and more artificial limitations and this makes you solve eternal ephemeral problems rather then concentrating on your problem domain. The world definitely needs some alternative, universal and open source mobile platform, and maybe even open hardware. As on the date of writing this essay there are two very interesting projects known to me that are going on: 1. Google released their Android mobile OS in December 2007, 2. Taiwan based company OpenMoko is developing totally open mobile hardware called Neo1973, which based on Linux and open source software. Android has not yet been available on any real hardware device, and I wish it would never be, because Android, in essence, is just another incarnation of mobile Java. I may sound bogus, but Java is real evil! Avoid Java as much as you can! As for OpenMoko project, I’m very fond of these guys, they are doing Right Thing and advancing in right direction. They have all the charisma, but most likely they lack some big $$ to establish proper promotion. So let me wish them luck and a big buck.
Second, oh, this beast -- General Packet Radio Service. I often wonder how in 21st century where we have all the Terabits/sec international submarine cables tangling the Globe, such a bogus stone-age technology found its way to become so uneliminatingly popular and so expensive. How long will it take to cease its domination ? Yes, we managed to make our Talkonaut software to produce quite acceptable voice quality over GPRS links, but the latency GPRS introduces makes it sometimes very hard to conduct a normal conversation: it rather turns into something like an old-style PTT radio when each party has to wait a couple of seconds before start talking.
Epilogue
Reading this essay one could ask “what are you trying to get by writing this, do you after some fame or what? who cares about your negative experience of uncertain developer life”? Well, yes some fame won’t be bad for us and our application, we devoted so much time to our development so we believe it deserves to be noticed. So please go try our Talkonaut software [15] and let us know what you think about it. Then, although there is so much negative in opinions expressed in this essay, the whole undertaking was successful and the Idea was implemented as it was essentially thought out, yet in a bit complicated and uncertain way. But, such is life, and those who seek always find :-).
We are about to finish a Windows Mobile port of Talkonaut, we currently investigating possibilities to port it to Android and iPhone (we’ve made some small successful steps in this direction already) , and we hope that many people find Talkonaut not only useful to solve their daily communication needs, but it will change the way they communicate.
We are not going to turn this software into commercial product for an end-user, but we are evaluating some ideas on how to benefit from it. Basically, here we are after the following ideas: 1. Through our GTalk2VoIP gateway we can provide Talkonaut users with some paid services like PSTN termination and DID numbers rent. 2. We can re-brand our Talkonaut software to anyone’s needs. So if you are a representative of a fairly large business, you might be interested in our offers. Please don’t hesitate to contact us.
5th of February 2008.
© Ruslan Zalata
Tyumen, Russia,
GTalk2VoIP TEAM
Email:
Tel.
Notes:
1. Although Thailand is pretty cool place to spend your life at, I’ve been to Thailand already, hence this did not appear so much intriguing as coding :-)
2. It seems it was intentionally introduced into MIDP standard the absence of ability to access raw audio without any pre-buffering and other high-level shitty stuff, so you cannot develop any real-time audio processing or steaming application. I strictly believe it was lobbied by mobile carriers in effort to ban development of mobile VoIP, at least for J2ME platform.
3. Personally I think that mobile revolution is already on the way. Apple with their iPhone had shown to the world that carriers with all the vendors who worship them just suck, and cannot dictate their rules to vendors. Projects like OpenMoko and Android are already bringing freedom to software developers. Innumerous Valley startups find their ways to steal minutes from mobile carriers using incredibly fast developing VoIP solutions. What we need is some synergy between iPhone, OpenMoko, VoIP and some Google to push it en-mass. And this will happen, no doubts!
4. Here I have to admit that GTalk2VoIP’s FSM style Perl based scripting language that we initially implemented (in 300 lines of Perl code), appeared so much powerful that we could add world-most top features in minutes rather that in days. In example, I have added voicemail feature in 40 minutes including debugging. All the power of FSM scripting came to our sense quite soon, so we used it every time either some user requested a cool new feature or we needed some feature for our Talkonaut project.
5. People often ask how did we choose that name for our software, but that’s a whole different story. All that I can say now is that we thought out and looked through a thousand of different “web 2.0”-ish names, either we did not liked them much or the domain addresses with these names were already taken. We spent much time discussing this naming issue and WHOIS-ing domain names, until someday we came to “Talkonaut” :-).
6. This Jabber.org issue appeared by accident. When we introduced conference chat feature, we managed to configure Talkonaut to ship with a predefined set of conferences so newcomers could see how this feature work, cold try it and maybe get used to Jabber chats. It appeared that the conference was very much populated and our Talkonaut users flooded it with stupid questions on any languages but English. Of course this made conference regulars very angry, but thank to Peter Saint-Andre and his lenient and mercy attitude they were trying to educate continuous hoards for a year long until Peter asked us to remove that conference from the list of predefined. We bring our apologies to all jabber.org regulars, we are very sorry for our users.
7. Compare it to 50k likes of heavy C++ code in libjingle and try to understand what Google intended to present to open source community with this bogus library which they don’t even use in their own projects.
8. If you read through this page dedicated to Symbian History, you will find about 10 different branches of the OS with 100 of totally different and incompatible versions. Now imagine that Microsoft had 100 different, incompatible versions of their OS Windows :-) and every time a new version is out, all third-party developers must take a great effort to port their applications to new OS. I mean “to port” – as to make a lot of changes in the code, and not just recompile with a new SDK or a new compiler.
9. Actually, there is no emulator for Symbian in the SDK as in common sense of the word “emulator”. There’s a copy of Symbian built for Win32 platform, which is positioned as an emulator of a device and an environment to test developers’ applications. Of course it is a) buggy, b) based on different machine architecture (x86 instead of ARM) and c) is not completely the same Symbian which is running on phones, so it is pretty common when an application runs ok on the emulator but does not even install on real device. The opposite situation is also not unusual. So, it might be a good advice to completely abandon such emulator and always use real devices (preferably as many devices as possible) to test your applications.
10. Some Nokia phones are equipped with a bunch of hardware codecs (DSPs) accessible for third-party applications. Among those codecs a proprietary G.729 is often available which is nowadays VoIP industry de-facto standard. So, with this codec API you can implement a support for G.729 codec without paying royalty fees to codec patent holder.
11. As a rule, a test process consists of a several trials, each cost developers a regular testing fee set in euros. Of course, the bigger and more feature-rich application you develop, the more attempts to pass the test it takes.
12. Some very old versions of Symbian were made to be able to run applications right from the ROM, thus avoiding copying code text segments into RAM. I suspect this was a rudimentary feature inherited from early days. This also explains why there is no global data permitted in the DLLs.
13. There’s some pretty serious bug in CMdaAudioOutputStream which makes the whole system crash and device to reboot. There’s another one in CMdaAudioInputStream that makes all CActiveSchedulers in your app freeze, and sometimes this class API does not produce proper callback calls.
14. You can download a latest test build from https://gtalk2voip.com/~rz/talkonaut-s60-3rd.SIS or follow the news on and wait till it will be offered for download from