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.
--
_ Damien Sandras
(o-
//\ Ekiga Softphone : http://www.ekiga.org/
v_/_ Be IP : http://www.beip.be/
FOSDEM : http://www.fosdem.org/
SIP Phone : sip:[email protected]
_______________________________________________
ekiga-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/ekiga-list
