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