sr-users November 2005

sr-users@lists.kamailio.org

245 participants
571 discussions

[Serusers] RADIUS/LDAP
by Felipe Louback 17 Nov '05

17 Nov '05

I'm putting my SER to authenticate on a LDAP base using RADIUS. But when I try to authenticate any client, I get the following error: auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: Attribute "User-Password" is required for authentication. modcall[authenticate]: module "ldap" returns invalid for request 0 Into my LDAP, the correct field is userPassword and not User-Password, as RADIUS is looking for... I already set in radiusd.conf: password_attribute = userPassword But still the same error.... Any clues? Felipe -- Master Student - Electrical Engineering Department Computer Engineering and Telecommunications Research Group Universidade Federal de Minas Gerais - Brazil "Humanly speaking it is impossible; but with God anything is possible!" Jesus Christ in Matthews 19:26

2 2

[Serusers] Compile problem on SLES 9 EM64T
by Marcello Lupo 17 Nov '05

17 Nov '05

Hi i'm getting this errors of files not found compiling SER 0.9.4 (both from onsip.org or not) and Openser stable 1.0.0 on Suse Linux Enterprise Server 9 x86_64 . Can you address me to solve the issue? After the compilation the SER compile but i don't know if it can be an operational problem. After make proper i get: venus:/data/src/ser-0.9.4 # make prefix=/data/ser Makefile.rules:80: action.d: No such file or directory Makefile.rules:80: crc.d: No such file or directory Makefile.rules:80: daemonize.d: No such file or directory Makefile.rules:80: data_lump.d: No such file or directory Makefile.rules:80: data_lump_rpl.d: No such file or directory Makefile.rules:80: dprint.d: No such file or directory Makefile.rules:80: dset.d: No such file or directory Makefile.rules:80: error.d: No such file or directory Makefile.rules:80: fifo_server.d: No such file or directory Makefile.rules:80: flags.d: No such file or directory Makefile.rules:80: forward.d: No such file or directory Makefile.rules:80: hash_func.d: No such file or directory Makefile.rules:80: ip_addr.d: No such file or directory Makefile.rules:80: main.d: No such file or directory Makefile.rules:80: md5.d: No such file or directory Makefile.rules:80: md5utils.d: No such file or directory Makefile.rules:80: modparam.d: No such file or directory Makefile.rules:80: msg_translator.d: No such file or directory Makefile.rules:80: pass_fd.d: No such file or directory Makefile.rules:80: proxy.d: No such file or directory Makefile.rules:80: qvalue.d: No such file or directory Makefile.rules:80: re.d: No such file or directory Makefile.rules:80: receive.d: No such file or directory Makefile.rules:80: resolve.d: No such file or directory Makefile.rules:80: route.d: No such file or directory Makefile.rules:80: route_struct.d: No such file or directory Makefile.rules:80: script_cb.d: No such file or directory Makefile.rules:80: socket_info.d: No such file or directory Makefile.rules:80: sr_module.d: No such file or directory Makefile.rules:80: stats.d: No such file or directory Makefile.rules:80: tcp_main.d: No such file or directory Makefile.rules:80: tcp_read.d: No such file or directory Makefile.rules:80: timer.d: No such file or directory Makefile.rules:80: tsend.d: No such file or directory Makefile.rules:80: udp_server.d: No such file or directory Makefile.rules:80: unixsock_server.d: No such file or directory Makefile.rules:80: usr_avp.d: No such file or directory Makefile.rules:80: mem/f_malloc.d: No such file or directory Makefile.rules:80: mem/mem.d: No such file or directory Makefile.rules:80: mem/memtest.d: No such file or directory Makefile.rules:80: mem/q_malloc.d: No such file or directory Makefile.rules:80: mem/shm_mem.d: No such file or directory Makefile.rules:80: mem/vq_malloc.d: No such file or directory Makefile.rules:80: parser/hf.d: No such file or directory Makefile.rules:80: parser/msg_parser.d: No such file or directory Makefile.rules:80: parser/parse_allow.d: No such file or directory Makefile.rules:80: parser/parse_content.d: No such file or directory Makefile.rules:80: parser/parse_cseq.d: No such file or directory Makefile.rules:80: parser/parse_disposition.d: No such file or directory Makefile.rules:80: parser/parse_diversion.d: No such file or directory Makefile.rules:80: parser/parse_event.d: No such file or directory Makefile.rules:80: parser/parse_expires.d: No such file or directory Makefile.rules:80: parser/parse_fline.d: No such file or directory Makefile.rules:80: parser/parse_from.d: No such file or directory Makefile.rules:80: parser/parse_hname2.d: No such file or directory Makefile.rules:80: parser/parse_hostport.d: No such file or directory Makefile.rules:80: parser/parse_methods.d: No such file or directory Makefile.rules:80: parser/parse_nameaddr.d: No such file or directory Makefile.rules:80: parser/parse_param.d: No such file or directory Makefile.rules:80: parser/parse_rpid.d: No such file or directory Makefile.rules:80: parser/parse_rr.d: No such file or directory Makefile.rules:80: parser/parse_sipifmatch.d: No such file or directory Makefile.rules:80: parser/parse_to.d: No such file or directory Makefile.rules:80: parser/parse_uri.d: No such file or directory Makefile.rules:80: parser/parse_via.d: No such file or directory Makefile.rules:80: parser/parser_f.d: No such file or directory Makefile.rules:80: parser/digest/digest.d: No such file or directory Makefile.rules:80: parser/digest/digest_parser.d: No such file or directory Makefile.rules:80: parser/digest/param_parser.d: No such file or directory Makefile.rules:80: parser/contact/contact.d: No such file or directory Makefile.rules:80: parser/contact/parse_contact.d: No such file or directory Makefile.rules:80: db/db.d: No such file or directory Makefile.rules:80: db/db_fifo.d: No such file or directory Makefile.rules:80: lex.yy.d: No such file or directory Makefile.rules:80: cfg.tab.d: No such file or directory bison -d -b cfg cfg.y cfg.y: conflicts: 1 shift/reduce flex cfg.lex gcc -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -DNAME='"ser"' -DVERSION='"0.9.4"' -DARCH='"x86_64"' -DOS='"linux"' -DCOMPILER='"gcc 3.3.3"' -D__CPU_x86_64 -D__OS_linux -DCFG_DIR='"/data/ser/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DF_MALLOC -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -c action.c -o action.o ... ... I checked in the main dir of SER/openser src and the files are present. May be the Makefile is searching somewhere else ? Thanks, Bye, Marcello

