sr-users December 2013

sr-users@lists.kamailio.org

70 participants
131 discussions

Start a nNew thread

Re: [SR-Users] memory
by Keith 17 Dec '13

17 Dec '13

Hi, Yeah sorry, I had to restart it as it's a production box. I have the log file which I can show you? Cheers Keith

1 0

Re: [SR-Users] Memory
by Keith 17 Dec '13

17 Dec '13

Hi, Here are the details: Version: 4.02 *kamcmd pkg.stats:* { entry: 0 pid: 15738 rank: 0 used: 1521632 free: 2504528 real_used: 1689776 } { entry: 1 pid: 15745 rank: 1 used: 1530112 free: 2495248 real_used: 1699056 } { entry: 2 pid: 15746 rank: 2 used: 1529920 free: 2496240 real_used: 1698064 } { entry: 3 pid: 15747 rank: 3 used: 1529920 free: 2496240 real_used: 1698064 } { entry: 4 pid: 15748 rank: 4 used: 1529920 free: 2496240 real_used: 1698064 } { entry: 5 pid: 15749 rank: 5 used: 1530192 free: 2494816 real_used: 1699488 } { entry: 6 pid: 15751 rank: 6 used: 1530208 free: 2494768 real_used: 1699536 } { entry: 7 pid: 15753 rank: 7 used: 1530192 free: 2494848 real_used: 1699456 } { entry: 8 pid: 15754 rank: 8 used: 1530192 free: 2494848 real_used: 1699456 } { entry: 9 pid: 15756 rank: 9 used: 1555456 free: 2458096 real_used: 1736208 } { entry: 10 pid: 15757 rank: 10 used: 1557328 free: 2455264 real_used: 1739040 } { entry: 11 pid: 15758 rank: 11 used: 1557216 free: 2455536 real_used: 1738768 } { entry: 12 pid: 15759 rank: 12 used: 1555952 free: 2457632 real_used: 1736672 } { entry: 13 pid: 15760 rank: -1 used: 2891024 free: 2496064 real_used: 3029088 } { entry: 14 pid: 15761 rank: -1 used: 2879152 free: 2496096 real_used: 3017216 } { entry: 15 pid: 0 rank: 0 used: 1539584 free: 2486512 real_used: 1707792 } { entry: 16 pid: 15776 rank: -2 used: 1532704 free: 2493424 real_used: 1700880 } { entry: 17 pid: 15778 rank: -1 used: 1532224 free: 2493872 real_used: 1700432 } { entry: 18 pid: 15779 rank: -1 used: 1532032 free: 2494096 real_used: 1700208 } { entry: 19 pid: 15782 rank: 13 used: 1610320 free: 2415744 real_used: 1778560 } { entry: 20 pid: 15784 rank: 14 used: 1610320 free: 2415744 real_used: 1778560 } { entry: 21 pid: 15786 rank: 15 used: 1610320 free: 2415744 real_used: 1778560 } { entry: 22 pid: 15788 rank: 16 used: 1610320 free: 2415744 real_used: 1778560 } { entry: 23 pid: 15790 rank: -4 used: 1603056 free: 2423008 real_used: 1771296 } *kamcmd stats* core:bad_URIs_rcvd = 0 core:bad_msg_hdr = 0 core:drop_replies = 0 core:drop_requests = 50 core:err_replies = 0 core:err_requests = 0 core:fwd_replies = 0 core:fwd_requests = 352 core:rcv_replies = 5181 core:rcv_requests = 5522 core:unsupported_methods = 0 dialog:active_dialogs = 34 dialog:early_dialogs = 0 dialog:expired_dialogs = 0 dialog:failed_dialogs = 60 dialog:processed_dialogs = 272 dns:failed_dns_request = 0 mysql:driver_errors = 0 registrar:accepted_regs = 103 registrar:default_expire = 3600 registrar:default_expires_range = 0 registrar:max_contacts = 0 registrar:max_expires = 3600 registrar:rejected_regs = 0 shmem:fragments = 1633 shmem:free_size = 64059008 shmem:max_used_size = 3755584 shmem:real_used_size = 3049856 shmem:total_size = 67108864 shmem:used_size = 2911792 siptrace:traced_replies = 0 siptrace:traced_requests = 0 sl:1xx_replies = 0 sl:200_replies = 616 sl:202_replies = 0 sl:2xx_replies = 0 sl:300_replies = 0 sl:301_replies = 0 sl:302_replies = 0 sl:3xx_replies = 0 sl:400_replies = 0 sl:401_replies = 81 sl:403_replies = 0 sl:404_replies = 0 sl:407_replies = 54 sl:408_replies = 0 sl:483_replies = 0 sl:4xx_replies = 0 sl:500_replies = 0 sl:5xx_replies = 0 sl:6xx_replies = 0 sl:failures = 0 sl:received_ACKs = 50 sl:sent_err_replies = 0 sl:sent_replies = 751 sl:xxx_replies = 0 sst:expired_sst = 0 tcp:con_reset = 0 tcp:con_timeout = 0 tcp:connect_failed = 0 tcp:connect_success = 0 tcp:current_opened_connections = 0 tcp:current_write_queue_size = 0 tcp:established = 0 tcp:local_reject = 0 tcp:passive_open = 0 tcp:send_timeout = 0 tcp:sendq_full = 0 tmx:2xx_transactions = 4543 tmx:3xx_transactions = 0 tmx:4xx_transactions = 795 tmx:5xx_transactions = 110 tmx:6xx_transactions = 0 tmx:UAC_transactions = 2365 tmx:UAS_transactions = 5449 tmx:active_transactions = 1 tmx:inuse_transactions = 8 tmx:local_replies = 1317 usrloc:location-contacts = 35 usrloc:location-expires = 2 usrloc:location-users = 35 usrloc:registered_users = 35 Thanks!

