alien registrar problem

[Michael Rickmann]

Christian Schäfer schrieb:

> Damien Sandras wrote:
>>>> The problem is that your router replaces the public IP address Ekiga
>>>> puts in by a private one due to a bug in the router itself, you can see
>>>> the Ekiga PDUs in the log, they are correct.
>>>> If you disable STUN, perhaps your router will put the public IP address
>>>> in the packets.
>>>>
>>>> What happens is that some dummy routers replace public ip's by private
>>>> ones. That's your case.
>>> Don't think that's true. As I said, using twinkle behind the NAT with
>>> the same router works perfectly with that provider. So the router
>>> couldn't be the problem here  and it seems that it's indeed a
>>> software issue.
>>
>> Please show me a trace of Ekiga with stun disabled and a trace of
>> twinkle so that we can compare both.
>>
>> Btw, I don't understand your reasoning which consists to say that Ekiga
>> puts deliberately private IP addresses in PDUs when the log says no.
>
> Again, to clearify my reasoning, these are the relevant observations:
>
> Firstly:
> Relevant -d 4 output of ekiga says the following when trying to connect
> to bluesip.net:
>
> rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0
>
> SIP/2.0 479 Please don't use private IP addresses
>
> This suggests that there's a problem with the private IP address
> (192.168.1.36). Whether this is sip conform or not I dodn't know.
> Concerning to some people in some voip forums, it isn't.
>
> Secondly:
> This behavior is independent of using a STUN server or not and only
> appears when I am behind a NAT router.
>
> And thirdly:
> The fact that twinkle is able to connect to bluesip successfully from
> behind this specific router, suggests that this is no router-issue.
>
> Detailed traces of both ekiga and twinkle will follow.
>
> Chris

Hi, I think a -d 4 trace and something from twinkle might really help
Ekiga. When I tried from a machine with official internet access the
line containing your rem=.. contained
rem=udp$212.227.15.231:5060,local=udp$134.76.145.30:5060,if=134.76.145.30%eth0

but a few lines up:
Contact: <sip:495512963297@...>;q=1,
<sip:495512963297@...>;q=0.500 because the machine had a
second interface to a local network.
result from sip.1und1.de: SIP/2.0 403 Keine RFC1918-IPs erlaubt
Regards
Michael
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Peter Robinson wrote:

>>>>> The problem is that your router replaces the public IP address Ekiga
>>>>> puts in by a private one due to a bug in the router itself, you can see
>>>>> the Ekiga PDUs in the log, they are correct.
>>>>> If you disable STUN, perhaps your router will put the public IP address
>>>>> in the packets.
>>>>>
>>>>> What happens is that some dummy routers replace public ip's by private
>>>>> ones. That's your case.
>>>> Don't think that's true. As I said, using twinkle behind the NAT with the
>>>> same router works perfectly with that provider. So the router couldn't be
>>>> the problem here  and it seems that it's indeed a software issue.
>>> Please show me a trace of Ekiga with stun disabled and a trace of
>>> twinkle so that we can compare both.
>>>
>>> Btw, I don't understand your reasoning which consists to say that Ekiga
>>> puts deliberately private IP addresses in PDUs when the log says no.
>> Again, to clearify my reasoning, these are the relevant observations:
>>
>> Firstly:
>> Relevant -d 4 output of ekiga says the following when trying to connect to
>> bluesip.net:
>>
>> rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0
>> SIP/2.0 479 Please don't use private IP addresses
>>
>> This suggests that there's a problem with the private IP address
>> (192.168.1.36). Whether this is sip conform or not I dodn't know. Concerning
>> to some people in some voip forums, it isn't.
>>
>> Secondly:
>> This behavior is independent of using a STUN server or not and only appears
>> when I am behind a NAT router.
>>
>> And thirdly:
>> The fact that twinkle is able to connect to bluesip successfully from behind
>> this specific router, suggests that this is no router-issue.
>
> This issue sounds quite familiar to a couple of bugs I've had reported
> on F-11 where they are unable to connect to a SIP server where with
> previous versions of ekiga they were (in some cases they even went as
> far as recompiling ekiga 2 themselves.

The bugs were because the local= address was private, not the if= address.

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Christian Schäfer-4]

Michael Rickmann wrote:

