Maybe it'll be able to get the port forwarded, but then maybe it's behind a very restrictive firewall. I feel that using a reverse tunnel on port 443 to a remote host is the bulletproof method:

It can be hidden at a very low level (/etc/inittab) and doesn't rely on any kind of user input, only that the thief has the phone switched on whilst near any open wifi.

You can make the phone connect to a different server by updating the dns of the remote host you programmed it to connect to. So, say you needed to bring down the remote server, you could put another in it's place without having to reprogram the phone.

Pretty much every firewall in the land allows port 443 and traditionally it's not monitored that heavily, as most traffic across it is expected to be encrypted/

There is a global var that tells you whether you are connected via wlan or gprs, so you can use that to stop it from sending data when it's using GPRS:

if [ "$ICD_CONNECTION_TYPE" != GPRS ]; then

It could quite easily use GPRS and shouldn't use much bandwidth at all unless you use the tunnel. I was thinking of having some rules as to when it should try and use GPRS to connect, something like no connection for a week via WLAN, try using the GPRS. It would be nice to work out a script that collected as much geographical/call related information, encrypt it then use the ssh tunnel to drop it off at the remote server.