2 1

Calling end_media_session twice
by Teddy Rabary 17 Dec '13

17 Dec '13

Hi all, I see this discussion about mediaproxy and it's the same what happens to me http://opensips.org/pipermail/users/2010-August/013997.html Indeed in my kamailio.cfg, I call twice end_media_session on "bye" and on "cancel" route[CANCEL] { if (is_method("CANCEL")) { end_media_session(); if (t_check_trans()) t_relay(); exit; } } and route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { end_media_session(); setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails $avp(s:can_uri) = $ru; } if ( is_method("ACK") ) { # ACK is forwarded statelessy route(NATMANAGE); } route(RELAY); } else { ... I thought both are necessary, so can I make something like this at route[WITHINDLG] ? ... if (is_method("BYE|CANCEL")) { end_media_session(); setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails $avp(s:can_uri) = $ru; } ... and then remove end_media_session at route[CANCEL] ? Regards.

2 1

Memory
by Keith 16 Dec '13

16 Dec '13

Hi, Not sure if this is a bug or config but getting this error message: insert_subst_lump_after(): ERROR: insert_new_lump_after: out of memory Any ideas? Keith

2 1

S-CSCF strange execution effects
by Flavio Battimo 16 Dec '13

16 Dec '13

Hello, i'm encountering in some strange behaviours while working with S-CSCF version: kamailio 4.1.0 (x86_64/linux) 350d2e Making some tests, in particular with Ro interface for online charging, the script execution doesn't follow normal flow (checking it by adding some xlog call). Looking at the following code script, i have made some modifications: 1) Modify the P-Asserted-Identity so as to add angle brackets to the value. 2) Add user=phone parameter to uri if it doesn't exists 3) Enabled RO interface for accounting The amazing thing is that if kamailio is executed with this script the whole flow terminates without any notice just after record_route() call. Making some attempts, removing record_route() call flow continues until Ro_CCR method, where same behaviour appears (call flow is unpredictable terminated and no diameter CCR request is made) Which kind of operations can lead to this strange behaviour If is needed i can attach some logs in debug level mode Thanks in advance ###################################################################### # Originating, Intial Requests ###################################################################### route[orig] { xlog("L_DBG","Enter orig route\n"); # modifica di P-Asserted-Identity subst('/P\-Asserted\-Identity:[ ]*([\+0-9a-z@\.\-\:]*)/P-Asserted-Identity: <\1>\r\n/ig'); if ($ru =~ ".*;user=phone.*" ){ xlog("L_DBG","Parameter user=phone already exists"); } else { xlog("L_DBG","Adding parameter user=phone"); $ru = $ru + ";user=phone"; } xlog("L_DBG","$rm $ru"); set_dlg_profile("orig"); # we MAYBE need something like this to check if a user is barred # if (S_originating_barred()){ # sl_send_reply("403","Forbidden - Originating Public Identity barred"); # exit; # } xlog("L_DBG","Checking AVP mo custom\n"); if (is_method("INVITE|SUBSCRIBE")) { xlog("L_DBG","Adding AVP mo custom parameter\n"); $avp(RR_CUSTOM_USER_AVP)="mo"; xlog("L_DBG","call record_route\n"); record_route(); } #!ifdef WITH_RO # before we allow call - lets check credit xlog("L_DBG","Checking if RO must be called\n"); if (is_method("INVITE")) { xlog("L_DBG","Sending initial CCR Request for call\n"); Ro_CCR("CHARGING_CCR_REPLY", "orig", "SCUR", "", "30"); } #!else xlog("L_DBG","calling route[finalize_orig]"); route(Finalize_Orig); #!endif } -- Flavio Battimo flavio.battimo(a)gmail.com fbattimo(a)meetecho.com skype: flaviobattimo