1 0

Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius Accounting
by Klaus Darilion 17 Nov '05

17 Nov '05

Hi! I think we should leave (open)ser radius as it is. If you need adopt the accounting packets to fit your billing application, I would add a radius proxy, which translates the acounting requests according to your needs and forward it to the billing application. regards klaus Lenir wrote: >>We could determine who sent the BYE from the value of ftag parameter in >>Route header field and swap the values, the question is whether this >>makes sense. The billing system could take all info from start requests > > > I think it would make sense just from a uniformity stand point. > > >>and use the stop request to calculate the session duration only. > > > I don't know if that's the case, but this would probably vary from billing > system to billing system. I think if we keep it uniform, then it would never > be a problem. Specially, for billing systems that only support stop-only > records and billing systems that authenticate by using PIN prefixes, > specially when one of the parties is not a user but a PSTN number. On my > billing platform it wont work, it complains about the discrepancy, and the > fact that when the callee hangs up it doesn't recognize that the CDR is for > a PSTN user. > > Lenir > > -----Original Message----- > From: 'Jan Janak' [mailto:jan@iptel.org] > Sent: Wednesday, November 16, 2005 3:45 PM > To: Lenir > Cc: serdev(a)iptel.org; serusers(a)iptel.org; users(a)openser.org; > devel(a)openser.org > Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius > Accounting > > Yes, this can happen if the callee sends BYE. In this case the URIs in >>From and To header fields are swapped. > > The only SIP RADIUS related document (which has expired a long time ago) > says that Calling-Station-Id is the URI from From header field of any > SIP request. Thus -- according this I-D it is correct. But use of RADIUS > with SIP is underspecified so there is no real standard for this. > > I don't think it matters that much, because other attributes, namely > Acct-Session-Id are used to match start and stop radius requests. > > We could determine who sent the BYE from the value of ftag parameter in > Route header field and swap the values, the question is whether this > makes sense. The billing system could take all info from start requests > and use the stop request to calculate the session duration only. > > Jan. > > On 16-11-2005 15:04, Lenir wrote: > >>Ok, that put the right things in place. However, here's a twist: >>Either way, wit switching Sip-Translated-Request-URI and Called-Station-ID >>around, or not, the CDRs are sent differently depending on who "hands up" >>the call. For example, notice the User-Name, Calling-Station-ID and >>Called-Station-ID: >> >>User 1000 calls 15615551212, and user 1000 hangs up: >>===================================================== >>rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39228, id=206, >>length=306 >> Acct-Status-Type = Start >> Service-Type = Sip-Session >> Acct-Terminate-Cause = 200 >> Error-Cause = Invite >> User-Name = "1000(a)xx.xx.xx.xx" >> Calling-Station-Id = "sip:1000@xx.xx.xx.xx" >> Sip-Translated-Request-URI = >>"sip:15615551212@xx.xx.xx.xx;user=phone" >> Called-Station-Id = >>"sip:949449852150#15615551212@gateway;user=phone" >> Acct-Session-Id = > > "000d2890-d47f01f5-6410e8bd-4baf0435(a)66.232.8.116" > >> Sip-To-Tag = "33C5A3C-76A" >> Sip-From-Tag = "000d2890d47f24f85e6c0b91-0092ab53" >> Sip-CSeq = "102" >> NAS-IP-Address = xx.xx.xx.xx >> NAS-Port = 5060 >> Acct-Delay-Time = 0 >>rlm_sql (sql): Reserving sql socket id: 15 >>rlm_sql (sql): Released sql socket id: 15 >>Sending Accounting-Response of id 206 to xx.xx.xx.xx:39228 >>rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39228, id=207, >>length=300 >> Acct-Status-Type = Stop >> Service-Type = Sip-Session >> Acct-Terminate-Cause = 200 >> Error-Cause = 8 >> User-Name = "1000(a)xx.xx.xx.xx" >> Calling-Station-Id = "sip:1000@xx.xx.xx.xx" >> Sip-Translated-Request-URI = >>"sip:15615551212@xx.xx.xx.xx;user=phone" >> Called-Station-Id = >>"sip:949449852150#15615551212@gateway:5060" >> Acct-Session-Id = > > "000d2890-d47f01f5-6410e8bd-4baf0435(a)66.232.8.116" > >> Sip-To-Tag = "33C5A3C-76A" >> Sip-From-Tag = "000d2890d47f24f85e6c0b91-0092ab53" >> Sip-CSeq = "103" >> NAS-IP-Address = xx.xx.xx.xx >> NAS-Port = 5060 >> Acct-Delay-Time = 0 >> >> >>User 1000 calls 15615551212, and user 15615551212 hangs up: >>=========================================================== >> >>rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39227, id=200, >>length=306 >> Acct-Status-Type = Start >> Service-Type = Sip-Session >> Acct-Terminate-Cause = 200 >> Error-Cause = Invite >> User-Name = "1000(a)xx.xx.xx.xx" >> Calling-Station-Id = "sip:1000@xx.xx.xx.xx" >> Sip-Translated-Request-URI = >>"sip:15615551212@xx.xx.xx.xx;user=phone" >> Called-Station-Id = >>"sip:949449852150#15615551212@gateway;user=phone" >> Acct-Session-Id = > > "000d2890-d47f01f4-372dff4b-793d4acc(a)66.232.8.116" > >> Sip-To-Tag = "33B37E4-77B" >> Sip-From-Tag = "000d2890d47f24f639ccef77-4ef08b02" >> Sip-CSeq = "102" >> NAS-IP-Address = xx.xx.xx.xx >> NAS-Port = 5060 >> Acct-Delay-Time = 0 >>rlm_sql (sql): Reserving sql socket id: 1 >>rlm_sql (sql): Released sql socket id: 1 >>Sending Accounting-Response of id 200 to xx.xx.xx.xx:39227 >>rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39227, id=201, >>length=286 >> Acct-Status-Type = Stop >> Service-Type = Sip-Session >> Acct-Terminate-Cause = 200 >> Error-Cause = 8 >> User-Name = "15615551212(a)xx.xx.xx.xx" >> Calling-Station-Id = "sip:15615551212@xx.xx.xx.xx;user=phone" >> Sip-Translated-Request-URI = "sip:1000@xx.xx.xx.xx" >> Called-Station-Id = "sip:1000@66.232.8.116:5061" >> Acct-Session-Id = > > "000d2890-d47f01f4-372dff4b-793d4acc(a)66.232.8.116" > >> Sip-To-Tag = "000d2890d47f24f639ccef77-4ef08b02" >> Sip-From-Tag = "33B37E4-77B" >> Sip-CSeq = "101" >> NAS-IP-Address = xx.xx.xx.xx >> NAS-Port = 5060 >> Acct-Delay-Time = 0 >> >> >>Shouldn't it always be that the User-Name attribute is the user who >>initiated the call? >> >>Lenir >> >>-----Original Message----- >>From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On > > Behalf > >>Of 'Jan Janak' >>Sent: Wednesday, November 16, 2005 1:53 PM >>To: lsantiago(a)globalgatewaycom.com >>Cc: serdev(a)iptel.org; serusers(a)iptel.org; users(a)openser.org; >>devel(a)openser.org >>Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius >>Accounting >> >>Either reconfigure the billing application to use >>Sip-Translated-Request-URI (recommended) or change the ID of the >>attribute in the radiusclient dictionary as suggested by Bogdan. >> >>In this particular example you should set Called-Station-Id to 107. >> >> Jan. >> >>On 16-11-2005 13:09, 'Lenir' wrote: >> >>>Ok, so how do I tell acc.so to send Sip-Translated-Request-URI as the >>>Called-Station-ID instead? >>> >>>Lenir Santiago, Partner >>>Global Gateway Communications, Inc. >>>2500 Quantum Lakes Drive, Ste. 203 >>>Boynton Beach, FL 33426 >>>Office: 561-853-2213 >>>Cell: 561-722-0966 >>>Fax: 877-875-0060 >>>http://www.globalgatewaycom.com >>> >>>-----Original Message----- >>>From: 'Jan Janak' [mailto:jan@iptel.org] >>>Sent: Wednesday, November 16, 2005 11:29 AM >>>To: Bogdan-Andrei Iancu >>>Cc: Lenir; 'Lenir Santiago'; serdev(a)iptel.org; serusers(a)iptel.org; >>>devel(a)openser.org; users(a)openser.org >>>Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius >>>Accounting >>> >>>Why would you do something like this ? All the info that is needed is in >>>Sip-Translated-Ruquest-ID below. You can see it in the RADIUS dump: >>> >>>Sip-Translated-Request-URI = "sip:949449852150#15615551212@gateway:5060" >>> >>> Jan. >>> >>>On 16-11-2005 16:50, Bogdan-Andrei Iancu wrote: >>> >>>>Hi Lenir, >>>> >>>>you can keep the modified To value into an AVP and use the extra >>>>accounting feature to log it. See >>>> http://www.openser.org/docs/modules/1.1.x/acc.html#AEN115 >>>>and >>>> http://www.openser.org/docs/modules/1.1.x/acc.html#AEN350 >>>> >>>>the problem is how to set it as Called-Station-ID attribute in order > > to > >>>>avoid overlapping. You can do a trick by playing with the radius >>>>dictionary (on proxy side) : >>>> changed the Called-Station-ID to a different ID attribute >>>> set extra accounting with the original attribute ID of >>> >>>Called-Station-ID >>> >>>>in this way the acc will set de default TO as something else and you > > AVP > >>>>as Called-Station-ID ;) >>>> >>>>regards, >>>>bogdan >>>> >>>> >>>>Lenir wrote: >>>> >>>> >>>>>Well, if userA dials to:30, 30 gets translated to:15615551212 and SER >>> >>>dials >>> >>>>>15615551212, how can I make the acc.so module send the modified >>>>>to:15615551212 as the Called-Station-ID attribute? >>>>> >>>>>This is important for billing, specially if someone forwards to a > > long > >>>>>distance or international long distance number. >>>>> >>>>>-----Original Message----- >>>>>From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@iptel.org] > > On > >>>>>Behalf Of Jan Janak >>>>>Sent: Wednesday, November 16, 2005 3:15 AM >>>>>To: Lenir Santiago >>>>>Cc: serdev(a)iptel.org; serusers(a)iptel.org; users(a)openser.org; >>>>>devel(a)openser.org >>>>>Subject: [Serusers] Re: [Serdev] Inaccurate Radius Accounting >>>>> >>>>>Hello, >>>>> >>>>>Called-Station-Id attribute always contains the To URI (not >>>>>Request-URI). You can find the outbound Request-URI in >>>>>Sip-Translated-Request-URI attribute. >>>>> >>>>>Even if you rewrite To header field, it will never be accounted in >>>>>Called-Station-Id. >>>>> >>>>>Jan. >>>>> >>>>>On 15-11-2005 21:59, Lenir Santiago wrote: >>>>> >>>>> >>>>> >>>>>>Hey guys, >>>>>> >>>>>> >>>>>> >>>>>>I'm using Radius to do pretty much everything regarding my users, > > i.e. > >>>>>>registrations, authorization, features and preferences. I > > implemented > >>my >> >>>>>> >>>>>> >>>>> >>>>>own >>>>> >>>>> >>>>> >>>>>>way of doing speeddial by using AVPs provided by radius and AVPOPs >>> >>>module, >>> >>>>>>Here is the snippet: >>>>>> >>>>>> >>>>>> >>>>>>AVP-SIP = speedial:30:15615551212 >>>>>> >>>>>> >>>>>> >>>>>> avp_subst("s:caller_speedial/i:99", > > "/(.*):(.*)/\2/"); > >>>>>>#15615551212 >>>>>> >>>>>> avp_printf("i:98","$rU:*"); #30 >>>>>> >>>>>> avp_printf("i:97","sip:$avp($temp2)@$td"); # >>>>>>sip:15615551212@xx.xx.xx.xx >>>>>> >>>>>> avp_printf("i:96","<sip:$avp($temp2)@$td>\r\n"); # >>>>>><sip:15615551212@xx.xx.xx.xx>. >>>>>> >>>>>> xlog("L_N"," SPEEDIALING: $fU is speed-dialing >>>>>>$hdr(To)->$avp($temp2)\n"); >>>>>> >>>>>> if (avp_check("s:caller_speedial", "fm/$temp1/g")) { >>>>>> >>>>>> >>>>>> >>>>>> #avp_pushto("$To","i:96"); >>>>>> >>>>>> #avp_pushto("$ruri","i:97"); >>>>>> >>>>>> #avp_pushto("$duri","i:97"); >>>>>> >>>>>> #subst('/^To: (.*)(a)(.*)/To: "$avp($temp2)" >>>>>><$avp($temp2)@\2/'); >>>>>> >>>>>> #append_hf("To: \"5615551212\" >>>>>><15615551212(a)xx.xx.xx.xx>;user=phone"); >>>>>> >>>>>> >>>>>>#subst_uri('/^sip:(.*)@(.*)$/sip:$avp($temp2)@\2/i'); >>>>>> >>>>>> #subst_user('/(.*)/$avp($temp2)/'); >>>>>> >>>>>> #remove_hf("To"); >>>>>> >>>>>> rewriteuser("15615551212"); >>>>>> >>>>>> xlog("L_N"," SPEEDIALING: $fU is dialing >>>>>> >>>>>> >>>>> >>>>>$hdr(To) >>>>> >>>>> >>>>> >>>>>>$avp($temp2)\n"); >>>>>> >>>>>> avp_delete("$temp1/g"); >>>>>> >>>>>> avp_delete("$temp2/g"); >>>>>> >>>>>> >>>>>> >>>>>> }; >>>>>> >>>>>> >>>>>> >>>>>>In this scenario, im forcing it instead of getting the value from > > AVPs > >>>>>> >>>>>> >>>>> >>>>>just >>>>> >>>>> >>>>> >>>>>>for ease of showing my point. The problem that I'm having is that no >>>>>> >>>>>> >>>>> >>>>>matter >>>>> >>>>> >>>>> >>>>>>what I do to change the To header or change the R-URI, radius ALWAYS >>> >>>sends >>> >>>>>>the accounting records with the original R-URI, in my case >>> >>>30(a)xx.xx.xx.xx, >>> >>>>>>how can I get acc.so to send the final resulting URI >>>>>>(15615551212(a)xx.xx.xx.xx) in the Called-Station-Id AVP? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39216, >> >>id=97, >> >>>>>>length=298 >>>>>> >>>>>> Acct-Status-Type = Start >>>>>> >>>>>> Service-Type = Sip-Session >>>>>> >>>>>> Acct-Terminate-Cause = 200 >>>>>> >>>>>> Error-Cause = Invite >>>>>> >>>>>> User-Name = "1000(a)xx.xx.xx.xx" >>>>>> >>>>>> Calling-Station-Id = "sip:1000@xx.xx.xx.xx" >>>>>> >>>>>> Called-Station-Id = "sip:30@xx.xx.xx.xx;user=phone" >>>>>> >>>>>> Sip-Translated-Request-URI = >>>>>>"sip:949449852150#15615551212@gateway;user=phone" >>>>>> >>>>>> Acct-Session-Id = >>>>>> >>>>>> >>>>> >>>>>"000d2890-d47f01e8-1dcc30bc-7a49c7a4(a)yy.yy.yy.yy" >>>>> >>>>> >>>>> >>>>>> Sip-To-Tag = "230383F4-2AF" >>>>>> >>>>>> Sip-From-Tag = "000d2890d47f20f54576a906-290bdc33" >>>>>> >>>>>> Sip-CSeq = "102" >>>>>> >>>>>> NAS-IP-Address = xx.xx.xx.xx >>>>>> >>>>>> NAS-Port = 5060 >>>>>> >>>>>> Acct-Delay-Time = 0 >>>>>> >>>>>>rlm_sql (sql): Reserving sql socket id: 12 >>>>>> >>>>>>rlm_sql (sql): Released sql socket id: 12 >>>>>> >>>>>>Sending Accounting-Response of id 97 to xx.xx.xx.xx:39216 >>>>>> >>>>>>rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39216, >> >>id=98, >> >>>>>>length=292 >>>>>> >>>>>> Acct-Status-Type = Stop >>>>>> >>>>>> Service-Type = Sip-Session >>>>>> >>>>>> Acct-Terminate-Cause = 200 >>>>>> >>>>>> Error-Cause = 8 >>>>>> >>>>>> User-Name = "1000(a)xx.xx.xx.xx" >>>>>> >>>>>> Calling-Station-Id = "sip:1000@xx.xx.xx.xx" >>>>>> >>>>>> Called-Station-Id = "sip:30@xx.xx.xx.xx;user=phone" >>>>>> >>>>>> Sip-Translated-Request-URI = >>>>>>"sip:949449852150#15615551212@gateway:5060" >>>>>> >>>>>> Acct-Session-Id = >>>>>> >>>>>> >>>>> >>>>>"000d2890-d47f01e8-1dcc30bc-7a49c7a4(a)yy.yy.yy.yy" >>>>> >>>>> >>>>> >>>>>> Sip-To-Tag = "230383F4-2AF" >>>>>> >>>>>> Sip-From-Tag = "000d2890d47f20f54576a906-290bdc33" >>>>>> >>>>>> Sip-CSeq = "103" >>>>>> >>>>>> NAS-IP-Address = xx.xx.xx.xx >>>>>> >>>>>> NAS-Port = 5060 >>>>>> >>>>>> Acct-Delay-Time = 0 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Thanks in advance! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Lenir >>>>>>_______________________________________________ >>>>>>Users mailing list >>>>>>Users(a)openser.org >>>>>>http://openser.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>> >>_______________________________________________ >>Users mailing list >>Users(a)openser.org >>http://openser.org/cgi-bin/mailman/listinfo/users >> > > > > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > >

2 2

[Users] Multiple mediaproxy instances
by Fernando Rodriguez 17 Nov '05

17 Nov '05

Hello, I have an openser box that has multiple interfaces each one with its own ip address and i was wondering how to run various mediaproxy instances in the same machine per ip address so I can have communication between interfaces and proxy all traffic coming and going between the UA, I have been trying to get information on this and I found that is valid to do this but I cant find any info on how to doit, actually if people can give me hint or a basic setup I could write a howto , actually im a newbe on openser but I can see a lot of potential if we had a basic manual and soma basic setup examples. Thanks a lot for your help. Fernando Rodriguez V.

1 0

[Users] Can I run this SIP server without running mysql.
by Mahesh Krishnan 17 Nov '05

17 Nov '05

I have the SIP server running. But I am not able to add any users. Do I have to install mysql to add users. Unfortunately the documentation is also not good. It mentions only how to start the server and then thats it. I stop it basically by killing it. [Ctrl-C]. I installed it by compiling and linking it from source. Basically this is what I am looking at. 1. Installed and started SIP server. -- Works 2. try to add a user with openserctl -- fails. no mysql connection. I do not have mysql started on my system. -- Mahesh. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

4 3

Re: [Users] Usrloc question
by Daniel-Constantin Mierla 17 Nov '05