>> Again, to clearify my reasoning, these are the relevant observations:
>>
>> Firstly:
>> Relevant -d 4 output of ekiga says the following when trying to
>> connect to bluesip.net:
>>
>> rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0
>>
>> SIP/2.0 479 Please don't use private IP addresses
>>
>> This suggests that there's a problem with the private IP address
>> (192.168.1.36). Whether this is sip conform or not I dodn't know.
>> Concerning to some people in some voip forums, it isn't.
>>
>> Secondly:
>> This behavior is independent of using a STUN server or not and only
>> appears when I am behind a NAT router.
>>
>> And thirdly:
>> The fact that twinkle is able to connect to bluesip successfully from
>> behind this specific router, suggests that this is no router-issue.
>>
>> Detailed traces of both ekiga and twinkle will follow.
>>
>> Chris
> Hi, I think a -d 4 trace and something from twinkle might really help
> Ekiga. When I tried from a machine with official internet access the
> line containing your rem=.. contained
> rem=udp$212.227.15.231:5060,local=udp$134.76.145.30:5060,if=134.76.145.30%eth0
>
> but a few lines up:
> Contact: <sip:495512963297@...>;q=1,
> <sip:495512963297@...>;q=0.500 because the machine had a
> second interface to a local network.
> result from sip.1und1.de: SIP/2.0 403 Keine RFC1918-IPs erlaubt

OK, here are the logs, one with STUN acivated and one without:
http://home.in.tum.de/~schaefer/ekiga/
Hope that helps and clarifies things.

Don't know however how to produce a twinkle trace. Something from
tcpdump or wireshark? Let me know.

Chris
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le lundi 29 juin 2009 à 18:15 -0400, Christian Schäfer a écrit :
> > but a few lines up:
> > Contact: <sip:495512963297@...>;q=1,
> > <sip:495512963297@...>;q=0.500 because the machine had a
> > second interface to a local network.
> > result from sip.1und1.de: SIP/2.0 403 Keine RFC1918-IPs erlaubt
>
> OK, here are the logs, one with STUN acivated and one without:
> http://home.in.tum.de/~schaefer/ekiga/
> Hope that helps and clarifies things.

OK, first a few remarks :
- having private IP addresses in SIP PDUs in perfectly legal and
conform ;
- in your logs, I see Ekiga puts both IP : private and public in the
contact field, this is also legal and the sip registrar at lund1.de
should not complain about it as there is also the public IP (with high
priority as q=1)

> Don't know however how to produce a twinkle trace. Something from
> tcpdump or wireshark? Let me know.

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Christian Schäfer-4]

Damien Sandras wrote:
> OK, first a few remarks :
> - having private IP addresses in SIP PDUs in perfectly legal and
> conform ;
> - in your logs, I see Ekiga puts both IP : private and public in the
> contact field, this is also legal and the sip registrar at lund1.de
> should not complain about it as there is also the public IP (with high
> priority as q=1)

By the way, today I stumbled over an article in the current German's
Linux Magazine issue, where a bunch of voip clients gets tested. They
also observe this issue concerning the private IP address which makes it
impossible to connect to some (german) providers like 1&1 and GMX with
ekiga.

Chris
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le mercredi 08 juillet 2009 à 13:16 -0400, Christian Schäfer a écrit :

> Damien Sandras wrote:
> > OK, first a few remarks :
> > - having private IP addresses in SIP PDUs in perfectly legal and
> > conform ;
> > - in your logs, I see Ekiga puts both IP : private and public in the
> > contact field, this is also legal and the sip registrar at lund1.de
> > should not complain about it as there is also the public IP (with high
> > priority as q=1)
>
> By the way, today I stumbled over an article in the current German's
> Linux Magazine issue, where a bunch of voip clients gets tested. They
> also observe this issue concerning the private IP address which makes it
> impossible to connect to some (german) providers like 1&1 and GMX with
> ekiga.
>

We need to add back an option to prevent automatic guessing for
braindead providers in that case...
--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

Christian Schäfer schrieb:

> Damien Sandras wrote:
>> OK, first a few remarks :
>> - having private IP addresses in SIP PDUs in perfectly legal and
>> conform ;
>> - in your logs, I see Ekiga puts both IP : private and public in the
>> contact field, this is also legal and the sip registrar at lund1.de
>> should not complain about it as there is also the public IP (with high
>> priority as q=1)
>
> By the way, today I stumbled over an article in the current German's
> Linux Magazine issue, where a bunch of voip clients gets tested. They
> also observe this issue concerning the private IP address which makes it
> impossible to connect to some (german) providers like 1&1 and GMX with
> ekiga.
>

