sr-users July 2005

sr-users@lists.kamailio.org

199 participants
544 discussions

by zhu lizhong

Hello, guys: I sent a help message to you before since I got problems in acc tables. Now i made some changes, and it finally works. thanks you for guys. now I want to share my tips to you who are need acc records, because many people have this problem. first, make sure that you must confiugre Makefile in acc module and recompile it properly. second load acc module into ser.cfg. third, put all necessary into ser and route section. please follow the sequences. maybe some parts are not really necessary. but there is data in acc. Now i show you my ser.cfg. loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/acc.so" modparam("auth_db|uri_db|usrloc|acc", "db_url", "mysql://ser:heslo@localhost/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("usrloc", "db_mode", 1) modparam("rr", "enable_full_lr", 1) modparam("acc", "db_flag", 1) # Record Route Section # testing from zhu----------------------------------------------------------------- if (method=="INVITE" || method=="ACK") { log (1, "%method - INVITE or ACK MESSAGE RECEIVED - START ACCOUNTING\n"); setflag(1); # record_route(); }; if (method=="BYE" || method=="CANCEL") { log (1, "%method - STOP ACCOUNTING\n"); setflag(1); # record_route(); }; # end of testing -------------------------------------------- if (method!="REGISTER") { record_route(); setflag(2); }; this is data section received from acc table of mysql: | 333 <sip:333@192.168.1.26:5061>;tag=249979601 | <sip:800@192.168.1.26>;tag=1273583692 | 200 | INVITE | sip:800@192.168.1.188:5061 | sip:800@192.168.1.188:5061 | sip:333@192.168.1.26:5061 | sip:800@192.168.1.26 | 4E916DD5-2141-3B23-08CC-6F2CEA3B405B(a)192.168.1.26 | 333 | 192.168.1.26 | 249979601 | 1273583692 | 2005-07-28 01:50:01 | 20050728095001 | 0 | 0 | | 333 <sip:333@192.168.1.26:5061>;tag=249979601 | <sip:800@192.168.1.26>;tag=1273583692 | 200 | ACK | sip:800@192.168.1.188:5061 | sip:800@192.168.1.188:5061 | sip:333@192.168.1.26:5061 | sip:800@192.168.1.26 | 4E916DD5-2141-3B23-08CC-6F2CEA3B405B(a)192.168.1.26 | 333 | 192.168.1.26 | 249979601 | 1273583692 | 2005-07-28 01:50:01 | 20050728095001 | 0 | 0 | | 333 <sip:333@192.168.1.26:5061>;tag=249979601 | <sip:800@192.168.1.26>;tag=1273583692 | 200 | BYE | sip:800@192.168.1.188:5061 | sip:800@192.168.1.188:5061 | sip:333@192.168.1.26:5061 | sip:800@192.168.1.26 | 4E916DD5-2141-3B23-08CC-6F2CEA3B405B(a)192.168.1.26 | 333 | 192.168.1.26 | 249979601 | 1273583692 | 2005-07-28 01:50:03 | 20050728095003 | 0 | 0 | try it!

19 years, 3 months

[Serusers] No record inserted into the acc table of mysql!

by zhu lizhong

