Packet capture:
tcpdump can be used on the Nokia device. Wireshark/Ethereal could be used from another host. See http://maemo.org/development/documen...s/tcpdump.html for more information.

General questions to check for SIP issues:
* Do you use NAT?
* If it's a SIP account, what are the account parameters? Is transport set to UDP in the Advanced settings of your SIP account?
* Could you also provide a syslog? To do so, start a terminal window. Now export TPORT_LOG=1 and export SOFIASIP_DEBUG=all in the environment (e.g. by editing /etc/osso-af-init/af-defines.sh) for telepathy-sofiasip. Exporting SOFIASIP_PERSIST=1 also prevents telepathy-sofiasip from exiting due to no connections being requested. Now SIP traffic logs get dumped into syslog. Also see http://maemo.org/development/tools/doc/diablo/syslog/ .
* Access Point Make and model?
* Access Point Firmware version?
* Access Point Hardware revision?
* What are the encryption settings? (open/WEP/WPA-PSK/WPA-EAP)

> Has anyone contacted the developers of according packages?
The correct way is to file a bug report with the requested info included at bugs.maemo.org

I'm new at Maemo. Where can i find a packed version of sysklogd for maemo?

Hi all,
I've the same problem and looked at the network traffic with wireshark when my N810 tries to register with sip.1und1.de.
What happens is the following:
It then tries a third time with the local IP only and then gives up.

The problem is that the server doesn't accept local (RFC1819) IPs (marked with *) to be registered. When I try to use an ekiga account with the N810's sip software the problem is the same. If a RFC1819 IP is in the contacts the server refuses to register.

On the other hand one could say the problem is on client side, because telepathy (this is the N810's sip software) tries to register with the local IP. It should use the NAT's (the router you are behind) public IP instead, which it found out using STUN.

I guess that in chinook telepathy was only registering the public IP, this is why it was working there.

The solutions could be to reconfigure the 1und1 server to allow local IPs, which is practically not possible. The other solution would be to tell telepathy not to register the local IP.

Does anyone out there know how to do that? Would it be possible to do that via config files or is the registration procedure something completely hardcoded? If there are config files for telepathy, where can one find them? Is there a documentation?

Interesting findings, I would be interested in some way to configure telepathy to use the public IP too..

@ quantenschaum
These are some very interesting findings. Thanks for your work so far.

I wasn't able to figure out anything new lately. In the meantime i'm still using Gizmo with the 1und1 account; But would really love to use the build in client again.

The same happens with eutelia network from Italy, i've got the traces with wireshark both chinhook and diablo.
If Discover Public IP is active the first REGISTER is always with private IP and fails...

then the second REGISTER is different between chinhook and diablo:

- Chinhook tries to register with one contact using the public IP address and succeed

- Diablo tries with two contacts one with private IP and one with public IP and the server refuse the authentication

If someone want to see the traces... just ask!

@SteelBlade
Please post the traces as well. So we can gather as much information here in this thread as possible.
Thanks for your effort.

I think they may mean RFC1918 address space, and I have doubts that this is the problem.

I use Ekiga from my Fedora desktop with no problem. The maemo built-in client gets errors. Same settings, same 192.168.5.0/24 network ....

I've been getting the 403 messages (without the indication of "RFC1819" space) for months ....

[Whoops - it's a 606 message, and I've been getting it since Oct 2008 -- I found my old post about it. This had been working in summer of 2008. I've just chalked it up to another in the growing list of non-working "features" on the N810]

Hi fattomm,

Yes that's a typo, I meant RFC1918 IPs, but I think you got what I meant.

You may doubt it, but exactly this is the problem. As said
Have a look at what happens:
In the first try telepathy (and I talk about telepathy here, the N810 VOIP software, not ekiga on fedora, it was just an ekiga account I tried to register with using telepathy software on the N810) tries to register a RFC1918 address. In the second try it tries to register an internet IP *and* an RFC1918 IP. So in both cases an RFC1918 IP is included in the registration request and unmistakenly the server complains just about this.

Someone asked for the wireshark trace, here it is.

Happy computing, Q.

So I suspect I have the same problem ("Internet Call" works with non-NATed Internet connection but does not work behind a NAT)

One problem I have is confusion with the the seemingly convoluted state of the rtcomm project. So I have an N810 with Diablo, fully updated as far as I know (are there some tests for this?), and I have a lot of repositories in my installer catalogue including "packages.collabora.co.uk/maemo diablo user". I do NOT have pidgin installed.

I tried installing the package listed in this thread for installing the rtcomm beta installer ver 6 and ran it. It installed an installer in my menu, which I then ran. It looked liked it got most of the way through but then failed.

An "rtcomm" is no longer listed in my installer under non-installed files, but I have both rtcomm-beta-os2008 (V2.4-1), and rtcomm-beta-installer (v.06) listed in "installed applications". So do I have a working version of rtcomm for Diablo? Is there a working version for Diablo? Can I now remove the rtcomm-beta-installer?

Reviewing my SIP setup:

I am using Ekiga.NET
It logs in and works when non NATed
I have STUN set to "stun.ekiga.net" and the default port of 3478 and the "Auto-detect STUN" turned off.
I have the "Authentication" tab things set up with the same user name and password as I have in the "connection" tab. I am not sure what this is for anyway.

So when NAT'ed I get the flashing icon (from green to red with white line through it) and an occasional message of "Unable to connect to one or more accounts".

Again, once I switch to a non-NAT'ed connection, this setup seems to work fine, in that I can call the ekiga echo test and talk to myself.