sr-users February 2007

sr-users@lists.kamailio.org

158 participants
285 discussions

Re: Re: Re: Re: Re: Re: Re: [Serusers] call forwarding issues - load_attrs and lookup_contacts - ottendorf

by tzieleniewski

I did some tests. I sent them on the list because I wat not sure how to interpret their correctness beefore putting them on the tracker I did the following general procedure: dump_attrs() lookup_user(..) dump_attrs() load_attrs(..) dump_attrs() lookup_contacts(..) Case one: dump_attrs() lookup_user("$t.uid","@ruri") dump_attrs() load_attrs("$tu","$t.uid") dump_attrs() lookup_contacts("location") my observations: after lookup_user("$t.uid","@ruri") uid avp appered in the uri class and to track, lookup_contacts("location") found the user debug log: Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:540: class=GLOBAL Feb 13 13:48:25 rd ser[9875]: AVP["lang"]="en" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 13:48:25 rd ser[9875]: AVP["did"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: AVP["digest_realm"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 13:48:25 rd ser[9875]: AVP["did"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: AVP["digest_realm"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:570: track=FROM class=USER Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:580: track=TO class=USER Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:590: track=FROM class=URI Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:600: track=TO class=URI Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: route[INBOUND]: (lookup_user($t.uid, @ruri)) Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:540: class=GLOBAL Feb 13 13:48:25 rd ser[9875]: AVP["lang"]="en" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 13:48:25 rd ser[9875]: AVP["did"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: AVP["digest_realm"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 13:48:25 rd ser[9875]: AVP["did"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: AVP["digest_realm"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:570: track=FROM class=USER Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:580: track=TO class=USER Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:590: track=FROM class=URI Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:600: track=TO class=URI Feb 13 13:48:25 rd ser[9875]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: route[INBOUND]: load_attrs($tu,$t.uid) Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:540: class=GLOBAL Feb 13 13:48:25 rd ser[9875]: AVP["lang"]="en" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 13:48:25 rd ser[9875]: AVP["did"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: AVP["digest_realm"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 13:48:25 rd ser[9875]: AVP["did"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: AVP["digest_realm"]="voip.touk.pl" Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:570: track=FROM class=USER Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:25 rd ser[9875]: INFO: avp.c:580: track=TO class=USER Feb 13 13:48:25 rd ser[9875]: INFO: No AVP present Feb 13 13:48:26 rd ser[9875]: INFO: avp.c:590: track=FROM class=URI Feb 13 13:48:26 rd ser[9875]: INFO: No AVP present Feb 13 13:48:26 rd ser[9875]: INFO: avp.c:600: track=TO class=URI Feb 13 13:48:26 rd ser[9875]: AVP["uid"]="hellboy(a)voip.touk.pl" Case two: dump_attrs() lookup_user("Request-uri") dump_attrs() load_attrs("$tu","$tu.uid") dump_attrs() lookup_contacts("location") my observations: after lookup_user("Request-uri") uid avp appered in the user class and to track, lookup_contacts("location") didn't find the user Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:540: class=GLOBAL Feb 13 14:22:57 rd ser[10047]: AVP["lang"]="en" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 14:22:57 rd ser[10047]: AVP["did"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 14:22:57 rd ser[10047]: AVP["did"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:570: track=FROM class=USER Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:580: track=TO class=USER Feb 13 14:22:57 rd ser[10047]: INFO: No AVP present Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:590: track=FROM class=URI Feb 13 14:22:57 rd ser[10047]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:600: track=TO class=URI Feb 13 14:22:57 rd ser[10047]: INFO: No AVP present Feb 13 14:22:57 rd ser[10047]: route[INBOUND]: (lookup_user(Request-uri) Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:540: class=GLOBAL Feb 13 14:22:57 rd ser[10047]: AVP["lang"]="en" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 14:22:57 rd ser[10047]: AVP["did"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 14:22:57 rd ser[10047]: AVP["did"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:570: track=FROM class=USER Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:580: track=TO class=USER Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["ruri_canonical"]="1" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:590: track=FROM class=URI Feb 13 14:22:57 rd ser[10047]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:600: track=TO class=URI Feb 13 14:22:57 rd ser[10047]: INFO: No AVP present Feb 13 14:22:57 rd ser[10047]: route[INBOUND]: load_attrs($tu,$t.uid) Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:540: class=GLOBAL Feb 13 14:22:57 rd ser[10047]: AVP["lang"]="en" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 14:22:57 rd ser[10047]: AVP["did"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 14:22:57 rd ser[10047]: AVP["did"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:570: track=FROM class=USER Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:580: track=TO class=USER Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["ruri_canonical"]="1" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:590: track=FROM class=URI Feb 13 14:22:57 rd ser[10047]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:22:57 rd ser[10047]: INFO: avp.c:600: track=TO class=URI Feb 13 14:22:57 rd ser[10047]: INFO: No AVP present Case three: dump_attrs() lookup_user("$tu.uid","@ruri") dump_attrs() load_attrs("$tu","$tu.uid") dump_attrs() lookup_contacts("location") my observations: after lookup_user("$tu.uid","@ruri") uid avp appered in the user class and to track, lookup_contacts("location") didn't find the user I also tried to invoke lookup_contacts("location","$tu.uid") but with the same result user wasn't found. Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:540: class=GLOBAL Feb 13 14:36:42 rd ser[10100]: AVP["lang"]="en" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 14:36:42 rd ser[10100]: AVP["did"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 14:36:42 rd ser[10100]: AVP["did"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:570: track=FROM class=USER Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:580: track=TO class=USER Feb 13 14:36:42 rd ser[10100]: INFO: No AVP present Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:590: track=FROM class=URI Feb 13 14:36:42 rd ser[10100]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:600: track=TO class=URI Feb 13 14:36:42 rd ser[10100]: INFO: No AVP present Feb 13 14:36:42 rd ser[10100]: route[INBOUND]: (lookup_user($tu.uid, @ruri)) Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:540: class=GLOBAL Feb 13 14:36:42 rd ser[10100]: AVP["lang"]="en" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 14:36:42 rd ser[10100]: AVP["did"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 14:36:42 rd ser[10100]: AVP["did"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:570: track=FROM class=USER Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:580: track=TO class=USER Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:590: track=FROM class=URI Feb 13 14:36:42 rd ser[10100]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:600: track=TO class=URI Feb 13 14:36:42 rd ser[10100]: INFO: No AVP present Feb 13 14:36:42 rd ser[10100]: route[INBOUND]: load_attrs($tu,$tu.uid) Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:540: class=GLOBAL Feb 13 14:36:42 rd ser[10100]: AVP["lang"]="en" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 13 14:36:42 rd ser[10100]: AVP["did"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:560: track=TO class=DOMAIN Feb 13 14:36:42 rd ser[10100]: AVP["did"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["digest_realm"]="voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:570: track=FROM class=USER Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:580: track=TO class=USER Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:590: track=FROM class=URI Feb 13 14:36:42 rd ser[10100]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 13 14:36:42 rd ser[10100]: INFO: avp.c:600: track=TO class=URI Feb 13 14:36:42 rd ser[10100]: INFO: No AVP present So generally lookup_contacts works only if it can find the uid in the uri class even if there are uid set in other classes it doesn' find the user. Another thing is that when invoked lookup_user("$t.uid","@ruri") the uid avp is put in the uri track. Maybe instead of lookup_contacts one should use registerd() function?? But what does it do? does it only check the location table or as well make an uri set?? Bests Tomasz > 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(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("$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(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 >

17 years, 9 months

[Users] Send Call using authentication

by Jobson Andrade

Hi All, I need of send the calls for my ITSP using verification. Ex.: User = user_itsp Passwd = pass_itsp SIP Server = itsp.com.br I my configuration I made of this way, more not work. ... ##Obelisk if (uri=~"^sip:00[1-9][1-9][0-9]*@") { route(3); exit; } ... route[3]{ #sending route to DDI strip(2); rewritehostport("itsp.com.br:5060"); rewriteuser("user_itsp"); rewriteuserpass("pass_itsp"); route(1); exit; } ... How to made this in openser? I use the openser version 1.0.1 Thanks in advanced, Jobson Andrade Projetos & Desenvolvimento Obelisk - The Asterisk & VoIP Experts phone/fax: (11) 2164-4808 ext. 115 cell Phone: (11) 8175-9916 / 8271-0480 email: <mailto:jandrade@obelisknet.com.br> jandrade(a)obelisknet.com.br

17 years, 9 months

[Users] Doubts about installation

by Javier Allende Astigarraga

i'm begining with openser , i've installed on ubuntu dapper but reading installation notes , always speak about openser-mysql-module, persistent, but i cant do apt.get install .... and if i seek i find files for http://packages.ubuntulinux.org/feisty/net/ only download and put con mysql/lib?? thanks for all any information about openserv config?? bye bye -- ===================================================== Legolas_Bilbao[ID2006][GKR] Dios creo un equipo Perfecto a los demas los lleno de extranjeros http://www.forosindicedonkey.com http://usuarios.lycos.es/ligaforo/ =====================================================

17 years, 9 months

[Serusers] call forwarding issue - attr_destination() unwanted behavior - ottendorf

by tzieleniewski

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

17 years, 9 months

[Users] Presence server -Confused about the Notify

by H Quintana

Hello, I'm a newbie with the SIMPLE extensions. This week I started using the presence server module (with the configuration suggested in the wiki and 2 X-lite's) The softphones are sending the SUBSCRIBE and the PUBLISH messages. The NOTIFYs are received for the Event presence.winfo with some XML content: <?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full"> <watcher-list resource="sip:10092011@a.b.c.d" package="presence"/> </watcherinfo> But, when I add each softphone as a Contact for the other there is no XML content for the Event presence, and the contact's status never changes even if I do multiple changes. I noticed that in the table xcap_xml there is no data, Should I put some information manually? or the information should be inserted when receiving the PUBLISH? Am I missing something? Any ideas? Thanks for your help, Humberto Quintana ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121

17 years, 9 months

[Users] several questions/concerns about branches

by Klaus Darilion

Hi! I hav the following questions about branch handling in openser 1.1.1: In route[1] I use the dispatcher to forward to the gateway 11.22.33.46. Thus, the DURI will be set. Further I use port 6060 to send calls to the GW. So far everything is ok. ... setting fr_timer to 2 seconds XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX route[1]: request's uri: $ru=sip:123456789@foobar.net route[1]: request's destination uri: $du=sip:11.22.33.46:5060 route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060 route[1]: request's first branch: $br=<null> route[1]: request's all branches: $bR= route[1]: request's destination set: $ds=Contact: sip:123456789@foobar.net ... t_relay Then, if the GW does not reply within 2 seconds the failure route triggers: First question: Why is the DURI set to NULL now? ... entering failure route ERROR: no response from gateway or clients a1.net ... branches before ds_next_dst: $ru=sip:123456789@foobar.net, $du=, $bR= XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX failure_route[1]: request's uri: $ru=sip:123456789@foobar.net failure_route[1]: request's destination uri: $du= failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060 failure_route[1]: request's first branch: $br=<null> failure_route[1]: request's all branches: $bR= failure_route[1]: request's destination set: $ds=Contact: sip:123456789@foobar.net ... ds_next_dst branches after ds_next_dst: $ru=sip:123456789@foobar.net, $du=, $bR=sip:123456789@foobar.net XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX failure_route[1]: request's uri: $ru=sip:123456789@foobar.net failure_route[1]: request's destination uri: $du= failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060 failure_route[1]: request's first branch: $br=sip:123456789@foobar.net failure_route[1]: request's all branches: $bR=sip:123456789@foobar.net failure_route[1]: request's destination set: $ds=Contact: sip:123456789@foobar.net, sip:979004369911 ... activating branch_route ... t_relay Second question: In the branch route the send_socket is reported as NULL. AFAIK it will be copied from branches[0] to the new branch during ds_next_dst. Also the request is sent from port 6060 - thus it looks like the $fs is wrong in branch_route. ==================================================== branch_route[1]: request's uri: $ru=sip:123456789@foobar.net branch_route[1]: request's destination uri: $du=sip:11.22.33.45:5060 branch_route[1]: request's force_send_sock: $fs=<null> branch_route[1]: request's first branch: $br=sip:123456789@foobar.net branch_route[1]: request's all branches: $bR=sip:123456789@foobar.net branch_route[1]: request's destination set: $ds=Contact: sip:123456789@foobar.net, sip:9790043699111 thanks klaus

17 years, 9 months

[Serusers] branch parameter

by Kapil Dhawan

Whats the importance of branch parameter. I am using RTC/1.2 library and its not generating branch parameter. _________________________________________________________________ Tried the new MSN Messenger? Its cool! Download now. http://messenger.msn.com/Download/Default.aspx?mkt=en-in

17 years, 9 months

Re: [Users] Corrupted 'To' after uac_restore_from

by Mahesh Paolini-Subramanya

Bogdan I'm sorry - I commited the cardinal cut/paste sin (copying stuff incorrectly :-( ) Anyhow, I've *correctly* cut/paste the INVITE and BYE headers below, and it looks to me like the route headers *are* being rewritten correctly. So, it doesn't look like that was the issue - unless you are referring to something else? cheers --- Original Message ----- From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> To: mahesh(a)aptela.com Cc: users(a)openser.org Sent: Thursday, February 8, 2007 3:29:26 AM GMT-0600 Subject: Re: [Users] Corrupted 'To' after uac_restore_from Hi Mahesh, I suspect you have a client that does not preserve the Route/Record-Route parameters. According to RFC326, the parameters must not be altered at al, but I saw UAC doing lowercase on the param's value. Most probably this is your case also - the uac module use B64 encoding of the old uri in RR param, so this is case sensitive. Get the full trace of the call and check the original RR param (inserted by openser in INVITE) against the one in put in the BYE. regards, bogdan ---- CORRECTED MESSAGE----- I'm seeing this *very* weird error where uac_restore_from is ending up with a corrupted 'From' header. The weird thing is that it happens with only one end point (a Televantage SIP Trunk). With virtually *everything* else - and I am talking about tens of thousands of end points, spanning all sorts of sip devices, we are having *no* problems. The call is set up as follows -> the endpoint sends the INVITE, which is forwarded to a PSTN gateway The ACKs and the 200 OK all have their From/To headers appropriately rewritten The problem arises when the PSTN gateway initiates the BYE As you can see below, the 'To' header gets corrupted The *only* thing I can think of is that it has something to do with the structure of the Televantage tags (the '+' signs?). Any ideas? FYI, Openser 1.1.0 (latest CVS checkout), and modparam("uac","from_restore_mode","auto") modparam("uac","rr_store_param","aptelavsf") --INVITE-- UAC->proxy INVITE sip:17038677006@69.25.47.136 SIP/2.0. Via: SIP/2.0/UDP 10.10.35.100;rport;branch=z9hG4bK+ec6a2a20436621337016546fa4dc9e87+10.10.35.100+1. Allow-Events: message-summary. Allow-Events: presence. Allow-Events: refer. Max-Forwards: 70. Call-ID: 56796C1E(a)10.10.35.100. From: "Member service"<sip:user100.crunchhq@69.25.47.136>;tag=10.10.35.100+1+8c020003+dd5437f3. To: <sip:17038677006@69.25.47.136>. CSeq: 132610708 INVITE. Expires: 180. Supported: replaces. Supported: 100rel. Contact: <sip:6462174165@10.10.35.100>. Content-Type: application/sdp. Content-Length: 242. . User-Agent: TeleVantage-UA/7.50.4817. . v=0. o=TeleVantage 10671 0 IN IP4 10.10.35.100. s=phone-call. c=IN IP4 10.10.35.100. t=0 0. m=audio 6036 RTP/AVP 0 18 101. a=rtpmap:0 pcmu/8000/1. a=rtpmap:18 g729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000/1. a=ptime:20. ---INVITE--- proxy->gateway INVITE sip:17038677006@65.91.91.16:5060;transport=udp SIP/2.0. Record-Route: <sip:69.25.47.136;lr;ftag=10.10.35.100+1+8c020003+dd5437f3;nat=yes;aptelavsf=dGVzdDciIDR0YndrISJGfHtsaWBbPWQ7NiQ4LCJlISgv>. Via: SIP/2.0/UDP 69.25.47.136;branch=z9hG4bKf67d.2d31dbb.0. Via: SIP/2.0/UDP 10.10.35.100;rport=5060;branch=z9hG4bK+ec6a2a20436621337016546fa4dc9e87+10.10.35.100+1. Allow-Events: message-summary. Allow-Events: presence. Allow-Events: refer. Max-Forwards: 69. Remote-Party-ID: "Membersevice Queue" <sip:6462174165@flareon.aptela.com>;party=calling;id-type=subscriber;screen=yes;privacy=off. Supported: replaces. Call-ID: 56796C1E(a)10.10.35.100. From: "Membersevice Queue"<sip:6462174165@flareon.aptela.com>;tag=10.10.35.100+1+8c020003+dd5437f3. To: <sip:17038677006@69.25.47.136>. CSeq: 132610708 INVITE. Expires: 180. Contact: <sip:6462174165@10.10.35.100:5060>. Content-Type: application/sdp. Content-Length: 262. User-Agent: TeleVantage-UA/7.50.4817. . v=0. o=TeleVantage 10671 0 IN IP4 10.10.35.100. s=phone-call. c=IN IP4 66.150.122.23. t=0 0. m=audio 59520 RTP/AVP 0 18 101. a=rtpmap:0 pcmu/8000/1. a=rtpmap:18 g729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000/1. a=ptime:20. a=nortpproxy:yes . ---BYE---gateway->proxy BYE sip:6462174165@10.10.35.100:5060 SIP/2.0. Via: SIP/2.0/UDP 66.52.236.25:5060;branch=z9hG4bKd8orpb20eg2hais2c2g1sd0000g00.1. To: "Membersevice Queue"<sip:6462174165@69.25.47.136>;tag=10.10.35.100+1+8c020003+dd5437f3. From: <sip:17038677006@66.52.236.25>;tag=1386496. Call-ID: 56796C1E(a)10.10.35.100. CSeq: 1 BYE. Content-Length: 0. Route: <sip:69.25.47.136;lr;ftag=10.10.35.100+1+8c020003+dd5437f3;nat=yes;aptelavsf=dGVzdDciIDR0YndrISJGfHtsaWBbPWQ7NiQ4LCJlISgv>. Max-Forwards: 70. ---BYE--- proxy->UAC BYE sip:6462174165@10.10.35.100:5060 SIP/2.0. Record-Route: <sip:69.25.47.136;lr;ftag=1386496>. Via: SIP/2.0/UDP 69.25.47.136;branch=z9hG4bK7791.48e0e2f5.0. Via: SIP/2.0/UDP 66.52.236.25:5060;branch=z9hG4bKd8orpb20eg2hais2c2g1sd0000g00.1. To: "Membersevice Queue"<sip:user100.cru>6'(!.l asr}XV.R\[>;tag=10.10.35.100+1+8c020003+dd5437f3. From: <sip:17038677006@66.52.236.25>;tag=1386496. Call-ID: 56796C1E(a)10.10.35.100. CSeq: 1 BYE. Content-Length: 0. Max-Forwards: 69. -- ******************************************* Mahesh Paolini-Subramanya (703) 386-1500 x9100 CTO mahesh(a)aptela.com Aptela, Inc. http://www.aptela.com "Aptela: How Business Answers The Call" *******************************************

17 years, 9 months

[Users] MAJOR FIXUP: avp access in reply route

by Bogdan-Andrei Iancu

Hi everybody, The ability of accessing/processing AVPs in reply route was a long debated and wanted functionality. Finally, OpenSER 1.2.x fixes this. The new code allows two types of behaviours: - use per message AVPs in reply route - no special synchronization is needed, but there is no persistence outside reply route. - use per transaction AVPS in reply route (as in failure route). the above behaviours apply to the reply routes triggered by TM. You can control this via the new TM parameter "onreply_avp_mode": http://www.openser.org/docs/modules/1.2.x/tm.html#AEN303 in default reply route only per message AVPs will be available. regards, bogdan

17 years, 9 months

[Users] invitation: SER User and Developer Meeting, collocated with the IETF, in Prague, March

by Jiri Kuthan

Ladies and gentlemen, boys and girls, be wholeheartly welcome to the SER user/developer meeting in Prague, March, colocated with the IETF meeting. For more information see http://www.iptel.org/ietf_meeting If interested in participation, just register yourself. Whereas this event is coming from the SER crowd, the content is going to be primarily technical and openser all in all draws greatly from SER. I believe this can be most useful for users(a)openser.org as well. -jiri -- Jiri Kuthan http://iptel.org/~jiri/

17 years, 9 months

← Newer
1
...
16
17
18
19
20
21
22
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users February 2007