Hello, guys: thanks for your replies. I run SER and make sip call. I configured ser.cfg and some message are displayed as fowwlow: loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/acc.so" modparam("acc","log_level",1) modparam("acc","log_flag",1) # modparam("acc", "db_url","flatstore:/var/log/acc") modparam("acc", "db_flag", 1) # modparam("acc", "db_missed_flag", 1) # modparam("acc", "failed_transactions", 2) modparam("auth_db|uri_db|usrloc|acc", "db_url", "mysql://ser:heslo@localhost/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("usrloc", "db_mode", 1) if (method=="INVITE" || method=="ACK") { log (1, "%method - INVITE or ACK MESSAGE RECEIVED - START ACCOUNTING\n"); setflag(1); # record_route(); }; if (method=="BYE" || method=="CANCEL") { log (1, "%method - STOP ACCOUNTING\n"); setflag(1); # record_route(); }; # end of testing -------------------------------------------- if (method!="REGISTER") { record_route(); setflag(2); }; some messages are capured : ACK sip:800@192.168.1.188:5061 SIP/2.0 Record-Route: <sip:192.168.1.26;ftag=78086448;lr=on> Via: SIP/2.0/UDP 192.168.1.26;branch=0 Via: SIP/2.0/UDP 211.25.2.30:5061;received=192.168.1.26;rport=5061;branch=z9hG4bK255A602DB910243AC238B003FB36CE58 From: 333 <sip:333@192.168.1.26:5061>;tag=78086448 To: <sip:800@192.168.1.26>;tag=542148979 Contact: <sip:333@211.25.2.30:5061> Call-ID: 0CF994AF-C18C-4447-A6D3-758FF4EB99A8(a)192.168.1.26 CSeq: 9213 ACK Max-Forwards: 16 Content-Length: 0 SIP/2.0 200 Ok Via: SIP/2.0/UDP 211.25.2.30:5061;received=192.168.1.26;rport=5061;branch=z9hG4bK7D8A9CF509DF4CAC2EB9DF19BEB26EE3 From: 333 <sip:333@192.168.1.26:5061>;tag=78086448 To: <sip:800@192.168.1.26>;tag=542148979 Contact: <sip:800@192.168.1.188:5061> Call-ID: 0CF994AF-C18C-4447-A6D3-758FF4EB99A8(a)192.168.1.26 CSeq: 9214 BYE Server: X-Lite release 1105d Content-Length: 0 2(2160) WARNING:vqm_resize: resize(0) called 2(2160) DEBUG: add_to_tail_of_timer[2]: 0x422c2440 2(2160) DEBUG: reply relayed. buf=0x8103438: SIP/2.0 2..., shmem=0x422c3e68: SIP/2.0 2 2(2160) DBG: trans=0x422c23f8, callback type 128, id 0 entered 2(2160) ACC: transaction answered: method=BYE, i-uri=sip:800@192.168.1.188:5061, o-uri=sip:800@192.168.1.188:5061, call_id=0CF994AF-C18C-4447-A6D3-758FF4EB99A8(a)192.168.1.26, from=333 I know there is something happened, maybe, somewhere is worng in route section. Please give me some suggestions! thanks in advance! lizhong

19 years, 3 months

[Serusers] new replication module

by Jev

Hi, On line 136 of modules/tm/doc/tm.xml there is reference made to a new replication module. Is this a public module? Where can I find out more about this module? Cheers, -Jev

19 years, 3 months

Re: [Serusers] Problem : Can SER process the reINVITE messages pr operly?

by Alberto Cruz

Yes it is working fine. Regards Ricardo Martinez wrote: > Alberto. > Thanks for your answer. You mean that your platform works well > with the reINVITE's to a NAT'd endpoint?. > > Regards, > Ricardo.- > > -----Mensaje original----- > De: Alberto Cruz [mailto:acruz@tekbrain.com] > Enviado el: Miércoles, 27 de Julio de 2005 16:12 > Para: Ricardo Martinez > CC: 'Greger V. Teigre'; 'serusers(a)lists.iptel.org' > Asunto: Re: [Serusers] Problem : Can SER process the reINVITE > messages pr operly? > Importancia: Alta > > Ricardo this block is working fine to me: > > #------------------------------------------------- > # subsequent messages withing a dialog should take the > # path determined by record-routing > #------------------------------------------------- > if (loose_route()) { > append_hf("P-hint: rr-enforced\r\n"); > # The following lines are added due media proxy > if (has_totag()&&(method=="INVITE" || > method=="ACK")) { > if (client_nat_test("3") || > search("^Route:.*;nat=yes")) { > # Mark as NAT'ed > setflag(6); > use_media_proxy(); > }; > }; > if ((method=="BYE") && ((client_nat_test("3") || > search("^Route:.*;nat=yes")))) { > fix_nated_contact(); > force_rport(); > }; > # end media session for BYE and CANCEL is done above > # before entering the loose route. no need to call > it here > route(1); > break; > }; > > Maybe you have something wrong at your mediaproxy.ini file. > > Regards > > Alberto Cruz > >> >>

19 years, 3 months

