After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 563670 - Registration fails (with tun interface enabled)
Registration fails (with tun interface enabled)
Status: RESOLVED DUPLICATE of bug 587504
Product: ekiga
Classification: Applications
Component: OPAL
3.0.x
Other All
: Normal normal
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-08 11:58 UTC by Stefan Söffing
Modified: 2009-07-11 09:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
-d 4 output while registering to SIP server (6.57 KB, text/plain)
2008-12-09 09:23 UTC, Stefan Söffing
Details

Description Stefan Söffing 2008-12-08 11:58:59 UTC
Please describe the problem:
Registration to my provider sip.1und1.de fails when an openvpn tunnel is active.


Steps to reproduce:
1. Enable openvpn (set up a route with local interface having a local IP, eg. 10.0.0.1)
2. Start ekiga and try to register with sip.1und1.de



Actual results:
Registration fails with the following reason: 403 Forbidden
ekiga -d 4 shows the server's response (Translated to english) : RFC1918 IP adresses are not allowed.

Expected results:
Registration to the SIP server

Does this happen every time?
Yes

Other information:
ekiga seems to transmit the local IP address together with the external adress which confuses the server. If I disable the openvpn, it works fine.
Comment 1 Damien Sandras 2008-12-09 08:36:29 UTC
Please attach the -d 4 output.
Comment 2 Stefan Söffing 2008-12-09 09:23:18 UTC
Created attachment 124251 [details]
-d 4 output while registering to SIP server

For simplicity I just attached the part of the output while registering to the server. If you need the complete output, please ask.
Comment 3 Damien Sandras 2008-12-21 18:38:47 UTC
Two possibilities: that this is one of the small set of registrars that
point bank refuse to accept multiple contact fields in the REGISTER command.

Or of the other subset of registrars that reject the REGISTER when there is
an un-routable address in the Contact field (the 10.0.0 one). What it SHOULD do is take the un-routable address out in the 200 OK and leave the routable one in. 

Much more sensible, but some registrars don't do it.

There is really nothing the stack can do about the first one.

The second one I was pretty sure had been fixed, but requires STUN to be
enabled so that the 10.x.x.x address gets translated. Perhaps you could try with pure TRUNK ?
Comment 4 Daniel Gimpelevich 2009-07-09 15:48:31 UTC
I think this bug should be merged into bug #587504, since that's the very same issue, but in the 3.2.x rather than 3.0.x series.
Comment 5 Eugen Dedu 2009-07-11 09:19:29 UTC
Thanks, duplicating it then!

*** This bug has been marked as a duplicate of 587504 ***