[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