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

[Étoile Dièse <jerome trullen etoilediese fr>]

Le lundi 4 janvier 2010 10:38:13 Damien Sandras, vous avez écrit :
> 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.
> 
Hello,

We use Yate as registrar. I'll try to fix this.
I wonder if maybe, without completely remove the line concerned, we may have an option like "Work around for buggy registrar" in the preferences since 99% of the users will not register sip:me there com:5060 and sip:me there com:5061 on the same service. This is even more true with Ekiga which does not let the user change the port to anything else than 5060.
Anyway, thank you for your answer.

Regards,

PS : sorry for reposting, I chose the wrong identity last time.
-- 
Etoile Dièse