Registrar compliance

[Michael Rickmann]

Yesterday Robert checked commit 23341 into Opal stable which allows
Ekiga to deal with registrars which do not allow RFC1918-IPs and which
may possibly help in complex interface situations as reported in
http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
capabilities I have adapted my patch to Ekiga stable (attached) with
which you have to place the string %limit into the account name. For me
it works for a noRFC provider. Regarding the various possibilities of
non-compliant registrars a simple boolean "is_limited" is rather simple
minded. On the other hand have we only one method to deal with these
registrars at the moment. How shall I proceed?
Michael

diff -ur ekiga.orig/lib/engine/components/opal/opal-account.cpp ekiga/lib/engine/components/opal/opal-account.cpp
--- ekiga.orig/lib/engine/components/opal/opal-account.cpp 2009-09-06 12:58:19.000000000 +0200
+++ ekiga/lib/engine/components/opal/opal-account.cpp 2009-09-06 12:59:10.000000000 +0200
@@ -122,6 +122,8 @@
   else
     type = Account::H323;
 
+  limited = (name.find ("%limit") != std::string::npos);
+
   registration_event.connect (sigc::mem_fun (this, &Opal::Account::on_registration_event));
 }
 
@@ -277,6 +279,12 @@
 }
 
 
+bool Opal::Account::is_limited () const
+{
+  return limited;
+}
+
+
 bool Opal::Account::is_active () const
 {
   return active;
diff -ur ekiga.orig/lib/engine/components/opal/opal-account.h ekiga/lib/engine/components/opal/opal-account.h
--- ekiga.orig/lib/engine/components/opal/opal-account.h 2009-09-06 12:58:19.000000000 +0200
+++ ekiga/lib/engine/components/opal/opal-account.h 2009-09-06 12:59:10.000000000 +0200
@@ -122,6 +122,8 @@
 
     bool is_enabled () const;
 
+    bool is_limited () const;
+
     bool is_active () const;
 
     void remove ();
@@ -145,6 +147,7 @@
     bool dead;
     bool active;
     bool enabled;
+    bool limited;
     unsigned timeout;
     std::string aid;
     std::string name;
diff -ur ekiga.orig/lib/engine/components/opal/sip-endpoint.cpp ekiga/lib/engine/components/opal/sip-endpoint.cpp
--- ekiga.orig/lib/engine/components/opal/sip-endpoint.cpp 2009-09-06 12:58:19.000000000 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.cpp 2009-09-06 13:00:41.000000000 +0200
@@ -82,6 +82,7 @@
     account.get_authentication_username (),
     account.get_password (),
     account.is_enabled (),
+    account.is_limited (),
     account.get_timeout ());
  } else {
 
@@ -555,6 +556,7 @@
        const std::string auth_username,
        const std::string password,
        bool is_enabled,
+       bool is_limited,
        unsigned timeout)
 {
   PString _aor;
@@ -572,6 +574,8 @@
   SIPRegister::Params params;
   params.m_addressOfRecord = aor.str ();
   params.m_registrarAddress = host_;
+  if (is_limited)
+    params.m_compatibility = SIPRegister::e_CannotRegisterMultipleContacts;
   params.m_authID = auth_username;
   params.m_password = password;
   params.m_expire = is_enabled ? timeout : 0;
diff -ur ekiga.orig/lib/engine/components/opal/sip-endpoint.h ekiga/lib/engine/components/opal/sip-endpoint.h
--- ekiga.orig/lib/engine/components/opal/sip-endpoint.h 2009-09-06 12:58:19.000000000 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.h 2009-09-06 12:59:10.000000000 +0200
@@ -153,6 +153,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

[Eugen Dedu]

Michael Rickmann wrote:

> Yesterday Robert checked commit 23341 into Opal stable which allows
> Ekiga to deal with registrars which do not allow RFC1918-IPs and which
> may possibly help in complex interface situations as reported in
> http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
> capabilities I have adapted my patch to Ekiga stable (attached) with
> which you have to place the string %limit into the account name. For me
> it works for a noRFC provider. Regarding the various possibilities of
> non-compliant registrars a simple boolean "is_limited" is rather simple
> minded. On the other hand have we only one method to deal with these
> registrars at the moment. How shall I proceed?

I would say: let's stay with this simple method for the moment.  When
the 2nd case appears, we will think at a general solution.

On master, it tempted limited also when the classical registration did
not work.  Shouldn't we do the same for stable?

--
Eugen

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

[Yannick-GNU/Linux]

Michael Rickmann a écrit :

> Yesterday Robert checked commit 23341 into Opal stable which allows
> Ekiga to deal with registrars which do not allow RFC1918-IPs and which
> may possibly help in complex interface situations as reported in
> http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
> capabilities I have adapted my patch to Ekiga stable (attached) with
> which you have to place the string %limit into the account name. For me
> it works for a noRFC provider. Regarding the various possibilities of
> non-compliant registrars a simple boolean "is_limited" is rather simple
> minded. On the other hand have we only one method to deal with these
> registrars at the moment. How shall I proceed?
> Michael
>
>

Hi,

Is it possible to have this automated?
I'm aware of at least 2 registrar answers:

Server: ecomPhoneServer
P-Registrar-Error: Too many registered contacts
(from the above URL)

and

SIP/2.0 403 Keine RFC1918-IPs erlaubt
Server: UI OpenSER
(from here: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/362891 )

Best regards,
Yannick


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

[Eugen Dedu]

yannick wrote:

> Michael Rickmann a écrit :
>> Yesterday Robert checked commit 23341 into Opal stable which allows
>> Ekiga to deal with registrars which do not allow RFC1918-IPs and which
>> may possibly help in complex interface situations as reported in
>> http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
>> capabilities I have adapted my patch to Ekiga stable (attached) with
>> which you have to place the string %limit into the account name. For me
>> it works for a noRFC provider. Regarding the various possibilities of
>> non-compliant registrars a simple boolean "is_limited" is rather simple
>> minded. On the other hand have we only one method to deal with these
>> registrars at the moment. How shall I proceed?
>> Michael
>>
>>
>
> Hi,
>
> Is it possible to have this automated?
> I'm aware of at least 2 registrar answers:
>
> Server: ecomPhoneServer
> P-Registrar-Error: Too many registered contacts
> (from the above URL)
>
> and
>
> SIP/2.0 403 Keine RFC1918-IPs erlaubt
> Server: UI OpenSER
> (from here: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/362891 )

Another idea is to have a database of such registrars.

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

[Yannick-GNU/Linux]

Eugen Dedu a écrit :

> yannick wrote:
>> Michael Rickmann a écrit :
>>> Yesterday Robert checked commit 23341 into Opal stable which allows
>>> Ekiga to deal with registrars which do not allow RFC1918-IPs and which
>>> may possibly help in complex interface situations as reported in
>>> http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
>>> capabilities I have adapted my patch to Ekiga stable (attached) with
>>> which you have to place the string %limit into the account name. For me
>>> it works for a noRFC provider. Regarding the various possibilities of
>>> non-compliant registrars a simple boolean "is_limited" is rather simple
>>> minded. On the other hand have we only one method to deal with these
>>> registrars at the moment. How shall I proceed?
>>> Michael
>>>
>>>
>> Hi,
>>
>> Is it possible to have this automated?
>> I'm aware of at least 2 registrar answers:
>>
>> Server: ecomPhoneServer
>> P-Registrar-Error: Too many registered contacts
>> (from the above URL)
>>
>> and
>>
>> SIP/2.0 403 Keine RFC1918-IPs erlaubt
>> Server: UI OpenSER
>> (from here: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/362891 )
>
> Another idea is to have a database of such registrars.
>

Where? on the web or inside ekiga? I would prefer something which do not
require user action (fully automated)...
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

yannick wrote:

> Eugen Dedu a écrit :
>> yannick wrote:
>>> Michael Rickmann a écrit :
>>>> Yesterday Robert checked commit 23341 into Opal stable which allows
>>>> Ekiga to deal with registrars which do not allow RFC1918-IPs and which
>>>> may possibly help in complex interface situations as reported in
>>>> http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
>>>> capabilities I have adapted my patch to Ekiga stable (attached) with
>>>> which you have to place the string %limit into the account name. For me
>>>> it works for a noRFC provider. Regarding the various possibilities of
>>>> non-compliant registrars a simple boolean "is_limited" is rather simple
>>>> minded. On the other hand have we only one method to deal with these
>>>> registrars at the moment. How shall I proceed?
>>>> Michael
>>>>
>>>>
>>> Hi,
>>>
>>> Is it possible to have this automated?
>>> I'm aware of at least 2 registrar answers:
>>>
>>> Server: ecomPhoneServer
>>> P-Registrar-Error: Too many registered contacts
>>> (from the above URL)
>>>
>>> and
>>>
>>> SIP/2.0 403 Keine RFC1918-IPs erlaubt
>>> Server: UI OpenSER
>>> (from here: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/362891 )
>> Another idea is to have a database of such registrars.
>>
>
> Where? on the web or inside ekiga? I would prefer something which do not
> require user action (fully automated)...

Inside ekiga (sorry).

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

[Damien Sandras]

Le dimanche 06 septembre 2009 à 14:25 +0200, yannick a écrit :
> Eugen Dedu a écrit :
> >
> > Another idea is to have a database of such registrars.
> >
>
> Where? on the web or inside ekiga? I would prefer something which do not
> require user action (fully automated)...

The problem is that each REGISTER will be tried twice in case of
failure. There is no dedicated error code for the "too many contacts"
problem.

I will perhaps try the automated method only if we can not register for
a reason which is different than those cases:
- timeout
- transport error
- forbidden

I don't think adding a new setting is a good idea. I don't think keeping
a database of broken registrars is a good idea either.
--
 _     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

[Yannick-GNU/Linux]

Damien Sandras a écrit :

> Le dimanche 06 septembre 2009 à 14:25 +0200, yannick a écrit :
>> Eugen Dedu a écrit :
>>> Another idea is to have a database of such registrars.
>>>
>> Where? on the web or inside ekiga? I would prefer something which do not
>> require user action (fully automated)...
>
> The problem is that each REGISTER will be tried twice in case of
> failure. There is no dedicated error code for the "too many contacts"
> problem.
>
> I will perhaps try the automated method only if we can not register for
> a reason which is different than those cases:
> - timeout
> - transport error
> - forbidden
>

That would be nice.

In the cases we have, there is a 500:
SIP/2.0 500 Service Unavailable
CSeq: 3 REGISTER
Via: SIP/2.0/UDP
90.178.67.135:5060;received=90.178.67.135;branch=z9hG4bK1c25676e-3a97-de11-8e1e-0022fa93d416;rport=5060

Server: ecomPhoneServer
From: <sip:222365341@...>;tag=2c0c7d66-3a97-de11-8e1e-0022fa93d416
Call-ID: 705f7c66-3a97-de11-8e1e-0022fa93d416@bradford
To: <sip:222365341@...>;tag=482965bfc53a503a3279ddc55b12e697.f882
P-Registrar-Error: Too many registered contacts
Content-Length: 0

and a 403:
SIP/2.0 403 Keine RFC1918-IPs erlaubt
CSeq: 1 REGISTER
Via: SIP/2.0/UDP
79.209.54.40:61224;branch=z9hG4bK04c5cbff-541d-de11-9f94-001b9e55716e;rport=61224
Server: UI OpenSER
From:
<sip:499419999999@...>;tag=d88bc7ff-541d-de11-9f94-001b9e55716e
Call-ID: 2cde27fe-541d-de11-9f94-001b9e55716e@clarissa-laptop
To:
<sip:499419999999@...>;tag=329cfeaa6ded039da25ff8cbb8668bd2.ad0d
Content-Length: 0

> I don't think adding a new setting is a good idea. I don't think keeping
> a database of broken registrars is a good idea either.

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

[Damien Sandras]

Le dimanche 06 septembre 2009 à 15:53 +0200, yannick a écrit :

> Damien Sandras a écrit :
> > Le dimanche 06 septembre 2009 à 14:25 +0200, yannick a écrit :
> >> Eugen Dedu a écrit :
> >>> Another idea is to have a database of such registrars.
> >>>
> >> Where? on the web or inside ekiga? I would prefer something which do not
> >> require user action (fully automated)...
> >
> > The problem is that each REGISTER will be tried twice in case of
> > failure. There is no dedicated error code for the "too many contacts"
> > problem.
> >
> > I will perhaps try the automated method only if we can not register for
> > a reason which is different than those cases:
> > - timeout
> > - transport error
> > - forbidden
> >
>
> That would be nice.
>
> In the cases we have, there is a 500:
> and a 403:

It is their decision, ie nothing standardized. We could have 500 in
other cases too. We could have something else than 500. That's annoying.
(Especially the 403 which is a code generally used to say
"authentication failed").
--
 _     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

[Yannick-GNU/Linux]

Damien Sandras a écrit :

> Le dimanche 06 septembre 2009 à 15:53 +0200, yannick a écrit :
>> Damien Sandras a écrit :
>>> Le dimanche 06 septembre 2009 à 14:25 +0200, yannick a écrit :
>>>> Eugen Dedu a écrit :
>>>>> Another idea is to have a database of such registrars.
>>>>>
>>>> Where? on the web or inside ekiga? I would prefer something which do not
>>>> require user action (fully automated)...
>>> The problem is that each REGISTER will be tried twice in case of
>>> failure. There is no dedicated error code for the "too many contacts"
>>> problem.
>>>
>>> I will perhaps try the automated method only if we can not register for
>>> a reason which is different than those cases:
>>> - timeout
>>> - transport error
>>> - forbidden
>>>
>> That would be nice.
>>
>> In the cases we have, there is a 500:
>> and a 403:
>
> It is their decision, ie nothing standardized. We could have 500 in
> other cases too. We could have something else than 500. That's annoying.
> (Especially the 403 which is a code generally used to say
> "authentication failed").

I know... Maybe think of this as the situation when writing a browser,
there is the W3C and tricks firefox implement for compatibility with
badly designed web sites. Unfortunately, few users will ask for W3C
compliance. Still it is important some people ask for standard
compliance. Some tools like the ACID test or the W3C syntaxe checker
will be nice for SIP... Or maybe a warning in Ekiga telling this
registrar is not standard compliant... But our users will still report
the incompatibility as a bug in our software :/
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Michael Rickmann wrote:

> Yesterday Robert checked commit 23341 into Opal stable which allows
> Ekiga to deal with registrars which do not allow RFC1918-IPs and which
> may possibly help in complex interface situations as reported in
> http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
> capabilities I have adapted my patch to Ekiga stable (attached) with
> which you have to place the string %limit into the account name. For me
> it works for a noRFC provider. Regarding the various possibilities of
> non-compliant registrars a simple boolean "is_limited" is rather simple
> minded. On the other hand have we only one method to deal with these
> registrars at the moment. How shall I proceed?

It's in the stable branch now, thanks!

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