January 2006 - sr-users

[Users] timeout problem with media gateway
by Matteo Piazza 21 Feb '06

21 Feb '06

HI, In my serial forking configuration I have this problem: if i use the a media gateway ( asterisk ) on the same machine ( but I see also on the another machine) of openser ( on the 5061 port) I have a problem with the timeout of a call. The call continues beyond the timeout and when by the PSTN telephone I reject the call appears the following log message: Warning: sl_send_reply: I won't send a reply for ACK!! Where I have mistake? Any idea? Another thing. I see that I redirect the call directly in the media gateway, (for example a location of a user is a PSTN number) whitout the traslation of IP number, all is ok. Matteo ====================================== # # $Id: openser.cfg$ # # # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (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" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "/usr/local/lib/openser/modules/mysql.so" loadmodule "/usr/local/lib/openser/modules/sl.so" loadmodule "/usr/local/lib/openser/modules/tm.so" loadmodule "/usr/local/lib/openser/modules/rr.so" loadmodule "/usr/local/lib/openser/modules/maxfwd.so" loadmodule "/usr/local/lib/openser/modules/usrloc.so" loadmodule "/usr/local/lib/openser/modules/registrar.so" loadmodule "/usr/local/lib/openser/modules/textops.so" loadmodule "/usr/local/lib/openser/modules/avpops.so" loadmodule "/usr/local/lib/openser/modules/xlog.so" loadmodule "/usr/local/lib/openser/modules/lcr.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/openser/modules/auth.so" loadmodule "/usr/local/lib/openser/modules/auth_db.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("registrar", "append_branches", 1) #modparam("usrloc", "db_mode", 0) # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2) # -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # modparam("auth_db", "password_column", "password") # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) modparam("usrloc","db_url","mysql://openser:heslo@127.0.0.1/openser") modparam("auth_db","db_url","mysql://openser:heslo@127.0.0.1/openser") modparam("lcr","db_url","mysql://openser:heslo@127.0.0.1/openser") modparam("avpops","avp_url","mysql://openser:heslo@127.0.0.1/openser") modparam("avpops","avp_table","usr_preferences") modparam("tm", "fr_timer", 7) modparam("tm", "fr_inv_timer", 10) modparam("tm", "wt_timer", 5) #modparam("avpops","avp_aliases","fwdbusy=i:665") # ------------------------- request routing logic ------------------- # main routing logic route{ # ============================================== # initial sanity checks -- messages with # max_forwards==0, or excessively long requests # ============================================== if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; # ============================= # Notify Keep-Alive Section # ============================ if ((method=="NOTIFY") && search("Event: keep-alive")) { sl_send_reply("200","OK"); exit; }; if (method =="INVITE" && uri =~"^sip:0[0-9]*@*"){ log(1, "Check 1 Start PSTN Call\n"); rewritehostport("192.168.9.97:5061"); } # ======================================================== # 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 (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { if(method=="BYE"){ t_relay(); exit; }; # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS #if(uri=~"@tls_domain1.net") { # t_relay_to_tls("IP_domain1","port_domain1"); # exit; #} else if(uri=~"@tls_domain2.net") { # t_relay_to_tls("IP_domain2","port_domain2"); # exit; #} route(1); }; # 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 (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication if (!www_authorize("create-net.it", "subscriber")) { www_challenge("create-net.it", "0"); exit; }; save("location"); exit; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; # ======================================= # PSTN Getaway # ======================================= if(method=="INVITE"){ if (avp_db_load("$ruri","s:fwdactive")) { if(avp_check("s:fwdactive","eq/y/i")){ log(1,"FWD ACTIVE\n!"); setflag(2); } }; if (avp_db_load("$ruri","s:mailactive")) { if(avp_check("s:mailactive","eq/y/i")){ log(1,"MAIL ACTIVE\n!"); setflag(4); } } if(load_contacts()){ xlog("L_ERR","LOAD CONTACTS!\n"); setflag(1); }; if(next_contacts()){ xlog("L_ERR","NEXT CONTACT!\n"); }; }; if(isflagset(2)){ t_on_failure("1"); t_relay(); exit; } else { if(isflagset(4)){ t_on_failure("2"); t_relay(); exit; } else { t_on_failure("3"); t_relay(); exit; } }; } route[1] { # log(1,"ROUTE 1 !\n"); if (!t_relay()) { sl_reply_error(); }; exit; } route[2] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP log(1,"ROUTE 2 !\n"); sl_send_reply("181","CALL IS BEING FORWARDED"); t_on_failure("1"); if (!t_relay()) { sl_reply_error(); }; exit; } failure_route[1]{ log(1,"FAILURE ROUTE FORWARD !\n"); if (t_check_status("408")){ if (next_contacts()) { log(1,"NUOVO CONTATTO !\n"); route(2); exit; } else { log(1,"FINE CHIAMATA - TIME OUT!\n"); if (isflagset(4)){ log(1,"ATTIVAZIONE VOICEMAIL!\n"); revert_uri(); xlog("L_ERR","<$ruri>"); rewritehostport("192.168.9.97:5061"); append_branch(); t_relay(); exit; } exit; }; } else { if ( t_check_status("603") || t_check_status("486") ){ log(1,"OCCUPATO!\n"); if (isflagset(4)){ log(1,"ATTIVAZIONE VOICEMAIL!\n"); revert_uri(); xlog("L_ERR","<$ruri>"); rewritehostport("192.168.9.97:5061"); append_branch(); t_relay(); exit; } exit; } }; } failure_route[2] { log(1,"FINE CHIAMATA 2 - SENZA FORWARD!\n"); revert_uri(); xlog("L_ERR","<$ruri>"); rewritehostport("192.168.9.97:5061"); append_branch(); t_relay(); exit; } failure_route[3] { log(1,"FINE CHIAMATA 3 - SENZA FORWARD!\n"); if ( t_check_status("603") || t_check_status("486") ){ t_relay(); exit; } exit; } ======================================= Matteo Piazza, Junior Researcher CREATE-NET Via Solteri, 38 - 38100 Trento - Italy email: matteo.piazza(a)create-net.it Tel: +39-0461-408400ext:308 www.create-net.it =======================================

