Inaki, Daniel,
In debug mode, it only shows that in auth/api.c:check_response the result doesn't match.
Since I managed to authenticate sipsak and qutecom, but not linphone, I also guess there must be something wrong with the implementation. Strange thing is that it works in a setup without FW, but not with FW (same for kphone).
Andreas
Daniel-Constantin Mierla wrote:
Hello,
running in debug mode should reveal also more details about where the issue actually resides.
Cheers, Daniel
On 05/10/2009 06:10 PM, Iñaki Baz Castillo wrote:
El Domingo, 10 de Mayo de 2009, Andreas Granig escribió:
So the only thing referring to the public Firewall IP is in the R-Uri of the registration and in the Authorization-uri-token. Is this token also used to calculate the auth hashes somehow? Username looks fine in the Authorization header, and so does Realm. Any ideas?
I see nothing wrong in this trace, all seems correct. So I expect some error in client authentication algorithm and so.
You could log the "www_authorize()" return code in Kamailio, which would be a negative value. I do the following:
if (!www_authorize("","subscriber")) { if $rc == -1 xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -1 (invalid user) [$tu from $si:$sp]\n"); else if $rc == -2 xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -2 (invalid password) [$tu from $si:$sp]\n"); else if $rc == -3 xlog("L_INFO", "REGISTER www_authorize(): -3 (stale nonce) [$tu from $si:$sp]\n"); else if $rc == -5 xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -5 (generic error) [$tu from $si:$sp]\n"); www_challenge("","1"); exit; }