sr-users May 2008

sr-users@lists.kamailio.org

121 participants
202 discussions

[OpenSER-Users] regarding presence module facing problem
by Amit Vijayvargiya 08 May '08

08 May '08

Hi All, i m add presence module in openser 1.3. but it not working properly. openser given this error --> DBG:tm:run_reqin_callbacks: trans=0xb60fa590, callback type 1, id 0 entered May 8 21:09:14 [20993] DBG:core:parse_headers: flags=ffffffffffffffff May 8 21:09:14 [20993] DBG:presence:search_event: start event= [message-summary] May 8 21:09:14 [20993] ERROR:presence:handle_subscribe: Missing or unsupported event header field value May 8 21:09:14 [20993] ERROR:presence:handle_subscribe: event= message-summary May 8 21:09:14 [20993] DBG:core:parse_headers: flags=ffffffffffffffff May 8 21:09:14 [20993] DBG:core:check_via_address: params 172.22.24.192, 172.22.24.192, 0 May 8 21:09:14 [20993] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Thanks & Regards Amit

2 1

[OpenSER-Users] OPenSER DISC Problem
by Dilip 08 May '08

08 May '08

Hello EveryOne, In the openser auth-diameter module,the first phase of digest AUTHETICATION of SIP is completly happening.But In the second phase when OPENSER sends the request to diameter client with authorization header,DISC server cant authorize the USER.Because the response of OPENSER and DISC SERVER are different. As per the code, In the DISC Server code, sipauth module is there which contains db.c file. In this file upto calc_response function call comes ,which calculate the response .This response and OPENSER response are different. Is that any configuration File Problem ? I have attached config file here. What was the reason for it? How can I solve this response problem? Thanks To Evrybody Regards, Dilip # # $Id: openser.cfg,v 1.6.2.1 2006/07/17 15:51:03 klaus_darilion Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=9 # 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 listen=192.168.1.1 #fifo="/tmp/openser_fifo" # # uncomment the following lines for TLS support #disable_tls = 0 #listen = tls:your_IP:5061 #tls_verify_server = 1 #tls_verify_client = 1 #tls_require_client_certificate = 0 #tls_method = TLSv1 #tls_certificate = "/usr/local/etc/openser/tls/user/user-cert.pem" #tls_private_key = "/usr/local/etc/openser/tls/user/user-privkey.pem" #tls_ca_list = "/usr/local/etc/openser/tls/user/user-calist.pem" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "/usr/local/lib64/openser/modules/mysql.so" #loadmodule "/usr/local/lib64/openser/modules/acc.so" loadmodule "/usr/local/lib64/openser/modules/sl.so" loadmodule "/usr/local/lib64/openser/modules/tm.so" loadmodule "/usr/local/lib64/openser/modules/rr.so" loadmodule "/usr/local/lib64/openser/modules/maxfwd.so" loadmodule "/usr/local/lib64/openser/modules/usrloc.so" loadmodule "/usr/local/lib64/openser/modules/registrar.so" loadmodule "/usr/local/lib64/openser/modules/textops.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib64/openser/modules/auth.so" loadmodule "/usr/local/lib64/openser/modules/auth_db.so" loadmodule "/usr/local/lib64/openser/modules/auth_diameter.so" ##Dilip loadmodule "/usr/local/lib64/openser/modules/domain.so" ##Dilip ############################################################ #modparam("dispatcher", "list_file", "/usr/local/etc/openser/dispatcher.list") #modparam("acc", "log_flag", 1) #modparam("acc", "log_missed_flag", 1) #modparam("acc", "service_type", 15) ############################################################# # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("usrloc|auth_db","db_url","mysql://openser:openserrw@localhost/openser") #Dilip #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", 1) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # modparam("auth_db", "password_column", "passwd_h") # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) ############################################################################################################ # Add By Dilip modparam("auth_diameter", "use_domain", 1) modparam("auth_diameter", "diameter_client_host", "linux173") modparam("auth_diameter", "diameter_client_port", 3000) ############################################################################################################ # ------------------------- 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; }; # 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()) { # 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("tls:domain1.net"); # exit; #} else if(uri=~"@tls_domain2.net") { # t_relay("tls:domain2.net"); # exit; #} route(1); }; #Add By Dilip if (method=="INVITE") { if (!diameter_www_authorize("linux173")) { www_challenge("", "0"); 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 (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication # if (!www_authorize("192.168.1.173", "subscriber")) { # www_challenge("192.168.1.173", "0"); # exit; # }; # Add by Dilip if(!diameter_www_authorize("linux173")) #if(!diameter_www_authorize("")) { #/* user is not authorized */ www_challenge("linux173", "1"); 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"); }; route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; exit; }