3 3

[Users] nathelper natping OPTIONS packets formated to not get reply?
by Glenn Dalgliesh 15 Feb '06

15 Feb '06

I was looking at packet traces of the OPTIONS packets generated by natping and it appears that at least in my implementation of OpenSer 1.0.0 the "To: sip" line has no username which causes many UA's require in order to respond to the OPTIONS packet. I was wondering if this was intentional or if it would be possible to change this behavior or at least make it an configurable option. I think a lot could be done/determined based on the results of the reply; including determining if the packet is really reaching the UA. I realize that some UA's may not support this feature but I think more do than not. Just my observations/thoughts. Please give me reasons for this being a good or bad idea.. Current Packet: U 2006/01/20 16:27:10.410848 111.15.13.67:5060 -> 111.16.187.102:5060 OPTIONS sip:111.16.187.102:5060 SIP/2.0. Via: SIP/2.0/UDP 111.15.13.67:5060;branch=0. From: sip:ping@intervoz.com.br;tag=ec30e9b7. To: sip:111.16.187.102:5060. Call-ID: b3fdcfa3-71a82db5-445151(a)111.15.13.67. CSeq: 1 OPTIONS. Content-Length: 0. Suggested Packet: U 2006/01/20 16:27:10.410848 111.15.13.67:5060 -> 111.16.187.102:5060 OPTIONS sip:<username from location table>@111.16.187.102:5060 SIP/2.0. Via: SIP/2.0/UDP 111.15.13.67:5060;branch=0. From: sip:ping@intervoz.com.br;tag=ec30e9b7. To: sip:111.16.187.102:5060. Call-ID: b3fdcfa3-71a82db5-445151(a)111.15.13.67. CSeq: 1 OPTIONS. Content-Length: 0.

2 7

[Users] New Feature - Global Statistics Management support
by Bogdan-Andrei Iancu 09 Feb '06

09 Feb '06

