23 Feb
2007
23 Feb
'07
10:59 a.m.
Hi,
now it's a lot easier to explain :-)
If you use authentization of requests (and you do), then the username
from the auth header is put into the from/user uid avp and used in
save_contacts.
You can either change username in your client to tomix(a)<whatever.domain>
and try again (should work) or change your ser.cfg to contain:
if (method==REGISTER) {
...
delete_attr("$fu.uid");
lookup_user("From");
#or lookup_user("$fu.uid","@from");
#or lookup_user("$fu.uid","@msg[\"your-header-name\"]");
if (!save_contacts()) {
...
}
}
(I did not check by ser, should be ok ;-)
Michal
On Fri, 2007-02-23 at 16:37 +0100, tzieleniewski wrote:
Michal we have the source if the problem,finally!!!
On Fri, 2007-02-23 at 01:39 +0100, TZieleniewski
wrote:
Ok I checked it and I think here is the problem!!:)
The registration procedure and the invocation of the
save_contacts("location") gives probably improper record because
the uid column contains only the user name part of the sip uri without the
'@domain' part. So this is probably a bug in the save_contacts() function.
That is why lookup_contacts didn't find the user. When I changed it manually
by adding the domain part to the value in the uid column it worked (with
lookup_user("$tu.uid",""@ruri") as well as speeddial stuff) !!
Strange that it somehow worked with "$t.uid".
What do you suggest to do to make it work??
contents of the location table:
mysql> select uid,aor,contact from location;
+-------+---------------------------+--------------------------------------------------------+
| uid | aor | contact
|
+-------+---------------------------+--------------------------------------------------------+
| tomix | sip:tomix@tezet.no-ip.org | sip:tomix@192.168.1.2:7060
|
| misia | sip:misia@tezet.no-ip.org |
sip:misia@192.168.1.10:4532;rinstance=87be1b88955eac60 |
+-------+---------------------------+--------------------------------------------------------+
dialog between ser and uac:
SEND TIME: 4013450560
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix <sip:tomix@tezet.no-ip.org>;tag=1047748579
To: tomix <sip:tomix@tezet.no-ip.org>
Contact: "tomix" <sip:tomix@192.168.1.2:7060>
Call-ID: 0FF3A0C155B1CD791DAF26938F078201(a)tezet.no-ip.org
CSeq: 20674 REGISTER
Expires: 1800
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450588
RECEIVE << 192.168.1.2:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.1.2:7060;rport=7060;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix <sip:tomix@tezet.no-ip.org>;tag=1047748579
To: tomix <sip:tomix@tezet.no-ip.org>;tag=b27e1a1d33761e85846fc98f5f3a7e58.1ef1
Call-ID: 0FF3A0C155B1CD791DAF26938F078201(a)tezet.no-ip.org
CSeq: 20674 REGISTER
WWW-Authenticate: Digest realm="tezet.no-ip.org",
nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6", qop="auth"
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3880
req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org
out_uri=sip:tezet.no-ip.org via_cnt==1"
SEND TIME: 4013450589
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix <sip:tomix@tezet.no-ip.org>;tag=1047748579
To: tomix <sip:tomix@tezet.no-ip.org>
Contact: "tomix" <sip:tomix@192.168.1.2:7060>
Call-ID: 0FF3A0C155B1CD791DAF26938F078201(a)tezet.no-ip.org
CSeq: 20675 REGISTER
Expires: 1800
Authorization: Digest
username="tomix",realm="tezet.no-ip.org",nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6",response="53452762af6fa51b21d4d40bd47cc991",uri="sip:tezet.no-ip.org",qop=auth,cnonce="08371BFB0A5C8A394D9ED6BB98BAC70F",nc=00000001
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450645
RECEIVE << 192.168.1.2:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.1.2:7060;rport=7060;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix <sip:tomix@tezet.no-ip.org>;tag=1047748579
To: tomix <sip:tomix@tezet.no-ip.org>;tag=b27e1a1d33761e85846fc98f5f3a7e58.890b
Call-ID: 0FF3A0C155B1CD791DAF26938F078201(a)tezet.no-ip.org
CSeq: 20675 REGISTER
Contact: <sip:tomix@192.168.1.2:7060>;expires=1800
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3883
req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org
out_uri=sip:tezet.no-ip.org via_cnt==1"
Cheers
Tomasz
> Michal
> Hi Michal
Michal Matyska napisał(a):
OK, so sd_lookup solved.
Hi,
so I've finally found some time and checked the code and from that point
of view:
sd_lookup rewrites request-uri, so basically you should call t_relay if
it was successful. (as the target of the speeddial might be different
domain you should relay it).
I did like you wrote and called t_relay() after positive result of the
sd_lookup() unfortunatelly the result was
the same as in the previously tried scenarios when I tried to forward
the sip message again to ser. The URI as you said was rewritten and
again received and processed through the logic, but the invocation of the
lookup_user("$t.uid","@ruri") in the 'second round' didn't
cause
the 'second round' lookup_contacts() to return the positive result.
It works by accident, if you don't set user/to avp uid, then the TO
header is used for the AOR building (I've already created SER-234 bug
report). So in the first loop, the To and request uri are the same and
the user is found correctly. The second round (e.g. due to sd_lookup) is
not working, as the To header is the original one.
lookup_contacts searches in the TO / USER avp list only for avp with uid
name. If such avp is not found the TO header uri is parsed and user uid
looked in the db and new avp stored. (This is correct for REGISTER (but
you won't use lookup_contacts within register :), for other request
methods it should use the request-uri).
Which makes me crazy related to your observations, it is supposed to be
working this way (but you reported it as failing):
...
lookup_user("$tu.uid", "@ruri");
if (lookup_contacts("location")) {
t_relay();
drop;
}
lookup_contacts() works but only in the 'first round' with the
lookup_user("$t.uid","@ruri"). I tried to invoke
lookup_user("$tu.uid","@ruri") after the positive
invocation of lookup_user("$t.uid","@ruri") to have the uid in the
to / user track but
even with the uid avp present the result of the second
lookup_contacts() was negative (user was registered and available -
direct call worked without any problems).
That's strange as we use it everywhere and it works.... Check uid of the
registered contact (location table) against the uid found by lookup_user
before the lookup_contacts call (dump_attrs).