1 0

[OpenSER-Users] openseradmin-03 modification
by Zen Kato 08 May '08

08 May '08

Hi, I installed openseradmin-0.3 on openser-1.2.3-notls. There are some errors,but works fine. Is it possible for the following modifications using Ruby-on-Rail even for a Ruby beginner? user login (only 2 screens) ============ http://localhost:3000/user/login Login Required Login : 0103 Password: 0103 [login>>] --------------------------------- [logout] Name: Domain: Username: 0103 Password: 0103 Email Address: 0103@localhost Caller ID: Voicemail: No Voicemail Password: Created At: Last Updated At: [Edit] ---------------------------------- [logout] Username: 0103 Password: 0103 Domain: First Name: Last Name: Email Address: 0103@localhost Caller ID: Voicemail[ ] Voicemail Password: [Edit] show ---------------------------------- admin login =========== http://localhost:3000/admin/login Login Required Login : openser Password: openserrw [login>>] no modification for admin screens. -- Zen Kato

1 0

[OpenSER-Users] Increase MAX_BRANCHES value?
by Zappasodi Daniele 07 May '08

07 May '08

Hello, I'm interested in this question too. I have tried to modify the tm module and I have found a solution that extends the maximum number of branches and it seems to work, but I'm still testing it. Can anyone, more expert than me on the tm module, give a look to the attached file with my patch? Bye Daniele Hi, thanks for your answer... I increased the SHM_MEM_SIZE to 64 and left KG_MEM_POOL_SIZE 4*1024*1024 . Anyway i found that is not possible to raise MAX_BRANCHES to values higher than 30 due to tm module internal limitation. Bye, Marcello ********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message inerror. **********************************************************************

2 3

Re: [OpenSER-Users] srv load-balancing
by Stanisław Pitucha 07 May '08

07 May '08

----- "Bogdan-Andrei Iancu" <bogdan(a)voice-system.ro> wrote: > OpenSER it is not ignoring the weights - the received records are > ordered by weight. The tricky question is about records with the same > > weight - which to be used? openser is right now using the first > returned > by the DNS server. Ok - maybe I should expand that a bit: It's not disallowed behaviour, but rfc2782 specifies standard way for handling weights and sip protocol doesn't really need other handling afaik: --->8--- from http://www.faqs.org/rfcs/rfc2782.html --- The following algorithm SHOULD be used to order the SRV RRs of the same priority: To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. --->8--- So even if they have same weight: server1=50 and server2=50, openser should get random number X between 0 and 100 and select server1 for X<=50, or server2 for X>50. Currently openser is not using SRV records correctly imho - it's client responsibility to get all those RRs and select one of them randomly from all servers with selected priority (whether they have same weight or not). Please correct me if I'm wrong. Cheers, Stan

2 1

[OpenSER-Users] Prepaid Service with SER + B2BUA + Radius
by Ilker YILMAZ 07 May '08

07 May '08

Dear Group, I would like to have your comments on setting up successful prepaid service using SER + Sippy B2BUA and a Radius Server. Did anybody accomplished to drop a call when a user's balance is empty with B2BUA? I will really appreciate if you can share your experinces on this issue.. Thank You Ilker

1 0

[OpenSER-Users] 200 OK retransmissions on missing ACK can cause subsequent calls to fail
by Sean O'Donnell 07 May '08

07 May '08

