Sounds like bug 4259, but just to make sure can you run "tcpdump -i wlan0 -n -s
1500 -w <filename> udp port 5060", transfer <filename> to a PC and examine the
REGISTER response with wireshark?

Tcpdump can be found in the tools repository
(<http://wiki.maemo.org/Documentation/devtools/maemo5>), and needs to run as
root.

Comment 2 Andre Klapper 2009-10-15 21:14:38 UTC

Isn't this the same as upstream
http://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636
?

Yes, probably, that's what bug #4259 leads to. I don't have an opinion yet
about whether it could be worked around. Simply closing it as WONTFIX doesn't
seem helpful.

I ran tcpdump and looked at the packets with wireshark, as requested. The
replies basically say:

SIP/2.0 606 Not Acceptable

I'm not sure if this makes it the same as bug 4269 or not. :)

I did an equivalent packet trace on a box running the Ekiga software, and it
works on this network. However, the first few packets that it sends are STUN
packets. 

I double-checked, and the N900 doesn't seem to send any packets to the STUN
server at all, no matter what I set in the 'Advanced SIP settings' menu. It
seems like the N900 is not properly using STUN.

I am using a NATed address, which seems like an obvious reason that the Ekiga
server is refusing the connection if the N900 is not using STUN to figure out a
public IP/port to register at.

Ug, replying one last time. I finally understand what the up-stream developer
is talking about.

The first packet uses the private address in the "contact" field:

<sip:myuser@192.168.1.220:50181>

The second and subsequent packets use something like this:

<sip:myuser@1.2.3.4:50181;transport=udp>

The idea is that you figure out your public address by looking at the reply you
got back. The Ekiga server does not seem to support this because there is YET
ANOTHER address in the packet, which is left as the private address, hence the
"it's not our problem" nature of the reply.

HOWEVER... this really would be solved with STUN, and the STUN configuration
really should be removed from the menus if it doesn't actually do anything.
OTOH, it seems like there is some STUN support for sofia-sip, so I humbly
suggest that actually using it may be the best option. :)

(In reply to comment #4)
> I ran tcpdump and looked at the packets with wireshark, as requested. The
> replies basically say:
> 
> SIP/2.0 606 Not Acceptable

Right, so this is the same server policy issue as bug 4259 and not really a
protocol bug.  I'm inclined to mark this as a duplicate and possibly reopen the
original to keep the conversation in one place, but I'll leave this up to
Murray or Andre.

(In reply to comment #6)
> HOWEVER... this really would be solved with STUN, and the STUN configuration
> really should be removed from the menus if it doesn't actually do anything.

AFAIK STUN is only used for media at the moment.  For SIP (signalling) STUN
support see bug 3120.

The problem with bug 3120 and bug 4259 is that it seems like one developer at
Nokia has decided that using STUN is inelegant and has decided that the VoIP
stuff in Maemo won't implement it. Therefore users are given software which
doesn't work, and he feels quite happy that it is not Nokia's problem - since
there is a 'better' solution that the server end of the connection should
implement.

That's why one of these bugs is RESOLVED INVALID and the other RESOLVED
WONTFIX.

Even if it is true that RFC 3581 is a perfect solution and the server should
support it, the reality is I have a very expensive phone that doesn't work with
either my work SIP or with ekiga.net. This sucks, and the iPhone users at my
office are laughing at me - as well they should! :(

So, I'm going to contact the Ekiga.net folks and see if they can support RFC
3581, although I am guessing that they have their own reasons why they don't.

Also, is the VoIP client open source? If so, I could begin hacking at it. I'm
not sure where one would find this though.

Comment 9 Andre Klapper 2010-01-13 21:12:06 UTC

(In reply to comment #8)
> So, I'm going to contact the Ekiga.net folks and see if they can support RFC
> 3581, although I am guessing that they have their own reasons why they don't.

Shane, any progress here, or maybe an Ekiga bug report in bugzilla.gnome.org
(URL?) to track?

I had sent a mail, without reply.

But... I just checked, and it works!

Please close, life is good.

Comment 11 Andre Klapper 2010-03-04 20:10:10 UTC

(In reply to comment #10)
> But... I just checked, and it works!
> Please close, life is good.

Murray, does this also work for you now in 3.2010.02-8?

Moving to chat guys. I'm sure this is alreadyfixed.

(In reply to comment #11)
> (In reply to comment #10)
> > But... I just checked, and it works!
> > Please close, life is good.
> 
> Murray, does this also work for you now in 3.2010.02-8?

No, the situation is the same as in my original report here. I've
double-checked in Settings/"About product" that I really have that version of
Maemo 5. I've also tried deleting and recreating the account.

Maybe Shane Kerr is doing something clever in the account's Advanced Settings?

(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > But... I just checked, and it works!
> > > Please close, life is good.
> > 
> > Murray, does this also work for you now in 3.2010.02-8?
> 
> No, the situation is the same as in my original report here. I've
> double-checked in Settings/"About product" that I really have that version of
> Maemo 5. I've also tried deleting and recreating the account.
> 
> Maybe Shane Kerr is doing something clever in the account's Advanced Settings?

Actually no. I tried it again, and realize that it worked from a location I was
at that gave public IP addresses, instead of private (RFC 1918) IP addresses.

I can confirm that the SIP stuff does work behind a NAT to a co-operating
Asterisk server. The one at our work has NAT stuff turned on and it works just
fine now.

So this is a configuration problem on the Ekiga side, but they don't have a
contact address to ask them to fix it, which is apparently the real answer. :(

Hi,

This issue is indeed related to the way ekiga.net is configured; the VoIP
softphone Ekiga uses STUN for SIP signalling while sofia-sip use the rport
field, ekiga.net is configured for STUN. Unfortunately our administrator for
the SIP proxy at ekiga.net is not available for long due to personal issue.
This means the ekiga.net configuration will not change anytime soon. Unless
someone knowing the ekiga.net software configuration well enough (it use
kamailio 1.5.3) propose a new configuration dealing with both STUN and the
rport for SIP signalling.

At the moment, practically this means for people using sofia-sip based
softwares:
* if behind a NAT, it will not REGISTER to ekiga.net.
* if not behind a NAT, it will be able to use ekiga.net service.

Sorry for the inconvenience.

Best regards,
Yannick Defais

cannot be pwnat or something like that used?
http://samy.pl/pwnat/

Comment 17 Andre Klapper 2010-08-26 20:08:28 UTC

I currently cannot see how Maemo5 can work around this, hence it is probably a
WONTFIX.

Comment 18 Andre Klapper 2010-10-11 15:11:06 UTC

Handled upstream in https://bugzilla.gnome.org/show_bug.cgi?id=624751 hence
closing as WONTFIX for this bugtracker as there are no plans to fix this in the
Maemo software stack currently.

Actually the same issue as bug 4259 against Maemo4.