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:u...@host to not be equivalent to > > sip:u...@host:5060 is a change from RFC 2543. When deriving > > addresses from URIs, equivalent addresses are expected from > > equivalent URIs. The URI sip:u...@host:5060 will always > > resolve to port 5060. The URI sip:u...@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:[email protected]:5060> > > > > And they reply with a contact field of: > > > > Contact: <sip:[email protected]> > > > > 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:[email protected]> Our NAT router changes it in : Contact: <sip:[email protected]:1048> The registrar Yate answers : Contact: <sip:[email protected]:1048> Our NAT router changes it in : Contact: <sip:[email protected]:5060> So Ekiga sends Contact: <sip:[email protected]> and receives an OK with Contact: <sip:[email protected]: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 : [email protected] _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
