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 > >