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@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
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
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@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@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@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ > Serusers mailing list > Serusers@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@tezet.no-ip.org and I try to forward to hellboy@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@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@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@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@lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > Serusers@lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers >
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@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@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("$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@tezet.no-ip.org and I try to forward to hellboy@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@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@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@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@lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > _______________________________________________ > > > Serusers mailing list > > > Serusers@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@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@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("$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@tezet.no-ip.org and I try to forward to hellboy@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@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
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@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@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@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("$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@tezet.no-ip.org and I try to forward to hellboy@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@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
-
Michal Matyska -
tzieleniewski