Hi everybody, A new feature is present on the development version of openser - Global Statistics Management support: the core includes a Statistics Manager which roll is to collect statistics variables from all over openser and to offer management support (to create and operate them); it also provides a single, centralized point of access to allow external apps or internal modules to get any statistics. How it works? the core and the module exports different statistics variables (via the module interface). The Statistics Manager (SM) offers support for auto-initialization, for updating ans resetting variables. The statistics variables are kept into shared mem to be accessible to all processes. Synchronization support is offered by SM. Statistic variable capabilities ------------------------------- be defined with: NO_RESET (it cannot be reset -ex. used mem, register subscribers, etc) NO_SYNC (it will not be synchronized during ops; by their nature, some variables are already synchronized) be updated (added with new val) be reset (set to zero if allowed). Accessing the statistics ------------------------- The SM export two FIFO functions for offering access to the statistics: "get_statistics all" - gets all statistics "get_statistics stat_name" - gets the value of the stat_name variable "get_statistics module_name:" - get all statistics exported by module "module name"; to get statistics from core, use "core" as module_name "reset_statistics stat_name" - sets to 0 the value of the stat_name variable The SM internally offers an API to be used by other modules interested in accessing the statistics. Ex: a future snmp module Current statistics ------------------ For the moment only a few core statistics are defined (we can easily add them in time): received requests : "rcv_reqs" received replies : "rcv_rpls" dropped requests (by scripts or post-script callbacks) : "drp_reqs" dropped replies (by scripts or post-script callbacks) : "drp_rpls" error requests (basic parsing failed) : "err_reqs" error replies (bassic parsing failed) : "err_rpls" How to use it -------------- first to need to enable its compiling - enable the -DSTATISTICS flag in Makefile.def (by default is disabled). Recompile and run openser. Use fifo to get the statistics. Ex: openserctl fifo get_statistics all openserctl fifo get_statistics core: openserctl fifo get_statistics rcv_reqs Next steps ----------- optimization of the SM (better locking for sync, usage of atomic ops if possible) replace old statistics (see stats.c) - the code is not compiling since it depends on some snmp stuff... replace local module statistics (sl,tm,usrloc) with sttistics via SM add more statistics...ideas are welcomed new module to implement dynamic statistics variables to be used from script. regards, bogdan

2 2

[Users] postgres and long AVPs values BUG?
by JF 08 Feb '06

08 Feb '06

Hi, I increased the length of the value column in the usr_preferences table from 128 to 1024, but I got a core dump after these logs: 0(24138) val2str(): converting record_route, 12 0(24138) PG[224] str2valp got string <sip:10.112.64.59;ftag=605ff764c617d3cd28dbbdd72be8f9a2;lr=on>,<sip:10.112.64.12;ftag=605ff764c617d3cd28dbbdd72be8f9a2;lr=on>,<sip:10.112.64.12;ftag=605ff764c617d3cd28dbbdd72be8f9a2;lr=on>,<sip:10.112.64.59;ftag=605ff764c617d3cd28dbbdd72be8f9a2;lr=on> Segmentation fault (core dumped) This was caused by an avp_db_load() call from the script. I'm using OpenSER 1.0.0. I found the following comment on modules/postgres/db_res.c that might have something to do with it: /* I'm not sure about this */ /* PQfsize() gives us the native length in the database, so */ /* an int would be 4, not the strlen of the value */ /* however, strlen of the value would be easy to strlen() */ Also, in modules/postgres/db_val.c, there is a FIXME in val2str() function that seems to be related. Can anyone help solve this problem? It seems like a bug. Thanks, JF

2 4

[Users] avpops, duplicate key, empty username and domain
by JF 08 Feb '06

08 Feb '06

Hi, I'm trying to use avpops module, but I'm facing the following error: 0(8178) PG[367] submit_query query 'insert into usr_preferences (uuid,attribute,value,type,username,domain ) values ('test','avpname','test',0,'','')', result 'ERROR: duplicate key violates unique constraint "usr_preferences_pkey" It seems to be caused by the username and domain parameters being empty strings, since the usr_preferences table has this PK constraint: "usr_preferences_pkey" primary key, btree (attribute, username, "domain") The avpops module is configured like this: modparam("avpops", "avp_url", "postgres://xpto:xpto@127.0.0.1/xpto") modparam("avpops", "avp_table", "usr_preferences") modparam("avpops","use_domain",1) modparam("avpops", "avp_aliases", "avpalias=s:avpname") And I'm simply doing: avp_printf("s:avpname", "test"); avp_db_store("$avpalias/uuid", "s:avpname"); What may be missing? Maybe the usr_preferences table should not have this PK when using UUID-based AVP identification... JF

2 3

[Users] acc module db_extra accounting issue
by Marcello Lupo 08 Feb '06

08 Feb '06

Hi, i have a db_extra accounting rule like: modparam("acc", "db_extra", "customer_code=$avp(i:102)") The avp value is 12 and i checked it with avp_print() . DEBUG:avpops:print_avp: p=0x2a97a866e8, flags=0 DEBUG: id=<102> DEBUG: val_int=<12> When it is accounted in the table the value become 11 !!!!! the field in the table is type int(10) . How is it possible?? Thanks, Bye, MArcello

3 7

[Users] record_route_preset(): No memory left
by Bastian Schern 05 Feb '06

05 Feb '06

Hello to all, I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )": record_route_preset(): No memory left Why this comes? Regards Bastian ____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5138 from 28.01.2006 Virus news: www.antiviruslab.com

2 17

Re: [Users] Using uac_replace_from to munge username between ser and Asterisk?
by Bogdan-Andrei Iancu 03 Feb '06

03 Feb '06