Hi all, Im using openser as a call distributor/proxy between a soft-switch/SBC and voicemail platform. Im seeing a problem with openser in that it is sometimes cancels an in-progress call (fr_inv_timer firing) because it didnt match the 200/OK with the call. After some investigation, I noticed that this was happening after a missing ACK on a previous call caused the voicemail platform to retransmit 200/OK responses beyond the TM wt_timer expiration, which in turn left several openser child processes (those that received a 200 after wt_timer expiration) in a state such that they might not properly match transactions on subsequent calls. My setup: I have openser 1.2.0 operating on a linux box with two network interfaces, with one interface (call it the outside interface) taking incoming calls from the soft-switch, and the other (inside) connected to the VM platform. I have openser configured to use both interfaces (see config below) and the TM wt_timer set to 5 seconds (default). As this is a voicemail system, all of the call traffic is inbound from the soft-switch. Given the traffic flow, for the most part the openser child processes servicing the inside interface are handling responses (180,183,200) from the VM platform. Call scenario: When an INVITE arrives from the soft-switch, openser forwards it to the VM platform. The VM platform responds with a 180 and then a 200. I've noticed several instances where the soft-switch did not respond with an ACK. This caused the VM platform to retransmit the 200 several times over a 10 second period. These were absorbed correctly by openser for the duration of wt_timer. After the timer expired, however, each openser child process that received a retransmitted 200 logged something like this: 4(2715) DEBUG: t_reply_matching: hash 45870 label 727647196 branch 0 4(2715) DEBUG: t_reply_matching: no matching transaction exists 4(2715) DEBUG: t_reply_matching: failure to match a transaction 4(2715) DEBUG: t_check: end=(nil) When I look at the TM code, the static variable T in t_lookup.c is now NULL for this child process. On a subsequent inbound call, the INVITE is passed to the VM correctly, and the 180 transaction matches (causing the fr_inv_timer to be armed). If the 200 is read by child proc 2715, I see: 4(2715) DEBUG: t_check: start=(nil) 4(2715) DEBUG: t_check: T previously sought and not found The 200 is forwarded back to the soft-switch, which responds with an ACK. Both end-points think the call is up, but since openser never matched the 200 with the call, the fr_inv_timer fires and cancels the call. Basically, child proc 2715 wont match any transaction after this unless it happens to process a request. I think this problem is made worse by the fact that Im using two network interfaces, and that the openser children on the inside interface handle (for the most part) only responses. This problem was touched on here: http://lists.openser.org/pipermail/users/2007-November/014188.html but I didnt see any follow up. Also, Ive checked openser 1.2.3 and 1.3.1 for fixes, but I dont think this has been addressed. I have a work around, I think, by upping the wt_timer to something like 15 seconds, but I was wondering if there is any scenario in which leaving T=NULL is desirable. Thanks in advance Sean ==== CONFIG ===== # # VMPROXY-PROXY - route between softswitch and media servers # # ----------- global configuration parameters ------------------------ check_via=yes # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) children=8 # multi-homed (i.e. listen on two or more interfaces) mhomed=1 alias=sipproxy1 alias=sipproxy1.vmproxy.com port=5060 #inside address listen=192.168.1.100 #outside address listen=10.55.2.100 disable_dns_blacklist=yes # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database #loadmodule "/usr/local/openser/lib/openser/modules/mysql.so" mpath="/usr/local/openser/lib/openser/modules" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "exec.so" loadmodule "xlog.so" loadmodule "textops.so" loadmodule "options.so" loadmodule "mi_fifo.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "/usr/local/openser/lib/openser/modules/auth.so" #loadmodule "/usr/local/openser/lib/openser/modules/auth_db.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- # local memory #modparam("usrloc", "db_mode", 0) # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # uncomment this for multiple record routes #modparam("rr", "enable_double_rr", 1) # -- tm params -- modparam("tm", "fr_timer", 5) modparam("tm", "fr_inv_timer", 60) # -- mi_fifo parms modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo_proxy") # ------------------------- 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"); return; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); return; }; xlog("L_INFO","$Tf VMPROXY: <$rm> message From:<$fu> To:<$tu> srcip:<$si>\n"); # # 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 # record_route(); # # loose-route processing # messages that already have routes on them are proxied here # if (loose_route()) { t_relay(); return; }; # # message not for us, route it through # if ( !(uri==myself) ) { if (!t_relay()) { sl_reply_error(); }; return; }; xlog("L_DBG","$Tf VMPROXY: <$rm> for me\n"); # handle options meant for me if( method == "OPTIONS" ) { options_reply(); return; }; if( method == "REGISTER" || method == "PUBLISH" || method == "SUBSCRIBE" || method == "MESSAGE" ) { sl_send_reply("405","Method Not Allowed"); return; }; # route INVITE based on source if( method == "INVITE" ) { exec_dset("/usr/local/vmproxy/bin/routeINVITE.sh"); xlog("L_DBG","$Tf VMPROXY: <$rm> after routeINVITE: new destination <$ru>\n"); t_on_failure("1"); }; # route NOTIFY to softswitch if( method == "NOTIFY" ) { exec_dset("/usr/local/vmproxy/bin/routeNOTIFY.sh"); xlog("L_DBG","$Tf VMPROXY: <$rm> after routeNOTIFY: new destination <$ru>\n"); t_on_failure("2"); }; # # NOTE: this logic is only executed if the request didn't have # a route on it (tsk,tsk). If it did, it would have been handed via # loose route function above. if( method == "ACK" || method == "BYE" || method == "CANCEL" || method == "PRACK" ) { exec_dset("/usr/local/vmproxy/bin/routeACK.sh"); xlog("L_DBG","$Tf VMPROXY: <$rm> after routeACK: new destination <$ru>\n"); }; # routing script error? if( uri=="sip:err@127.0.0.1" ) { sl_reply_error(); return; }; # forward to current uri if (!t_relay()) { sl_reply_error(); }; } # # Initial INVITE route failed, retry # failure_route[1] { # endpoint canceled call if( t_was_cancelled()) { xlog("L_DBG", "$Tf VMPROXY: call <id:$ci> cancelled\n"); return; } # don't retry on 40[0-7|5xx failures if( !t_check_status("40[0-7]|420|487|488|5[0-9][0-9]")) { xlog("L_ERR","$Tf VMPROXY: ERROR routing call <$rm> from <$fu> to <$ru>\n"); exec_dset("/usr/local/vmproxy/bin/routeINVITE2.sh"); xlog("L_ERR","$Tf VMPROXY: Rerouting call <$rm> to <$ru>\n"); append_branch(); t_relay(); } } # # Initial NOTIFY route failed, retry # failure_route[2] { # endpoint canceled call if( t_was_cancelled()) { xlog("L_DBG", "$Tf VMPROXY: call <id:$ci> cancelled\n"); return; } # don't retry on 40[0-7|5xx failures if( !t_check_status("40[0-7]|5[0-9][0-9]")) { xlog("L_ERR","$Tf VMPROXY: ERROR routing <$rm> from <$fu> to <$ru>\n"); exec_dset("/usr/local/vmproxy/bin/routeNOTIFY2.sh"); xlog("L_ERR","$Tf VMPROXY: Rerouting <$rm> to <$ru>\n"); append_branch(); t_relay(); } }

