Do you have the res_rtp_asterisk module loaded?
The annoying thing is that you have to press 1 to answer calls when forwarded to GTalk. And if you automatically answer before dialing the SIP extension then you can’t send the call to GV voicemail if the SIP extension does not answer.
Yes. I did have the module loaded.
I right now only want to make out going calls so receiving call is not an issue yet.
I just realize that recompile iksemel-1.4 can be avoided. It is only necessary to do an “apt-get install libiksemel-dev” to have the necessary support for jabber and gtalk modules. However, this didn’t solve the “no RTP session allocated” problem.
I also tried to do the same Asterisk 1.8 installation on Sheevaplug, which have larger internal RAM. However, the result was the same.
I did a few more experiment to install Asterisk 1.8 and using for gtalk. On x86 platform (Ubuntu), it always works without problem. Install the Asterisk1.8 packages by Mario on OpenWRT also works. However, the packages only available for ar71xx and brcm-2.4 on routers. BTW, you will need at least 8 MB flash memory to have it work. Unfortunately, I cannot make it work on Dockstar Debian yet. The Asterisk1.8 packages are not available for Kirkwood so I cannot install them on Dockstar. Hope someday somebody will compile them for Kirkwood or maybe I will be able to compile one 
someday.
Gtalk really work very well once it works.
I did more experiments of Asterisk 1.8 on Dockstar. This time, I compiled asterisk 1.8 Openwrt packages, using Mario’s diff file. I managed to compile the needed files for Dockstar Openwrt for gtalk following what Mario did in (supermario-world.blogspot.com/20 … roper.html). However, the results were exactly the same as for Debian installation. It can only log in with null password and has the No RTP engine. So it looks like not a debian problem but more a Kirkwood/Asterisk incompatibility issue. Maybe somebody at Marwell ought to take a look.
The “No RTP engine” error (and many others) on Kirkwood cpus (and maybe other ARMs) is the result of a “conflict” between the ARM’s memory-alignment and Asterisk’s dynamic string allocation and management. The underlying issue can be fixed fairly easily.
BTW, it may also appear as other problems, or as inconsistent problems.
Details posted in another topic in these forums:
http://forums.digium.com/viewtopic.php?f=1&t=76909&sid=59baa909f1fff9b9e109113d3a364f37
.