3 2

500 I'm terribly sorry error
by Helena Garcia-Nieto 16 Dec '13

16 Dec '13

Hello, Thanks in advanced for the help. I am almost new with kamailio and still struggling through silly problems so please forgive me if the solution is so obvious. I have a network like Xlitle -- Kamailio -- GW The GW is more or less out of my reach for changing the behaivour. As devices I have xlitle Kamailio is on version 4.0.2 I've changed only few things from the default config file. Add mysql support, auth, userlocdb, pstngw. For this part, gw routing , I've defined gw ip and port inside the PSTN definition like: #!ifdef WITH_PSTN # PSTN GW Routing # # - pstn.gw_ip: valid IP or hostname as string value, example: # pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" # # - by default is empty to avoid misrouting pstn.gw_ip = "" desc "PSTN GW Address" pstn.gw_port = "" desc "PSTN GW Port" iskratel.gw_ip = "10.XX.XX.XX" iskratel.gw_port = "5060" #!endif I route the calls with: route(ISKRATEL); And defined a routing function route[ISKRATEL] { #!ifdef WITH_PSTN # check if ISKRATEL GW IP is defined if (strempty($sel(cfg_get.iskratel.gw_ip))) { xlog("SCRIPT: PSTN rotuing enabled but iskratel.gw_ip not defined\n"); return; } # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } if (strempty($sel(cfg_get.iskratel.gw_port))) { $ru = "sip:" + $rU + "@" + $sel(cfg_get.iskratel.gw_ip); } else { $ru = "sip:" + $rU + "@" + $sel(cfg_get.iskratel.gw_ip) + ":" + $sel(cfg_get.iskratel.gw_port); } # Add profix to ISKRATEL: A99901 subst_uri('/^sip:(.*)/sip:A99901\1/i'); # add A99901 route(RELAY); exit; #!endif return; } I can see that the code goes all the way to the route(relay) but all I can see is the 500 I'm terribly sorry, server error occurred (7/SL) and a second response 500 I'm terribly sorry, server error occurred (7/TM) I've tried defining the IP as the given pstn.gw_ip and route(pstn) without changing anything on the pst default routing but the response of the server is the same. I cannot see any special error on the logs. I have the exact same config for this part, in another test server and the calls go to the gw without reporting any error. I'll appreciate any help from you! Thanks in advanced for your time Helena

3 8

Trying to understand the interal workings of Dispatcher and timers
by Grant Bagdasarian 16 Dec '13

16 Dec '13

