I first tried to connect gizmo to my asterisk at home and it doesn't seem to work in any direction, "sip show peers" never shows a connection for the N800's user.
(N800 with the latest IT2007 firmware that should fix the SDHC bug)

So, after that failure, I tried with osso-rtcom-beta 1.3-3 and it registers just fine (but only with secret= in sip.conf and not md5secret= mind you! That's a pitty as security on the road would be much more needed than at home!)

So, now i can make phone calls but i can't receive them... it just doesn't ring my device while it does ring ekiga on another machine and my SPA2102 ATA too.

Any idea why i would have this asymetrical sip connection? :-(

If this can be of any help, my current asterisk sip.conf user for this profile is:
[n800]
type=friend
username=n800
secret=12345678
canreinvite=no
dtmf=rfc2833
host=dynamic
mailbox=2100@default
context=provider

And when the asterisk receives a call it says Ringing for other phones but i get this message for the n800:

-- Got SIP response 405 "Method Not Allowed" back from 192.168.1.178

any ideas?

It sounds like your registering via SIP just fine, but your new "n800" account isn't included in any of the incoming call rules in your extensions.conf file. I'd take a look in there first.

Don't worry about the 405 "Method Not Allowed" messages, I think those have to do with the mailbox=2100@default line. As far as I can tell the N800 Rtcom stuff doesn't support voicemail info (#messages waiting, new message, etc).

Hahahah thanks a million man, that's what you get for fixing stuff at 4 am...
I completely forgot to add the n800 to the indial in extensions.conf ;-)

Any suggestions on how to secure this now? All my other phone being at home i don't care about them but i still use md5secret instead of secret... it doesn't seem to work with the n800 though.

So using this with my VoIP account from bars makes me a little nervous, maybe i'll try to see if i can make an ssh tunnel but i'm afraid of latency...

Well, one thing to be aware of is this bug re: OpenVPN and RTcom :

https://bugs.maemo.org/show_bug.cgi?id=1860

Really I haven't messed with thing enough to give you any suggestions though. I think there are some TLS options as part of RTcom (like TCP w/ TLS), but I'm not sure Asterisk supports TLS yet.

RTComm doesn't support TLS etc just yet and i fear this bug is with RTComm rather than OpenVPN (just guessing, i hope not)... though, in the mean time, i have found a pretty elegant solution (when i'll manage to figure out why i can't get it to work yet ;-) with OpenSSH 4.3 and later with a kernel supporting TUN/TAP devices. You can use ssh -w any:any your.host.com to generate a tunX device through which you can route traffic... no need for additional VPN softwares anymore :-D

a couple references for futur use:
http://www.debian-administration.org/articles/539
https://help.ubuntu.com/community/SSH_VPN

RTcomm (really Sofia) doesn't want to use any VPN tunnels on the N800. One HUGE bug right there, especially since their wi-fi & SIP-enabled cell phones can do it easily enough.
But Nokia's too busy trying to be iTunes at the moment to really bother trying to fix it.

Uhm, someone on #maemo actually said they managed to have rtcomm run over the PPP/SSH VPN solution... if ppp0 works tun0 should too, but before trying this first hand, i must understand the new OpenSSH 4.3+ tunnel mode (-w any:any flags).

If i have 2 machines: 192.168.1.2 and 192.168.1.3

and i ssh -w any:any 192.168.1.2 from .3

then on .2:
ifconfig tun0 10.0.0.2 pointopoint 10.0.0.3
and on .3:
ifconfig tun0 10.0.0.3 pointopoint 10.0.0.2

after i can ping 10.0.0.2 from .3 but after a long time it just dies... the route or ifconfig information doesn't change or show Errors. It's very easy to trigger if you ping -f 10.0.0.2 for example... it will die within a minute. I reproduced this between other pairs of machines.

Any idea anyone? I know people haven't played much with this new tunnel mode but it's so useful/promising that i can't give it up ;-)

(all kernels are 2.6.22+ and ssh 4.6p1-Debian5*)

I am the person who started the 1860 Bug. Here is the last reply I got from the developers:

Unfortunately, no fix is likely to make it to this OS2008 release.
But we haven't forgotten about the problem.
To solve it properly, the VPN daemon needs to talk to icd (the system
connectivity service) and inform it of the new tunnel interface. This requires
a supporting API from icd which was not implemented in Chinook. We may still
come up with a specially hacked vpnc package (if only ifup/ifdown scripts need
to be changed) that will at least tell Mission Control about the IP address
obtained for the VPN. Please inform which VPN solution you use on your device,
what are the packages and where they came from; in time, we may post some
customized packages for testing through our garage project.

So it's not likely to be an easy solve. I have my n800 working with my trixbox 1.2.4 (with g729 BTW) and have not been able to use rtcomm over openvpn (VNC and telnet work fine).

So it's a matter of time, probably. Have anyone succeeded with other VPN solutions?

er... that sounds horrible! They need to know "which VPN solution you use on your device"! That should of course be completely irrelevant, what VPNs basically do is simply to set up a virtual network interface and run the default route through there. _This_ is what should be supported. In any case there are lots and lots of VPN solutions out there, it's an impossibility to code up support for all of them in applications or the like. I guess it all boils down to the hacks made with the icd and libc to handle on-demand networking (as that hadn't been solved better before..). Such things tend to come down hard on you later..