Well, in a way these providers sell their phone numbers and they save
money when they can not be used. But otherwise I cannot see any reason
but achieving acceptance of standards why Ekiga - actually it seems Opal
- behaves this way. I think trying with public and private IP first, if
failure trying again with public only, if failure give in could be
implemented.
Regards
Michael
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Michael Rickmann wrote:

> Christian Schäfer schrieb:
>> Damien Sandras wrote:
>>> OK, first a few remarks :
>>> - having private IP addresses in SIP PDUs in perfectly legal and
>>> conform ;
>>> - in your logs, I see Ekiga puts both IP : private and public in the
>>> contact field, this is also legal and the sip registrar at lund1.de
>>> should not complain about it as there is also the public IP (with high
>>> priority as q=1)
>>
>> By the way, today I stumbled over an article in the current German's
>> Linux Magazine issue, where a bunch of voip clients gets tested. They
>> also observe this issue concerning the private IP address which makes
>> it impossible to connect to some (german) providers like 1&1 and GMX
>> with ekiga.
>>
> Well, in a way these providers sell their phone numbers and they save
> money when they can not be used. But otherwise I cannot see any reason
> but achieving acceptance of standards why Ekiga - actually it seems Opal
> - behaves this way. I think trying with public and private IP first, if
> failure trying again with public only, if failure give in could be
> implemented.

I see a commit in opal which might interest you:
2009-07-13 06:33  rjongbloed

        * src/sip/handlers.cxx: 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.

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Christian Schäfer-4]

Eugen Dedu wrote:

> I see a commit in opal which might interest you:
> 2009-07-13 06:33  rjongbloed
>
>     * src/sip/handlers.cxx: 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.

Thanks Eugen. That sounds indeed very interesting.

Chris
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

Christian Schäfer schrieb:

> Eugen Dedu wrote:
>> I see a commit in opal which might interest you:
>> 2009-07-13 06:33  rjongbloed
>>
>>     * src/sip/handlers.cxx: 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.
>
> Thanks Eugen. That sounds indeed very interesting.
>
> Chris
> _______________________________________________

Yes opal is providing a possibility for handling this kind of brain-dead
provider now. Only Ekiga has to pick it up. Since ekiga.net is serviced
I worked against the aliens - patch is attached. What it does it lets
Ekiga try twice to register, the second time setting %LIMITED. Or if you
know before that you have a limited provider you can put the string
%limit into the name of your account and Ekiga will succeed without
retry. I tried under Linux only and only with sip.1und1.de with which
Ekiga could not register before. Now it works.
Michael

diff -ur src/ekiga/lib/engine/components/opal/opal-account.cpp ekiga/lib/engine/components/opal/opal-account.cpp
--- src/ekiga/lib/engine/components/opal/opal-account.cpp 2009-07-16 17:30:46.000000000 +0200
+++ ekiga/lib/engine/components/opal/opal-account.cpp 2009-07-19 12:10:14.000000000 +0200
@@ -127,6 +127,8 @@
     type = Account::SIP;
   else
     type = Account::H323;
+
+  limited = (name.find ("%limit") != std::string::npos);
 }
 
 
@@ -301,6 +303,12 @@
 }
 
 
