[Serusers] call forwarding issue - attr_destination() error: Feb 12 14:37:53 rd ser[3979]: parse_nameaddr(): No < found - ottendorf

[Michal Matyska]

On Mon, 2007-02-12 at 22:13 +0100, tzieleniewski wrote:
> Thank You:) It help!
> But actually I had it done with the usage of lookup_user("$t.uid","@ruri").
> does it make any difference from lookup_user("$tu.uid","@ruri") when I use $t.uid instead of $tu.uid? this is putting this avp to general class with the To track isn't it??
> when I changed to lookup_user("Request-uri") it worked so generally works:) but not for lookup_user("$t.uid","@ruri").

Obviously there must be some difference... if it has helped. :-) You can
check what it has done using dump_attrs() call. It will output all AVPs
set to the syslog (must have debug >= 3 iirc). 

It should not go into general class, if not specified the user should be
the correct one... check the dump_attrs output and fill bug report at
tracker.iptel.org. (I guess it set the uri class and lookup_contacts
checks user class only)

Michal

> is there some order and priority in which the lookup_contacts() searches for uid?? (for instance first in user class and then I global??)

Basically uri, user, domain, global is the order if you specify track
only AVP e.g. $t.uid  so you can set widely accepted default value
(domain/global) and override it for some users and uris if you want.

Some functions (like lookup_contacts) don't allow to set the avp name,
have to check the code what they expect.

If you specify class too (e.g. $tu.uid) just the only one track/class is
searched.

Michal

> 
> tomasz
> 
> > The difference is that there is the forwarded request visible...
> > #
> > U 2007/02/12 20:35:16.241648 192.168.1.2:5060 -> 192.168.1.2:5060
> > INVITE sip:hellboy at tezet.no-ip.org SIP/2.0.
> > Record-Route: <sip:192.168.1.2;ftag=1173592111;lr=on>.
> > Via: SIP/2.0/UDP 192.168.1.2;branch=z9hG4bKb946.ee8b4793.0.
> > Via: SIP/2.0/UDP
> > 192.168.1.2:7061;rport=7061;branch=z9hG4bK7AF94D00BA07C6380C5EC3434F4EB592.
> > From: tomix <sip:tomix at tezet.no-ip.org:7061>;tag=1173592111.
> > To: <sip:tomix at tezet.no-ip.org>.
> > Contact: <sip:tomix at 192.168.1.2:7061>.
> > Call-ID: 0E6FCCFF-D661-0186-3392-977A4BBCDE86 at 192.168.1.2.
> > CSeq: 23808 INVITE.
> > Proxy-Authorization: Digest
> > username="tomix",realm="tezet.no-ip.org",nonce="45d0c2a0f928f22d790a5dfa17228b193d454c7e",response="0df094e8ea2808fa71d2fa28ccdfa8a4",uri="sip:tomix at tezet.no-ip.org",qop=auth,cnonce="67344073698582511BAA60061EBDA625",nc=00000001.
> > Max-Forwards: 16.
> > Content-Type: application/sdp.
> > User-Agent: X-Lite release 1105d.
> > Content-Length: 308.
> > 
> > 
> > If I understand it correctly you get this request being forwarded to the
> > contacs of tomix at tezet.no-ip.org and not hellboy at .... using usrloc
> > lookup (P-hint in the next INVITE).
> > 
> > Then you must have set the TO / USER avp name "uid" based on the To
> > header instead of request-uri. Check the lookup_user function calls, it
> > should be
> > for REGISTER 
> > lookup_user("To") or lookup_user("$tu.uid","@to.uri")
> > 
> > and for other requests
> > lookup_user("Request-uri") or lookup_user("$tu.uid","@ruri")
> > 
> > 
> > If you want to do some originating services, you can use
> > lookup_user("From") or lookup_user("$fu.uid", "@from.uri")
> > 
> > Michal
> > 
> > 
> > 
> > On Mon, 2007-02-12 at 20:41 +0100, tzieleniewski wrote:
> > > Ok I did it.
> > > There is no difference.
> > > Just to make sure I attached the file.
> > > 
> > > Because I left work I repeated the situation at home. I call to "myself" tomix at tezet.no-ip.org and I try to forward to hellboy at tezet.no-ip.org which is not registered.
> > > 
> > > I can also send my ser.cfg if it might help.
> > > 
> > > tomasz
> > > 
> > > > I see. Please capture the network on linux cooked interface "any", so
> > > > even the request sent over loopback will be visible.
> > > > 
> > > > Michal
> > > > 
> > > > On Mon, 2007-02-12 at 16:53 +0100, tzieleniewski wrote:
> > > > > Yes but this ruri sip:hellboy at 192.168.0.116:5060 is set after the invocation of lookup_contacts(). the function is invoked on the message which contains ruri changed by the forward_blind parameter.
> > > > > There is  first "round" when processing of the first INVITE reaches the checking of the forward_blind parameter after which I invoke the attr2uri and just after this make the t_relay. then there is second "round" with the changed ruri. before lookup_contacts I see the ruri as mm at voip.touk.pl and after sip:hellboy at 192.168.0.116:5060 which is in fact the location corresponding to sip:hellboy at voip.touk.pl.
> > > > > there is no message sending through the network but the message with the new ruri is processed which is visible in the log file I see it logged with the changed ruri??
> > > > > 
> > > > > So where is the problem??
> > > > > Is it the problem of attr2uri?
> > > > > I tried it by using rewriteuri() and it gave me the same result. changed ruri but lookup_contacts() returns value corresponding to the first ruri. Maybe 
> > > > > lookup_contacts() checks not the ruri??
> > > > >  
> > > > > 
> > > > > > Yes, your request-uri is sip:hellboy at 192.168.0.116:5060 which I think
> > > > > > will not be looked up in location (lookup_contact should fail), so it
> > > > > > does not rewrite the request-uri at all.
> > > > > > 
> > > > > > Michal
> > > > > > 
> > > > > > On Mon, 2007-02-12 at 16:05 +0100, tzieleniewski wrote:
> > > > > > > hmm
> > > > > > > it is strange because I can see that after attr2uri and t_relay() message again enters the main route block and goes through the whole processing but I can't see the message being send through the network. the recourd_route and via headers are being attached which is visible in the message send to unwanted (contained in the first invite - in this case myself because I try this by calling my self and setting forward_blind to another sip uri) destination:
> > > > > > > 
> > > > > > > U 2007/02/12 16:05:12.199566 192.168.0.74:506