Re: [Ekiga-list] Fix for Ekiga not re-registering

[Damien Sandras <dsandras seconix com>]

Hi,

The answer from Robert is below your e-mail.

Le mercredi 30 décembre 2009 à 10:18 +0100, Jérôme Trullen a écrit :
> I have the known problem of Ekiga not re-registering at the requested expiration timeout. Since I saw that I was not alone in this case, I took a look to the code of Opal and found out a fix for this which works for me.
> In the file opal-3.6.6/src/sip/sippdu.cxx, I commented out the line 413 : // COMPARE_COMPONENT(GetPortSupplied());
> I don't know what this boolean "portSupplied" is but I saw that it prevents the test (*request == *reply) (line 740 of opal-3.6.6/src/sip/handlers.cxx) from being true when it should.
>
> Is there any way when parametering Ekiga to make this test working, or is my work-around the only way to fix the problem ?

I have seen this before and I am not sure what to do about it. There are two parts to the issue:

First, RFC3261 explicitly describes how to compare two SIP URIs (section 19.1.4) in particular:

       o  For two URIs to be equal, the user, password, host, and port

         components must match.

 

         A URI omitting the user component will not match a URI that

         includes one.  A URI omitting the password component will not

         match a URI that includes one.

 

         A URI omitting any component with a default value will not

         match a URI explicitly containing that component with its

         default value.  For instance, a URI omitting the optional port

         component will not match a URI explicitly declaring port 5060.

         The same is true for the transport-parameter, ttl-parameter,

         user-parameter, and method components.

 

            Defining sip:user host to not be equivalent to

            sip:user host:5060 is a change from RFC 2543.  When deriving

            addresses from URIs, equivalent addresses are expected from

            equivalent URIs.  The URI sip:user host:5060 will always

            resolve to port 5060.  The URI sip:user host may resolve to

            other ports through the DNS SRV mechanisms detailed in [4].

 

 

Second, we have a bug in some registrars. This is where we put in a contact field of something like:

 

Contact: <sip:me there com:5060>

 

And they reply with a contact field of:

 

Contact: <sip:me there com>

 

And that is NOT THE SAME THING, as per the RFC3261 rules. Section 10.3 says the registrar MUST reply with the contact, and technically it doesn’t.

 

 

So, I cannot remove the line as described.

 

And I am not sure how to work around this bug in the registrar either. Last time it happened (on a paid consulting job) we got the registrar people to fix the issue. I don’t know if this is an option in this case.
 

Robert Jongbloed

OPAL/OpenH323/PTLib Architect and Co-founder.

-- 
 _     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 net