+bool Opal::Account::is_limited () const
+{
+  return limited;
+}
+
+
 bool Opal::Account::is_active () const
 {
   return enabled;
@@ -494,10 +502,16 @@
 
   case RegistrationFailed:
 
-    status = _("Could not register");
-    if (!info.empty ())
-      status = status + " (" + info + ")";
-    updated.emit ();
+    if (!limited) {
+      limited = true;
+      gmref_ptr<Sip::EndPoint> endpoint = core.get ("opal-sip-endpoint");
+      endpoint->subscribe (*this);
+    } else {
+      status = _("Could not register");
+      if (!info.empty ())
+        status = status + " (" + info + ")";
+      updated.emit ();
+    }
     break;
 
   case Processing:
diff -ur src/ekiga/lib/engine/components/opal/opal-account.h ekiga/lib/engine/components/opal/opal-account.h
--- src/ekiga/lib/engine/components/opal/opal-account.h 2009-07-16 17:30:46.000000000 +0200
+++ ekiga/lib/engine/components/opal/opal-account.h 2009-07-19 12:10:37.000000000 +0200
@@ -128,6 +128,8 @@
 
     bool is_enabled () const;
 
+    bool is_limited () const;
+
     bool is_active () const;
 
     void remove ();
@@ -160,6 +162,7 @@
     RegistrationState state;
     bool dead;
     bool enabled;
+    bool limited;
     unsigned timeout;
     std::string aid;
     std::string name;
diff -ur src/ekiga/lib/engine/components/opal/sip-endpoint.cpp ekiga/lib/engine/components/opal/sip-endpoint.cpp
--- src/ekiga/lib/engine/components/opal/sip-endpoint.cpp 2009-07-16 17:30:46.000000000 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.cpp 2009-07-19 12:17:59.000000000 +0200
@@ -82,6 +82,7 @@
     account.get_authentication_username (),
     account.get_password (),
     account.is_enabled (),
+    account.is_limited (),
     account.get_timeout ());
  } else {
 
@@ -574,6 +575,7 @@
        const std::string auth_username,
        const std::string password,
        bool is_enabled,
+       bool is_limited,
        unsigned timeout)
 {
   PWaitAndSignal mut(listsMutex);
@@ -592,6 +594,8 @@
   SIPRegister::Params params;
   params.m_addressOfRecord = aor.str ();
   params.m_registrarAddress = host;
+  if (is_limited)
+    params.m_contactAddress = "%LIMITED";
   params.m_authID = auth_username;
   params.m_password = password;
   params.m_expire = is_enabled ? timeout : 0;
diff -ur src/ekiga/lib/engine/components/opal/sip-endpoint.h ekiga/lib/engine/components/opal/sip-endpoint.h
--- src/ekiga/lib/engine/components/opal/sip-endpoint.h 2009-07-16 17:30:46.000000000 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.h 2009-07-19 12:15:49.000000000 +0200
@@ -160,6 +160,7 @@
      const std::string auth_username,
      const std::string password,
      bool is_enabled,
+     bool is_limited,
      unsigned timeout);
 
       void OnRegistered (const PString & aor,

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Christian Schäfer-4]

Michael Rickmann wrote:
> Yes opal is providing a possibility for handling this kind of brain-dead
> provider now. Only Ekiga has to pick it up. Since ekiga.net is serviced
> I worked against the aliens - patch is attached. What it does it lets
> Ekiga try twice to register, the second time setting %LIMITED. Or if you
> know before that you have a limited provider you can put the string
> %limit into the name of your account and Ekiga will succeed without
> retry. I tried under Linux only and only with sip.1und1.de with which
> Ekiga could not register before. Now it works.
> Michael

Great, thanks Michael. Is this change available through svn? I'll give
it try.

Chris
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

Christian Schäfer schrieb:

> Michael Rickmann wrote:
>> Yes opal is providing a possibility for handling this kind of
>> brain-dead provider now. Only Ekiga has to pick it up. Since ekiga.net
>> is serviced I worked against the aliens - patch is attached. What it
>> does it lets Ekiga try twice to register, the second time setting
>> %LIMITED. Or if you know before that you have a limited provider you
>> can put the string %limit into the name of your account and Ekiga will
>> succeed without retry. I tried under Linux only and only with
>> sip.1und1.de with which Ekiga could not register before. Now it works.
>> Michael
>
> Great, thanks Michael. Is this change available through svn? I'll give
> it try.
>
> Chris

Yes, svn co
https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/trunk 
src/opal -r HEAD
  in one line or 23104 instead of HEAD. My patch is against Ekiga master
only so you need a recent version there as well.
Michael
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Michael Rickmann wrote:

> Christian Schäfer schrieb:
>> Eugen Dedu wrote:
>>> I see a commit in opal which might interest you:
>>> 2009-07-13 06:33  rjongbloed
>>>
>>>     * src/sip/handlers.cxx: 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.
>>
>> Thanks Eugen. That sounds indeed very interesting.
>>
>> Chris
>> _______________________________________________
>
> Yes opal is providing a possibility for handling this kind of brain-dead
> provider now. Only Ekiga has to pick it up. Since ekiga.net is serviced
> I worked against the aliens - patch is attached. What it does it lets
> Ekiga try twice to register, the second time setting %LIMITED. Or if you
> know before that you have a limited provider you can put the string
> %limit into the name of your account and Ekiga will succeed without
> retry. I tried under Linux only and only with sip.1und1.de with which
> Ekiga could not register before. Now it works.

Hi,

Committed in master, thanks!  (I still added a small comment,)

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list