17 Nov '05

Hello, there is a solution using the branch_route[] in openser. For each branch created after the usrloc lookup you can make different checks. So, in the branch route you have to check the IP in the R-URI and if matches the asterisk IP, then drop it (http://openser.org/dokuwiki/doku.php?id=openser_core_cookbook#drop). There is an example how to check source and destination addresses, although in your case you can do it even without avps: http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_org_dst Cheers, Daniel On 11/15/05 17:05, Darren Nay wrote: > > Hey all, > > I have a question regarding usrloc. I have run into a problem.. > > We have static routes sent to an asterisk server for all of our SIP > usernames. In addition our IAD’s will register with the same username, > so that calls coming into our switch for that username will be routed > to both the asterisk box and the SIP IAD. This way, whichever endpoint > (IAD or asterisk) answers the call first will take the call. > > For example. > > root:/ # serctl ul show +18646404810 > > <sip:+18646404810@192.168.1.60>;q=1;expires=-1012151 > > <sip:+18646404810@192.168.1.157:5060>;q=;expires=403 > > 192.168.1.60 is the asterisk server. This is a static route added by > serctl. > > 192.168.1.157 is my IAD which registers with the switch every 10 minutes. > > So when calls are made to (864) 640-4810 then SER will send an INVITE > to both location. > > I explained all of this just to explain now what my problem is, and > ask if anyone may know a possible solution. > > Now, we also use asterisk to perform call fwd’ing functions. Asterisk > will answer the call and then originate another call out back to SER > to a new location. Now the problem! (finally!) This call fwd’ing > method works very well in most cases, except that if the call fwd’ing > is being sent to another location registered with SER then it will be > redirected back to asterisk again, albeit to a different URI, and > asterisk will kill the call because it thinks that it has looped > (which I guess it has… sort of). > > So, I’m wondering if there is possibly a way to retrieve only the > usrloc locations that don’t contain the IP address 192.168.1.60 in the > contact URI? This way I can just check if the src_ip is 192.168.1.60 > and if so then retrieve all the usrloc locations – without asterisk – > and the call will not be redirected back to asterisk. > > Is this possible? Or if anyone has any other ideas that may help then > I am definitely open to suggestions. > > Thanks for your help!! > > Darren Nay > > Ionosphere, Inc > > VoIP Network Development > > dnay(a)ionosphere.net <mailto:dnay@ionosphere.net> > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >

1 0

[Serusers] Re: [Serdev] ACK before INVITE on re-INVITE causes CiscoAS's to return a 500 error
by Ettore Benedetti 17 Nov '05

17 Nov '05

Hallo Evan, I reckon Nils is right on the matter. The ACK of the dialog-forming INVITE is actually the first in-dialog request and, as a matter of fact, it is a separate transaction. As far as the UAS is concerned, the dialog is established as soon as the 200 response is sent. The Cisco GW just misbehaves provided the first INVITE from Asterisk did contain an SDP offer (didn't it?). Ettore Benedetti THALES COMMUNICATIONS B.V. Bestevaer 46, 1271 ZA Huizen The Netherlands Unclassified >>> Evan Borgstrom <evan.borgstrom(a)ca.mci.com> 11/16/05 5:27:52 PM >>> Hey Nils, You are correct that each message is handled by a different process, as it to be expected, and I know that SER is not call statefull so my concern lies around the fact that SER is delivering an INVITE which requires FAR more processing and at least 2 database hits before a loosely routed ACK which requires little to none for processing. I'm going to differ with you, and my self from last night, on the views about the RFC as it does indeed cover the problem (I was just looking at it the wrong way before). A re-INVITE cannot modify a dialog that does not exist, and without the ACK being delivered in response to the 200 OK the dialog is not yet created which is why the Cisco is returning a CheckRequest failure since there's no dialog to map the re-INVITE to. So, the device is correct in returning an error. When the Cisco returns the 500 error it's only for the re-INVITE so the initial call stays established and a BYE is still required to tear it down. The problem is that Asterisk is expecting that to work and has already re-INVITED to the client so there's no audio and to the caller the call failed. -Evan Nils Ohlmeier wrote: > Evan, > > I would not invest the time to look into the SER side of your problem. Because > this is a general problem. Instead of SER any other network element (router, > switch, etc.) could change the order of the packets. > BTW I guess this problem occurs on your SER because the ACK and the INVITE are > handled by different SER processes. And as SER is not call-statefull there is > no parameter to solve this situation. > > I fear you are right that this problem is not covered by any RFC, but the > solutions seems logical to me: > if this a generic problem, then either the UAC is not allowed to send a > re-INVITE until the first INVITE is completed, or the UAS has to accept a > re-INVITE after sending the 200 OK. But how does the the UAC know that the > ACK reached the UAS so that it can send the re-INVITE now? It cant know that, > so it would have to wait for a timer before it could send the re-INVITE. > On the other side the INVITE transaction is completed for the UAS by sending > the 200 OK (the ACK is a new transaction, according to the branch). > Thus I think the UAS (the Cisco gateway) should accept the re-INVITE without > complaining. > > Just for curiosity: is the call established or does the Cisco gateway drop the > call after sending the 500? > > Regards > Nils > > On Wednesday 16 November 2005 07:51, Greger V. Teigre wrote: >> Evan, >> I'm not able to match your text with the messages you show. The message >> timestamped 16:51:51.559657, does it go to Cisco? It is shown to go to >> Asterisk and it doesn't make sense. >> However, until the Cisco gw receives the ACK from Asterisk, no call has >> been established and the reINVITE cannot be matched. IMO, this is not a >> Cisco bug. It seems very strange indeed that ser should send a reINVITE >> before the ACK in the same call. Even without FIFO, an INVITE is likely to >> take more time to process than a loose routed ACK. I would try to log more >> thoroughly in SER to see what happens in processing the ACK and the >> reINVITE. It could be a problem in your ser.cfg, but it seems strange >> indeed. >> g-) >> >> ----- Original Message ----- >> From: "Evan Borgstrom" <evan.borgstrom(a)ca.mci.com> >> To: <serusers(a)lists.iptel.org>; <serdev(a)lists.iptel.org> >> Sent: Wednesday, November 16, 2005 12:05 AM >> Subject: [Serdev] ACK before INVITE on re-INVITE causes Cisco AS's to >> return a 500 error >> >>> Hey all, >>> >>> This has more to do with Asterisk & Cisco AS's IMO but I thought it >>> would be interesting to get some responses from this group before I >>> begin the battle with Cisco to get a bug report underway. >>> >>> We have an Asterisk box acting as a PBX sending calls to our SER >>> instances. The asterisk box has "reinvite=yes" in the sip.conf file >>> which causes Asterisk to send a re-INVITE for the call once it receives >>> the 200 OK. This re-INVITE has it's SDP changed to that of the IP Phone >>> behind the Asterisk box so that all media doesn't need to traverse it. >>> This works fine except in certain instances where messages get out of >>> order and it causes our Cisco GW's to error the call with a generic 500 >>> message. When the messages are in the correct order the 500 error does >>> not appear. >>> >>> So here's the situation, user behind the asterisk box picks up the >>> phone and dials a PSTN destination. Asterisk fires off the initial >>> invite and everything proceeds as normal and we eventually receive the >>> 200 OK message to which the Asterisk box replies with ACK and a new >>> INVITE that come in this order (X = Asterisk, Y = SER, Z = Cisco): >>> >>> U 2005/11/15 16:51:51.557322 X.X.X.X:5060 -> Y.Y.Y.Y:5060 >>> ACK >>> >>> # >>> U 2005/11/15 16:51:51.557948 X.X.X.X:5060 -> Y.Y.Y.Y:5060 >>> INVITE >>> >>> SER accordingly processes the two messages and replies 100 Trying to >>> the new INVITE message. Here's where the problem occurs, SER then sends >>> these messages out to the PSTN gateway but the order has been reversed: >>> >>> # >>> U 2005/11/15 16:51:51.558937 Y.Y.Y.Y:5060 -> X.X.X.X:5060 >>> SIP/2.0 100 trying >>> >>> # >>> U 2005/11/15 16:51:51.559000 Y.Y.Y.Y:5060 -> Z.Z.Z.Z:5060 >>> INVITE >>> >>> # >>> U 2005/11/15 16:51:51.559657 Y.Y.Y.Y:5060 -> X.X.X.X:5060 >>> ACK >>> >>> When this happens the Cisco GW replies with a 500 error message and the >>> following is sent to the Cisco's logs: >>> >>> # >>> U 2005/11/15 16:51:51.711355 Z.Z.Z.Z:5060 -> Y.Y.Y.Y:5060 >>> SIP/2.0 500 Server Internal Error. >>> >>> >>> Nov 15 21:51:51.613: HandleUdpSocketReads :Msg enqueued for SPI with >>> IPaddr: Y.Y.Y.Y:5060 >>> Nov 15 21:51:51.613: *****CCB found in UAS Request table. ccb=0x653BCD0C >>> Nov 15 21:51:51.613: CCSIP-SPI-CONTROL: act_sentsucc_new_message >>> Nov 15 21:51:51.617: CCSIP-SPI-CONTROL: act_sentsucc_new_message_request >>> Nov 15 21:51:51.617: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE >>> Nov 15 21:51:51.617: sip_stats_status_code >>> Nov 15 21:51:51.617: sipSPICheckRequest: CheckRequest fail on method 102 >>> error code: 2 and status: 500 >>> >>> >>> Is there any parameter that I can set to ensure that message leave SER >>> in the order they enter? Should the Cisco be able to handle this >>> condition (I check a number of different sections of the RFC but >>> couldn't find anything specific for either side)? >>> >>> Thanks, >>> Evan >>> >>> _______________________________________________ >>> Serdev mailing list >>> serdev(a)lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serdev >> _______________________________________________ >> Serdev mailing list >> serdev(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serdev _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

1 0

[Serusers] ser High Availability
by Arne Van Theemsche 17 Nov '05

17 Nov '05

Hi I've been thinking on making a HA setup with multiple ser's. Wat would be the best solution? 1) Sharing a usrloc database? Then I think the only way is to use db_mode 1 (every read out of a database), but would cause a lot of overhead because of every request needs a sqlquery. Method 2 doesn't seem to work, because if I delete a record manually from database, the internal DB doesn't get synced to that 2) evey SER automaticly dials also to all ser's in the clusters, and the one's who have a known location, dial them. Don't know if this would give errors when the same user is connected to multiple ser's? thx Arne

