Some SIP providers return 403 Forbidden (No RFC 1918 IP allowed)

same here.

same problem

same problem. Is it a buggy server or a buggy sip-implementation in ekiga3?!

same here..... ekiga 2 works!

I also think it has to do with the buggy sip implementation in ekiga3, because ekiga2 works for me, and also other softphone clients...

Perhaps ekiga3 has the first full and correct sip implementation and this leads to problems with bad configured servers.

Yes, it might be true that the sip implementation is the latest once in ekiga 3 but honestly, a switch in ekiga that serves compatibility would be good.
Honestly do you think that sip providers like 1&1 would change there settings?
As far as i know it's an general issue of openser, and i think many providers use openser.

Are you aware of some providers or servers with similar problems?

Log of working Ekiga 2.0.12 extracted from original description

Log of not working Ekiga 3 extracted from original description

Ekiga released 3.2.1 with fixes regarding sip registration. Just did not manage to get it build to try if it resolves the problem.

Is there any chance to get the upstream fix into ubuntu?

Hi,

Ekiga 3.2.5 was released yesterday. I do not recommend any version between 3.2.0 and this last one because of a nasty bug in video in them.

3.2.5 seems to compile quite easily on Jaunty as one user reported on the ekiga mailling list using this procedure:

(If you're not familiar with compiling software yourself, I do not recommend doing the following... Do it at your own risks. I made some minor changes to the recipe...)

wget ftp://ftp.gnome.org/pub/gnome/sources/ekiga/3.2/ekiga-3.2.5.tar.bz2
wget ftp://ftp.gnome.org/pub/gnome/sources/opal/3.6/opal-3.6.4.tar.bz2
wget ftp://ftp.gnome.org/pub/gnome/sources/ptlib/2.6/ptlib-2.6.4.tar.bz2
sudo dpkg -r libopal3.6.1-dev libopal3.6.1
sudo dpkg -r libpt2.6.1-dev libpt2.6.1 libpt2.6.1-plugins-v4l2
libpt2.6.1-plugins-alsa
sudo dpkg -r ekiga
sudo apt-get install intltool libgtk2.0-dev libgconf2-dev libsigc++-2.0-dev
libgconf2-dev libebook1.2-dev libldap2-dev libsasl2-dev libxv-dev
libdbus-glib-1-dev -y
tar jxvf ptlib-2.6.4.tar.bz2
cd ptlib-2.6.4
./configure
make
sudo checkinstall
cd ..
tar jxvf opal-3.6.4.tar.bz2
cd opal-3.6.4
./configure
make
sudo checkinstall
cd ..
tar jxvf ekiga-3.2.5.tar.bz2
cd ekiga-3.2.5
./configure
make
sudo checkinstall
sudo cp /usr/local/lib/libpt.so.2.6.4 /usr/lib
sudo cp /usr/local/lib/libopal.so.3.6.4 /usr/lib
Installed in minutes.

Source:
http://mail.gnome.org/archives/ekiga-list/2009-July/msg00013.html

Best regards,
Yannick

I don't know if this is new to you: I think I found the reason for this ugly bug: Some servers require that the client reports a valid IP but Ekiga 3 reports sometimes the internal IP if you're behind a NAT.

Funatiker,

In this particular case, ekiga provide several IPs for contact with priority order:

Contact: <sip:499419999999@79.209.54.40:61224>;q=1, <sip:499419999999@79.209.54.40>;q=0.667, <sip:499419999999@192.168.2.101>;q=0.334

The first one to be tried (q=1) is a public one. There is indeed also a private one, but with a lower priority. I rather suspect interoperability issue here, than a real bug in ekiga.

Still, it's true I've also seen cases where the issue is there is only 1 private address (most of time due to router policy), but it is not the case here.

Best regards,
Yannick

What would be if ekiga didn't use the internal IPs at all?!

Funatiker,

there is a fix in the new upstream versions. Did not try so far, but changelogs say, they fixed this issue.

The usage of the internal IPs _can_ be what you want, if you want to talk to people in you internal network. If your sip provider allows, this is a nice feature. But the current implementation in Ubuntu does not work with some of the big ISPs.

Hi,

This has been fixed in OPAL:
"2009-07-13 06:33 rjongbloed

 * [r23102] :
   Added special case of m_contactAddress *= "%LIMITED" for SIP
   registration which will only fill the "Contact" field of the
   REGISTER command with addresses that are on the same interface as
   where the packet is being sent.

   This is to address STUPID registrars that refuse the entire
   registration when extra contact addresses are included that it
   doesn't like, e.g. the private address. Correct behaviour is to
   return what it DOES like, not refuse registration completely."

and the fix is included in OPAL version 3.7.0 released 2009-08-03.

This will be fixed in Ekiga too, when Ekiga will be based on this version or above.

Best regards,
Yannick

Hi,

Ekiga 3.2.6 was released yesterday. It fix numerous issues. Could you please give it a try to check if it solves your issue?

https://launchpad.net/~sevmek/+archive/ekiga-released
(instructions and packages)

In your case add the string "%limit" to the registrar field in the account window and restart ekiga.

Best regards,
Yannick

Yannick,

what do you mean with %limit?

I have tried:

before: sip.1und1.de
after: sip.1und1.de%limit

does not change anything.

% aptitude show ekiga | grep Version
Version: 3.2.6~ppa~jaunty1

Hey,

you have to add "%limit" to account name, not registrar: https://bugzilla.gnome.org/show_bug.cgi?id=592012
After doing so restart Ekiga (!) and you should be done. At least it worked for me with 1und1 ;)

Works fine for me. Now we need a user-friendly implementation of that workaround.