[Serusers] lookup_contacts() error after sd_lookup() from the speeddial module- latest cvs ottendorf
Michal Matyska
michal at iptel.org
Fri Feb 23 16:59:28 CET 2007
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@<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:
> > > Hi Michal
> > >
> > >
> > > Michal Matyska napisał(a):
> > > > 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
> >
> > OK, so sd_lookup solved.
> >
> > > the lookup_user("$t.uid","@ruri") in the 'second round' didn't cause
> > > the 'second round' lookup_contacts() to return the positive result.
> > > >
> > > > 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").
> >
> > 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.
> >
> >
> > > 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).
> >
> 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 at tezet.no-ip.org | sip:tomix at 192.168.1.2:7060 |
> | misia | sip:misia at tezet.no-ip.org | sip:misia at 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 at tezet.no-ip.org>;tag=1047748579
>
> To: tomix <sip:tomix at tezet.no-ip.org>
>
> Contact: "tomix" <sip:tomix at 192.168.1.2:7060>
>
> Call-ID: 0FF3A0C155B1CD791DAF26938F078201 at 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 at tezet.no-ip.org>;tag=1047748579
>
> To: tomix <sip:tomix at tezet.no-ip.org>;tag=b27e1a1d33761e85846fc98f5f3a7e58.1ef1
>
> Call-ID: 0FF3A0C155B1CD791DAF26938F078201 at 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 at tezet.no-ip.org>;tag=1047748579
>
> To: tomix <sip:tomix at tezet.no-ip.org>
>
> Contact: "tomix" <sip:tomix at 192.168.1.2:7060>
>
> Call-ID: 0FF3A0C155B1CD791DAF26938F078201 at 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 at tezet.no-ip.org>;tag=1047748579
>
> To: tomix <sip:tomix at tezet.no-ip.org>;tag=b27e1a1d33761e85846fc98f5f3a7e58.890b
>
> Call-ID: 0FF3A0C155B1CD791DAF26938F078201 at tezet.no-ip.org
>
> CSeq: 20675 REGISTER
>
> Contact: <sip:tomix at 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
> >
More information about the sr-users
mailing list