[Serusers] SDP of payload settings

by Jason Mohler

Hello All, I am using SER and ran into a stumper. I am trying to set my SDP payload settings to the following below but I do not know how to config it in my invite message. Does anyone have a solution to my problem? Thank you for any information thqt you can provide.. a=rtpmap:0 PCMU/8000. a=rtpmap:100 X-NSE/8000. a=fmtp:100 192-194. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20.

19 years, 3 months

Re: [Users] ACK processing (was: CANCEL processing)

by Michael Ulitskiy

Thanks, Bogdan. So it's still better to process CANCEL the same as INVITE to avoid this race condition. My next question is about ACK processing. In my observations if one uses statefull processing ACKs are either loose_routed or absorbed by t_relay(). In my test scenarios I've never seen otherwise. So, again, my question is if the following is OK: if (loose_route()) { #in-dialog ACKs are forwarded here do something t_relay(); exit; } if (is_method("ACK")) { #out-of-dialog ACKs are absorbed here t_relay(); exit; } if (uri==myself) { do lookups that rewrite RURI t_relay(); } Thank you, Michael > On Monday 25 July 2005 07:39 am, you wrote: > > Hi Michael, > > > > that is correct. just note you may encounter some races between INVITEs > > and CANCELs in the case of a fast CANCEL (CANCEL follows the INVITE > > almost instantly) - when one process is still handling the INVITE (the > > transaction may not be build yet), another process receives the CANCEL > > and it will not be able to match it to a transaction in this case, the > > CANCEL will be forward based on its RURI without any info from INVITE..... > > > > regards, > > bogdan > > > > Michael Ulitskiy wrote: > > > > >Hello, > > > > > >I have a question about CANCEL processing. > > >I read on the mailing list that CANCEL will be automatically matched by t_relay > > >to transaction it's cancelling, if needed transformation to RURI will be automatically > > >applied and then it will be automatically send to correct destination. > > >I'm experimenting with openser 0.10.x and it seems to be true, but I'd like to confirm > > >that the following is OK: > > > > > >if (loose_route()) { > > > do something > > > t_relay(); > > > break; > > >} > > >if (is_method("CANCEL")) { > > > t_relay(); > > > break; > > >} > > >if (uri==myself) { > > > do lookups that rewrite RURI > > > t_relay(); > > >} > > > > > >Thank you, > > > > > > > > > > > > > >

19 years, 3 months

RE: [Serusers] Problem : Can SER process the reINVITE messages pr operly?

by Ricardo Martinez

Alberto. Thanks for your answer. You mean that your platform works well with the reINVITE's to a NAT'd endpoint?. Regards, Ricardo.- -----Mensaje original----- De: Alberto Cruz [mailto:acruz@tekbrain.com] Enviado el: Miércoles, 27 de Julio de 2005 16:12 Para: Ricardo Martinez CC: 'Greger V. Teigre'; 'serusers(a)lists.iptel.org' Asunto: Re: [Serusers] Problem : Can SER process the reINVITE messages pr operly? Importancia: Alta Ricardo this block is working fine to me: #------------------------------------------------- # subsequent messages withing a dialog should take the # path determined by record-routing #------------------------------------------------- if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); # The following lines are added due media proxy if (has_totag()&&(method=="INVITE" || method=="ACK")) { if (client_nat_test("3") || search("^Route:.*;nat=yes")) { # Mark as NAT'ed setflag(6); use_media_proxy(); }; }; if ((method=="BYE") && ((client_nat_test("3") || search("^Route:.*;nat=yes")))) { fix_nated_contact(); force_rport(); }; # end media session for BYE and CANCEL is done above # before entering the loose route. no need to call it here route(1); break; }; Maybe you have something wrong at your mediaproxy.ini file. Regards Alberto Cruz

19 years, 3 months

[Serusers] How to avoid sending messages more than once at the same destination?

by Alberto Cruz

Hi I have an issue. We are using B2BUA in the middle of SER and the UA and the PSTN-GW. Sometimes when a call is canceled the B2BUA finished the call transaction and clear the call id from the memory before it receives the 408 message from SER so SER continues sending the same message many times until it completes the max forwards time. Is there a way to tell SER if it don't receive a replay for that message it stop sending the message again? Regards Alberto Cruz

19 years, 3 months

RE: [Serusers] Problem : Can SER process the reINVITE messages pr operly?

by Ricardo Martinez

Hello Greger and SER users. About this issue here are some test that i made. I added the lookup("location") as you recommend me : # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { if (has_totag() && (method=="INVITE" || method=="ACK")) { lookup("location"); if (isflagset(6) || client_nat_test("3") || search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); break; }; Unfortunately, i'm still unable to have voice in both ways, but this modification seems to handle better the reINVITE message. And this is why. For the normal approach (i mean the initial onsip_pstn configuration) the second INVITE was not using the mediaproxym as Greger pointed. Now, as you can see in the debugs that i'm attaching, the second invite is using the mediaproxy, and therefore the "c" parameter in the SDP message is being correctly modified by SER. So, i don't understand why this time the call is failing. Could it be that mediaproxy is not capable to handle the reINVITEs?. For example in the debug from mediaproxy (i'm also attaching this one), i see a warning message like this : warning: Received packet from a third party: 200.0.0.7:16432. It seems like mediaproxy is not accepting "voice packets" from the second IP (the one indicated by the reINVITE). Why? Also, when the call is established this is the output from the "session" command : Caller Via Called Status Duration Codec Type Traffic ---------------------------------------------------------------------------- -------------------------------------- 200.0.0.6:17480 - 200.0.0.5:35094 - 200.0.0.4:46115 inactive 0'24" G729 Audio 0/16.75k/16.75k The call is established but between the first IP (Asterisk box) and the endpoint public IP. So, could this be a problem with mediaproxy?. I read the changelog from the version 1.3.1 and this is what i found : Changes from version 1.2.1 to 1.3.0 ----------------------------------- - Only create a new session if a request belongs to the first INVITE (no longer creates new sessions on re-INVITEs) could it be related?. I also have a general question about the reINVITE. As you can see the first INVITE has in his URI the domain name for the number : 5555848114(a)sipvoiss.desarrollo.redvoiss.net (Frame 1 from the debug). The reINVITE sent by Asterisk has the URI : 5555848114(a)200.0.0.4. Is this ok?, despite of this the reINVITE is correctly redirected to the endpoint. (You can check this in the frame 13 from the debug). Thanks again. Regards, Ricardo Martinez.-

19 years, 3 months

[Users] rpid problem

by Klaus Darilion

Hi! I'm using openser CVS and try to deliver the rpid using auth_radius. But the rpid never appears in the AVPs. Also other AVP-SIP attributes (e.g. SIP-AVP = #101:TEST) do not appear in the AVP. Filling AVPs in the .cfg using avp_write("$ruri/username","$ruser"); works fine and are printed with avp_print. Any ideas how I can track down this problem? thanks klaus The radius server responds with a SIP-AVP (225) attribute (verfied with tcpdump): rpid:<sip:+4359966366102@1013cbc.com> my cfg snippet (full config attached): if (!radius_proxy_authorize("")) { xlog("L_WARN","wrong or no credentials - challenging client ..."); proxy_challenge("", "0"); exit; }; xlog("L_WARN","start avp_print()-"); avp_print(); xlog("L_WARN","stop avp_print()--"); the debug log: 8(5807) checking REGISTER authentication ... 8(5807) check_nonce(): comparing [42e78dca8153d605c63042be302f64af00e1abfc] and [42e78dca8153d605c63042be302f64af00e1abfc] 8(5807) DEBUG:auth_radius:radius_authorize_sterman: Success 8(5807) xl_printf: final buffer length 37 8(5807) start avp_print() - 8(5807) xl_printf: final buffer length 37 8(5807) stop avp_print() -- 8(5807) xl_printf: final buffer length 58 # # $Id: openser.cfg,v 1.1.1.1 2005/06/13 16:47:30 bogdan_iancu Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=7 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E) /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #port=5060 #children=4 fifo="/tmp/openser_fifo" listen=1.2.3.83:5060 log_facility=LOG_LOCAL4 # /var/log/openser.log # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database #loadmodule "/usr/local/lib/ser/modules/mysql.so" mpath="/usr/lib/openser/modules" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "postgres.so" loadmodule "domain.so" loadmodule "alias_db.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "auth.so" loadmodule "auth_radius.so" loadmodule "avpops.so" # ----------------- setting module-specific parameters --------------- # database configuration modparam("usrloc", "db_url", "postgres://openser:xxxxxx@localhost/openser") modparam("domain|uri_db|alias_db", "db_url", "postgres://openserro:xxxxxxx@localhost/openser") # radius configuration modparam("auth_radius", "radius_config", "/etc/openser/radiusclient.conf") # multi domain configuration modparam("domain", "db_mode", 1) # Use caching in domain module modparam("alias_db|usrloc|registrar", "use_domain", 1) # group, group_radius, speeddial, uri_db, avpops # -- usrloc params -- modparam("usrloc", "db_mode", 1) # 0=no DB, 1 = write through, 2=caching # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # AVPs # I:101 = cbcprefix # call by call provider prefix # I:102 = ruser # userpart in request uri # I:103 = rdomain # domainpart in request uri # I:104 = dummy1 # I:105 = dummy2 # modparam("avpops","avp_aliases","cbcprefix=I:101;ruser=I:102;rdomain=I:103;dummy1=I:104;dummy2=I:105") # ------------------------- request routing logic ------------------- # main routing logic route{ xlog("L_WARN","[$Tf] $rm $ru ($fu --> $tu)"); #xlog("L_WARN","reference to message buffer: $mb"); xlog("L_WARN","playing around with avps..."); avp_write("$ruri/username","$ruser"); avp_write("$ruri/domain","$rdomain"); # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { xlog("L_WARN","too many hops, reply with 483 ..."); sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { xlog("L_WARN","message too big, reply with 513 ..."); sl_send_reply("513", "Message too big"); exit; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!is_method("REGISTER")) { record_route(); } # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { log(1,"loose_route processing ..."); # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); exit; }; if (!is_method("REGISTER|CANCEL|ACK|BYE|OPTIONS|INFO")) { if (is_from_local()) { xlog("L_WARN","checking authentication ..."); # digest authentication if (!radius_proxy_authorize("")) { xlog("L_WARN","wrong or no credentials - challenging client ..."); proxy_challenge("", "0"); exit; }; xlog("L_WARN","start avp_print()--------"); avp_print(); xlog("L_WARN","stop avp_print()---------"); consume_credentials(); xlog("L_WARN","username/password correct ..."); log(1,"adding rpid header ..."); append_rpid_hf(); } } if (!is_uri_host_local()) { log(1,"outbound request ..."); # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); exit; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (is_uri_host_local()) { if (is_method("REGISTER")) { if (is_from_local()) { log(1,"processing REGISTER ..."); xlog("L_WARN","checking REGISTER authentication ..."); # digest authentication if (!radius_www_authorize("")) { xlog("L_WARN","wrong or no credentials in REGISTER - challenging client ..."); www_challenge("", "0"); exit; }; xlog("L_WARN","start avp_print() of REGISTER--------"); avp_print(); xlog("L_WARN","stop avp_print() of REGISTER---------"); consume_credentials(); xlog("L_WARN","username/password correct in REGISTER, saving location ..."); save("location"); exit; } else { xlog("L_WARN","REGISTER for unknown domain received, reply with 403 ..."); sl_send_reply("403","Use your own proxy"); exit; } }; lookup("aliases"); if (!is_uri_host_local()) { append_hf("P-hint: outbound alias\r\n"); route(1); exit; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { # send to at43 main proxy xlog("L_WARN","user not found, forwarding to main proxy ..."); t_relay_to_udp("1.2.3.160", "5060"); #sl_send_reply("404", "Not Found"); exit; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1); } route[1] { xlog("L_WARN","route[1] entered ..."); # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP xlog("L_WARN","t_relay the request ..."); if (!t_relay()) { sl_reply_error(); }; xlog("L_WARN","... leaving route[1]"); }

19 years, 3 months

← Newer
1
...
4
5
6
7
8
9
10
...
55
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 July 2005