sr-dev March 2010

sr-dev@lists.kamailio.org

24 participants
359 discussions

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Iñaki Baz Castillo (ibc) ---------- Regarding the invented response: I would always prefer a timeout over some 500 a downstream proxy might have sent (the 408 says at least that there might be a working phone, but the user didn't pick it up). If gw1 doesn't send a reply (neither a provisional) then fr_timer expires and creates a local 408. Of course this 408 means nothing about "there might be a working phone, but the user didn't pick it up". So I'd strongly prefer the 500 received from gw2. Please check also the report [[http://sip-router.org/tracker/index.php?do=details&task_id=55&project=1|rep… 55]] in which I suggest a solution for locally generated responses. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment71 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 7 months

[tracker] Task opened: Improving logging (show at least the transaction branch)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Iñaki Baz Castillo (ibc) Attached to Project - sip-router Summary - Improving logging (show at least the transaction branch) Task Type - Improvement Category - logging Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Low Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Sometimes I inspect the log of SR/Kamailio and find errors like: ERROR:nathelper:force_rtp_proxy: incorrect port 0 in reply from rtp proxy or: WARNING:dialog:dlg_onroute: unable to find dialog for BYE with route param '7b4.36497575' [1207:1465357411] Of course in a server with high traffic such logs help nothing (even if I'm capturing all the SIP flow via pcap or 'siptrace' module). It would be great if the logging core system would log always "something" related to the request or transaction, perhaps the branch, something as: ERROR[recv 183 z9hG4bK6887.92b352f.0]:nathelper:force_rtp_proxy: incorrect port 0 in reply from rtp proxy WARNING[sent BYE z9hG4bK68612qwre1h3]:dialog:dlg_onroute: unable to find dialog for BYE with route param '7b4.36497575' [1207:1465357411] It would help a lot when debugging occasional issues (perhaps more related to a specific client rather than the SR/Kamailio server). More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=57 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 7 months

[tracker] Assignee added: Improving logging (show at least the transaction branch)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#57 - Improving logging (show at least the transaction branch) User who did this - Iñaki Baz Castillo (ibc) http://sip-router.org/tracker/index.php?do=details&task_id=57 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 7 months

Re: [sr-dev] [Kamailio-Users] Fast lock loop with arm

by Daniel-Constantin Mierla

Hello, what version of kamailio do you use? Can you grab a backtrace with gdb once you get this high cpu usage? Spot one of the processes, take the pid and do: gdb /path/to/kamailio _pid_ Then: bt You should see the bactrace of executed function getting to deadloc. Make sure you get at least one SIP worker process backtrace (do kamctl ps to see the type of kamailio process). Cheers, Daniel On 3/24/10 4:29 PM, Zappasodi Daniele wrote: > > Hi, > I have a big problem with fast lock mutex on arm CPU: > sometimes I find one or more children that go in an infinite loop, in > the while loop of get_lock function. > They remain in Run for long time (sometimes hours) and openser keeps > 100% CPU. > > Now I have changed the functions get_lock and tsl in order to obtain > more info and > I observe that (if and) when the process finish the cycle, it have > done a big amount of cycles. > > This the log with my added info: > Mar 26 20:29:08 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 1 (cycle) > Mar 26 20:29:51 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 1 (cycle) > Mar 26 20:29:55 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 1 (cycle) > > Mar 26 20:29:55 SAM-IP openser[1645]: NOTICE:tm:t_retransmit_reply: > MYTM lock > [process in loop] > Mar 26 20:33:46 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 59374917 > (cycle) > [after 4 minutes and 59374917 cycles, this is an example with a > "short" loop] > Mar 26 20:33:46 SAM-IP openser[1645]: NOTICE:tm:t_retransmit_reply: > MYTM lock done > > I'm not able to recognize the call flow that generates the loop (I > know only that it always happens when t_retransmit_reply calls > LOCK_REPLIES), > > but I urgently need a work around to escape from the loop. > > This is the get_lock function with my counter j: > > inline static int get_lock(fl_lock_t* lock) > { > #ifdef ADAPTIVE_WAIT > int i=ADAPTIVE_WAIT_LOOPS; > int j=1; /***** my change ****/ > #endif > > while(tsl(lock)){ > #ifdef BUSY_WAIT > #elif defined ADAPTIVE_WAIT > j++; /***** my change ****/ > if (i>0) i--; > else sched_yield(); > #else > sched_yield(); > #endif > } > return(j); > } > > Can I break the lock when my counter reaches a big value? > Should I call the unlock function after the break? > which value can be considered too big? > > Thanks, > Daniele > > > > ********************************************************************** > 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 in error. > ********************************************************************** > > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 7 months

GSoC 2010 Student Registration is Open

by Daniel-Constantin Mierla

Hello, if you are a student (or know one) interested in working with SIP and Presence over the summer, earn some money and experience, you have the choice of Kamailio - SIP Router project within SIP Communicator organization: http://www.kamailio.org/w/gsoc-2010/ Registration is now open, up to April 9, more details in above link. If you have further questions, drop an email. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla

14 years, 7 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Andrei Pelinescu-Onciul (andrei) ---------- Regarding the option, I'll add a local_repl_prio_adj option, but it's low priority and I have a long todo list (if you don't see it when the 3.1 freeze is announced, it means I forgot and you should bug me about it). ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment70 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 8 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Andrei Pelinescu-Onciul (andrei) ---------- Alex, DNS failover is automatically attempted if a 503 is received or on timeout (just making sure that you don't try to do in script something that is already automatically handled). I guess your example is valid if you don't want to do DNS failover on the local proxy, but on the upstream one. Regarding the invented response: I would always prefer a timeout over some 500 a downstream proxy might have sent (the 408 says at least that there might be a working phone, but the user didn't pick it up). For 4xx responses is not so clear, it's debatable if one should prefer a 408 over a 480 or even a 486. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment69 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 8 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Alex Hermann (axlh) ---------- Andrei, making the priorities configurable would be a nice addition. For the example I gave with DNS based failover an even simpler solution is possible. In the DNS failover case i'm only interested in the replies from the last contacted host. Because the other hosts already gave responses i'm not interested in, hence the failover to the next host. So an option to only consider replies from the last host (branch) would (also) be a nice solution. I could use that in other cases too, because in general, i'm only interested in the responses from the last branch (but that might be related to my specific use cases). The question i asked myself is: why would i prefer a (invented) response from a host that __fails__ above the response from a responding host. I couldn't find an anwer... ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment68 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 8 months

about dp_translate()

by jh＠tutpro.com

currently, dialplan module dp_translate() function requires src/dest style second parameter even in cases where a dialplan id consists of rules where subst_exp and repl_exp are missing, i.e., when dp_translate() is only used for matching and possibly setting of attrs avp. how about if i try to change the syntax of second param to be src[/dst] if /dst is missing then no replacement is done? -- juha

14 years, 8 months

[tracker] Comment added: Cfg parsing error for alias/listen and custom global parameter

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#56 - Cfg parsing error for alias/listen and custom global parameter User who did this - Iñaki Baz Castillo (ibc) ---------- Doesn't the grammar parser split the parameter declarations into lines? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=56#comment67 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2010