Hello, I'm trying to understand how the dispatcher module works and how the timers in the TM module influence the behavior. My architecture looks like this: UA1 ---- SBC1 ---- Kamailio ----- SBC2 ---- FreeSWITCH App Server(x2) What I got so far: 1) UA1 sends an INVITE to SBC1, which bridges the call between the UA1 and Kamailio 2) INVITE is received by Kamailio. 3) Kamailio looks in its dispatcher table to dispatch the INVITE to its destination 4) Kamailio rewrites the $du value to that of the SBC2 5) Kamailio rewrites the request-uri and sends the INVITE to the destination in $du. 6) SBC2 is a FreeSWITCH instance which bridges the call (does not answer). It only responds back with a 100 TRYING 7) SBC2 tries to contact the endpoint (FS App Server 1) in the request-uri, but the destination does not respond because it is unavailable. 8) Kamailio keeps waiting for a final reply. 9) The fr_inv_timer is set to 5000 on startup 10) Once the timer hits, Kamailio executes the route set in t_failure_route 11) The failure route looks like this: if(t_is_expired()) { ... } if (t_is_canceled()) { ... } if(t_check_status("500") || t_branch_timeout() || !t_branch_replied()) { .... } 12) Kamailio enters the third if block in which the next domain is selected and the $du is rewritten again to that of SBC2 13) A new INVITE is generated and sent to its destination (FS App Server 2) through SBC2. Nothing is sent back to SBC1 yet, because Kamailio handles the failover here. Is this correct? Are there any other timers which are fired which I missed, or does the fr_inv_timer have nothing to do with this? If Kamailio is supposed to load balance between FS App Server 1 and 2 using the Round-Robin algorithm, does it in case of an unreachable first destination take the next destination in the route set? Regards, Grant

2 1

Kamailio stability/timing problem w.r.t. registrations?
by Sotas Development 16 Dec '13

16 Dec '13

Hi, We run Kamailio 3.2.3 (FLAVOUR=ser) on an embedded ARM platform in near- default configuration. In a duration test, we observe that at a certain moment Kamailio seems to start ignoring all (re-)register messages, and eventually expires the existing registrations. We have not been able to reproduce the issue using debug-level logging (-dddd). Info-level logging (-ddd) does reproduce the error, but does not produce any error messages. Configuration: ser-basic.cfg, with the following changes: port=5060 alias=testnet Command line: ser -m 4 -f /etc/ser/ser-basic.cfg -n3 -l udp:eth0 Load: Bursts of 8 (Re-)REGISTER messages that are repeated every 85 seconds. The specified expiration time is 120 seconds. Bursts of 9 (Re-)INVITE messages that are repeated every 45 seconds. Note: With this load it takes roughly 1 hour for the error to occur. Using a more standard 3600 second expiration time Kamailio still stalls, it just takes longer. Does anyone have any idea how to tackle this issue? Kind regards, Michiel Veldkamp

3 14

flatstore.rotate not working
by Abdelkader Allam 16 Dec '13

16 Dec '13

Hello Guys, I am using Kamailio 4.1.0. I am trying to get Kamailio to rotate the cdr log through command kamcmd flatstore.rotate but it keeps sending log to the renamed files, I use the following parameter (i tried to set flush to 1 and 0, same result, i have also tried in debug and normal mode) #!define WITH_ACCFILE # ----- acc params ----- /* what special events should be accounted ? */ modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) /* enhanced DB accounting */ modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) #!ifdef WITH_ACCFILE modparam("acc", "db_url", "flatstore:/var/log/kamailio") modparam("db_flatstore", "flush", 1) modparam("acc", "cdr_enable", 1) #modparam("acc", "cdr_flag", 3) modparam("acc", "db_extra","ds=$DLG_lifetime") modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;" "duration=$DLG_lifetime") modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;" "duration=$avp(i:256)") #!endif

2 10

Outbound Calls using pstn.gw_ip
by Rajah Chowbay 16 Dec '13

16 Dec '13

Setup: jitsi --> kamailio <-----> pstn.gw jitsi is registered using TCP SIP Trunk between kamailio and pstn.gw is using TCP Initial invite from jitsi to kamailio is sent using TCP but invite sent from kamailio to pstn.gw is being sent with UDP. How can I configure kamailio to send invite to pstn.gw with TCP? Thank You

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
14
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 December 2013