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

Bug #362891 reported by Seppl
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ekiga
Fix Released
Low
ekiga (Ubuntu)
In Progress
Medium
Unassigned

Bug Description

Binary package hint: ekiga

Since Version 3 of Ekiga I'm no longer able to connect to my SIP Provider.
I get the error Message 403 Forbidden (No RFC 1918 IP allowed)

First analysis thought is has to to with the following contact command (and the q=1....)

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 exact error message:

rem=udp$212.227.15.231:5060,local=udp$79.209.54.40:61224,if=192.168.2.101%wlan0
SIP/2.0 403 Keine RFC1918-IPs erlaubt
CSeq: 1 REGISTER

Attached the logfiles from Ekiga Version 3 (not working) and Ekiga Version 2 (working)

Revision history for this message
Christian Gut (cycloon) wrote :

same here.

Revision history for this message
return13 (return13) wrote :

same problem

Revision history for this message
Funatiker (koehlerx) wrote :

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

Revision history for this message
Totti (denied) wrote :

same here..... ekiga 2 works!

Revision history for this message
return13 (return13) wrote :

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

Revision history for this message
Funatiker (koehlerx) wrote :

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

Revision history for this message
Seppl (seppl) wrote :

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.

Revision history for this message
Funatiker (koehlerx) wrote :

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

Revision history for this message
Robert Ancell (robert-ancell) wrote :

Log of working Ekiga 2.0.12 extracted from original description

Revision history for this message
Robert Ancell (robert-ancell) wrote :

Log of not working Ekiga 3 extracted from original description

description: updated
summary: - Since update to Egika Version 3 => 403 Forbidden (No RFC 1918 IP
- allowed)
+ Some SIP providers return 403 Forbidden (No RFC 1918 IP allowed)
Changed in ekiga (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Christian Gut (cycloon) wrote :

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.

Revision history for this message
Christian Gut (cycloon) wrote :

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

Revision history for this message
Yannick Defais (sevmek) wrote :

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

Revision history for this message
Funatiker (koehlerx) wrote :

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.

Revision history for this message
Yannick Defais (sevmek) wrote :

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

Revision history for this message
Funatiker (koehlerx) wrote :

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

Revision history for this message
Christian Gut (cycloon) wrote :

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.

Revision history for this message
Yannick Defais (sevmek) wrote :

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

Yannick Defais (sevmek)
Changed in ekiga (Ubuntu):
status: New → In Progress
Changed in ekiga:
status: Unknown → New
Revision history for this message
Yannick Defais (sevmek) wrote :

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

Revision history for this message
Christian Gut (cycloon) wrote :

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

Revision history for this message
Florian Schmidt (flosch369) wrote :

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 ;)

Revision history for this message
Funatiker (koehlerx) wrote :

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

Changed in ekiga:
importance: Unknown → Low
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.