Hi again I found out that there appears the following error in the log: Feb 12 14:37:53 rd ser[3979]: parse_nameaddr(): No < found

Please give me a hand with this issue:) Thanks in advance -tomasz _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Thanks it worked but another thing appeared:) Everything works fine, I see the message being routed again to ser with different ruri but at the end of the message processing when I invoke the lookup_contacts("location") function the message is forwarded to the location which corresponds to the first ruri which was changed by attr2uri() function. Please point me what do I miss. Generally my procedure looks like this: if inbound user then check if user have forward_blind parameter if yes rewrite ruri (attr2uri("$tr.forward_blind")) and forward with t_relay() So for instance when I call myself and have the forward_blind set on the account on which user is not registered I get the 486 - busy response instead of the unavailable user. > On Mon, 2007-02-12 at 14:32 +0100, tzieleniewski wrote: > > Hi again > > I found out that there appears the following error in the log: > > Feb 12 14:37:53 rd ser[3979]: parse_nameaddr(): No < found > > The attr_destination uses the same uri parser as core, and is able to > accept event the nameaddr specification... so if you put uri without <> > you will get this "warning". > > It just rewrites internal next hop, so the t_relay will send it as > appropriate. If you want to rewrite the request uri too use attr2uri > function call together with it. > > Michal > > > Please give me a hand with this issue:) > > > > Thanks in advance > > -tomasz > > > > > Hi!! > > > > > > I am trying to set up the blind call forwarding with the usage of attr_destination() > > > function. > > > I do the following I load the user attributes from user_attrs and uri_attrs table and then according to the loaded parameters I do: > > > > > > if ($tu.call_forward == "blind" && $tr.forward_blind) > > > { > > > xlog("L_INFO", " route[CALL_FORWARD]: fwd \n"); > > > attr_destination("$tr.forward_blind"); > > > xlog("L_INFO", " route[CALL_FORWARD]: route(FORWARD) \n"); > > > route(FORWARD); > > > xlog("L_INFO", " route[CALL_FORWARD]: drop \n"); > > > drop; > > > } > > > > > > after the ser.cfg logic goes through this part I don't see any change in the request uri?? Please point me what do I miss? > > > > > > here is my database contents: > > > mysql> select * from user_attrs where uid like 'hellboy%' and name like 'call_%'; > > > +----------------------+--------------+-------+------+-------+ > > > | uid | name | value | type | flags | > > > +----------------------+--------------+-------+------+-------+ > > > | hellboy(a)voip.touk.pl | call_forward | blind | 2 | 1 | > > > +----------------------+--------------+-------+------+-------+ > > > 1 row in set (0.00 sec) > > > > > > mysql> select * from uri_attrs where username like 'hellboy%'; > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > | username | did | name | value | type | flags | scheme | > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > | hellboy | voip.touk.pl | forward_blind | sip:tzl@voip.touk.pl | 2 | 1 | sip | > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > 1 row in set (0.00 sec) > > > > > > Cheers > > > -tomasz > > > > > > _______________________________________________ > > > Serusers mailing list > > > Serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers >

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:5060 -> 192.168.0.116:5060 INVITE sip:hellboy@192.168.0.116:5060 SIP/2.0. Record-Route: <sip:192.168.0.74;ftag=218741881;lr=on>. Record-Route: <sip:192.168.0.74;ftag=218741881;lr=on>. Via: SIP/2.0/UDP 192.168.0.74;branch=z9hG4bK5141.91077cd7.0. Via: SIP/2.0/UDP 192.168.0.74;branch=z9hG4bK5141.81077cd7.0. Via: SIP/2.0/UDP 192.168.0.116:5060;rport=5060;branch=z9hG4bK0FCAE301A64EA5A82F9E7BE990AD76FB. From: hellboy <sip:hellboy@voip.touk.pl>;tag=218741881. To: <sip:hellboy@voip.touk.pl>. Contact: <sip:hellboy@192.168.0.116:5060>. Call-ID: 4C739990-7D22-D9F2-72CE-D5F10A9BC99F(a)192.168.0.116. CSeq: 54988 INVITE. Proxy-Authorization: Digest username="hellboy",realm="voip.touk.pl",nonce="45d08354b71cd0fddc45daa67447c271fd6b36db",response="054c2a5a43cb527ea70a8040dde9aaa0",uri="sip:hellboy@voip.touk.pl",qop=auth,cnonce="29546711E944E708A52A2122A1E71614",nc=00000001. Max-Forwards: 15. Content-Type: application/sdp. User-Agent: X-Lite release 1105d. Content-Length: 240. P-hint: usrloc applied. I put the whole ngrep output in the attached file Tomasz > Seems very strange to me, that incoming message would remember the > request uri as it was before rewrite.... do you really forward it? > > Please attach network capture. > > Michal > > On Mon, 2007-02-12 at 15:23 +0100, tzieleniewski wrote: > > Thanks it worked but another thing appeared:) > > > > Everything works fine, I see the message being routed again to ser with > > different ruri but at the end of the message processing when I invoke the > > lookup_contacts("location") function the message is forwarded to the location which > > corresponds to the first ruri which was changed by attr2uri() function. > > Please point me what do I miss. > > > > Generally my procedure looks like this: > > > > if inbound user then > > check if user have forward_blind parameter > > if yes > > rewrite ruri (attr2uri("$tr.forward_blind")) and forward with > > t_relay() > > > > So for instance when I call myself and have the forward_blind set on the account on which user is not registered I get the 486 - busy response instead of the unavailable user. > > > > > > > On Mon, 2007-02-12 at 14:32 +0100, tzieleniewski wrote: > > > > Hi again > > > > I found out that there appears the following error in the log: > > > > Feb 12 14:37:53 rd ser[3979]: parse_nameaddr(): No < found > > > > > > The attr_destination uses the same uri parser as core, and is able to > > > accept event the nameaddr specification... so if you put uri without <> > > > you will get this "warning". > > > > > > It just rewrites internal next hop, so the t_relay will send it as > > > appropriate. If you want to rewrite the request uri too use attr2uri > > > function call together with it. > > > > > > Michal > > > > > > > Please give me a hand with this issue:) > > > > > > > > Thanks in advance > > > > -tomasz > > > > > > > > > Hi!! > > > > > > > > > > I am trying to set up the blind call forwarding with the usage of attr_destination() > > > > > function. > > > > > I do the following I load the user attributes from user_attrs and uri_attrs table and then according to the loaded parameters I do: > > > > > > > > > > if ($tu.call_forward == "blind" && $tr.forward_blind) > > > > > { > > > > > xlog("L_INFO", " route[CALL_FORWARD]: fwd \n"); > > > > > attr_destination("$tr.forward_blind"); > > > > > xlog("L_INFO", " route[CALL_FORWARD]: route(FORWARD) \n"); > > > > > route(FORWARD); > > > > > xlog("L_INFO", " route[CALL_FORWARD]: drop \n"); > > > > > drop; > > > > > } > > > > > > > > > > after the ser.cfg logic goes through this part I don't see any change in the request uri?? Please point me what do I miss? > > > > > > > > > > here is my database contents: > > > > > mysql> select * from user_attrs where uid like 'hellboy%' and name like 'call_%'; > > > > > +----------------------+--------------+-------+------+-------+ > > > > > | uid | name | value | type | flags | > > > > > +----------------------+--------------+-------+------+-------+ > > > > > | hellboy(a)voip.touk.pl | call_forward | blind | 2 | 1 | > > > > > +----------------------+--------------+-------+------+-------+ > > > > > 1 row in set (0.00 sec) > > > > > > > > > > mysql> select * from uri_attrs where username like 'hellboy%'; > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > | username | did | name | value | type | flags | scheme | > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > | hellboy | voip.touk.pl | forward_blind | sip:tzl@voip.touk.pl | 2 | 1 | sip | > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > 1 row in set (0.00 sec) > > > > > > > > > > Cheers > > > > > -tomasz > > > > > > > > > > _______________________________________________ > > > > > Serusers mailing list > > > > > Serusers(a)lists.iptel.org > > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > Serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > >

Yes but this ruri sip:hellboy@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(a)voip.touk.pl and after sip:hellboy@192.168.0.116:5060 which is in fact the location corresponding to sip:hellboy@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@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:5060 -> 192.168.0.116:5060 > > INVITE sip:hellboy@192.168.0.116:5060 SIP/2.0. > > Record-Route: <sip:192.168.0.74;ftag=218741881;lr=on>. > > Record-Route: <sip:192.168.0.74;ftag=218741881;lr=on>. > > Via: SIP/2.0/UDP 192.168.0.74;branch=z9hG4bK5141.91077cd7.0. > > Via: SIP/2.0/UDP 192.168.0.74;branch=z9hG4bK5141.81077cd7.0. > > Via: SIP/2.0/UDP 192.168.0.116:5060;rport=5060;branch=z9hG4bK0FCAE301A64EA5A82F9E7BE990AD76FB. > > From: hellboy <sip:hellboy@voip.touk.pl>;tag=218741881. > > To: <sip:hellboy@voip.touk.pl>. > > Contact: <sip:hellboy@192.168.0.116:5060>. > > Call-ID: 4C739990-7D22-D9F2-72CE-D5F10A9BC99F(a)192.168.0.116. > > CSeq: 54988 INVITE. > > Proxy-Authorization: Digest username="hellboy",realm="voip.touk.pl",nonce="45d08354b71cd0fddc45daa67447c271fd6b36db",response="054c2a5a43cb527ea70a8040dde9aaa0",uri="sip:hellboy@voip.touk.pl",qop=auth,cnonce="29546711E944E708A52A2122A1E71614",nc=00000001. > > Max-Forwards: 15. > > Content-Type: application/sdp. > > User-Agent: X-Lite release 1105d. > > Content-Length: 240. > > P-hint: usrloc applied. > > > > I put the whole ngrep output in the attached file > > > > Tomasz > > > Seems very strange to me, that incoming message would remember the > > > request uri as it was before rewrite.... do you really forward it? > > > > > > Please attach network capture. > > > > > > Michal > > > > > > On Mon, 2007-02-12 at 15:23 +0100, tzieleniewski wrote: > > > > Thanks it worked but another thing appeared:) > > > > > > > > Everything works fine, I see the message being routed again to ser with > > > > different ruri but at the end of the message processing when I invoke the > > > > lookup_contacts("location") function the message is forwarded to the location which > > > > corresponds to the first ruri which was changed by attr2uri() function. > > > > Please point me what do I miss. > > > > > > > > Generally my procedure looks like this: > > > > > > > > if inbound user then > > > > check if user have forward_blind parameter > > > > if yes > > > > rewrite ruri (attr2uri("$tr.forward_blind")) and forward with > > > > t_relay() > > > > > > > > So for instance when I call myself and have the forward_blind set on the account on which user is not registered I get the 486 - busy response instead of the unavailable user. > > > > > > > > > > > > > On Mon, 2007-02-12 at 14:32 +0100, tzieleniewski wrote: > > > > > > Hi again > > > > > > I found out that there appears the following error in the log: > > > > > > Feb 12 14:37:53 rd ser[3979]: parse_nameaddr(): No < found > > > > > > > > > > The attr_destination uses the same uri parser as core, and is able to > > > > > accept event the nameaddr specification... so if you put uri without <> > > > > > you will get this "warning". > > > > > > > > > > It just rewrites internal next hop, so the t_relay will send it as > > > > > appropriate. If you want to rewrite the request uri too use attr2uri > > > > > function call together with it. > > > > > > > > > > Michal > > > > > > > > > > > Please give me a hand with this issue:) > > > > > > > > > > > > Thanks in advance > > > > > > -tomasz > > > > > > > > > > > > > Hi!! > > > > > > > > > > > > > > I am trying to set up the blind call forwarding with the usage of attr_destination() > > > > > > > function. > > > > > > > I do the following I load the user attributes from user_attrs and uri_attrs table and then according to the loaded parameters I do: > > > > > > > > > > > > > > if ($tu.call_forward == "blind" && $tr.forward_blind) > > > > > > > { > > > > > > > xlog("L_INFO", " route[CALL_FORWARD]: fwd \n"); > > > > > > > attr_destination("$tr.forward_blind"); > > > > > > > xlog("L_INFO", " route[CALL_FORWARD]: route(FORWARD) \n"); > > > > > > > route(FORWARD); > > > > > > > xlog("L_INFO", " route[CALL_FORWARD]: drop \n"); > > > > > > > drop; > > > > > > > } > > > > > > > > > > > > > > after the ser.cfg logic goes through this part I don't see any change in the request uri?? Please point me what do I miss? > > > > > > > > > > > > > > here is my database contents: > > > > > > > mysql> select * from user_attrs where uid like 'hellboy%' and name like 'call_%'; > > > > > > > +----------------------+--------------+-------+------+-------+ > > > > > > > | uid | name | value | type | flags | > > > > > > > +----------------------+--------------+-------+------+-------+ > > > > > > > | hellboy(a)voip.touk.pl | call_forward | blind | 2 | 1 | > > > > > > > +----------------------+--------------+-------+------+-------+ > > > > > > > 1 row in set (0.00 sec) > > > > > > > > > > > > > > mysql> select * from uri_attrs where username like 'hellboy%'; > > > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > > > | username | did | name | value | type | flags | scheme | > > > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > > > | hellboy | voip.touk.pl | forward_blind | sip:tzl@voip.touk.pl | 2 | 1 | sip | > > > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > > > 1 row in set (0.00 sec) > > > > > > > > > > > > > > Cheers > > > > > > > -tomasz > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Serusers mailing list > > > > > > > Serusers(a)lists.iptel.org > > > > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > _______________________________________________ > > > > > > Serusers mailing list > > > > > > Serusers(a)lists.iptel.org > > > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > >

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(a)tezet.no-ip.org and I try to forward to hellboy(a)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@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(a)voip.touk.pl and after sip:hellboy@192.168.0.116:5060 which is in fact the location corresponding to sip:hellboy@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@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:5060 -> 192.168.0.116:5060 > > > > INVITE sip:hellboy@192.168.0.116:5060 SIP/2.0. > > > > Record-Route: <sip:192.168.0.74;ftag=218741881;lr=on>. > > > > Record-Route: <sip:192.168.0.74;ftag=218741881;lr=on>. > > > > Via: SIP/2.0/UDP 192.168.0.74;branch=z9hG4bK5141.91077cd7.0. > > > > Via: SIP/2.0/UDP 192.168.0.74;branch=z9hG4bK5141.81077cd7.0. > > > > Via: SIP/2.0/UDP 192.168.0.116:5060;rport=5060;branch=z9hG4bK0FCAE301A64EA5A82F9E7BE990AD76FB. > > > > From: hellboy <sip:hellboy@voip.touk.pl>;tag=218741881. > > > > To: <sip:hellboy@voip.touk.pl>. > > > > Contact: <sip:hellboy@192.168.0.116:5060>. > > > > Call-ID: 4C739990-7D22-D9F2-72CE-D5F10A9BC99F(a)192.168.0.116. > > > > CSeq: 54988 INVITE. > > > > Proxy-Authorization: Digest username="hellboy",realm="voip.touk.pl",nonce="45d08354b71cd0fddc45daa67447c271fd6b36db",response="054c2a5a43cb527ea70a8040dde9aaa0",uri="sip:hellboy@voip.touk.pl",qop=auth,cnonce="29546711E944E708A52A2122A1E71614",nc=00000001. > > > > Max-Forwards: 15. > > > > Content-Type: application/sdp. > > > > User-Agent: X-Lite release 1105d. > > > > Content-Length: 240. > > > > P-hint: usrloc applied. > > > > > > > > I put the whole ngrep output in the attached file > > > > > > > > Tomasz > > > > > Seems very strange to me, that incoming message would remember the > > > > > request uri as it was before rewrite.... do you really forward it? > > > > > > > > > > Please attach network capture. > > > > > > > > > > Michal > > > > > > > > > > On Mon, 2007-02-12 at 15:23 +0100, tzieleniewski wrote: > > > > > > Thanks it worked but another thing appeared:) > > > > > > > > > > > > Everything works fine, I see the message being routed again to ser with > > > > > > different ruri but at the end of the message processing when I invoke the > > > > > > lookup_contacts("location") function the message is forwarded to the location which > > > > > > corresponds to the first ruri which was changed by attr2uri() function. > > > > > > Please point me what do I miss. > > > > > > > > > > > > Generally my procedure looks like this: > > > > > > > > > > > > if inbound user then > > > > > > check if user have forward_blind parameter > > > > > > if yes > > > > > > rewrite ruri (attr2uri("$tr.forward_blind")) and forward with > > > > > > t_relay() > > > > > > > > > > > > So for instance when I call myself and have the forward_blind set on the account on which user is not registered I get the 486 - busy response instead of the unavailable user. > > > > > > > > > > > > > > > > > > > On Mon, 2007-02-12 at 14:32 +0100, tzieleniewski wrote: > > > > > > > > Hi again > > > > > > > > I found out that there appears the following error in the log: > > > > > > > > Feb 12 14:37:53 rd ser[3979]: parse_nameaddr(): No < found > > > > > > > > > > > > > > The attr_destination uses the same uri parser as core, and is able to > > > > > > > accept event the nameaddr specification... so if you put uri without <> > > > > > > > you will get this "warning". > > > > > > > > > > > > > > It just rewrites internal next hop, so the t_relay will send it as > > > > > > > appropriate. If you want to rewrite the request uri too use attr2uri > > > > > > > function call together with it. > > > > > > > > > > > > > > Michal > > > > > > > > > > > > > > > Please give me a hand with this issue:) > > > > > > > > > > > > > > > > Thanks in advance > > > > > > > > -tomasz > > > > > > > > > > > > > > > > > Hi!! > > > > > > > > > > > > > > > > > > I am trying to set up the blind call forwarding with the usage of attr_destination() > > > > > > > > > function. > > > > > > > > > I do the following I load the user attributes from user_attrs and uri_attrs table and then according to the loaded parameters I do: > > > > > > > > > > > > > > > > > > if ($tu.call_forward == "blind" && $tr.forward_blind) > > > > > > > > > { > > > > > > > > > xlog("L_INFO", " route[CALL_FORWARD]: fwd \n"); > > > > > > > > > attr_destination("$tr.forward_blind"); > > > > > > > > > xlog("L_INFO", " route[CALL_FORWARD]: route(FORWARD) \n"); > > > > > > > > > route(FORWARD); > > > > > > > > > xlog("L_INFO", " route[CALL_FORWARD]: drop \n"); > > > > > > > > > drop; > > > > > > > > > } > > > > > > > > > > > > > > > > > > after the ser.cfg logic goes through this part I don't see any change in the request uri?? Please point me what do I miss? > > > > > > > > > > > > > > > > > > here is my database contents: > > > > > > > > > mysql> select * from user_attrs where uid like 'hellboy%' and name like 'call_%'; > > > > > > > > > +----------------------+--------------+-------+------+-------+ > > > > > > > > > | uid | name | value | type | flags | > > > > > > > > > +----------------------+--------------+-------+------+-------+ > > > > > > > > > | hellboy(a)voip.touk.pl | call_forward | blind | 2 | 1 | > > > > > > > > > +----------------------+--------------+-------+------+-------+ > > > > > > > > > 1 row in set (0.00 sec) > > > > > > > > > > > > > > > > > > mysql> select * from uri_attrs where username like 'hellboy%'; > > > > > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > > > > > | username | did | name | value | type | flags | scheme | > > > > > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > > > > > | hellboy | voip.touk.pl | forward_blind | sip:tzl@voip.touk.pl | 2 | 1 | sip | > > > > > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+ > > > > > > > > > 1 row in set (0.00 sec) > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > -tomasz > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Serusers mailing list > > > > > > > > > Serusers(a)lists.iptel.org > > > > > > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Serusers mailing list > > > > > > > > Serusers(a)lists.iptel.org > > > > > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > > > >

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").

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

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@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@tezet.no-ip.org:7061>;tag=1173592111. > To: <sip:tomix@tezet.no-ip.org>. > Contact: <sip:tomix@192.168.1.2:7061>. > Call-ID: 0E6FCCFF-D661-0186-3392-977A4BBCDE86(a)192.168.1.2. > CSeq: 23808 INVITE. > Proxy-Authorization: Digest > username="tomix",realm="tezet.no-ip.org",nonce="45d0c2a0f928f22d790a5dfa17228b193d454c7e",response="0df094e8ea2808fa71d2fa28ccdfa8a4",uri="sip:tomix@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(a)tezet.no-ip.org and not hellboy@.... 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(&quot;$tu.uid&quot;,&quot;(a)to.uri&quot;) > > 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", &quot;(a)from.uri&quot;) > > 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(a)tezet.no-ip.org and I try to forward to hellboy(a)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@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(a)voip.touk.pl and after sip:hellboy@192.168.0.116:5060 which is in fact the location corresponding to sip:hellboy@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@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