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

[Jérôme Trullen <jerome trullen etoilediese fr>]

Le lundi 4 janvier 2010 10:38:13, Damien Sandras a é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,

I just tcpdump'ed the registration :

Ekiga sends : Contact: <sip:me there com>
Our NAT router changes it in : Contact: <sip:me there com:1048>
The registrar Yate answers : Contact: <sip:me there com:1048>
Our NAT router changes it in : Contact: <sip:me there com:5060>

So Ekiga sends Contact: <sip:me there com> and receives an OK with Contact: <sip:me there com:5060>
Conclusion, the problem is not the registrar but the port translation done by the router.

To fix that without any modification of code, one just have to ask Ekiga to use a port different from 5060 (ie. 5061) so that it has to say it in the contact field.
Is there any equivalent to gconf-editor for Windows ?

Regards,
-- 
Jérôme Trullen
Téléphone : +33 567733803
SIP : jerome trullen etoilediese fr