1 0

[Users] 302 Redirect behavior
by Brandon Price 17 Nov '05

17 Nov '05

I am trying to use the uac_redirect module to duplicate the behavior that asterisk performs when it receives a 302-Moved Temporarily from a registered user agent. It basically extracts the number to forward to from the SIP contact address in the 302 reply. For example if "sip: 13143212222(a)ser1.voipnoc.net" is the sip contact address then 13143212222 is the number (of coarse). It then executes whatever code matches that pattern. This works perfectly for me but ends up making 2 calls because I get the invite, I send it to the UA, and then I do another dial if there is a forward. That of coarse costs me twice as much. I have tried... if(t_check_status("302")){ # what to do if device tells us to forward to another number xlog("A redirect"); get_redirects("*","redirect"); rewritehost("our.pstn.gw.ip"); t_relay(); return; I simply need it to get the number to redirect to from the contact portion and forward the invite to that number @ our pstn gateway. Any help greatly appreciated.

2 1

[Serusers] ERROR: exec_str: cmd /etc/ser/sipldap failed. exit_status=-1, errno=10: No child processes
by davor jovanovic 17 Nov '05

17 Nov '05

Hi all, I'm using SER 0.9.3 and trying to do LDAP query but I keep getting this message: 0(17313) INFO: dont_fork turned on, living on 0(17313) exec_str: rtrim 0(17313) ERROR: exec_str: cmd /etc/ser/sipldap failed. exit_status=-1, errno=10: No child processes can someone explain to me why is that and how can I fix it? when I'm doing lookup with: (!lookup("location")) { if (!exec_dset("/etc/ser/sipldap")) { sl_send_reply("404", "Not Found"); break; } else { log(1," sipldap call"); }; }; I'm getting "Not Found", but when I'm doing (transferring to PSTN route without sl_send_reply) (!lookup("location")) { if (!exec_dset("/etc/ser/sipldap")) { #sl_send_reply("404", "Not Found"); route(5); break; } else { log(1," sipldap call"); }; }; route[5] { rewritehostport(xxxxxxxxxxx); I do extract LDAP telephone number (so "sipldap" script works OK) and do get call transferred to PSTN GW but still getting "ERROR: exec_str:" thanx davor

1 0

← Newer
1
...
28
29
30
31
32
33
34
...
58
Older →

Jump to page:

2025

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