2 1

[Serusers] SER Nokia CANCEL Problem
by Abdul Qadir 07 May '08

07 May '08

Hi , I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation. I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome. Thanking you all in advance. Best Regards, Abdul Qadir --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.

10 36

[OpenSER-Users] Pseudovariable for whole SIP-message
by Peter Lemenkov 07 May '08

07 May '08

Hello All! Is there a pseudovariable denoting the whole SIP-message? If not - are there plans for implementing such functionality? -- With best regards!

2 2

Re: [OpenSER-Users] Version table
by Henning Westerholt 07 May '08

07 May '08

On Wednesday 07 May 2008, Bård Aase wrote: >> [...] > Thanks, I will check this out now, I'm using OpenSER 1.3.1 and the > sip_buddies table looks like this: > [..] You'll find the subscriber DB docs (for trunk) at: http://www.openser.org/docs/db-tables/openser-db-devel.html#GEN-DB-SUBSCRIB… AFAIK there were some fiels removed, but except this it should be the same format as in the 1.3 branch. > The openser.cfg configuration for auth_db: > [..] > modparam("auth_db", "calculate_ha1", yes) > modparam("auth_db", "user_column", "name") > modparam("auth_db", "domain_column", "domain") > modparam("auth_db", "password_column", "secret") > modparam("auth_db", "password_column_2", "ha1b") > modparam("auth_db", "use_domain", 0) > modparam("auth_db", "db_url", > "mysql://UNDISCLOSED:UNDISCLOSED@UNDISCLOSED/asterisk") > > All the fields referred to here exists in the asterisk.sip_buddies > table, so my guess now is that this is just a matter of disabling the > version check, or bumping the version number. I think the same. If the semantics of the colums in question are also the same, then it should work just fine. Regards, Henning

1 0

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 May 2008