[Serusers] call forwarding issue - attr_destination() error: Feb 12 14:37:53 rd ser[3979]: parse_nameaddr(): No < found - ottendorf
Michal Matyska
michal at iptel.org
Mon Feb 12 17:09:13 CET 2007
I see. Please capture the network on linux cooked interface "any", so
even the request sent over loopback will be visible.
Michal
On Mon, 2007-02-12 at 16:53 +0100, tzieleniewski wrote:
> Yes but this ruri sip:hellboy at 192.168.0.116:5060 is set after the invocation of lookup_contacts(). the function is invoked on the message which contains ruri changed by the forward_blind parameter.
> There is first "round" when processing of the first INVITE reaches the checking of the forward_blind parameter after which I invoke the attr2uri and just after this make the t_relay. then there is second "round" with the changed ruri. before lookup_contacts I see the ruri as mm at voip.touk.pl and after sip:hellboy at 192.168.0.116:5060 which is in fact the location corresponding to sip:hellboy at voip.touk.pl.
> there is no message sending through the network but the message with the new ruri is processed which is visible in the log file I see it logged with the changed ruri??
>
> So where is the problem??
> Is it the problem of attr2uri?
> I tried it by using rewriteuri() and it gave me the same result. changed ruri but lookup_contacts() returns value corresponding to the first ruri. Maybe
> lookup_contacts() checks not the ruri??
>
>
> > Yes, your request-uri is sip:hellboy at 192.168.0.116:5060 which I think
> > will not be looked up in location (lookup_contact should fail), so it
> > does not rewrite the request-uri at all.
> >
> > Michal
> >
> > On Mon, 2007-02-12 at 16:05 +0100, tzieleniewski wrote:
> > > hmm
> > > it is strange because I can see that after attr2uri and t_relay() message again enters the main route block and goes through the whole processing but I can't see the message being send through the network. the recourd_route and via headers are being attached which is visible in the message send to unwanted (contained in the first invite - in this case myself because I try this by calling my self and setting forward_blind to another sip uri) destination:
> > >
> > > U 2007/02/12 16:05:12.199566 192.168.0.74:5060 -> 192.168.0.116:5060
> > > INVITE sip:hellboy at 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 at voip.touk.pl>;tag=218741881.
> > > To: <sip:hellboy at voip.touk.pl>.
> > > Contact: <sip:hellboy at 192.168.0.116:5060>.
> > > Call-ID: 4C739990-7D22-D9F2-72CE-D5F10A9BC99F at 192.168.0.116.
> > > CSeq: 54988 INVITE.
> > > Proxy-Authorization: Digest username="hellboy",realm="voip.touk.pl",nonce="45d08354b71cd0fddc45daa67447c271fd6b36db",response="054c2a5a43cb527ea70a8040dde9aaa0",uri="sip:hellboy at 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 at 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 at voip.touk.pl | 2 | 1 | sip |
> > > > > > > > +----------+--------------+---------------+----------------------+------+-------+--------+
> > > > > > > > 1 row in set (0.00 sec)
> > > > > > > >
> > > > > > > > Cheers
> > > > > > > > -tomasz
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Serusers mailing list
> > > > > > > > Serusers at lists.iptel.org
> > > > > > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Serusers mailing list
> > > > > > > Serusers at lists.iptel.org
> > > > > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > > > >
> > > >
> >
More information about the sr-users
mailing list