if you enable auto from_restore_mode, you do not need to perform any restore from script. Just replace the from in the initial INVITE and this is it - all replies and sequential request would be auto fixed (restore/replace). regards, bogdan Barry Flanagan wrote: > Bogdan-Andrei Iancu wrote: > >> Hi Barry, >> >> have you set auto from restoring? See: >> http://openser.org/docs/modules/1.1.x/uac.html#AEN75 > > > Yes, but I am not sure where it is supposed to go. > > I have the following in just before relaying to Asterisk: > > rewritehostport("XXX.XXX.XXX.XXX:5060"); > uac_replace_from("$fn","sip:$au_$ar@$fd"); > append_hf("P-hint: GATEWAY\r\n"); > t_relay("udp:XXX.XXX.XXX.XXX:5060"); > > > and I put in uac_restore_from(); just after the record_route() > > > with all the other modparams I have: > > modparam("uac","from_restore_mode","auto") > > > Thanks for the help. > > -Barry > > >> regards, >> bogdan >> >> Barry Flanagan wrote: >> >>> >>> So, the only way around it that I can see is to somehow have OpenSER >>> change the username to username_domain so that each will be unique. >>> >>> It looks like uac_from_replace should handle this. I have tried it, >>> and I can see that Asterisk does in fact get user_domain@domain in >>> the first invite, but thereafter for some reason OpenSER changes it >>> to just _@domain for subsequent requests. >>> >>> >>> Regards, >>> >>> -Barry >>> > >

2 5

[Serusers] SER & SEMS on separate machines
by Amos M. Nungu 02 Feb '06

02 Feb '06

Hello members, I have SER and SEMS on the same machine and it works fine. For performance reasons, I would like to them to be on separate machines. My query is the fact that SEMS uses the email address from the subscriber table in SER db. Do I need to have SER db on the machine where SEMS is running (means 2 identical dbs) or how can I achieve this? Regards, Amos.

6 5

[Users] INVITE transaction timer vs. SIP Proceeding timer
by Arek Bekiersz 02 Feb '06

02 Feb '06

Dear all, I think it will be useful for everybody. I have discussion with SIP device manufacturer about expiration time of call attempt. When call is made from UA it sends INVITE with "Expires: 65". It is controlled by device's timer setting "ring_time_limit". This timer can be set to anything between 10 and 600 seconds, we set it to 65 seconds. Fine. However at the same time it starts a special timer, say "max_response_time_invite". It can be set to anything between 8 and 20 seconds. We set it to 20 sec. Fine so far. CASE 1: Imagine we call from UA to PSTN number, using one of VoIP->PSTN providers. We have more than one provider, so we setup SER with "fr_timer" value of, let's say 25 seconds and "fr_inv_timer" of 60. We prepare failure routes in case when those timers hits in PSTN call. When "fr_timer" hits, we simply reroute to another gateway. Great. SER forwards INVITE from UA to remote PSTN gateway and at the same time sends back "100 Trying" to UA. Fine. Imagine now that it is busy-hour and it takes PSTN provider 21 seconds to send back "180 Ringing" (or "183 Session Progress") and after 8 seconds more remote callee picks up ("200 OK"). Unfortunately device wil send CANCEL to SER, because it hasn't received "180 Ringing" or "183 Session Progress" within the "max_response_time_invite" setting of 20 seconds. It only received "100 Trying" at the beginning. This ruined any failure route attempts from SER, as call failed. CASE 2: Imagine now a second call. This time PSTN provider send "183 Session Progress" after 14 seconds and remote callee picked up after further 15 seconds. This time everything went good. UA did not hit "max_response_time_invite" timer - it waited patiently for whole 29 seconds for remote callee to pick up. I think that when UA receives provisional response (like "100 Trying") from SER it should stop timer "max_response_time_invite" and use 'ring_time_limit'. What device does now, it uses: * "max_response_time_invite" when "100 Trying" received * "ring_time_limit" when "180 Ringing" or "183 Session Progress" received I haven't really found explanation of this in RFC3261. When you look at SIP state machine on page 128, it is not explicitly said which timer controls behaviour of UA when in "Proceeding" state ("Proceeding" is entered oin receipt of ANY provisional response). QUESTION 1: what timer controls behaviour of UA when in "Proceeding" state? Especially regarding timeout. Is this still the 'timer B' started at the beginning of INVITE transaction? If it is 'timer B', why UA is CANCELing transaction after 20 seconds, if it informed by "Expires: 65" field in INVITE that it set 'timer B' to 65 seconds. QUESTION 2: What should I propose to manufacturer for maximum value for "max_response_time_invite"? -- Thanks, Arek Bekiersz

2 1